Get a cost center in D365FO

It is shocking to see over and over again functional consultants failing to create the Cost center dimension backed by the Organization units table (Organisation administration > Organisations > Operating units), choosing a custom dimension type instead and loosing the ability to specify an address, make a hierarchy of cost centers, specify a cost center manager etc.

This has also given a rise to excruciatingly dumb custom code snippets predating the dimension name CostCenter as if there were no British English or other languages.

With the proper setup and the proper coding this reduces to 3 essential lines:

				
					static void main(Args _args)
{
    // Copy of the private method OMOperatingUnit::getDimensionViewId()
    RefTableId getDimensionViewId(OMOperatingUnitType _omOperatingUnitType)
    {
        Dictionary dict = new Dictionary();
        DictEnum dictEnum = new DictEnum(enumNum(OMOperatingUnitType));
        return dict.tableName2Id(strFmt('DimAttribute%1', dictEnum.index2Symbol(_omOperatingUnitType)));
    }
    DefaultDimensionView defaultDimensionView;
    RefRecId testDefaultDimensionRecId =
    (select firstonly DefaultDimension from ProdTable where ProdTable.ProdId == "P000173").DefaultDimension;
    
    // Filter by the virtual backing entity table Id for cost centers
    select defaultDimensionView
        where defaultDimensionView.BackingEntityType == getDimensionViewId(OMOperatingUnitType::OMCostCenter)
           && defaultDimensionView.DefaultDimension == testDefaultDimensionRecId;
    
    info(defaultDimensionView.DisplayValue);
}

X++ programming blog series

Italian eInvoicing FatturaPA: Part 2

You thought this was over? Not at all, the implementation of the FatturaPA format in D365FO harbors many pearls : )

DatiBollo, ImportoBollo

The “Bollo” or the Import duty seems to be a self-assessed Italian charge on certain deliveries. The user should be able to apply stamp duties to a subset of outbound invoices at will. The total stamp duty load is deducted 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 the 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:
IF(ISEMPTY('Stamp duty'), LISTJOIN(WHERE(@.InvoiceBase.MarkupTransaction, LEFT(@.InvoiceBase.MarkupTransaction.Code,5)="Bollo"), WHERE(@.LineItem.MarkupTransaction, LEFT(@.LineItem.MarkupTransaction.Code,5)="Bollo")), WHERE(@.InvoiceBase.MarkupTransaction, @.InvoiceBase.MarkupTransaction.Code='Stamp duty'.Value))

RiferimentoNormativo

The RiferimentoNormativo delivers the legal justification for tax exempt invoices and refers to the Italian tax codex, e.g. <RiferimentoNormativo. 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 CustInvoiceJour/<Relations/TaxTrans :
@.'>Relations'.TaxTable.TaxName

A new conditional XML element shall be added to the format configuration:
XMLHeader/p:FatturaElettronica/FatturaElettronicaBody/DatiBeniServizi/DatiRiepilogo/RiferimentoNormativo:
@.lines.TaxDescription

The Enabled-condition for the tag shall trigger the XML element only if the delivery is tax exempt, and this correlates with the “Natura” tag:
@.lines.'$IsVisibleNatura'

Credit notes in FatturaPA and ESTEROMETRO

The worst comes at the end. It turned out that credit notes ( = TD04) must have the positive sign throughout the XML file. This requires massive changes in the DettaglioLinee section
ABS(@.LineBase.Quantity)
ABS(IF(@.LineBase.Quantity<0, -(1)*@.LineBase.'$FinalUnitPrice', @.LineBase.'$FinalUnitPrice'))
DatiRiepilogo
ABS(@.aggregated.Amount_Sum)
and DatiPagamento sections:
ABS(@.DueAmount)
Similar amendments but just at one place should be made in the ESTEROMETRO (which is a kind of an EU Sales list report for Italy) electronic formats, such as the “Report customer invoices IT” and “Report vendor invoices IT”.

Monthly Archives: June 2019