- Koha-bugs - lists.koha-community.org

[Bug 43789] New: EDI quote processing dies with undefined to_json when AcquisitionLog is enabled
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43789 Bug ID: 43789 Summary: EDI quote processing dies with undefined to_json when AcquisitionLog is enabled Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Koha::EDI::process_quote logs the automatic basket approval with to_json( $approved->unblessed ), but Koha::EDI only imports encode_json from JSON: use JSON qw( encode_json ); so when a vendor has auto_orders enabled and the AcquisitionLog system preference is on, edi_cron.pl fails after the order has been generated and the basket closed: Undefined subroutine &Koha::EDI::to_json called at Koha/EDI.pm line NNN. The APPROVE_BASKET entry is never written to the action log and processing of any remaining auto-ordered baskets in the same run is aborted. Test plan: 1. Enable the EDIFACT and AcquisitionLog system preferences. 2. Configure a vendor EDI account with quotes_enabled and auto_orders enabled. 3. Process a quote for that vendor (misc/cronjobs/edi_cron.pl, or process_quote in a test). 4. Without the patch: Undefined subroutine &Koha::EDI::to_json is raised. 5. Apply the patch and repeat: no error, the basket is closed, the EDI order is created and an ACQUISITIONS / APPROVE_BASKET entry exists in the action logs. 6. prove t/db_dependent/Koha/EDI.t -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 43732] New: koha-create doesn't output a message about enabling email
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43732 Bug ID: 43732 Summary: koha-create doesn't output a message about enabling email Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: robin(a)kallisti.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: mtj(a)kohaaloha.com Target Milestone: --- koha-create is supposed to output a message telling you that email isn't enabled and how to enable it. Due to a bug, it doesn't. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 20252] New: If an EDI orderline is cancelled send a cancellation message
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20252 Bug ID: 20252 Summary: If an EDI orderline is cancelled send a cancellation message Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: colin.campbell(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org On cancelling a order if the order has been submitted as an edifact order an ORDCHG message should be generated and transmitted. ORDCHG will contain the order reference and the ean for the item -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 27235] New: Add gzip to package dependencies
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27235 Bug ID: 27235 Summary: Add gzip to package dependencies Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: mtj(a)kohaaloha.com Both koha-dump and koha-translate (since Bug 24211) use gzip. While it appears to be installed in Debian/Ubuntu by the time we run Koha, we should explicitly reference it as a dependency. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 43696] New: ISO 18626 date-times are not UTC
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43696 Bug ID: 43696 Summary: ISO 18626 date-times are not UTC Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Target Milestone: --- -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 41789] New: EDIFACT messages broken by unidecode
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41789 Bug ID: 41789 Summary: EDIFACT messages broken by unidecode Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: andreas.jonsson(a)kreablo.se QA Contact: testopia(a)bugs.koha-community.org In EDI.pm EDIFACT messages are built and the result is passed to unidecode. However, unidecode replace unicode characters with the transliterated ascii characters which may include characters that have special meaning including apostrophe '. my $order_file = $edifact->encode(); # ingest result if ($order_file) { my $m = unidecode($order_file); # remove diacritics and non-latin chars But this must be done before escaping special characters. For instance: diff --git a/Koha/Edifact/Order.pm b/Koha/Edifact/Order.pm index a36bd7e1b5b..096e66d5f3e 100644 --- a/Koha/Edifact/Order.pm +++ b/Koha/Edifact/Order.pm @@ -27,6 +27,7 @@ use Readonly qw( Readonly ); use Koha::Database; use Koha::DateUtils qw( dt_from_string ); use C4::Budgets qw( GetBudget ); +use Text::Unidecode qw( unidecode ); use Koha::Acquisition::Orders; @@ -685,6 +686,7 @@ sub _interchange_sr_identifier { sub encode_text { my $string = shift; if ($string) { + $string = unidecode( $string ); $string =~ s/[?]/??/g; $string =~ s/'/?'/g; $string =~ s/:/?:/g; -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 43757] New: EDIFACT parser drops syntax 4 interchanges silently and dies on a missing UNA
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

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(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)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.

1 2

