Dynamics 365 Supply Chain Management

in USMF entity i have created a prospective vendor registration reuqest and this user has been scussfully submitted the Registration form and it has been approved and converted to Vendor.and the vendor name is "XYZ ltd.".

in another legal entity have created new vendor and it will ask for use the existing vendor infomation in another legal entiy.

IN USRT entity the "XYZ Ltd" vendor does not have any contact information and we have recreated the contact information and submitted to the provision for vendor collobration and giving to the erro message as "email id already exists in the ADD".

Unable to use the same email id for the providing the vendor collobration access in 2 different legal entities.

The standard catch weight design helps prevent weight changes after registration.

For us, we set the catch weight during production and keep it the same for all movements afterward.

We use the standard CatchWeight item handling policy by setting the Outbound weight variance method to "Restrict weight variance" and the Movement weight capturing method to "Not capture."

With these settings, we expect the weight to remain constant during movements and picking processes. Therefore, the reservation and release processes should follow this rule when determining the catch weight allocation method.

Based on our settings, we do not expect the weight to change or need confirmation during reservation and picking.

However, the "Catch weight item handling policies" only work if the quantity is picked using a mobile device, not manually.

We expect the catch weight item handling policies to apply to all methods for completing inbound, picking, and outbound processes.

Even if we were not using the warehouse scanner function and were picking entirely through the client, the handling policies should still apply.

GST is not being calculated in the invoice journal generated through Transportation Management, even though the SAC/HSN code has been added to the charge code.

The journal includes both Freight Charges and Accessorial Charges, but the tax calculation does not seem to be reflecting as expected.

Quick steps:

• Setup Shipping carrier, Accessorial charges and Freight charges from TMS
• Create SO and processing using Outbound load planning workbench
• Generate Freight bill invoice to process vendor invoice

when a vendor modifies the payment terms in their RFQ response, the updated value is not transferred to the purchase order (PO) after accepting the bid

When Approver rejected Purchas Order and request modification in quantity and/or Unit price if approver didn't refresh PO view after modification the Totals pop up window shows updated information and Overall form shows old records creating confusion when users are not aware of.

When a purchase order is created from an approved purchase requisition line, the Approval status on the PO is set to "Approved" even when the Activate change management parameter is set to "Active" and an active Purchase order workflow configuration exists.

There was a previous Microsoft Idea that has been completed for this: https://experience.microsoftcrmportals.com/ideas/idea/?ideaid=1b8b981b-438f-e711-80c0-00155d7cd0b4

However, as confirmed by Microsoft, this is currently only active for customers that have the configuration key 'Public Sector' enabled.

Our customer in Industrial manufacturinghas has two distinct processes:

• The requisition process with an approval workflow which takes place "in the business" and where department managers can approve requisitions for their employees
• The second process takes place in the procurement department where buyers prepare the purchase orders and pricing and then submit the purchase orders for approval via a separate approval hierarchy with stepped signing limits.

The suggestion here is to open up this already developed feature outside of the Public Sector Configuration Key.

There is a requirement to enforce credit limits based on item categories—specifically, to restrict the processing of items in Category One when the amount exceeds for example $20.000, and items in Category Two when the amount exceeds $30,000. However, the current system design does not provide functionality to manage this requirement through existing credit limit settings or blocking rules.

D365 where modifying a ship date on project quotation leads to automatic recalculation of prices, resulting in the loss of actual price values. In sales quotation and sales orders, there is a prompt to retain the current prices during this process, this prompt is not presente on the project quotation.

• The customer tries to submit a workflow it reflects with the error message below:

Stopped (error): Accounting distribution validation failed. Please recall purchase order workflow and rectify accounting distributions. This action can only be completed after the line number 10 is fully distributed.

• While checking the lines we found all lines are distributed.
• Throw investigation we found a raised fix request related to that error, it will not be fix and there is a workaround had been provided
• Our customer tested the workaround that had been mentioned in the fix request, and it did not resolve the issue as expected, please find the feedback below:

 if we Disable the Parameter Auto Calculate Totals and Accounting Distribution from Accounts Payable Parameters -> General -> Purchase Order Workflow, this will also affect all PO's with actual errors in distribution that we would like the system to stop. For example if a PO is missing a financial dimension as Department, we need the PO to stop in WF and give a warning to correct the PO before approval. If this stop/validation is skipped, we will have issues later in the process when trying to post PO against vendor invoice. The error we have reported now is a bug and should be taken care of. 

• As a result for the above please advise with another workaround as the mentioned did not fit our customer gap.

There’s an issue with the configurator where the OK button becomes grayed out after a few minutes of inactivity. This is particularly frustrating, especially during complex configurations when we need to keep the configurator open while gathering information from other systems.

To improve usability, we request that the configurator’s idle timeout be extended to accommodate longer periods of inactivity.