1.0 Overview




 The Bill of Materials (BOM)  is a complete, structured list of the components (raw, packaging, intermediates) with their quantities to be used for the production of a material. The list contains the description, the quantity, and unit of measure. The components are known as  BOM  items.

The objective of the application is to extract from WP1 & PF1 SAP systems Bill of Material data and explode Production Planning BOM level by level with components data. Then data is then consumed by downstream application ( Dynasys) via a generated flat file.

Describe the key User profiles that exist for the application. 

General role/Viewer role:

Approver role:

Target Users:

Manufacturing teams also Purchasing and Supply chain colleagues TBC with SME

VERSION

DATE

MODIFIED BY 

DESCRIPTION

0.01

20.10.2023

Abidemi Raji

Initial draft

0.02

10/14/2023

Abidemi Raji

Update





 

Data Product Type 
  • Dashboard
  • Report
  • Advanced analytics
  • AI 
  • Others <specify which one>
Technologies
  • BW
  • Tableau
  • Qliksense
  • Talend
  • Dataiku
  • Others <specify which one>

Data Sources 

Note: list of all applications and various environment

  • SAP PF1 (Production environment)
  • SAP WP1
  • SAP PI1
  • BW (versions)
  • iCare CRM 
  • CORE CRM
  • Others <specify the name of the source> 

2.0 Business Process


Capture the business process that the application supports . This can be describe through a process diagram or a business capability model

A bill of materials (BOM) is a comprehensive inventory (a structured list) of the raw materials, assemblies, subassemblies, parts and components, as well as the quantities of each needed to manufacture a product.  The BOM describes  how products are characterized, composed, produced, and configured . Every month a manual extract is done of BOM Data from ERP SAP system. The goal is to extract data from SAP to BW and automatically generate BOM data level by level in a flat file format and send this file to Dynasys for import. 

  • BoMs are plant-specific. The list of components used to produce a product in 1 plant may be different than in another. For products which can be produced in more than 1 plant, selecting the right plant or calculating a blended average BoM is an important design topic.
  • BoMs can have multiple alternatives, even within the same plant. Typically there is one "most likely" alternative that is used as a base assumption for costing & pricing, but selecting the right alternative is another important topic.
  • A regular BoM contains the components for a single production step. The production of many products requires multiple production steps and intermediate materials, which may span multiple plants. Combining together the BoM data of each of those production steps is called a "BoM explosion" and the result is a multi-level BoM that shows all the raw materials and intermediate production steps required to produce a product "from start to finish".





Bill of Materials features:

  • Output:
    • Usage
      • 1 for production
      • 3 for subcontracting (3 = universal)
    • plant
    • Alternative #
      • may be several bills of materials in the same plant for the same output
    • Quantity of output
      • Note: unit of measure = base unit of measure.
  • For each Input:
    • Quantities of input
    • Unit of measure = free, provided that a standard or custom conversion exist for this material
      • Unit of measure of the BOM item shows in the cost estimate
      • Unit of measure of the BOM item shows in the list of components of Planned Orders/Process Orders
    • Default issue storage location
      • Overwrites the default from the Material Master
    • Costing relevance flag
      • Is the price of the component taken into account in cost estimates of the output product
    • Issue storage location
      • Note: if not blank, overwrites the default storage location (view MRP2 of the input material master)
    • Phantom flag
      • Used to reference to another output material’s bill of material
    • Component Scrap
      • Increase component usage accordingly
    • Net Indicator
      • Clear out other all other scrap factors (assembly scrap, if any)
      • Note: assembly scrap may be regarded as output product scrap
    • Recursivity flag
      • Allows an input and the output to be the same
      • Used when recycling output material



To create a BOM


Use  transaction : Create Bill of Materials

  • IB01   to create an Equipment BOM
  • IB11 to create a Functional Location BOM
  • CS01 to create a Material BOM (for an Assembly)




3.0 Application Feature Overview


N/A







4.0 Functional Specification


4.1 General Data/Calculations 

This section will approach the concepts/definitions that will be used in all the reports and required to understand the data from the reports.

Could be specific fields, closing activities, additional information to work and understand the reports.



BOM  Data Flow


4.2 Process Detail 



4.2.1.  Report/Process Definition 


BOM Master Data 

BOM Number master data (C_BOMNUM) is loaded by the datasource DTS_ZBW_V_MAST_STKO.

The Datasource is based on SAP tables MAST (Material to BOM Link) and STKO (BOM Header) => View ZBW_V_MAST_STKO

In view ZBW_V_MAST_STKO, we keep only entries from STKO with BOM Status (STLST) is not equal to 2 (inactive BOM) and BOM usage (STLAN from MAST) is equal to '1' (Production).

There are 2 fields used to filter data during extraction and loading on BW : 

  • AEDAT (STKO)
  • ANDAT (MAST)

For more explanations, see part Data Loading

BOM Item Master Data 

BOM Item master data (C_BOMITM) is loaded by the datasource DTS_ZBW_EXTRACT_BOM_ITEM.

The datasource is based on specific function module ZBW_EXTRACT_BOM_ITEM.

In this function module we call the standard function  CSAP_MAT_BOM_ITEM_SELECT to extract each item for a given material/plant.

There are 2 fields used to filter data during extraction and loading on BW : 

  • AEDAT (STPO)
  • ANDAT (STPO)

