Turns a service request into a dispatched visit: the dispatcher picks the engineer and parts, the engineer closes the job on mobile, and the service order is confirmed for billing.
Today the service desk types the request into the ERP, the dispatcher plans the day on a whiteboard, and the engineer reports the visit on paper that reaches billing a week later. Whether the visit is covered by warranty is checked at invoicing, when the customer disputes it.
A customer or the service desk submits the request against a serial number, and the app reads the equipment's warranty and entitlement so everyone sees at once whether the visit is covered or billable. The dispatcher sees the engineers of the region with their skills and the visits already assigned, picks one, and adds the parts as lines on the service order. The engineer receives the visit on the mobile screen, confirms arrival, records the parts used and the hours, takes the customer's signature and closes the job. The app confirms the service order in the ERP with the actual quantities, so the invoice or the warranty claim follows the same day.
| Lane | Does |
|---|---|
| Customer | requests the visit on the portal screen against the serial number; signs on the engineer's phone |
| Service desk | checks the request, sets the priority and the coverage |
| Dispatcher | assigns the engineer and the parts; moves visits when the day changes |
| Field engineer | completes the visit on mobile: arrival, parts, hours, signature |
Every screen renders for desktop and mobile; portal screens are the same screens delivered to an outside login.
| Screen | What is on it |
|---|---|
| S01 Service request | portal screen: serial number, fault description, photo, preferred window; coverage shown from the warranty; submit |
| S02 Dispatch board | engineers of the region by day with assigned visits, skills and travel; open requests by priority and coverage; drag to assign |
| S03 Order lines | service order with the visit line, parts lines with quantity and price, labour line; add and remove |
| S04 Engineer mobile | today's visits with address, contact, fault and parts; arrive, parts used, hours, notes, customer signature, close |
| S05 Confirmation | actual parts and hours against planned; billable or warranty; confirm to the ERP |
| S06 Service board | visits per day and engineer, first-time fix rate, response time by priority, open requests |
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 |
|---|---|---|
| Sales order line | the service order and its lines for the visit, parts and labour | S/4HANA · Oracle Fusion · Salesforce · Snowflake |
| Warranty | equipment, serial number and coverage dates | S/4HANA · Oracle Fusion · Salesforce · Snowflake |
| Customer master | site, contact and terms | S/4HANA · Oracle Fusion · Salesforce · Snowflake |
| Employee | the engineers of each region and their org unit | S/4HANA · Oracle Fusion · Salesforce · Snowflake |
| Object | What changes |
|---|---|
| Sales order line | service order created with the visit, parts and labour lines; confirmed quantities and completion written when the engineer closes the job |
Start: A customer submits S01 on the portal screen, or the service desk logs a request from a call or from the service case in the CRM.
| Step | Moves when |
|---|---|
| Request logged | serial number matched to the equipment; coverage set from the warranty; priority set |
| Dispatched | engineer and parts assigned; service order created in the ERP; customer told the window |
| On site | engineer confirms arrival on mobile; the response clock stops |
| Job closed | parts used, hours and signature recorded; a follow-up visit created when the fault stays open |
| Order confirmed | actual quantities written to the service order; invoice or warranty claim released |
| Component | Trigger → action → outcome |
|---|---|
| fld_serial | on change → read the equipment and its warranty → show covered or billable with the end date |
| brd_dispatch | on drop → check the engineer's skills and the day's load → create the service order with the visit line, notify the engineer and the customer |
| btn_close_job | on click → write parts used, hours and the signature image → move the order to confirmation, open S05 |
| btn_confirm | on click → call the order change interface with the actual quantities → store the confirmation, close the request, refresh S06 |
| Step | Time limit and escalation |
|---|---|
| Response | by priority: 4 hours for a line down, 2 working days for routine; then the dispatcher is reminded and the service manager is copied |
| Confirmation | 1 working day after the job closes, then the dispatcher is reminded |
Names, places and figures are illustrative; the pattern is the catalogue's.
At 07:40 a packaging plant near Turin reported a filler stopped, and the app matched the serial number to a machine under warranty until March. The dispatcher, Giulia, saw that Luca was 25 minutes away with the drive belt on his van and dropped the visit into his morning. Luca arrived at 08:35, replaced the belt, recorded 1.5 hours and the part on his phone, and the plant manager signed the screen at 10:10; the service order was confirmed at 10:12 and the warranty claim went out that afternoon.
The objects with their real names, the criteria in that system's fields, the write interface and what to set up first.
Sales order line read from VBAK · VBAP · VBEP; also on SAP ECC.
Open the S/4HANA page →Sales order line read from Order Management REST: salesOrdersForOrderHub · lines; also on Oracle E-Business Suite.
Open the Oracle Fusion page →Sales order line read from Order · OrderItem; CRM.
Open the Salesforce page →Sales order line read from CONFORMED.SALES_ORDER_LINE; lakehouse.
Open the Snowflake 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, Salesforce, Snowflake, 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.
