Dynamics 365 Supply Chain Management

Right now it's not possible to add the Auto charges price component to a price tree. It can only be used in the base price tree.

As mentioned in this engage post https://www.yammer.com/dynamicsaxfeedbackprograms/#/threads/show?threadId=3226711020036096

This would be a very useful addition . Let me give an example. When you have a large company with a lot of intercompany customers often the whole pricing structure differs from regular customers. Or when selling into different regions all over the world. In that case it would be very use full to steer the pricing trees based on the order attribute and applying a different charges.

In addition it would be very beneficial to steer the order attribute based on a customer attribute or field of the customer

If we have multiple items that we purchase at multiple vendors. That means that one specific item can be purchased at two or more vendors. Based on the vendor selection, the unit conversion may differ. For example, item A is purchased at vendor 1 and vendor 2. At vendor 1, 10 pcs in 1 box and 10 boxes on 1 pallet (=100 pcs). At vendor 2, 20 pcs in 1 box and 6 boxes on 1 pallet (120 pcs). If 600 pcs of item A are being purchased, than vendor 1 sends 6 pallets, as vendor 2 sends 5 pallets. That means at purchase order receiving, for vendor 1 6 license plates need to be printed, as for vendor 2 5 license plates need to be printed. 

Based on single intra-class conversion and multiple intra-class conversion it is not possible to automatically generate the unit conversion based on the vendor selection on the purchase order. We want to be able to change the unit for each and every vendor.

When adding a project journal line to a work order within the Asset Management module and specifying the cost price, the sales price should be updated automatically according to the sales price expense settings defined in the Project module. However, an issue arises when the sales price is occasionally not updated and remains at zero. This typically occurs when the user refreshes the page after entering the cost price on the journal line

1.  Business Impact
2. If user doesn’t notice that the sales price remains 0 the work order is not billed from the customer. And if it is noticed later, then the repairing needs to be done in the invoicing phase. The major impact here is that some order would not be invoiced at all. Money is lost!
3. When this invoicing line is zero, the customer is first billed according to other lines such as kilometer or hour lines. If this line is then found out and corrected, the customer would receive another bill after having thought to have paid already.
4. How does the problem impact your business? (Ability to bill, revenue loss, sales etc.).
5. If the sales price is zero, the work order is not invoiced from the customer. Revenue is lost and might go unnoticed for a long time.
6. How frequently does this issue occur (times daily/times weekly/times monthly)?
7. The procedure is carried out weekly. Problem may occur any given time that a project journal line is added. 
8. Is there a workaround? Are you applying the workaround?
9. No work around.
10. How many users are affected by this issue?
11. Every user that inputs work order project journal lines. In this case around 100 workers. The problem occurs for every user if they would handle the journal lines. Customers who are affected by this are counted in the hundreds.

The form should be updated to automatically calculate the sales price based on the inputted cost price, eliminating the need for manual computations. This enhancement aims to minimize errors in the invoicing process. The revised process would work as follows:

1. The user inputs the cost price into the designated field.

2. The system will then automatically calculate the sales price using pre-defined parameters for the charge percentage.

3. The calculated sales price will be displayed immediately, ensuring accuracy and consistency.

By implementing this adjustment, we can streamline the workflow and ensure that all sales prices are derived directly from the cost price with the correct charge percentage applied. This systematic approach will improve efficiency and reduce the risk of human error in pricing calculations.

When modifying an existing line on a mixed license plate, using the "Mixed license plate receiving" work creation process, the unit of measure should be selectable in the "Select new quantity" step.

When entering a new mixed LP line, workers do not typically use the inventory UOM. When the try to modify the line's quantity, it is always in the invent UOM and does not represent what they initially entered. Allowing the unit to be selectable, and preferably, stored on the WHSMixedLicensePlateReceiptLine record defaulted to the UOM it was initially input as, would be ideal to eliminate confusion and manual conversions.

Vendor rebates impact margin on a positive way. Understanding thius impact is very import to any organistion who are funded by Vendors via rebates. In a large number of industries, rebates are a part of the standard method of doing business therefore must be accepted. The way in which margin is defined is different for individual business and some business even have a number of different definitions of margins they report on therefore being able to calculate the margin in a reporting environment provides more flexibility. In the rebate functionality today, there is no method of seeing the impact of Vendor reabtes or vendor funding has on overall margin. Vendor rebates track the calculated rebate onto the related transactions i.e. purchase order or sales order but the impact this has on overall margin is not shown or calculated anywere.

I have recently found out that if using signing limits with the purchase requisition workflow, that workflow notification placeholders reference the system currency, ignoring both the default currencies on both the vendor and legal entity.

One could argue for either the vendor currency or the legal entity accounting currency, but either would be more appropriate that using the system currency, particularly for companies operating in multiple countries. If there is an argument for using the system currency, it could possibly be based on a legal entity-specific parameter.

When creating a Sales quotation, the default pop up for account type is Prospect. In several business process, they use the Customer account type instead of Prospect and users accidentally miscreate Sales quotation with wrong account type.

Hence, there should be a parameter where user can set the default account type is Customer.

Hi,

We need an alternative to the deprecated integration between Dynamics 365 Supply Chain Management (SCM) and Outlook for syncing contacts, appointments, and tasks. The current replacement is not ideal for many customers who don't use D365 Sales, and it's inefficient to invest in D365 Sales solely to sync contacts from Outlook to SCM.

This feature was incredibly valuable for streamlining workflows and enhancing productivity.

Thank you for your consideration!

By default, in D365, when a Purchase order is booked in the foreign currency (EUR), the Purchase order is posted transaction currency, but inventory is posted in accounting currency (USD). 

It brings a challenge to reconcile the inventory between USMF and different companies, because USMF manually booked the inventory in EUR in transaction currency.

Hence, it should have a feature that can enable to post inventory in both transaction currency/ accounting currency.

I am requesting a parameter that enables the direct approval of partial delivery of purchase orders under change management in the 10.0.41 version update.

Currently, the system throws an error message: "Changes to the document are only allowed in state Draft, because change management is activated." However, in previous versions ex. 10.0.39, this wasn't an issue.

The functionality could work similar as the existing parameter called "request change" which exists in the purchase order tab. Then, adding the number of the received POs on the PO lines, and finally restarting the workflow.

The workaround is a labor-intensive time-consuming process that users didn't have to go through in previous versions and could do without now.