EDI 852 Product Activity Data: Using Sell-Through for Replenishment

The weekly sell-through file arrives every Monday, the replenishment planner downloads it into a spreadsheet, and by Wednesday the stores that sold out on Saturday are still waiting for a truck. When an order finally goes out, it is sized from on-hand figures that are six days old and ignore the cases already in transit. The supplier ends up shipping too little to the busy stores and too much to the quiet ones.

The X12 852 Product Activity Data transaction exists to fix that lag. It carries each location's on-hand, sales, receipts and on-order quantities in coded segments that a replenishment engine can read without a person opening a file. Mapped correctly and checked against the supplier's own shipments, it lets a vendor-managed inventory program calculate an order-up-to quantity per store each reporting period and round it to case pack.

• What this guide covers: the segment layout, the ZA activity codes worth mapping, per-store quantities in the SDQ segment, and the order arithmetic that turns them into a replenishment proposal.
• What it adds: a worked order in dollars and rupees, a unit-of-measure failure trace, the revenue and GST consequences for consignment programs, and an onboarding checklist for a new trading partner.

What the 852 carries, and how it differs from the 846 and 867

The 852 reports what happened to a product at the buyer's locations: stock, sales, receipts and orders. The 846 reports what inventory a seller or a location has available, and the 867 reports product transfers and resales. Choosing the wrong set for a replenishment program means mapping fields that were never designed to carry store demand.

X12's own description says the 852 can be used "to advise a trading partner of inventory, sales, and other product activity information," so that the partner can plan and ship, or propose replenishment quantities, for distribution centres, warehouses or retail outlets. The receiver is expected to keep movement records for its partners so that replenishment can be calculated from the data provided.

• 852 Product Activity Data: sent by a retailer, distributor or warehouse to its supplier; carries quantities by activity code and location for a reporting date or period.
• 846 Inventory Inquiry/Advice: used by a seller to state available inventory or by one location to inform another; our 846 mapping guide covers 3PL balance snapshots.
• 867 Product Transfer and Resale Report: reports transfers between locations or resales to end customers, and can include demand beyond actual sales, which suits distributor chargebacks better than store replenishment.
• 830 Planning Schedule: sends forecast requirements rather than actual activity; see our 830 planning schedule guide for how forecasts and firm releases differ.

Segment map: XQ dates, reporting location, LIN item and ZA activity

An 852 has a small heading and a repeating detail loop. Read the heading for the reporting period and the location, then read each LIN loop for the item and its ZA activity segments. Ownership of each field decides who fixes it when a value is wrong.

In the AmerisourceBergen version 4010 guide, the heading carries ST, the mandatory XQ reporting date and action segment, optional XPO preassigned purchase order numbers, and N1 loops. XQ02 is the report start date and XQ03 the end date when a range is reported; XQ01 carries a transaction handling code, with "G" meaning plan orders and ship product. The summary closes with CTT, whose CTT01 counts LIN segments, then SE.

ZA activity codes that drive replenishment, and the ones to park

Map four codes first: QA for current stock, QS for quantity sold, QR for quantity received and QP for quantity on order. Add QI and QO when the partner sends them; park the rest until a planner asks for them. Every quantity must be read with its unit of measure, in ZA03 or in SDQ01.

The ZA01 element is X12 data element 859, Activity Code. Retailer guides each pick a subset, and the AmerisourceBergen outbound 4010 map lists more than twenty, from bailment sales to retail sales quantity. Definitions matter: QA is "Current Inventory Quantity Available for Shipment or Sale," which some partners report net of damaged or held stock and others do not. Ask which one before using it as on-hand.

• QA, available quantity: the starting point of inventory position; confirm whether held and damaged units are excluded, because QH and HL codes exist to report them separately.
• QS, quantity sold: the demand signal; confirm with the partner whether it reports point-of-sale scans or shipments out of its own warehouse.
• QR, quantity received: receipts during the period; compare with what you shipped to measure in-transit loss and late receiving.
• QP, quantity on order: defined as on order, not yet received; check whether your open shipments already appear here before adding them again.
• QI and QO: quantity in transit and quantity out of stock; QO is useful as a lost-demand marker when QS reads zero only because the shelf was empty.
• QU and Q2: quantity returned by consumers and quantity returned; net them against QS only if the partner's QS is gross.

