Collects each function's view of a new material on its own screen, checks duplicates and completeness, and creates the record in the ERP when every view is released.
Today a new material is a spreadsheet passed around by email, and the master data team types the views into the ERP once the last column arrives. A missing lead time or valuation class is found when the first order is blocked.
The app defines the four functions that own a material master and the levels in each: the requester and sales operations, engineering, planning and purchasing, and finance. Each level has its own screen with only the fields of its view, pre-filled from a similar material when one exists, and validated against the rules of the material type and the plant. A duplicate check runs on the description and the classification before anyone fills a view. When every view is released, the app creates the material through the released interface, reads the record back, and shows the number to everyone involved.
| Function | Level | Does |
|---|---|---|
| Product and sales | Level 1: requester | proposes the material with description, type, base unit and product hierarchy |
| Product and sales | Level 2: sales operations | completes the sales view per sales organisation: item category, tax class, minimum order |
| Engineering | Level 1: engineer | fills the basic data: dimensions, weight, classification, drawing number |
| Engineering | Level 2: engineering lead | releases the design data |
| Planning and purchasing | Level 1: planner | fills the plant view: MRP type, lead time, lot size, safety stock |
| Planning and purchasing | Level 2: buyer | fills the purchasing view: purchasing group, source of supply, order unit |
| Finance | Level 1: cost accountant | sets valuation class, price control and standard price |
Every screen renders for desktop and mobile; portal screens are the same screens delivered to an outside login.
| Screen | What is on it |
|---|---|
| S01 Request | description, material type, base unit, product hierarchy, plants, sales organisations, reason; similar-material search with copy-from; submit |
| S02 Duplicate check | candidate records by description and classification with a similarity score; confirm new, or use the existing record and close |
| S03 Engineering view | dimensions, weight, classification, drawing number, hazardous flag; release button |
| S04 Planning and purchasing view | per plant: MRP type, lead time, lot size, safety stock, purchasing group, source of supply; release button |
| S05 Sales view | per sales organisation: item category, tax class, minimum order quantity, initial price; release button |
| S06 Finance view | valuation class, price control, standard price, costing lot size; release button |
| S07 Tracker | requests by stage, view completeness per function, owner, age; material numbers created |
The first object is the main one; each system page shows the real table or resource behind every handler.
| Object | Why the app reads it | See it on |
|---|---|---|
| Material master | existing records for the duplicate check and the copy-from; the created record read back | S/4HANA · Oracle Fusion · Snowflake · Databricks |
| Bill of materials | structures where the new material is a component or a parent | S/4HANA · Oracle Fusion · Snowflake · Databricks |
| Supplier master | the source of supply for a purchased material | S/4HANA · Oracle Fusion · Snowflake · Databricks |
| Price condition | the initial sales price condition for a sold material | S/4HANA · Oracle Fusion · Snowflake · Databricks |
| Object | What changes |
|---|---|
| Material master | material master created with basic, plant, purchasing, sales and accounting views through the material interface; status set to active when every view is complete |
| Price condition | initial sales price condition created for a sold material with its validity |
Start: A requester submits S01.
| Step | Moves when |
|---|---|
| Request submitted | duplicate check shows candidates below 80 percent similarity, or the requester confirms the record is new |
| Views assigned | each function sees its screen with the fields pre-filled from the copy-from material; clocks start |
| Views released | every required field of the view present and valid for the material type and plant; the function releases |
| Finance released | valuation class and price present; the record is ready to create |
| Record created | material number returned from the ERP; views read back and shown; requester informed |
| Component | Trigger → action → outcome |
|---|---|
| fld_description | on change → search existing materials by description and classification → show candidates above 80 percent similarity on S02 |
| btn_release_view | on click → check the required fields for the view, the material type and the plant → mark the view complete, notify the next function where the sequence needs it |
| btn_create | on click → call the material interface with every released view → store the material number, read the record back and show it on S07 |
| grd_tracker | on load → list open requests with the view each waits on and its age → flag any view past its 2-day clock |
| Step | Time limit and escalation |
|---|---|
| Each view | 2 working days, then the function's level 2 is reminded |
| Whole request | 7 working days, then the master data lead is copied |
Names, places and figures are illustrative; the pattern is the catalogue's.
Hannah, a product manager in Manchester, requested a 500 ml variant of a bottle at 09:30 on a Monday; the duplicate check showed the 330 ml record, so she copied its views as a starting point. Engineering released its view by 14:00, planning set the lead times for both plants on Tuesday, and finance set the standard price on Wednesday at 10:50. The material number appeared at 11:05 the same day, and the planner raised the first purchase requisition against it after lunch. The tracker showed the master data lead 23 other requests and the view each one waited for.
The objects with their real names, the criteria in that system's fields, the write interface and what to set up first.
Material master read from MARA · MARC · MAKT; also on SAP ECC.
Open the S/4HANA page →Material master read from Product Hub REST: itemsV2; also on Oracle E-Business Suite.
Open the Oracle Fusion page →Material master read from CONFORMED.MATERIAL; lakehouse.
Open the Snowflake page →Material master read from silver.material; lakehouse.
Open the Databricks page →Other systems connect through the same handlers; see how SmartApps connect.
About 30 minutes to a first running screen on your live rows, and 7 working days to the production-grade version described here, most of it spent agreeing screens and criteria with the process owner.
Any of SAP S/4HANA, Oracle Fusion Cloud, Snowflake, Databricks, with the objects read in place; the pages above show the objects and the write path for each. Two systems at once is one handler per object per system.
Every role in this app is inside the company; an outside role can be added as a lane with a portal screen.
Every step, value, decision, notification and write-back acknowledgement of every instance, with the version of the app, append-only.
Bring the process and the systems it touches. In the first session we register the data handlers, draw the levels or the lanes and run the first screen on your live rows.
