Источник:
http://erconsult.eu/blog/electronic-...-numbers-riba/
==============
Introduction
The use of eInvoices in public procurement in Italy is mandatory for ministries, tax agencies and national security agencies since June 2014. Since 31 March 2015, it is mandatory for all public entities. We also see private companies embarking this platform. Every supplier must comply and provide invoices in the “FatturaPA” format which is perfectly described in English (!)
here.
In Dynamics 365 for Finance and Operations, the [public] client must have the parameter
eInvoice set to
Yes to activate electronic invoicing. If the
eInvoice attachment has been activated as well, D365FO even embeds a copy of the invoice into the XML stream (as a PDF encoded by Base64 algorithm and stored in a CDATA block).
The eInvoices are driven by the
Electronic Reporting. As I am writing this, the most recent version if the format “
Sales invoice (IT)“, based on the “
Customer invoice model” and mapping v 29 from the 15th of January 2019.
In essence, you download the above 2 configurations, deploy them at
Organization administration > Electronic reporting > Configurations, put an anchor on the
Electronic documents tab at
Accounts receivable > Setup > Accounts receivable parameters. With this setup on hand, you post your sales or project invoice and it creates a record in the
Accounts receivable > Invoices > E-Invoices > Electronic invoices list. These records are then processed manually or in a batch and the ER generates and drops XML files.
The problem is, the output is full of bugs.
DatiOrdineAcquisto, CodiceCIP, CodiceCUP, RiferimentoNumeroLinea
To crack down on mafia, the government issues CUP and CIG codes to identify contracts or assignments with public investments. They are tracked end-to-end from the invoice down to the payment (e.g. RIBA bills of exchange, see below). In Dynamics 365, these numbers need to be entered into the
Base document part in the sales order header. As you post the sales invoice, it creates a persisting copy of the
BaseDocument_IT record and attaches it to the invoice record
CustInvoiceJour. The ER picks it up and the Base document type triggers one of the 5 sections , , and so on. So much for theory.
The code in
\Data Dictionary\Tables\BaseDocument_IT\Methods\updateRefRecords is wrong in so many ways. It is going to fail creating a record for 2 invoices for the same order, 2 orders for the same public tender. The ER cannot find the record
BaseDocument_IT, and the section is then missing in the output.
To mitigate this, you must create a mapping derived from
Customer invoice model, declare it
Default for model mapping and put a fallback into the
InvoiceBase/BaseDocument_IT node:
IF(NOT(ISEMPTY(CustInvoiceJour.'