Dynamics 365 Finance

Currently if a customer has multiple bill to addresses (purpose = Invoice), user can select the secondary invoice address on Free text invoice header. However, this capability is not available on the Sales order header. The work around is to update the default invoice address on the customer record temporarily, generate the sales order invoice that needs to be billed to the secondary invoice address, and return to the customer record to update the default invoice address back to the primary one. This work around will not be feasible if there's high volume of invoice that needs secondary bill to address.

Italian Bollo stamp duty is required on invoices where the subtotal of the lines without VAT exceeds 77,74 EUR.

If the requirement is met, Bollo charge is applied only once per invoice document, the charge is fixed, set to 2 EUR.

Standard solution is to manually validate all Sales orders to verify if the requirement for bollo stamp duty is met and apply the auto charge into the sales order before invoicing.

Ideally there should be a setup for Bollo in auto charges, where the sum of total invoice lines for certain items with VAT exempt were calculated and added automatically when using the “tired charges” in a Sales order, if conditions were met.

Potentially this could be done by adding the Items to a specific Item charge group and enabling the option also from the Auto charge header view, instead of only the line view. Additionally, there must be a calculation for subtotal of all invoice lines which contains items from this item charge group, so bollo charge is only applied once per invoice. The threshold amount EUR 77.74 must still be validated against the subtotals of invoice lines from the item charge group, to meet the requirements.

Manage personalizations at the organization level with views - A small suggestion for improvement to published views

We would like to publish and pin the view per menu item but unfortunately whenever menu items are sharing the same table, the published views will overide themself.

E. g. creating a saved view in the invoice approval and publishing it leads to default view of this view also in fixed assets and general journal (all of them are sharing the LedgerJournalTable). The problem is, however, that each menu item requires different views with a different structure of information and column layout and that it is very confusing if the general ledger displays a separate view from the accounts payable module by default and vice versa.

It should be possible to publish 1 view per menu item. Every menu item has its own requirements and structure. So we suggest that the published views be linked to the menu items or the corresponding work masks instead oft he table.

Then there should be no more unwanted overlaps between the different published views showing all data from the same table. And as a small side effect, one could read MS's handouts on published views with more serenity.

In the month end closing process, when closing application modules separately there is an option to close the "project" module.

This will block any entries on the project subledger for that period. This will block both the registration of revenue transactions (new project invoices) and the registration of cost transactions (hour, item and expense transactions).

This closing is perceived as being too strict by our customers and is also not in line with the closing of other modules.

Our proposal is to either align the closing of the project subledger with the closing of the other subledgers or split the closing of the project modules into at least 2 domains: revenue & cost.

The end result of this request is providing the possibility to close the revenue side of a project in a period while still allowing to make cost entries: allow to enter expenses, hours and item consumption on a project while the generation of new project invoices is not allowed for that period.

--> Typically the customer ledger is closed in the first days of the new period while the vendor subledger and expense subledger is still open.

Below an example of a scenario that is categorised as intended behaviour but is perceived as a bug by customers:

• Customer subledger closed
• Project subledger open

When you try to create a new customer transaction via the account receivable module that is not allowed. (customer is closed) However, when you create a new customer transaction via the project module that is allowed.

In the above scenario you would expect that closing the customer module means:

• no entries are allowed in the customer subledger.
• With the current functionality this means: no entries are allowed from module X but entries are allowed from module Y

To achieve the scenario where new entries of all types of customer transactions are blocked in a period (and allow cost transactions on a project) the current 'customer' application module closing should be adjusted or a new application module 'project revenue' is required.

Ref. TrackingID#2303310010000933 regarding the parameter "Safety level of invoiced orders" on Accounts receivable parameters - Updates. When selecting "Locked", you are not able to delete invoiced lines. However, you are not able to create credit notes on invoiced sales orders either. Therefore, the suggestion is to expand the possible alternatives to select for this parameter. For example adding an alternative as "Lock invoiced lines only", with this alternative it will still be possible to create credit notes from invoiced sales orders. The alternative which is named as "Locked" today can be renamed to for example "Lock invoiced orders", which still means that it is not possible to delete invoiced lines or create credit notes.

Context: 

• Some purchases at GC are captured as standing orders (e.g. 10,000 Qty / 1 Unit Price) as the amount invoice is unknown at the time of PO creation.  

• Invoices for these orders come in as normal invoices (e.g. 1 Qty / 950 Unit Price) 

• Since the lines do not match, invoice capture needs to be trained to ignore them and process the invoice as a header only invoice. 

• Header invoices only contain information for the total amount, if there are multiple receipts available, the automation cannot tell which receipt is the right receipt. (Receipts only capture qty information and do not contain price values) 

Requirement: 

• Need to be able to map the product receipt in invoice capture to the product receipt field in D365, so it allows invoices to find the right receipt to match to.  

• Users can capture the product receipt number as the invoice number and in invoice capture. 

• Users can teach the model to capture the invoice number in the new product receipt field. 

• We can potentially utilize existing “Product Receipt” field from Invoice Capture side.

Extending customer payment calendar configuration in order to:

1) let the configuration to be applied for specific customers, not only for specific payment terms/methods (it is not user-friendly asking to create a lot of similar payment terms/methods only for managing calendar holiday date)

2) let the possibility to move the due date not only in the previous/next business date (based on the actual standard “Due date update” field in Terms of payment setup), but in a longer period, for example, letting the system use the Payment days setup in order to let the system calculates the needed due date

Some business scenario, self-billing or credit notes, workflow for the Bank account is needed for the customers as well to make sure that no information is changed without being validated and reapproved. This is achievable with the Vendors accounts and it will be great to have the same to not to risk any transaction.

When enabling Belgian localization, a default functionality regarding posting validation is available. This functionality allows finance administrators to enter a date range in which a number sequence can be used. If a transaction is posted outside the date range, the transaction will not be posted due to a check on the number sequence with the allow date.

If we could have this functionality for other countries we could allow finance to have a smoother period close due to the fact that we can enforce the number sequence used in a transaction.