Electronic Reporting (ER) Cookbook 4: References in a model

The “Item reference” in Dynamics 365 Electronic Reporting models has been an elusive concept for me for quite a long time. A reference creates a kind of a cross-link between the ER model parts, but what for? Now I think I have figured out some important use cases:

Re-use structures and record list definitions within the model, especially for UNIONs
Map the same model in different ways and export similarly structured files from different sources

References to facilitate LISTJOINs

The LISTJOIN ER function is an analogue to the SQL UNION. It combines heterogenous record lists into one list of a common type. For example, a LISTJOIN(model.PurchaseLines, model.SalesLines) creates a typed single record list with their common fields: Product no, Quantity, Delivery date, Warehouse etc. However, for the LISTJOIN to recognize the common fields, the fields must be aligned, i.e. follow in exactly the same order, bear exactly the same names.

Here is where the references come into play. One can organize a “Dictionary” root entry in the model, define the most elementary composite entries there, then click the Switch item reference button elsewhere and include this small “brick” into a larger record. From the small bricks one may build larger bricks and so on. Such cross references are indicated by the asterisk (*):

In the above example, an Order record includes the CategoryComposite, Coverage order, Item order nested 1:1 records, and uses fields of the Category type and Line status enumerations. The resulting common Order record type is further assigned to the Sales and Purchase record lists, and this makes their structure in the model identical. The LISTJOIN() then produces a list of records with the following fields:

@.Amount
@.’Qty avail’
@.Category.Group
@.Category.’Category ID’

and so on.
By the way, the root node Item dictionary here is a Container. A Container is used simply to put together diverse artefacts, a way to make the model definition more readable.

References to apply different mappings to the same model

Imagine you need to export sales order lines and purchase order lines into 2 different files, similar in structure. You need a model to abstractly describe a generic Order line list, then a Sales line format export definition, a Purch line format definition both preferrably derived from a common Order line format, and 2 mappings: Sales line to model and Purch line to model to populate the Order line list model from 2 different data sources in Dynamics 365.

Try to run the Sales line format file. It is going to start complaining about 2 models present: “More than one model mapping exists. Set one of the configurations as default.” You set the Sales line to model as Default for model mapping = Yes and the export starts working.
No try to run the Purch line format. It is going to export sales order lines in the purchase order line format, because a link between the format and the outbound mapping is through the model node they use:

Format → Model [node] → [default] Model mapping

To fix this, the 2 formats should be mapped to different nodes in the model!

I’ve got a similar issue when I was trying to use the same model both for the export and for the import of data. There was a Counting journal model and 2 formats: Export to Kardex and Import from Kardex. There was a Counting model mapping for the export and a Counting model to destination mapping for the import.

Tried to run the export Export to Kardex and it asked to “Set one of the configurations as default“, which I did.
Then I tried to run the Counting model to destination mapping but it was not prompting any files for the upload, because a link between the inbound mapping to the import format was established through the model and it was pointing to the export format:

Model mapping to destination → Model [node] → Format

The trick is to use different nodes! The import format should write the data from the inbound file into one Record list in the model, while the export format should read data from another Record list in the model. The mappings then bind the same table to the one node and another, respectively. To reuse the data types and the structure, one node references the other (Switch item reference).

Electronic reporting blog series

Electronic reporting for data migration

Intro

There are still dozens of important tables in Dynamics 365 for Finance and SCM not exposed by any entity. Sometimes simple solutions like my Copy-paste with a keyboard script from Excel don’t work due to the volume or complexity of the data, and sometimes there is no UI at all.

One of the notorious examples is the table EcoResCatalogControl which is associated with product attributes bound to procurement categories, see the Searchable flag in my blog Searchable product attributes. An import of these “Product category attributes” through the entity EcoResProductCategoryAttributeEntity leaves the attributes dysfunctional: the internal table EcoResCategoryAttributeLookup is left out of sync and the new attributes remain invisible in the product master.

The only form where the EcoResCatalogControl is editable and visible is the Procurement category form, but an attempt to update the flag fails with a “Missing reference” error: the system expects a EcoResCatalogControl record to exist already. Dead end.

Electronic reporting: the last resort

Since the table browser is not an option anymore in a sandbox or production environment, the number of tools available to the consultant reduces to just one: Electronic reporting. Despite the name, the Electronic reporting module is able not only to read, but also freely insert, update or delete voluntary tables in D365FO.
In essence, the idea is to make a CSV text file and import it into the EcoResCatalogControl with the help of the Electronic reporting (ER).

