Metcash V7 Host

Recommended Field
Implementation
Guide - Liquor
(for host version 7.1.0)

Ver 2.0.6
Contents
Revision History ................................................................................................................... 4
Purpose of Document .......................................................................................................... 6
Host Collection..................................................................................................................... 7
Header node (including File Type Indicator) ........................................................................ 7
Host Process Reporting: ............................................................................................... 8
Host Process Flow ........................................................................................................ 8
Effective Dates:........................................................................................................... 10
Business Pillar ................................................................................................................... 11
MSC – Metcash Standard Commodity ................................................................................ 12
Field Size ........................................................................................................................... 19
Product Description and Size ............................................................................................. 20
Alternate Description ......................................................................................................... 21
Warehouse Indicator .......................................................................................................... 22
Product Grade ................................................................................................................... 23
Product Group ................................................................................................................... 24
In-House Branding ............................................................................................................. 24
Australian Made ................................................................................................................. 26
Country of Origin ................................................................................................................ 26
Availability .......................................................................................................................... 26
Ti Hi ................................................................................................................................... 27
Fees ................................................................................................................................... 28
Child Code (Product Linking) ............................................................................................. 29
Cigarettes Per Sleeve ........................................................................................................ 34
SRP Compliance - Diamond .............................................................................................. 34
GTIN PLU .......................................................................................................................... 36
Promotions (Critical for V7 Implementation) ...................................................................... 38
Promotion Placement......................................................................................................... 43
Retail Offers (Not populated on initial go live) .................................................................... 44
Metcash PDE Software ...................................................................................................... 45
Appendix A ........................................................................................................................ 46
Appendix B ........................................................................................................................ 47
Appendix C ........................................................................................................................ 48
Appendix D ........................................................................................................................ 49

Page: 2
Frequently Asked Questions .............................................................................................. 50
Key Metcash Contacts ....................................................................................................... 54

Page: 3
Revision History

Version Date Name Section Notes

2.0.2 7th August, 2015 Colin Higgins Host Collection Added requirement to change web
services protocols when moving a
store to V7 host
2.0.2 7th August, 2015 Colin Higgins Effective Dates Added information relating to
effective dates for cost and sell –
Metcash cannot guarantee cost or
sell promos will not overlap.
2.0.2 7th August, 2015 Colin Higgins GST On Analgesics Updated XML example

2.0.2 7th August, 2015 Colin Higgins Recommendations Added dept reporting as desirable
for MSC
2.0.2 7th August, 2015 Colin Higgins Field Size Added notation that 3 digit prefix to
be added to existing 5 digit supplier
number
2.0.2 7th August, 2015 Colin Higgins Product Updated XML sample
Description and
Size
2.0.2 7th August, 2015 Colin Higgins In House Branding Updated XML sample and reworded
advice and explanation
2.0.2 7th August, 2015 Colin Higgins Australian Made Updated XML sample and reworded
advice and explanation
2.0.2 7th August, 2015 Colin Higgins In House Branding Added more details to In House
branding
2.0.2 7th August, 2015 Colin Higgins Australian Made Updated XML sample and reworded
advice and explanation
2.0.3 11th August, Colin Higgins MSC Added note on Parent/Child
2015
2.0.3 11th August, Colin Higgins Retail Offers Added note re web services
2015
2.0.4 29th February, Colin Higgins Product Grade Added note on how Foodworks will
2016 use Product Grading
2.0.4 29th February, Colin Higgins In House Branding Updated XML sample
2016
2.0.5 3rd February, Colin Higgins FAQ Added question on effective date
2017 and Order Multiples
2.0.5 3rd February, Colin Higgins Contacts Updated Contact details
2017
2.0.5 3rd February, Colin Higgins Promotions Added advice on “U” and “I”
2017 received in a host maintenance file
under certain conditions.
2.0.5 3rd February, Colin Higgins Promotions Updated advice on Promo ID delete
2017 with regards to Zones

2.0.5 3rd February, Colin Higgins Child Code Added advice regarding deleting of a
2017 (Product Linking) Parent item code, and information
and FAQ’s on the use of OM, MOQ and SM

Page: 4
Version Date Name Section Notes
2.0.5 3rd February, Colin Higgins Host Process Flow Added advice on how to handle a
2017 situation where the GTIN is moved
from one item to another.
2.0.5 3rd February, Colin Higgins MSC Added advice confirming
2017 “Categories” will not be deleted, but
descriptions may change to reflect
the status of delete.
2.0.5 3rd February, Colin Higgins Weighed Added illustration of alternative
2017 products and how they can be
handled.
2.0.5 15th March, Colin Higgins Australian Made Changed advice to ignore
2017 implementing this field pending new
legislative requirements.
2.0.5 15th March, Colin Higgins Promotion ID Additional clarification of how
2017 Promo ID’s are hosted.
2.0.5 15th March, Colin Higgins Retail Offers Previous advice removed as details
2017 of future offers hosting is under
review.
2.0.6 13 November Brendan Product Delete Clarified that deleting a parent item
2017 McKeown code implies the children are
deleted, but the host advice may
include advice for both the parent
and its children.
2.0.6 15th May, 2018 Colin Higgins Product Grade Advice altered slightly to reflect
change in business usage of this
field.

Page: 5
Purpose of Document

The purpose of this document is to highlight certain aspects of the Metcash V7 host specification that might
require further explanation for greater understanding of how and why it is to be implemented.

This document is to be used in conjunction with the V7specification and the V7 Minimum Specification
Spreadsheet to provide additional information on specific sections along with the implementation
requirements Metcash deems necessary upon transition to using the V7 host. It also contains
recommended implementation guidelines that would be of benefit to retailers at launch, and separates
those that could be placed on hold until after initial rollout should time prevent a Vendor from meeting the
guidelines given time constraints to meet the deliverable date.

The V7 Minimum Specification Spreadsheet provides the following additional information:

 A matrix comparison between V5 and V7 host specifications
 V7 suppliers List
 V7 MSC structure list
 Business Pillar Codes List

This document should not be seen as the only requirements for V7 implementation. Retailers are looking
for an edge on their competitors and Metcash encourages Vendors think outside the box and make
provision to allow retailers to make use of the data provided to enhance the retailer experience and
improve the profitability of retailers by using the data to make better decisions. The additional components
of the V7 host can be used to improve reporting, stock control, business processes, ticketing etc.

Page: 6
Host Collection

Host collection will change under the V7 host model. It will be a requirement to change web services
protocols when moving a store to V7 host. The new web services will allow for greater flexibility and
integration with POS systems.

For further details, please refer to the Retail Web Service V7 Host specification.

Header node (including File Type Indicator)

The header node contains key information to identify which store, and what warehouse the information is
supplied for. This will enable differentiation on products where multiple host files are processed into a back
office system.

The “Type” field will be used to identify the differing files a store might receive from Metcash. The file types
a store may receive are:

 I – Initial Host (supplies the full gambit of information from MSC, supplier and product
details)
 M – Maintenance Host (commonly a weekly host, but a file that contains increases and
reductions, new lines, product detail changes, promotions, offers etc)
 A – Ad hoc File (commonly used to produce “refresh files” which are effectively cost and
sell records only)
 P – Promotion File (contains only promotional information relating to a specific period)

