EDI 852: product activity

What the document carries

Activity per item per location for a period, most often weekly. Sales, on-hand, and whatever further measures the programme includes. A partner with hundreds of stores sends hundreds of rows per item, so the volume is real even when the products are few.

It exists because the retailer wants suppliers planning against sell-through. An order tells you what a buyer decided; the 852 tells you what shoppers did.

What it is worth beside Odoo

The 852 is information. Nothing in Odoo has to change when one arrives; the value is in what it feeds: forecasting, production planning, and the conversation with the buyer about replenishment and range.

Landing it means storing it where it can be queried, keyed to the same item cross-references the order flow already maintains. The mapping work done for the 850 pays a second time here.

Where it goes wrong

The common failure is the quiet one: the feed arrives, nobody looks, and the signal is wasted while the supplier plans from gut feel beside a weekly report of actual sell-through.

The other failure is drowning: store-level rows accumulate fast, and without the item mapping and a summary view, the data is technically present and practically unreadable. Deciding the two or three questions the feed should answer comes before storing a byte of it.

The rest of the set

One document never travels alone. The mandate that asks for this one names its siblings, and the questions repeat: direction, mapping, and what happens when it is late or wrong.

For product movement and resale activity beyond store-level sales, continue with the EDI 867 product transfer and resale report.

Every code in plain language: the X12 catalog. What a late or wrong document costs: chargebacks and deductions. Who mandates and how it is enforced: the US programmes and the Canadian ones. How the documents fit into purchasing, fulfilment and accounting: EDI across the supply chain.