Takes a new supplier from the first request to an approved, usable vendor record in the ERP, with every check and signature recorded.
Today a new supplier is a chain of emails between the buyer, the supplier, finance and compliance, and the vendor master is typed in at the end from an attachment.
A buyer starts the request with the supplier's basic details. The supplier completes its own profile on a portal screen, uploads certificates and bank confirmation, and signs the terms. Compliance screens the supplier, finance checks the bank details and payment terms, and the category lead approves. The app then creates the vendor record in the ERP through the released interface and shows the new number to everyone involved.
| Lane | Does |
|---|---|
| Buyer | starts the request and answers the supplier's questions |
| Supplier | fills in the profile, uploads documents, signs |
| Compliance | runs the sanctions and conflict checks, records the result |
| Finance | verifies bank details and sets payment terms |
| Category lead | approves and releases the record |
Every screen renders for desktop and mobile; portal screens are the same screens delivered to an outside login.
| Screen | What is on it |
|---|---|
| S01 New supplier request | supplier name, country, category, spend estimate, reason; submit |
| S02 Supplier profile | portal screen: legal entity, addresses, contacts, tax numbers, bank details, certificate uploads, terms signature |
| S03 Compliance check | screening result, conflict declaration, risk class; pass or return with a note |
| S04 Finance check | bank confirmation, payment terms, currency, withholding; approve or return |
| S05 Approval | summary of every check; approve, return or reject; note |
| S06 Tracker | all requests by stage, age and owner; overdue steps |
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 |
|---|---|---|
| Supplier master | existing records, to prevent a duplicate and to read the number once created | S/4HANA · Oracle Fusion · Snowflake · Databricks |
| Purchasing contract | any agreement already in place with the supplier | S/4HANA · Oracle Fusion · Snowflake · Databricks |
| Purchase order line | open orders that wait for the new supplier | S/4HANA · Oracle Fusion · Snowflake · Databricks |
| Object | What changes |
|---|---|
| Supplier master | vendor record created with addresses, bank details, payment terms and purchasing data; block removed after approval |
Start: A buyer submits S01.
| Step | Moves when |
|---|---|
| Request submitted | duplicate check against existing vendors; supplier invited |
| Profile complete | all required fields and documents present; terms signed |
| Compliance passed | screening result recorded as pass |
| Finance passed | bank confirmation attached and terms set |
| Approved | category lead approves; vendor created in the ERP; number shown |
| Component | Trigger → action → outcome |
|---|---|
| btn_invite | on click → create the portal user for the supplier contact → send the invitation, start the 10-day clock |
| btn_screen | on click → call the screening service with the legal entity → store the result and set the risk class |
| btn_create_vendor | on click → call the ERP vendor interface with the profile values → store the vendor number, close the request |
| Step | Time limit and escalation |
|---|---|
| Supplier profile | 10 working days, then the buyer is reminded and the request is flagged |
| Compliance and finance | 3 working days each, then the step escalates to the function's lead |
Names, places and figures are illustrative; the pattern is the catalogue's.
Daniel, a buyer in Rotterdam, started a request for a packaging supplier at 10:20 on a Monday. The supplier finished its profile on Tuesday, compliance passed it on Wednesday morning and finance confirmed the bank details after lunch. The category lead approved on Thursday, the vendor number appeared in the ERP a minute later, and the first purchase order went out the same day. The tracker showed 14 other requests and which step each one was waiting on.
The objects with their real names, the criteria in that system's fields, the write interface and what to set up first.
Supplier master read from LFA1 · LFB1 · LFM1 (business partner in S/4); also on SAP ECC.
Open the S/4HANA page →Supplier master read from Procurement REST: suppliers · supplierSites; also on Oracle E-Business Suite.
Open the Oracle Fusion page →Supplier master read from CONFORMED.VENDOR; lakehouse.
Open the Snowflake page →Supplier master read from silver.vendor; 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 6 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.
Roles on portal screens see only the rows the access policy allows, and their steps are logged like everyone else's.
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.