It is envisaged that when attempting to collect host, the store user may choose from the different file types
on offer. Ordinarily, weekly maintenance files will be the most common downloaded for processing.
However, in conjunction with Metcash Retail Technology, users may request other file types for various
reasons.

The use of file types will be required to ensure users receive the correct file when communicating via web
services to the document repository. Please review the new web services V7 specification for further
details.

The “Type” indicator can be seen in the XML extract below. In this instance, it is “I” for Initial file.

Page: 7
Host Process Reporting:

It is expected that reports identifying the changes brought in by the host would continue to be made
available, although it is recognized that this reporting will need adjustment given the additional data
elements available in the V7 host. The expectation is that retailers should have clear visibility to all changes
in the host as they relate to each product.

Host Process Flow

The V7 host specification relies upon certain actions taking place before others (priorities) when processing
host elements. The requirement is for the following elements to be processed in order of priority:

For MSC (Department, Category, Commodity and Sub-Commodity):

1. Action = I: Insert
2. Action = U: Update
3. Action = D: Delete

In practice, let’s say we want to delete a sub commodity. It has products linked to it. Logically, one could
not delete the sub commodity first, since the products attached to that commodity must be moved to
another sub-commodity first, thereby needing the update records processed first. If these products were to
move to a brand new sub-commodity, then we would need to insert that sub-commodity, then update the
products, then we could delete the old sub-commodity.

For Product Node details:

1. Action = D: Delete
2. Action = I: Insert
3. Action = U: Update

In practice, the V7 host may provide for deletions and inserts or updates in the same host file. A case in
point would be the moving of a GTIN from one item to another. In this case, an “Insert” is applied to the
product receiving the GTIN. An “Insert” and a “Delete” is applied to the item where the GTIN is to be
removed. The “Insert” adds the new GTIN to that item, while the “Delete” removes the “problem” GTIN. In
this example, the “Delete” would need be applied first.

Example of this scenario in XML can be seen on the following page:

Page: 8
Item with the GTIN being removed, and new GTIN added. Note that the GTIN being deleted is the same as
that being inserted above:

Page: 9
Effective Dates:

It is recommended vendors make use of the effective dates provided in the host. For example, a price
increase comes through on host for both cost and sell, the cost should be changed in the BOS to reflect the
host based on the effective date (No recommendation on when the sell should change is provided which
allows for current functionality to continue, however it is suggested that the retailer should be able to
process the host, and determine when the sells will apply). This will ensure that GP’s are as accurate as
possible, and that the cost in the system reflects that on the invoice supplied from Metcash.

Metcash cannot guarantee that either cost, or sell promotions will not overlap.

For further clarity on the use of effective dates, please review below scenarios:

Cost

Effective Dates for cost should apply once the host is processed, back date if possible.

For example, the host file was generated 16/05/2015 and an item with an immediate price change of
16/05/2015. The retailer collects and processes the file 19/05/2015. Ideally, the BOS would apply and back
date the cost to 16/05/2015. (Back dating only for the purpose of showing when the price was meant to
take effect. It is not expected that BOS Vendors re-calculate previous sales information for reporting
purposes with the correct date should the above scenario occur, although if possible, then it would be
welcomed.)

If an item has a future effective date 25/05/2015, then apply the cost change on that date.

Sell

The retailer can choose when to apply the sell price, however there should be an option for Tobacco and
Liquor items to apply the Sell on the effective date. A way this could be implemented is to apply effective
date to RRP for item type T).

For greater flexibility, the ability to toggle this feature on or off would be welcomed. For example, turn the
feature on when a CPI change is coming via their weekly maintenance file.

Page: 10
Business Pillar
Business Pillar can be found in the “Header Node” (page 11) and the “Product Subnode” (page 29) of the
Metcash V7 Host specification document.

The Business Pillar indicator may be utilised for consolidated host (i.e. an IGA, CSD & ALM host in one file).

The Business Pillar indicator will also help determine where an order should be sent for items that are
similar (i.e. foodservice items that are orderable from CSD but perceived to be an IGA item)

XML example:

Business Pillar Types:

ALM – Liquor
CCC – Campbells Cash and Carry
CSD – C-Store
CWD – Campbells Wholesale Distribution Product Subnode
IGA – IGA Distribution
TAS - Liquor

Header Node

Page: 11
MSC – Metcash Standard Commodity

Background Information

The V7 host contains Metcash Standard Commodity structure. To keep pace with competitors, and to allow
for better reporting and analysis, the MSC structure is an important change to host with advantages such
as:
 Allowing Metcash and it’s retailers to analyse business trends using the same data set
 Allow Metcash to assist retailers achieve greater profits through better Scan Data analysis, and in
turn implementation of profit improvement strategies based on the analysis
 Improved benchmarking and store comparison reporting, again helping to improve retailer
profitability by having access to better data
 To better manage on-line offers between differing retailers ensuring consumers see the same, no
matter which store they are buying from.
 Potential to reduce in-store workload through better host mechanisms for directs. Metcash may be
able to host more direct lines in the future and assign them to MSC.

Metcash currently host the MLC only, a 3 digit number identifying a group of products such as 724 which is
Matches/Firelighters (For WA the code is 819 Variety - Other and for SA 186 Other Variety).
Under v7 host, Dept, Category, Commodity, and Sub Commodity will be hosted. For example: General
Merch 17, Outdoor/Leisure 326, Barbecue / Coolers / Picnic 01, Firelighters 01. By joining these together a
unique dept structure code is formed, 173260101.

Both the MLC and MSC structure will be hosted initially in v7, but there is no guarantee on how long the
commodity will be hosted for. By virtue of the fact a product can be hosted with both the MLC commodity
and the new MSC Dept Structure code, a map can be created between the new and the old structures.

A requirement of the new v7 MSC structure is that stores MUST be able to produce reporting and return
Scan Data for warehouse and direct items based on the new MSC structure. It is also noted that stores may
find the structure unpalatable so reporting on the both the MSC and a form of In-store hierarchy is
required.
There are a number of factors to consider when determining how stores should manage their product file,
dept hierarchy and reporting. They are:
 Only hosted items will have a MSC
 Stores providing scan data will be required in the future to provide the MSC details of products sold
 Not all products are hosted to stores
 New direct lines loaded at store level must have some form of GUI which enables linking back to
the MSC
 Stores will need a form of GUI to link existing direct lines to a MSC structure
 A mapping table is recommended to allow reporting in either MSC and In-Store hierarchy
 Reporting must be available by MSC and In-Store hierarchy
 Stores must have access to an interface to allow for mapping of MSC to an In-Store hierarchy
 New stores should be setup using only the MSC (for discussion MSO’s)

So, how will this be implemented and maintained?

Page: 12
Each product will be hosted with both the MLC and MSC structure. E.g:
001129 SCHICK QUATRO BLADES TITAN 4S –
 MLC = East Coast: 665 RAZORS AND RAZOR BLADES
