The documentation suggests there are no limitations when setting up party relationship types:

https://learn.microsoft.com/en-us/dynamics365/finance/accounts-receivable/location-relationship

However, some relationship types are not supported and will result in unexpected errors. I consider this a bug, but PG team claims this is an (undocumented) feature, see support case 2412191420001753.

Ideally this bug should be fixed, alternatively the behaviour should be documented in the documentation (which essentially comes down to documenting the bug as a feature).

At https://learn.microsoft.com/en-us/dynamics365/finance/localizations/italy/emea-ita-competence-date is stated that "On the General ledger parameters page, on the Ledger tab, set the Transaction date reference to competence date option to Yes. After the competence date functionality is turned on, you can specify Transaction date as an acknowledgment date for each journal that can be used to post the adjustment and closing transactions for the fiscal year:".

Despite the checkbox is turned off the Transaction date (AcknowledgementDate) is automatically populated and can be manually adjusted.

At the same link is also stated that "you can specify Transaction date as an acknowledgment date for each journal that can be used to post the adjustment and closing transactions for the fiscal year:

General journal (General ledger_Journal entries_General journals), Fixed assets journal (Fixed assets_Journal entries_Fixed assets journal), Bank account reconciliation (Cash and bank management_Bank accounts_Bank accounts_Reconcile_Account reconciliation), Closing period adjustments (General ledger_Period close_Closing period adjustments), Year-end close (General ledger_Period close_Year end close_Run fiscal close), Project – Post costs (Project management and accounting_Periodic_Time and Material_Post Costs_Post), Project – Accrue revenue (Project management and accounting_Periodic_Time and material_Accrue revenue), Project – Estimate post (Project management and accounting_Periodic_Estimates_Post estimates), Project – Estimate reverse (Project management and accounting_Periodic_Estimates_Reverse estimates)" but the Transaction date (AcknowledgementDate) is automatically populated and can be manually adjusted also when it comes to vendor invoices for example.

Expected results: We should not be able to use the functionality without enabling “Transaction date reference to competence date option to yes”. And use this on accounts payable as this is not listed on document.

Title: Issue with Purchase Order Linked to Project

Description

When a purchase order is created and linked to a project, please ensure the following steps are completed before proceeding:

1. Set up the "Create Item Requirement" option.
2. Create the TM project, which will be linked to the purchase order.

Once the purchase order is linked to the project and posted, navigate to the project page, and under the item requirement section, attempt to invoice the sales order (item requirement). However, the item does not get stamped, resulting in a "rejected" status and displaying the error message below.

Additionally, the XML generated does not include the fields "ClaveProdserv" and "ClaveUnidad," which are required.

Resultado Descripcion="El campo ClaveUnidad no contiene un valor del catálogo c_ClaveUnidad." IdRespuesta="CFDI40165" Detalle="CFDI40_0065_ValidaConcepto_ClaveUnidad" FullError="<Errores>  <Error>    <Codigo>CFDI40165</Codigo>    <Mensaje>El campo ClaveUnidad no contiene un valor del catálogo c_ClaveUnidad.</Mensaje>    <Detalle>CFDI40_0065_ValidaConcepto_ClaveUnidad</Detalle>    <MensajeParaCliente>El atributo 'ClaveUnidad' es requerido y no puede ser vacío o nulo, para el concepto con ClaveProdServ ''.</MensajeParaCliente>  </Error>  <Error>    <Codigo>CFDI40158</Codigo>    <Mensaje>La clave del campo RegimenFiscalR debe corresponder con el tipo de persona (física o moral).</Mensaje>    <Detalle>CFDI40_0058_ValidaReceptor_RegimenFiscalReceptor</Detalle>    <MensajeParaCliente>La clave del campo RegimenFiscalR debe corresponder con el tipo de persona (física o moral).</MensajeParaCliente>  </Error>  <Error>    <Codigo>CFDI40162</Codigo>    <Mensaje>El campo ClaveProdServ, no contiene un valor del catálogo c_ClaveProdServ.</Mensaje>    <Detalle>CFDI40_0062_ValidaConcepto_ClaveProdServ</Detalle>    <MensajeParaCliente>El campo ClaveProdServ, no contiene un valor del catálogo c_ClaveProdServ.</MensajeParaCliente>  </Error> </Errores>" />

Actual Outcome: The CFDI is not including the information in the "ClaveProdserv" and "ClaveUnidad" fields.

Expected Outcome: Since the "ClaveProdserv" and "ClaveUnidad" information is provided for the sales order (required items) in question, once posted on the project page, the CFDI should be approved instead of "rejected." Furthermore, the XML should include the information for the "ClaveProdserv" and "ClaveUnidad" fields as defined in the system.

