Retail — Store Operations

1. Stock in Transit – Core Idea

When a DC ships goods to a store via a stock transfer order (STO):

• Two-step stock transfer (most common):
  1. DC Goods Issue → Stock moves to valuated stock in transit at the receiving store level (no storage location yet).
     • An accounting document is created (ownership shifts to store).
  2. Store Goods Receipt → Stock posted from stock in transit to unrestricted-use stock.
     • If no differences, no further accounting entry (valuation already at GI).
• One-step stock transfer:
  • DC GI directly creates unrestricted-use stock in the store.
  • Simpler, but less control (less visibility on stock “in transit”).

👉 Interview phrasing:

“In Retail, most STOs run as two-step transfers. GI at the DC creates valuated stock in transit for the store, and the GR in the store simply transfers it to unrestricted-use stock. If it’s one-step, GI directly increases the store’s stock.”

2. Posting Goods Receipt in the Store

Traditionally, this could be done in SAP GUI (MIGO/MIGO_GR). But in Retail, Fiori Store Operations apps are designed for stores.

Key Fiori App: Receive Products

• Role-based (Store Associate, Store Manager).
• Works on tablets, phones, scanners, desktops.
• Supports:
  • Posting GR against outbound deliveries (from DC).
  • Posting GR against vendor POs.
  • Handling Unit (HU) receipt: inspect contents, compare expected vs received, show product images.
  • Reference GTINs and tracking numbers.

Benefits

• Fast, touch-friendly UI.
• Simplifies process for non‑SAP users (store staff).
• Supports RFID and barcode scanning.

👉 Interview phrasing:

“In a store, GR is posted via the Fiori app Receive Products. Staff can scan handling units, compare expected vs. received, and post GR directly against outbound deliveries or POs. It’s optimized for mobile devices.”

3. Integration with In‑Store Merchandising

• My Store Assignment app ensures each user is tied to a store.
• GR links to inventory management and replenishment:
  • Stock updated in real time.
  • Documents updated (delivery history, PO history).
• GR updates the stock overview at store level.

4. Accounting & Valuation Effects

• Two‑step STO:
  • At GI → accounting document created (ownership moves to store).
  • At GR → quantity posting only (no FI doc if quantities match).
• One‑step STO:
  • GI/GR combined → direct valuation at store.

5. Interview Cheat Sheet

• Why 2‑step? More visibility; stock‑in‑transit tracked; better handling of lead times/missing deliveries.
• How posted? Fiori Receive Products app; reference POs or outbound deliveries.
• HUs? Supported, with content check.
• FI impact? GI in DC creates accounting doc; store GR typically no new FI doc unless differences.

👉 10‑sec answer:

“Store GR in Retail usually follows a two‑step transfer: DC GI creates valuated stock in transit for the store, and the store then posts GR to move it into unrestricted stock. The Fiori Receive Products app is used for this — it allows staff to scan handling units, compare expected vs. received, and post GR efficiently.”

Managing Retail Store Operations

Retail employees can’t sit in the back office all day — they need to work on the sales floor, helping customers. That’s why SAP Fiori apps (touch‑friendly, role‑based, mobile) exist:

• Always connected: Real-time link to central SAP Retail.
• Device-friendly: Works on tablets, smartphones, laptops.
• Supports scanners/RFID: Barcode and RFID ready.
• Role-based: Different experiences for Store Associates vs Store Managers.

👉 Interview line:

“The Fiori Store Ops apps bring SAP to the shop floor. Associates can check stock, post receipts, adjust inventory, and transfer goods directly on tablets — with minimal SAP training.”

2. Key Store Operations Apps

🔹 My Store Assignment

• Each associate/manager must be assigned to a store.
• Done via the My Store Assignment app (self‑service) or by admin (transaction FPB_MAINTAIN_PERS_S).
• Printer assignment also configured here (important for label printing).

🔹 Look Up Retail Products

