1. Processes and Guides
  2. Trading with us via eCommerce (EDI)
  3. Electronic Data Interchange (EDI) with Foodstuffs
  4. The PO-MSG-ASN cycle
  5. Purchase order (PO) considerations

Purchase order (PO) considerations

NW DH Price scanner 2

Purchase Orders

The purchase order XML file can be broken into several sections:

Customer - the details for the deliver to entity. This is usually the Store or Distribution Centre to which goods will be delivered. It also specifies the Foodstuffs organisation to which the site belongs.

Supplier - usually the invoicing and supply entity details. If there is a distributor relationship (partner function) then this will identify the invoicing entity.

Distributor (optional) - the supply entity if there is a Distributor relationship, i.e. if a third party provides order fulfilment services (partner function)

Header - the background information relating to the order: reference, date, value etc.

Lines - the details of the products being ordered

Control - a check to make sure that the document is internally consistent

 

Identifying the trading parties

Each major entity or trading party (Foodstuffs company, supplier and distributor) is identified in the ORG_ID tag in each COMPANY section. This tag has an OrgType attribute that defines how the entity will be identified. 

The default is the eXchange account number ("EAN_Prefix")- a 3 to 7 digit reference for the entity's account at the Foodstuffs eXchange.

e.g. <ORG_ID OrgType="EAN_Prefix">789</ORG_ID>

Alternatively, you could use GLNs.

e.g. <ORG_ID OrgType="GLN">9429000008990</ORG_ID>

This setting requires us to set up a GLN alias for the supplier account. This is a Foodstuffs eCommerce function. You can call us on 0800 555 985 to set it up for you.

Identifying the unit of measure

Foodstuffs use the Retail GTIN (barcode number) as the default identifier for each product. It is important to note that this does not indicate the unit of measure. That is defined in the UNIT_OF_MEASURE tag and its associated attribute. We would normally order in cartons, so the content of the SUPPLIER_PRODUCT does not always define the UNIT_OF_MEASURE.

You need to refer use the UNIT_OF_MEASURE tag to identify the Unit of measure being ordered! You can do this  using the combination of these two attributes:

  • You can use the uomcode attribute to identify the type of unit being ordered. This will contain one of: "Retail Unit", "Inner", "Shipper", "Layer", "Pallet", or "KG".
  • You can use the numeric value of the UNIT_OF MEASURE to verify the carton size is correct. This is defined as the number of retail units that the UOM contains.
e.g.  <UNIT_OF_MEASURE uomcode="Shipper">12</UNIT_OF_MEASURE>

defines the UOM as a carton ("Shipper") of 12 eaches ("Retail units"). It follows that "Retail unit" uomcode attribute can only ever have a value of 1.

The Retail Unit is defined as the smallest size available for sale at retail - sometimes referred to as "each", "piece", "item" etc. 

Handling random weight items

From time to time, Foodstuffs will order items that cannot be defined as discrete units. These are most often butchery or produce items that are intended to be invoiced in kilograms.

These will be identified in the ORDER_LINE relating to the article. The optional RANDOM_WEIGHT_IND tag will be included and populated with "true". Additionally, the priceuomcode attribute will be defined as "KG". We'll normally order these in nominal weight cartons ("Shipper") so the (order) UNIT_OF_MEASURE and PRICE_UNIT_OF_MEASURE will differ.

e.g. For a nominal weight carton of 20Kg

<UNIT_OF_MEASURE uomcode="Shipper">20</UNIT_OF_MEASURE>
...
<PRICE_UNIT_OF_MEASURE priceuomcode="KG">1</PRICE_UNIT_OF_MEASURE>