Dynamics 365 Finance

Currently, when the OOB commission structure is setup for the US localization, the only option is to record the commission at the time of invoice. As company policies vary, some will record the commission at the time of customer payment of the outstanding invoice, to ensure they are not paying out commission prior to receiving payment from the customer. This is not currently an option in the US localization, however, it is available for Italy https://learn.microsoft.com/en-us/dynamics365/finance/localizations/emea-ita-exil-commission-settlement. It would be nice to be able to leverage this functionality across other localizations within the MS community.

Tax Journal is an essential function and is used to post the GST adjustments, having an approval workflow on the same is a normal business requirement as it affects the tax liability of the organization.

But as confirmed by MS the same is not available out of the box as of now.

Having a workflow on the same will enable to have a control over the transactions posted.

Hence, we would request to consider the same.

Currently even if a financial tag of the List or Custom list value type is defined, the tag values aren't validated to ensure that they exist in the list. In our scenario we have 65'000+ properties that we want to be able to report on. We want to create a financial tag for Unique Property Reference Number (UPRN). In most cases transactions and tags will come via integrations, but some will be entered manually. We want to ensure that the manually entered UPRN values are correctly entered and validated against the UPRN list (custom list).

Would be great to be able to configure financial tag to validate values against the list or custom list.

As part of the vendor payment unsettlement process, D365FO users will need to manually go through each line and unsettle / reverse each transaction. This is after the vendor refund payment has been received in the bank account. There needs to be a more efficient method of completing this task as there will be journals with 100s of lines that will need to be reversed per journal. 

Currently Microsoft have proposed the following (as part of their Microsoft Doc here);

1. Navigate to the Vendor Master Record and select Transactions in the top pane.

2. Navigate to your Vendor Payment Transaction, select Settle Transactions and Undo Settlement. 

3. Once this is complete, complete a manual reversal of the Vendor Payment Journal. 

4. Settle the Reversal of the Reversed Payment Journal and the Old Payment so this doesn't populate in your next pay run. 

5. Once these steps are complete, you will be able to run a new payment against the original vendor invoice.

A new entity has been added to import setup for foreign trade states/provinces: 'IntrastatCodeEntity'.

This entity has a similar name to an already existing data entity 'Intrastat code'.

Can a more suitable name be foreseen for this data entity?

Description:

Customer generated the depreciation proposal process filtering by fixed asset, filtered only two fixed assets (both had the same fixed asset group) and activated the batch processing button, but the system generated the depreciation journal with more fixed assets than the two selected.

Actual Outcome:

Depreciation proposal journal is showing the interval between the two selected fixed assets. You can see other fixed assets unfiltered in the proposal (depreciation journal).

e.g. Fixed Assets in the Proposal process with active batch= BUIL-000002, BUIL-000006

Fixed Assets in the depreciation journal = BUIL-000002, BUIL-000003, BUIL-000004, BUIL-000005 & BUIL-000006.

Expected Outcome:

Have the depreciation journal only with the fixed assets filtered in the Proposal depreciation.

As of now the functionality is catering to exclude/include all the charges ( billable and non-billable ) from the TCS/TDS calculations on Sale order. But certain requirement arises where the billable charges should be included for the TCS calculations and non-billable should not be considered, although non-billable charges are getting deducted while calculating TCS.

While setting up document handling and the overall attachment framework, customers perfer external file repositories like SharePoint, specially in a moment where capacity-based licensing is being enforced. When specifying a document type, a SharePoint URL is defined and all attachments of this type are uploaded to the directly within that URL is SharePoint. When a user uploads and then opens the file, he's redirected to the file itself, but the URL can be reverse-engineered and the root folder can be accessed, allowing full access to all files in the folder (assuming the user has access to it). This model, when applied to SharePoint-based document types means that:

1. Any user can upload any file type in any entity (customers, PO's, Fixed Assets, Employee cards, etc)
2. The file attachment only works if the user has access to the SharePoint directory associated to the configured document-type URL
3. Any user that can upload a given document-type, can also navigate to SharePoint and see all documents in the system associated to that document type.
4. To restrict a user to see a sub-set of documents, in SharePoint, we need to specify different document types, assign each type to a specific SharePoint URL (folder) and apply security rules on that folder (via SharePoint).
5. The point above frequently turns into a 50+ list of document types, which all show up listed in an attachment-enabled form, generating a very inneficient experience to users, prone to errors and confusion

Proposal:

1. When configuring what tables are "active" for document attachments, allow the specification of what type of documents are allowed. This way, a given entity (say, "Customers"), would only allow users to upload document types configured as relevant with that entity, while all others could not been seen neither selected on the attachment type list (after they click on the little paperclip icon).

On "User Options", a user can select what should be his home screen experience when loging in. It would be quite useful that we could assign a specific workspace from the list of standard workspaces the user has access to. Eventually even to custom workspaces. Most users interact with the solution in a given workspace every single day, so accessing a list of 2 or 3 workspaces, and click always on the same one to see relevant data is an efficient approach on the interaction with the solution.