Retail — Procurement And Supply

1. Purpose of Requirements Planning

• Guarantee article availability at sites.
• Minimize capital lockup and logistics cost.
• Continuously monitor stock and auto‑generate procurement proposals (PR → PO).
• Runs at article/site level (MRP Area = site).

👉 Interview phrasing:

“Requirements planning in Retail makes sure stores don’t run out of stock, while keeping inventory low. It automates PR creation based on consumption, forecasts, and vendor calendars.”

2. Setup in Article Master (Logistics Views)

Key fields:

• MRP type (RP/MRP type) — planning method (forecast mandatory/optional/not relevant).
• Lot‑sizing procedure.
• MRP controller (stock planner).
• Forecast parameters: period indicator (daily/weekly/monthly), number of past and forecast periods.

Forecast Models

• Constant
• Trend
• Seasonal
• Seasonal + Trend

👉 New articles can inherit history from a reference article.

3. Consumption‑Based Planning Procedures

a) Reorder Point Planning

• System checks stock vs. reorder point; if stock < ROP → PR created.
• Reorder point = safety stock + average consumption × replenishment lead time.
• Lead time = purchasing processing + planned delivery + GR processing time.
• Safety stock buffers unexpected demand/vendor delays.

b) Time‑Phased Planning

• Uses a planning calendar and vendor delivery cycle (e.g., delivers every Friday).
• Planning run creates proposals only on those days.
• Requires MRP type “time‑phased” + planning cycle + delivery calendar in article master.

c) Forecast‑Based Planning

• Uses forecasted consumption (not only past usage) to create PRs according to projected demand.

4. Seasonal / Fashion Articles → Planned Independent Requirements (PIRs)

• PIRs = planned quantities for articles/sites per horizon (e.g., monthly).
• Maintained manually or imported from Assortment Planning.
• PIRs feed MRP along with sales orders, stock transfers, and existing stock.
• Used especially for generic articles + variants in seasonal businesses.

5. Running MRP (MRP Live)

• MRP Live = HANA‑optimized mass planning at site (MRP Area) level.
• Planning file entry required (created automatically when MRP type is set).

Control Parameters

• Planning Scope: which articles/sites or by MRP controller.
• Regenerative vs Net Change planning.
• Planning Mode: reuse or recreate unfirmed PRs.
• ATP Check: considers current stock + POs + sales orders.
• Usually run as background job (no Fiori app for MRP Live).

6. Output of Planning Run

• Generates Purchase Requisitions (PRs) with quantity and delivery date.
• Auto‑convert PR → PO if flags are set in site master (automatic order conversion), article master (auto PO allowed), and vendor master (auto PO).

7. Supply Source Determination

In MRP Live (cross‑industry simplified sourcing)

1. Quota arrangement (rare in Retail).
2. Outline agreements (contracts, scheduling agreements).
3. Purchasing info records (auto sourcing flag).
4. Purchasing info records (regular vendor flag).

Retail‑Specific Supply Source Determination

• Internal (DCs) and external (vendors) sources in parallel.
• Priority:
  1. Quota arrangement (if used).
  2. Source list (allow/block entries, with validity).
  3. External vendor contracts/info records.
  4. Internal supply via DC (stock transport scheduling agreement; supplying site in site master at general or site/category level).
• If multiple sources valid → options proposed during PO creation.

👉 Interview phrasing:

“In Retail, supply source determination first tries quota, then source list, then contracts/info records, and finally supplying DCs. Internal and external sources are handled in parallel.”

8. Integration with Purchasing

• PRs can be converted manually or automatically into POs.
• Quantity optimization available at PO creation.
• Release Procedure can enforce approvals (e.g., PO > 10,000 USD).

9. Interview Cheat Sheet

• Goal = availability + low cost.
• MRP type controls method (Reorder Point, Time‑Phased, Forecast).
• Safety stock + lead time drive Reorder Point.
• Time‑phased planning follows vendor delivery calendar.
• PIRs for seasonal/generic articles.
• MRP Live = site‑level planning, background job, ATP check.
• Output = PRs → POs (auto‑convert if flagged).
• Supply Source = quota > source list > contracts > info records > DC supplying sites.

👉 Quick 10‑sec answer:

“Requirements Planning in Retail runs at article/site level. It uses MRP types like reorder point, time‑phased, or forecast‑based planning. Seasonal demand is handled with PIRs. The MRP Live run generates purchase requisitions, which can auto‑convert to POs, with supply sources determined via contracts, vendors, or supplying DCs.”

1. How POs Are Created in Retail

• Automatic conversion from purchase requisitions (MRP run).
• Generated from Store Replenishment or POS Inbound Store Order.
• Follow-on docs from allocation tables (e.g., promotions).
• Via external interfaces (F&R, Replenishment Planning).
• Or manually (classic ME21N / Fiori Create Purchase Order).

