There is a bug in the inbound IFS_FINVOICE_TO_IFS_EINVOICE transformer that reads the IFS FInvoice format for processing of E-Invoices.

The first thing IFS needs to do when receiving an E-Invoice is to identify which Company it is meant for.

First it will try to use BuyerPartyDetails/BuyerPartyIdentifier to match against Company association no.

Second it will try to use the BuyerOrganisationUnitNumber to match against “Company’s Own Address ID” (EAN Location).

Thirdly it will try to match the VAT No. Unfortunately instead of fetching the VAT No from BuyerPartyDetails/BuyerOrganisationTaxCode (just next to the BuyerPartyDetails/BuyerPartyIdentifier) IFS fetches the value DeliveryPartyDetails/DeliveryOrganisationTaxCode. Now, the DeliveryParty is an optional tag that can describe where the supplier shipped the goods. Unfortunately it doesn’t make much sense to fetch the VAT No from there, both because it is optional, but also because it might not be our Company. If you have made a Purchase Order and requested a Direct Delivery directly to your customer then that customer would end up in the DeliveryParty segment. While it is of interest on an invoice to see where the goods was shipped to, it doesn’t really help us who should be paying for the invoice.

We reported this bug to IFS (CS0178635) but because we are the first to find and identify this issue apparently it is not a bug. Instead it was suggested that we list this as an “idea” and if enough of the community thinks that IFS should fix bugs R&D might consider it for future development.

We are likely to fix the transformer ourselves, but of course this will also mean that for every Update or patch we get from IFS we will have to take care to not overwrite the transformer and reintroduce the bug.