Dynamics 365 Finance

In the current standard code, the parameter Values used for summary account does not include the Sales order invoice.

The General ledger setup parameter is only geared towards transaction sources that utilize Source Document Framework. Sales orders are not yet utilizing Source Document Framework so that parameter is irrelevant for Sales orders and invoices.

The current documents that use this setup can be found in the GL Parameters form under the Batch transfer rules tab of GL parameters and look at the Source document type drop-down. 

Users would like to have the ability to view the accounting currency information on the purchase order and purchase order line prior to the receipt and invoicing process.

There is currently no way to view this information in the current standard code as the purchase table only tracks the transaction currency.

Hello Team,

I hope you are all doing well. I am reaching out to discuss an issue our customer is facing when trying to post some of their sales order transactions while the current period is on hold. Below, I have detailed the scenarios and the specific problem they are encountering.

Scenario 1:

When Period 1 is open (1/1/2025 to 1/26/2025) and Period 2 is on hold (1/27/2024 to 2/23/2025), the customer is unable to post the sales order transaction dated 1/15/2025. They receive an error message stating: "Posting sales order 37061698 voucher msi-10058419 fiscal period for 2/5/2025 not open. The fiscal period is closed for module sales order on the date 2/5/2025. Posting has been canceled."

Scenario 2:

When both Period 1 (1/1/2025 to 1/26/2025) and Period 2 (1/27/2024 to 2/23/2025) are open, the customer can post 80% of the sales order transactions dated 1/15/2025 without any errors. However, they are unable to post the remaining 20% of the sales orders due to the issue.

I have already reached out to the Product Group (PG) team for assistance. They suggested opening the period, changing the session date, and then posting the transactions. The customer followed this advice and was able to post some sales transactions, but they continue to experience issues with others. Upon further inquiry, the PG team mentioned that this behavior is by design. However, the customer disagrees and has escalated the issue.

Could you please provide us with the reason why the system is behaving this way? Your insights and guidance on this matter would be greatly appreciated.

Thank you.

Situation:

We create a new PO with budget checking. We set a deferral template, and this PO will apply it. When posting the PO Invoice, the invoice deferral tag is "Yes", and the deferral schedule will auto-generate for this PO invoice. However, the PO budget will be released at the same time. When we decide to recognize these deferral lines, the budget checking will be triggered again.

Error:

If we don't recognize the deferral schedule as soon as the PO invoiced, the released budget may be occupied by other procurement action. And we cannot see the records in budget control statistics table. It is unreasonable.

Requirements:

1. We hope budget control statistics table can have a column to show the budget used by "PO invoiced-deferral schedule-active".
2. Budget control statistics table should reserve the budget, do not allow it to be released for other procurement, after deferral generated.

Currently in D365F&O a Purchase Requisition submitted to the workflow can be edited by the Approver before approving the Purchase requisition. This behaviour increases the risk of a fraudulent transactions being processed especially if the approver can change the Vendor Account to be that of an employee vendor (e.g., those used for employee reimbursements') prior to approval. Items submitted to the workflow across the entire system should not be able to be edited by anyone unless it's recalled to DRAFT.

There are multiple petty cash expenses without taxes. Including non-taxable tax codes in the capture of these operations to ensure they are issued in the exógena1001 format requires an increase in manual work.

D365 F&O wants to compute withholding tax based on the invoice amount provided by the vendor for poland.(https://learn.microsoft.com/en-us/dynamics365/finance/general-ledger/withholding-tax-in-purchase-transactions)

If you didn't select any invoices, then also withholding tax on vendor payments wants to calculate for poland.

Standard Design:

Dynamics 365 Finance & Operations (D365 F&O) does not natively calculate withholding tax (WHT) without marked invoices lies in the way the system is designed. The standard functionality is built around the assumption that WHT is calculated based on specific invoice details.

The client needs the ability to merge customer accounts after transactions have been posted, which differs from the existing functionality in the Retail module, where merging is only allowed before transactions. Implementing this feature would require updating several customer-related tables, including Customer Invoice Journals, Sales Orders, Projects, and others.

Listed under AR but would also apply under AP

Often duplicate customers/suppliers are created in error in the same LE.

An automated merge function would be very useful. This would close one customer/supplier, transferring open transactions and ideally historic transactions to the other record which will be used going forward.

When trying to post cost invoice in invoice approval journal where are two project type of lines (credit and debit) and two different sales tax codes used (VAT25,5 and VAT0). Only the amount of VAT will be paid for the vendor. Posting will end up in error: Tax direction must be specified on ledger account . No specific ledger account is mentioned in the warning. VS debugger shows that validation try to find sales tax direction for "empty" ledger account. Posting will passthrough when GL Sales Tax parameter Tax direction requirement is switched off. All needed ledger accounts have tax direction. SingUp Software's ExFlow AP automation is used. Posting of approval journal is standard functionality. Tax direction validation in this case was working in version 10.0.36 but not anymore.