Alireza Eshaghzadeh Senior Business Consultant

Configurations that we import from Microsoft repositories misses release note to find which changes have been made on data model, model mapping and format designer.

This will help user to get better overview that each KB or ID include in regards with new fields functions, changed mapping and deleted fields.

As an example, It could be added a text field as attachment regarding the changes as "Release note" or a new field on mapping model and format designer that contain information about the KB/ID changes.

Once we create a new company in the solution, mostly, we need to define print setup for forms in account receivable, account payable , and project module manually (e.g. Account receivable > Setup > Forms > Form setup > General > Print management). It is cumbersome job once we create several companies in the solution and you need to add a print destination for each forms.

It would be great if either we can have

1-A batch job to add these default print management report format automatically to each form in a company.

2-A data entity that can be used to copy default print management report format from one company to selected company(ies).

Electronic reporting destination form is company-specific and can be utilized for various purposes. One of the key advantages is the ability to design business documents in Excel or Word and activate the "Convert to PDF" functionality.

In order to improve our system, we have identified two potential solutions:

1-Creating data entities for "Electronic reporting destination references" and "Electronic reporting file destination". This will allow us to store and manage information related to electronic reporting destinations in a structured manner, enabling seamless integration with other systems and processes.

2-Activating tables that can be shared via Configure cross-company data sharing. However, we have encountered a warning that may prevent us from sharing the ERFormatDestinationTable. Specifically, the warning states that this table is a Miscellaneous table and may not be shared unless its Data Sharing Type is set to Duplicate.

"Electronic reporting destination" form is a company-specific that primarily utilized for configuring the destination of generated reports or invoice layouts (such as Email, Archive, Screen, etc.) within business documents. Presently, we face a challenge due to the absence of standard entities (Reference, File Destination, Document Layout Setting) that can be accessed through the Data Management Framework (DMF). Given our frequent use of business documents and the shared requirements across multiple companies, the implementation of standard entities for these forms would greatly facilitate the process of copying configurations via DMF.

There are multiple reports and documents that can be archived using Electronic Reporting jobs, such as e-invoices, SAF-T(NO), Pain.001, and others. Additionally, when using business documents or their derived versions and setting the destination as "Screen" via Workspaces > Electronic reporting > Electronic reporting destination (by adding a new reference or business document and clicking on "Settings" to enable "Screen"), a log is created within Electronic Reporting jobs when a user prints the corresponding document. For example, Run of Format mapping 'Collection letter note (Excel)', configuration 'Collection letter note (Excel)').

It's great to have a log of who printed the business documents, though the current form (Electronic Reporting jobs) may not be the most suitable place for this functionality.

I would like to propose the following development ideas:

- Create a dedicated form for logging the print status of business documents. Each record could be associated with a specific business document name, with the ability to mark and delete records

- Add an Enum to Electronic Reporting destinations, allowing users to activate or deactivate logging for print status.

- Define a new field on the Electronic Reporting jobs form for "File type," linked to ER configuration names (such as SAF-T Format (NO) and OIOUBL Sales invoice), and provide the option to mark multiple records for deletion.

Regarding the Microsoft Learn post on optimizing Financial Journal Posting Performance in Dynamics 365 via lines limit, this functionality is designed to operate through batch processing. It can be applied to general journals and customer/vendor payment journals. However, it should be noted that this feature is not applicable to fixed asset journals due to the absence of batch posting capabilities in that context.

PS. The same is related for project journals.

It would be great to have the possibility to post project and fixed asset journals via batch job.

Proposal:

Introduce a new feature allowing businesses to seamlessly include business documents as embedded attachments within e-Invoice files.

Current behavior:

When activating "eInvoice attachment" for a customer in D365FO, a copy of the invoice layout in PDF format from SSRS is embedded in the e-invoice file. However, there is an issue when using business documents instead of SSRS, as attaching the invoice file in PDF format is inaccurately executed.

<cbc:EmbeddedDocumentBinaryObject mimeCode="application/pdf" filename="FreeTextInvoice.Report.pdf">JVBERi0xLjcNCjIgMC</cbc:EmbeddedDocumentBinaryObject>

Proposed Solution:

Upon activating "eInvoice attachment" on the customer card, the system will use the Report format specified in the print management setup and ER destination setup. It will convert the document into PDF, if "Convert to pdf" is activated on Electronic reporting destination, attach it to the invoice journal, and seamlessly embed it in the e-invoice file as an embedded document. This enhancement allows customers to include business documents designed in Excel or Word as attachments to e-Invoices, providing a more versatile and accurate solution.

