If you work with customers or distributors who share sell-through and inventory data, you’ve probably heard “Send us your 852,” or “We’ll send you 867 resale.” This guide explains what those X12 messages mean in SAP terms, how they move through IDocs, and what you, as a super user, actually do day to day. You’ll also see realistic scenarios you can use to sanity-check your design.
Quick primer: what each message does
- EDI 852 — Product Activity Data (usually inbound)
Retailers or distributors send you store/DC-level activity by SKU and date: sales (units out), on-hand inventory, receipts, sometimes returns and forecasts. Your team uses it for demand visibility, VMI, and replenishment tuning. - EDI 867 — Product Transfer & Resale (usually inbound)
Distributors send resale to end customers/locations and sometimes transfer movements. You use it to trace channel sales and to settle rebates/chargebacks (ECC: SD rebates; S/4: Settlement Management/Condition Contracts).
How the flow works (high level)
- Trading partner → EDI gateway
Your partner sends X12 852 or 867. Your EDI/B2B platform validates, translates, and maps to an SAP IDoc format. - EDI gateway → SAP (inbound IDoc)
The mapped file is posted to SAP over tRFC/HTTPS. Your partner profile (WE20) points the message to the right message type/process code and basic type. - SAP application processing
- 852 typically becomes a PROACT (product activity) IDoc—or Retail POS IDocs in SAP for Retail—and updates activity repositories used for VMI/replenishment and analytics.
- 867 typically lands as SLSRPT (sales reporting) or a custom Z-IDoc and feeds resale history, often downstream to rebates/chargebacks or Settlement Management.
- Acknowledgements & monitoring
997s (functional acks) go back to partners; you monitor IDoc statuses in WE02/WE05 and reprocess errors in BD87. Application logs and custom error queues catch unknown SKUs or sites.
The SAP objects and IDocs you’ll most likely see
- 852 (Product Activity Data)
- PROACT (e.g., PROACT01/02): generic product activity—sales, on-hand, receipts by site/SKU/date.
- Retail POS IDocs like WPUUMS (sales), WPUWBW (stock), WPUUMR (receipts) if you’re on SAP for Retail.
- Some teams stage 852 into Z-tables first to cleanse, then post into planning/analytics.
- 867 (Product Transfer & Resale)
- SLSRPT (e.g., SLSRPT01): sales reporting by end-customer/ship-to/location.
- Custom Z-IDoc or extended PROACT if you need extra fields for rebate/chargeback references.
- In S/4HANA Settlement Management, 867 is often staged then posted via APIs/BAdIs into Condition Contract determination and calculation.
What a super user actually does
- Day-to-day checks
- Review last inbound 852/867 batches in WE02/WE05.
- Triage and reprocess in BD87.
- Work exceptions: unknown SKU, unit mismatch, invalid location, missing contract reference.
- Master data guardrails
- Keep material cross-references current (partner UPC/EAN ↔ your material).
- Validate location/site codes (plants, storage locations, sites).
- Normalize UOMs (EA vs CS) and dates (daily vs weekly buckets).
- Downstream sanity
- For 852: verify that activity updates are visible in replenishment/VMI dashboards or demand planning.
- For 867: verify resale lines are visible for rebate/chargeback or Condition Contract settlement and that accruals/settlements behave as expected.
Scenario 1: Retail VMI using EDI 852 (PROACT)
Business story
You supply camping stoves to a national retailer that wants vendor-managed inventory. Every night they send 852 with yesterday’s sales and current on-hand by store.
What arrives
For SKU CAMP-STOVE-100, you receive:
- Store 311, Date 2025-09-25: Sales 8, On-hand 24, Receipts 0
- Store 528, Date 2025-09-25: Sales 3, On-hand 7, Receipts 12
SAP flow
- Your EDI tool maps 852 → PROACT02.
- IDoc posts and updates your product activity repository.
- Your VMI logic (in SAP or IBP) sees Store 311’s on-hand is trending below target and proposes a replenishment to the DC.
Super user checklist
- Confirm material cross-reference: Retailer sends UPC 123456789012 → your CAMP-STOVE-100.
- Check UOM: Retailer sends CS of 4 but sales are in EA—mapping converts correctly.
- Verify planning result: You see a replenishment proposal for Store 311 or DC allocations reflecting the drop in on-hand.
- If the IDoc errors with “Unknown site 311,” add/maintain the site mapping and reprocess (BD87).
Value
Fewer stockouts, smarter allocations pre-promotion, better forecast accuracy because you see sell-through and on-hand, not just your shipments.
Scenario 2: Distributor resale & chargebacks using EDI 867 (S/4 Settlement Management)
Business story
You sell water filters to a distributor at a list price, but offer a ship-and-debit (rebate) when they sell to approved end customers in municipal accounts. The distributor sends 867 weekly: who they sold to, when, and how many.
What arrives
For SKU WTR-FILT-MUNI, week ending 2025-09-26:
- End Customer: City of Springfield Water Dept (ship-to 009876)
- Qty: 120 EA, Net resale price: $45.00
- Distributor transfer: from DC-01 to DC-03, 60 EA
SAP flow
- 867 → SLSRPT01 (or custom) lands in a staging area.
- Condition Contract (Settlement Management) finds a match for the end-customer group and SKU.
- System accrues the rebate or directly settles a chargeback/credit based on contract terms (e.g., $5/unit).
- Finance sees traceability from inbound resale to accrual/settlement lines.
Super user checklist
- Confirm end-customer mapping (distributor’s ship-to ↔ your customer master/partner function).
- Verify the Condition Contract includes this SKU and customer group and is valid for the resale date.
- Review calculated quantity base (did transfers get excluded if your rules say so?).
- If lines fail with “No contract found,” check condition contract determination and resale attributes (customer group, material, sales org).
Value
Fast, auditable channel programs. Lower dispute rates because your settlement math matches the distributor’s resale data.
Key master data and configuration (what trips teams up)
- Partner profiles & ports: WE20/WE21 must point to the right message type and process code (and the correct basic type, e.g., PROACT02).
- Material cross-references: Central table or custom mapping for UPC/EAN/customer material number ↔ MATNR.
- Location/site mapping: Retail store/DC codes to your plant/site IDs.
- UOM & pack: Align EA/CS and pack sizes; ensure conversions exist in MARM.
- Calendars & buckets: Decide daily vs weekly; capture “week ending Friday” logic consistently.
- Rebate/Settlement setup: ECC SD rebates or S/4 Condition Contracts with correct key fields; design how transfers and returns affect eligibility.
Monitoring, controls, and KPIs
- Operational controls
- 997 acknowledgements exchanged and monitored.
- IDoc status dashboards: counts by partner, by day; top error reasons.
- Exception queues: unknown SKU/site, negative on-hand, duplicate days.
- Health KPIs
- Timeliness of 852/867 receipts (e.g., >95% received by 10:00 local).
- Match rate of SKU/site (target >99%).
- Impact on forecast accuracy or OOS rate (852).
- Rebate/chargeback settlement cycle time and dispute rate (867).
Practical tips for a smooth rollout
- Start with a minimal viable mapping: SKU, site, date, quantity. Add price/PO/transfer flags later.
- Decide the IDoc by downstream use: If you need VMI and planning, PROACT fits. If you need resale for settlements, SLSRPT or a purpose-built Z-IDoc is safer.
- Backfill history: Ask partners for a catch-up of 6–13 weeks to seed planning and settlement baselines.
- Document your “truth rules”: Net vs gross sales, how to treat returns, how to handle inter-DC transfers, late corrections.
- Own the mapping tables: Give super users simple tools (ALV, Fiori list) to maintain UPC↔MATNR and site codes without waiting on IT.
Common issues you’ll recognize—and how to handle them
- “Everything posted, but planning didn’t change.”
Check the activity repository or planning interface job; confirm the bucket granularity (daily vs weekly) matches your planning run and that the posting date aligns with your horizon. - “Rebates missed a week of resale.”
Look for date misalignment (partner’s “week ending Sunday” vs your calendar). Validate Condition Contract validity windows and the precise customer/material keys used for determination. - “Tons of errors: unknown items.”
Refresh the UPC/EAN mappings or load new alternative UOMs. Often it’s one new product line missing from your cross-reference.
Quick start checklist (print this)
- Partner profile in WE20 with correct message/process codes
- Basic type chosen (PROACT02 or SLSRPT01—or your Z-type)
- Material and location cross-reference tables loaded
- UOM and pack conversions in MARM verified
- Staging/cleansing job scheduled; BD87 access for reprocessing
- For 867: Condition Contracts or SD rebates configured and testable
- Monitoring: WE02/WE05 views, error dashboards, and 997 tracking
- Agreed business rules (returns, transfers, late corrections, bucket logic) documented
Mini FAQ
- Do I have to use PROACT for 852 and SLSRPT for 867?
No, but they’re natural fits. Choose the structure that best aligns with your downstream processes. Many teams extend via Z-segments when they need extra fields. - Can 852 drive automatic replenishment?
Yes—commonly for VMI. You still need guardrails: target stocks, min/max logic, and exception alerts. - What changes in S/4 vs ECC for 867?
The big difference is using Settlement Management (Condition Contracts) instead of classic SD rebates. It’s more flexible, but you must align 867 keys (customer/material attributes) with contract determination early.
The bottom line
Think of 852 as your window into the shelf. It feeds replenishment and planning. Think of 867 as proof of who bought what. It feeds channel programs and settlements. As a super user, your superpower is keeping the mappings clean, the buckets aligned, and the exceptions moving so planners and finance see trustworthy results without wrestling with raw EDI.
If you have question on this or any other PortSAP Consulting blog please feel free to contact us at Blog@PortSAP.com. Or if you are looking for Top Quality SAP Consultants please feel free to contact us.
The author, Ray Hornbrook, has over 19 years of SAP functional and technical experience. Ray started his career in SAP as a MM/PP Subject Matter Expert (SME) for a SAP implementation in 1998 and is now a Senior Level SAP Consultant. Since Ray has worked both sides of SAP, business end user and IT professional, he is able to communicate effectively with both IT and Business team members. Having a background as an SAP business end user has helped Ray greatly in his consulting career. The business background helps him better communicate with the business members of the team. As well as helping bridge gaps in communication between the IT and Business team members.
To find out more about Ray Hornbrook please check out his LinkedIn profile by clicking HERE.
End of document – www.portsap.com
PortSAP Blogging 