https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43754 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia@bugs.koha-communit |kyle@bywatersolutions.com |y.org | Status|NEW |CONFIRMED Assignee|koha-bugs@lists.koha-commun |martin.renvoize@openfifth.c |ity.org |o.uk -- 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=43754 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=43754 --- Comment #1 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 208624 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=208624&action=edit Bug 43754: Set item acquisition fields when receiving through an EDI invoice When an EDIFACT invoice is processed, Koha::EDI::receipt_items only assigned a barcode (from GIR LAC) and applied AcqItemSetSubfieldsWhenReceived. A manual receive, in acqui/finishreceive.pl, also sets these fields on every item of the received order: booksellerid, dateaccessioned, datelastseen, price, replacementprice, replacementpricedate so an item received through an invoice ended up with different data to the same item received by hand: no source of acquisition, an accession date that was still the order date, and no price or replacement price. receipt_items now sets the same fields on each item it receives, taking each from the invoice where the EDItEUR Library EDI guidelines give it, and from Koha only where the invoice does not: - booksellerid: the supplier of the invoice, falling back to the vendor of the basket - dateaccessioned, datelastseen and replacementpricedate: the message date (DTM+137), which process_invoice sets as the received date; it is the only date the INVOIC message gives - price: the unit price process_invoice works out from the line amounts (MOA 203 and 128) and sets on the order - replacementprice: the copy value of the copy (GIR LCV, "the replacement cost of an individual copy, which may not be the same as the price paid"), falling back to the replacement price of the order. The copy value was already read by the parser but never used. A value that is missing is not written, so an item keeps the data it already has rather than losing it. Only the items that are received are updated: on a part receipt the items left on the original order are not touched. Test plan: 1. Apply the patch 2. prove t/db_dependent/Koha/EDI.t => the subtest 'process_invoice sets item acquisition fields like a manual receive' passes 3. 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, with a replacement price on the order. 4. Import an EDIFACT invoice for that order (RFF+LI with the order number, QTY+47:2, MOA+203) with no GIR copy values and process it => each item has the vendor as booksellerid, dateaccessioned and datelastseen set to the invoice date, price set to the invoiced unit price, and replacementprice and replacementpricedate set from the order as in a manual receive 5. Repeat with a GIR+001+<branch>:LLO+15.50:LCV segment for each copy => each item's replacementprice is the copy value from the invoice 6. Repeat with an order for 3 copies and an invoice for 1 => only the received item is updated 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=43754 --- Comment #2 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Open question on tax: which unit price should go on the items? A manual receive follows the vendor's "invoice prices include tax" setting (aqbooksellers.invoiceincgst). When it is set, the order's unitprice is the tax-included figure, otherwise the tax-excluded one (Koha::Acquisition::Order::populate_with_prices_for_receiving, acqui/parcel.pl), and acqui/finishreceive.pl copies that unitprice to items.price. process_invoice does not follow it. It always sets unitprice and unitprice_tax_included to the line total including tax (MOA+128 divided by the quantity), and unitprice_tax_excluded to the amount excluding tax (MOA+203 divided by the quantity), whatever the vendor setting is. The patch here copies the order's unitprice to items.price, so for a vendor whose invoice prices exclude tax an EDI receipt records a different price on the item, and a different unitprice on the order, from the same receipt done by hand. Proposal: follow Koha's existing settings (the vendor's invoiceincgst, and the system preferences that govern how acquisitions prices and fund values are handled) for what is stored, and add a vendor-level setting for the tax handling the supplier's message uses. We would then convert from what the message says to what Koha expects, rather than assuming one basis. The EDItEUR INVOIC gives both amounts (MOA+203 excluding tax, MOA+128 including it), so for a conforming supplier the conversion is only a choice of which one to use. The setting is needed for suppliers whose MOA codes do not follow that meaning. Whether this is done in this bug or a follow-up is open, as it changes the unitprice on the order as well as on the item. -- You are receiving this mail because: You are watching all bug changes.