Skip to Content
Personal Insights

When should you convert planned orders to production orders?

Last month I rolled off an SAP PP project to join a new project. Before I rolled off I held some knowledge exchange sessions with my replacement, a seasoned consultant with over 10 years of experience.  I was shocked by his lack of knowledge about when to convert planned orders to production orders so that’s why I’ve written this blog.

Here is the point of contention:  When should you convert planned orders to production orders and release them?

My answer:  Convert and release as late as possible as determined by the activities that must take place with production orders.

His answer:  It’s a personal preference.  My preference is to work with production orders so I will convert the next 4 weeks of planned orders to production orders and then a day or two before production I will release them.

He is wrong and this blog explains why.

Here is the correct way to determine when to convert and release:

  1. Ask the production supervisor how many days she needs to get components from the warehouse and stage them at the line and to get the operators ready. Suppose her answer is 1 day. Therefore, release production orders 1 day before production.
  2. Ask the planner how many days she needs production orders to sit in a CRTD status so she can do activities like:
    • Plan alternate sequences and operation splits
    • Chase up missing components as determined by the CRTD Production order ATP check
    • Publish the production schedule for the upcoming X days

Suppose her answer is 2 days.  Therefore, convert planned orders to production orders 2 + 1 = 3 days before production.  Beyond those 3 days the plan will consist of planned orders.  In the near term the planned orders will be dispatched in the planning table for as long as the planner needs the firmed schedule. In most industries this dispatched period is from 1 to 2 weeks although I’ve seen it as long as 6 weeks in the aerosol paint industry.

The screen shot below shows a typical Planning Timeline:

Typical%20Planning%20Timeline

Typical Planning Timeline

 

Why is it important to convert as late as possible?

  1. SAP expects you to plan both capacity and components with planned orders and execute with production orders; that’s just the way it’s been designed. The name “planned orders” tells you that planning activities take place with them.
  2. Once you convert to a production order it is firmed; MRP cannot make changes to dates or quantities so it gives exception messages for the planners to make the changes. By converting too soon you create more MRP exception messages for planners to action. The plan is also firmed by dispatching so you must take care not to dispatch planned orders for a period any longer than necessary.
  3. By having 3 distinct planning statuses:  Planned orders vs. CRTD vs. REL you can apply 3 levels of ATP checking rules to commit components to production that is running soonest. If you maintain only production orders in the planning horizon you lose some of this functionality.
  4. Other processes’ ATP checks (sales orders, deliveries, etc.) respect ATP commitments on MRP elements differently, e.g., Dep Req. vs Reservations.  If we ATP commit components to CRTD production orders 4 weeks out we lose the ability to commit them to sales orders. Think of the process of selling a spare part that is also used in production.
  5. In the graphical planning table the functionality to “drag and drop” to an alternate line is controlled by production version; if the version exists for the alternate line (work center) the planner can drag and drop the planned order; if it doesn’t, she can’t. This control is lost once it is a production order.  This means you can accidentally schedule a production order to an incorrect line without getting an error message. Just another hint that SAP expects you to plan with planned orders.
  6. SAP has reports that can compare plan vs scheduled vs actual for quantities and dates. See TCode COOIS on the object: Items.  The plan to actual report is meaningless if you have converted before you have proven that both capacity and components are available.

Point 6 is very important! Planning activities are completed only once the planner has:

  • Proven capacity by dispatching the planned order in the graphical planning table, and
  • Proven component availability by running a successful ATP check on the dispatched planned orders (Tcode MDVP)

At the moment she converts the planned order to a production order the planned orders’ finish date and quantity are “cast in stone” and can be used to compare to actual dates and quantities. Planners are responsible for planned orders and the shop floor is responsible for executing to the proven plan using production orders.

The time frame to convert and release should be sytematically controlled through a configured Scheduling Margin Key.  Below is a screen shot of configuration point: Define Floats (Scheduling Margin Key):Configuration%20Point%20for%20Scheduling%20Margin%20Key

Configuration Point for Scheduling Margin Key

Scheduling margin key P01 has a 3 day opening period and 1 day release period.  If planners fail to convert and release on time, they will be reminded to do so through MRP Exception messages: 05 and 06 as seen in the screen shot of the Exception Message Groups from the Stock Requirements List, Tcode MD07.

Exception%20Messages

MRP Exception Messages

 

Conclusion

Plan with planned orders and execute with production orders; this is how SAP designed the Plan to Manufacture process.  Convert planned orders to production orders as late as possible to ensure that the 2 planning milestones have been achieved:  line capacity and components are available.  Then release the production order; throw it over the wall and measure the shop floor on how well they executed to the plan in terms of dates and quantities.

 

 

11 Comments
You must be Logged on to comment or reply to a post.
  • Good read. Perfectly explained.

    Unfortunatly many companies handle it differently and once the processes are widly introduced it is difficult to change them afterwards and you are stuck with whatever you have.

  • I have to admit, that I am a bit torn by this article.

    Yes, the PP module was built with the intentions and functions described above, but it originated from a time when there was still a status called "Printed".

    Sentences like the final "Then release the production order; throw it over the wall and measure the shop floor on how well they executed to the plan in terms of dates and quantities." remind me of exactly this mentality.

    Unfortunately, most Manufacturing Execution Systems, including those offered by SAP, base their integration on the Released status. In conclusion this keep the main system actually orchestrating the factory blind beyond one day.

    In a modern smart factory, decisions like alternate resources or routing sequences are not taken beforehand on a desk, but during production, down on the shop floor. The same is true for staging decisions and maintenance schedules.

    All this is the reason SAP is heavily investing in tight integration scenarios and lots of extensibility APIs, to tear down these walls mentioned above.

    “Man makes plans . . . and God laughs.”

    Well-implemented execution systems like MES and LES can help make the right decision when (not if) things are going wrong. But to do this they need the respective horizon.

     

    P.S.: I get that the answer to point 1. "Ask the production supervisor how many days ..." can be used to just dial up the horizon, but that is not my point.