12566 – MRP not calculating Works Order dates as expected with Operations and Grouping
Version Reported In
Sicon Manufacturing v221.0.0
Detailed Description
Sicon works orders created manually use a different method to that used by MRP to create the works order suggestions. Put simply, manual works orders uses a thorough, but slower method to add all the operations and calculate the exact time a works order takes to make. MRP uses a less thorough, but much quicker method to ensure MRP can be run efficiently. This results in a known issue where the suggested works orders in MRP do not show the start and due dates as expected when there are operations on a built item and a Grouping option has been selected. This can then have a knock-on effect on when purchase orders are suggested, potentially resulting in stock being made / bought too late for the earliest demand.
Here is a very simplified example to illustrate the issue. Using the example of a built item with operations that take 1 day per 1 built item being made, there are 3 sales orders due at different dates:
Demand | Qty | Duration | Due Date |
Sales Order 390 | 5 | 5 days (1 day each) | 14/03/2025 |
Sales Order 391 | 5 | 5 days (1 day each) | 19/03/2025 |
Sales Order 392 | 5 | 5 days (1 day each) | 24/03/2025 |
In this example, to keep the illustration simple the BOM requires 1x component, with a supplier lead time of 3 working days.
When MRP is run with no grouping applied, the works order suggestions are calculated as expected (5 working days each). And crucially, because they are separate works orders the timings can overlap. At the time of running, the demand is in the future and can be made in time for the due date, therefore the start date is calculated working backwards from the due date.
![]() |
This in turn shows the purchase orders for components suggested to arrive 3 working days before each start date.
![]() |
The known issue comes when grouping is applied. Using the example above, this time the Works Orders are grouped by 1 month. These all fall within 1 month so there is only one suggestion. However, it is the date of the last one that is used as the due date, which in this example is 24th March. However, because of the simplified calculation MRP uses for the suggestion compared to a more detailed calculation when creating the works order manually, the start date does not reflect the true start date of the works order. This is the first part of the known issue.
![]() |
This in turn has an impact on any suggested purchase orders for components. Because there is one grouped demand, there is one suggestion, made in line with the simplified start date.
![]() |
Impact: Medium
- Urgency | Ability to work not affected; sufficient workaround available.
- Impact | All users affected.
Workaround
Whilst Sicon recognises that this is not ideal for planning purposes, MRP is a complex engine with many inputs, and to resolve this in the current release would risk stability and functionality to existing customers, many of which are not using grouping when looking at MRP for scheduling purposes. Therefore, if both operation dates and purchase order dates are critical, the recommended workaround is simply not to use grouping when running MRP.
There are however a couple of process changes that can be adopted to mitigate the risk grouping MRP results has to businesses, although neither are risk-free.
Mitigation 1 – create the Works Order, then re-run MRP for Purchase Orders
Firstly, if grouping continues to be used as-is, create the suggested works orders required first. At the point of creating the works order from the suggestion in MRP, the more thorough method kicks in and the start date of the actual works order is calculated backwards from the due date (assuming it can be made in time for demand – otherwise the due date will calculate forwards from the start date).
![]() |
Then re-run MRP for the Purchase Orders.
When MRP is re-run for suggested purchase orders, the dates will now pick up the start date of the actual works order and suggest to purchase the stock at the earliest possible date. In this example, MRP was run on 3rd March, and because there is a lead time of 3 working days this was too soon for the Works Order start date. So instead, it made the suggestion to buy that day, and the date requested shows +3 working days:
![]() |
Mitigation 2 – Use Production Lead Time on works orders
Another option is to add a Default Production Lead Time to the stock item via the Sicon – WOP tab.
![]() |
And then enable the WOP setting to “Only use production Lead time for Works Orders” (Sicon Works Order Processing – Utilities – Settings – Dates tab).
![]() |
This way, if MRP is run with grouping turned on, it instead looks at the Production Lead time and basically ignores the operation timings.
This can result in suggestions being made earlier than the product can physically be built, but does mean any purchase orders are suggested early enough to build the stock.
![]() |
![]() |
This does mean that the works order created from MRP will now use production lead times, which may show a mismatch on how the operations themselves are displayed.
![]() |
Sicon are looking to address this known issue in the next major release to keep the methods consistent.
Development Priority Voting
Please let us know your development priority for this Known Issue by providing us with a star rating based on the below;
- Not causing any problems – not a priority.
- It’s annoying, but not causing too many problems – not a priority.
- Would be nice to be fixed, but not essential – not a high priority.
- It would be helpful to have this fixed – fairly high priority.
- Really needs to be fixed as soon as possible – high priority.