Massive Creation of Version-Controlled Bill of Material (Version BOMs) in SAP PEO

[Juan_Ventura]

Introduction

A bill of material (BOM) is a list of all components required in a process to make a product or assembly, together with the quantities required, the unit of measure, the description, the storage location, the production supply area, etc… The components are known as BOM items.

On a normal BOM, the different changes states are represented using date effectivity, so changes depend on dates. For BOMs with a change history, the change states are identified using the Engineering Change Numbers (ECN).

SAP Production Engineering and Operations (PEO) introduced a new version-controlled BOM concept, where different change states of the BOM are represented by versions. This means no need to work with ECN and date combinations. The main highlight of SAP PEO is then the use of Version BOMs instead of Normal or Classic BOMs.

Version BOMs cannot be created in the SAP S/4HANA classic GUI transaction codes (e.g. CS01). Instead, they must be created in the “Maintain Bill of Material” Fiori App (F1813). The BOM details and fields are exactly the same; the only difference between BOM structure of PEO and PP is the version number. 

The following table contains the main differences between classic and version-controlled BOMs:

Image 1. Main differences between Classic BOMs and Version BOMs

Management of Version-Controlled BOMs

SAP PEO provides a range of features for handing over complex product structures to manufacturing with version-controlled BOMs, which can be very useful for the usage in prototyping and new design implementation. With SAP PEO, three different BOMs can be used for the same finished product, based on the engineering requirements and process complexity:

• Engineering BOM (EBOM)
• Planning BOM (PBOM)
• Shop Floor BOM or Manufacturing BOM (MBOM)

The classic production engineering, planning, and execution process is sequential. Production engineering starts after product design was completed. Production planning starts after release of MBOM and Shop Floor Routing. Production execution can start only after engineering, planning, and the procurement of components is completed. Sequential processing leads to long overall lead times, typical of PEO scenarios.

Usually, the first version BOM you create in an SAP PEO process is an EBOM. EBOM is the engineering bill of material which comes from the engineering department of the new product. We can create EBOM in SAP manually with snapshots or directly without snapshots in the “Maintain Bill of Material” Fiori App (F1813).

The EBOM can be first incorporated into a PBOM, which is then used to create the MBOM automatically. PBOMs can be used in production versions, which are used by MRP. Differentiating between PBOM and MBOM, and between Planning Routing and Shop Floor Routing, has the following advantages:

1. It helps reduce lead time.
2. It provides tools and a process to translate Phantom BOMs used in engineering and production planning into flat MBOMs.

Phantom BOMs allow the use of the same set of components in several parent BOMs, improving the consistency across different parent BOMs. When the parent material's BOM is exploded, the components in the main assembly and the components in any nested phantom assemblies are added to the flat component list of the MBOM. Phantoms can only be added to EBOMs and PBOMs. When converting the PBOM into a MBOM, the BOM gets flattened.

Image 2. BOM explosion with flattened phantom components

Maintain Bill of Material

As mentioned before, Version BOMs cannot be created using classic GUI BOM transaction codes. Version-controlled BOMs can be managed in the “Maintain Bill of Material” Fiori App (F1813). This app is not a PEO specific application but can be used for all BOM types in SAP S/4HANA.

With this app, you can display and manage all your BOMs. Using the available filters, you can find and view existing BOMs, drill down to the level of detail you need, and perform any necessary actions (such as delete BOMs, obsolete BOMs or assign change records to BOMs).

You can create new BOMs (whether classical, version-based, or alternative BOMs) and insert the relevant components along with the required data, including any attachments. This must be done one by one material, and the following options are available for version-controlled BOMs:

• “Create Version BOM”: Create the initial version BOM for a material
• “Create Version”: Create a new version of an existing version BOM
• “Copy BOM”: Copy BOM components into a new initial version BOM for a material, to reduce manual maintenance
• “Create Alternative”: Copy BOM components into a new initial version BOM for a material, with a new alternative BOM.

When adding components, you have the following options (not exhaustive):

• You can add new lines one by one
• You can use “Add Multiple Rows” button, which allows to add several rows info at the same time (10 lines)
• You can also use existing lines as a template by using button “Copy”

Image 4. “Maintain Bill of Material” Fiori App (F1813), header data.

Image 5. “Maintain Bill of Material” Fiori App (F1813), BOM items.

Image 6. “Maintain Bill of Material” Fiori App (F1813), BOM details.