WA:719NON FD - RAZOR / BLADES
SA: 89 SHAVING REQUIREMENTS
 MSC = 09 H.B.A., 114 Health & Beauty, 16 Shaving Needs, 05 Blades –
Premium (091141605)

A new direct shaver should be loaded to 091141605. You could do this a number of ways but one
suggestion is to do the following:
Load the product by choosing the correct MSC structure. Each level is filtered on the selection above. E.g.
the sub-comm Blades – Premium only shows once the Commodity Shaving Needs is selected. Blades –
Premium would be one of a number of selections the user can make and is dependent upon how many sub-
commodities have been hosted.
A drop down box allowing user to select
from available depts.

A drop down box allowing user to select

from available categories.

A drop down box allowing user to select

from available commodities.

A drop down box allowing user to select

from available sub commodities.

The user cannot make a selection here as

A mapping setup might look like the following:
it is dependent upon the MSC structure. A
table linking In-Store Depts to the MSC
structure with a user interface where this
mapping can be setup and maintained is
recommended

This table illustrates a link between an MSC code and a possible in-store
Dept. In this model, all hierarchy items from Category and lower remain the
same when reporting in either the MSC or In-Store hierarchy.

A store needs to be able to add their own codes under the MSC dept 99. In the future, some in-store
categories may become hosted so the vendor needs to allow for this.
For example, if the store sells fuel, they might want to setup a reporting level called fuel. Following the
above rules, we could add fuel similar to below:

Page: 13
 All items highlight blue are setup in store
according to retailer requirements.
This is hosted as an in-store use dept.

Metcash may decide to host (for example Fuel or Newsagency as per example above) these departments in
the future. The new hosting should re-map the store setup, to the new MSC structure as it evolves. So if
Newsagency was to become a hosted MSC dept, then items would be hosted with the new structure and
therefore be required to move with the new structure. This would then mean the new Newsagency MSC
dept would have no – instore mapping. This could easily be fixed by using the methods above to add the
new MSC to an existing or new in-store department.

Reporting:
The GUI for reporting purposes needs to allow for stores to be able to print reports for either the MSC
structure or the In-Store structure. It also needs to allow for interrogation of the lower levels of the
departments for deeper analysis.

Other impacts:
There are other parts of most systems which may be impacted due to the change in dept structures such
as:
 Auto Ordering or Computer Aided ordering, and
 Exporting to accounts packages
 Sales to Dept keys (if store wants to use only MSC, but impact if using the instore structure should
be minimal or null)

In these instances, allowing options for the retailers to move to the new MSC is recommended, but in order
to limit the change management in transitioning from the current structure to the new, it would also be
recommended to allow no change to these routines if possible.

For example, in the mapping below, if a store currently used an Instore Dept such as Grocery in an Auto
Ordering filter to order from the Metcash warehouse, then this might be retained by the user. Should the
user wish to move over to the MSC, they should be able to, but would need to be aware that Biscuits exist
in a different category to Grocery.

However, should a store order by MLC currently (that is at a commodity level), then migrating these order
routines to the new MSC may make more sense. A migration map may be required upon changeover to
assist retailers in converting. Thought needs to be given as to how best this is handled in your system.

Page: 14
Please note any changes to the MSC structure will be hosted as a change record, and any products
subsequently affected by the change will also be hosted with this change information as per the XML.

When processing changes to MSC, it is recommended that structure changes be processed first, then
inserts and updates, with deletes following.

Should a Sub Commodity for example be deleted, the products will need be moved to a new Sub
Commodity before the Sub Commodity could be deleted. This is how Metcash would handle the change
internally, and therefore, the host would reflect this. It would mean products are hosted with the updated
changes, and a deletes record sent to remove the Sub Commodity. If a new Sub Commodity was to be
included, it would have to be hosted too, and subsequently, products attached to that Sub Commodity
would be hosted with the MSC details they are loaded to.

Please Note: We’ve confirmed that while the interface technically supports deletion of a “Category”, it
won’t happen in practice (because the Category value has to be preserved to maintain referential-integrity
with other systems within Metcash).

As a result, the description will be changed to reflect its practical deletion. You may choose to delete this,
but consider that if for some reason it is re-instated with the same code, it would be hosted as a “U” action.

Note you will see delete advice on commodity and sub-commodity records. There is no referential-integrity
requirement on these.

The Hosted MSC should not be changed in any way by instore users. Any maintenance should be prohibited
except via host. The only exception is the category range Metcash has set aside for instore use only. The
Categories 995 to 998 will be made available for Instore Use Only. Only the below table of figures will be
hosted. This means a store can add their own Sub Commodity and Commodity under these categories until
all 99 codes are used.

This will allow Retailers to add departments and sections of their own choosing that do meet existing MSC
structures.

Required for Initial Implementation

 The MSC structure

 For each product, the MSC should be visible on screen
 Dept Reporting (same reports in system currently for MLC) based on MSC structure is required,
however only reporting for Dept Sales based on MSC is required at go live.
 Changes to ordering, exporting, dept keys or other areas of your system that might be impacted
from changes to dept mapping

Page: 15
  Map direct items to the Sundries MSC category (use the mapping in place for MLC to MSC
structure) where no Directs lookup file containing the correct MSC exists for the item.

Recommended but not essential for Initial Implementation

 Dept Reporting (same reports in system currently for MLC) based on MSC structure is required,
however only reporting for Dept Sales based on MSC is highly desirable at go live. Please keep in
mind, that Metcash initiatives ranging from “The Shopper Led Way”, Retail Analytics App,
Space/Shelf Management, Retail Offers and loyalty to name a few, all use the MSC to analyse
performance and drive improvement, and alignment for retailers to view reporting in the MSC is
functionality, highly desirable at go-live. It is definitely a requirement in the mid term, that systems
can report in MSC. This should be on your roadmap as a deliverable as soon as practical.
 Drill down reporting by MSC structure

Please Note: In a Parent/Child Relationship, the MSC is not populated on the child node as it belongs to the
same MSC as its parent. Under the old MLC, some items such as Cigarettes had “Parents” or cartons which
belonged to one MLC and the “Child” or packets belonging to another MLC. The MLC in this case will not be
hosted on the product, and will be deemed redundant data, just as the MLC structure in its totality will
cease to exist in the future, and at some point become redundant and cease to be hosted.

Page: 16
XML example showing the legacy commodities

XML example showing the Standard Commodity structure, starting with “Department”:

Page: 17
XML example of the product node containing the MLC and MSC structure

Page: 18
Field Size

8 digit item code and customer number, along with 8 digit supplier code is a significant change and one that
is required for business continuity reasons to be implemented as soon as possible.

Immediately effective after implementing a V7 host, existing product numbers are effectively 8 digit item
codes with 2 leading zeros added to make it 8 digits.

The customer number will have a specific prefix assigned to create the 8 digit code.