As of January 1, 2022, the “TicketBAI” system has become mandatory in the Basque region of Spain. “TicketBAI” is a legal requirement aimed at combating tax fraud by ensuring that all business transactions are recorded and reported to the tax authorities in real-time. This system applies to all businesses operating within the Basque region, regardless of their size or industry.

Businesses in the Basque region must comply with “TicketBAI” to avoid penalties and legal issues. By integrating “TicketBAI” support into Microsoft Dynamics 365 Finance and Supply Chain Management, Microsoft can help its customers meet these legal requirements seamlessly.

As Spanish goverment has announced, it will probably be also implemented in the rest of the Spanish territory.

On the header of an intercompany journal, the description always defaults to the description of the intercompany journal in the 'Journal names' screen e.g. 'Intercompany Journal' in our scenario.

It would be really useful for us to be able to use this field to give a better description of what the intercompany journal was raised for in the new legal entity e.g. if it could take the description from the general journal header that was raised in the first legal entity to create the intercompany transaction.

Thanks

Since we nowadays almost every project migrate data from one instance to another via data management or we copy data from one legal entity to another legal entity via copy to legal entity function in data management. It would be great if newly added fields were also mapped in data entities, for example field "GLStatementByMainAccountFormat", which is prerequisite for smooth data migration.

The problem is not once upon a time manually migrate this field, the problem is when you need to migrate 200+ legal entities, and you have to do it 200 times manually. I do not have to write about not existing time efficiency + space for mistakes the problem produces, right?

To calculate a planned cost, we need to override the the exchange rate or choose another type of exchange rate. By default the last exchange rate of the company is used in the calculation but we need to use the exchange rate of our budget.

After adjusting a lease via the lease adjustment wizard, the lease end date should update in the lease details page. Currently only updates in the book.

Can we be alerted when the Financial Reporting  MRDB and AXDB gets out of sync?

Business Justification:

We are continuing to experience issues with the FR - accounting is having to check data in FR every time FR reports are refreshed before certifying the report for consumption. We reported this in case 2312040040006743 - we know that there is a known issue that can occur when MRDB and AXDB get out of sync. We also know how to fix it - by resetting the datamart

How can we trust the data in the FR due to this issue? Checking FR report every time they are generated is not practical.

Per an Idea suggested in April 2022 - the Product team was focusing on "eliminating the need for data mart resets".

Does not look like this has made any progress. Hence the need for system help .This issue with FR is eroding confidence in FR reporting & has raised the risk of inaccurate financial reporting for our organization.

Business process/setup

Company is based in UK but this might occur in different entities location

Company use Date of VAT register global feature: Tax point date (Date of VAT register) - Finance | Dynamics 365 | Microsoft Learn

Company run ‘settle and post” based on Date of VAT register

Company post vendor invoices with the automatic fill of Date of VAT register as document date

Due to the delay in receiving invoices there might be documents that are posted in current month but with date of vat register in one of previous periods, example, Posting date: 10/30/2023, Date of VAT register (document date) 15/07/2023

Till the document is posted in the system ‘settle and post sales taxes” has been run for all previous periods – original and as well correction. 

User do not want to run ‘settle and post’ for each month, but identify all transactions that has not been included in settlement, change the Date of VAT register to current period and include in last declaration. 

NOTE: Running ‘settle and post” for each previous month is time consuming, not efficient and require to submit corrections for all periods to Tax Office.

Issues

Issue 1: Not easy to find what transactions have not been included in any of previous ‘settle and post sales taxes and find all that has not been included. 

Issue 2: Not able to find out from where the difference is coming on VAT account if we check Trial Balance, Accounting source explorer. 

Current way of control

Right now, user must run 2/3 (sales tax list, sales tax transactions) reports and filter transactions on “Maintain VAT register transactions” to identify the transactions and discrepancies.

Go voucher by voucher to check if it was included in ‘settle and post”

Note, that we can only count on the “version” on the sales tax transactions/Maintain VAT register transactions which is not sufficient, because in each previous period ‘settle and post’ could be run several time (original and latest corrections), so the version for each month will be different and we cannot use this for filtering. 

There is no other information about if and where the sales tax transaction ahs been included in ‘settle and post” periodic task. 

Possible improvements: 

Possible improvements that will help to reconcile ledger and sales tx sub ledger and also identify transactions that has been posted after the ‘settle and post”

1. Create 2 new columns in table — VAT Settlement Voucher and VAT Settlement Date. 

2. Populate data to 2 new columns When using Settle and post sales tax process into TaxTrans. 

3. Add these 2 new columns to posted Sales Tax, Maintain VAT Register Transactions and Voucher Transactions. 

4. Add Date of VAT Register to Accounting Source Explorer, Ledger Settlements and Voucher transactions. 

5. Add Document Date to Maintain VAT Register Transactions 

6. Block functionality to change Date Of VAT Register after Settle and post sales tax was done 

(VAT Settlement Voucher column is filled) in Maintain VAT Register transactions.