This requires a so-called Mapping to destination where the “destination” is one or many tables or entities in D365FO. The concept is nicely outlined in the blog of Mr. Ties Philippi. In total, 4 “components” are required in at least 2 ER configurations (the Mapping to destination may in theory be detached into a separate – third – configuration).

Model
Model mapping “To destination”
[CSV file] Format
Model mapping [from format] ”To model”

The execution flows in the order (3) -> (4) -> (1) -> (2).
The 2 configurations I used can be downloaded here.

First, create a model, for the simplification its structure may follow exactly the table.

Next, create a mapping with the Direction = To destination. Add the target table to the right with the button Destination, then bind the model from the left to the table at the right side of the Model mapping designer. Change the status of the configuration to Complete.

Next, create a format configuration based on the model. It should describe the CSV file structure, namely a set of records (Lines) separated by CRLF, with 2 fields in every line, separated by the semicolon “;” (in a German version of the Excel; in an English version the comma “,” is more appropriate). The encoding of the CSV format should better be UTF-8 (Excel is able to produce UTF-8 encoded files).

Do not bind the format to the model, but use the button Map format to model to create a mapping of the same name. Bind the format to the model as shown on the screenshot below. The button Run can be used to test the mapping ad hoc: it takes a CSV file, interprets it according to the format definition, translates to the model internal container and exports this container to an XML file.

Once tested, update the format status to Completed. Make note that the import is started from the artefact (2) Model mapping to destination (with the button Run). The system looks for a format based on the model the mapping belongs to, and inside of that format it looks for a “To model” mapping.

Having found an appropriate format, the system asks for a CSV file and unleashes the import, there is no way back.

Update route

Added on 31.01.2020
Electronic reporting destination mappings can also be used to launch X++ code. If you have ever worked with production routes, you may have noted the Update route button. The class behind is called RouteUpdate and it is executed by the system automatically from the UI on any change in the order of operations. On plain production routes, it updates the Next operation numbers, and multiplies the variable scrap percentages to cache and store accumulated scrap factors. The problem is, this class cannot be run over all routes in the batch mode; in the Route headers entity they forgot to use it. Opening every single route out of thousands imported is obviously not an option.

I took the same CSV file and created a new destination mapping which updates the RouteTable. One column in the CSV file (Attribute) contains the key RouteId, the other (Category) bears the route name. I am updating the name by the key, but in the middle I am injecting the following code
RouteSearch.newRouteId(@.Attribute).routeId
like this
LEFT(RouteSearch.newRouteId(@.Attribute).routeId,0)&@.Category
It instantiates and executes the RouteSearch class which as a by-product calls RouteUpdate in its constructor method, then gives a routeId() value back which I neglect. Thousands of routes are updated blazing fast, and the Next operation and the Accumulated scrap is set everywhere:

The ER configuration can be downloaded here: RouteUpdateMapping.zip.

Open project milestones

Added on 16.04.2020
Finally, I have designed a data model and mappings for the fixed fee project On-account transactions aka Billing milestones. The configuration may take a project TransId from the CSV file, or it may create its own from the standard number sequence in the Project module parameters. Both the related tables ProjOnAccTrans + ProjOnAccTransSale are generated.

The ER configuration can be downloaded here: ProjOnAccTransModel.zip
Fun fact: a DMF entity for this existed in AX2012, but not D365.

Epilogue

The above crude trick works, but it is dangerous. Fixing a broken import might be a challenge, because to delete the data and start all over you need to change the destination Record action to Delete and then hope to find the right record by the primary key from the CSV file.

I would love to use standard entities, and make Microsoft add them to the application. Please vote for my 2 “favourites”:

the management of EcoResCatalogControl in an entity and…
the open (not invoiced) project milestones ProjOnAccTrans + ProjOnAccTransSale.

Electronic reporting blog series

Minimalistic EU VAT Configuration in Dynamics 365

Introduction

Let me present my 4th iteration of the EU VAT setup in Dynamics. The below concise VAT configuration in Dynamics 365 for Finance has been tested over 3 years of my operations. It has been constantly updated with the changes in taxation. It covers intra-community import, export and import of services within the European Union and beyond, domestic supplies, business travel within the EU and abroad.

Before we begin with the setup let me explain some background facts and assumptions:

