Dynamics 365 Finance

Please add the MACRS depreciation method. The reducing balance methods do not switch to SLRB automatically and it's unreasonable to think that someone managing an enterprise system full of thousands of assets is going to monitor this manually.

This is a feature in products such as D365 BC for small and med size businesses already (https://learn.microsoft.com/en-us/previous-versions/troubleshoot/dynamics/nav/how-to-set-up-modified-accelerated-cost-recovery-system-depreciation).

Capitalization of an Investment Project in D365 happens on a one to one realtionship. This means that the project can be capitalized in a single Fixed asset, meanwhile there are a lot of scenarios when the capitalization is needed to be done in several other assets.

There should be the option to capitalize a project in more than one Fixed assets and be able to have the option to capitalize this sum in percantage, Fiexd amount, etc. to the Fixed asset selected.

If the 'Adjust invoice posting date' parameter is set to either 'Change posting date to first day of new period when posting date period is closed or on hold' or 'Change posting date to system date when posting date period is closed or on hold', and the Purchasing module is closed in the Ledger calendar but Vendor module is open, the system will move the posting date up according to the parameter. It shouldn't do this, the Purchasing module isn't required to post a vendor invoice journal, only the Vendor module. If the parameter is then set to 'No change', it will post without error. The parameter should be updated to not adjust the posting date in this scenario.

In previous versions when D365 was called Dynamics AX and on prem we had the ability when architecting the solution to have user, batch, and integration AOS'. This allowed us to separate out specific workloads to not only ensure performance but also reliability (such as a user process not crashing an AOS that runs integrations).

We would like to see Microsoft add the ability to dedicate AOS' for integrations so that we can ensure that business critical integrations are not impacted by user or batch processes that are not performant or crash a system. This would also allow us to ensure that integrations that have high resource needs are not impacting user interactions and batch processes on the AOS (acknowledging that there is still SQL impact that is not addressed by this enhancement). Note that while the priority based batch feature is helpful in certain circumstances it does not address all scenarios.

I suspect this would come with a need to license this type of AOS and accept that (in 2012 and previous versions we would get additional aos licenses to handle the batch and/or integration load).

Colombia companies must issue a "Vendir Equivalent document" for certain vendors that meets requirements and it is not mandatory to issue an invoice.

https://www.dian.gov.co/impuestos/Paginas/Sistema-de-Factura-Electronica/Documento-Soporte-Adquisiciones-No-Obligados.aspx

The suggestion is MS to develop the criteria when a vendor is setup, also controls the total amount per transaction per vendor and also develop the report to be rpintes from PO invoice, Vendor Invoice Journal and General Ledger Journal.

Change the financial dimension on a pending vendor invoice that is created via import, should not have the unit price deleted, as changing a dimension should not affect the price. If the pending vendor invoice is created manually the unit price is not deleted.

This was reported as a bug but will not be changed by MS:

Microsoft has evaluated this request and will not be pursuing a fix for this issue as this will bring quite a lot of effort to fix it. In the meantime, it has a high risk of affecting the existing functions.

Before we spend the effort on fixing it, we'd like to gather more feedback and see how many customers have been impacted by this problem first.

Vendor V2 entity exports only Primary contact details. Customers need to export all the contact details, not only primary details. There is no other table that contains such information and can be filter per entity, and there is no way around it so far. Such change would be very convenient for plenty of customers in the future.

We propose changing how the vendor balance list is generated to better reflect scenarios in which certain vendors have transactions pending approval, so it would actually take into consideration said transactions when showing the balance.

As the functionality currently stands, at the time of generating the vendor balance list, if we don't change the criteria to group and sort the results, the balance list will include all transactions corresponding to the vendor. This results in eschewed amounts in environment configurations that involve transaction approvals via a separate account and do not reflect the factual amounts transacted with the vendor.

If we change the criteria to group and sort by main account, the system shows both the transaction pending approval and the actual payable account separately, this results in more accurate amounts in the sense that the results do reflect the right amounts transacted with the vendor except in scenarios in which there are transactions pending approval, as these aren't taken into consideration when generating the vendor balance list.

While it's true that transactions not yet approved don't need to be added to the actual vendor balance (until approved, that is) these need to be taken into consideration while generating this list.

We propose making the option to only generate the balance list based on vendor transactions (vendtrans) When group by vendor is selected. That way the balances will be correct in the scenarios described above.

In an environment where there are several legal entities, across various countries, all of which need to execute reporting configurations that rely on the same data model and definition (Standard Audit File as an example), the need to constantly select a default model mapping configuration is creating an issue for users. As it stands, the users need to be given access to the Electronic reporting workspace, update the Default for model mapping flag, ensuring that they are not affecting a process another user is performing, and execute their report. The Default for model mapping constantly needs to be changed.

It should be possible in D365 to select a model mapping to use at runtime, or alternatively reference the model mapping to be used in the header of a format configuration.

There needs to be a solution for this problem.

Para os eventos R-4010 e R-4020 referente ao pagamento da variação cambial ao fornecedor externo que não emitem nota fiscal.

O fornecedor envia um informe de rendimentos referente a estes pagamentos ao cliente, atualmente o Cliente cria um diário de fatura do fornecedor para efetuar o pagamento, e inclui as outras informações referente diretamente no arquivo da DIRF anual.

Agora estas informações deverão ser enviadas através dos blocos R-4000 do SPED REINF preenchendo a tag.   

Aos campos correspondentes no Diário Geral da Contabilidade ou de Fatura do fornecedor, o Dynamics 365 F&O preencherá as tags correspondentes a informação do pagamento do fornecedor exterior para os eventos R4010 e R4020