https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43510 Bug ID: 43510 Summary: EDI invoicing miscalculates tax_value_on_receiving for mixed-rate order lines 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: --- When Koha imports an EDIFACT INVOIC message, it computes tax_value_on_receiving as: quantity * price_excl_tax * tax_rate_on_receiving using only the rate parsed from the *first* TAX segment on the LIN (Koha::Edifact::Line::tax_rate returns on the first match). It never reads the vendor's actual invoiced tax amount, which EDIFACT carries in one or more MOA+124 segments per LIN. This is wrong whenever a vendor invoice line is genuinely mixed-rate - part of the line's value standard-rated, part zero-rated (for example a book bundled with a non-book component). EDIFACT represents this as more than one TAX/MOA segment pair on the same LIN, one pair per rate. Koha only reads the first pair's rate and applies it to the entire line value, hugely overstating the tax on the zero-rated portion. Concrete real-world example (production data, order numbers changed): LIN block for a mixed-rate item, quantity 6, price_excl_tax total 56.46: TAX+7+VAT+++:::20+S MOA+124:2.95 (20% portion, taxable base 14.74) TAX+7+VAT+++:::0+Z MOA+124:0 (0% portion, taxable base 38.00) Vendor's actual invoiced tax for this line: 2.95. Koha's computed tax_value_on_receiving: 6 * (56.46/6) * 0.20 = 11.29. Koha::Edifact::Line already parses the taxable amount and rate per TAX segment (tax_rate, moa_amt('124')), and even has a helper that sums every MOA+124 occurrence on a line (amt_taxoncharge), but nothing in Koha::EDI's invoice receipt code uses it - the flat rate x price recompute in the tax_value_on_receiving assignments is unconditional. We looked at fixing this directly in Koha::EDI but believe it needs the wider acquisitions costing rework rather than a point patch here: aqorders.tax_rate_on_receiving is a single scalar column that cannot represent a split rate, and C4::Acquisition::ModReceiveOrder recomputes tax_value_on_receiving from that single rate on every subsequent receive/edit of the order line. So a fix confined to the EDI ingest path alone would be silently reverted the next time the line is touched through the normal receiving UI. Filing this for visibility so it can be considered as part of that larger effort. Impact: any library receiving EDI invoices from vendors who send genuinely mixed-rate order lines will have Koha significantly overstate the tax recorded against those lines, which then propagates into any local financial reporting or exports built on tax_value_on_receiving. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.