- Any export of goods or services in or outside of the European Community is tax-free, but reported
- An export of services is special: in accordance with Directive 2008/8/EC any service rendered for customers abroad is subject to reverse charge
- In the case of an intra-community (IC) delivery, goods and services are presented separately on the EU Sales List
- On the contrary, goods and services delivered in the home country are reported together and should not be distinguished
- Intra-community deliveries are reported separately from the foreign trade with the so-called 3rd countries (i.e. countries which are not the 28 members of the EU, e.g. Norway or Switzerland). IC trade appears of the EU Sales list, while 3rd country trade does not. Deliveries of tangible goods are reported to the INTRASTAT in addition.
- Most of the countries apply a full rate and several reduced rates. The reduced rates are there mostly for the basic consumer services and goods (Austria: 10%). They normally do not affect enterprises, until the employees start reporting travel expenses.
- A semi-reduced “hotel” rate of 13% stands out in Austria, but also in Switzerland and France for accommodation. Update 2018: 13% were reverted back to 10% in Austria, but I am going to keep it in my scheme.
- A grocery may have separate tax codes for an IC acquisition of Polish potatoes (self-assessed 10%) or French wines (self-assessed 13%). However, the reduced-% goods and services are rarely imported by manufacturing or professional service businesses, with the exception of foreign books and printed media (self-assessed 10%).
- In Switzerland, the VAT receivable from investments is reported separately from the VAT received from current assets or services (de-ch: “Vorsteuer auf Investitionen und übrigem Betriebsaufwand” vs “Vorsteuer auf Material- und Dienstleistungsaufwand“) despite the same rate.
  Since 2019, a similar aspect has become valid in Austria too. The mandatory Chamber of Commerce contribution (de-at: “Kammerumlage 1” or KU1) is evaluated at 0,29% of the total VAT receivable excluding any investments i.e. assets acquired either domestically or abroad.
  The reduced VAT (foodstuffs, pharmaceuticals) may be neglected: milk is unlikely to become a long-term asset, unless condensed 😉
- From the system point of view, there is a difference between a “zero rate” and “no rate”. A tax code with a 0,00 rate still logs the tax base for reporting, as long as a record in the tax Values table exists.
  From the fiscal standpoint, there is a difference between a “zero” an “no” rate too. For example, in the UK public transportation is taxable at 0% which is considered a tax rate of its own. In France, 0% is applied to newspapers. To enable a zero rate, just open the Values table in connection with the tax code, let the system create a record, leave the Value = 0,00000 and save the record.

VAT codes (en-us: Sales tax codes)

Tax code	Name	Rate AT	Example
doF	Domestic VAT, full	20%	Sales or purchase of regular goods and services, e.g. raw materials, office consumables, car expenses (electric cars or ‘fiscal trucks’ only)
doA	Domestic VAT from assets, full	20%	Investments in long-term assets, i.e. machines, office equipment, electric car fleet
doH	Reduced “hotel” rate	10%	This reduced rate applies to accommodation, but not restaurant bills
doR	Domestic VAT, reduced	10%	Public transportation, taxi, and basic foodstuffs, including restaurant bills with non-alcoholic beverages, books and newspapers; in Germany it is slightly different: dishes served in a restaurant are charged with the full tax rate, while the ‘take away’ foodstuff is reduced
TF	Tax free Out of scope	0%	Exempt international air and sea transportation, or services delivered by “non-genuine” tax exempt suppliers such as insurances, postal services (de-at: “unechte Steuerbefreiung“), but also the City tax (de-at: “Tourismusabgabe“, “Ortstaxe“) component on hotel bills. The base on purchases may still be reported to the authorities.
NR	Not recoverable	–	On a travel abroad, services consumed by the employee are taxable per se, and within the European Community the tax may even be recovered, but very few companies do so. The code is not reported to the authorities. Running expenses from traditional personal cars with internal combustion engines fall into this category too.
euF	IC export IC acquisition	0% 20%	Delivery of goods to another country of the European Community is tax free, but the value of the goods is reported to the tax authority. On a regular import of goods from another member of the European Community the full domestic tax is levied; the tax is self-assessed with a zero effective tax load (what you pay is what you get recovered). This is achieved with the Use tax (en-us) i.e. Import VAT / purchase VAT (en-gb) setting in the VAT group.
euA	IC asset export IC asset acq.	0% 20%	It is highly likely, that the investments into long-term assets (machinery, other equipment) flow into another EU country. Less probably but also possible, is that used assets are sold to an EU neighbour.
euR	Reduced IC export IC acquisition	0% 10%	Delivery of goods to another country of the European Community is tax free, but the value of the goods is reported to the tax authority. On goods that would be subject to the reduced tax rate domestically (e.g. books), the same reduced tax rate is applied when procuring such goods from another member of the EU; the tax is self-assessed with a zero effective tax load and the Use tax setting in the VAT group.
euS	IC services export IC services import	0% 20%	Delivery of services in another country of the European Community is tax free but reported. The buyer, however, must obey the reverse charge principle. The setup for the reverse charge and the zero tax impact is similar to the above IC goods acquisition.
exF	Export 3rd county Import 3rd country	0% ~20%	The export of goods is tax free in most of the countries, but the value has to be reported. Tangible goods imported into the EU from a 3rd country is subject to an import tax, whose base is hard to calculate because it includes the portion of insurance and freight up until the border. Normally the import tax is calculated and paid by the customs broker; in the exotic import tax self-assessment mode (de-at: “Einfuhrumsatzsteuer geschuldet”) this exF tax code may be used to post the tax.
exS	Services export 3rd Services import 3rd	0% 20%	If the place of supply of services is outside of the EC, the export is tax-free but still have to be reported (as taxable elsewhere under the reverse charge regime). The procurement of services outside of the EC is subject to a self-assessed reverse charge.

