Skip to main content

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.

Hi ​@jaw 

 

We faced the same problem and a workaround we are trying is to create a XSL transformer which will read the value of the BuyerPartyDetails/BuyerOrganisationTaxCode from the incoming XML and add as tag DeliveryPartyDetails/DeliveryOrganisationTaxCode. 

 

This transformer can be placed before the IFS_FINVOICE_TO_IFS_EINVOICE in the routing address so that IFS would get the xml tag it’s looking for.

 

Hope this would help someone who’s looking for a way around this problem!

 

Cheers!

Damith

Hi ​@dsj ,

We ended up patching the IFS_FINVOICE_TO_IFS_EINVOICE transformer directly. I like the idea of adding another transformer in front, but I suspect that it may not be trivial to copy every possible in the XML only to modify one of them.

This is what we added:

			<xsl:choose>
				<xsl:when test="string(BuyerPartyDetails/BuyerOrganisationTaxCode) != ''">
				    <C17>
						<xsl:value-of select="BuyerPartyDetails/BuyerOrganisationTaxCode"/>
				    </C17>
				</xsl:when>
				<xsl:when test="string(InvoiceRecipientPartyDetails/InvoiceRecipientOrganisationTaxCode) != ''">
				    <C17>
						<xsl:value-of select="InvoiceRecipientPartyDetails/InvoiceRecipientOrganisationTaxCode"/>
				    </C17>
				</xsl:when>
			</xsl:choose>

We added it just after:

			<xsl:for-each select="BuyerPartyDetails">
				<xsl:for-each select="BuyerPartyIdentifier">
					<C50>
						<xsl:value-of select="."/>
					</C50>
				</xsl:for-each>
			</xsl:for-each>

The old section we just commented out:

				<xsl:for-each select="DeliveryOrganisationTaxCode">
					<C17>
						<xsl:value-of select="."/>
					</C17>
				</xsl:for-each>

 

As you can see we completely dropped the DeliveryOrganisationTaxCode, since it in our opinion is completely wrong. It could be added as a third step in the new code.

 

Good luck!

Alexander

Reply


Terms & ConditionsCookie settings