Supplier numbers will change to be 8 digit. A 3 digit prefix will be added to the existing 5 digit number.
Please ensure your processes update the supplier number and don’t simply create (or append) a new
supplier for the new longer number. Most codes will be State orientated and receive the State prefix. See
appendix A for an example of how the numbers look in each state.

An example of the Supplier node in XML can be seen below:

Required for Initial Implementation

 Be able to accept and use 8 digit item codes

 Be able to receive the V7 e-invoice (with 8 digit item codes)
 Be able to send an order with 8 digit item codes (Current Order file spec allows for 8 digit item
codes)
 Reports that show the item code must be changed to allow for 8 digits
 Ticketing updated to include 8 digit item code
 Customer field updated to allow for 8 digits
 Supplier code updated to allow for 8 digits (Add prefix to the existing 5 digit supplier code)
 PDE software to cater for 6 and 8 digit barcodes on the tickets to prevent the need to re-ticket the
whole store on changeover to V7.

Recommended but not essential for Initial Implementation

 A re-ticket of the store should not be required and only new tickets will need to cater for the 8 digit
item code.

Page: 19
Product Description and Size

The V7 Host provides for a Legacy Description (as per the current V5 specification) it remains at the current
30 characters in length. Product Size is a new field designed to show the size of the product for display,
searching, and reporting purposes.

Required for Initial Implementation

 The Legacy Description and Alternate Description to be used for ticketing, reporting and receipt
purposes.

Recommended but not essential for Initial Implementation

 The new product size field to be shown on product details screens, but not required for ticketing or
POS receipting.
 The new product size field may be useful for reporting, searching, sorting, or grouping on products
of like size.

Page: 20
Alternate Description

The V7 host also allows for an “Alternate Description” where items are linked. The child item will have the
alternate description which is designed for use where the child is a selling unit, where a ticket and receipt
description is required.

An example of the Alternate Description in the GTINPLUUnit Node as it would appear in the V7 host.

Required for Initial Implementation

 Yes. To be used for ticketing, receipt and reporting purposes.

Page: 21
Warehouse Indicator

The table below describes the WarehouseDirectIndicator, Indicator “F” & “N” are new and introduced to
Host Version 7 (“F” is included in Host Version 5.6). Host version 5.8 is to be used for Fresh only and will
cater for 8 digit item code and will be a flat file. Please refer to the V5.8 specification for further details.

Warehouse Description Notes

Indicator
D Direct (Order directly from supplier)
E Direct (Orderable through Metcash)
F Fresh Produce (Orderable through Metcash)
L Trade Show Delivery Date
N NDC (Orderable through Metcash)
T Trade Show Event
V Variety (Orderable through Metcash)
W Warehouse Line (Orderable through
Metcash)
Z Slow Moving Item (Orderable through
Metcash)
Hosted only, must order directly with Supplier
Ordered and invoiced by Metcash but supplied
directly by the Supplier
Fresh Produce Lines supplied by the Fresh
Warehouse
Applies to Victoria, Fast Moving lines supplied by
the Slow Moving Warehouse (Closed on
Weekends)
General Merchandise Lines
Items supplied by the Slow Moving Warehouse

If Metcash provides a combined Business Pillar Host, the Business Pillar indicator combined with the
Warehouse Indicator would ensure the order goes to the correct place.

Please note that in Victoria, there are items that have a Warehouse Indicator of N and a Slow Moving flag
of N, meaning the item is only available Mon to Fri for Victorian Retailers from the NDC warehouse.

Required for Initial Implementation

 Use of additional indicators are treated accordingly

 Allow for additional Warehouse indicators to be added as the need arises

Recommended but not essential for Initial Implementation

 Trade show indicators can be used to validate orders. For example, if an order contains an item that
has a Warehouse Direct Indicator of L or T then ensure that:
- Only 1 L Item is provided
- Only 1 T Item is provided
- If an L or T item is provided, ensure both a single “L” item & a single “T” item are provided

Page: 22
Product Grade

The Product Grade flag will help the retailer with ranging. It is designed to allow varying size stores to easily
determine the basic products that should be available in their store. It also allows for a way to manage
seasonal lines, such as Christmas and Easter specific items. The table below gives some more guidance
around what to expect.

Product Description
Grade
A All Stores; A’s are staple products & suitable for all stores regardless of the size of the store.
These items are core for all IGA’s and as such will form the basis for catalogue promotional
activity
B Medium Stores; B’s would be suitable for IGA sized stores
C Large Stores; this means that this line is suitable for all larger stores
S Seasonal Lines; e.g. Easter Eggs & XMAS Lines
O Food Service & Allocation Lines; Stores use lines and extra lines loaded by the National
Buyer and will not be in any of the Retail Space Plano Grams
N New Lines
Note Directs Lines are not graded as they are deemed local to the store. These products are
unlikely to be included in the layouts provided by Metcash.

*The following are example uses of the Product Grade definition

 All SUPA IGA’s (Channel 1 or Large Stores) should carry all A,B,C graded lines
 All IGA’s (Channel 2) should carry all A & B graded lines (pending on size of store)
 All smaller stores (Channel 3) would carry all A graded lines

The Product Grade Field is a MANDATORY field and is viewed as highly important by the IGA business in
driving consistency and foot traffic.

Foodworks Grading

Foodworks grade products using codes A through to G, therefore, Foodworks may use different values to
that listed in the table above. Grading for Foodworks customers ties in with planograms issued by
Foodworks and is deemed mandatory at go live of V7 launch for Foodworks retailers.

Please note: there are no rules around the use of the N flag, although it is envisaged that a period of up to
12 weeks is likely to be used as the “new line” period, after which the product grade will change according
to Category Management decisions.

Required for Initial Implementation

 Yes, mandatory for initial implementation

 BOS Vendor to receive any grading character that is hosted
 Show on the product screen, and in handheld device software what the product grade is
 Warning on screen when attempting to “de-range” from store

Page: 23
  Be able to display on the shelf edge label what the product grade is
o If label option is active for “Product Grade”, generate a label if the grade has changed
o If label option is not active for “Product Grade”, do not generate a label if the grade has
changed
 Reporting to have ability to report sales, G.P. etc by grade
 Host reports showing products changing product grade in the host
 Report showing product grading for ranging purposes. E.g. an exception report showing “A” lines
not ranged, or “C” line ranged which would be useful for an Xpress store

Recommended but not essential for Initial Implementation

 Reporting to show whether items are seasonal or not

Product Group

Product groups are a way to group products for a suggested retail price. It could be used to report on a
group of items, for example the top 50 warehouse lines.

Required for Initial Implementation

 No. Please ignore

In-House Branding

The in-house branding flag will allow retailers to identify in-branded items such as IGA Brand, Black and
Gold, No Frills lines etc.

 ability to print labels/talkers by brand – IGA, B/Gold, Control Brands (such as Crystal Peak Water)
 Reporting
 Ranging opportunities

Required for Initial Implementation

 Print talkers and shelf labels by brand – e.g. IGA, B&G

Recommended but not essential for Initial Implementation

 Report stock, sales, purchases etc by brand – e.g. IGA, B&G

 Report on range stocked vs not stocked and available from warehouse by in house brand

