EDI EANCOM New Code Work Request

CHANGE REQUEST TO THE EANCOM® STANDARD

New Code Request NECORE

Front Sheet

Submitter information (*): Name (*): Organization: Phone + country code (5): E-mail address (*): User’s reference number

GSMP number (*) GSMP number reference (*):

Version Nr 2012-03-21 1 New Code Request

UN LOG: UN DATE : Development Group (*): EP LOG : EP DATE: User ref (*): GS1 User date (*):

Originator (*): Company (*): Address: Email (*): Phone (*) + country code:

Message (*): Based on Directory D.01B (Batch) (*): Target Directory (Batch) (*): Attached documentation: Business need/justification (*): Related change request(s):

Action (*): Code name (*): Code tag (*): Code definition (*): Code note: Based on data element (*): Based on composite (*): Based on segment (*): Code category (*):

Example code required in notes: (yes) : (No) Internal use only

EANCOM segment Version Nr 2012-03-21 2 number(s) (*):

(*) Mandatory fields

Attached documentation:

Comments boxes

Initial assessment Date - Initials expert(s)

Date - Initials technology owner

Technical development Date - Initials expert (s)

Standards Maintenance Group (SMG) assessment Date - Initials expert (s)

UN/EDIFACT data maintenance request Date - Initials expert (s)

Version Nr 2012-03-21 3 Guidance on filling in the fields

1. Front sheet

1. Fields to be filled in by the submitter. See detailed guidance.

2. Detailed guidance

Submitter information Submitter (*): Name (*): Organization: Phone + country code (5): E-mail address (*): User’s reference number

GSMP number reference: Technology owner The GSMP number of the change request. (E.g. 12-000012) GSMP number reference Technology owner (*): The GSMP number of the change request, this request is mending. (E.g. 12-000067)

2. New Code Request form

1. Fields to be filled in on an original change request by the submitter, technology owner and UN/EDIFACT liaison. See detailed guidance.

In the course of the process the technology owner may change, in consultation with the submitter, the content of the fields as originally filled out by the submitter. The same applies to the attached documentation.

Sections 1 up to 4 and 6 constitute the UN/EDIFACT Data Maintenance Request (DMR).

2. Detailed guidance.

Section 1 Development Group (*) UN/EDIFACT liaison The UN/EDIFACT group responsible for the maintenance of the message.

User ref (*) Technology owner The GSMP change request number.

Version Nr 2012-03-21 4 User date (*) Submitter Date of preparation. (E.g. 23/05/2002)

Section 3 Message (*): Submitter A/the message(s) in which the request for change is to be used. (E.g. ORDERS - Purchase order message) Target Directory (Batch) (*): UN/EDIFACT liaison If the new code is not available in the most current UN/EDIFACT directory, the target directory is the directory in which the UN/EDIFACT liaison wants the requested new code to be implemented. (E.g. D.03A) Attached documentation: Submitter If there is any attached documentation, such as a business model or updated segment, it should be indicated here. Business need/justification (*): Submitter A comprehensive description of the reason(s) why the new code is needed. The business function, operation or problem that will be satisfied is discussed. Related change request(s): Submitter The reference number(s) of a/the related change request(s), if any. Section 4 Action (*): Submitter Allowed actions: - Add an existing UN/EDIFACT D.01B code to EANCOM®, - Add a new GS1 code to EANCOM®. (E.g. Add a new GS1 code to EANCOM® ) Code name (*): Submitter The name of the code. (E.g. Recommended maintenance quantity) Code tag (*): Submitter The UN/EDIFACT code tag if the requested code already exists in a UN/EDIFACT directory. Technology owner If no UN/EDIFACT code exists, a temporary EAN code tag will be assigned. (E.g. E16) Code definition (*): Submitter The definition of the code. (e.g. Recommended quantity of an article which is required to meet an agreed level of maintenance.) Code note: Submitter The note to be added to the code, if any. (E.g. The field of implementation of this code is the area of transport and/or customs.) Based on data element (*): Submitter The tag and name of the data element to which the code list, containing the code, belongs. (E.g. 6063 - Quantity type code qualifier) If the data element has a restricted code list it is Version Nr 2012-03-21 5 recommended to explicitly state that condition and, add in section 6 the updated segment with the added code shown in italics. See also “Segment change request”. (E.g. 6063 / Restricted code list - Quantity type code qualifier) Based on composite (*): Submitter The tag and name of the composite data element, if any, containing the data element. (E.g. C819 - Address usage) Based on segment (*): Submitter The tag and name of the segment containing the data element. (E.g. NAD - Name and Address) Code category (*): UN/EDIFACT liaison Indication of the category into which the new code fits. 1 – Codes related to service data elements 2 – Codes in the public domain, maintained by UN/EDIFACT 3 – International code lists endorsed by UN/ECE 4 – Other code lists maintained by officially recognized organizations e.g. GS1 (E.g. 2) Section 5 EANCOM® segment number(s) (*): Submitter The number(s) of the segment(s) in the EANCOM® message(s) where the code will be used. (E.g. 12, 56) (e.g. ORDERS - 12,56 / ORDCHG - 13,57 / ORDRSP - 13,57) Section 6 Attached documentation Submitter/ Any expert Attached documentation itself. (e.g. , Segment showing the updated data element’s restricted code list)

3. Comments boxes

1. Fields to be filled in by the tasked expert(s)/group and the technology owner. See detailed guidance.

2. Detailed guidance

Initial assessment (*): Tasked expert Disposition and comments, if any. (E.g. Withdrawn by submitter. The existing GS1 code ‘12E’ meets the business needs.) Technology owner Consolidated comments, if any.

Technical development (*) Tasked expert Comments, if any. (E.g. The requested functionality in IFTMIN should also be added to the corresponding multi consignment message IFCSUM.) Version Nr 2012-03-21 6 Technology owner (E.g. A new change request will be submitted against IFCSUM.) Standards Maintenance Group (SMG) SMG manager assessment (*) Disposition and assessment comments, if any. (E.g. Rejected. The business needs conflict with the UN ADR regulations.) Technology owner Consolidated comments, if any. (E.g. The submitter agrees to the BRG comments and will withdraw the change request.) UN/EDIFACT data maintenance UN/EDIFACT liaison request Assessment results. (E.g. Approved with amends.) Technology owner Consolidated comments, if any. (E.g. Textual changes to be ignored.)

Version Nr 2012-03-21 7