• 22

    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.


  • 16

    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.


  • 12

    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.


  • 9

    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".

    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.


  • 9

    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.


  • 9

    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.

     


  • 6

    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.



  • 5

    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.


  • 5

    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.


  • 5

    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