https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43757 Bug ID: 43757 Summary: EDIFACT parser drops syntax 4 interchanges silently and dies on a missing UNA Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs@lists.koha-community.org Reporter: martin.renvoize@openfifth.co.uk QA Contact: testopia@bugs.koha-community.org Target Milestone: --- Koha::Edifact::service_string_advice only accepts the exact string ":+.? '" and the failure paths are silent or fatal: 1. An interchange using syntax version 4 service characters, for example UNA:+.?*' , is not accepted. In syntax version 3 the fifth UNA character is reserved (a space); in syntax version 4 it is the repetition separator (default asterisk). Koha does not use repetition, so it can simply be ignored, but at present the file is thrown away. Result on main: the parser only carps "Non standard Service String Advice", Koha::Edifact->message_array returns 0 messages, process_invoice (and process_quote / process_ordrsp) then mark the message 'received' having done nothing. An invoice is lost without any error being shown to staff. 2. An interchange that does not start with UNA makes Koha::Edifact->new croak ("File does not start with a Service string advice"). The calls in edi_cron.pl are not wrapped, so the whole cron run stops: the remaining messages and accounts are not processed and the message is left in status 'processing'. Reproduced on main with a minimal interchange: - UNA:+.?*' -> messages = 0, warning only - no UNA -> dies References: ISO 9735 service string advice as profiled for syntax versions 3 and 4 (for example Odette OS11 "Structure of an EDIFACT Interchange", sections 2.2 and 4, and GS1 EANCOM syntax documentation). Note that for character sets other than UNOA/UNOB the default separators are non-printable, so a sender using printable separators is required to send UNA; a missing UNA is therefore a supplier-side error rather than something Koha should guess at. Proposed changes: a. Accept the syntax 4 service string advice by ignoring position 5, and keep refusing separators Koha cannot handle. b. When an interchange cannot be parsed, or parses to no messages, set the edifact_messages status to 'error', add an edifact_errors row with the reason, and carry on with the next message instead of marking it received or dying. (Optionally, as a follow-up, assume the standard separators when UNA is absent.) Test plan: 1. Add an INVOIC message whose interchange starts with UNA:+.?*' to edifact_messages and process it. 2. Without the patch: no invoice is created, the message is marked received, and no error is recorded. 3. With the patch: the invoice is created as it would be with UNA:+.? '. 4. Add a message with no UNA and a second, valid message, then run misc/cronjobs/edi_cron.pl (or process_invoice on both). 5. Without the patch: the cron dies on the first message. With the patch: the first message has status 'error' with an edifact_errors row, and the second is processed. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.