-
Item Tax Groups per Country per Released Product
Increasingly, companies with a web presence, selling products to customers in multiple countries are required to collect GST/VAT/C-Tax (name your term) on behalf of the destination country. For the most part, the Tax module in D365 is flexible enough to supports this. However, one gap we have encountered working with a few of our clients, relates to the tax treatment of different products in different countries. As an example, in Australia sunscreen is tax-free, whereas in New Zealand it is taxable. If we are selling sunscreen to customers in both countries from the same legal entity, this means we would need to create two products, with different default item tax groups. This becomes a headache when dealing with thousands of SKUs. To me, the ideal solution seems to be have sales country overrides on released products. We could supplement the current default sales Item tax group field, with a separate table to store customer-country-specific defaults where required. When a sales order line is created, if an item tax group exists for the customer's country, use that, otherwise copy the usual default to the sales line. All standard logic would apply after that. -
Remove purchase prepayment in previous financial year
Currently it is not possible to remove a prepayment created in a previous financial year. It would be ideal it was possible to either default the reversal to the next open period, as per other areas of the system; or to give the user the option to nominate the reversal date. -
Date format in Embedded Power BI
One of the first things people notice when seeing an application for the first time, is that dates are in the wrong format for their region. In D365 FSC, this issue is avoided by setting the Date, time, number format according to the user's region. However, this does not flow through to embedded Power BI, and currently the only way to address this is to make a change per report, which is not ideal for companies that operate in multiple countries. It would be great if this could be addressed in the future. -
Ledger Allocations - Basis calculation
When defining ledger allocation rules, we get the option to specify whether to use the period movement or the closing balance of the source account. It would be good if we could do the same for the account used in the basis e.g. use the current period movement when the basis is a P&L account such as sales; but use the closing balance when referencing a statistical account such as Head Count. -
Allocation Terms and Budget Control
Allocation terms (defined against the main account) are a great feature, as they post in real time with the original transaction. However, when using budget control, they don't work in all areas of the system. For example, I've found that while they work for sales order posting, they don't work when posting free text invoices. Ideally, even when budget control is activated, allocation terms should work in all areas of the application. -
Rebate management deals - Grouped customer sales for rebate eligibility
It would be great if it was possible to have a group of customers, for whom sales are summed for the purposes of eligibility for a given rebate percentage, while configuring the posting profile such that the rebates are paid/credited to each customer based on their portion of the total sales figure. From my testing, it seems that this is not possible. While sales are summed where a customer rebate management group is selected on the deal, on the selected posting profile, we must select fixed account and specify a single customer/vendor. This only works where the rebate amount is to be remitted/credited to a single customer. -
Rebate management deals - Accrue based on forecast rather than actuals
It would be great if there was a way to base rebate management deal provisions on a forecast, rather than actuals? The scenario we have is a rebate agreement whereby the customer is eligible for a 1% rebate on sales up to $1m, 2% for $1m to $2.5m and 3% for $2.5m to $3.5m. We forecast that they exceed $3m, but most likely not until later in the year. This means that the accrual is not accurate for most of the year, until they reach the top percentage later in the year. -
Task guides not appearing in help menu
Where a task recording is uploaded to the client's BPM but the form name doesn't match the menu item, the recording doesn't appear in the list of task guides when you access help from the form the recording relates to. Clients love task recordings and the ability to access them from the help menu, however when they don't appear, users don't know to look for them. It would be great if this could be addressed by Microsoft. -
Vendor Payment Journal Workflow Approval and Entering spot Rates
Many companies choose to implement vendor payment journal approval workflow. The key difference between this and other workflows is that instead of involving approval before posting, it is designed to require approval before generating the payment file. Once the workflow is approved, the 'Generate payment' button becomes active and the journal is no longer editable. The user then generates the file to send to the bank. This all works well for all payment types, except foreign currency transfers.
The problem with forex transfers is that the bank usually provides the spot rate after the file is sent, meaning that the user then needs to edit the payment journal to enter the rate and then submit for approval again.
It would be good if we could provide the option to enter the rate for an approved journal, without letting them edit anything else, and without having to submit to approval again.
-
Vendor Bank Account Validation
It would be good to see improved validation around vendor bank account details, particularly the account and routing numbers.
There are two main areas where this could be addressed. The first is at the point of creating or editing the vendor bank account. This would need to be configurable, as the right validation will depend on the bank the company is paying from, but this is the best point at which to catch errors such as existence or lack of special characters or numbers that are too short or long.
The next point at which to implement further validation is in the electronic reporting payment configuration. For example, the maximum field length for an account number in the payment configuration is 9 characters, but the user has entered the account number with a space, meaning that it is 10 characters. Some of the standard configurations, such as CBA Direct Credit Service (AU), simply truncate the number, meaning you finish up with the wrong account number without knowing it. It should return an error instead.
You’re offline. This is a read only version of the page.
