Item Relation Message
Version: Proces specification SALES005 v1.0.1
With the item relation message (developed and published in the SALES005) it is possible to indicate relations. Only product – product (PP) and trade item – trade item (AA) relations are made. In one relation message, PP and AA relations might occur simultaneously.
1 Relation types
The code list with the relations types is, just as other SALES Messages, managed externally. All relations are in one direction, this means that ID2 tells one something about ID1. Please consider the examples (table 1).
Table 1 - Available relationtypes
| Relations | Code | Meanting | Direction |
|---|---|---|---|
| Successor, transcends successor from the price catalogue message | OPV | ID1 has as its successor ID2. A successor has 1 to 1 the same technical foundation. The supplier indicates that the predecessor (ID1) is replaced in terms of functionality and technical specifications by the successor (ID2), the (new) product or article. The relationship type OPV is mirrored to that of VOO. | ID1 -> ID2 |
| Predecessor, transcends the predecessor from the price catalogue message | VOO | ID1 has as its predecessor ID2. A predecessor has a 1-to-1 identical technical substantiation. The code for the trade item or product shall be replaced (ID2). The supplier finds that the predecessor (ID2) is replaced by the successor (ID1) in functionality and technical specifications. The relation type VOO is a mirror image of the OPV. | ID1 -> ID2 |
| Alternative | ALT | Relation between two trade items who are not 1-to-1 identical, but can replace one another. | Both |
| Technical fit | TEP | Technical fit, trade items based upon specifications, or that together form a solution. | Both |
| Part of | ONV | ID2 is a part of ID1. Together with one or more items or products, it forms a whole. Note that this relationship type can lead to many relationships. This relationship type is mirrored to BEO. | ID1 -> ID2 |
| Contains part of | BEO | ID2 contains item ID1. The larger whole (ID2) consists of several items or products (ID1). These parts have a relationship to the whole. This relationship type is mirrored to ONV. | ID1 -> ID2 |
| Belongs to | HOB | Commercial advice / series / look and feel / made for each other. This includes the accessories. | Both |
| Cannot do without | KNZ | ID2 forms a (working) whole with article ID1. An article or product (ID2) must be added to ID1. Deepening of the relation type "belongs to", but with a mandatory relation. Can be used with a choice group, see section "choice group". | ID1 -> ID2 |
| Spare | RES | ID2 is a spare part of ID1. Relationship applies to a spare and wear part. | ID1 -> ID2 |
| Morrored | GSP | Mirrored trade items or products. This relation type is most useful when ordering and assembling. | Both |
A relationship that can function in both directions is recorded only once to avoid redundant information. This also applies to mirrored link types. For example, the relationship type TEP is bidirectional. If the wipper technically fits the cover frame, the reverse is 813 true. The relationship then does not need to be established again in the opposite direction.
Table 2 - Example a redundant relationship type
| Supplier X | Supplier X | ||
|---|---|---|---|
| 2.1 | PP | ||
![]() | Technical fit | ![]() | |
| Wipper | Coverframe | ||
![]() | ![]() | ||
2 Group of choice
Obligatory relations might be applied through the relation ‘cannot do without’. Through including a groups choice, a choice might be made when the ‘cannot do without’ relation offers several options to reach the desired result. This allows for a relation to be made to a particular group of trade items or products in a coherent manner.
An example might be a gas stove that needs to be ordered with either a wood or coal insert, for the stove will not function without it.
Table 3 - Group of choice
| Product 1 | Type relation | Product 2 | Group of choice | Quantity |
|---|---|---|---|---|
| Gas stove | Can not without | Insert (wood) | A | 1 |
| Gas stove | Can not without | Insert (coal) | A | 1 |
Or, a computer’s adaptor for which, in different countries, different types of plugs and thus different cables have to be used:
Tabel 4 - Group of choice
| Product 1 | Type relation | Product 2 | Group of choice | Quantity |
|---|---|---|---|---|
| Power Adapter Computer | Can not without | Cable type F (EU) | B | 1 |
| Power Adapter Computer | Can not without | Cable type A (US) | B | 1 |
| Power Adapter Computer | Can not without | Cable type G (UK) | B | 1 |
3 Delivery of relations
The party that forwards the relation message is responsible for the correctness of the made relations, to safeguard its quality. In principle GLN 1 and 2 belong to the same owner. If this not the case, both parties shall have to agree on this. The amount of GLNs present in a message is not technically limited. This is bilaterally agreed upon. The exchanging parties determine how the relation is to be handled.
An example: supplier X’s cover frame (technically) fits on supplier Y’s wipper. Supplier Y’s wipper fits (technically) on supplier Z’s switch. Here, the relation is independent from the suppliers, as the GLN-numbers do not correspond. In this example, supplier X’s cover frame might develop a relation with supplier Z’s switch.
Table 5 - Different suppliers
| Supplier X | Supplier Y | Supplier Z |
|---|---|---|
![]() | ![]() | |
| Coverframe | Wipper | Switch |
If three parties wish to develop relations between a wipper, a switch and a cover frame, this might be done in the following manner. The example presumes there to be a PP relation, which is mostly used by manufacturers. It might be possible to develop an AA relation, however.
Table 6 - Relations between different products of different suppliers
| 6.1 | Supplier X | Supplier Y | |
|---|---|---|---|
| PP | |||
![]() | HOB Belongs to | ![]() | |
| Coverframe | Wipper | ||
| 6.2 | Supplier Y | Supplier Z | |
| PP | |||
![]() | TEP Technical fit | ||
| Wipper | Switch | ||
| 6.3 | Supplier X | Supplier Z | |
| PP | |||
![]() | TEP Technical fit | ||
| Coverframe | Switch |
4 Examples
Table 7 - Example relationtypes
| Relations: | Code: | Examples: | Direction: | ||
|---|---|---|---|---|---|
| Succesor | OPV | ![]() | Boiler A (ID1) OPV Boiler B (ID2) | ![]() | ID1 > ID2 |
| Succesor | OPV | ![]() | Basin X (ID1) OPV Basin Y (ID2) | ID1 > ID2 | |
| Predecessor | VOO | ![]() | Boiler B (ID1) VOO Boiler A (ID2) | ![]() | ID1 > ID2 |
| Predecessor | VOO | Basin Y (ID1) VOO Basin X (ID2) | ![]() | ID1 > ID2 | |
| Alternative | ALT | ![]() | Boiler A (ID1) ALT Boiler C (ID2) | ![]() | Both |
| Alternative | ALT | Basin Y (ID2) ALT Basin Q (ID2) | ![]() | Both | |
| Technical fit | TEP | ![]() | Pipe A (ID1) TEP Coupling A (ID2 ) | ![]() | Both |
| Technical fit | TEP | ![]() | Tap X (ID1) TEP Basin X (ID2) | ![]() | Both |
| Part of | ONV | ![]() | Ketel A (ID1) ONV Circulation pump A (ID2) | ![]() | ID1 > ID2 |
| Part of | ONV | ![]() | Tap X (ID1) ONV Interior X (ID2) | ![]() | ID1 > ID2 |
| Contains part | BEO | ![]() | Circulation pump A (ID1) BEO Ketel A (ID2) | ![]() | ID1 > ID2 |
| Contains part | BEO | ![]() | Interior X (ID1) BEO Tap X (ID2) | ![]() | ID1 > ID2 |
| Belongs to | HOB | Phone A (ID1) HOB Cover A (ID2) | ![]() | Both | |
| Belongs to | HOB | ![]() | Screw A (ID1) HOB Trox bit A (ID2) | ![]() | Both |
| Can not without | KNZ | ![]() | Gas stove A (ID1) KNZ Insert piece A (ID2) | ![]() | Both |
| Can not without | KNZ | ![]() | Adapter P (ID1) KNZ Power cable Q (ID2) | Both | |
| Spare | RES | Smoke alarm A (ID1) RES Battery B (ID2) | ID1 > ID2 | ||
| Spare | RES | ![]() | Christmas light L (ID1) RES Lights K (ID2) | ![]() | ID1 > ID2 |
| Mirrored | GSP | ![]() | Handle A (ID1) GSP Handle B (ID2) | Both |




















