erconsult: Electronic reporting: Italian eInvoicing FatturaPA, CIG and CUP numbers, RIBA

[Blog bot]

Источник: 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.'