-
Adding a "CANCEL" feature to the production orders
User wishes to have the ability to "cancel" a production order to maintain the number sequence of the production orders as it is useful for the Audit Department to have all production orders visible and correctly numbered regardless of if they are "ended" or "cancelled".
-
Start multiple jobs parallel to each other in PFE
User is using PFE and is trying to start multiple jobs parallel to each other at the same time. However, he receives the following
error message: "You are currently registered on other job(s). You need to report feedback on these before commencing on new jobs."
-
Enabling the Lot inheritance values to be updated at the registration level not later after processing.
Lot inheritance values are updated when deferred RAF record is processed not when it is registered.
The inventory registration process is crucial for fast-moving businesses because it allows inventory to be picked and shipped to customers quickly. Customers require deferred posting for performance reasons and batch attributes to ensure
documents like packing slips are posted correctly. Performance, in this context, refers to the speed at which reports are processed, and transactions are completed, enabling the inventory to be available for the next process as soon as possible.
-
Vendor’s PO calendar and work timings not considered while assigning requested ship and receipt dates.
Actual Result
If the Lead time is 2 days and then a Purchase order is created on 15.04.2025 this means that the Requested ship date has to be on 17.02.2025 which is 2 days after the creation days as per the Lead time assignment. However, when a Purchase order is created on 16.04.2025 the system records the Requested ship date to be 17.04.2025 when it is supposed to be 18.04.2025. However, the system doesn’t recognize the Lead time. Same issue happens if 15.04.2025 is to be considered a closed day, this means that the creation of the Purchase order should be on 16.04.2025 and respectively the Requested ship date should be 18.04.2025, but it is recorded to be on 17.04.2025. For more clarification, if the Working hours on 15.04.2025 are between 08:00 AM and 02:00 PM and a Purchase order is to be created after the Working hours, this means that the system should create it on 16.04.2025 and therefore the Requested ship date is to be on 18.04.2025 instead of 17.05.2025.
Expected Result
If the Lead time is 2 days and then a Purchase order is created on 15.04.2025 this means that the Requested ship date has to be on 17.02.2025 which is 2 days after the creation days as per the Lead time assignment.
-
Planned Orders not getting generated for Full Coverage Time Fence. Instead, a single planned order is getting generated for the current time period only.
In D365 F&O DDMRP Functionality – Planned Orders not getting generated for Full Coverage Time Fence. Instead, a single planned order is getting generated for the current time period only.
Actual Result
Only 1 Planned purchase order is generated instead of 12 different Planned purchase orders for the respective Coverage time fence of 12 months (365 days).
Expected Result
The generation of 12 separate Planned purchase orders corresponding to the setup Coverage time fence of (365 days) 12 months.
-
The status of grouped planned orders automatically changes from 'Unprocessed' to 'Approved' after grouping them in 10.0.43
When 2 Planned orders with the same Item number and the Status “Unprocessed” are grouped into 1 single Planned order, the system automatically changes the Status to “Approved” in version 10.0.43.
The system shouldn’t change the Status to “Approved” unless the customer actually decides to manually approve the grouped Planned orders. The problem is that when you approve a Planned order, you wouldn’t be able to delete it if you were to run the Planning optimization again.
Customer wishes to have the option to "Approve" the Planned orders and not have them automatically approved. This could happen if there was to be a toggle/parameter to give the freedom of changing the status of the Planned orders as wished.
-
Grouped planned orders revert back to original route number after manual modification
Currently, upon manually changing the Route number on versions 10.0.42 and 10.0.43 against 2 different Planned orders with the same Item number then grouping these 2 Planned orders, a new Planned order will be created, however, the manual Route number change is overlooked by the system and the old Route number get assigned to the newly created Planned order. If we proceed further to Firm this Planned order, a Production order will be created against the wrong Route number. The users wish to have the system assign the correct Route number to the Grouped Planned orders.
-
Refresh issue: base document settings from one sales order are incorrectly displayed on all other unrelated sales orders in Italian localization
The system has a refresh issue where when we assign the Base document “Contract” and the CIPE and the Tender procedure identification codes to a certain value, the correct values get assigned at first. However, after some time while remaining in the All Sales order page for an hour or more then go back to check, then the system ignores the unique codes that the user assigned to each Sales order individually and assigns all the Sales orders to the codes assigned solely to the last created Sales order. Then if we leave the Accounts receivables module and go click on a form in a different module then go back to the Accounts receivables module and check the codes in the Sales orders that we created the codes will reflect as how they were intended to be for each Sales order.
So, if SO 1 has codes AAA, SO 2 has codes BBB, and SO 3 has codes CCC.
When we check all is well after these SOs are freshly created. However, if we wait for an hour or more and check again, SO 1 and SO2 and SO3 have codes CCC. Then if we choose a different form in F&O and then go back, we will see that SO 1 has codes AAA, SO 2 has codes BBB and SO 3 has codes CCC.
Expected Result
Each Sales order should have its unique CIPE and Tender procedure identification codes as per how the user assigned these codes to be without needing to leave the Sales order form and going to any other form then going back to the SO.
Same behavior was noticed in 10.0.42 – 10.0.43 – 10.0.44.
-
Item substitutions (plan groups) are not considered for Formula/BOM item requirements in PLOP
Customer configured the Plan group and Priorities for Formula/BOM version lines of a finished good item (FG) in a way that Priority 1 item does not have on-hand while others have. Via Demand forecasting a Planned batch order for the FG is created and after running the derived requirements, the system is generating the Planned batch order for the Priority 1 Formula/BOM line item without consuming available on-hand quantity of Priority 2 or Priority 3 Formula/BOM line items.
Many customers are suffering from the same issue. Kindly reconsider the outcome on the LCS.
-
Item substitutions (plan group) are not considered when formula line is replenished through transfer requirement
The customer is using item substitutions (plan groups) on formulas that consist of two lines, each with its own priority. The primary and secondary formula item have corresponding item coverage setup that replenish demand with planned purchase orders at warehouse 12 and transfer this demand to warehouse 13. However, when planning is run with demand at warehouse 13 the system completely ignores plan group setup. It covers the demand with on-hand inventory and replenishes the remaining quantity only for the item with priority 1, without considering the on-hand inventory for the item with priority 2. However, if the demand is for warehouse 12 (where no transfer is required), the item substitutions work as expected, and the on-hand inventory for the item with priority 2 is considered.
You’re offline. This is a read only version of the page.