👉 Interview phrasing:

“In Retail, POs can originate from planning runs, store orders, promotions, or be created manually. Automatic conversion saves huge manual effort.”

2. Purchase Order Structure

PO has three parts:

1. Header — supplier, PO type, purchasing org/group, company code.
2. Item Overview — list of ordered articles.
3. Item Details — conditions, scheduling, texts, partner, stock.

Types of POs:

• Standard PO (NB) → external vendor.
• Stock Transport Order (STO / UB) → internal DC → store.

Personalization: users can set defaults, adjust item table columns, variants.

3. Functions Available

At Header Level

• Maintain texts, partners (vendor/invoicing party/payee).
• Adjust supplier address (for document only).
• Display header conditions, print preview.
• Jump to supplier master.

At Item Level

• Maintain conditions.
• Order generic articles via variant matrix.
• Handle returns (empties, transport equipment).
• Show sub-items: Empties (crates, bottles) and components of structured articles.
• Manage free goods, schedule lines, and access material/stock/info records.

4. Logistics Monitoring (Transportation Chains)

• PO Monitoring: check transport segments vendor → DC → store.
• Uses Transportation Chains: define route segments + lead times.
• Datelines Workbench: simulate, correct, or monitor deviations.
• Reactive PO Monitor: alerts for anticipated delays.

👉 Interview phrasing:

“Transportation Chains let retailers track expected delivery times across multiple legs and react early to delays.”

5. Quantity Optimization (Rounding Profiles)

Net requirement from PR often doesn’t match vendor packaging.

• Rounding Profiles adjust order qty to vendor’s allowed UoM (case, layer, pallet).
• Can round up/down, enforce minimums, max limits.
• Dynamic profiles → allow multiple units of measure.
• Static profiles → only one fixed UoM.
• Ensures POs align with vendor logistics and price scales.

Example: Pallet = 240 EA. 216–264 EA → 1 pallet; 456–504 → 2 pallets. Vendor conditions typically better at higher pack levels.

6. Purchase Price Determination

Uses condition technique (same as SD, adapted for MM).

1. Schema determination → find pricing schema (based on vendor + purchasing org schema groups).
2. Condition types → cost factors (basic price, discounts, freight, surcharges).
3. Access sequence → search for condition records in order (vendor/article → vendor → general).
4. System stops when a valid record is found (exclusive indicator). Final price = base + freight – discounts ± surcharges.

Condition records always have validity periods.

7. Contracts & Release Orders

• Contracts = long-term agreement with supplier (time‑bound) with total quantity or value.
• Types: Quantity Contract vs Value Contract.
• Can be site-specific or centrally agreed (apply to all sites with site-specific conditions).
• Release Order = actual PO referencing the contract → defines delivery date + qty.

👉 Interview phrasing:

“Contracts set long-term conditions, release orders execute them. Retailers often negotiate centrally agreed contracts to get better terms.”

Interview Cheat Sheet

• PO Creation: automatic (MRP, replenishment, store order, allocation table, F&R) or manual.
• Structure: Header / Item Overview / Item Details.
• Types: NB = standard vendor, UB = stock transport.
• Functions: texts, partner mgmt, returns, generic article matrix, structured article sub-items.
• Monitoring: Transportation Chains + Reactive PO Monitor.
• Quantity Optimizing: rounding profiles (dynamic vs static), UoM groups, min/max.
• Price Determination: condition technique (schemas, condition types, access sequences).
• Contracts: long-term value/quantity agreements → executed via release orders.

👉 Quick interview answer:

“In Retail, purchase orders can be created automatically or manually. They follow a header–item structure, and support special functions like variant matrix, returns, or empties. Quantity optimization aligns order quantities to vendor pack sizes via rounding profiles. Pricing uses the condition technique, pulling conditions from info records or contracts. Long-term vendor agreements are handled via contracts, and release orders execute against them.”

Order Confirmation & Goods Receipt Process

1. Order Confirmation

Confirmation Control

• Defined in Customizing, assigned via vendor or article master (Info Record).
• Specifies confirmation categories and their sequence, plus relevance for MRP & GR posting:
  • Simple Order Confirmation
  • Advanced Shipping Notification (ASN) / Inbound Delivery
  • Rough Goods Receipt (delivery note)

Example: Vendor requires ASN → GR. ASN (Inbound Delivery) provides Handling Unit (HU) details so the DC can receive efficiently without opening each pallet.

PO Output / Message Control

• On PO save, an output message is generated (print, EDI, fax, etc.).
• Timing can be immediate, scheduled batch, or online.

👉 Interview phrasing:

