Ian Luu

Currently, in the Vendor payment journal, the Sales tax group is populated based on the default Sales tax group assigned to the Main account (in General ledger > Chart of accounts > Accounts > Main accounts > Legal entity overrides).

If the main account is not assigned a default Sales tax group, then this field will be cleared when the financial dimensions of the journal are modified.

It would be preferred if the system allows users to flexibly select the sales tax group without having to set the default main account sales tax group, and the manually selected sales tax group will not be cleared when the financial dimensions of the journal are modified. This would help save input time for different business scenarios, as not all scenarios require the same sales tax group.

Reproduction steps as follows:

1. Account Payable > Payment journal detail line account type select Ledger and select main account, financial dimensions.

2. Manually select the Sales tax group.

3. Adjust the financial dimensions.

4. The sales tax group gets cleared immediately.

Currently the accounting distribution is calculated by percentage even though users have an option to input the accounting distribution by exact amount. This is mentioned in public issue 967201.

This leads to the accounting distribution discrepancy when invoices are posted in different dates than the PO. This is not ideal as users tend not to review the invoice accounting distribution before posting.

System needs to have a mechanism to maintain the manually input accounting distributions throughout the PO process, regardless of whether the invoice posting date is changed.

Currently, when posting the packing slip for sales order that contains product bundle, the system only takes the main accounts associated with the item groups of the component items that are defined in the inventory posting profiles (Inventory management > Setup > Posting > Posting > Sales order).

The system should have an option to override the item groups of the component items with the item group of the parent item when posting sales order packing slip.

Currently, the system doesn't have an out of box option to automatically fetch and generate public holidays for various regions yearly. Users need to either manually add the public holidays one by one for each calendar over at Leave and absence > Setup > Calendars > Holidays and closures; or use the data management framework to import data entities (Work calendar holiday - HcmWorkCalendarHolidayEntity and Work calendar holiday line -HcmWorkCalendarHolidayLineEntity). These methods are time consuming and might be error prone.

It would be great if the system can have a feature to automatically fetch and generate public holidays for various regions yearly.

Currently, a vendor account can only have 1 currency, 1 payment method linked to 1 bank account.

In the invoice journal and payment journal, system currently defaults the currency from the vendor account master data.

There is actual scenario in which a vendor accepts payments in different currencies linked to different payment methods and bank accounts.

There should be an option to support this scenario, as manual changing the currency-payment method-bank account is time consuming and error prone.

In the current system design, when reversing general ledger vouchers, the JournalCategory of the reversal vouchers will be set to 0 (None) as per this bug https://fix.lcs.dynamics.com/Issue/Details?kb=4598493&bugId=532943&dbType=3&qc=baefeee4b954e605d477db7d875827d37956df172ba5b69c3c8c9486b9121e29

It would be helpful to appropriately set this value, as some customers rely on this value for custom reports/tracking

Currently, it seems the Invoice capture solution has yet to support Intercompany purchase order invoices, as mentioned on Yammer.

The error users will face when trying to transfer these invoices is: “The vendor invoice was generated with an error. The purchase order … for invoice … is an intercompany purchase order”.

Please consider adding support for Intercompany purchase order invoices as this is vital for many businesses

Currently the credit limit functions only consider the invoice account. Reference:

https://learn.microsoft. com/en-us/dynamics365/finance/accounts-receivable/customer-inv-account#other-fields-to-consider

In actual businesses, there're scenarios in which multiple customer accounts have their invoices charged to a single head office account. However, these are individual stores that are owned by franchisees, and the financial viability of these individual stores will vary.

The Head Office will allow most stores to order without checks but insist that authorization needs to be gained from them before new sales orders from specific customers in specific conditions can be confirmed.

In such scenario, the current system design is not feasible as the credit limit information of all stores are controlled by the head office account instead of their own customer accounts.

Please highly consider adding an option to let users select whether credit management should be checked against the main customer account, or the invoice account.

Currently the FO system only provides the Indonesia VAT Declaration in Excel format.

Reference: https://learn.microsoft. com/en-us/dynamics365/finance/localizations/indonesia/apac-idn-ppn-declaration#upload-electronic-reporting-configurations

However, from 2025, the Directorate General of Taxes of Indonesia requires the VAT Declaration in XML format instead of Excel.

The Directorate General of Taxes of Indonesia already provides the Excel to XML converters, but it seems not to cover the VAT Declaration yet.

Reference: https://www.pajak.go. id/id/reformdjp/coretax/template-xml-dan-converter-excel-ke-xml

Please produce the VAT Declaration Electronic reporting in XML format

Currently the Taxable Payments Annual Report for Australia retrieves all vendors from a vendor group for TPAR calculation and reporting.

However, there's the situation where some vendors, across certain legal entities, may change their business nature (e.g., providing both materials and services, or vice versa).

Therefore, it'll be helpful to have a vendor filter to exclude such vendors from vendor group when running Taxable Payments Annual Report.