How NOT to send an order confirmation per e-mail

When utilizing configurable business documents (Electronic Reporting) in Dynamics 365, additional steps are required to dispatch various documents such as invoices, delivery notes (referred to as packing slips in the US), sales order confirmations to customers, or purchase order requests to suppliers. Begin as usual with Accounts receivable > Setup > Forms > Form setup, Print management. Select the appropriate Electronic Reporting (ER) configuration as a Report format.

It’s important to note that the conventional flexible print destinations outlined in Set up print management for a module | Microsoft Learn are not applicable for ER reports. Instead, navigate to Organisation Administration > Electronic Reporting > Electronic reporting destination. Here, for each ER configurable business document, create a dedicated line where you can specify Email as the destination under the Settings.

Programmable e-mail recipients

Here’s where it gets interesting: for each From, To, Cc address, clicking Edit provides you with the flexibility to choose between the traditional hard-coded method of extracting business party account details (+Add, Print Management email) or the Configuration email, featuring a low-code ER formula. When opting for the latter choice, Electronic Reporting grants access to the corresponding ER model.

The From formula can be a simple hardcoded text with the unattended e-mail address: "noreply@erconsult.eu". The mails will be sent via SMTP on its behalf, thus it must be a true Exchange 365 account.

The To = @Business@ field is employed to choose one among several electronic contact addresses (emails) of the party based on the electronic address Purpose. This configuration remains consistent with the classic Print Management setup.

For the Email source account for the To e-mail address, consider the following examples:

Configurable Business Document	Party	ER Formula to extract the account number
Sales order confirmation	Customer	`model.SalesConfirm.BuyerCustomerParty.Party.PartyIdentification.AccountNumber`
Sales order packing slip	Customer	Missing in the mapping; modify `model.BuyerCustomerParty`
Sales invoice	Customer	`model.InvoiceBase.InvoiceAccount.AccountNum`
Free text invoice	Customer	`model.Customer.AccountNum`
Collection letter note	Customer	`model.AccountingCustomerParty.AccountNum`
Purchase order	Supplier	`model.PurchaseOrderInquiry.SellerSupplierParty.Party.Reference`

The subject of the email can either be set as a fixed value, such as “Lieferschein / Delivery note” or dynamically constructed from components of the document model. This dynamic approach is particularly useful for the Body of the email. The FORMAT function with placeholders does not work. Instead, HTML tags must be concatenated sequentially. Thank you Ludwig Reinhard for this hint. Here is a sample:

"Dear Ladies and Gentlemen,"&"<br>"&"Attached you may find invoice "&model.InvoiceBase.Id&” for your order"&model.InvoiceBase.SalesId&".”&"<br>"&"Best regards, XXX"

Reprint documents safely

In the described setup, Dynamics 365 will automatically dispatch your configurable business documents to your business partners via email every time, even if you attempt to reprint or review the invoice, order confirmation, etc. The customers and suppliers will go nuts. Fortunately, a solution has been introduced since 2021: a feature known as Configure action-dependent ER destinations – Finance & Operations | Dynamics 365 | Microsoft Learn. This feature responds to the button clicked by the user—whether it’s ‘Copy,’ ‘Original,’ or ‘Use Print Management‘—and redirects the document to a different destination, providing a more controlled document distribution process.

With the configuration shown below, reprinted copies of an invoice are directed exclusively to the screen. The ‘View‘ option corresponds here to the buttons Copy preview and Original preview. The ‘Print‘ action is initiated during every post-and-print action when the configurable document is initially generated. Additionally, the ‘Print‘ action is triggered when the user deliberately selects Use print management for reprinting.

Do not send pro-forma documents to your business partners

The electronic reporting destinations unfold their devious nature when the people first preview a document before sending. Dynamics 365 is going to send the document via email regardless of whether the user opts to Use print management or not, proforma or not a proforma. Namely, both generating a pro-forma sales order confirmation and posting a final sales order confirmation are considered Print actions. This aspect bears potential legal consequences.