Replenishment from an X12 852 starts with four ZA01 activity codes, QA on-hand, QS sold, QR received and QP on order, each read with its unit of measure in ZA03 or SDQ01; a version 4010 import should convert every quantity to the item master's base unit and hold any file lacking a conversion factor.

SDQ versus an RL location: per-store quantities in one segment

An 852 states its reporting location either once in N1 with qualifier RL or per quantity in the SDQ segment, never both. SDQ lets one ZA segment carry up to ten store quantities, which keeps files for large chains compact and makes store-code mapping the most fragile step.

The transaction set notes in the AmerisourceBergen guide state that the reporting location is required and that the N1 with RL and the SDQ method "are mutually exclusive". They also require the item quantity either in ZA02 or in SDQ. In the 4010 SDQ layout, SDQ01 is the unit of measure, SDQ02 an identification code qualifier such as 92 for a code assigned by the buyer, SDQ03 the store code and SDQ04 its quantity.

Per-store quantities in an X12 852 travel in the SDQ segment as up to ten location and quantity pairs, SDQ03 through SDQ22, under unit SDQ01; a chain reporting 400 stores therefore needs 40 SDQ segments under each ZA activity code, and the import should count store rows against pairs received.

Because the pairs run from SDQ03 and SDQ04 up to SDQ21 and SDQ22, a translator that reads only the first pair silently drops nine stores in every ten. Build a test file that fills every pair in several segments, load it, and compare the store rows created with the number of populated location elements before the feed goes live.

ST*852*000004117~
XQ*G*20261102*20261108~
LIN**UP*012345678905*IN*448210~
ZA*QA~
SDQ*EA*92*01142*96*01187*41*01203*0~
ZA*QS~
SDQ*EA*92*01142*182*01187*77*01203*121~
ZA*QP~
SDQ*EA*92*01142*48*01187*0*01203*72~
CTT*1~
SE*11*000004117~

-- Order-up-to proposal per store (all quantities in eaches)
d      = sum(QS over n weeks) / (7 * n)        -- average daily sales
SS     = z * sigma_d * sqrt(L + R)             -- safety stock
S      = d * (L + R) + SS                      -- order-up-to level
IP     = QA + QP + T                           -- T = vendor units shipped,
                                               --     not yet in QP
Q      = max(0, S - IP)
Q_ship = C * ceil(Q / C)                       -- C = case pack
-- L lead time days, R review period days, z service factor

The sample is illustrative, built to the segment rules above: each ZA carries only its activity code, because SDQ carries the unit and the store quantities. In the formula, add T only for shipments the retailer has not yet booked into QP, or the same cases are counted twice. Rounding up to case pack is a business choice; some programs round to the nearest case and accept a small shortfall.

Turning on-hand, sales and receipts into a store order

A store order proposal is the gap between an order-up-to level and inventory position, rounded to case pack. With weekly 852 files, the review period is seven days, and the safety stock covers demand variability across lead time plus that review gap.

The worked example uses one item at one store in each market. Figures are illustrative: the same arithmetic serves a US chain sending X12 852 and an Indian retailer that shares the same quantities in another format. Indian law does not require X12; the trading partner agreement sets the file format.

The Indian column shows why the GST team belongs in the design. Rule 138(1) of the CGST Rules requires an e-way bill before moving goods whose consignment value exceeds ₹50,000, and Explanation 2 counts the tax charged in that value. A store order sized purely by the formula can cross the threshold, so the shipment planner should know which proposals need one before the truck is booked.

Checking the 852 against your own shipments before trusting it

Retailer activity data is only as good as store receiving, so compare QR with what you shipped and delivered before letting QA and QP drive orders. A gap that persists for more than two reporting periods points to a mapping or receiving problem, not to demand.

