Dynamics 365 Finance

Problem:

Sales exempt from VAT (sales tax) that are incorrectly posted with a “purchase” tax direction instead of a “sales” tax direction are not included in the Norwegian VAT declaration. Therefore, the VAT declaration does not comply with the Norwegian VAT reporting requirements. The Norwegian Tax Administration (Skatteetaten) reconcile the reported VAT declaration with the reported SAF-T (Standard Audit File-Tax) file, and this reported problem results in a discrepancy.

Background:

Dynamics 365 FO determines the sales tax direction based on the account specified in the Account field. If the general ledger parameter "tax direction requirement" is set to "yes", the system validates that a tax direction is entered on a main account. This setup allows posting of sales exempt from VAT on accounts that are set up with a “purchase” tax direction. The result is that the transaction is posted with the correct sales tax code, but the sale is classified as a “purchase” tax transaction.

Mapping of the tax code to the VAT declaration allows both “sales” and “purchase” tax directions, so we expect the sale to be included in the VAT declaration. However, the VAT declaration only includes sales exempt from VAT that are posted with a “sales” tax direction and not those posted with a “purchase” tax direction. The result is incorrect reporting of sales exempt of VAT to the Norwegian Tax authorities.

Legal reference:

The legal reporting requirements in Norway stipulate that sales exempt from VAT must be reported for each account and in total. This is outlined in The Norwegian Bookkeeping Act (Bokføringsloven) Section 5, which specifies statutory financial reporting, and further detailed in the Norwegian Bookkeeping Regulations (Bokføringsforskriften) Section 3, specifically item 8.

Example:

A sale of NOK 10,000 is posted as a credit to main account 6730 and a debit to offset account 2999. The general ledger parameter "tax direction requirement" is set to "yes", and main account 6730 is configured with a “purchase” tax direction. The sale is recorded with sales tax code 6, which is set up for domestic sales exempt from VAT.

Due to this setup the sale is posted with a “purchase” tax direction and is therefore not included in the VAT reporting to the Norwegian government. In the event of a tax audit by the Norwegian Tax Administration (Skatteetaten), the VAT reporting would not reconcile with the SAF-T reporting (as emphasised earlier). This discrepancy could result in serious sanctions from the Norwegian authorities, according to the Norwegian Tax Administration Act (Skatteforvaltningsloven), Section 11-1.

Solution for solving the problem:

To ensure that Dynamics 365 FO complies with Norwegian laws and regulations, all sales reported with tax codes set up for sales must be included in the VAT declaration, regardless of the tax direction. Both sales posted with a “purchase” tax direction and a “sales” tax direction must be included.

Alternatively, the problem could be resolved by implementing an extended validation when posting the general journal to ensure that tax codes for sales exempt from VAT are not posted with a "purchase" tax direction.

Issue Description:

When creating a new Consolidated invoice for Japan, the runtime parameter for currency is fixed to JPY. As a result, consolidated invoices cannot be created for customers with foreign currency transactions (e.g., USD).

This issue occurs when the Japan Invoice support feature is enabled.

Request:

Please make the following improvements:

a. Enable the creation of Consolidated invoices for Japan regardless of the transaction currency.

b. Ensure that when a consumption tax discrepancy occurs, the adjustment entry (consumption tax transaction) is correctly created even for foreign currencies.

Issue Description:

When using the Post button on the Consolidated invoices for Japan page, a general journal entry is created and posted. However, the journal name used in this process cannot have approval and workflows configured. If such settings are applied, an error occurs when clicking Post button on the consolidated invoice page.

As a result, it is not possible to prevent a malicious user from using the journal name on the general journal page to post journal entries without any approval.

Request:

Please fix this so that malicious users cannot post journal entries using the posting function on Consolidated Invoices for Japan page without anyone's approval.

At present, the system supports configuring alerts at the individual batch job level, enabling notifications for job completion, failure, or cancellation. However, it lacks native functionality to set alerts at the batch group level. As a result, when dealing with batch groups containing hundreds of jobs, each job must be configured separately to enable alerts making the process time-consuming and inefficient. We're therefore exploring a solution that enables more streamlined monitoring and faster issue resolution.

Issue Context: In Dynamics 365 Finance and Operations (D365FO), when importing general journal lines using “Data Management” or “Excel Add-Ins,” it has been identified that the UUID field (CFDIUUID_MX) —required by Microsoft’s Mexican localization— is not available in the standard data entity General Journal Account Entry. Although this field exists in the journal lines interface, it is not exposed for mass import/export operations.

Operational Impact:

• Affects multiple Mexican companies.
• The absence of the field prevents compliance with Mexican fiscal requirements.

Key Findings:

• The UUID field appears in the journal lines screen for Mexican users but is not available in the data entity for import.
• The “Insert Columns” feature allows manual addition of the field, but this is not viable for bulk operations.
• It has been confirmed that the CFDIUUID_MX field is missing from both the import template and the field mapping in the entity.

Expected Outcome:

• Modify the General Journal Account Entry entity to include the UUID field (CFDIUUID_MX).
• Ensure it is available for both data import and export actions.
• Make the field visible in the Excel Add-In template by default.

The prepayment customer invoice feature should be improved by the following points:

• a parameter to predefine the posting profile for the posting of the payment from the customer
• a Workflow to automatically inform the responsible salesperson and delete active order holds after payment receipt
• after a partial invoice of the sales order, it should be possible to see the remaining amount as open on the customer transactions
• it should be possible to reverse the advance invoice (remaining amount) after a partial invoice

Issue Description

In the Project Management Accounting module, when generating a project invoice proposal, the foreign trade information specified in the related sales order—including the Intercom and Registration Number fields—is not being transferred. As a result, sales orders that contain foreign trade data fail to carry over this regulatory information during invoice proposal creation.

Expected Outcome

The system should automatically transfer the foreign trade information (Intercom and Registration Number fields) from the sales order to the project invoice proposal. This ensures compliance with SAT regulations (Mexican tax authority) and prevents invoice rejection during the stamping process.

Sometimes invoices for one customer/vendor can be posted with different posting profiles and in these cases also the revaluation accounts for these different profiles should be booked to different accounts. Currently Currency revaluation posting profiles can be setup for accounts receivable/payable on currency/account level but posting profile is not available.

Our suggestion is to include Posting profile as one option for setting up revaluation accounts.

O processo de integração entre o Dynamics F&O e o Webservice dos municípios que aderiram à plataforma NFS-e para atender a Reforma tributária

For better consistency and P&L (Profit and Loss) reporting, financial tags should be added to inventory adjustment transactions. This is particularly useful when a client wants to track P&L by a specific document number (e.g., a Booking ID).

While a financial dimension could also meet this need, it often negatively impacts system performance. Financial tags are a more ideal solution for tracking document numbers, but currently, they don't capture data for the Inventory adjustment transaction (Cost of Goods Sold (COGS).

Thanks