• Fast product search by GTIN, product number, or barcode scan.
• Displays article details, current stock and future receipts, promotions/bonus buys, planned deliveries.
• Shows nearby stores + stock; variants view for generic articles (e.g., color/size).

👉 Use case: A customer asks, “Do you have this T‑shirt in blue, size M?” — associate scans article and instantly sees variants + stock across nearby stores.

🔹 Print Labels (optional)

• Print price labels, HU labels, shelf labels.
• Add products manually or via barcode scan.
• Supports label templates (Adobe Document Server or custom); requires printer assignment in SPAD.

🔹 Perform Store Walk‑Through (optional)

• Task management for store associates: correct stock levels, check BBD, refill shelves, review order proposal corrections.
• Tasks are stored in app‑specific tables for analytics (no standard SAP document flow).

👉 Think of it as a digital task list for managers and associates.

🔹 Order Products

• Manual order — associate directly enters required qty.
• Review order proposals — from PRs, POs on hold, or SAP F&R proposals; shows history + expected receipts (planned delivery time).
• If modified, documents (PRs/POs) are updated accordingly; document type set in customizing.

👉 Interview highlight: “Order Products supports both ad‑hoc ordering and reviewing system‑generated proposals — flexibility for the floor.”

🔹 Transfer Stock

• Quick one‑step posting (article document created immediately).
• For spontaneous transfers: between stores or between storage locations within a store.
• Movement types: 301 (inter‑store), 311 (intra‑store).

👉 Example: Customer needs a product; staff transfers stock from another store the same day.

🔹 Transfer Products

• Full document‑controlled transfer: PO, outbound delivery, handling unit, GI document.
• RFID‑enabled; used for larger or planned movements (promo returns, damaged goods to DC, seasonal clearance).
• Generates HU labels (requires printer in SPAD); reason codes must be maintained.

👉 Interview tip: “Transfer Stock is for quick one‑step moves. Transfer Products is the formal, documented flow.”

3. Apps for Inventory Adjustments

• Adjust Stock — quick corrections for one product.
• Adjust Mass Stock — mass adjustments for several products.
• Count Stock — for physical inventory.
• Count Products with RFID — RFID‑enabled inventory count.

4. Manager‑Specific Apps

• My Store Overview — dashboard for KPIs and status.
• Assign Associates to Stores — manage staff assignments.

5. Interview Cheat Sheet

• Fiori apps are role‑based: Associates = daily ops, Managers = oversight.
• Daily apps: Receive Products, Look Up Products, Adjust Stock, Transfer Stock.
• Transfer Stock vs Transfer Products: one‑step vs full document flow.
• Order Products: manual entry or proposal review.
• Perform Store Walk‑Through: digital task lists, not document‑driven.

👉 15‑sec answer:

“SAP Store Operations apps let staff perform all daily tasks — GR, stock adjustment, ordering, transfers — directly from tablets or smartphones. Apps like Receive Products, Look Up Products, and Transfer Stock are used daily. Transfer Products handles full outbound processes with documents. Store Walk‑Through and Order Products support proactive stock and shelf management.”

Selling to Customers – Sales Order

1. Sales Order Basics in Retail

• Sales order = central document for selling merchandise or services.
• Structure:
  • Header: customer, org data, pricing.
  • Items: ordered products, quantity, schedule lines.
  • Schedule lines: allow partial deliveries.
• Organizational assignment: sales organization, distribution channel, division.
• Controlled by: sales order document type (customizing).

System Functions at Creation

• Scheduling → calculates delivery dates.
• ATP Check → availability confirmed.
• Item category determination → TAN (stock delivery), TAS (third‑party), etc.
• Quantity optimization → e.g., round to logistical units.

👉 Interview line:

“The system automatically checks availability, determines item and schedule line categories, and optimizes quantities when creating a sales order.”

2. Standard Process: Stock Reduction (TAN)

• Merchandise shipped from DC or store stock.
• Steps:
  1. Sales order created (item cat. TAN).
  2. Outbound delivery generated → picking + goods issue.
  3. Invoice created (delivery‑related billing).