For more explanations, see part  Data Loading.

BOM Level determination

The most important need of this dataflow is to extract (and explode) all BOM items and components for a given product. 

A specific BW extractor has been developed to build the Bill of Material from SAP WP1 source system : DTS_ZBW_MAST_BOM_LEVEL.

There are 2 fields used to filter data during extraction and loading on BW : 

  • AEDAT (STPO)
  • ANDAT (STPO)

For more explanations, see part Data Loading.

The extractor is based on view  ZBW_V_MAST  and in particular from MAST table to keep all Bill of material to explode and the class ZDTS_ZBW_MAST_BOM_LEVEL is used to extand the datasource adding new fields.

In view ZBW_V_MAST, we keep only entries from STKO with BOM Usage (STLTY) = M (Material) and BOM Status (STLST) is not equal to 2 (inactive BOM).

In the class, we use the standard function module 'CS_BOM_EXPL_MAT_V2' to build the Bill of material and BOM level. The function module is used as recursive function, as long as BOM exists and have to be explode.

Today we only explode BOM at level 1 (Master material and its components at first level).

We filter records from MAST to have only data with :

  • BOM usage (STLAN) is equal to '1' (Production).
  • BOM deletion flag (LOEKZ) is not equal to 'X'.
  • BOM valid from date (DATUV) is greater than current date.

Additional filter is done during extraction to keep  only one alternative BOM for the material exploded.

To get this alternative BOM, we select  the first valid production version  (excluding locked production version) from MKAL table.


This section represents the process with detail information for the application. Can include specific or special cases, complex logics , calculations, flows, among others.



5.0 Non-functional Descriptions 


Please populate the relevant section and delete those that are not applicable.

5.1 Usability

Usability is about the ease with which a User can learn to start using the solution and the ease with which they can use the system.  In addition to ease of learning and ease of use, usability also includes areas such as ease of recall, error avoidance and handling, accessibility among others e.g., 99% of metadata entry Users who have use the Maintenance Dashboard should be able to change filters, extract etc., when required.  Maintenance data will be centrally stored in the Google Cloud platform, which will be available to other applications e.g., and Dashboards if needed.

5.2 Regulatory Compliance

Software systems must comply with legal and regulatory e.g., GDPR requirements, this can change depending on country, organisation industry and / or region.  The software systems must be secure from unauthorized access.  The Maintenance Dashboard will comply with Solvay’s regulations and compliance e.g., access only granted to authorized Users.

5.3 Security

Security refers to essential aspects that assure a solution and its components will be protected against unauthorized access or malware attacks.  Important considerations related to security aspects of a system are User authentication, User authorization or User access privileges, data theft, malware attacks, data encryption, and maintaining audit trails, e.g., only Users with administrator access shall be able to create new accounts and assign data access privileges to the new accounts e.g.,

  • All data will be encrypted in the dashboard
  • Only authorised Users / Administrative Users will be able to access data.
  • Maintenance data will be split between either SCO or ECO, and Users will only have authority to one Entity data.

5.4 Performance

Performance defines how fast a software system or a particular section of it responds to certain User actions under a certain workload.  In most cases, this metric explains how long a User must wait before the target operation happens e.g., the page renders, a transaction is processed, etc., given the overall number of Users now.  Performance requirements may describe background processes invisible to Users, e.g., backup and speed of data transfers. 

5.5 Reliability

Reliability is the ability of a solution or its component to perform its required functions without failure under predefined conditions for a specified time / period.  Reliability can possibly be specified in terms of average time system runs before failure occurs, percentage of operations completed successfully within a time / period, maximum acceptable failure probability, or number of failures within a period.  Reliability aspects are in reference to (but not limited to) evaluation of the system to be considered as reliable, classification of reliability defining failures vs. regular failures, and the impact of failure on business operations.  The Maintenance Dashboard will display data from the previous refresh of data.   

5.6 Scalability

Scalability refers to the degree to which a solution can evolve to handle increased amounts of work.  The increased amount of work could be in terms of the user base, transactions, data, network traffic, or other factors e.g., the system should be able to handle an additional load of a maximum of 5,000 Users every month for the next 6 months without any noticeable performance impacts.  

5.7 Compatibility

Interoperability is the degree to which the solution is compatible with other components.  It is a measure of how effectively the system interoperates with other software systems and how easily it integrates with external hardware devices.

Interoperability aspects to be discussed during elicitation are in reference to (but not limited to) software systems to be interfaced with along with data / messages to be exchanged and any standard data formats, hardware components to be integrated with, and any standard communication protocols to be followed e.g., Order Management system will push the order file into a secured file transfer protocol server from where it will be loaded into the system through a daily job.  To guarantee between Google Cloud platform and SAP BW Queries e.g., BW_QRY_MVPMOR01_0002, Solvay has introduced a new tool called Xtract (Xtract).

5.8 Availability

Availability is the degree to which the solution is operable and accessible when required. It is a measure of time during which the system is fully operational e.g., available for use and sometimes included as a Service Level Agreement (SLA) considering its criticality to the business, e.g., the system shall be at least 99% available on weekdays between 09:00 to 18:30 Central European Time (CET).

5.9 Refresh of the Data

Frequency, data, and time of the data refresh in the data product.