erconsult: Italian eInvoicing FatturaPA: Part 2
You thought this was over? Not at all, the implementation of the FatturaPA format in D365FO harbors many more pearls : )
The “Bollo” or the Import duty seems to be a self-assessed Italian charge on certain deliveries. The user should be able to apply the stamp duties to some of the outbound invoices at will. The total stamp duty load is calculated by the Italian authorities periodically by harvesting the electronic invoices. In case the stamp duty is applicable, the tag should say “si” and should give the [positive] amount: 2.00.
The standard D365FO electronic format assumes the stamp duty is represented by a miscellaneous charge to the sales order. These charges trigger the XML element; otherwise the miscellaneous charge is exported as a regular invoice line.
The respective charge code can be configured with a transit debit and a transit credit account and added to any sales line manually or automatically as a auto-charge:
The system relies on a Spanish parameter Stamp duty to identify the dedicated miscellaneous charges code representing this duty. Unfortunately, this Spanish parameter is unavailable in Italy by definition, check the button Electronic document properties in the legal entities form:
Moreover, in the mapping between the database and the format the charges code was missing, and the duty only took sales order header level charges into accounts. A custom mapping needs to be derived from the Customer invoice model – Model mapping Customer invoice to fix this. This mapping must be declared Default for model mapping = Yes.
In the format the parametrized query $StampDutyCharges can be extended by a hardcoded check if the charge code begins with “Bollo”, then both the header-level and line-level charges can be merged into a single list:
The RiferimentoNormativo delivers the legal justification for tax exempt invoices and refers to the Italian tax codex, e.g. Escluso IVA art. 15. This tag was completely missing in the standard format. The tax code description is a good place to store the justification, the Customer invoice model has a node to store this data, but in the standard mapping the tax code description was not bound to the model. The derived mapping needs to be adjusted at the node <strong>CustInvoiceJour/
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.
|erconsult: Electronic reporting: Italian eInvoicing FatturaPA, CIG and CUP numbers, RIBA||Blog bot||DAX Blogs||0||10.04.2019 12:11|
|erconsult: Configuring Austrian and Norwegian per diems in Dynamics 365||Blog bot||DAX Blogs||0||03.05.2018 04:28|
|emeadaxsupport: AX Performance Troubleshooting Checklist Part 2||Blog bot||DAX Blogs||0||09.09.2014 16:11|
|Microsoft Dynamics CRM Team Blog: List Web Part for Microsoft Dynamics CRM 4.0 Deployment Scenarios||Blog bot||Dynamics CRM: Blogs||0||30.01.2009 22:05|
|Microsoft Dynamics CRM Team Blog: List Web Part for Microsoft Dynamics CRM 4.0: Understanding Connections||Blog bot||Dynamics CRM: Blogs||0||20.01.2009 02:07|
|Опции темы||Поиск в этой теме|