Dynamics 365 Finance

When importing a customer payment file with file format Camt.054 to a customer payment journal it would be preferable if the payment status would be set to "Approved" on the payments that are fully settled against an invoice. Currently all payments get payment status "Received" regardless of finding an invoice match or if the payment amount is not correct. It would also be a nice feature to get an import report when the import of the payments has finished. This report should display which payments that were OK (i.e settled) and which payments that were not OK (ex not finding the invoice or wrong amount). A short description of why the settlement against an invoice failed shold be displayed on all lines that are not OK. Today most swedish customers are importing customer payments with the file format BGMax. When importing this format you both get a import report once the import is finished (displaying whats suggested above). Additionaly, payments that successfully settles against an invoice gets payment status approved while payments that do not settle (fully or at all) gets status received. This makes it easy to see which payments you need to take a look at and manually handle. However, this payment format (BGMax) will no longer be supported by the banks as of 2022, and the new recomendation will be to use the camt.054 format. Therefore many swedish customer will be effected by this and will most likely miss the functionality that comes with BGMax format that the camt.054 format does not support today.

Enabling user to choose the number sequence which will be used when depreciation adjustment are posted during split, disposal.

The ability to transfer leases between dimensions and legal entities. Leases for things like forklifts or trucks (and others) can be moved between warehouses/locations as well as to new legal entities. Similar to the one in Fixed Assets, but with the extra step to move it to a different legal entity. Clients may transition the same lease back and forth multiple times.

Right now, when a payment journal is created, you can click functions > generate payments in order to generate the payment file. Next to generating the payment file, post actions are done like updating the Payment status to "Sent". Since this is done in the same process, it can happen that the payment status is not updated while the file was actually generated due to a transient error (memory issue, database connection loss). We suggest to resolve this by creating a batch job that will create 2 runtime tasks: * 1 for actually creating the xml file and storing it * 1 for doing post processing (like updating payment status and direct debit mandates)

It would be nice to have a periodic task that allows us to send out the payment advice to vendors on a weekly basis. Presently we can configure the payment advice to be generated in batch, however, it is journal specific. Let us say we have created payment 10 payment journals for the current week and all the lines of these payment journals are in status sent. It would be nice to have a periodic batch job that enables us the selection of the payment journal and we can schedule the batch to have the payment advice generated for all the payment journals selected at once.

When you enable the feature "(Italy) Separate accounts for credit note" and you post an invoice from a return order the system is not using the account for the credit note but always the one for the revenues because at the creation of the return order the system populates the field “Main Account” in the Line details > Product with the main account used in the sales order (revenues) and uses that account at the posting. In order to use the account for the credit note you should delete manually the value in the field “Main Account” from each line of the return order. This is not an acceptable solution in case of orders with a lot of lines. At the moment of the creation of the return order, if the mentioned feature is enabled, the system should not fill in the account of the sales order in the "Main Account" field.

Include in the scope of the Brazilian location the calculation, calculation and tax assessment of the IPI Presumed according to 'Art. 227 of DECREE No. 7.212, OF JUNE 15, 2010'

The customer in Thailand has the fiscal requirement to maintain the Tax information based on Vendor\Customer address? These tax information are recorded in the Table: TaxInformation_TH. And the user need the ability to import\export those data for huge volume of customer\vendor records. Ideally this new data entity could be consider to include the table TaxInformation_TH, DIRPARTYLOCATION, VendTable and CustTable.

ISD or an Input Service Distributor is a type of taxpayer under GST who needs to distribute the GST input tax credits that pertain to its GSTIN to its units or branches having different GSTIN but registered under the same PAN. At present No option is available in D365 Finance for the same, However Microsoft Business central has this function. Moreover, the customer who use D365 Finance operate in multiple states & perform the IDS outside of D365. I do see partner have raise multiple request on the same & got declined by MS. I don't see any reason why partner need to vote & force MS to work on the same, instead should have been provided by default. I request MS to share the decline reason for the same, if its declined again.

It would be great, if we have option of selecting multiple withholding tax (TD's) for vendor.