• Used for regular items or bulky goods not at checkout counters.

Example: DIY store, customer buys a ladder → sales order created in Fiori → automatic delivery → issue counter handles GI → invoice.

Document flow: Sales Order → Outbound Delivery → Picking → Goods Issue → Billing → FI Posting.

3. Variant: Third‑Party Sales Order (TAS)

• Used for non‑stock items, custom‑made, bulky goods.
• Steps:
  1. Sales order created (TAS).
  2. System generates purchase requisition automatically.
  3. Requisition → Purchase Order to vendor (customer’s address = delivery address).
  4. Vendor delivers directly to customer.
  5. Vendor invoice posted (MM LIV).
  6. Customer invoice created (sales‑order related billing).

Heads‑up: Changes to the sales order do not auto‑update the PO → adjust manually. Report SDMFSTRP helps identify mismatches.

Document flow: SO (TAS) → Purchase Requisition → PO → Vendor Delivery → Vendor Invoice → Customer Invoice.

👉 Interview line:

“With TAS, the system automatically creates a purchase requisition, and direct delivery happens from vendor to customer. Billing is sales‑order related, not delivery‑related.”

4. Variant: Click & Collect / Click & Reserve

Customers order online → pick up in store.

Store apps involved:

• Process Picking Requests → associates pick items for handover.
• Hand Over Orders → verify and hand over items to customer.
• Maintain Picking Sequence (optional) → optimize picking route.

Two possible flows

1. Click & Reserve (older / fashion)
   • SO created → items picked → at handover, SO rejected → POS sale recorded for final chosen items.
   • Useful in fashion: try before you buy.
2. Click & Collect (newer / food, electronics)
   • SO created → items prepared → customer pays online → only pickup in store.
   • SO remains active, fully billed already.

👉 Interview line:

“Click & Collect evolved: earlier SOs were rejected at handover (‘reserve and try on’), but now retailers can choose to keep SOs active for prepaid pickup scenarios.”

5. Fiori Integration

• Create Sales Order for Retail (VA01 equivalent).
• Manage Sales Orders app:
  • Search & filter SOs.
  • Check status (delivery, GI, billing).
  • Trigger follow‑up actions (pick, GI, invoice).
• Full integration with document flow & logistics.

6. Billing

• Delivery‑related billing (TAN): based on delivered qty in outbound delivery.
• Sales‑order related billing (TAS): based on SO qty + conditions.
• Proof of Delivery (POD) optional → invoice only after customer confirms receipt.

Billing types: F1 = invoice, G2 = credit memo, L2 = debit memo.

Every billing doc generates an accounting doc in FI via automatic account determination.

7. Cheat Sheet for Interview

• TAN (stock) = DC/store fulfillment → delivery‑related billing.
• TAS (third‑party) = vendor direct delivery → sales‑order billing.
• Click & Collect = hybrid → pickup in store, can be reserve or prepaid.
• Fiori apps: Create SO for Retail, Manage SOs, Process Picking Requests, Hand Over Orders.
• Document flow = your best friend to track SO → Delivery → GI → Billing.

Performing Physical Inventory

1. Why Physical Inventory?

• Every retailer must count stocks at least once a year (legal + compliance).
• Goal: reconcile book stock vs. physical stock.
• If differences: system posts adjustments → updates stock quantities and valuation in FI/CO.

👉 Interview line:

“Physical inventory ensures accurate stock in the system. It’s required for compliance, but it also improves replenishment and financial accuracy.”

2. Types of Physical Inventory

1. Periodic
   • Count all stock on a specific key date.
   • Used for year-end stocktaking.
2. Continuous / Cycle Counting
   • Count different parts of stock throughout the year.
   • Each article must be counted at least once annually.
   • Fits large retailers with big assortments.

3. Key Concept: Stock Management Unit

The smallest unit that has its own book balance.

Defined by:

• Article
• Site
• Stock type (unrestricted, quality, blocked)
• Special stock (e.g., consignment, RTP)