VAT groups (en-us: Sales tax groups)

In every business case in Dynamics 365 for Finance, the tax code is deducted by the system from an intersection between the customer/supplier VAT group and the product Item VAT group. Aside of the basic “F”, “S”, “TF” item VAT groups I recommend “H”, “Food” and “PubT” for the travel expense recording. The reason to separate the latter 2 groups is my reverence to companies holding multiple VAT identification numbers (UIDs) in different EU countries: tax rates for these categories vary across Europe.

It is a good practice to have a valid tax code, i.e. a valid Customer/Item group combination in every business case whenever it is present on the tax declaration or not. This is enforced by the tax parameter Check tax code. For example, on a business trip from Germany to Hungary the VAT may theoretically be recovered, but hardly any company does it. One way is omit the tax completely, but to stay compliant to the Check tax code setting, the tax code NR has been introduced. The respective VAT group AP-NR may be then assigned to the country HUN in the Travel and Expense module, and any foreign Hungarian VAT will be neglected yet formally recorded on the tax code NR.

Any business case we do not anticipate or consider a human mistake is going to result in a missing VAT code, e.g. an attempt to sell milk by a consulting company, or a foreign trade operation in a society without an EORI number. With the strong Check tax code setting such an attempt is going to result in an error and roll the transaction back, preventing havoc in the ledgers.

Customer or supplier VAT group	Item VAT group “F” (full)	Item VAT group “A” (assets)	Item VAT group “S“ (services)	Item VAT group “TF“ (tax free)	Item VAT group “H” (hotel)	Item VAT group “Food“	Item VAT group “PubT“ (public transp.)
*Suppliers*
AP-DO	doF	doA	doF	TF*	doH	doR	doR
AP-EU	euF**	euA	euS	TF	NR	euR	NR
AP-EX	exF		exS	TF	NR	NR	NR
AP-NR	NR	NR	NR	NR	NR	NR	NR
*Customers*
AR-DO	doF	doA	doF	TF
AR-EU	euF	euA	euS	TF
AR-EX	exF		exS	TF

*) Tax codes to be marked Exempt in the VAT group configuration are stroke through,

**) and those marked as a Use tax are in italic.

Disclaimer

The above configuration is going to work well in the D-A-CH countries, in Scandinavia and even in Spain. Yet it doesn’t account for the “VAT on payment” aka Conditional tax common in France (de: “IST-Besteuerung“), and it will probably not work for countries with inflated reporting requirements (Italy). The Conditional tax may however become highly relevant if the customer is required to pay a significant advance payment. That case is treated in the blog Advance payment invoices in Fixed fee projects in D365, D-A-CH style.

Dynamics 365 for Operations

Electronic Reporting (ER) Cookbook 4: References in a model

Electronic Reporting (ER) Cookbook 4: References in a model

References to facilitate LISTJOINs

References to apply different mappings to the same model

Electronic reporting blog series

Electronic reporting for data migration

Electronic reporting for data migration

Intro

Electronic reporting: the last resort

Update route

Open project milestones

Epilogue

Electronic reporting blog series

Minimalistic EU VAT Configuration in Dynamics 365

Minimalistic EU VAT Configuration in Dynamics 365

Introduction

VAT codes (en-us: Sales tax codes)

VAT groups (en-us: Sales tax groups)

Disclaimer

Blog series on Finance and VAT in the EU