“The confirmation control key defines which confirmations (e.g., ASN) are required and their sequence. In Retail DCs, ASN with HU data is critical for efficient goods receipt.”

2. Goods Receipt (GR) Process

One-Step vs Two-Step

• One-Step: GR posted directly against PO or ASN.
• Two-Step:
  • Step 1: Rough GR (based on delivery note).
  • Step 2: Final GR posted after check.
• Reference documents: PO, Inbound Delivery (ASN), Rough GR.

Key Effects of GR

• Updates stock at site/storage location.
• Updates PO history (used for monitoring & dunning).
• Can trigger notifications to purchaser.
• Creates FI/CO documents if valuation‑relevant.

Checks at GR Posting

• Quantity (over/under‑delivery), Best Before Date (BBD), GTIN.
• Shipping instructions and returnable transport packaging (RTP) as special stock.

GR Without Reference

• Possible (unplanned GR, e.g., returns); system can auto‑create a PO afterwards.

👉 Interview phrasing:

“In DCs, GR is usually two‑step: delivery note (rough GR) then final GR. Reference documents speed up posting and ensure PO history + FI updates.”

3. Warehouse Management Integration

Options for DCs (Storage Locations)

1. No WM → MM‑Inventory Mgmt only (simple DC, returns).
2. Lean WM → fixed bins; simple warehouse structure.
3. Classic WM (Stock Room Mgmt) → allowed until 2027/2030.
4. Decentralized WM/EWM → SAP SCM‑based EWM or non‑SAP WMS.
5. Embedded EWM in S/4HANA → Basic or Advanced (strategic solution).

EWM Structure

• Warehouse Number = overall DC.
• Storage Types = functional zones (GR zone, high rack, GI zone).
• Storage Sections = group bins by attributes (fast movers, bulky).
• Storage Bins = lowest level, often 18‑digit coordinate (aisle–stack–level).
• Activity Areas = group bins for processes (GR staging, picking, etc.).

👉 Interview phrasing:

“Retail DCs often integrate with Embedded EWM. GR posts stock to bins, with quants tracked by batch, HU, or BBD. This allows precise putaway, picking, and inventory visibility.”

4. Goods Movements (MM‑IM Level)

• GR (Goods Receipt) → increases stock.
• GI (Goods Issue) → decreases stock (store replenishment, customer order).
• Stock Transfer → move between sites/storage locations.
• Transfer Posting → reclassify stock types (QI → unrestricted).
• Controlled by movement types (3‑digit codes) that define reference docs, FI impact, and screen fields.

5. Inventory Management & Valuation

Quantity‑Based IM

• Updates quantities + values; creates FI documents for valuation‑relevant movements.
• Stock types: Unrestricted‑use, Quality inspection, Blocked.
• Special Stocks: Vendor consignment, Returnable Transport Packaging (RTP).

Value‑Based IM (Retail‑Specific)

• Stock managed at value level only (not quantity) using value‑only articles (often by merchandise category).
• Retail price valuation possible (optional with quantity‑based; mandatory with value‑based).
• Used mainly in stores, not DCs.

Valuation Methods

• Standard Price (S) → fixed price, variances to price difference account.
• Moving Average Price (V) → recalculated at every GR.
• Supports lowest‑value and LIFO methods.

Example: Stock = 100 EA @ 10 USD; GR of 100 EA @ 20 USD → MAP recalculated = 15 USD.

6. Interview Cheat Sheet

• Order Confirmation: Confirmation Control Key (ASN/Inbound Delivery critical for DCs).
• GR Process: One‑step vs Two‑step; reference docs ensure accuracy + update PO history.
• Warehouse Integration: Lean WM, Stock Room Mgmt, Embedded EWM. Storage hierarchy = Warehouse → Type → Section → Bin.
• Goods Movements: GR, GI, Stock Transfer, Transfer Posting (movement types control FI impact).
• Inventory Mgmt: Quantity‑based vs Value‑based (value‑only articles in stores).
• Valuation: Standard Price vs MAP; retail price valuation where applicable.

👉 Quick 10‑sec interview answer:

“In DCs, vendors usually send an ASN that creates an inbound delivery. Goods receipt is then posted, often in two steps: delivery note check → final GR. If WM/EWM is active, stock is put away into bins. FI valuation depends on MAP or Standard Price. Retailers may also use value‑only articles for value‑based IM, especially in stores.”

Invoice

1. Purpose & Context

• LIV ensures supplier invoices are accurate before payment is released.
• Crosses MM (logistics) and FI (finance):
  • Checks invoice against PO + GR + conditions.
  • Posts differences correctly (tolerance or price diff accounts).
  • Final postings hit GR/IR clearing and vendor account.

👉 Interview phrasing:

