S2C 404 ยท AT THE KEYBOARD
S2C Configuration Workbench
Configure and prove one shared service commercial spine while making the execution architecture explicit: standard S/4HANA Service, In-House Service / Depot Repair, Field / Advanced Execution, SAP Field Service Management integration where selected, and classic CS / DIP only where still relevant.
WORKBENCH ENVELOPE
One commercial core, three execution branches
The commercial service process is shared, but execution architecture differs by service scenario. Configure the common controls once, then prove the evidence unique to each branch.
SERVICE COMMERCIAL CORE
- Request / Qualification
- Service Quotation / Contract
- Service Order
- Choose Execution Model
A - STANDARD S/4HANA SERVICE
- Service Order
- Service Confirmation
B - IN-HOUSE SERVICE / DEPOT
- Service Object Sent In
- In-House Service
- Repair Order
- Repair Confirmation
- Return
C - FIELD / ADVANCED EXECUTION
- Service Order
- Maintenance / Advanced Execution
- Technician / FSM
- Confirmation
THE S2C MEMORY MODEL
Foundation, promise, architecture, close, reconcile
Use this forest-before-the-trees model before opening configuration details.
Customer -> Site -> Service Object -> Installed Base -> Contract / Warranty→QUALIFY
Request -> Entitlement -> Priority -> SLA -> Quote / Promise→COMMERCIAL ORDER
Service Order→CHOOSE EXECUTION
Standard, In-House Service, or Field / Advanced Execution→COMMERCIAL CLOSE
Confirmation / Order -> Release for Billing -> Billing Document Request -> Invoice -> FI / AR -> Payment / Clearing→RECONCILE
Technical History + Execution + Cost + Revenue + Receivable
ARCHITECTURE DECISION
Choose execution before configuring details
STANDARD SERVICE
Service Order -> Service Confirmation.
IN-HOUSE SERVICE / DEPOT REPAIR
Customer Service Object -> In-House Service -> Repair Order -> Repair Confirmation -> Return.
FIELD / ADVANCED EXECUTION
S/4 Service -> Service with Advanced Execution -> Maintenance Execution Object -> SAP Field Service Management -> Schedule / Dispatch / Mobile -> Time / Parts / Findings / Acceptance -> S/4 Confirmation / Goods Movement.
Scope note: Advanced Execution is architecture / scope-dependent. Do not imply that every field-service scenario requires it.
CONFIGURATION WORKBENCH
Service identity
Who needs service, where is the work, and what exactly is being serviced? Entitlement depends on identifying both the correct customer and the correct technical object.
How the control works
WHO?
Business Partner -> Service Recipient.
WHERE?
Customer Site -> Functional Location.
WHAT?
Equipment -> Serialized Product / Service Object.
CONTEXT?
Installed Base -> Service History.
Technical Identity -> Contract / Warranty Determination -> Service History. The same visible customer problem can lead to a different promise or price when the service object, serial number, installed base, or service recipient is wrong.
Design and maintain in this order
Define Business Partner roles, service recipient, customer site, functional location, equipment, serial number, installed base, service object, service organization, and authorization scope at the level needed for entitlement, history, planning, and billing.
Configuration locator
SPRO - SAP S/4HANA -> Service -> Basic Settings; Cross-Application Components -> SAP Business Partner; Plant Maintenance and Customer Service -> Master Data -> Technical Objects
Partner roles, technical-object model, serial continuity, installed-base assignment, service history, authorization proof, and entitlement-ready identity.
CONFIGURATION WORKBENCH
Entitlement & promise
Are they covered, what is chargeable, and what date has the business promised? Service contracts, warranty, effective date, priority, and SLA determine the commercial promise before execution is configured.
How the control works
Customer + Service Object + Effective Date -> Applicable Contract / Warranty -> Coverage -> Chargeable / Non-Chargeable Scope -> Priority / SLA -> Promised Dates.
Why is the replacement part covered while labor or emergency travel remains chargeable? That answer proves the entitlement design better than a saved configuration screen.
Design and maintain in this order
Configure request categories, priorities, date rules, warranties, service contracts, entitlement checks, SLA profiles, catalogs, quote relevance, and request-status controls. Keep service contract management depth outside this minimum spine.
Configuration locator
SPRO - SAP S/4HANA -> Service -> Basic Settings and Service Transactions; use IMG search for service request, service contract, warranty, priority, date profile, and status profile
Explainable contract or warranty, coverage scope, chargeable and non-chargeable split, priority, promised dates, owner, request status, and exception route.
CONFIGURATION WORKBENCH
Service order control
The Service Order is the commercial control object for the service. Do not let configuration lists replace the business-object dependency from request through qualification, optional quotation, release, execution, and confirmation.
How the control works
Service Request -> Entitlement / Qualification -> Service Quotation (optional) -> Service Order -> Release -> Execution -> Service Confirmation.
Transaction type determines the kind of service document. Item category determines how labor, parts, expenses, fixed-price items, and billing relevance behave.
Design and maintain in this order
Configure service transaction types, item categories, service products, partner determination, organization determination, status profiles, pricing, account assignment, quotation behavior, and release rules.
Configuration locator
SPRO - SAP S/4HANA -> Service -> Service Transactions; Sales and Distribution -> Sales -> Sales Documents; Plant Maintenance and Customer Service -> Maintenance and Service Orders
Order structure, planned resources, service product, commercial terms, status progression, document flow, release proof, and execution-architecture decision.
CONFIGURATION WORKBENCH
Execution architecture
Choose the execution model before configuring order, confirmation, logistics, mobile, and billing behavior. Standard Service, In-House Service, and Field / Advanced Execution are legitimate but different architectures.
How the control works
STANDARD SERVICE: Service Order -> Service Confirmation.
IN-HOUSE SERVICE / DEPOT REPAIR: Customer Service Object -> In-House Service -> Precheck / Decision -> Repair Order -> Repair Execution -> Repair Confirmation -> Billing / Return.
FIELD / ADVANCED EXECUTION: Service Order -> Maintenance / Advanced Execution -> Technician / FSM -> Confirmation. Architecture / scope-dependent; do not imply every field-service scenario requires Advanced Execution.
Current SAP S/4HANA terminology uses In-House Service. Older releases and documentation may refer to In-House Repair.
Design and maintain in this order
Define the approved branch first. For depot, configure receipt, inspection, diagnosis, repair, component usage, testing, repair confirmation, return, and custody/status controls. For field or advanced execution, define the integration boundary to Maintenance execution and/or SAP Field Service Management; scheduling, dispatch, mobile, and FSM product setup belong in the relevant product, not in S/4 SPRO lists.
Configuration locator
SPRO - SAP S/4HANA -> Service -> Service Transactions; Plant Maintenance and Customer Service -> Maintenance and Service Processing; Materials Management -> Inventory Management and Physical Inventory; selected FSM or integration product where in scope
Architecture decision, branch-specific document chain, custody or dispatch evidence, resource and parts proof, repair or service confirmation, target integration status, and branch completion status.
CONFIGURATION WORKBENCH
Service Confirmation
Service Confirmation converts executed service into commercial and accounting evidence. It records what actually happened and provides the basis for downstream cost, stock, and billing behavior where applicable.
How the control works
Service Execution -> Service Confirmation -> Actual Time + Service Parts + Expenses + Findings -> Cost / Stock / Billing Relevance.
Compare planned work on the Service Order with actual labor, parts, travel, expense, findings, completion, and customer acceptance on the confirmation.
Design and maintain in this order
Define confirmation relevance, actual-work capture, parts and goods-movement relevance, expense capture, completion evidence, customer acceptance, follow-up controls, and the hand-off to costing and billing.
Configuration locator
SPRO - SAP S/4HANA -> Service -> Service Transactions; Plant Maintenance and Customer Service -> Maintenance and Service Orders; use IMG search for confirmation, completion, status, and goods-movement controls
Confirmed actuals, completion status, customer acceptance where required, stock or parts impact, cost basis, billing relevance, and follow-up requirement.
CONFIGURATION WORKBENCH
Billing & commercial close
Modern S/4HANA Service billing must show the Billing Document Request. Do not mix classic CS / DIP into the modern chain or make it look mandatory.
How the control works
Order / Confirmation -> Release for Billing -> Billing Document Request -> Customer Invoice -> FI / Accounts Receivable -> Payment -> Clearing.
FIXED PRICE
Service Order -> Release for Billing -> Billing Document Request -> Billing Document.
RESOURCE-RELATED SERVICE BILLING
Service Confirmation -> Actual Time / Parts / Expenses -> Release for Billing -> Billing Document Request -> Billing Document.
MODERN S/4HANA SERVICE
Service Confirmation -> Release for Billing -> Billing Document Request -> Billing.
CLASSIC CS / COMPATIBILITY PATH
Service Order Actuals -> Dynamic Item Processor -> Billing Request -> Billing. Classic CS / compatibility / scenario-dependent.
Fixed-price billing can be order-related, while resource-related billing uses confirmed actual service consumption.
Design and maintain in this order
Configure billing relevance, release for billing, Billing Document Request behavior, pricing, tax, account determination, settlement or cost flow where applicable, output, billing blocks, and FI/AR hand-off. Configure DIP only for classic CS, compatibility, or scenario-dependent designs where it is approved.
Configuration locator
SPRO - Sales and Distribution -> Basic Functions -> Pricing; Sales and Distribution -> Billing; Materials Management -> Valuation and Account Assignment -> Account Determination; Financial Accounting -> Accounts Receivable and Accounts Payable
Coverage decision, billing basis, Billing Document Request, customer invoice, accounting document, service cost, margin, receivable, payment, clearing, and technical/commercial reconciliation.
Transport and data boundary
Configuration: service transaction types, item categories, status profiles, service-order configuration, confirmation configuration, billing relevance, contract / entitlement rules, integration settings, and Advanced Execution integration settings where used.
Master / governed data: Business Partner, customer site, functional location, equipment, serial number, installed base, service product, service contract, warranty, service organization, and technician / resource data where applicable.
Transaction / execution data: service request, service quotation, service order, in-house service, repair order, service confirmation, repair confirmation, goods movements, Billing Document Request, customer invoice, FI document, payment, and clearing.
S2C / O2C / R2R handoff
S2CService Entitlement -> Service Execution -> Billing Basis.O2C / SD billing layerCustomer Billing Document.R2RReceivable -> Payment -> Clearing -> Accounting Reconciliation.PRACTITIONER MNEMONIC
Read the service result in seven questions
WHO / WHAT?
Customer + Service Object.
COVERED?
Contract / Warranty / Entitlement.
PROMISED?
Priority / SLA / Quote.
EXECUTED?
Service / Repair / Technician Work.
CONFIRMED?
Time / Parts / Findings / Acceptance.
BILLABLE?
Fixed / Resource Related / Covered.
ACCOUNTED?
Invoice / AR / Payment / Clearing.
TRANSACTIONAL PROOF
Run both golden paths before calling the design complete
Configuration screenshots are not proof. Reconcile business evidence, documents, quantities, values, statuses, inventory, and accounting.
- 01Depot golden path
Customer Reports Failure -> Identify Customer + Service Object -> Determine Contract / Warranty -> Create In-House Service -> Receive Object -> Inspect / Diagnose -> Create / Execute Repair Order -> Use Parts / Labor -> Repair Confirmation -> Return Object -> Release for Billing -> Billing Document Request -> Invoice / FI -> Reconcile Technical + Commercial Result. Record customer, service object or serial number, entitlement, receipt/custody status, repair order, component usage, labor/time, repair confirmation, return status, billing basis, invoice, and accounting result.
- 02Field-service golden path
Customer Service Need -> Identify Customer + Service Object -> Determine Entitlement / SLA -> Create Service Order -> Select Execution Architecture -> Schedule / Dispatch -> Technician Executes -> Capture Time / Parts / Findings -> Customer Acceptance -> Service / Execution Confirmation -> Release for Billing -> Billing Document Request -> Invoice / FI -> Reconcile.
- 03Controlled entitlement exception
Warranty Covers Part BUT Emergency Travel Is Chargeable -> Entitlement Determines Scope -> Execution Captures Both -> Covered Component Not Billed -> Chargeable Travel / Labor Billed -> Invoice Reconciles to Entitlement.
- 04Reconcile both commercial outcomes
Coverage, confirmations, billed value, tax, service cost, margin, technical history, receivable, payment, clearing, and accounting reconciliation agree with each scenario.
FINAL PRINCIPLE
One Service Need, One Reconciled Commercial Outcome
Configuration is complete only when a service need can be correctly identified, entitled, executed through the selected service architecture, confirmed, billed, and reconciled to the technical history and financial result. Settings are not evidence.
Apply both paths inside workshops, testing, migration, cutover, dispatch readiness, billing controls, and stabilization.