Each unit must be counted separately.

4. Phases of Physical Inventory

🔹 Phase 1 – Create Physical Inventory Documents

• Define site, storage location, stock types.
• Document groups articles for counting.
• Can be mass-generated → printed, loaded to handhelds, or managed via Fiori apps.

🔹 Phase 2 – Enter Count

• Store associates count physically.
• Results entered in system → compared with book balance.
• If large differences → manager can trigger recount.

🔹 Phase 3 – Post Differences

• Adjusts stock in Inventory Management (IM).
• Generates article document + accounting document (if valuated).

5. Controlling Book Inventory

• Posting Block: prevents goods movements during count.
• Freeze Book Inventory: “snapshot” book balance at count start, even if movements continue later.
• Needed when store operates during stock count.

Scenario: Store counts 3 pcs, but book shows 8. If 5 sales came through POS during count, system adjusts automatically after POS upload → no real difference.

6. Stores vs. Distribution Centers

• Stores:
  • POS sales/returns integrated.
  • Often use Fiori Store Operations apps.
  • Ad-hoc counts possible (cycle counts by shelf/category).
• Distribution Centers (DCs):
  • Often use Warehouse Management (WM/EWM).
  • Inventory is done per storage bin.
  • Differences posted to special storage type, then transferred to IM.

7. Organizational Options

• Head office–driven: HQ generates PI docs, sends to stores.
• Store-initiated: stores create their own PI docs (common for cycle counts).
• Integration: if external store systems → counts uploaded via IDoc.

8. Fiori Apps for Store Physical Inventory

• Create Physical Inventory Document → like MI01 in GUI.
• Count Stock → associates record counts (barcode, scanning, RFID).
• Manage Stock Counting → manager reviews, approves, requests recount.
• Post Physical Inventory Differences → updates stock + accounting.
• Count Stock Ad Hoc – TODAY → quick, spontaneous cycle counts.
• Adjust Mass Stock – TODAY → adjust stock for shrinkage, spoilage, unplanned GR.

Apps are role-based: associates → Count Stock, managers → Manage & Post.

9. Special Considerations

• Special stocks → separate PI docs (consignment, RTP).
• Handling POS data:
  • Freeze/fix book inventory at count start.
  • POS sales integrated (via POS DTA / PIPE in CAR).
• Inventory differences → always documented in FI.

10. Cheat Sheet for Interview

• 3 phases: Create → Count → Post differences.
• Posting Block vs. Freeze = block movements vs. snapshot book balance.
• Store vs. DC = Fiori apps vs. WM/EWM bin-level counts.
• Fiori support = Count Stock, Manage Stock Counting, Post Differences.
• POS integration ensures counts are corrected with daily sales.

👉 Final interview tip:

“In retail, accuracy of store stock is critical because replenishment and POS depend on it. That’s why SAP provides retail-specific Fiori apps for associates and managers to simplify counts, corrections, and ad-hoc adjustments.”

POS

1. What Happens at the POS

• POS system = cash registers at store.
• Captures:
  • Article sold (via GTIN/barcode).
  • Quantity & sales price.
  • Payment info (cash, credit, loyalty, returns).
  • Metadata: POS number, cashier ID, date/time.
• All transactions stored in a TLog (Transaction Log) for:
  • Store-level monitoring.
  • Corporate-level aggregation.
  • Audits, disputes, fraud detection.

👉 Interview phrasing:

“The POS system captures article, qty, price, payment, cashier, and stores this in a TLog. SAP Retail uses that data for stock, accounting, and replenishment.”

2. POS ↔ SAP Retail Integration

a) POS Outbound (HQ → Store)

HQ sends data to POS so sales can be processed correctly.

Includes:

• Master data: articles, GTINs, prices, promotions.
• Merchandise Category Hierarchy.
• Movement data: shipping notifications, POs for store, physical inventory docs.
• Bonus buy conditions.

Transfer options:

