|
CATALOGUE ITEM AUTHORISATION v. 2.1 |
|
|
|
|
|
Problem
Statement |
|
|
In order to realise supply chain
efficiencies and reduce back office inefficiencies (discrepancies) within the
DSD business model, it is necessary to develop a process and transaction(s)
that will facilitate the electronic communication of item authorisation
(including acceptance and rejection) between trading partners. The current
Catalogue Item Notification (CIN) message, as defined in GDSN, facilitates the
process of item synchronisation but the acceptance of the notification message
(Catalogue Item Confirmation – CIC) is not an acceptance to sell an item within
the store. Currently, manual processes link items to stores and distributors
and the CIN message does not facilitate this link.
The GCI DSD defines Item Authorisation as:
The act of
granting permission to sell (or deliver) an item at a specific location or
groups of locations where the authorisation could be triggered by either
trading partner depending on the buying and selling relationship. This process
will facilitate the linkage of who can deliver a product to a store and who
will be paid for the product.
This Item Authorisation process can be used
either in the GDSN or in a Peer to Peer network. The adoption of this Item
Authorisation process is optional. It will identify items the trading partners
desire to conduct commerce at any level in a retailer’s hierarchy (corporate or
store). The “players” that may engage in the Item Authorisation process
may be: suppliers and retailers, brand owners, franchise owners and
distributors, etc.
An example of how the item authorisation
message relates to the item synchronisation message is shown below:
|
|
|
fig from BMS |
|
|
Objective |
|
|
To supply
the detail design of the (specific) business transaction needed to meet the requirements
of the referenced BRAD. This includes
- the
documentation of item authorisation process and choreography
- the
development of all messages required for item authorisation.
|
|
|
Audience |
|
|
All manufacturers, retailers, distributors
and importers of warehouse or direct store delivery (DSD) distributed items
could utilise this Item Authorisation (De-authorisation) Process standard as it
allows trading partners to distinguish the traded items among various distribution
and sales channels (warehouse, 2-tier or 3-tier) with retailers. The process
and the defined messages can be utilised by the identified parties within and
outside the GDSN network.
|
|
|
Business
Context |
|
|
Industry: All
Geopolitical: All
Product: All
Process: Align_GDSN
System
Capabilities: EAN.UCC
Official
Constraints: None |
|
|
|
|
|
Business
Transaction View |
|
|
Use Case Diagram |
|
|
fig. from BMS
|
|
|
|
|
|
Use Case Description |
|
|
|
Use Case ID
|
UC-1
|
|
Use Case Name
|
Item Authorisation
|
|
Use
Case Description
|
The act of granting permission to sell (or deliver) one or many items
at a specific location or groups of locations, where the authorisation could
be triggered by either trading partner depending on the buying and selling
relationship. This process will facilitate the linkage of who can deliver a
product to a store and who will be paid for the product.
This use case supports the following scenarios:
· The distributor of a
product is changing in one to many stores or a new store is opening and an
authorisation of product must occur.
· Trading partner wants to
introduce a new item and phase it in to all locations based on a rollout
schedule. Product may or may not be in all locations at same point in time.
Product is manufactured by one to many suppliers.
· Item is authorised at a
store within a store. Payment for product may originate from different buying
departments within retail hierarchy. A GLN may or may not be assigned to the
“store within a store”.
|
|
Actors (Goal)
|
IA Initiator (a Trading Partner)
IA Recipient (a Trading Partner)
|
|
Performance Goals
|
To grant permission to sell (or deliver) one or many items at a
specific location or groups of locations.
|
|
Preconditions
|
• ITEM = NOT
AUTHORISED or ITEM = DE-AUTHORISED
• GDSN: Item Data
synchronisation and Party Alignment has been performed.
• PEER-TO-PEER:
Upfront master data alignment (Trade Item and Party)) has been performed.
• GDSN: Trading
partner Catalogue Items and GLNs registered; not necessary for
peer-to-peer.
|
|
Post conditions
|
ITEM = REQUESTED FOR AUTHORISATION
|
|
Scenario
|
New Item Introduction
Begins when... the IA Initiator (a Trading Partner)
identifies the trade item it intends to authorise.
Continues with...
|
Step #
|
Actor
|
Activity Step
|
|
1
|
IA Initiator
|
IA
Initiator identifies its own source GLN and that of the intended recipient
GLN or group of GLNs of message.
|
|
2
|
IA Initiator
|
IA
Initiator sends an Item Authorisation message to the IA Recipients.
|
Ends when... the IA
Recipients receive the Item Authorisation message.
|
|
Alternative Scenario
|
Store Openings
Begins when... the IA Initiator (a Trading Partner)
identifies the trade items it intends to authorise.
Continues with...
|
Step #
|
Actor
|
Activity Step
|
|
1
|
IA Initiator
|
IA
Initiator identifies its own source GLN and that of the intended recipient
GLN of message.
|
|
2
|
IA Initiator
|
IA
Initiator sends an Item Authorisation message to the IA Recipient.
|
Ends when... the IA
Recipient receives the Item Authorisation message.
|
|
Related Requirements
|
See related data requirements in associated
BRAD
|
|
Related Rules
|
|
1
|
For peer-to-peer: master
data alignment (Item and Party) must occur before the Item Authorisation
process can be initiated.
|
|
2
|
For GDSN: Item
Synchronisation and Party Alignment must occur before the Item Authorisation
process can be initiated
|
|
3
|
The Item Authorisation
can be initiated by any trading partner (buyer, seller or third party)
involved in the trade of the item.
|
|
4
|
Any non GLN identifiers
for party e.g. Store Number, DUNS or internal identifier need to be
communicated through the Additional Party Identifier (optional).
|
|
5
|
Any non GTIN identifiers
for items e.g. UPC, EAN-8 need to be communicated through the Additional
Item Identifier (optional).
|
|
6
|
There is no cross
validation between the IA message and the item sync message. There is no
impact on the global registry.
|
|
7
|
ADD and CHANGE_BY_REFRESH
are the only Document Commands that are valid for an Item
Authorisation/Deauthorisation.
|
|
8
|
The Item (De-) Authorisation must to be confirmed
with a Catalogue Item Authorisation Response.
|
|
9
|
An item authorization message authorises/de-authorises
all items in the message and all items bellow it in the item hierarchy.
|
|
|
|
|
Business Transaction Activity Diagram |
|
|
fig. from BMS
|
|
|
Use Case Diagram |
|
|
fig. from BMS
|
|
|
Use Case Definition Item
De-authorisation
|
|
|
|
Use Case ID
|
UC-2
|
|
Use Case Name
|
Item De-authorisation
|
|
Use
Case Description
|
The act of removing from a GLN the permission to sell (or deliver) one
or many items at a specific location or groups of locations, where the item
de-authorisation could be triggered by either trading partner depending on
the buying and selling relationship. This process will facilitate the
unlinking of who can deliver a product to a store or who will be paid for the
product.
|
|
Actors (Goal)
|
IDA Initiator (a Trading Partner)
IDA Recipient (an IA Initiator or IA Recipient)
|
|
Performance Goals
|
· A manufacturer or
distributor has items authorised in some or all stores, but wants to
de-authorise the products in some or all stores.
· A retailer de-authorises
a private label item a supplier manufactures and distributes to a retailer on
a store-by-store basis. This can change based on pricing or service levels on
a weekly or monthly basis. Multiple manufacturers may distribute the same Trade
Item within a retailer’s hierarchy.
|
|
Preconditions
|
· Item
Authorisation has occurred, i.e. ITEM = AUTHORISED
|
|
Post conditions
|
ITEM = REQUESTED FOR DE-AUTHORISATION
|
|
Scenario
|
Deauthorisation of Many
Items at One Business Location
Begins when... an IDA Initiator or IDA Recipient identifies
the trade items it intends to de-authorise.
Continues with...
|
Step #
|
Actor
|
Activity Step
|
|
1
|
IDA Initiator or IDA Recipient(IDA
Initiator)
|
IDA
Initiator or IDA Recipient identifies its own source GLN and that of the
intended recipient GLN.
|
|
2
|
IDA Initiator or IDA Recipient(IDA
Initiator)
|
IDA
Initiator or IDA Recipient sends an Item De-authorisation message to the IDA
Recipient.
|
Ends when... the IDA
Recipient receives the Item De-authorisation message.
|
|
Alternative Scenario
|
Deauthorosation of One Item
at Many Business Locations
Begins when... an IDA Initiator or IDA Recipient
identifies the trade item it intends to de-authorise.
Continues with...
|
Step #
|
Actor
|
Activity Step
|
|
1
|
IDA Initiator or IA Recipient(IDA Initiator)
|
IDA
Initiator or IDA Recipient identifies its own source GLN and that of the
intended recipient GLN or group of GLNs of message.
|
|
2
|
IDA Initiator or IA Recipient(IDA
Initiator)
|
IDA
Initiator or IDA Recipient sends an Item De-authorisation message to the
IDA Recipients.
|
Ends when... the IDA
Recipients receive the Item De-authorisation message.
|
|
Related Requirements
|
See related data requirements in associated
BRAD
|
|
Related Rules
|
|
1
|
De-authorisations
are limited to the initiator or recipient of the Item Authorisation
|
|
2
|
Any non GLN identifiers
for party e.g. Store Number, DUNS or internal identifier need to be
communicated through the Additional Party Identifier (optional).
|
|
3
|
Any non GTIN identifiers
for items e.g. UPC, EAN-8 need to be communicated through the Additional
Item Identifier (optional).
|
|
4
|
ADD
and CHANGE_BY_REFRESH are the only Document Commands that are valid for an
Item Authorisation/Deauthorisation.
|
|
5
|
The Item (De-) Authorisation must to be confirmed
with a Catalogue Item Authorisation Response.
|
|
6
|
There is no cross
validation between the IA message and the item sync message. There is no
impact on the global registry.
|
|
7
|
An item authorization message authorises/de-authorises
all items in the message and all items bellow it in the item hierarchy.
|
|
|
|
|
Business Transaction Activity Diagram |
|
|
fig. from BMS
|
|
|
Use Case Scenario – Item (De-)
Authorisation Response
|
|
|
fig. from BMS
|
|
|
Use Case Definition Item (De-) Authorisation Response |
|
|
|
Use Case ID
|
UC-3
|
|
Use Case Name
|
Item (De-) Authorisation Response
|
|
Use
Case Description
|
The act of accepting or rejecting either an item
authorisation or de-authorisation by the message recipient.
|
|
Actors (Goal)
|
IA Recipient (i.e. a Trading Partner)
IDA Recipient (i.e. an IA Initiator or an IA Recipient)
IA Initiator (i.e. a Trading Partner)
IDA Initiator (i.e. an IA Initiator or an IA Recipient)
|
|
Performance Goals
|
To accept or reject Item Authorisation or De-Authorisation.
|
|
Preconditions
|
· Item
Authorisation or Item De-authorisation message has been received, (i.e. ITEM
= REQUESTED FOR AUTHORISATION or ITEM = REQUESTED FOR DE-AUTHORISATION).
· GDSN: Item Data synchronisation and Party
Alignment is required.
· PEER-TO-PEER: Upfront master data alignment (Trade
Item and Party)) is required.
· GDSN: Trading partner Catalogue Items and GLNs
registered; not necessary for peer-to-peer.
|
|
Post conditions
|
For Authorisation: ITEM = AUTHORISED
For De-Authorisation: ITEM = DE-AUTHORISED
|
|
Scenario
|
Begins when... the IA Recipient or IDA Recipient processes
an Item (De-) Authorisation message within their internal systems.
Continues with...
|
Step #
|
Actor
|
Activity Step
|
|
1
|
I(D)A Recipient
|
I(D)A
Recipient identifies its own source GLN and that of the intended recipient
GLN or group of GLNs of message.
|
|
2
|
I(D)A Recipient
|
I(D)A
Recipient accepts or rejects the item authorisation/deauthorisation on the
buyer-seller-(distributor)-item level.
|
|
3
|
I(D)A Recipient
|
I(D)A
Recipient sends an Item (De-) Authorisation Response message to the I(D)A Initiator.
|
Ends when...the I(D)A
Initiator receives the Item (De-) Authorisation Response message.
|
|
Alternative Scenario
|
N/A
|
|
Related Requirements
|
N/A
|
|
Related Rules
|
|
1
|
If the Distributor is not present on the Item
Authorisation Message, it becomes mandatory on the IA Response.
|
|
2
|
Only the statuses of Accepted and Rejected can be
sent in the Catalogue Item Authorisation Response.
|
|
3
|
The Item (De-) Authorisation must to be confirmed
with a Catalogue Item Authorisation Response.
|
|
4
|
Any non GLN identifiers
for party e.g. Store Number, DUNS or internal identifier need to be
communicated through the Additional Party Identifier (optional).
|
|
5
|
Any non GTIN identifiers
for items e.g. UPC, EAN-8 need to be communicated through the Additional
Item Identifier (optional).
|
|
6
|
A recipient must respond to every Item on an Item
Authorisation or Item De-Authorisation..
|
|
7
|
The absence of a response does not mean that the
authorization/de-authorisation has been accepted by the recipient.
|
|
8
|
Response messages must be in the same format as the
originating authorisation or deauthorisation.
|
|
|
|
|
Activity Diagram |
|
|
|
|
|
TOP |
|
|
|
|
|
Code Lists |
|
|
Implementation Considerations |
|
|
Test Data |
|
|
|
|