Page: 24
Example of the In-House branding XML output:

Please note:

At this time, whilst all “Control Brands” should have an SRP Compliance indicator of “4”, the In-House
Brand Identifier is likely to reflect the “brand” of the product. So in the case of Crystal Peak Water, expect
to see “Crystal Peak” as the In-House Brand identifier rather than “Control Brand”. Similarly, you could
expect to see “Allure” for Allure toilet paper.

Below is an extract from a communication to retailers explaining control brands and how they are to be
ticketed.

Page: 25
Australian Made

The Australian Made Flag is intended to be used on a “Shelf Ticket or Talker”. At this time, legislation has
changed which means we are not in a position to advise final usage of this field and the original intent of
this field is unlikely to meet legislative requirements.

Required for Initial Implementation

 No. Please ignore

Country of Origin

Country of origin is similar to the Australian Made flag in its designated use, except the host file will be a
string with text stating the country of origin.

Required for Initial Implementation

 No. Unlikely to be required in Liquor business.

Availability

The use of the availability flag is to show whether an item is orderable or not. It is therefore expected that
the BOS can prevent ordering of a “not available” line from warehouse.

Required for Initial Implementation

 Prevent ordering of lines not available

 Host report showing products that are changing on/off available
 Show on the product screen whether or not a product is available to be ordered from Metcash

Recommended but not essential for Initial Implementation

 Reporting of not available lines

Page: 26
Ti Hi

The TiHi provides details of the carton size, and pallet configuration of each item. The pallet and layer
configuration will be based on the purchase node. This information could be useful to improve purchasing
decisions related to freight and storage expenses/capacity. Some examples of its use could be:

 To determine ‘pallet buys’

 Estimate pallets ordered and allow the retailer to order more or less pending the quantities
ordered (To fill a container, or body truck for example) thereby saving of freight costs
 There may come a time where pallet buys are cheaper than carton buys. If so, then the retailer may
want to order by the pallet.
 To save costs for retailer and warehouse, allow rounding up to the nearest layer or pallet

Required for Initial Implementation

 Show the TiHi details on the product information screen, and in ordering modules

Recommended but not essential for Initial Implementation

 When placing a manual or Computer Aided order, the system should show a “Suggested” number
of pallets the order will require. While not entirely accurate, an estimation could give retailers a
very good idea of what to expect, and therefore make changes to their ordering if needed. Some
considerations for a retailer are, price per pallet in freight, container space, storage space in the
store.
 Round up to the nearest layer or pallet would be beneficial, but should be allowed to be
overwritten by the retailer. E.g. if a retailer ordered 44 cartons of coke, and the pallet qty is 48,
then the system should highlight this fact by suggesting an order of 48 cartons, but should allow
the retailer to revert to the original quantity ordered, or order a new quantity if required. Equally, if
a an order has 11 cartons of coke, then suggesting the store order 12 would make sense as a full
layer provides for a very good, stable base from which to build the remaining pallet of stock.

Page: 27
Fees

IGA>D

The current scenario is that all fees are included in the Total Cost. Total Cost of the Item Equates to
Standard Cost + Fees + Taxes + GST.

The Landed Unit Cost (LUCCOST) would be the Total Cost multiplied by the Retail Multiple and divide by the
Carton Multiple.

The Landed Unit Cost Ex GST (LUCCSTEX) would be the Standard Cost multiplied by the Retail Multiple and
divide by the Carton Multiple.

For IGA supplied items, the LUCCOST should be the same as the Total Cost as all fees in IGA are currently
rolled up in to the Total Cost.

CSD

In C-Store, stores currently pay an additional fee when ordering in split cartons (that is in singles). This is
not supported in the V5 host. It will be Metcash’s intention to provide these fees in the CSD host. Further
advice and information on this will be provided in the future.

ALM

The total cost for ALM items includes GST and Wet tax, but does not include any fees like Admin or Finance.

Admin, Delivery and Finance fees are included in both the Landed Unit Cost Inc and Exc GST fields. Pick and
Pack fees would also be included if applied, but at this time, the business does not intend to apply Pick and
Pack fees to items.

This would mean that the fields that itemise Admin, Finance and Delivery fees are not required to
determine the full cost of an item. The LUCCOST and LUCCSTEX provide this detail by unit.

Page: 28
Child Code (Product Linking)

Background Information

The parent/child linking node will show relationships between the carton or multipack, and the single
where they are part of a retail selling unit hierarchy. Key points:
 Parent /child supported eg Tobacco, Liquor
 Parent /multiple child supported eg DVD’s
 Multiple parent/child NOT supported eg Coke 24pk, 6pk, 4pk and single can

The Child description will be based on main product description (unless child GTIN description is populated
/ **Description + UOM = Complete description**)

Example Parent > Child (Host Supported)

Parent item 450394 Peter Jackson Original Blue 180X30

Child item 318055 Peter Jackson Original Blue 30S

Example Parent > Multiple Child (Host Supported)

Example of items but the child has different descriptions (per GTIN):

295260 DVD COLLECTION KIDZ VIDZ $5.95 (pack 100) 9345879000050

Example Multiple Parent > Multiple Child (Retailer Managed)

Example items:

681220 Coca Cola 24X375ML (Pack 1) 9300675000628,

24509 Coca Cola 6X375ML (Pack 4) 9300675001434,
12007 Coca Cola 375ML (Pack 24) 9300675001410

Please Note the following:

 The Liquor host treats the single item as the parent as opposed to the Grocery host which in
relation to Tobacco items treats the carton as the parent.
 The child code does not have a “warehousedirect” indicator. Please treat child codes as non-
orderable.
 When receiving a “Delete” for a Parent Item code, the assumption is that the Child Item code is also
to be deleted. In the Metcash V7 host file, a Delete will only be supplied on the Parent Item Code.

The V7 host file provides 3 fields to be used in product management functions. They are:
 Order Multiple
 Minimum Order Quantity
 Sell Multiple

Page: 29
If the Minimum Order Quantity (MOQ) and the Order multiple (OM) are the same, then the order quantity
should be in cartons (See V5 Order Specification).

If the MOQ is less than the OM, and the intent is to order less than the OM, then the order quantity can be
in units as per the V5 Order Specification.

The Sell Multiple (SM) can be used to adjust the carton and order multiples on Parent and Child items
where the Parent is not represented as a multiple of the lowest retail unit (e.g. Tobacco).

Example Tobacco Parent/Child Relationship

Tobacco products are hosted with the “Carton” as the parent as per the example below.

Page: 30
Page: 31
Example ALM Parent/Child Relationship

Liquor Parent/Child relationships are hosted with the “single” item number as the Parent.

