-
Integrating the use of scanners in the Production Floor Execution to be able to Start and Report progress
Suggested by Fabiola Lizette Torres Rivera – Rejected – 1 Comments
Many of our clients want to use Production Floor Execution, after they removed the functionality related to time and assistance, but in a more automated manner without manually entering data to avoid errors.
Instead of doing it manually as is currently done, integrating the use of the scanner to be able to start the Jobs ID and report its progress would help industries optimize their processes.
-
Production floor execution started multiple quantity
Suggested by Ahmed Abdelaal – Rejected – 0 Comments
If a user starts production order from all production orders and then start it again from PFE, quantities reported in BOM journal will be doubled.
PFE will show that the quantity specified for the route operations is zero, even if they are displayed in BOM in the production order form.
This leads to discrepancy in cost valuation for quantities and machinery and will also cause variance between estimated and reported quantities.
-
Planned Orders not getting generated for Full Coverage Time Fence. Instead, a single planned order is getting generated for the current time period only.
Suggested by Yasmine Hesham Hassan Zaki (Convergys International Europe B V) – Rejected – 1 Comments
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.
-
In planning optimization an Inventory journal line with today's date is created, regardless of the planned arrival date of the purchase order with Inventory Status set as "Blocking".
Suggested by Yasmine Hesham Hassan Zaki (Convergys International Europe B V) – Rejected – 0 Comments
There is a mismatch between the confirmed receipt date and the system’s current stock receipt date (today), leading to planning inaccuracies.
This discrepancy causes underestimation of available stock, disrupting planning cycles and triggering unnecessary stock orders.
Clients are informed of stock issues while the stock is still with the supplier. They expect the system to reflect that the stock is unusable without canceling the order, which is not currently happening.
When changing the stock status to “quarantine inbound” to indicate unusable stock, which should trigger stock blocking.
We expect that the system should show a negative stock blocking entry on the expected receipt date. Instead, it creates a blocking entry for today, skewing stock reporting.
PG advised that when it comes to inventory status blocking, inventory status dimension should be part of coverage dimensions in order to exclude such transactions from planning. Otherwise, they will appear as 'Inventory journal' transaction in net requirements form. Also, as for the date, the 'Inventory journal' transactions are basically negative "Reserved ordered" transactions with "Inventory blocking" reference which are not order specific but instead grouped by multiple orders and therefore doesn't have any specific date. For these it is assumed that the date is current, just like the on-hand.
However, the use of the inventory status as a coverage dimension would defeat the purpose of it as then we'd be planning for blocked materials and the customer would like visibility of the stock, just with the correct dates to reflect it.
-
Item substitutions (plan groups) are not considered for Formula/BOM item requirements in PLOP
Suggested by Yasmine Hesham Hassan Zaki (Convergys International Europe B V) – Rejected – 0 Comments
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.
-
Grouped planned orders revert back to original route number after manual modification
Suggested by Yasmine Hesham Hassan Zaki (Convergys International Europe B V) – Rejected – 0 Comments
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.
-
Resource time on planned production order not getting recalculated after split
Suggested by Thomas Tran – Rejected – 0 Comments
This is happening on Planning Optimization
When split quantity of a planned production order, the resource time on the original planned production order remain the same, with less quantity, the resource time should be recalculated, not remain the same resources time of the original quantity before getting split.
Only the resource time on split planned production orders got recalculated correctly.
This behavior causes incorrect forecasting and disrupts labor, happen every time we try to split planned production order.
-
The status of grouped planned orders automatically changes from 'Unprocessed' to 'Approved' after grouping them in 10.0.43
Suggested by Yasmine Hesham Hassan Zaki (Convergys International Europe B V) – Rejected – 0 Comments
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.
-
Enhance the "Print" Option in the Order and Planning Worksheet to Support Different Sending Methods
Suggested by Stefan Lüschen – Rejected – 0 Comments
Enhance the "Print" Option in the Order and Planning Worksheet to Support Different Sending Methods
Currently, in the Order Worksheet and Planning Worksheet, there is a "Print" option available when processing an event notification. However, this option does not take the creditor’s Document Sending Profile into account. This can lead to inefficiencies, as users might expect an automatic sending process but still need to manually choose the appropriate method (email, print, or electronic transfer).
Proposed Improvement: The "Print" option should be enhanced to respect the Document Sending Profile of each creditor. This would enable seamless email dispatch, printing, or electronic transmission, ensuring that documents are sent automatically through the preferred channel.
Why This Matters:
- Eliminates unnecessary manual steps and enhances process automation.
- Prevents misunderstandings, as "Print" currently implies that the function is already fully available.
- Ensures consistency with other automated sending processes in Business Central.
Even Better: To make the function clearer and more intuitive, renaming "Print" to "Send" would be a great improvement! This way, users immediately understand that multiple sending methods are included.
-
DDMRP Average daily usage calculation base on actually usage not only base on inventory unit decimals.
Suggested by Ke Ji – Rejected – 0 Comments
Customer sales of 1 Pcs in last 10 days and as per DDMRP past method it should be 1/10=0.1 Average daily usage, but system is calculating Average daily usage as 1.
So they get 5 min and 24 max, by following formula, it's too much for the customer to purchase, so they think we may have an option to make the ADU is calculated base actual usage.
Min is calculated by following formula, so it 1(Average daily usage)*5(purchase lead time)*0.8(Lead time factor) = 4, 4(Red base) * 0.3(Variability factor) = 1.2, so the Min = 4+1.2 ≈ 5.
- Red base = ADU × Decoupled lead time × Lead time factor
- Red safety = Red base × Variability factor
- Red zone = Red base + Red safety
The Record point is Min+Yellow zone, Yellow Formula as following, so the Record point = 5 +1(Average daily usage)*5(purchase lead time) = 10
- Yellow zone = Average daily usage (ADU) × Decoupled lead time
The Max = the record point + Green zone, The green zone is calculated as the maximum result of the following three equations: so the Max = 10 + 14(Max) = 24
- Minimum order quantity 0
- ADU × Order cycle 1*14
- ADU × Decoupled lead time × Lead time factor 1*5*0.8