Migrate Classic BOMs to Version-Controlled BOMs

In case you are working with classic BOMs, and you would like to use your existing classic BOMs in SAP PEO, you can perform a one-time migration to convert your classic BOMs into version-controlled BOMs. PEO provides for that the migration report RMPE_MIGRATE_BOM. Please notice that this report is not designed for continuous migration of classic BOMs created in transaction CS01; the migration should be performed only once.

Image 7. Selection screen for classic BOMs migration report.

On the selection screen you can enter the BOMs which you want to convert to version-controlled BOMs. You can specify the target BOM as well, as in which do you want to create. And you have an option to delete the existing classic BOM after the creation of the Version BOM. Please notice that this migration report cannot be used for configurable materials.

More details are available on SAP Help Portal, on PEO Implementation Guide section.

Standard APIs for BOM Version Management

The below Remote-enabled Function Modules (RFC) are available and can be used for manipulation of version BOMs:

• MPE_VERSNBOM_CREATE_INITIAL: Creates initial BOM version (first version)
• MPE_VERSNBOM_CREATE_VERSION: Creates new BOM version (with reference)
• MPE_VERSNBOM_UPDATE: Updates BOM version
• MPE_VERSNBOM_READ: Reads BOM version
• MPE_VERSNBOM_CHANGE_STATUS: Changes BOM version status

These APIs support BOM for both Unitized and Non-Unitized Materials, so the effectivity parameters for every BOM item are also supported. If these APIs were not available on your system, you can check SAP note 2855536 “Remote enabled Function Modules (RFC) for Manipulating Version Controlled Material Bill of Materials (BOM)”.

Customer Use Case for Massive Creation of Version BOMs

Customer works with version-controlled PBOMs and MBOMs. PBOMs are mainly used to flatten the phantom components. For some minor simple products, MBOMs can be directly created, but the standard procedure consists of first creating the PBOM, and later creating the MBOM by updating the PBOM on a Change Record (CR).

Customer manufactures highly engineered discrete products which contain hundreds of components, so requirement was to be able to create new version BOMs by importing the data from an Excel file. Thus, users could manage the BOM changes more quickly in Excel. As standard SAP functionalities do not offer this possibility, a custom program was developed.

Basic data requested by customer to be maintained at component level was item category (only stock items), item number, component, component quantity (always basic unit of measure), special procurement type, production supply area, and effectivity parameters (several values possible). The main key requirements to be considered were:

1. Only creation of new versioned BOMs, not to change data on existing or just created BOMs.
2. The new BOM versions are only created, but not released.
3. The BOM release process to be manually done after the BOM creation, on “Maintain Bill of Material” Fiori App (F1813). This would also help as a double-check for the BOM upload.
4. Keep component links with Operation Activities from the previous BOM version.

For the creation of the initial BOM version, that is, the first BOM version for the material, plant, BOM usage, and BOM alternative, the API MPE_VERSNBOM_CREATE_INITIAL was used. For the creation of a new BOM version, that is, the following successive version of existing version for the material, plant, BOM usage, and BOM alternative, the API MPE_VERSNBOM_CREATE_VERSION was used. In this latest case, the new BOM version is created with reference to an existing released BOM version. Let’s call it the Previous BOM version.

SAP PEO manages version-controlled routings, called Shop Floor Routings (SFR), that are not dependent on time and contain more level of detail. Every SFR operation can have one or multiple Operation Activities (OAs). OAs enable to define detailed work instructions for production operators without making scheduling and costing on operation level more complicated. You can also assign qualifications and buyoffs to OAs. In addition, you can create any-order groups (any sequence) or simultaneous groups (parallel).

Components can be assigned to the more detailed OA level. On “Component Assignment Workspace” of the SFR, users can perform component assignment to OAs in the produce segment for the currently selected MBOM and unassign components. The true challenge of this custom massive creation program was to keep the same component links with the OAs of the SFR, as per the Previous BOM version for still existing BOM items in the new version. This was a mandatory requirement for customer, as minor changes are normally done within the hundreds of components of the BOM, and if existing links are lost this would mean to manually re-assign all the components again.