Page: 32
Page: 33
Required for Initial Implementation

 Link products based on the host file linking for selling and stock control purposes
 Computer Aided ordering routines will need to work with this change
 SOH would need to show the rolled up value in units (however, it may be beneficial to also show
the SOH in its variants sizes. (e.g. 60 units, 10 x 6 packs, or 2.5 x 24 packs)

Recommended but not essential for Initial Implementation

 Report on products linked

 Report sales for the linked items individually (e.g. if Carlton Cold was sold in singles, 6 packs and 24
pack slab and were linked, then a report which showed how many singles, 6 packs and 24 packs
were sold with their individual GP and selling details reported)

Cigarettes Per Sleeve

This field defines the number of Cigarettes per Sleeve of the purchase unit. It can be used to assist
with calculating a cost or sell per cigarette, and the production of reports for calculating rebates
based on the “stick” value.

Required for Initial Implementation

 Not required for initial implementation

Recommended but not essential for Initial Implementation

 Reporting to determine rebates on the stick value

SRP Compliance - Diamond

There are three reference baskets for both Price Match & Black & Gold, retailers can opt in for, Small, Mid
and Full. The SRP indicator is set by item number.

Use of the SRP Compliance Indicator in host will help identify items in Price Match & Black & Gold PRR, this
will help with shelf tickets/talkers, reporting and pricing compliance. The current SRP indicator flags are as
per below:

SRP IND Description

1 Core Range - Price Match Proprietary
2 Mid Range - Price Match Proprietary
3 Full Range - Price Match Proprietary
4 Control Brands
5 Black & Gold (Price Match & PRR)
6 IGA Signature (IGA stores only), no talker required
7 Black & Gold PRR only
8 IBA Key Retail
9 Everyday Discount (EDD)

Page: 34
SRP Ticketing Talker Guide:

Items that attract an SRP Compliance Indicator, the sell price must not be any higher than the hosted
recommended retail, price over-rides (for sell prices higher than hosted recommended retail) and margin
locks must be turned off.

The only exception to the rule is for Soft Drinks that attract a cold sell price (the ambient sell price must
comply with the above rules).

Please Note: Advice on the use of CRIN 8 is not yet available. However, it is envisaged that use of this value
will incorporate selling at or below the hosted retail, and that the items will be displayed on a unique talker
style similar to that described above, bit Liquor focused.

Required for Initial Implementation

 Current functionality as per the CRIN development such as:

o create ticket/talker runs based on the SRP Indicator, both on an ad-hoc basis and via
normal host changes
 Reporting on changes to cost/sell, and on/off compliance from host
 Sales, GP and stock control reports limited to SRP items, and by SRP flag
 Prevent sell going above the RRP on SRP compliant items (Excluding cold soft drinks)

Recommended but not essential for Initial Implementation

 Optional - Ability to prevent lead in/out promos on SRP compliance items

 Reporting on sales of SRP compliant items

Example XML showing the compliance indicator

Page: 35
GTIN PLU

GTINPLU field allows for an item to be identified as conforming to the Global Trade Item Numbers, or
whether it conforms to a PLU, whether it be 4 or 5 digits in length and typically used in fresh areas to
produce labels, or at the front end for easy lookup of fresh items.

Key points of the GTINPLU host information is that it allows:

 Multiple GTIN’s may be hosted

 Able to host GTIN, PLU or TUN code (Identified via the Type field)
 Identification as to whether the item is pre-packed or not (pre packed meaning the item is sold as
an each rather than a weighed item)
 4 and 5 digit PLU’s, 8/13/14

Required for Initial Implementation

 Accept additional GTINs on products via the host mechanism

 Treat PLUs and GTINs appropriately during host processing
 Ensure PLUs are used in accordance with the field specifications (e.g. pre-packed items typically are
weighed/wrapped using a fresh area scale and a label attached to the product, with a price
embedded barcode. This is then scanned at POS.)
 Ensure during conversion that hosted PLU’s do not overwrite existing PLU’s currently in use in store
systems.

An example of the full GTINPLU Node as it would appear in XML V7 host can be seen below.

Page: 36
An example of the moving of a GTIN from one Product to another in the same host:

Page: 37
Promotions (Critical for V7 Implementation)

Promotions in V7 will be hosted with a Promotion ID and will include amongst other items, a zone number.

This is a critical development item for Metcash and must be completed for your first phase
of the V7 implementation.
It will be expected that after a promotion is initially hosted (usually promotions are hosted 2-3 weeks in
advance of the instore start date) and an error is detected and corrected by the Metcash Promotions
department, the corrected promotion will rehost in the next weekly host (or daily host) that will alter any
promotional parameters (Dates, prom type, zone, group, comment, promotion placement, week number
cost & sell) with the “PromotionID” being the primary key.

PromotionID’s are unique across the Metcash business, meaning that ALM, IGA, CSD etc cannot use the
same PromotionID.

If a particular promotion overlaps with another promotion at the item level, Metcash’s intention is that
“best of pricing” is used, the lowest cost should be applied as the retailer will be invoiced at the lowest cost
price of that item.

PromotionID’s are used once only, however you may find the same PromotionID on multiple products from
the same Supplier. You may also find the same Promotion ID across different “ZoneNumbers” which has
implications for Multi Store Systems. The promotions will have the same in-store sell period. This means
that promotions are not necessarily unique to a product or group of products. However, together the item
code and promotionID (and where applicable the Zone Number) are unique. Please see the diagram on the
following page for more information.

Page: 38
 Note: In the multi-store case, the same PromotionID can have different retail prices in
different retail zones. You can use the “ZoneNumber” field to differentiate the effective retail
pricing in different stores (in different zones) for the same PromotionID.

Note however, that if a PromotionID is deleted, the promotion will be deleted for all zones.

NB: The suggestion of a HOSPromotionID (above example) is not mandatory. It is defined here to illustrate
how zones and promotion IDs can be used in a HOS environment.

Page: 39
Promotion Moved

If the Mount Franklins promotion was incorrectly hosted out and the promotion moved to a different
buy/sell period, Metcash will host out a promotional delete for 00083100, create a new promotion with a
new PromotionID. The Coca Cola promotion remains as is.

Promotion Attribute Change

If the Mount Franklins promotion PromType changed from SL to AD (other attribute may change such as
cost, sell, promotion placement and template ID), then Metcash will host out a promotional update for
00083100 with all the relevant attributes including the ones that have changed. The Coca Cola promotion
remains as is (no changes hosted out).

Promotion Deleted

If the Mount Franklins promotion is to be removed, Metcash will host out a promotional delete for
00083100. The Coca Cola promotion remains as is.

In addition, when a delete record is received for a Promotion ID, all zones are affected. That means, when a
PromoID is deleted, the Zone Number is not supplied in the host and therefore the assumption to be
applied is that all zones are to be deleted for a PromoID.

Please ensure that the above scenario is catered for in your handling of promotion ID’s.

Metro and Regional stores may have different promotional pricing for the same item, “ZoneNumber”
indicates which pricing zone the promotion is based on, this is particularly useful for Multi Store Owner.

Page: 40
Please Note:

There may be occasions when a Promotion is hosted where the expected “Action” would be “I”, but in
reality, the host file will contain a “U”. An example of why this occurs is as follows:

1. A product family is put on promotion by sub-range

2. One variety changes pack-size before the promotion is first hosted and has to be updated in the
promotion
3. When translated, the “Action” is sometimes “U” (reflecting it was updated) and not “I” (reflecting
this is an insert from the store perspective).

It is expected that in these situations, the “Update” is applied as an “Insert”. Sample XML is provided
below:

Page: 41
Template ID is an addition to the promotion node. Its aim is to provide guidance as to what talker style
should be used. This may be used to pass onto 3rd party ticketing programs to identify the type of ticket to
be used. For example, should Metcash wish a promotion to be ticketed with a 50% Off talker, then the
Template ID would be used in this instance to determine the ticket style.

No guidance has been given at this time on what form the Template ID’s might take, but on the following
page we provide an example of what they might look like (this is not guaranteed).

Possible Template ID

Template Description
ID
MB Multibuys
1F Buy One Get one Free (BOGOF)
P1 10% Off
P2 15% Off
P3 20% Off
P4 25% Off
CB Combo Buy
SP Special
CS Community Chest Special
CC Community Chest
MS Managers Special
CL Clearance
FS Fresh Food Special
FG Fresh Food Guarantee
VA Value
LD Lock Down Low Prices
SB Save Blue
SG Save Green
SO Save Orange
SR Save Red
SY Save Yellow
NL New Lines
PM Price Match
BG Black & Gold
A9 AD Special 50% off
A8 AD Special 45% off
A7 AD Special 40% off
A6 AD Special 35% off
A5 AD Special 30% Off
A4 AD Special 25% Off
A3 AD Special 20% Off
A2 AD Special 15% Off
A1 AD Special 10% Off

Required for Initial Implementation

 Be able to add, delete or adjust a promotion from the host based on the use of the promotion ID

Page: 42
  Ensure that the possibility of different products using the same PromotionID is accounted for.
Promotions are part of the “Product Node”. Together the Item # and the PromotionID are unique.
 Allow users to deactivate a hosted promotion, but not make any other adjustments to the hosted
promotion. (If the user needs to make an adjustment, it is recommended they create a new
promotion with the corrected details, rather than adjust the hosted promotion)

Recommended but not essential for Initial Implementation

 Report on promos by Promotion ID and date on/off with cost and sell detail
 Allow printing based on Template ID’s
 Allows 3rd party ticketing programs to access the Template ID for ticketing purposes

Promotion Placement

This field shows how the promotion type has been promoted. Retailers can then know whether an item is
in the brochure, on TV, or simply an in store promotion. This has ramifications for how a retailer ties up
with particular promotions.

 Brochure identification
 Reporting on Non Adv v’s Adv
 Ordering

Required for Initial Implementation

 Display the type of promotion placement on the product details screen

Recommended but not essential for Initial Implementation

 Allow reporting of products by promotion placement

 Allow users to manage promotions by product placement group
 Allow users to order stock by product placement group

Page: 43
Retail Offers (Not populated on initial go live)

Retail Offers is to be incorporated in the standard V7 host file, removing the need for a separate file. On
conversion, retail offers will NOT be part of the V7 host and will continue to be hosted in the current V5
format.

Metcash will advise future course of Retail Offers host when confirmed.

Required for Initial Implementation

 Not required to be extracted from the V7 host

 Will continue to be supplied via the current spec in a separate file until further notice
 Retail Offers V5 to use the current Web Services as opposed to the new Retail Web Services V7

Recommended but not essential for Initial Implementation

Page: 44
Metcash PDE Software

To accommodate 8 digit item code, the Metcash PDE software has a configuration which will allow it to
scan both 6 and 8 digit item codes and send this to the BOS in the form of an 8 digit item code. It works by
prefixing 2 leading zeros to the 6 digits item codes.

The current export from PDE, and subsequent import from the BOS is likely to target a 6 digit item code
followed by the quantity. It might look something like the following:

H0123450+F01+F139859+F0000000+F0000000000000000+0252041+4044081+6246681+61020312+01301
11+3968911+3527039+0130111+6974256+……+

After setting the configuration to export 8 digit item code, when transmitting a file from the PDE to the
BOS, all item codes will be exported in the file as an 8 digit item only (plus the quantity) similar to the
following:

H0123450+F01+F139859+F0000000+F0000000000000000+000252041+004044081+006246681+33610203
12+220130111+003968911+003527039+000130111+276974256+……+

In this example, item code 33610203 has a quantity of 12, whilst item code 00404408 has a quantity of 1.

The following two tables may show this more clearly:

Please see appendix B that contains some randomly generated 8 digit barcodes that can be used for testing
purposes. (The PDA file specification is available upon request)

Page: 45
Appendix A

An extract of supplier numbers across the states. While the last five digits of the supplier code remain the same in each state, a different prefix for each state is
applied to create the 8 digit Supplier Code.

Page: 46
Appendix B

Sample 8 digit barcodes for test purposes.

Page: 47
Appendix C

The following table provides guidance as to how the information supplied within certain fields is derived,
whether it be National, State, or DC specific.

Field Field Governance

ProductGrade State
ProductType National
ProductGroup State
InhouseBrand National
SlowMoving State
GeneralMerchandise State
AustralianMadeFlag National
CountryOfOrigin State
Available Supplied DC Location
Comment State
GTINPLU.PrePacked State
GTINPLU.Weighed National
GTINPLU.AlternateDescription National
UnitPricing.Exempt National
TiHi State

Page: 48
Appendix D

HOS Considerations For Promotional Hosts

Promotions can be hosted by two different types of groups;

 Customer Groups
 Promotion Groups

Most promotions are set by “customer groups”, the Metcash promotion teams usually copy promotions
over several customer groups. Customer groups are defined by banners, IGA, SUPA IGA, Foodland & IGA
Xpress are all separate customer groups, an MSO may operate with multiple Customer/banner groups.
Promotions can have the same PromotionID within the same state but have different pricing parameters
(based on price zones which is also hosted).
Promotions can be setup by “promotion groups”, these promotion group can be configured to specific
customer accounts, for example “Tobacco”, and most states have three tobacco group for promotions.
The diagram above shows for an MSO, potential complexities for a HOS environment.

Page: 49
Frequently Asked Questions

Q. How will orders be affected?

A. The current V5 order specification caters for 8 digit customer number and 8 digit item codes. IT will be a
requirement to send the 8 digit customer number and 8 digit item codes in the V5 order file when sending
orders.

Q. How should we handle converting directs from MLC to MSC in conversion from V5
host to V7 Host?

A. Ideally, the vendor would convert instore direct products loaded against an MLC to a logical, or retailer
determined MSC Cat/Com/SubCom. For example:

In the MSC structure, Soft Drinks may be broken up into the following (not indicative of the final MSC structure):

Currently, Soft Drinks and Home Brews are hosted in the following MLC commodities:

Any instore directs that are linked to these MLC’s could be automatically converted to a “Sundry” Sub
Commodity as part of the conversion. Any directs loaded to Commodity 201, Soft Drinks Bottled, could go
to the MSC Sub Commodity of 06 Soft Drinks, 071, Soft Drinks, 01 Soft Drinks, 98 Sundry Bottled Soft
Drinks.

Page: 50
Be aware that some MSC’s are part of a broader MLC structure. The MSC Commodity “New Age” for
example, will have products linked to Commodity 206, Energy Drinks. So providing a mapping of 206 Energy
Drinks to an MSC will also move any direct Coconut Waters to the same MSC which will be incorrect.

We feel there are 3 options which could be employed. They are:

1) Link all directs within an MLC to a Sundry MSC Category. Allow the retailer, through a GUI interface,
to map individual direct products to the correct MSC at a later date post conversion.
2) Link all directs within an MLC to a Sundry MSC Sub Commodity. Allow the retailer, through a GUI
interface, to map individual direct products to the correct MSC at a later date post conversion. This
would see most products mapped correctly at lower levels, but will leave some products in
incorrect sub-commodities.
3) Map all directs to an Unknown Dept. Allow the retailer, through a GUI interface, to map individual
direct products to the correct MSC at a later date post conversion.

