Package unit codes in relation to UN/ECE Rec.20 and EANCOM

Last comment 10/07/2019 09:29 by Ronald
· Mark as unread
Ronald Muller 8 months ago created
ETIM specifies data type `dtPUNIT` as "Package unit codes". The permitted set of codes is based on "UN/ECE Recommendation 20 / Package Units", according to the documentation. This data type is used by element `UDX.EDXF.PACKING_UNIT_CODE`.

BMECat defines a set of 32 package unit codes. Checking these codes against "Package units UN/ECE Recommendation 20 (Annex II & Annex III, Level / Category 3.3)", rec20_Rev10e_2014.xls we observe the following differences

+ CQ is not defined by Rec.20 (however, it is defined by Rec.21)
+ C62, EV, PR and SET are not defined by Rec.20 and Rec.21 (PR is defined in Rec.21, but with a different meaning)

My questions are:

+ Is this observation correct? Or is the code list based on another version or Rec.20?
+ If it is correct, it would be helpful to make a note about these additions in the documentation
+ What is the background of these additions?
+ Why is it based on Rec.20 and not Rec.21 (Rec.20 is officially deprecated for a long time, even the original BMECat 2005 states this in its documentation)
+ Is there a mapping available to/from EANCOM, tag code 7065, "Package type description code" as used by all GS1/SALES (Netherlands) based messages?
Marc Habets 8 months ago created
CQ and EV are still defined in Rec. 20 in the latest revision Rev13e dated 2017, see attached file, however Rec 20 mentions (since a long time already) that these 'have been flagged for deletion', see note 2. That is because they originates from Rec 21 and both recommendations are maintained independently. C62, PR and SET are still in REC 20 and even not flagged for deletion. 

EV was requested by 2BA if I remember correctly, the other units you mention were already present before revision 4.0.2.

We tried to see before if Rec.21 could completely replace Rec. 20 for all order-, quantity- and packing units, but that was not possible, since then units would be missing in Rec. 21. And we have to stay compatible with the basic BMEcat. There is no mapping with EANCOM available.
Ronald Muller 8 months ago created
Hi Marc,

Thanks for your quick and useful reply.

Clear, CQ, EV, C62, PR and SET all found in Rec.20. But not in category 3.3 ("Packing Units"), that was the cause of my confusion. These units have another classification (Sales Unit / Miscellaneous / Normative).

I also checked the original BMECat 2005 documentation (XSD) and they accept the same code set for dtUNIT and dtPUNIT (1095 values!) and above mentioned values are all included.
So, I now understand where it comes from!

>  And we have to stay compatible with the basic BMEcat.
This means all BMECat-ETIM package units must be defined by the basic BMECat 2005? So this is a severe restriction, is not it? EANCOM defines packing codes (used in practice) with no equivalent within UNECE, we cannot handle those units in BMECat?
Marc Habets 8 months ago created
Yes, it is a prerequisite that an ETIM BMEcat file is still valid as a basic BMEcat file. That is the reason why all mandatory fields in the basic BMEcat are part of the ETIM BMEcat and also translates to units. So we limited the units to a subset of what is allowed in basic BMEcat, but all units we use need to be allowed in the basic format. And yes, that is severe, but is needed to maintain compatibility. And with BMEcat's development at a standstill since many years already, that is not easy and for sure we will discuss if compatibility with basic BMEcat is sustainable for the future. But for now it is still a prerequisite. 
Ronald Muller 8 months ago created
Makes sense.

All clear now, thanks again.
Join the conversation
You have to be a registered user to join the conversation.
Topic started 09 July 2019 at 10:55
Reader count 8
Comment count 5