Opens a case 90 days before a purchasing contract expires, shows consumption against target value, and carries the renew, renegotiate or lapse decision through legal and the category lead.
Today a buyer learns that a contract has expired when the ERP stops a call-off against it, and the consumption figure comes from a report run for the occasion. Legal receives the new terms as a scanned attachment.
The app watches every purchasing contract's validity and opens a case 90 days before expiry for its buyer, with 12 months of call-offs by month, consumption against the target value, the prices against the last 3 purchase orders and any open orders dated beyond expiry. The buyer chooses to renew, renegotiate or let the contract lapse and records the reason. For a renegotiation the supplier confirms prices and validity on the portal screen, legal reviews the changed clauses, and the category lead approves. The app then changes the validity and target value, or creates the new contract, in the ERP through the contract interface.
| Lane | Does |
|---|---|
| Buyer | reviews consumption and prices and proposes the option |
| Supplier | confirms new prices and validity on the portal screen and uploads the signed document |
| Legal | reviews changed clauses |
| Category lead | approves the renewal or the lapse |
Every screen renders for desktop and mobile; portal screens are the same screens delivered to an outside login.
| Screen | What is on it |
|---|---|
| S01 Expiring contracts | grid of contracts with supplier, valid-to, target value, released value as a percentage, call-offs in the last 12 months, days to expiry; filter by category and buyer; open button |
| S02 Contract review | consumption chart by month, contract prices beside the last 3 purchase orders, supplier block status and payment terms, open orders dated beyond expiry; options: renew, renegotiate, lapse; reason; submit |
| S03 Supplier terms | portal screen: proposed validity, target value and price list; accept or counter; upload of the signed document |
| S04 Legal review | changed clauses highlighted against the current contract; approve or return with a note |
| S05 Approval | summary with consumption, price change in value, legal result; approve or return; note |
| S06 Tracker | contracts by stage and days to expiry; contracts lapsing this month; value renewed this quarter |
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 |
|---|---|---|
| Purchasing contract | validity, target value, released value and buyer | S/4HANA · Oracle Fusion · Snowflake · Databricks |
| Purchase order line | call-offs against the contract in the last 12 months and open orders beyond expiry | S/4HANA · Oracle Fusion · Snowflake · Databricks |
| Supplier master | block status, payment terms and contacts | S/4HANA · Oracle Fusion · Snowflake · Databricks |
| Supplier invoice | amounts paid against the call-offs | S/4HANA · Oracle Fusion · Snowflake · Databricks |
| Object | What changes |
|---|---|
| Purchasing contract | validity and target value extended, or a new contract created with the agreed prices; a lapse recorded with the reason |
| Purchase order line | open order lines dated beyond expiry moved to the new contract or closed |
Start: A purchasing contract whose validity ends within the next 90 days.
# start criterion, in canonical fields; each system page shows it in that system's fields
{contract.valid_to} <= today + 90 and {contract.valid_to} >= today| Step | Moves when |
|---|---|
| Contract selected | case opened 90 days before expiry for the buyer with 12 months of consumption and open orders beyond expiry |
| Option chosen | buyer chooses renew, renegotiate or lapse with a reason; consumption below 30 percent needs a note for the category lead |
| Supplier terms | for a renegotiation the supplier confirms prices and validity on the portal within 10 working days |
| Legal cleared | changed clauses approved; a renewal with unchanged clauses skips this step |
| Approved | category lead approves; above 1 million the head of procurement signs as well |
| Contract updated | validity and target value changed, or the new contract created, in the ERP; open orders beyond expiry moved; case closed |
| Component | Trigger → action → outcome |
|---|---|
| dd_option | on change → show the fields the option needs (new validity, target value, price list or lapse reason) → route a renegotiation to the supplier and a lapse to the category lead |
| btn_send_terms | on click → create the portal request with the proposed terms → start the 10-day supplier clock |
| btn_legal_clear | on click → record the legal decision on the clause set → move the case to approval, notify the buyer |
| btn_update_contract | on click → call the ERP contract interface to change validity and target value or to create the contract → store the number, close the case, refresh S01 |
| Step | Time limit and escalation |
|---|---|
| Buyer proposal | 10 working days from case open, then the category lead is reminded |
| Supplier reply | 10 working days, then the buyer is reminded and the supplier's account manager is copied |
| Approval | 3 working days, then the case escalates to the head of procurement; a contract within 30 days of expiry moves to the top of S06 |
Names, places and figures are illustrative; the pattern is the catalogue's.
On 3 March the app opened a case for a logistics services contract expiring on 1 June, and showed Sofia, the category buyer in Milan, that 84 percent of the 2 million target value was consumed and that the rates sat 6 percent below the latest quotes. She chose to renegotiate at 10:15; the supplier confirmed new rates on the portal on 12 March, legal cleared the 2 changed clauses in a day, and the category lead approved on 17 March at 16:40. The new validity and target value reached the ERP the same minute, and the tracker showed 23 more contracts expiring that quarter, 4 of them set to lapse.
The objects with their real names, the criteria in that system's fields, the write interface and what to set up first.
Purchasing contract read from EKKO · EKPO (BSTYP = 'K' / 'L'); also on SAP ECC.
Open the S/4HANA page →Purchasing contract read from Procurement REST: purchaseAgreements · Enterprise Contracts REST: contracts; also on Oracle E-Business Suite.
Open the Oracle Fusion page →Purchasing contract read from CONFORMED.PURCHASING_CONTRACT; lakehouse.
Open the Snowflake page →Purchasing contract read from silver.purchasing_contract; 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 5 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.