[Bug 43755] New: EDI invoices without GIR segments leave items unmatched and part receipts without items
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@lists.koha-community.org Reporter: martin.renvoize@openfifth.co.uk QA Contact: testopia@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.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43755 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CONFIRMED QA Contact|testopia@bugs.koha-communit |kyle@bywatersolutions.com |y.org | Assignee|koha-bugs@lists.koha-commun |martin.renvoize@openfifth.c |ity.org |o.uk -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43755 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |42890 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42890 [Bug 42890] EDI INVOIC processing should create/link items in aqorders_items when AcqCreateItem=receiving -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43755 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |41852 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41852 [Bug 41852] Modernize EDI support in Koha -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43755 --- Comment #1 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 208622 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=208622&action=edit Bug 43755: Match EDI invoice lines with no GIR to the items on the order Koha::EDI::receipt_items and transfer_items find the items that belong to an invoice line by the branch given in its GIR segments (LLO). GIR is conditional on an invoice line in the EDItEUR Library EDI Implementation Guidelines (INVOIC segment 39A, which is not part of the regular EANCOM subset), and the worked example in those guidelines has none, so an invoice with no GIR segments is valid. Such a line has no branch, so nothing matched: - on a full receipt the order was completed but an edifact_errors row was written for every copy, the items were not touched (so AcqItemSetSubfieldsWhenReceived was not applied), and Perl warned about an uninitialized $branch - on a part receipt transfer_items moved no items, so the new completed order had none and all the items stayed on the original order A copy that has no branch, because the line has no GIR or fewer GIRs than the quantity invoiced, now takes the first item linked to the order that is not already taken, in itemnumber order. Copies with a branch are matched first, as before, so an invoice with matching GIR segments behaves as it did. transfer_items and receipt_items use the same order, so the items moved to the completed order are the ones that are received. Test plan: 1. Apply the patch 2. prove t/db_dependent/Koha/EDI.t => the subtest 'process_invoice without GIR segments' passes 3. 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. 4. Process an INVOIC for that order with QTY+47:1 and no GIR segments => the first item is moved to the completed order and received, the other 2 stay on the original order, and there are no errors 5. Repeat with QTY+47:3 and no GIR segments => all 3 items are received with no errors 6. Repeat with a matching GIR+LLO segment => behaviour is unchanged: the item at that branch is used Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43755 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |Needs Signoff --- Comment #2 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Spec check on the premise of this bug, that GIR segments are optional on an invoice line. EDItEUR Library EDI Implementation Guidelines v1.2, INVOIC (L8, segment 39A in the line item group): GIR has status C (conditional) and can repeat up to 1000 times. The text says it can be used for copy- or part-order-related detail, and that it is not part of the regular EANCOM subset. The worked example of a book invoice (L.8.7) has two invoice lines and no GIR. The UK Library Invoice Message document gives the same segment definition. Civica's Spydus EDI requirements for vendors (2021) list the key elements of an invoice line as LIN, RFF+LI, QTY+47 and the price. GIR is "if used". So an invoice line without GIR is valid. The fallback proposed here (take the first items linked to the order, in itemnumber order) covers a spec-conformant invoice, not only a non-conforming supplier. I have not established how common this is. I do not have a supplier spec or sample file showing a GIR-less INVOIC. Baker & Taylor and Ingram, which the ByWater plugin has vendor modules for, would be the ones to check. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43755 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |43754 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43754 [Bug 43754] EDI invoice receipt does not update item acquisition fields like manual receive does -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43755 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks|41852 | Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41852 [Bug 41852] Modernize EDI support in Koha -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43755 Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |emily.lamancusa@montgomeryc | |ountymd.gov --- Comment #3 from Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> --- We do receive GIR-less invoices from Ingram, so I have examples I can use to test this. I can't figure out or find instructions on how to process a test invoice in KTD, though. Can you provide more details on how to perform step 4 of the test plan, or point me in the right direction? -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org