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: [email protected]
Reporter: [email protected]
QA Contact: [email protected]
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.
_______________________________________________
Koha-bugs mailing list -- [email protected]
To unsubscribe send an email to [email protected]
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
