One 850, several kinds of orders: transaction set variants explained
A new order, a rush order, a consigned order and a drop-ship order can all arrive as the same 850. One code near the top tells them apart, and it decides how you should handle the order.
BEG*00*NE*4500012345**20261001~ PO1*1*24*EA*8.40**UP*012345678905~ N1*ST*DC 0412*92*0412~
BEG*00*CN*4500012346**20261001~ PO1*1*24*EA*8.40**UP*012345678905~ N1*ST*DC 0412*92*0412~
A transaction set variant is one EDI document type used for several kinds of business documents. The structure stays the same; a code early in the file says which kind you received. In an 850 purchase order, that code is BEG02, the purchase order type.
Common 850 order types
| BEG02 | Order type | What usually changes for you |
|---|---|---|
SA | Stand-alone order | A regular one-time order |
NE | New order | A regular order, sometimes the first for an item or store |
RO | Rush order | Expedited picking and shipping |
CN | Consigned order | The retailer holds the stock; you are paid when it sells |
DS | Drop-ship order | You ship straight to the retailer’s customer |
BK | Blanket order | A framework order; releases follow |
The purpose code in BEG01 works the same way across all of them: 00 for an original order, 01 for a cancellation, 05 for a replacement. Read both before you act on an order.
Why the variant matters more than the format
Two orders can be identical line for line and still need different handling. A consigned order may not be invoiced the usual way, because you are paid only for what sells. A drop-ship order goes to a consumer’s address, often with its own packing slip and ship notice rules. A rush order changes your picking priority. The EDI is easy; the business rules are the part to get right.
How to handle variants
Ask which ones your partner sends
Most retailers use only a few of the dozens of codes the standard defines. Their implementation guide lists them.
Agree the rules before the first order
Decide with your team how each type is picked, shipped and invoiced, then map only the codes that actually arrive.
Route on the code, not by eye
A mapping can branch on BEG02, so a consigned or rush order is flagged the moment it comes in.
Variants inside a document, too
The same idea applies to segments. An 850 can carry an N1 loop several times, once with ST for the ship-to and once with BT for the bill-to, each with its own rules. Weredi’s guide pages show these as separate variants of the segment, so you can see what each one requires. For an example, open Amazon’s 850 guide or the summary of its EDI requirements.
In Weredi
Where a partner publishes them, its guide lists the codes it accepts for BEG02 and other coded elements, and the validator flags a code the guide doesn’t accept. In mappings, one expression can treat a consigned or rush order differently from a regular one.
The short answer
Before you build anything for an 850, find out which order types the partner sends, and decide what each one means for your warehouse and your invoicing.
Questions
What is a transaction set variant in EDI?
One transaction set, such as the 850, used for several kinds of business documents. A code early in the document, like BEG02 for purchase orders, tells you which kind it is.
What does BEG02 mean in an 850?
BEG02 is the purchase order type code: SA for a stand-alone order, NE for a new order, RO for a rush order, CN for a consigned order, DS for drop ship, among others. Each retailer uses only some of them.
What is the difference between BEG01 and BEG02?
BEG01 is the purpose of the document (00 original, 01 cancellation, 05 replace). BEG02 is the type of order. You need both to know what to do.
Keep reading
All articles →Know every order type before it arrives
Weredi’s guides list the order types each retailer accepts, and every document you send is checked against them.