Dynamics 365 Supply Chain Management

After planned purchase orders are firmed, the ‘Approval status’ is default to ‘Approved’ on purchase order screen, which is skipping the purchase order workflow. Suggest to default the ‘Approval status’ to ‘Draft’ while workflow is enabled; or have a parameter like 'require workflow' to control planned purchase orders. Then the workflow process should work the same way as any other manually created purchase orders.

The reason is: the 'approve' and 'firm' on the planned order screen is normally used by the planning / purchasing department, then workflow is still required from purchase authorisation / financial point of view.

A vendor return is created (purchase order with negative lines) for an intercompany vendor in company A. This generates an intercompany sales return order in company B.
Now it's required to ship to goods from company A using WHS processes, but in the purchase order there is no way to "Release to warehouse". Therefore all the capabilities of the warehouse processed cannot be used for shipping returned godos to vendors.

It is currently not possible to do an over pick for raw material picking (production order). We have scenario's that the bill of material is not correct and in that case you want to have the option to pick additional items with the warehousing app. Dynamics suggest that this scenario is possible with the warehousing app (parameter allow over pick on mobile device menu item) but it doesn't work.

Situation :

Planning Optimization replaces the usual Master Resource Planning.

Within this Planning Optimization, CTP capability has been added, it becomes GA in 10.0.32.

But : this CTP is not yet able to run on the fly, when user saves the sales line. It's necessary to re-run the master plan. We are then loosing reactivity.

Idea : The request is then : retrieve instant capabilities of the existing CTP with the old MRP :

1. Be able to request manually a delivery date control, on each sales line. Get an immediate information.
2. Have a setting to activate by default this delivery date control, when user saves the line. If a risk of late delay is detected, inform the user with the form : "Requested delivery date can not be promised..." And visibility on alternative possible delivery dates (as the existing form).

Business case: I am working with 2 legal entities. LE 1 has entity language set to italian LE 2 has entity language set to english System language is english I have a released product with an EN and IT translation When i go to the released products list page or add items in a sales order I will always get to see the products with EN name and description Desired situation (2 possibilities): 1 When going to IT company, show me products in italian, when going to EN company show me in EN 2 show me the product name and description according to the language set in my user preferences

Displaying product and category names in accordance with user or legal entity in mulitinational environment is a must for implementation for client operating worldwide. Our client operate in few countries with different languages. It's a problem to prepare consistent processes for purch and sales as the list of categories and products display only in one system language. Users from different countries cannot properly carry out sales and purch processes as they cannot read product and category names, which are crucial for document lines. Coherent files is obligatory in a large organization like my client's one.

The purchase receiving process has an issue. Mobile client brings the PO line to 'registered' - Nobody in warehouse or office is willing to go to each PO and individually click a "Product receipt" for the registered lines - Batch program in advanced warehousing exists to bring PO lines to "received" status using a LOAD number - So we can auto-create Loads for each PO via a parameter in Transportation - then the batch program , filtering on "inbound" and "open" load status could theoretically handle this.. all PO lines become "received" after being "registered" within a few minutes. But then we still have a Load in status 'received' which is not the final status. somebody will have to manually go to each Load (and we have one load per PO) and say "confirm inbound shipment".. and only then will the load be 'shipped' and disappear from the radar screen. No batch exists to "auto confirm inbound shipments". What can be done to streamline the PO receiving process in advanced warehousing? We would like to request a batch program that processes "registered" PO lines to "received" and also confirms the inbound shipment. There is no business added value to have that last step as a manual step

In addition to the current lead time setup and calculation, a default lead time by vendor should be added to the vendor card. In several scenarios we had one vendor supplying 50K plus different products and maintaining the lead time per product is not really feasible. This is only the default vendor lead time, any other lead time calculations can stay as they are. 

Many customers wants to control their purchases using an approval workflow. These controls are required whatever the delivery type means: either receive goods in own stock or by delivery directly the customer. today in D365 F&Ops, change management can be used to trig workflow approval for PO ONLY if this PO is not created as direct delivery. the same way of work is observed for intercompany purchase orders. in that case you are blocked to create the PO and to workaround, you need to activate setup "Override settings per vendor". if you do that, PO can be created but workflow approval is disabled. This way of work can make sense in case of intercompany as this is the same company group but it is senseless in case of a PO for a another vendor. it means you can bypass approval controls just by changing the delivrey type. Idea would be to adapt standard to allow usage of change management whatever the delivery type. Workflow approval for PO would be more consistent. as example: maybe create a setup to select all fields that if they are modified on SO then they will trig a "request change" on PO and force user to submit again. if modified field is not part of this list then accept the change without new submission