Overview
The SLSRPT (Sales Report) message communicates sales activity data from the point of sale back through the supply chain. Typically sent from a retailer to a supplier, it reports how much of each product was sold during a given period at specific locations. This sell-through data is distinct from purchase order data (which reflects what the retailer buys) — it reflects actual consumer demand as captured at the checkout.
Sharing sales data via SLSRPT is a fundamental element of collaborative supply chain management. When suppliers have visibility into actual consumer sales, they can forecast demand more accurately, adjust production schedules, manage raw material procurement, and coordinate deliveries to minimize both stockouts and excess inventory. This collaboration benefits the entire supply chain through reduced waste, improved service levels, and lower safety stock requirements.
The SLSRPT message supports various levels of granularity. It can report sales at the individual store level or aggregated across a region or chain. It can cover daily sales, weekly summaries, or custom periods. The data can include quantities sold, returned quantities, promotional versus regular sales, and even sales value where pricing data sharing is agreed upon between partners.
Message Structure
The SLSRPT header identifies the reporting party, recipient, reporting period, and currency. Location segments define the reporting locations (stores, warehouses, regions). The detail section repeats for each product within each location, carrying sales quantities and optionally values for the reporting period.
Key Segments
| Segment | Name | Purpose |
|---|---|---|
BGM | Beginning of Message | Sales report number and type |
DTM | Date/Time/Period | Reporting period (start date, end date, or period code) |
NAD | Name and Address | Reporting party (retailer), recipient (supplier) |
CUX | Currencies | Currency for sales value data if included |
LOC | Place/Location | Store or location where sales occurred (GLN) |
LIN | Line Item | Product identification (GTIN) |
QTY | Quantity | Quantity sold, quantity returned, promotional quantity sold |
MOA | Monetary Amount | Sales value, return value (when sales value sharing is agreed) |
PRI | Price Details | Average selling price or promotional price during the period |
Sales Data Granularity
The level of detail in SLSRPT varies by trading partner agreement and business need:
- Store-level daily: The most granular level, reporting each product's sales at each store for each day. This is ideal for demand sensing and rapid response to sales trends.
- Store-level weekly: Aggregates daily data into weekly buckets per store. Reduces message volume while still providing location-level visibility.
- Chain-level weekly: Total sales across all stores for the week. Simplest to implement but loses store-level demand patterns.
- Warehouse withdrawals: Some implementations report withdrawals from the distribution centre to stores rather than actual POS sales, as a proxy for store-level demand.
Common Use Cases
- Demand planning: Suppliers feed SLSRPT data into their demand planning systems to generate sales forecasts. Historical POS data provides the statistical foundation for time-series forecasting models.
- Vendor Managed Inventory: Combined with INVRPT, SLSRPT enables suppliers to calculate consumption rates and generate replenishment orders that maintain agreed service levels at each location.
- Promotional analysis: By comparing promotional period sales with baseline sales, both retailer and supplier can evaluate promotion effectiveness and plan future promotions.
- New product launch tracking: After a product launch, daily SLSRPT data gives the supplier early signals about market acceptance, enabling rapid production adjustments.
- Seasonal planning: Year-over-year SLSRPT data supports seasonal demand pattern analysis, helping suppliers align production capacity with expected demand peaks.
Example Snippet
UNH+1+SLSRPT:D:96A:UN:EAN008'
BGM+73+SLS-2024-W11+9'
DTM+137:20240315:102'
DTM+194:20240311:102'
DTM+206:20240317:102'
NAD+MS+5412345000013::9'
NAD+MR+4012345000010::9'
CUX+2:EUR:4'
LOC+18+5412345000099::9'
LIN+1++4012345000027:SRV'
QTY+153:325:PCE'
MOA+203:8287.50'
LIN+2++4012345000034:SRV'
QTY+153:120:PCE'
MOA+203:1440.00'
LOC+18+5412345000105::9'
LIN+1++4012345000027:SRV'
QTY+153:210:PCE'
MOA+203:5355.00'
UNT+18+1'Implementation Considerations
Data quality and consistency are the primary challenges with SLSRPT. Ensure that the POS data feeding your SLSRPT generation is clean — handle voided transactions, returns, employee purchases, and inter-store transfers correctly. A common mistake is double-counting items that were scanned, voided, and re-scanned at the register.
Agree on the GTIN level for reporting. Retailers may sell products at a different pack level than they order. For example, a retailer might order cases (GTIN-14) but sell individual consumer units (GTIN-13). The SLSRPT should use the GTIN level that the supplier needs for demand planning — typically the consumer unit GTIN with quantities expressed in sellable units.
Timeliness matters for demand sensing. Daily SLSRPT data should be transmitted within 24 hours of the sales day. Delays reduce the data's value for rapid replenishment decisions. Automate the SLSRPT generation from your POS consolidation system and schedule transmission during off-peak hours.