[Bug 43756] New: EDI invoice processing receives lines for cancelled orders and re-opens them
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43756 Bug ID: 43756 Summary: EDI invoice processing receives lines for cancelled orders and re-opens them Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Koha::EDI::process_invoice receives an invoice line even when the order it refers to has been cancelled in Koha. The cancelled order is received like any other: its status is changed from cancelled to complete, quantityreceived and prices are set, and nothing is recorded in edifact_errors. Bug 38423 made process_invoice skip and report lines that cannot be receipted (no ordernumber, unknown order, deleted record) and its description names cancelled orders as one of the problem cases, but a cancelled order is not skipped. Process_invoice already records a warning for an order that is already complete; a cancelled order gets no such treatment. Reproduced on main (vendor EDI account without plugin): an order with orderstatus 'cancelled' and one linked item, and an invoice for it with QTY+47:1 and RFF+LI pointing to the order. - order status after processing: complete (quantityreceived 1) - edifact_errors: none - message status: received This silently undoes a cancellation (for example one made by staff or by an ORDRSP cancel), re-opens spent budget and gives staff no indication that the supplier invoiced a line the library believed was cancelled. Proposed behaviour: skip the line, leave the order cancelled, and add an edifact_errors row (with the invoice number) saying the invoice line refers to a cancelled order, so staff can reconcile it with the supplier. Test plan: 1. Create an order line and cancel it. 2. Process an EDIFACT invoice that refers to the order with RFF+LI. 3. Without the patch: the order becomes complete and no error is shown. 4. With the patch: the order stays cancelled, other lines on the invoice are still received, and the EDIFACT messages page shows an error for the invoice line referring to a cancelled order. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 43754] New: EDI invoice receipt does not update item acquisition fields like manual receive does
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43754 Bug ID: 43754 Summary: EDI invoice receipt does not update item acquisition fields like manual receive does Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- When an EDIFACT invoice is processed, Koha::EDI::receipt_items only assigns a barcode (from GIR LAC) and applies AcqItemSetSubfieldsWhenReceived. It does not touch any of the other fields that the manual receive path sets. Manual receive (acqui/finishreceive.pl) updates every item linked to the received order with: booksellerid, dateaccessioned, datelastseen, price, replacementprice, replacementpricedate EDI receipt sets none of these, so items received through an invoice end up with different data from the same items received by hand: no source of acquisition, an accession date that is still the order date, and no price or replacement price. Reproduced on main with a vendor EDI account (no plugin), a basket with create_items=ordering, an order for 2 copies each with a linked item (dateaccessioned 2020-01-01), and an INVOIC for the 2 copies carrying matching GIR+LLO segments: - order becomes complete, quantityreceived 2 - items: booksellerid NULL, dateaccessioned still 2020-01-01, price NULL, replacementprice NULL Expected: the same item fields as a manual receive, using the invoice date as the received date, the vendor of the basket and the invoiced/replacement prices of the received order. Note this is separate from Bug 42890 (creating items when AcqCreateItem=receiving). Test plan: 1. Create a vendor with an EDI account (no plugin) and a basket with AcqCreateItem=ordering. Add an order line for 2 copies so that 2 items exist. 2. Import an EDIFACT invoice for that order (RFF+LI with the order number, QTY+47:2, MOA+203/MOA+128) and process it. 3. Without the patch: the items have no booksellerid, an unchanged dateaccessioned, and empty price and replacementprice. 4. With the patch: the items have the vendor as booksellerid, dateaccessioned and datelastseen set to the invoice date, price set from the received unit price, and replacementprice/replacementpricedate set as in a manual receive. 5. Repeat with a partial receipt (invoice 1 of 3) and confirm only the received items are updated. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 43535] New: Support matching EDIFACT invoice lines to orders via RFF+SLI
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43535 Bug ID: 43535 Summary: Support matching EDIFACT invoice lines to orders via RFF+SLI Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Depends on: 43534 Target Milestone: --- Koha::Edifact::Line already parses the RFF+SLI segment (supplier's unique order line reference number) into orderline_reference_number for both QUOTES and INVOIC messages. However, Koha::EDI's process_invoice only ever matches an incoming invoice line to an aqorders row via RFF+LI (Koha's own internal ordernumber, which the supplier is expected to echo back because Koha sent it in the original EDIFACT ORDERS message). If RFF+LI is missing, or was never set in the first place, the invoice line is skipped and logged as an error - even in cases where RFF+SLI carries a vendor reference that could be matched against aqorders.suppliers_reference_number. Use case: Vendors such as GOBI/YBP support ordering via MARC file import (Koha's MarcFieldsToOrder workflow, see bug 43534) rather than via EDIFACT ORDERS, yet still return EDIFACT INVOIC invoices referencing their own order/line ID via RFF+SLI (e.g. the GOBI order ID). Because Koha never sent an ORDERS message for those lines, there is no RFF+LI value the vendor can echo back, so the invoice lines currently cannot be auto-matched at all. Bug 43534 proposes capturing that vendor reference into aqorders.suppliers_reference_number / suppliers_reference_qualifier at MARC-order time. This bug is to add a fallback in Koha::EDI's invoice processing: when RFF+LI does not resolve to an aqorders row, attempt to match the invoice line to an order via RFF+SLI (orderline_reference_number) against aqorders.suppliers_reference_number. Depends on bug 43534. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43534 [Bug 43534] Allow MarcFieldsToOrder to map a MARC field to supplier's reference number/qualifier -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6