Engineered products can be pretty complex. In some cases, a VC model can be written that covers all the possible combinations that can be built. Other times that’s unreasonable. There are too many “once a year” options and customer special requests to ever take all of them into account. Even if you could, you probably wouldn’t want to. The added overhead and complexity would make the model too unwieldy. So you settle on a faster, easier to maintain model that completely handles 80 to 90 percent of your orders. Those few oddities you handle manually. You just create an order specific BOM for the oddities.
With Planned / Production orders (i.e. Plnd/Prod Order as the Process in the Config Profile) this means creation of a completely new BOM, separate from the original master BOM, created from scratch, which totally ignores all the logic built into your master BOM. Tedious, but not difficult. And, as long as it’s once in a while it’s not a big deal.
Unless it’s not “once in a while”.
Some products are different. Orders for some products almost always have something special or unique about them. There’s always extra engineering or special materials that need to be handled. In these cases the VC model automatically handles only 80 to 90 percent of any individual order. Orders that are completely handled are the exception, not the rule. And building a custom BOM for every order is a lot of work.
For these cases SAP has included the concept of the Order BOM process, as defined in the Config Profile. Order BOMs are sales order line item specific BOMs that are based on explosion of the “standard” master BOM, but can then be customized to suit the requirements of an individual order. The important takeaway here is that you start with the results of the master BOM explosion using the order specific configuration, not an empty BOM.
Another important aspect is that this isn’t just a copy of the BOM that then becomes disconnected from the master BOM. This is an Order Specific BOM that retains all of the logic from the original model, but which keeps track of what custom changes you made. If you make changes in the config that affect BOM items that you haven’t touched; the appropriate resultant changes happen automatically. Make other changes that would affect something that you changed manually and SAP does not reverse your changes.
For example: a Bookcase.
The top level configuration requires height, width, and depth of the unit, as well as the color and thickness of the shelf and carcass material. Underneath is a production BOM containing configurable materials for the sides, top, bottom, back, and shelves. The number of shelves is dynamic depending on the height of the unit. The length and width of all the pieces are inferred from the top level configuration, as is the material thickness.
In this case, the setting in the Config Profile is Order BOM.
Rather than the convoluted methods described above, after the order is saved I can go into CU51 and modify the BOM (and engineering configuration) to my heart’s content. And I do it starting with the result of the original master BOM. I can add, delete, and change items at all levels.
I can also edit the engineering configuration (i.e. the configuration of the components that was inferred from the top level, but was not editable in the sales process).
When I save it, this becomes the BOM that SAP will use for all downstream processes. But, just for this sales order line item. Other bookcase orders will use either their own order specific BOM, of the unmodified explosion of the master BOM for their configuration.
Order Specific BOMs are only saved for those configurations that have had modifications made. The Order BOM setting does not require that all orders be modified and saved. The configurations that are completely accounted for by coded VC are simply treated as Planned/Production orders.
Again, it’s important to keep in mind that your manual changes will not be overridden by SAP in reprocessing rules and re-exploding the BOMs. Changing the number of shelves manually means that changing the height of the unit will not cause the shelf quantity to change anymore. Changing the height of the back means changing the height of the unit will no longer affect the back height.
For the record, I know I’m talking about Sales Changes here. The top level configuration can only be changed in Sales. But sometimes you do need to change the sales configuration. With Order BOMs, even after you have created an order specific BOM and saved it, you can still go into the sales order (VA02) and make modifications to the configuration. If the resultant changes were not manually modified in the Order BOM, they will still be made to the resultant Order BOM. Going back into CU51 will validate this. If I hadn’t changed the back size manually, changing the height of the unit in the sales order and saving the modified order would cause the size of the back piece to be changed.
For those companies who use this functionality extensively SAP also offers an add-on called the Order Engineering Workbench. This is a fairly pricey add-on which gives the user the ability to have a second order on the screen at the same time and drag and drop between them. It’s more user friendly, and also handles the concept of versioning aside form/in addition to the concept of Engineering Change Management. This allows you to copy from or revert to old versions.
Depending on your specific order engineering processes and requirements OEW still might require some modification to make it fit perfectly. We have actually gathered requirements for a number of companies, exactly specifying their needs, and built an entirely custom OEW with all the bells and whistles required for less than the cost of the OEW from SAP.
Really, this is what SAP did with their OEW. There are a number of native “functions” or “macros” that can be invoked by custom programs that call the CU51 functionality in a custom manner. Once invoked, they process the data exactly like SAP does in CU51. This means that both the SAP OEW and all the eLogic OEWs can do exactly the same things when the same functions are invoked. This preserves SAP compatibility and prevents newer modifications from breaking this functionality. Except that the eLogic OEWs are custom tailored, and the SAP OEW is a “one size fits all”.
There is a similar process for Routings. With Order Specific Routings you can account for order specific changes in operations in addition to changes in materials. I’ll discuss those in a separate blog.
When Order BOMs are working, they can be a tremendous time saver. Saving Time means becoming more efficient, saving money, and increasing customer satisfaction. A true win-win situation.
The usual disclaimer: A little knowledge is a dangerous thing. Everything I’ve said here is valid, and should be able to work on any SAP system that is up to date and hasn’t been too heavily modified. There may be IMG settings and user processes that need to be changed to allow this. But, every system is different. All of the parts of SAP need to be coordinated to work together, including VC. I highly recommend consulting with all the downstream process owners, and completely testing this functionality (including regression testing) in a Test system before deploying.
When SAP needs to find the correct BOM for an order (like when you’re running MRP, or printing the shop floor documents) it looks for different types of BOM in a specific sequence. For a production BOM (setting PP01 in the Config Profile) SAP will (generally) look for an order specific Type 1 BOM. If it finds it, that is what gets used. If it doesn’t find one SAP looks for a non-order specific Type 1 BOM. If it finds one, that’s what gets used. If it doesn’t find one SAP looks for an order specific type 3 BOM (Type 3 is Universal; suitable for both Sales and Production). … I bet you can guess what it looks for next.
If the KMATs Configuration Profile is set to Order BOM, and MRP settings (TCode OPPQ) determine that the BOM explosion process is Order BOM, SAP knows to look for an Order Specific BOM. It always looks, but only uses one when an order specific BOM is found.
That’s kind of a universal SAP concept. Looking for the most specific object first (Price, BOM, Class Node …) and if an appropriate object isn’t found SAP looks for decreasingly specific objects. For prices, SAP looks first for a Customer Specific price, then for a Customer Group specific price, then for a Sales Area specific price, then for a Generic List Price. SAP uses the first one it finds. Your actual list may vary, but the concept of looking in decreasing levels of specificity is common.