Retailer addendum for the harmonized Order to Cash (O2C) messages

Transcription

1 Retailer addendum for the harmonized Order to Cash (O2C) messages

2 Retailer addendum for the harmonized O2C messages (v ) Page 2 / 10 Content 1. Objective of the O2C Retailer addendum 4 2. Exceptions on the 1<>1<>1 principle 5 3. Not used O2C scenarios 6 4. Invoice processing 9 5. Validation in general 10

3 Retailer addendum for the harmonized O2C messages (v ) Page 3 / 10 Log of changes: Version Date Change 1.0 Sep Making document available Contact: ecom.support@gs1belu.org +32 (0)

4 Retailer addendum for the harmonized O2C messages (v ) Page 4 / Objective of the O2C Retailer addendum The O2C retailer addendum was created for informative purposes. It is intended to provide additional information for those who implement the EDI messages. It explains e.g. the reasons why a message may be rejected by retailers, or how certain information shall be processed by the retailers. This retailer addendum is however under NO circumstances to contradict the specifications from the harmonized messages, nor to lead to retailer specific syntax development. The retailer addendum is simply to give complementary insights.

5 Retailer addendum for the harmonized O2C messages (v ) Page 5 / Exceptions on the 1<>1<>1 principle Provided it was bilaterally agreed beforehand between the retailer and the supplier, certain exceptions on the 1<>1<>1 principle are. Currently in O2C documentation Basic: 1 order <> 1 DESADV <> 1 INVOIC (meaning 1 ORDERS message generates 1 DESADV message, which in turn generates 1 INVOIC). In case 1 voluminous order is split up over several trucks; 1 order <> 'n' trucks' <> 'n' DESADV <> 'n' INVOIC If backorder is : 1 backorder <> 1 DESADV <> 1 INVOIC Exceptions on used/ used/ If 'n ORDERS from 1 supplier consolidated in 1 truck; n ORDERS <> 'n' DESADV <> n INVOIC AND/OR 'If 'n ORDERS from 1 supplier consolidated in 1 truck; n ORDERS <> 1 DESADV (because of 1 truck) <> n INVOIC (Do e however that when the RECADV will be applied n<>n<>n<>n is the only way forward.) If n ORDERS from different suppliers consolidated in 1 truck; per supplier 1 DESADV resulting in 1 INVOIC. used used/ (1 DESADV per Order, 1 INVOICE per ORDER) used used/

6 Retailer addendum for the harmonized O2C messages (v ) Page 6 / Not used O2C scenarios The O2C examples provide for each scenario a message example. As a supplier you know of course which order, delivery and invoicing scenario you have agreed with your customer. Nevertheless this overview shows you which scenarios are by your customer(s), and thus helps you to avoid possibly un developments in your EDI environment. O2C scenarios (cf. examples) that are by the retailer ORDERS Simple order Direct delivery Cross dock order (only 1 ultimate destination) Transshipment order ( n ultimate destinations, cf. alloti) Backhauling order Platform order (cf. C3C) (Season) reservation order Actual order referring to the season reservation order webedi order Goods in consignment Promotional articles combined with regular Promotional article via separate order Free goods combined with regular goods Free articles via separate order Variable weight products Empty RTI Priority goods Consumer units (only for FR suppliers) DESADV Simple despatch advice for uniform and/or mixed pallets for DC delivery Crates - Non-serialized crates on pallets Empty crates as part of a logistic unit (stabilization crates)

7 Retailer addendum for the harmonized O2C messages (v ) Page 7 / 10 Empty crates NOT being part of a logistic unit Serialized crates on pallets Complex pallets - stacked pallets Half pallets delivered on mother pallet Half pallets without mother pallet but wrapped together Single half pallet Delivery of self-assembled trolleys (variable number of shelves) Goods with a variable weight Goods subject to traceability requirements Direct delivery to a store Cross docking & transshipment (synonym flux alloti ) Backhauling INVOIC Simple invoice (containing the minimal legally required elements) Exempt from tax (referring to EBL001 code) Exempt from tax (referring to full text) Penalty terms (optional) Conditional allowance (synonym: payment discount) Prepaid amount RTI - Charging (non-serialized) RTI Invoice containing returned RTI Consumer empties - Charging consumer empties Invoice containing returned consumer empties Line allowance in amount Line allowance in % Header allowance in amount Header allowance in % Line charge in amount Line charge in %

8 Retailer addendum for the harmonized O2C messages (v ) Page 8 / 10 Header charge in amount (transport only) Header charge in % Excise Consignment Display Free goods Bulk goods invoiced in its true physical dimension Semi-bulk goods O & D in units, but I in kg (via fixed conversion factor) Semi-bulk goods O & D in units, but I in its true physical dimension (weighed at reception) Semi-bulk goods O & D in units but I in a commercially agreed fixed dimension (although its true nature is variable). Credit e Correcting errors made in a previous invoice Credit returned goods Credit goods that were damaged, without physically returning them Credit returned RTI Credit returned RTI upon which a discount is applied mutual agreement Credit returned consumer empties mutual agreement Correct over invoicing (of price) Correct over invoicing (of quantity) Correct under invoicing (of price) Correct under invoicing (of quantity) Fully crediting and fully re-invoicing Debit e & Self billing

9 Retailer addendum for the harmonized O2C messages (v ) Page 9 / Invoice processing Does the retailer validate the invoice amount based on the gross price (PRI+AAB) or net price (PRI+AAA)? net price net price + gross price gross net price How many decimal digits does the retailer allow/request for the invoice to be acceptable...? For unit price (#54 PRI, DE 5118) 2 to 4 up to 3 5 max. 4 For total line item amount (#49 MOA, DE ) up to For summary totals (#83 MOA, DE 5004) 2 up to Remark Carrefour: If the field contains more than 3 digits after decimal point, then the value is truncated (no rounding)

10 Retailer addendum for the harmonized O2C messages (v ) Page 10 / Validation in general Does the retailer reject or accept the EDI message if it contains a ' Data Element (DE)'? E.g. DESADV UNB segment DE 0026 (application reference) accept, because the ' used element' will be ignored accept, because the ' used element' will be ignored We do allow certain ' data elements'. It is part of testing. accept, because the ' used element' will be ignored Does the retailer consider the following elements to be ' ', 'nice to have' or ' ideal but ' for a message flow to be Order to Cash compliant in terms of matching the EDI messages to one aher? Reference to the preceding message (e.g. RFF+ON) Exactly the same GTIN in the ORDERS, DESADV nice to and INVOIC have nice to have Not the same GTINs, but matching ideal ideal (recognizable) but but in terms of product hierarcy Same GLN in NAD+SU and the other parties nice to have nice to have ideal but nice to have nice to have