• Receipts versus shipments: sum QR by store for the period and compare with delivered quantities from your proof of delivery; flag stores where the difference exceeds one case.
• On order versus open shipments: list your shipped-not-received units by store and check whether they already appear in QP; this decides whether T in the formula is zero.
• Zero sales with zero stock: treat QS of zero alongside QA of zero, or a QO value, as unmet demand rather than no demand, or the formula will shrink the next order.
• Period continuity: confirm that each file's XQ02 follows the previous file's XQ03, so a missing week is detected before averages are calculated.
• Line count: compare CTT01 with the LIN segments received; a mismatch means a truncated file, which a functional acknowledgment alone may not reveal.

Incident trace: a unit-of-measure slip that tripled a store order

The fault below came from one changed element in the retailer's map, and the supplier's translator accepted it because the code was valid. A unit check against the item master would have stopped it at the first file.

1. Mon 2 Nov, 06:10: File 000004117 arrives for the week ending 1 Nov. The retailer has switched store 01142's QA from eaches to cases after a system upgrade, so SDQ01 reads CA and the store reports 8 instead of 96.
2. Mon 2 Nov, 06:12: The translator validates the segment, sends the 997 acceptance and loads 8 as eaches because the import ignores the unit element.
3. Mon 2 Nov, 07:30: The replenishment run sets inventory position at 8 + 48 = 56 against S of 314 and proposes 22 cases, 264 units, instead of 15 cases.
4. Tue 3 Nov, 14:00: The order ships under VMI auto-release. Store 01142 receives 84 more units than planned, enough for over three days of sales, and its backroom fills.
5. Controlled path: the import compares SDQ01 with the item master pack levels, converts CA to eaches at 12 per case, writes QA as 96 and logs the change for the EDI analyst; the proposal stays at 15 cases.

Consignment programs: when QS becomes the revenue trigger

Where the supplier still controls stock on the retailer's shelf, the 852 sales quantity stops being a planning input and becomes the basis for revenue and invoicing. Accounting and GST teams then depend on the same QS values the planner uses, so the data needs stricter controls.

Under US GAAP, ASC 606-10-55-80 lists indicators of a consignment arrangement: the entity controls the product until a specified event such as sale to the dealer's customer, can require its return or transfer, and the dealer has no unconditional obligation to pay. PwC's guide illustrates a manufacturer recognising revenue when consumers buy from the retailer. Ind AS 115 carries matching consignment guidance in paragraphs B77 and B78.

In a scan-based or consignment program, the supplier recognises revenue when the retailer's 852 reports quantity sold, because ASC 606-10-55-80 and Ind AS 115 paragraph B77 keep control with the supplier until consumer sale; QS values that drive invoicing should reconcile to the retailer's settlement within 0.5% each period.

India adds a GST timing rule. Section 31(7) of the CGST Act says that where goods sent on approval for sale or return are removed before the supply takes place, the invoice must be issued before or at the time of supply or six months from the date of removal, whichever is earlier. A consignment program that bills only on reported sales therefore needs an ageing report on stock moved to stores without an invoice.

Translator rules versus planner judgement on 852 feeds

Syntax, code lists, units and period continuity can be checked by fixed rules every time a file arrives. Whether a sales spike is real demand, a promotion or a data error is a judgement for a planner, though software can rank the proposals that deserve a second look.

Onboarding checklist for a new 852 trading partner

Most 852 problems are settled in the first fortnight of onboarding, when the partner's guide is mapped against your item and store masters. The checklist below records the questions to close before any proposal is released without a planner's review.

The planning side of these programs, including how sell-through feeds into collaborative forecasts, is covered in our CPFR software and S&OP workflow article, which focuses on forecast reconciliation and tool choice rather than on 852 field mapping. Min-max locks for VMI are set out in our VMI min-max model, and related EDI topics sit on the logistics and supply chain hub.

If you are choosing a translator or replenishment tool to run an 852 program, list the unit check, SDQ handling, period continuity test and shadow-run reporting as mandatory requirements in your request for proposal, and ask each vendor to process a ten-store SDQ test file during the demonstration.