Cross-module and cross-system flows

A common question from a first-time user is: if I ask Atlas for a sales-to-cash view, will it see the warehouse and the finance module too, or will it stop at the sales boundary? The answer is that Atlas sees the whole chain, because the chain is how SAP was designed. This page explains what the chain is and why Atlas is built to traverse it.

Modules are not islands

S/4HANA is divided into modules — FI, CO, MM, SD, PP, PM, QM, HR, PS, WM, LE — each owning a business domain. From a developer’s point of view the modules look like neighborhoods in the same city: each has its own history and conventions, they connect through well-known streets, and a single business process routinely visits several of them in order.

FIFinancial accountingindexedCOControllingindexedMMMaterials managementindexedSDSales & distributionindexedPPProduction planningindexedPMPlant maintenanceQMQuality managementHRHuman resourcesPSProject systemWMWarehouse managementLELogistics execution

FI · Financial accounting

General ledger, payables, receivables. Every business action Atlas plans for eventually posts here.

Cross-module flows

Order-to-cash

1. 1. SD · sales order
2. 2. MM · ATP
3. 3. WM · pick
4. 4. LE · delivery
5. 5. SD · billing
6. 6. FI · posting

Procure-to-pay

1. 1. MM · PR / PO
2. 2. MM · goods receipt
3. 3. QM · inspection
4. 4. FI · invoice
5. 5. FI · payment

Plan-to-produce

1. 1. PP · MRP
2. 2. PP · work order
3. 3. QM · release
4. 4. CO · cost

Tap a module to see what it covers, and follow the flow links below the grid to watch a document move through them. Order-to-cash starts in SD, reaches into MM for availability and WM for picking, comes back through SD for billing, and lands in FI for the posting. That path is not a convenience — it is how every SAP customer actually runs sales.

Atlas models this directly. When you ask for a view that touches sales, the planner asks Keystone for every other module the document chain will visit and adds the relevant evidence to the plan graph. If posting information is required, FI views join the plan automatically. If stock movement matters, WM/MM views join. The planner does not ask you to name the modules — it walks the chain on your behalf.

The chain extends past the ERP

A second property of SAP deployments is that the chain does not stop at the S/4HANA boundary. Many of the processes Atlas plans against thread through sibling products — Ariba for supplier collaboration, IBP for planning, TM for transportation, EWM for warehouse execution, GTS for customs and compliance. Each of those is a separate SAP system with its own data model, but the document chain continues through all of them.

1. 1
   Shanghai
   Supplier books shipment
   Supplier confirms goods via Ariba; delivery promise syncs into the buyer's inbound expectation.
   AribaS/4 MMGTS — export license
2. 2
   Shanghai port
   Container loads on vessel
   TM plans the route; carrier + freight cost contracted. EWM releases the picked goods.
   SAP TMSAP EWMGTS — origin customs
3. 3
   Open sea
   ETA events stream back
   Tracking signals flow into IBP so the plant can firm up production for downstream demand.
   SAP IBPTM event mgmt
4. 4
   Rotterdam
   Customs clears · goods receipt
   GTS sanctions + HS-code check; EWM books the receipt; FI posts the liability.
   SAP GTSEWMS/4 FI
5. 5
   Wolfsburg
   Consumed on the line
   PP backflush issues stock; CO picks up the cost; the next demand signal ripples back to suppliers.
   S/4 PPS/4 COIBP

A single outbound shipment — from a purchase order to a goods receipt to a sale to a posted revenue — may touch five SAP systems on three continents. Atlas indexes the hand-offs between them so that a plan you write in one system can see the artifacts it will eventually interact with in another. That does not mean Atlas emits code into every sibling; it means the plan is aware of them, the evidence trail mentions them, and the reviewer is not surprised when the transport mentions a downstream consumer in GTS.

What this means for how you write tasks

You do not have to name every module or every sibling system in your task description. If the task is expressed in business language — “rank customers by net sales” or “flag overdue goods receipts for review” — Atlas will place it on the chain and pull in what it needs. What you do need to say is which system the task belongs to at the top: on- premise or cloud, your dev system or your production extract. Once Atlas knows the root, the rest of the chain comes with it.