Finds purchase order lines that will arrive late, gives each to its buyer with the supplier's reply, and updates the order once a decision is made.
Today a buyer learns about a late line when a planner calls. The order history sits in the ERP, the supplier's promise sits in email, and the decision is written down in a spreadsheet.
The app watches every open order line against its delivery date and the goods receipts posted so far. A line that is late, or will be late by the supplier's own confirmation, opens a case for its buyer with the vendor's contact, the planner who needs the material and the stock the line covers. The buyer asks the supplier through the portal screen, records the answer and chooses an action; the app updates the order in the ERP and confirms it.
| Lane | Does |
|---|---|
| Buyer | reviews the late line, asks the supplier, decides |
| Supplier | replies with a new date or quantity on the portal screen |
| Planner | confirms whether the new date covers demand |
| Buyer lead | decides escalations and alternate sources |
Every screen renders for desktop and mobile; portal screens are the same screens delivered to an outside login.
| Screen | What is on it |
|---|---|
| S01 Late lines | grid of late order lines with days late, value and supplier; filter by plant and buyer; open button |
| S02 Line detail | order, schedule lines, receipts to date, stock covered, planner note; ask-supplier and decide buttons |
| S03 Supplier reply | portal screen for the supplier: new date, new quantity, reason; submit |
| S04 Decision | options: accept new date, split, cancel and re-source; note; approve |
| S05 Board | open cases by buyer, age, value; escalations due today |
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 |
|---|---|---|
| Purchase order line | open order lines, delivery dates, received quantities | S/4HANA · Oracle Fusion · Snowflake · Databricks |
| Supplier master | supplier contact and block status | S/4HANA · Oracle Fusion · Snowflake · Databricks |
| Stock position | what the line covers | S/4HANA · Oracle Fusion · Snowflake · Databricks |
| Planned order | the demand the line feeds | S/4HANA · Oracle Fusion · Snowflake · Databricks |
| Object | What changes |
|---|---|
| Purchase order line | confirmed delivery date and quantity updated on the schedule line; note added |
Start: An open order line whose delivery date is within 5 days, or has passed, and whose received quantity is below the ordered quantity.
# start criterion, in canonical fields; each system page shows it in that system's fields
{po.delivery_date} <= today + 5 and {po.received_qty} < {po.qty}| Step | Moves when |
|---|---|
| Late line detected | case opened for the buyer of the purchasing group |
| Supplier asked | portal message sent; clock of 8 working hours starts |
| Reply received | planner sees the new date; confirms cover or flags a gap |
| Decision | buyer chooses; a cancel above 50,000 goes to the buyer lead |
| Order updated | schedule line changed in the ERP; acknowledgement stored; case closed |
| Component | Trigger → action → outcome |
|---|---|
| btn_ask_supplier | on click → create portal message from S02 values → start the 8-hour clock, notify the supplier contact |
| dd_decision | on change → show the fields the option needs → enable btn_approve when a note is present |
| btn_approve | on click → call the ERP change interface → store the acknowledgement, close the case, refresh S01 |
| Step | Time limit and escalation |
|---|---|
| Supplier reply | 8 working hours, then the buyer is reminded and the buyer lead is copied |
| Buyer decision | 2 working days, then the case escalates to the buyer lead |
Names, places and figures are illustrative; the pattern is the catalogue's.
At 08:14 the app opened 31 cases for the Penang plant, 9 of them above 50,000. Priya, the buyer for connectors, asked two suppliers before 09:00 and had answers by 11:30; one new date covered demand, the other left a 2-week gap, so she split the line and the planner released the alternate source the same afternoon. The board showed the plant lead every case, its age and its value, and the audit record showed who decided what and when.
The objects with their real names, the criteria in that system's fields, the write interface and what to set up first.
Purchase order line read from EKKO · EKPO · EKET · EKBE; also on SAP ECC.
Open the S/4HANA page →Purchase order line read from Procurement REST: purchaseOrders · lines · schedules; also on Oracle E-Business Suite.
Open the Oracle Fusion page →Purchase order line read from CONFORMED.PURCHASE_ORDER_LINE · HISTORY.PO_LINE_VERSIONS; lakehouse.
Open the Snowflake page →Purchase order line read from silver.purchase_order_line · gold.po_line_versions; 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 4 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.