Recommended Approach

We recommend using option 1 during the conversion/implementation of V7 phase. We will aim to provide
a reference

We also recommend that a GUI interface be made available to easily map items and/or whole MLC
commodities to a MSC Cat, Commodity or Sub Commodity.

Q. A store I am about to convert uses 7 digit item numbers for directs products. How
should I handle these to prevent clashing with Metcash 7 digit item codes?

A. The recommendation is to make directs alpha numeric. For example, add a “D” to the beginning of the
item code to ensure it will not clash with Metcash Item numbers. You will however, need to consider the
impacts of this on the store such as ticketing. Please ensure any decisions regarding this are clearly advised
to retailers prior to conversion. It is also recommended your intentions here are also communicated to
Metcash Retail Technology.

Q. Admin and Finance fees for ALM customers will not be hosted immediately upon
conversion to V7 host. When will Metcash, via V7, host the admin and finance fees
for Liquor?

A. Once V7 rollout is completed, retailers will be given the option to have admin fee and finance fee
included in their host file. This will be communicated by ALM.

Q. Will the current format of V5 Retail Offers be hosting an 8 digit item code?

A. No. Vendors will be required to accept the current 6 digit item codes and convert them if necessary to 8
digit in order to process the V5 Retail Offers Host file.

Q. When will V5 Retail Offers host cease and h ow will I know what font style and
size to use to create a retail offers promotional ticket under V7 host?

