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

[Bug 43874] New: EDIFACT GIR part-order sets (Lnn with LQT) are not expanded into copies
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43874 Bug ID: 43874 Summary: EDIFACT GIR part-order sets (Lnn with LQT) are not expanded into copies 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 Target Milestone: --- Koha treats every GIR segment as one copy. The EDItEUR Library EDI Implementation Guidelines (v1.2: quotes, orders, order responses and invoices) also define a part-order set, which is one GIR standing for several copies of an order line that share the same branch, fund, shelfmark and servicing. In a GIR segment the first element (DE 7297, set identification qualifier) is either a copy sequence number 001 to 999, or a part-order sequence number L01 to L99. For a part-order set the number of copies is given by the LQT code (part-order quantity, an integer in DE 7402), which the guidelines require with an Lnn set and do not use with a copy number. For example: GIR+L01+3:LQT+BR1:LLO+FIC:LSQ' means 3 copies to branch BR1 in the FIC sequence, in place of GIR+001, GIR+002 and GIR+003. LAC may repeat to list the barcodes of the set, or LAF and LAL may give a sequential range. It is a compact form for a large order spread over a few branches. Current behaviour: - Koha::Edifact::Line::extract_gir reads LQT into part_order_quantity, but nothing uses it. Each GIR is one entry, and segments with the same set number are merged. - Quotes: when there is more than one GIR the count must equal the quantity, otherwise an error "Order for N items, M segments present" is recorded. Koha::EDI has a comment, in the quote processing, that 1:1 GIR and 1:n GIR (with LQT values) should both be handled there. - Invoices: receipt_items and transfer_items take the branch from the GIR of each copy. With one GIR for N copies, only the first copy is matched by its branch, and the others have no branch. After bug 43755 they are taken from the remaining items on the order without any branch matching, so nothing fails but they may be taken from the wrong branch. Some suppliers do not follow the guidelines exactly. For example the Civica Spydus requirements for vendors put LQT on a numbered set (GIR+001+2:LQT+ABB:LLO...). Support should accept LQT whatever the set number is. Proposed change: expand part-order sets in the parser, Koha::Edifact::Line, into one entry per copy, so that quotes and invoices both see one GIR per copy and need no changes of their own: a. A GIR with LQT = n becomes n entries with the same field values. b. A list of LAC values is spread over the copies in order, and an LAF to LAL range is expanded into one barcode per copy. c. The mismatch error for quotes is kept for a count that still does not match after expansion, and the comment about LQT in the quote processing is removed. Optionally, as a follow-up, Koha::Edifact::Order could send part-order sets for a line whose copies share all their GIR data. Related to bug 43755 (invoice lines with no GIR), which also changes how items are matched on an invoice line. Test plan: 1. Process a QUOTE whose line has QTY+21:3 and a single GIR+L01+3:LQT+BR1:LLO+FIC:LSQ. 2. Without the patch: the line is not treated as 3 copies at BR1. 3. With the patch: the order line is for 3 copies, with 3 items at BR1 in the FIC sequence. 4. Process an INVOIC for an order of 4 copies, 3 of them at BR1, with QTY+47:3 and GIR+L01+3:LQT+BR1:LLO. 5. Without the patch: only the first copy is matched by branch. 6. With the patch: the 3 items at BR1 are the ones received. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 43876] New: CancelReceipt deletes items with raw SQL: no deleteditems copy, no reindex, no logging
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43876 Bug ID: 43876 Summary: CancelReceipt deletes items with raw SQL: no deleteditems copy, no reindex, no logging 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: adolfo.rodriguez(a)xercode.es QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- When a basket creates items on receiving (effective_create_items eq 'receiving'), cancelling a receipt (C4::Acquisition::CancelReceipt) deletes those items with a raw SQL DELETE in _cancel_items_receipt: DELETE FROM items, aqorders_items USING items, aqorders_items WHERE items.itemnumber = ? AND aqorders_items.itemnumber = ? Because Koha::Item->delete is bypassed: - no copy of the item is kept in deleteditems - the bibliographic record is not reindexed, so the deleted items are still shown in the search results (Elasticsearch and Zebra) - nothing is written to the cataloguing log - the after_item_action plugin hook (action 'delete') is not called - the real-time holds queue is not updated - an item group left empty is not deleted To reproduce: 1. Create a basket with "Create items when: receiving an order". 2. Add an order with quantity 2, close the basket and receive it. Two items are created and shown in the catalog search results. 3. Cancel the receipt. 4. The items are gone from the items table, but they are not in deleteditems, there is no DELETE entry in the cataloguing log, and the record still shows the items in the search results. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 14806] Action Log for Modifying borrower messaging preferences
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14806 Pedro Amorim (ammopt) <pedro.amorim(a)openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pedro.amorim(a)openfifth.co.u | |k Status|Passed QA |Failed QA --- Comment #37 from Pedro Amorim (ammopt) <pedro.amorim(a)openfifth.co.uk> --- Hi all, the logging itself works well. One thing to fix first: The new logging test passes even when nothing is logged 1) Open t/Members_Messaging.t and add this as a new line right after line 317 (subtest 'SetMessagingPreference logs undef for removed digest and days values'): require t::lib::Mocks; t::lib::Mocks::mock_preference('BorrowersLog', 0); 2) Run: prove -v t/Members_Messaging.t 3) Notice both "is logged as undef" checks still pass, although logging is switched off and nothing was logged. When nothing is logged, $calls[-1] is undef, so both checks compare undef with undef. Please mock 'BorrowersLog' to 1 and check that the expected entries were actually logged (e.g. the number of calls), so the test fails if logging breaks. Also, has_digest and takes_days (added to GetMessagingPreferences and returned by GetPatronMessagingPreferences) aren't mentioned in the commit message and don't appear to be used or needed. Can we please confirm? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 41852] New: Modernize EDI support in Koha
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41852 Bug ID: 41852 Summary: Modernize EDI support in Koha Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified 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 A collector bug for all the modernization and maintenance work we've been undertaking in EDIfact support for Koha -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 43755] New: EDI invoices without GIR segments leave items unmatched and part receipts without items
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43755 Bug ID: 43755 Summary: EDI invoices without GIR segments leave items unmatched and part receipts without items 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::receipt_items and Koha::EDI::transfer_items locate the items that belong to an invoice line using the branch given in the GIR segments (GIR ... :LLO). If the invoice line has no GIR segments, the branch is undefined and no item can be matched. Many suppliers send no GIR on invoices (the segment is conditional on the invoice message). Koha then records errors and leaves the items untouched: Reproduced on main (vendor EDI account without plugin, basket with create_items=ordering, items linked in aqorders_items, no GIR on the invoice line): 1. Full receipt, order for 2, invoice for 2, no GIR: - order is marked complete, but 2 edifact_errors are written: "No matching item found for invoice line 1:0 at branch (order N has items at: , XXX)..." (the branch in the message is empty) - the items are not touched (so anything done at receipt, such as AcqItemSetSubfieldsWhenReceived, is not applied) - Perl warnings: Use of uninitialized value $branch in hash element at Koha/EDI.pm line 591 (and others) 2. Part receipt, order for 3, invoice for 1, no GIR: - the original order drops to quantity 2 (partial) and a new complete order is created for 1 copy - transfer_items moves nothing, because no item homebranch matches an undefined branch: all 3 items stay linked to the original order and the new completed order has no items - receipt_items then logs "No matching item found ... (order M has items at: none)" The same invoice with matching GIR segments works as expected (1 item is moved to the new order). Proposed fix: when the invoice line has no GIR (or a GIR occurrence has no LLO), fall back to the items already linked to the order, in itemnumber order, taking as many as the invoiced quantity. Transfer those to the new order on a part receipt, then receive them. Test plan: 1. Create a vendor with an EDI account (no plugin) and a basket with AcqCreateItem=ordering. Order 3 copies of a record, so 3 items are linked to the order. 2. Process an INVOIC for that order with QTY+47:1 and no GIR segments. 3. Without the patch: the new completed order (1 copy) has no linked items, the 3 items stay on the original order, and edifact_errors contains "No matching item found". 4. With the patch: 1 item is moved to the completed order and received, 2 stay on the original order, and there are no errors. 5. Repeat with QTY+47:3 (full receipt) and confirm the 3 items are received without errors. 6. Repeat with matching GIR+LLO segments and confirm behaviour is unchanged. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 43804] New: Add after_edifact_action plugin hook for processed EDIFACT messages
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43804 Bug ID: 43804 Summary: Add after_edifact_action plugin hook for processed EDIFACT messages 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 Target Milestone: --- Koha has plugin hooks around bibliographic, item, hold, circulation and account actions, but nothing that lets a plugin react once an EDIFACT message has been processed. Plugins can currently only take over invoice processing (edifact_process_invoice) or alter order sending (edifact_order). Plugins that need to act after a QUOTE, INVOICE or ORDRSP has been processed have to poll edifact_messages for new or recently changed rows. That is racy against the next edi_cron.pl run, and it does not work for invoices processed manually from the staff interface. Typical uses: finance reconciliation, exporting to external systems, alerting, extracting data Koha does not handle itself (e.g. invoice service charges), and post-processing records created from a quote. This patch adds after_edifact_action, following the existing after_*_action pattern (after_biblio_action, after_item_action, ...): after_edifact_action( { action => 'process', payload => { message => $row, message_id => $id, message_type => 'QUOTE' | 'INVOICE' | 'ORDRSP', }, } ) It is called from process_quote, process_invoice and process_ordrsp in Koha::EDI once processing has finished, so it fires for both edi_cron.pl and manual processing. For quotes it fires after any auto-orders are created. For invoices it also fires when a vendor plugin processes the invoice itself via edifact_process_invoice. Test plan: 1. Apply the patch 2. prove t/db_dependent/Koha/Plugins/Edifact_hooks.t => Tests pass 3. Revert the Koha/EDI.pm change and run the test again => It fails 4. prove t/db_dependent/Koha/EDI.t => Tests pass -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 41087] New: EDI Retry: We should add the option to retry EDI processing for errors
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41087 Bug ID: 41087 Summary: EDI Retry: We should add the option to retry EDI processing for errors 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: 39215, 39291 Blocks: 3728 Now that we're catching and reporting EDI processing errors more, we should add the option to retry and revert a message Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3728 [Bug 3728] select mandatory fields broken https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39215 [Bug 39215] EDIFACT quote files should skip orders that cannot be processed rather than failing to complete https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39291 [Bug 39291] Edifact should record an error and move on if there's a problem with transport filename change -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 43875] New: Do not auto-close invoices that have EDIFACT processing errors
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43875 Bug ID: 43875 Summary: Do not auto-close invoices that have EDIFACT processing errors 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 Depends on: 40932 Target Milestone: --- Bug 40932 adds three ways of closing an invoice automatically, and all of them call Koha::Acquisition::Invoice::check_and_close: circulation check-in when AutoCloseInvoicesOnCheckin is set, the "close completed invoices" background job, and the "check and close" action on the invoice page. check_and_close closes an invoice when every item on its non-cancelled orders has been received. It only looks at the orders that are linked to the invoice. An invoice line that EDI processing could not receive is not linked to it, so check_and_close cannot see it. For example, since bug 43756 an invoice line that refers to a cancelled order is skipped and an error is recorded in edifact_errors; the same happens for a line with no order number, an unknown order, or an order whose record has been deleted. The supplier has invoiced for those lines, so the invoice total in Koha is less than the supplier's and part of the invoice has not been dealt with. Once the other items are checked in, the invoice is closed automatically. Closing an invoice is often what triggers a finance integration to pay it, so an invoice that includes a line for something cancelled and never received could be paid in full, or the shortfall could go unnoticed. Proposed change: check_and_close does not close an invoice that has EDIFACT processing errors, and returns 0 as it does for an invoice that is not ready. The errors that count are those for the invoice (the same invoice number in the message) and the message-level ones that affect the whole file, as shown on the invoice page under "Processing errors". Staff can still close the invoice by hand once they have checked it with the supplier. A method on the invoice returns those errors, and the invoice page uses it instead of repeating the query. This is deliberately cautious: any recorded error, including a warning such as an invoice line for an order that is already complete, keeps an invoice from closing automatically. A flag that only covers the lines that were skipped would be more precise, but needs a change to the database. Related to bug 43756. Test plan: 1. Set AutoCloseInvoicesOnCheckin. Receive an EDIFACT invoice for two orders with items, where one line refers to an order that has been cancelled 2. Check in all the items of the order that was received 3. Without the patch: the invoice is closed 4. With the patch: the invoice stays open and the invoice page shows the processing error 5. Check and close the invoice from the invoice page, or run the close completed invoices job => the invoice is still open 6. Close the invoice by hand => it closes Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40932 [Bug 40932] Automated trigger for invoice closure -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 43868] New: Log viewer search does not find circulation entries by item barcode
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43868 Bug ID: 43868 Summary: Log viewer search does not find circulation entries by item barcode Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: slavashishkin(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 29016 Target Milestone: --- Searching the log entries table by item barcode returns no matches, even when the barcode is visible in the Info column of a circulation entry. Reproduced on current community main, with bugs 29016 and 43119 already applied. To reproduce: 1. Open a patron's modification log containing a checkout or check-in entry with a visible item barcode. 2. Copy the barcode into the table's Search box. 3. Observe that no matching records are found. 4. Search by the item's internal itemnumber. 5. Observe that the entry is found. Expected: Searching by the displayed item barcode finds the matching circulation entries. Actual: Searching by barcode returns no matches, while searching by itemnumber finds the entries. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29016 [Bug 29016] Improve performance of the Log viewer when working with a high volume of action logs -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

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

22 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 5