Dynamics 365 Finance

When I run the report "Role to user assignment" there is no possibility to apply a filter with table joins. These would be necessary to filter a list of certain roles (typical business case: who has been granted sysadmin, etc.). Obviously the report is a ammended copy of the "User role assignments" report, where the reporting scope is the other way around (Which role is granted to which user?).

However, although the appearance of the two reports is different, the primary table for applying filters is still the same. If the primary table for applying filters would be changed to the security role table, you wouldnt even need to create a join to apply a typical filter like a certain role name.

Of course there are many other ways of finding out role to user assignments, but from an auditing point of view it is better to have a system built-in ready-to-share report, which works and only produces the amount of paper/pages, which is actually necessary.

External reporting tools are fine but always need to be set up and verified. Especially when dealing with critical information.

The reason code that is set on a transaction when putting this transaction on disputed should not be removed when doing a (partial) payment for this transaction. The partial payment does not mean that the dispute has been resolved (as is also doesn't trigger the removal of the dispute status on the transaction). It might just be an agreement between the 2 parties that part of the invoice that is not be disputed should be paid while the disputed part is under investigation. By removing it, it becomes more difficult to have a clear overview of why certain transactions are in the disputed status and which actions need to be taken to get them resolved.

Select "JBA(JP) - Format A" for "Import format" in "Methods of payment".

Specify any string for "Document" in the "Journal names" setting.

After selecting the "Journal names" created in the Journal in "Customer payment journal" and importing the JBA format file in "Import payments", the "Document" field in the imported line is Blank.

The string value set in “Document” in the "Journal names" screen is not retained.

Since the "Document" field value is retained when creating records using the "New" button or when using the payment proposal, the same behavior is expected when creating records through payment import — the "Document" field should also be carried over.

Regards,

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.