The recent feature, “Allow ER destinations adjustment at runtime (Phase 2)“, introduced in version 10.0.36, may offer assistance. However, I consider it intrusive and unsafe as it opens an additional dialog window placing the decision-making in the hands of the user: humans make mistakes.

We’ve identified a somewhat unconventional but more straightforward solution by manipulating and corrupting the Email source account mentioned earlier. Consider the following example:

IF(LEN(model.InvoiceBase.Id)>0, model.InvoiceBase.InvoiceAccount.AccountNum, "FUBAR")

If the invoice number is empty, the system returns a fabricated account number; otherwise, it returns the legitimate account number.

When attempting to send a copy of a pro-forma invoice to the customer’s email address, an exception will be raised, stating, “The email address in the To field is not valid.” The Screen destination will still succeed despite this exception.

Electronic reporting blog series

ZUGFeRD 2.3.2 export / Factur-X 1.07.2 for Dynamics 365 FO

We are excited to announce the release of the common German-French electronic invoice ZUGFeRD / Factur-X in Dynamics 365 for Finance and SCM. This plug-and-play solution in its “Light” version does not require any customisation and can be easily installed in the standard Electronic Reporting module of D365. It supports the ZUGFeRD 2.3.2 / Factur-X 1.07.2 profile EN 16931, also known as the “COMFORT” profile, and the “EXTENDED” profile. Both profiles meet all tax law requirements and must be accepted by customers unless explicitly denied.