• Middleware with IDocs/RFC (classic PI/PO).
• Service-based / SOAP (newer).
• DRFOUT (Data Replication Framework) in S/4HANA Cloud → product data → POS.

Key point:

• Initial Load = full master data (new store onboarding).
• Delta Load = only changes (new/changed articles, future prices).

b) POS Inbound (Store → HQ)

POS sends back to HQ the actual sales & movements.

Includes:

• Sales & returns.
• Financial transactions (cash, credit, loyalty).
• Goods movements (store GR, transfers).
• Store orders.
• Physical inventory counts.
• Cashier statistics.
• Customer order payments.

Processing:

• Typically via middleware/converter → IDocs (INVOIC, WPUUMS, WPUBON).
• Can also use SOAP services and monitor via SAP AIF (Application Interface Framework).

Data updates:

• Inventory (reduce stock).
• Billing documents (post to FI).
• Payment data → Accounting.

👉 Simulation:

SAP allows manual POS Inbound test — useful for configuration testing.

3. Store Connection Options

• Option A: Direct HQ ↔ POS Server.
• Option B: Store runs a local non‑SAP store merchandising system; it updates POS + HQ.
• Option C: Store uses SAP In‑Store Merchandising (ISM) + SAP Fiori Store Ops Apps (GR, inventory, returns). POS Server still handles sales transactions separately.

4. SAP POS DTA (Data Transfer & Audit) & CAR

• SAP POS DTA (part of SAP CAR):
  • Receives POS data centrally.
  • Validates, corrects, audits before posting further.
  • Forwards data at different granularity levels (receipt level or aggregated).
  • One central audit ensures consistency across SAP Retail, FI, Loyalty, Forecasting.
• SAP CAR (Customer Activity Repository):
  • HANA foundation storing granular sales data (store + e‑com).
  • Feeds apps: Merchandise & Assortment Planning, Allocation, Forecasting & Replenishment (UDF, OSA), Omnichannel Pricing (OPPS), Omnichannel ATP (OAA).

👉 Key value:

“Audit once in CAR, reuse everywhere — finance, replenishment, loyalty, analytics.”

5. Process Chain – POS Sales Data

Outbound (HQ → POS)

1. Article/prices/promos sent (initial or delta).
2. Store POS server updates tills.

Inbound (POS → HQ)

1. Sales logged in TLog at store.
2. POS server sends transactions via middleware (IDoc/SOAP).
3. SAP POS DTA (CAR) loads, validates, audits.
4. Data forwarded to:
   • SAP Retail → inventory updates.
   • FI → revenue postings.
   • F&R → demand/forecast.
   • Loyalty/Analytics systems.

6. Interview Cheat Sheet

• POS captures: article GTIN, qty, price, payment, cashier → TLog.
• POS Outbound: HQ sends article, price, promo data (IDoc/DRFOUT).
• POS Inbound: Sales, returns, payments flow back → inventory & FI updated.
• Integration Options: Middleware (PI/PO, RFC), SOAP, DRFOUT, AIF monitoring.
• SAP POS DTA + CAR: Central audit + storage → distribute clean, consistent sales data.
• Store options: Direct connection, local non‑SAP store MM, or SAP In‑Store Merchandising.

👉 10‑sec answer in interview:

“POS systems capture sales & payments and transfer TLog data back to HQ. SAP Retail integrates via POS Outbound (article, price, promo data) and POS Inbound (sales, returns, payments). Middleware or DRFOUT handles transfer. Modern retailers use SAP CAR with POS DTA to centrally audit, correct, and stage POS data for inventory, finance, replenishment, and analytics.”

People also ask

About the Author

Dzmitryi Kharlanau

Senior SAP Consultant·EPAM Systems

Senior SAP SD / O2C Consultant | S/4HANA Logistics | Integration at EPAM Systems. Interested in S/4HANA, automation, AI, and Event-Driven Architecture (EDA).

SAP SDOrder-to-CashS/4HANABTPEDAIntegrationAutomationAI