https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43822 Bug ID: 43822 Summary: EDI invoice receipt reassigns already-received order lines when RFF+LI points at a complete order Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major 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::process_invoice matches each invoice line to an order using the RFF+LI ordernumber only. It never compares the line's EAN/ISBN with the order's biblio. If the RFF+LI ordernumber belongs to an order that is already 'complete' and already attached to a different invoice, Koha adds an edifact_errors warning ("already marked as complete ... The ordernumber in this invoice may be incorrect") and then carries on regardless. The simple-receipt branch overwrites these columns on the existing aqorders row: - invoiceid - datereceived - quantityreceived - unitprice, unitprice_tax_excluded, unitprice_tax_included - tax_rate_on_receiving, tax_value_on_receiving Effects: - The original invoice, which may already be closed and paid, silently loses lines. Its Koha total no longer matches what the supplier billed. - The new invoice holds lines for goods it does not cover, at the new message's prices. - The line's real receipt history is lost. The edifact_errors warning is the only trace. Real-world trigger: a supplier sent a first INVOIC with the correct EANs but stale RFF+LI values pointing at 39 lines of an older, already received and invoiced basket, plus different prices. It then sent a corrected INVOIC with the same invoice number. Koha moved the 39 old lines onto the first invoice, which was then closed and paid. The older closed invoice was left 39 lines short. The supplier data was wrong, but Koha turned a bad message into silent corruption of already-received, already-invoiced lines. EdifactInvoiceImportBlockDuplicates does not help here. It blocks on invoice number, so it would block the supplier's corrected resend rather than the bad message. Test plan (to reproduce): 1. Create a vendor with an EDI account. Order line A (EAN X) and line B (EAN Y) on two baskets. 2. Import INVOIC 1 receiving A (RFF+LI:<A ordernumber>, EAN X). Close that invoice. 3. Import INVOIC 2 (different invoice number) containing EAN Y and different prices, but with RFF+LI:<A ordernumber>. 4. Look at aqorders for A: invoiceid is now INVOIC 2's invoice, and datereceived and unit prices are INVOIC 2's. INVOIC 1's invoice has lost the line. B is still not received. 5. The only trace is an edifact_errors warning on INVOIC 2's message. Expected: a line that is already complete and attached to another invoice is not overwritten. It is skipped and an error is recorded in edifact_errors. Suggested fix: - In process_invoice, when orderstatus is 'complete' and invoiceid is set and differs from the invoice being created, skip the line and record an error instead of only warning. - Optionally cross-check the invoice line's EAN/ISBN against the order's biblio and skip/warn on mismatch. Related: Bug 43756 (EDI invoice processing receives lines for cancelled orders and re-opens them), Bug 43755, Bug 43754. The "already marked as complete" warning was added under Bug 41996. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.