A. V5 Retail Offers host will cease once all IGA’s are converted to V7 host format. Prior to this date, advice
will be given to vendors on the likely cessation date, and what style and size of font should be used to
create Offer Tickets.

Page: 51
Q. How should a PDA be treating 6 digit item code barcodes on tickets?

A. It is expected that vendor PDA software will accept a 6 digit item code and convert to 8 digit when
communicating with the BOS. The Metcash software on PDA’s converts existing 6 digit item codes to 8 digit
for upload to the BOS.

Q. Are vendors expected to support the Metcash PDA software?

A. Yes. We expect all accredited vendors to be able to import files and communicate with PDA’s using the
Metcash Software.

Q. After conversion to V7 host, what other systems or interfaces if any will also have
changes applied?

 The E-invoice file will be in V7 E-Invoice format, primarily to support 8 digit item code, but will also
provide other information
 Web Service will change post implementation. All host files will be provided via this web service.
 Orders will need to include the 8 digit Customer number and 8 digit item codes

Q. What are the business rules regarding the use of the “N” flag for new lines?

At this time, use of the N flag is not clearly defined. Relying on this flag to determine the validity of New
Lines is not recommended at this time.

Ideally, new lines will be hosted with an N initially. After a period of time (e.g. 3 months) the product is re-
hosted with an alternative flag such as “B” to signify the item is no longer classified as a new line. However,
these rules are not yet determined.

Q. Will there be the ability in V7 for a host to edit, append, delete data from an
already accepted and retailer edited promotion ?

Ideally yes. However, the expectation would be to allow the retailer to activate or deactivate the promo,
and be able to set their own promo for the product at a higher or lower price point, and have that one take
effect if they desire, even though it is not recommended they do so.

Q. Will there be a requirement to provide reporting based on the 4 level MSC

structure?

A. Ideally yes. Benchmarking and comparisons to Scan Data are two key areas where the MSC structure will
be used. It will also be used to provide better ranging, making analysis of Sub-Commodities far easier than
the current Commodities structure in place today.

Q. I don’t want to use the MSC Department tier. What are the possible impacts?

A. Keep in mind that the MSC forms the basis of Metcash thinking and planning going forward. It is highly
likely, the MSC Dept, Cat, Com and Sub Com will be used in future Retail Offers host capability. This means
that if any of these levels are not imported via the host, then the ability to process and activate retail offers
using this indicator would be negatively impacted. It is therefore recommended that the MSC is
implemented at go live.

Page: 52
Q. How long in advance will the effective date on standard cost or sell changes be
hosted?

A. At present Metcash may host up to one week in advance.

Q. The Metcash V7 Host Specification suggests that you can have more than one
PurchaseUnit with differing Order Multiples. Is this possible in the Metcash
environment?

A. In practice, it is only possible for Metcash to host one Purchase Node for an item. This means that if
there is a change to the way an item can be purchased from Metcash, the host file will provide for an
“Update” record instead of a “Delete” and “Insert” record when the Order Multiple changes.

Q. What should I do if I receive a Delete for a Parent Item Code, but no Delete for the
associated Child Code?

When receiving a “Delete” for a Parent Item code, the assumption is that the Child Item code is also to be
deleted. In the Metcash V7 host file, a Delete will only be supplied on the Parent Item Code.

Page: 53
Key Metcash Contacts

Grocery and Liquor

Head of Retail Technology: Pat Smith

pat.smith@metcash.com
0438 601 990

National Services and Vendor Manager, Retail Technology: Colin Higgins

colin.higgins@metcash.com
0412 15 26 25

Product Owner, Retail Technology: Brendan McKeown

brendan.mckeown@metcash.com
0411 757 527

Systems Analyst, Retail Technology: Kartheek Akula

Kartheek.akula@metcash.com
0436 407 161

Retail Technology National Support Manager: Jacki Wuersching 0409 574 477 jacki.wuersching@metcash.com
ph: 1300 138 220
email: retailtech@metcash.com
Service Manager NSW/ACT, Retail Technology Joseph Sue 0407 433 283 Joseph.Sue@metcash.com
ph: 02 8822 3642
email:nretsys@metcash.com

Service Manager VIC/TAS, Retail Technology Rita Hansen 0419 341 257 Rita.Hansen@metcash.com
ph: 03 8368 6178
email:vretsys@metcash.com

Service Manager SA/NT, Retail Technology Kellie Splett 0418 654 608 Kellie.Splett@metcash.com
ph: 08 8152 8651
email:sretsys@metcash.com

Service Manager WA, Retail Technology Nicole Hogan 0409 367 235 Nicole.Hogan@metcash.com
ph: 08 9311 6140
email:wretsys@metcash.com

Page: 54