Electronic Reporting (ER) Jobs form could be improved in its UI by adding fields to better track document status, such as invoice or order IDs, destination types, and ER configurations. These updates would make it easier for users to retrieve and manage Business Documents files and streamline reporting processes. To better display business document status, the following fields should be added:

1. Account Number: Invoice account number.
2. Document ID: ID for the document (e.g., invoice, packing slip, or confirmation ID).
3. Order ID: Order ID or project contract ID.
4. Form: Form source (e.g., Project Invoice or Customer Invoice).
5. Destinations: ER destination type (Screen, Archive, Email) to indicate the document distribution method.
6. ER Config: Name of the ER configuration used.

These new fields will be be filterable and searchable, enabling users to find specific documents more efficiently. Additionally, they can be marked for quick and straightforward deletion.

Additionally, a new “Archive” functionality can be added to each required form (e.g. Invoice journal and Project invoices), redirecting users to Electronic Reporting Archived Jobs if the document has already been archived via ER destinations (i.e., Archived = Yes). This enhancement allows users to quickly access already archived documents without needing to open extra forms to locate the business document.

In the invoicing process using Peppol Billing BIS 3.0 for customer electronic invoices in Norway (as described in the Microsoft Learn documentation - https://learn.microsoft.com/en-us/dynamics365/finance/localizations/norway/emea-nor-e-invoices), a PDF copy of the invoice is created as an attachment when the following conditions are met:

• ER configuration is enabled via electronic documents (Accounts receivable parameters > Electronic documents).
• The "eInvoice attachment" option is activated on the customer card.
• The user posts a project invoice or a customer invoice with the "Print" option set to "Yes."

This PDF attachment is automatically generated based on the selected report format—either standard SSRS or Business Documents—and is added to CustInvoiceJour and ProjInvoiceJour. However, the current implementation uses a generic attachment description that is the same for all invoices, regardless of the format applied.

Problem: Since this attachment is embedded in the e-invoice file, a generic description does not provide meaningful or unique identification for attachments. This creates challenges when managing e-invoice files efficiently.

Proposed Solution: To improve usability and traceability, the attachment description should dynamically reflect the naming conventions of the associated business document or SSRS report. Specifically:

• For Business Documents: The attachment description should match the Business Document file name.
• For SSRS reports: The description should follow a custom format incorporating key identifiers, such as the company ID, invoice number, and customer ID.

Examples of File Names for Attachments (AS-IS):

• Customer Invoice: SalesInvoice.Report.pdf
• Free Text Invoice: FreeTextInvoice.Report.pdf
• Collection Letter Note: CustCollectionJour.Report.pdf
• Project Invoice without Billing Rules: ProjInvoice.Report.pdf
• User-Defined Project Invoice: ProjInvoice.Report.pdf



By implementing this enhancement, the attachment descriptions will become more informative and aligned with the content of the invoice files. This will result in improved efficiency and accuracy in managing e-invoice files, ultimately benefiting users handling large volumes of transactions.

Scenario

When posting an invoice (Free Text Invoice, Sales Invoice, or Project Invoice), and if the following conditions are met:

1. e-Invoice attachment is activated on the customer card.
2. “Print invoice” is activated on the posting form.

Then the following actions occur automatically:

• The invoice is printed.
• The invoice is posted.
• A PDF copy of the printed invoice is attached to the respective journal (CustInvoiceJour or ProjInvoiceJour).
• The e-invoice file is generated and stored under Electronic Reporting jobs.

Current Behavior

The attached PDF file uses a generic file name regardless of whether users apply standard SSRS reports or CBD formats.

The default names are as follows:

• SalesInvoice.Report.pdf – Sales Invoice
• FreeTextInvoice.Report.pdf – Free Text Invoice
• ProjInvoice.Report.pdf – Project Invoice
• CustCollectionJour.Report.pdf – Collection Letter

This causes two main issues:

1. User Experience – Users can't easily identify the document before opening it due to the generic naming convention.
2. System Conflict – When used in e-invoice XML files or exposed via access points, these non-unique names can result in duplicates issues.

Proposed Solution

To resolve this, we recommend:

• Updating the logic to follow the file name format defined in CBD or SSRS reports so that attachments have unique and descriptive names.
• Implementing a check to prevent duplicate attachments: if an attachment already exists for an invoice, the system should not recreate the same file when users reprint.

This enhancement would greatly improve document management, streamline user interaction, and avoid issues in systems that consume these attachments.