Dynamics 365 Finance

Current behavior

In the current system design, when fixed asset is acquired through purchase order, the posting of product receipt only generates the fixed asset with book status 'Not yet acquired', with no Fixed asset subledger acquisition transaction. On the General ledger side, there are Debit transactions posted to the main account.

Only when the purchase order invoice is posted will the Fixed asset book status change to 'Open', and an acquisition transaction is generated in the subledger.

This causes FA subledger - ledger discrepancy during the time gap between product receipt posting and invoice posting.

System design change request:

System should provide an option to acquire the fixed asset right when the product receipt is posted.

In PPAC currently when we want to copy our DB from one environment to another (such as a UDE) we have the option for transactionless (default) or to include all transactions. For us this is the difference between around 200GB DB and 800GB DB. We require to have some transactions in our UDE for our developers to work with, but we don't require all. We would like a third option - something like 'Reduced Transaction Copy' that copies only the past year's worth of transactions, as this would provide the transactions that our developers require without pulling over everything. It would likely reduce our DB to around 300GB to 400GB.

Globalization studio enables us to set up tax calculation rules. With those rules, we can for example change the sales tax group based on certain conditions.

However, when creating a new sales order, the rule will only be executed, after pressing the Sales Tax button, manually. This makes the process more complicated and manual, especially if sales invoices are posted via a batch run.

Therefore, I suggest to trigger the execution of the tax calculation rule when posting the sales invoice, automatically.

With Credit management, we have a possiblity to have total credit limit created by credit limit, temporary credit limits and Insurance and Guarantees. With this, if using mostly Insurance and guarantees, we do not see the right numbers in Reports as Customer balance with credit limit or when using Workspace Customer credit and collection.

Those parts of the system still uses the column credit limit and not the column total credit limit.

It would be great, if those overviews can actually show all the fields from customers.

Issue:

• In flows like PR > PO and RFQCase > RFQ, attachments are copied using the standard Docu framework (Docu::copyDocumentAttachments), which includes an extensibility point via the OnCopy delegate.
• However, during the Journal creation flow (FormLetterJournalPost.Post()), the attachment copy process follows a different path (copyDocuRefTable() → docuRefCopy() → docuRefCopyByRecId()), which does not leverage the Docu framework and lacks extensibility.

Proposals:

• Rework the Journal posting code to use the Docu framework.
• Or introduce a delegate to the current Journal posting attachment copy flow to allow for customization.

It should be possible to view accounting entries (vouchers) on the bank reconciliation worksheet screen.

Today, it is necessary to go to other tables and manually search for the corresponding voucher, which consumes a lot of time for accountants.

In the control tab at the top of the bank reconciliation worksheet screen, the difference between what has been selected should be displayed; this would make it easier to identify the other amounts to be reconciled.

At this moment, we can only see the total amount selected, not the difference.

We have a case where charges are added prior invoicing PO and seems that when 'Generate Charges on Product Receipt' is turned on under Procurement and Sourcing Parameters > Delivery, there are no entries being generated to Purchase Stock Variation and Purchase Expenditure for Product on either Product Receipt voucher and Vendor Invoice.

But when charges are added after invoicing PO as an adjustment, entries to above mentioned posting types were generated. This makes the accounts understated because of the inconsistencies. (CHARGES SETUP --- Dr. Item, Cr. Vendor Account or ledger Account)

A ticket has been raised with MS and suggested to turn of the 'Generate Charges on Product Receipt' and both now have the same entries whether charges are existing prior invoice posting and after invoice posting as an adjustment. (CHARGES SETUP --- Dr. Item, Cr. Ledger Account)

We think there's a bug on the 'Generate Charges on Product Receipt' as charges were not being accounted for properly when it is turned on. This leads to understated account balances

There are too many criteria to reconcile banking transactions, which cancel each other out.

We need to be able to reconcile bank transactions that cancel each other out, including summarized transactions (by payment reference, for example). At this moment, D365 allows to reconcile only the "Others" document type.

And not to have so many matching criteria (same payment references, same transaction type, same document type).

Once we configure electronic invoicing for Malaysia or other eligible country regions following the regulatory guidelines, the out of the box 'Electronic document submission log' UI experience helps tracking communication results for individually submitted AR/ AP retail invoices to tax portal or batch submissions for AR invoices related to customer accounts sharing the general public TIN number 'EI000000000010'.

Once the retail invoices are batch submitted, currently there's no efficient UI experience to trace individual invoices those were part of the batch submission. As of now, we can validate the individual invoices associated with the batch submission instance only by referring to the output submission file or by navigating to the batch submission instance in tax portal experience. 

In the 'Electronic document submission log' view Microsoft has provided an out of the box view as 'Batch submission invoices' to trace the individual invoice documents reported but that option is limited for commerce invoices only.

It'll be extremely beneficial if the 'Batch submission invoices' can be purposed for retail invoices too so that business users can easily track the individual invoices reported against batch submission. This also becomes crucial for batch submission scenarios as for batch submission, the QR code or UUID gets assigned to the whole batch and we can't track these details against the posted invoice journal documents upon reporting.