Contents
- Why This Integration Matters
- Scope of the Integration
- What Gets Created in FSA
- Confirmation Flow
- Architecture Overview
- Master Data Considerations
- Error Monitoring and Operations
- Limitations
- Prerequisites
- CPI iFlow Configuration
- SSCUI Configuration Guide
- Quick Troubleshooting Guide
1. Why This Integration Matters
In large, asset-intensive enterprises, maintenance work doesn't happen in one place — it happens across dozens of plants, regions, and legal entities. Organizations running SAP S/4HANA Public Cloud use Plant Maintenance (PM) to manage the full lifecycle of assets and work orders. But the people who actually do the work? They're in the field, using SAP Field Service and Asset Management (FSA).
Without integration, field technicians are working blind — no order context, no planned materials, no status visibility. With PM-FSA integration:
- The right order reaches the right technician in real time.
- Technicians see equipment details, operations, materials, and priority before arriving on site.
- Completed work (time, materials, expenses) flows back automatically to S/4HANA.
- SLA adherence improves and asset downtime is reduced.
PM-FSA Integration Overview
SAP S/4HANA | ⇄ | SAP FSA |
PM Order Created Plant Maintenance | → | Service Call Created Technician dispatched |
Order Updated Time, materials, status | ← | Work Confirmed T&M Journal approved |
2. Scope of the Integration
S/4HANA → FSA
S/4HANA Object | FSA Object |
Maintenance Order | Service Call |
Order Operation | Activity |
BOM Component / Reservation | Reserved Material |
PM Notification (damage, problem) | problemType / description |
Key rules:
- A Reactive Maintenance Order replicates to FSA as a Service Call when its operation phase is set to Scheduling with sub-phase Ready for Schedule.
- Each order operation replicates as an FSA Activity.
- If the phase is reset from Scheduling back to Preparation, no update is sent to FSA. The Service Call retains its last known state — customers must manage consistency manually in this scenario.
- Planned stock and non-stock components replicate as Reserved Materials on the corresponding Activity.
- When a Maintenance Order is set to Technically Completed (TECO) in S/4HANA, the FSA Service Call status is automatically updated — provided phase mapping is configured. All Activities are set to CLOSED.
Note: If TECO is reversed, FSA Service Call and Activity statuses are not rolled back. This is a technical limitation of the FSA API.
FSA → S/4HANA
Service Call Updates
When a Service Call of type Maintenance is updated in FSA, the corresponding Maintenance Order in S/4HANA is updated accordingly.
Activity → Operation Updates
When an Activity on a Maintenance Service Call is modified in FSA, the following fields transfer back to the Maintenance Order operation:
- Description.
- Equipment.
- Duration.
- Planned Start and End Dates.
When an Activity is assigned to a technician and released in FSA, the Person Responsible on the Maintenance Order operation is updated and the operation phase is set to Execution with sub-phase Ready for Execution.
A new Activity created in FSA triggers creation of a corresponding new Maintenance Order operation in S/4HANA.
Confirmation Flow
After time effort or material (planned or unplanned) is approved in FSA:
FSA Action | S/4HANA Result |
Planned stock material consumed | Goods Movement 261 posted against the reservation |
Planned non-stock material consumed | Goods Receipt posted against the Purchase Order |
Unplanned stock material consumed | Goods Movement 261 posted against the Maintenance Order |
Expense confirmations approved | Financial Document (G/L posting) created |
After successful confirmation creation, the confirmation number is written back to the corresponding time-effort externalId in FSA — closing the loop between the two systems.
3. What Gets Created in FSA
When a PM order replicates successfully, FSA receives a complete composite object in a single API call to the FSA composite-tree endpoint — ensuring consistency and avoiding partial updates.
- Service Call (from the Maintenance Order)
- Activities (from Order Operations)
- Reserved Materials (from BOM components)
- Problem type / description (from PM Notification)
4. Confirmation Flow in Detail
Outbound: Reserved Materials (S/4HANA → FSA)
Before the technician even arrives on site, the PM order's component list is already visible in FSA. When an order operation is replicated, the planned components (BOM reservations) are sent as reservedMaterials on the FSA Activity. The technician sees what materials are planned before starting work.
Inbound: The Confirmation Flow (FSA → S/4HANA)
When a technician completes work in FSA, they log their time, consumed materials, and expenses. A manager then approves these entries in the FSA Time and Material (T&M) Journal. Upon approval, FSA fires the activity.confirmed event — this kicks off the entire inbound confirmation chain.
- Material withdrawals → BAPI_GOODSMVT_CREATE (movement type 261) → Goods movement posted in S/4HANA.
- Status updates → PM order user status updated to reflect FSA lifecycle changes.
- The Maintenance Order operation phase is set to Execution with sub-phase Work in Execution.
5. Architecture Overview
The integration follows a two-directional architecture:
Outbound (S/4HANA → FSA)
- BAdI WORKORDER_UPDATE fires on PM order save.
- OData Client Proxy (async via bgRFC) sends payload to FSA Service Call API.
- AIF monitors and handles errors.
Inbound (FSA → S/4HANA)
- FSA Connector triggers events to SAP Cloud Integration.
- iFlows route payload to Update PM Order iFlow or Confirmation iFlow.
- OData API in S/4HANA processes the incoming data.
Key design principle: All business and mapping logic lives in S/4HANA. The middleware (Cloud Integration) is used only for routing from FSA to S/4HANA.
6. Master Data Considerations
Before transactional data can flow, the right master data must be in place:
S/4HANA Object | FSA Object | Setup Method |
Equipment & Functional Location | Equipment | Replicated via MAIF |
Work Center & Planner Group | Region | Manual setup required |
Measuring Point | Measuring Point | DRF |
Measurement Document | Measurement Reading | Replicated via iFlow |
Work Center → FSA Region Mapping
Work centers are not automatically replicated. Configure FSA Service Regions manually:
- Region Code format: <WorkCenter>/<Plant> (e.g. 0001/0001)
- Region Name: Description of the work center.
A customizing table in S/4HANA lets you choose — per plant — whether to use the Work Center (KOSTV) or the Planner Group for the FSA region field.
7. Error Monitoring and Operations
The integration uses AIF (Application Interface Framework) as the operational monitoring layer. Every replication message (outbound and inbound) passes through AIF.
- Failed messages appear in Fiori App Message Monitoring under namespace /FSMPM with full context for manual restart.
- bgRFC provides delivery guarantee — even if FSA is temporarily unavailable, messages queue and retry automatically.
- A stuck queue in SBGRFCMON means messages are waiting, not lost.
Monitor this table in production: EAMD_FSM_MO_LINK stores the mapping between each PM order/operation and its FSA Service Call/Activity. A missing or corrupt entry is the most common cause of duplicate Service Calls in FSA.
Interface | Description |
CONFIRM_IN | Maintenance Order Confirmation Inbound |
ORDER_IN | Maintenance Order Inbound |
ORDER_OUT | bgRFC Interface for PM Order replication to FSA |
ORDEROP_IN | Maintenance Order Operation Inbound |
8. Limitations
- Replication of Sub Operations from S/4HANA to FSA or vice-versa is not supported.
- When a Service Call of type Maintenance is created in FSA, a corresponding Maintenance Order will not be created automatically in S/4HANA.
- Replication of reserved material created in FSA to S/4HANA is not supported.
- Activity Cancellation from FSA to S/4HANA is not supported.
- FSA Service Call status updates (Technically Completed) will not update the Maintenance Order in S/4HANA.
- FSA Service Call Activity status updates (Completed and Closed) will not update the Maintenance Order operation in S/4HANA.
- Mileage Confirmation is not supported.
- Initial load of Maintenance Orders is not supported.
- Replication of Attachments is not supported.
- Only Order Type YA01 is supported.
9. Prerequisites
- S/4HANA Public Cloud tenant (2502 or higher recommended)
- FSA tenant provisioned.
- SAP Cloud Integration tenant with FSA connectivity iFlows deployed.
- Communication arrangement SAP_COM_0B10 active (PM → FSA replication)
- Communication arrangement SAP_COM_0B12 active (FSA → S/4HANA inbound)
- OAuth 2.0 client credentials provisioned for each FSA company.
- Scope Item 07Z2 active.
- Configuration user requires role SAP_BR_BPC_EXPERT.
10. CPI iFlow Configuration
The following iFlows must be configured in SAP Cloud Integration to handle inbound replication from FSM to S/4HANA:
iFlow | Purpose |
Route Payload from SAP Field Service Management to SAP S/4HANA | Routes maintenance order updates to the correct downstream iFlows based on service call type. |
Notify Plant Maintenance Order Update from SAP Field Service Management to SAP S/4HANA | Replicates updates such as activity assignment, release, and date changes. |
Update Maintenance Order for New Activity from SAP Field Service Management to SAP S/4HANA | Replicates newly created activities in FSM as operations in S/4HANA. |
Replicate Confirmed Maintenance from SAP Field Service Management to SAP S/4HANA | Replicates confirmations approved in FSM back office to S/4HANA. |
For the routing iFlow, a configuration entry must be added to identify the correct service call type related to maintenance orders.
11. SSCUI Configuration Guide
In Public Cloud S/4HANA, all configuration is done through the Manage Your Solution Fiori app via Self-Service Configuration UIs (SSCUIs) — no SPRO access required. For the PM-FSA integration, the SSCUI entries are organized under:
Asset Management → Maintenance Management → Integration with Field Service and Asset Management
1. Define Plant Specific Order Types
Not every order type should replicate to FSA. This step is your whitelist — only PM order types configured here (per plant) will trigger replication. If an order type is not listed for a given plant, it will be ignored by the replication engine.
In a multi-company setup, routing is controlled by the multi-company configuration. This SSCUI applies to the single company case only.
2. Configure Mapping for Service Call Type Codelist
Every FSA Service Call requires a serviceCallType. This step maps your PM order types to the corresponding FSA code list entries (e.g. Maintenance, Repair, Inspection). This determines how work is categorised in FSA and affects which templates and follow-up workflows are triggered.
3. Configure Mapping for Phase Codelist
Status is bidirectional. This mapping table works both ways:
- Outbound: PM system status → FSA Service Call status.
- Inbound: FSA status change → PM order user status update.
A missing status mapping doesn't cause an error — it causes a silent mismatch. Both directions must be fully mapped before go-live.
4. Configure Mapping for Priority Codelist
PM order priorities are numeric or text codes configured in PM Customizing. FSA has its own priority codelist (HIGH, MEDIUM, LOW). Without this mapping, FSA receives the raw PM value — which almost certainly won't match any FSA entry, resulting in a blank priority on the Service Call.
5. Configure Mapping for Problem Type Codelist
Maps PM damage or object-part codes to FSA problemType entries. This helps FSA categorize the nature of the work correctly for reporting and dispatch, and helps dispatchers assign technicians with the right skill set immediately.
6. Define System Status to Filter Maintenance Order Replication
Controls when in the PM lifecycle an order is sent to FSA — and whether it lands on the Dispatching Board or the Capacity Planning Board in FSA.
Replication Type | Meaning |
1 | Replicate and land on the Dispatching Board in FSA |
2 | Block replication when this status is active |
3 | Replicate and land on the Capacity Planning Board in FSA |
Best Practice content is delivered — but verify and change the Replication Type as per your requirement.
7. Set Default Business Partner (Customer)
FSA Service Calls require a customer reference. PM orders don't always carry one. This configuration sets a fallback default Business Partner — used when the PM order has no Ship-To party — to prevent replication failures.
8. Configure Region
Defines where the FSA region field is sourced from — the functional location, the equipment master, or a fixed value. Region drives FSA's dispatch routing logic and directly affects which dispatcher queue the Service Call lands in.
Best Practice content is delivered — but verify and change the Region Source Code as per your requirement.
An incorrect or missing region means the order sits in the wrong dispatcher queue. This is one of the most common causes of orders not appearing for the right team in FSA.
9. Configure Mapping for Expense Payment Types
Part of the confirmation configuration. Maps FSA expense payment types to S/4HANA posting keys, ensuring that expense entries approved in FSA are posted to the correct G/L accounts in S/4HANA.
10. Configure for Expense Document Type Item Details
Controls the document type and item details used when posting expense documents in S/4HANA from FSA confirmations. This must be configured to complete the expense confirmation loop — only G/L Document posting is supported in the current release.
12. Quick Troubleshooting Guide
Symptom | First Check |
Order not replicated | Fiori App Message Monitoring → /FSMPM → ORDER_OUT (Outbound) and ORDER_IN (Inbound) |
Priority blank in FSA | Configure Mapping for Priority Codelist |
Service Call type wrong | Configure Mapping for Service Call Type Codelist |
bgRFC queue not moving | SBGRFCMON — check for locks or errors |
Confirmation not posting | Message Monitoring → /FSMPM → CONFIRM_IN |
For multi-company configuration for PM for SAP S/4HANA Public Cloud – SAP FSA integration, refer to Enabling S/4HANA Public Cloud Plant Maintenance integration for multiple companies in SAP FSA
References
Source link