“Invoice verification is where logistics and finance meet — it’s how SAP ensures vendors get paid correctly, only for what was delivered.”

2. Verification Principles

Target vs Actual Invoice

• Target Invoice = expected value based on GR + PO conditions.
• Actual Invoice = vendor’s submitted invoice.
• If match (or within tolerances): invoice posts.
• If outside tolerances: invoice blocked, needs correction.

Options for Verification

• PO reference: Purchase Order, Scheduling Agreement.
• GR reference: Delivery Note, Bill of Lading.
• Service reference: Service Entry Sheet.
• Other: Outbound delivery (rare).

3. Process Flow (Standard GR-based LIV)

1. Vendor delivers goods → GR posted.
   • GR updates stock + PO history.
   • FI entry: Debit Inventory / Credit GR/IR.
2. Vendor sends invoice:
   • Online entry (MIRO).
   • Or EDI IDoc INVOIC01 (auto).
3. System compares invoice against GR + PO.
   • Qty check.
   • Price check (PO conditions).
   • Taxes, freight, discounts.
4. Tolerance check:
   • If within defined %/value → auto-adjust to expense/revenue account.
   • If outside → invoice blocked for payment.
5. Posting:
   • Invoice posted → FI update: Debit GR/IR clearing, Credit Vendor.
   • Payment released through FI.

4. Variants of LIV

a) Goods-Receipt-Based Invoice Verification (GR-IV)

• Most common in Retail.
• Invoice verified against what was actually received.
• Prevents paying for undelivered quantities.

b) Evaluated Receipt Settlement (ERS)

• No vendor invoice required.
• System auto-creates invoice using GR + PO conditions.
• Requires: Vendor flagged for ERS in master data; clear conditions in PO.
• Often used with returnables, transport, or trusted suppliers.

c) Prepayment

• Vendor paid before GR, e.g., to capture cash discount.
• Requires settings in Customizing and vendor master.
• Risks: must reconcile later against GR and invoice.

👉 Interview phrasing:

“GR-based is standard, ERS avoids invoices altogether, and prepayment is an exception for cash discounts.”

5. Execution Modes

a) Online Verification

• Invoice entered + verified in real-time.
• User sees each item, can correct immediately.
• Downside: slower for high volumes.

b) Background Verification (Immediate)

• User enters invoice.
• Verification runs in background → result list.
• Fully posted invoices hidden; focus only on errors.

c) Background Verification (Scheduled)

• Batch job for mass invoices.
• Used in Retail (large volumes, daily).
• Errors flagged for later correction.

6. Error Handling & Tolerances

Tolerance Limits (Customizing)

• Small differences → auto-posted to expense/revenue accounts.
• Example: invoice = 100.05, PO = 100.00 → system posts 0.05 diff to expense.
• Large differences → invoice blocked for payment.

Error Scenarios

• Wrong quantity invoiced → user adjusts in invoice.
• Wrong price/tax → adjust tax code or condition.
• Wrong PO reference → reassign items.

Notifications

• REKL message → supplier informed of condition mismatch.
• EINK message → buyer informed if master data/conditions are wrong.

👉 Interview phrasing:

“Tolerance limits save time by auto-posting small differences. Larger mismatches trigger blocking or require manual correction, with notifications sent to buyers or suppliers.”

7. Assignment Test (Pre-Step)

• Lightweight background check before LIV.
• Confirms open GR exists before verifying invoice.
• Faster: avoids reading article data or full checks.
• Useful for high-volume background processing.

8. Integration with FI

MM vs FI Roles

• LIV is part of MM (Materials Management) → decentralized invoice verification possible.
• But postings always flow into FI:
  • Debit: GR/IR clearing.
  • Credit: Vendor.
• If FI in separate system: postings sent via RFC.

9. EDI / Automation

• Invoices can arrive via EDI IDoc (INVOIC01).
• Enables fully automated invoice verification.
• Works with change pointers + background verification for true mass processing.

10. Interview Cheat Sheet

• Purpose: Match invoice vs PO + GR → ensure correct payment.
• Variants: GR-based (standard); ERS (no invoice); Prepayment (early pay for discount).
• Execution: Online (real-time), Background Immediate, Scheduled Batch.
• Tolerances: small diffs auto-posted, large diffs → block + correction.
• Integration: MM process, FI postings always created.
• Automation: Assignment Test + EDI IDocs.
• Messages: REKL (supplier), EINK (buyer).

👉 Quick 10-sec answer in interview:

“Invoice verification in Retail is GR-based: the system matches invoice against PO and GR. Small differences are posted automatically; larger ones block the invoice. Options include ERS for automatic settlement without invoices, or prepayment. Invoices can be entered manually or via EDI. LIV runs in MM but always posts to FI.”