In the ZUGFeRD/Factur-X standard, the invoicing information is included in an XML payload attached to a human-readable PDF file (see https://de.wikipedia.org/wiki/ZUGFeRD). This is in contrast to the Italian electronic invoicing system, where a PDF is embedded in a Base64 encoded block within an XML. The PDF document is just a visualisation of the electronic content, what counts is the XML attachment. The XML file is always named factur-x.xml and it is attached to at the PDF document level, not to a single PDF page:

Here is an example: factur-x.xml

Our solution, which utilizes Configurable business documents in D365, supports Sales invoices with separate buyer, seller, and order accounts. Other types of invoices such as the Free text invoice or any of the 3 Project invoices, can be provided upon request at a discounted price. Our solution also handles form notes, line and header notes and footers, line discounts, total discounts, and cash discounts, document level and line level charges, properly reflecting VAT for domestic, EU, and export sales. The settlement instructions orchestrate a SEPA credit transfer or a SEPA direct debit withdrawal; partially prepaid invoices are properly interpreted.

In addition, the EXTENDED profile introduces structured cash discounts, HS (customs Harmonized System = Intrastat) codes, countries of origin, standardised VATEX exemption codes, and more. To ensure backward compatibility and in response to customer requests, support for the BASIC and XRECHUNG profiles has also been added.

The solution is available in French, German, British and American English, Spanish. The PDF itself may be rendered in German, French, Britisch and American English, Spanish and Dutch.

Price

The solution is offered at a fixed fee per end customer / D365 tenant:

Version	Price	Deliverables	Notes
Light	€890	A ZUGFeRD Sales invoice ER configuration, the XML file only	This option does not require any X++ customisations or 3rd party software and can be installed and used right away.
Light+	€1200	Same as the Light version but with 5 hours of prepaid support and installation
Heavy	€2200	Contains the full solution, including a PDF template, and a PDF post-processor with 8 hours of prepaid support.	Includes the iTextSharp 5.5.13.2 .NET library under the GNU Affero General Public License Includes the BouncyCastle 1.8.9 .NET cryptographic library under a variant of the MIT license.

You may acquire the solution on the official Microsoft App Source portal: https://appsource.microsoft.com/en-us/product/dynamics-365-for-operations/er-consultgmbh1674479095356.zugferd_light_plus

Setup and use

Basic setup: “Light” and “Heavy”

For the ease of installation, configuration and integration, the standard Invoice model Invoice model v 277 and the standard Invoice model mapping are used (the recent mapping is 277.273 as of 31.03.2025 ), make sure they have been imported upfront.
Import the Electronic configuration “ZUGFeRD Sales invoice” provided to you (Organisation administration > Electronic reporting > Configurations, button Exchange / Load from XML file). Optionally, import the custom Invoice model mapping (ZUGFeRD), see below.

Beware The standard Invoice model mapping from Microsoft has a number of shortcomings. For instance, the buyer and seller addresses are passed in a de-normalized form as multi line strings. As a walkaround, some heuristics and regular expressions have been applied to extract the ISO2 code of the country and the zip (postal) code. The provided custom "Invoice model mapping (ZUGFeRD)" resolves the issue.

Under the button Configurations / Application specific parameters / Setup, provide a mapping of the VAT (en-us: Sales tax) Print codes to the ZUGFeRD categories S, K, AE, G, O (for example, the 19% and 7% VAT belong to the “S” category). Also provide a mapping of the D365 Unit of measure codes to the UNECE Recommendation No. 20 list called “Codes for Units of Measure Used in International Trade” (see Codes for Units of Measure used in International Trade: Recommendation N°.20 – Revision 7 | UNECE). For instance, a piece has the standard code H87. A sample parameter setup can be downloaded here: 03-01-2023 03.29.45 pm_ZUGFeRD Sales invoice.277.11 Once both the mappings have been established, set the Application specific parameters State to Completed.
Pay attention to the sample VAT print codes on the screenshot above: the standard Invoice model mapping does not pass the tax rates to the report, and the VAT Print code must contain the VAT rate in numbers, if applicable. In other words, they should look like “19%” and “7%” in Germany or “20%” and “5,5%” in France.

Print codes, Tax write codes These symbolic "print codes" persist in the tax transactions and invoice lines along with the VAT codes, i.e. they are historized and must be set correctly from the beginning: these changes in the VAT code have no effect on past data.

The current Microsoft Invoice model mapping Sales invoice does not pass the EU Tax directives into the report. By default, the report relies on the non-EU Tax exempt codes in the same way as the standard Excel invoice does. The provided Invoice model mapping (ZUGFeRD) changes that and makes the Tax directives available. Should there be both a Tax directive and an Exemption code in your VAT setup, the Exemption code wins and it will be shown in the tag
<ram:ApplicableTradeTax>
...
<ram:ExemptionReason>Tax-free EC shipments with tax registration number</ram:ExemptionReason>
...
</ram:ApplicableTradeTax>

The mapping of the sales units of measure is against the language-specific, translated unit texts (if exists), not the UoM symbol used in D365 globally, i.e. not pcs but Stk. You may find them in the Organization administration > Setup > Units form, button Unit texts. This Stk. then becomes H87 in the output file. The configuration translates the local units of measure to one of the H87, KGM, MTR, LTR, TNE, CMT, HUR, DAY, GRM, MIN, MON, WEE, MMT, SEC, C26, YRD, APZ, FOT, GLL, INH, ONZ, LBT.

The Years class is used as a fallback: no translation is applied and the unit text falls through as it is; for example, a UN mapped to Years remans UN in the output file.

To perform some post-processing, translate one unit to many as 1:N (for example, the unit ea may be translated to either C62 - an abstract units of service - or pieces H87 depending on the context), you may derive your own format version from the ZUGFeRD Sales invoice and extend the formula model.InvoiceLines.$SalesUnit2UN in the format Mapping.

Open Sales ledger (en-us: Accounts receivable) > Setup > Forms > Form setup. Make sure that the VAT specification option is set to Registration currency. You may also wish to display external item numbers: Item number in forms = Both.
On the Invoice tab, make sure the option Print VAT number on invoice is ON: it is mandatory. The option Print delivery note specifications should be better set, too: it populates the <ActualDeliverySupplyChainEvent> and the <DeliveryNoteReferencedDocument> tags. The Include documents… parameters activate the display of line and header notes.

Show in sheet: Configuration, Size etc. activates the line inventory dimensions, where the [translated] name becomes the Description and the code becomes the Value of an ApplicableProductCharacteristic:

<ram:ApplicableProductCharacteristic>
<ram:Description>Size</ram:Description>
<ram:Value>1440</ram:Value>
</ram:ApplicableProductCharacteristic>

Line level charges Data for the invoice is calculated in D365 by the same Data Provider as with the original SSRS sales invoice: "SalesInvoiceDP". In this SalesInvoiceDP, no information about line surcharges is stored - unless we are in Finland. But even in Finland, the SalesInvoiceTmp record representing the surcharge does not have a reference to the invoice line.

To fix that, an X++ extension of the SalesInvoiceDP class is required... if not for the active Retail Call Center ("MCR") configuration key (it is usually active): their MCRMarkupCalculatedAmount field keeps the total of all line charges which affect the invoice amount. This MCRMarkupCalculatedAmount is leveraged in our ZUGFeRD configuration to reflect the sum of all charges per line:

<ram:SpecifiedTradeAllowanceCharge>

<ram:ChargeIndicator>
<udt:Indicator>true</udt:Indicator>
</ram:ChargeIndicator>
<ram:ActualAmount>12.3</ram:ActualAmount>
<ram:Reason>Belastung</ram:Reason>

</ram:SpecifiedTradeAllowanceCharge>

In accordance with the ZUGFeRD specification, this markup amount increases the total line amount before VAT <ram:LineTotalAmount/>, and it is excluded from the header level charges <ram:ApplicableHeaderTradeSettlement>.<ram:SpecifiedTradeAllowanceCharge>.

Finally, open Print management and select the Report format = ZUGFeRD Sales invoice at the Customer invoice node. Specify a Footer, too.
Create a new ER destination (Organisation administration > Electronic reporting > Electronic reporting destination) for the report ZUGFeRD Sales invoice. Under File destination, add a new line, choose the factur-x file component and divert it to a destination of your choice (for instance, the Screen).

The Light version setup ends here.

Supplementary setup: “Heavy”

For the Heavy version, first deploy the X++ customisations and libraries from the D365 deployable package provided to you.
Create a new File document type in the Organisation administration > Document management > Document types list. Name it exactly like this: ZUGFeRD.
In the ER destination (see 9 above) this time choose the ZipFolder file component. Click Settings. To show the invoice on the Screen, divert the file to the Archive: set Enabled and Save in job archive, and choose file Type = ZUGFeRD.

Action-dependent ER destinations For the screen destination to work, make sure that the feature "Configure action-dependent ER destinations" (see https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/analytics/er-action-dependent-destinations) remains inactive: the selection Document type in the ER destination must be set to Any. This is a known bug in D365 FO v41 and earlier versions.

To send the invoice per Email, add a new file destination line, click Settings, open the tab ZUGFeRD, and flip the Email slider. In the Email ID parameter, you may also select an Organisation administration > Setup > Organisation email template with an appropriate subject and a HTML body in your corporate design. Placeholders%ExchangedDocument% (invoice ID), %DuePayableAmount% (invoice amount) and %BuyerTradeParty% (customer ID) are supported out of the box i.e., the email subject and body of the email are dynamic. The selection Document type in this ER destination must remain Any or Electronic.
The steps to configure the Heavy version end here. The Electronic Reporting engine will fill out the PDF form, populate an XML file and put both into a folder (i.e. a ZIP). This ZIP file is intercepted, unpacked, and the XML part is embedded into the PDF, adding some references and mandatory attributes. The PDF file is not fully PDF-A/3 compliant, but it can be read and parsed, the XML payload passes the validations (see the links below).
Print the sales invoice with the option Use print management turned on. The resulting PDF document is rendered on the screen (the Light version offers an XML file to download) in a separate browser window or sent per e-mail to the email contact of the customer with the role Invoice. In the batch invoicing mode (de: “Autofaktura”), the Screen destination is obsolete.
You may also re-print invoices out of the Invoice journal form (Sales ledger > Enquiries and reports > Invoices > …) with the button View.

An example of a ZUGFeRD invoice with the COMFORT profile may be found here: ZUGFeRD_COMFORT.pdf

"The file may not be sent: Pro forma invoice or Invoice copy" Be aware of the hardcoded safeguards against re-sending the invoice per email if already sent, and against mailing proforma invoices to the end customer. Namely, a successful transmission per e-mail raises the SentElectronically flag at the invoice.

Custom Mapping and the EXTENDED profile

The EXTENDED profile, compared to the ‘EN16932’ profile (also known as the ‘COMFORT’ profile), adds the following elements

Structured payment terms, such as cash discounts in %;
Serial numbers, batch numbers per line;
Delivery note numbers and dates per line;
Customer’s PO reference per line;
Ship to party (a deviating shipping address, see below);
Package quantity (per line only!);
<ExemptionReasonCode> i.e., the reason for exemption from VAT obligation provided as a CEF VATEX code.

In the Root of the ZUGFeRD Sales invoice format mapping, a variable “Profile” is introduced. It acts as a profile selector. By default, it returns the number “3” for the COMFORT (=EN 16931) profile. The values “2”, “3”, “4” and “5” are reserved for the profiles BASIC, EN 16931, XRECHNUNG, and EXTENDED, respectively.

For example, to switch to the EXTENDED profile, derive your own version of the format, select the Profile node to the left, click Edit and let the formula return “5”.

Through a derived mapping, this variable may be even tied to a property of the customer (a CustTable field, for example) to act as a dynamic selector of the profile.

For the EXTENDED profile to function, the custom Invoice model mapping (ZUGFeRD) is necessary. The same custom mapping enables some features of the COMFORT and XRECHNUNG profiles, for example the country of origin or the HS code, or the city name. For the reasons of compatibility, these features – even though they belong to the COMFORT profile – are unlocked by the Profile > 3, too.

Ship to party In standard D365 for SCM, the Ship to address is present on the invoice only if the Transportation details have been populated at the SO header prior to the invoice posting: https://learn.microsoft.com/en-us/previous-versions/dynamicsax-2012/appuser-itpro/lva-enter-transport-information-for-a-sales-order. The custom mapping changes that and starts exposing the <ShipToTradeParty> tags whenever a customer delivery address is known.

Below are additional steps to get the most of the EXTENDED profile:

Deploy the Electronic configuration “Invoice model mapping (ZUGFeRD)” (Organisation administration > Electronic reporting > Configurations, button Exchange / Load from XML file).
Select it in the ER tree, and make it Default for model mapping to resolve the ambiguity between the custom and the standard Invoice model mapping.
To embed HS codes and the country of origin into the <DesignatedProductClassification> tag, make sure the Commodity code and the Country/region are populated at Product information management > Products > Released products.

Print product dimensions The Country of origin and the HS code may not work in a system where the Form setup parameter "Print product dimensions" is set to "Part of item number" (see the section "Basic setup"). Use the other 2 options instead.

For the batch and serial numbers to appear in the <IndividualTradeProductInstance> node, mark Show in sheet: Batch number and/or Serial number on the Invoice tab in the Form setup form (see the screenshot in the previous section).
For the output of the commercial register (de: Handelsregister or HRB) number, a dedicated Registration type must be given the Czech (!) category “Spisova znacka” under Organization administration > Global address book > Registration types > Registration categories (this is how the standard free text invoice works 🙂

This registration record must be added to the primary address of the legal entity (see Organisation administration > Organisations > Legal entities, look for the Registration ID button, enter the Registration number and the Issuing agency there). The validity date of this registration cannot be changed, it becomes effective from the date of the entry onwards. Ultimately, it appears in a note of the REG type as intended by the maintainers of the ZUGFeRD standard:

   <ram:IncludedNote>
      <ram:Content>Registrierung: Landesgericht Eisenstadt 533252 w</ram:Content>
      <ram:SubjectCode>REG</ram:SubjectCode>
    </ram:IncludedNote>

Before leaving the Organisation administration > Organisations > Legal entities form, check if the company Bank account is populated, and this bank account has an IBAN and a SWIFT code.

This concludes the EXTENDED setup. Check out the sample below, you buy what you see!

Useful links

End user license agreement: ZUGfERD_Heavy_EULA
The French PDF / XML validator is available online on Factur-X Validator (fnfe-mpe.org)
The German validators are now hosted at portinvoice | Safe Harbour für eingehende E-Rechnungen
A rich interactive ZUGFeRD schema navigator is hosted here: EN 16931 – FacturX 1.03 – ZUGFeRD 2.0.1 – COMFORT (gefeg.com), for the German dialect refer to XRechnung_CII; v1.2.1; 28.06.2019

Extensibility

To implement a custom invoice design with a corporate logo, a certain colour palette or fonts, extend the ER configuration “ZUGFeRD Sales invoice” as any other ER configurable business document. Derive an own configuration, then extract, amend and replace the PDF template attached to the ER configuration version. Please bear in mind that PDF forms do not contain dynamic, repeatable ranges or cells. This is the reason why the number of invoice lines in the template is currently limited by 10; this number will be extended on demand. Refer to Design ER configurations to fill in PDF templates – Finance & Operations | Dynamics 365 | Microsoft Learn for more details.

The “output actions” are extendable: new output actions may be offered upon request at a discounted price. You may even implement your own /Class/ERFileOutputActionXXX_ZUGFeRD, for example:

				
					/// <summary>
/// Send the resulting PDF to a browser window interactively
/// </summary>
[ERFileOutputAttribute_ZUGFeRD(SRSPrintMediumType::Screen)]
class ERFileOutputActionScreen_ZUGFeRD extends ERFileOutputAction_ZUGFeRD
{
    /// <summary>
    /// The screen destination does not need to extract any contact info
    /// </summary>
    /// <returns>An empty visitor class</returns>
    public ERFileOutputActionXmlVisitor_ZUGFeRD makeVisitor()
    {
        return new ERFileOutputActionXmlVisitor_ZUGFeRD();
    }

    /// <summary>
    /// Display  the PDF file formed by ERFileDestinationPostProcessor_ZUGFeRD on the screen 
    /// </summary>
    /// <param name = "_outputPDF">Stream with a PDF file, with a CII XML attached</param>
    /// <returns>Success or failure to display</returns>
    public boolean sendFile(System.IO.MemoryStream _outputPDF)
    {
        Browser br = new Browser();
        
        str downloadUrl = File::SendFileToTempStore(_outputPDF,
                                                    ERConstants_ZUGFeRD::ZUGFeRD_Filename,
                                                    classstr(FileUploadTemporaryStorageStrategy),
                                                    true);
        if (downloadUrl != '')
        {
            br.navigate(downloadUrl, true, false);
        }
        else
        {
            return checkFailed("@ApplicationPlatform:DownloadFailed");
        }
        return true;
    }

}

E-invoice and configurable business documents blog series

Enumerate lines in Configurable Business Documents

The delivery note, invoice etc. Report Data Providers in Dynamics 365 for Finance do not expose line numbers for no obvious reason. For instance, the SalesInvoiceTmp table sent from D365 to the report renderer – whatever it is – misses the line number. The situation becomes dire when it comes to Electronic Reporting / Configurable Business Documents.

The ENUMERATE(Lines) function applied to the lines makes a totally new object {Number, Value} and every binding “@” becomes “@.Value“. This is a massive change in the report, very hard to maintain and upgrade (rebase).

In XML or CSV outbound formats there is a Counter element, it auto-counts itself. In Excel and Word outbound formats there are just Ranges, Cells. I thought we worked with lists as isolated objects and there were no internal variables in Electronic Reporting which were aware of the execution history.

But today I finally understood what the DATA COLLECTION does. It is a listener, you pass a value to it, it returns it back unchanged but keeps a global variable to count and summarise the values.

For example, to enumerate delivery note (en-us: packing slip) lines, first create a root Data collection class of the integer type in the Mapping to the right, Collect all values = Yes, let’s call it a LineNumberCollection.

Then put the following formula into the Excel Cell with the line number:
LineNumberCollection.Collect(1)+LineNumberCollection.Sum(false)-1

The first LineNumberCollection.Collect() call takes 1, records 1 internally, and returns the 1 back into the cell. The second call LineNumberCollection.Sum(false) adds the running total of 1’es recorded so far. The last operand subtracts 1.

Here is the result: Bingo!