Dynamics 365 Finance

user may receive information that fixed asset should be disposed after some times.

Depreciation have been posted and fiscal periods are closed for transaction.

Nonetheless fixed asset disposal should be considered on correct date even if posting date is different.

There is no way to differentiate posting date from disposal date.

example

Fixed asset depreciations have been run up to January 2023.

in January, user has information that fixed asset has been scrap in October 2022.

But periods are closed.

Fixed asset disposal should be posted in January 2023.

Depreciation for January 2023, December 2022, November and prorate October should be reversed.

Disposal amount should be calculated based on October date but posted in January.

System should be able to manage disposal date independently of posting date.

We have an issue with Document Routing Agent (DRA) and raised an MS ticket #2209050030001734

After research, as a conclusion MS engineer replied that there is some limitation with the product.

We request to develop DRA to be run as windows service without any issue.

Some countries used conditional tax.

Tax reversal with sales tax code for payment is generated during settlement process.

BUT no link exist between invoice and tax transactions.

Customers request a report to reconcile the tax ledger account and be able to link tax to initial invoice.

No such report provide good information.

Payment amounts from the Payment Schedule in Asset Leasing should be included in the Cash flow forecast. Currently, even though the information about Asset Leasing payments is available in the system, it is not considered in the Cash flow forecast. This way, there is no complete picture of cash flows.

In blue is the record starting at 20, when we have an Adjustment code with related subitems (in red) it’s necessary to create the records CR=25, CR=26, CR=27 and CR=28.

010120200602130634000002100001

051132565061176031681700010300000000120200600000001100000000000000000000000000000006031681700010300000000000000000000000000000000000000000000000000000000000100000000

20002190000000006266490                                                                                                                                                                                                                                                                                            0000000000000000

Main Accounts linked to the Asset Leasing Module should be able to be locked through the "Do not allow manual entry" feature (General ledger > Chart of accounts > Accounts > Main accounts > General > ADMINISTRATION).

These are control accounts and should be locked from manual entry to prevent accidental postings from outside the Asset Leasing module. 

In the current design, with the mentioned feature enabled, the system throws a warning when posting several types of transactions, including depreciation. This warning makes the system post the voucher transactions to the “999999” Error Account instead of to the account set in Asset Leasing Parameters. The manual workaround of disabling "Do not allow manual entry" and using Posting validation to specific users is not feasible in some scenarios.

For all other modules, including fixed assets which is closely related to the asset lease module, if a control account is in use, then the posting is made to a locked account via a system/module posting. Thus, if this is a control account to which the sub-ledger should reconcile, the approach is showing an inconsistent behavior, not following standard accounting needs/processes.

Request:

We hear from more and more Customers their requests regarding the process in FA management:

1. Perform the periodic stocktaking of Fixed Assets (preferably with the barcode/RFID usage).
2. System should allow running partial stocktaking (ie. chosen group of FA).
3. Automatic generation of documents for stocktaking settlement, such as: stocktaking sheet, differences list, stocktaking summary.
4. System should allow an automatic posting of this transaction after a simple, easy to configure approval workflow.

Reasons:

1. Speed up the obligatory periodic process of Fixed Assets stacktaking, in case there is a huge volume of FA (>1 000 000 active FA's).
2. Keep the list of FA's in D365 being the exact projection of the real situation with the all the FA's used in the Organization.

Current Issue:

In D365, we are unable to book an overdelivery for purchase orders with two-way matching categories. When attempting this, we receive the following error:

"The line has quantity XXXX and total delivery of YYYY. This results in Z percent overdelivery of the line. The line only allows overdelivery of 0.00 percent. You can adjust this on the order line."

Workaround:

The only workaround is to manually add an overdelivery percentage to the PO line. However, this requires extra effort for each PO, making it inefficient.

System Limitation:

In Accounts Payable parameters > Invoice validations > Price and quantity matching, we can choose either three-way matching or two-way matching, but not both at the same time. This is a known D365 limitation.

Expectation:

We require a separate parameter for two-way matching categories that works on a net amount basis. For these categories, the unit price is entered in the quantity field and the quantity is entered in the unit price field. However, the system currently only validates the unit price when two-way matching is set in the AP parameter. This needs to be adjusted so that it validates correctly for two-way matching categories.

If a main account is used in a posting setup in a module it would be great if information on where the account have been used could be found directly on the main account.

This would easily provide users with information if an account is used in posting setups in more than one module that potentially could create differences.

In the header section of the Purchase Order invoice within Finance and Operations (FnO), there is a Purchase Order drop-down field that enables users to select a single Purchase Order (PO).

Many organizations rely on this field containing a PO number as a condition within their invoice posting workflows. Specifically:

• If the Purchase Order field is left empty, the invoice is treated as a non-PO invoice.
• If the field contains a PO number, the invoice is processed as a PO invoice.

Currently, the system does not support the scenario where an invoice—transferred from Invoice Capture—is associated with multiple POs. In such cases, the Purchase Order drop-down field in FnO remains unpopulated, as no PO number is applied automatically.

This gap in logic presents a challenge for organizations attempting to automate PO invoice posting via workflow, as the absence of a PO number in the field prevents the system from correctly identifying the invoice type.

Proposed Design Enhancement:

To align with the manual process in FnO, the system should populate the Purchase Order drop-down with one of the associated POs—preferably the first PO in the sequence—when a multi-PO invoice is transferred from Invoice Capture. This approach reflects current user behavior during manual entry, where the first PO added to an invoice is automatically set in the drop-down field.

Implementing this enhancement will enable businesses to maintain workflow automation for PO invoices, even in multi-PO scenarios.