Hi, I wondered if anyone has had success using standard E1 eInvoicing with XML output? After following all the setup in the doc linked above by John we don't get any output when running R42565. It seems highly messy with all the versions, UDC's etc.
Seems a lot of people go for custom solutions so I wondered...
Thanks,
Mark
Hi Mark, thank you for sharing your thought which is similar to mine.
In Italy we have mandatory B2B einvoice since year 2019, thus quite a bit of experience, and I'm not aware about customers happyly live with standard module without customisations.
There are several reasons not easy to be summarized in few sentences, but I'm tring to list some of them here below:
* difficulties in compliance with country specific VAT rules (for example "split payment" when invoicing B2G or listed companies).
* Difficulties in handling rounding for VAT and taxable amount (see for example price UOM different from sales UOM at SO level).
* XML invoice file coming from BIP tranformation while I would prefer BSFN approach (see for example standard R744002 for SEPA payment XML).
* XML invoice file coming from R42565, while it's not wise to send to Tax Authority a document not yet posted in GL, thus potentially subject to changes. Moreover R42565 is calculating VAT, but it's not storing it into the database (posting does that using F0018 table) and the same for due dates / payment installments, increasing the risk to have discrepancies between what you are declaring in your official XML and what you get in your accounting evidences.
* Needs to install several ESUs related to different countries even if you are not interested in them because the core module is the same for several EU countries, thus in few words you know when you start and you don't know when you will finish installing ESUs.
* It appears in recent years the way how Oracle-JDE is developing localization did change radically. For example: in the past you had specific localizations including BSFNs and specific TBLE for each country. Now you can see generic F70xxxxx tables with the same field assuming different meaning depending on the localization country from your JDE UserId, and this is not appearing an improvement in my humble opinion.
Kind regards,
Carlo
.