Technically, the component links are maintained though the tables STPO (field STPO- STVKN_VERSN, inherited node number of BOM item) and STPO_LINKS. To maintain this link, you need the field BOM item node number (STPO-STLKN) to be imported for those BOM items for which you want to keep the same component links to OAs. Thus, you can assign by code the same value for fields STLKN, STPOZ, and STVKN in the “T_BOM_ITEMS_IN” structure, for the items with update type “U”. For the new items or those not keeping the links, the update type will be “I” and unique identifier will be required for field NEW_ITEM_IDENT.

Practical Example

Let’s review a practical example to verify how component links are kept. Originally the “Component Assignment Workspace” of the SFR for the assembled material is the following:

Image 8. Component assignation for existing BOM version as reference.

We create a new PBOM version for the assembled material, release it, assign a CR, update the new MBOM version, and release it. On the new PBOM version, we changed on Excel the quantity of one BOM item, the effectivity of another, and we have added a new component item. NOTE: These changes can also be performed on the PBOM of a phantom assembly component, and components will also be linked (by means of table STPO_LINKS).

With the new MBOM version, on the “Component Assignment Workspace” of the SFR for the assembled material we can notice the following:

1. For those components with a change on the quantity, the assignation status is “Partially Assigned” (yellow).
2. For those components with a change on the effectivity parameters, the assignation status is “Assigned Outside Effectivity” (red).
3. For those components without any of above changes or not changed at all, the assignation status is “Assigned” (green).
4. For the new components there is no assignation (no icon).

Image 9. Component assignation for new BOM version created.

Programs for Exporting/Importing Version BOMs to/from Excel

Initially, the standard exporting functionality provided by “Manage Bill of Materials” Fiori App (F1813) was used. But we found the following issues:

• We were not able to include the header data on the exported Excel.
• We couldn’t split the parameter effectivity data into several columns.
• We couldn’t split the parameter effectivity data into several lines, in case multiple effectivity values exist.

Image 10. Exporting BOM items on “Maintain Bill of Material” Fiori App (F1813).

These issues were causing users to have to manually change and adapt the layout for later data importing, thus reducing the process agility because of the different download and upload layouts. Therefore, customer decided to also create a new custom export program to export the existing BOM versions of materials in an Excel file, directly with the same agreed layout to be later used for importing and creating a new BOM version. Thus, users would make the required changes for the BOMs directly on the Excel file, without the need of changing any layout.

The flow chart of the final solution for massive exporting and importing version BOMs is the following:

Image 11. Flow chart of the final solution for massive exporting and importing version BOMs

The selection screen and output list of the new program to export version BOMs to Excel are displayed on below images:

Image 12. Selection screen for program to export version BOMs to Excel.

Image 13. Output list for program to export version BOMs to Excel.

Columns colored in orange are the ones to be exported to Excel, that is, the ones which have been agreed to later be imported from the Excel to create the new BOM version (agreed layout). Rest of columns are calculated fields (basically descriptions). The implemented stripped Zebra pattern uses the same color for all the lines belonging to the same material BOM version (same plant, material, usage, alternative, and BOM version), to provide a visual help for fast identification of the components of the same BOM.

The exportation to Excel format is a customized feature. We have a header row in bold grey and several rows with the data values. Key fields of the different BOM levels (header, item, item effectivity) are on italics. The layout to be shared by both programs is the following:

Image 14. Excel layout to be shared by both programs.

The selection screen and output list of the new program to import version BOMs from Excel are displayed on below images:

Image 15. Selection screen for program to import version BOMs from Excel.

Image 16. Output list for program to import version BOMs from Excel.

Before creation of the new BOM versions can take place, several verifications are done to assure the data imported is correct. Basically, the existence of the different objects (plant, assembled material, component, item category, special procurement type, production supply area, model) is verified, together with some other additional checks.

Both APIs MPE_VERSNBOM_CREATE_INITIAL and MPE_VERSNBOM_CREATE_VERSION used for new BOM version creation allow execution without commit, so there are two possible execution modes:

• Test Mode: the BOM creation is simulated, and all the messages returned by the API are displayed on the execution log, but BOMs are not saved on the database.
• Execution Mode: the BOMs are saved on the database.

With this program more than one version BOM can be uploaded each time, thus increasing the agility of the users working with BOM management. For the performance’s sake of the program, there is a limit of records on the imported Excel file, delimited by the field “Maximum Records”, which can be customized as desired.

After the execution process, the execution log is displayed, but it is also saved as a specific application log to be later monitored in case of issues.

Image 17. Execution log for program to import version BOMs from Excel.

Image 18. Application log for program to import version BOMs from Excel.