|
US$1634.00 · In stock
Delivery: <= 5 days. True-PDF full-copy in English will be manually translated and delivered via email.
GB/T 36147.2-2018: Security management systems for the supply chain -- Electronic port clearance (EPC) -- Part 2: Core data elements
Status: Valid
| Standard ID | Contents [version] | USD | STEP2 | [PDF] delivered in | Standard Title (Description) | Status | PDF |
| GB/T 36147.2-2018 | English | 1634 |
Add to Cart
|
5 days [Need to translate]
|
Security management systems for the supply chain -- Electronic port clearance (EPC) -- Part 2: Core data elements
| Valid |
GB/T 36147.2-2018
|
PDF similar to GB/T 36147.2-2018
Basic data | Standard ID | GB/T 36147.2-2018 (GB/T36147.2-2018) | | Description (Translated English) | Security management systems for the supply chain -- Electronic port clearance (EPC) -- Part 2: Core data elements | | Sector / Industry | National Standard (Recommended) | | Classification of Chinese Standard | U07 | | Classification of International Standard | 47.020.99; 35.240.60 | | Word Count Estimation | 86,852 | | Date of Issue | 2018-05-14 | | Date of Implementation | 2018-12-01 | | Regulation (derived from) | National Standards Announcement No. 6 of 2018 | | Issuing agency(ies) | State Administration for Market Regulation, China National Standardization Administration | GB/T 36147.2-2018: Security management systems for the supply chain -- Electronic port clearance (EPC) -- Part 2: Core data elements
---This is a DRAFT version for illustration, not a final translation. Full copy of true-PDF in English version (including equations, symbols, images, flow-chart, tables, and figures etc.) will be manually/carefully translated upon your order.
Security management systems for the supply chain--Electronic port clearance(EPC)--Part 2. Core data elements
ICS 47.020.99; 35.240.60
U07
National Standards of People's Republic of China
Supply Chain Security Management System Electronic Port Clearance (EPC)
Part 2. Core data elements
Clearance(EPC)-Part 2. Coredataelements
(ISO 28005-2.2011, IDT)
Published on.2018-05-14
2018-12-01 implementation
State market supervision and administration
China National Standardization Administration issued
Content
Foreword III
1 Scope 1
1.1 Overview 1
1.2 Application of core data elements 1
1.3 Data element type 1 defined in this section
1.4 Data element representation structure 2
2 Normative references 3
3 Terms and definitions, abbreviations 4
3.1 Terms and Definitions 4
3.2 Abbreviations 5
4 General Provision 5
4.1 Use of XML Namespace 5
4.2 Principle 5 of Creating Tag Names in Message Files
4.3 Structure of data type definition 6
4.4 Principle 6 for defining enumerated types
4.5 Character Set of Data Fields 6
4.6 Unused XML attribute 6
4.7 Empty Label 7
4.8 minOccurs and maxOccurs default value 7
5 Improved XSD data type 7
5.1 Overview 7
5.2 epc.anyURI---Universal URI 7
5.3 epc.Boolean---Boolean variable 7
5.4 epc.date---regular date 7
5.5 epc.dateTime---Time and date with time zone 8
5.6 epc.decimal---carrying system 8
5.7 epc. duration---duration time 8
5.8 epc.int---integer 9
5.9 epc.string---basic string 9
5.10 epc.token---computer-recognizable string 9
6 general data type 9
6.1 Overview 9
6.2 epc. AttachmentType---Reference Additional Document 10
6.3 epc. ContactInfoType---Contact 10
6.4 epc. CommunicationNumberType---communication number information 10
6.5 epc. CountryCodeContentType---Country Code 11
6.6 epc.GenderContentType---Male/Female enumeration type 11
6.7 epc. MeasureType---Physical Measurement 11
6.8 epc. NameType---person name 12
6.9 epc.OrganisationType---Institutional Description 12
6.10 epc. PortType---Port Identification 13
6.11 epc.PositionType---Location 13
6.12 epc.PostalAddressType---zip code 14
6.13 epc. RemarksType---Common Remarks 14
6.14 epc. UNLoCodeContentType---UN positioning code 14
6.15 epc.VersionType---version code 15
7 core data type 15
7.1 Overview 15
7.2 Ship identification and contact data type 15
7.3 Cargo data type 17
7.4 Crew and passenger data 25
7.5 Class and certificate 29
7.6 Security Data Type 32
7.7 Service-Related Data Types 34
7.8 Ship Elements 37
7.9 Ship Operation Data Type 40
7.10 Waste and Environmental Data Types 53
8 Electronic representation of this part 55
8.1 Main XML Schema Files 55
8.2 Code Set Specification Structure 55
Appendix A (informative) Certificate Code 57
Appendix B (informative) Classification Society Code 59
Appendix C (informative) in the ship and onshore job code 60
Appendix D (informative) Garbage Type Code 64
Appendix E (informative) Message Type Code 65
Appendix F (informative) Business Type Code 66
Appendix G (informative) Cargo and packaging code example 67
Appendix H (informative) Common unit code 68
Appendix I (informative) UN hazard class 69
Appendix J (informative) Ship type code 70
Appendix K (informative) UNECE docking purpose code 73
Appendix L (informative) IMOFAL Figure 74
Appendix M (informative) XSD coding overview 77
Reference 79
Foreword
GB/T 36147 "Supply Chain Security Management System Electronic Port Clearance (EPC)" is divided into two parts.
--- Part 1. Message structure;
--- Part 2. Core data elements.
This part is the second part of GB/T 36147.
This part is drafted in accordance with the rules given in GB/T 1.1-2009.
This section uses the translation method equivalent to ISO 28005-2.2011 "Supply Chain Security Management System Electronic Port Clearance (EPC)
Part 2. Core Data Elements.
The documents of our country that have a consistent correspondence with the international documents referenced in this part are as follows.
---GB/T 1836-1997 Container code, identification and marking (idtISO 6346.1995);
---GB/T 2659-2000 World and region name codes (eqvISO 3166-1.1997).
This part is proposed and managed by the National Marine Ship Standardization Technical Committee (SAC/TC12).
This section drafted by. China Shipbuilding Industry Comprehensive Technology and Economic Research Institute.
The main drafters of this section. Sun Yaogang, Li Jun, Zhu Jiashuai.
Supply Chain Security Management System Electronic Port Clearance (EPC)
Part 2. Core data elements
1 Scope
1.1 Overview
This part of GB/T 36147 specifies the general requirements for safety and security information requirements for electronic port clearance, and improved XSD data.
Type, general data type, core data type, electronic representation.
This section applies to the definition and use of core data elements between ships and ports for safety, security and offshore operations. It can also be used for ships.
Information exchange between ships and ship agents, port and ship operators or ship managers.
1.2 Application of core data elements
This section includes definitions of core data elements for Electronic Port Clearance (EPC). These data elements include ship-to-shore and shore pairs as defined below
All requirements of the ship.
a) all FAL Standard Announcements (FAL1~FAL7) as defined in the Convention on International Facilitation of Sea Transport (FAL Convention);
b) ISPS reporting requirements as defined in ISPS and MSC1305;
c) regular ship reporting requirements as defined in IMOA.851 resolution;
d) Ship-generated waste report as defined in MEPC644 (mandatory in the European Union, see EU/2000/59);
e) the necessary report as defined in the IMOA.862 Resolution on the Solid Bulk Cargo Safety Operational Rules (BLU);
f) ETA report to the pilot station as defined in IMOA.960 Resolution.
Appendix L gives a horizontal comparison between the above requirements and the core data elements.
This section does not include matters such as customs clearance for import and export goods or transportation services provided by the owner.
1.3 Data element types defined in this section
The partial metatypes defined and referenced in this section are shown in Figure 1. The gray box is an object that is not defined in this section, but the base of this section is used.
This information and results.
The top gray box represents some of the data types in XML Schema Part 2 (XSD-2). The bottommost gray box represents the inclusion
Use the electronic XML message for the data element defined in this section.
Figure 1 Data elements in this section
All the elements in each group are not included in Fig. 1, except that part of the elements are selected in each group as an example. The definition of the meta from top to bottom is as follows.
---Improve the XSD type. These are the limitations imposed on this element by the basic elements.
---General data types. These data types represent common concepts, such as port representations or certificates, which need to be specified rather than based on
Defined below;
---Core data types. These data types are defined by context rather than common concepts, such as using Hong Kong instead of ordinary ports, or using newspapers
The location is replaced by the general location.
When the message is defined (as shown by the arrow in Figure 1), this section does not prohibit the use of data types other than the EPC core data element. However, this
These data elements should be given a specific meaning in the message format specification.
1.4 Data element representation structure
The structural outline of this section is shown in Figure 2. The upper two rectangular boxes represent the general data types specified in the previous clause, while the bottom rectangle
The columns in the box represent the EPC core data elements.
Figure 2 Schematic diagram of this part
The order of grouping is based on the order in which it appears in a typical FAL form.
a) Ship ID. Ship identity information and contact details;
b) goods. data relating to the type of goods and goods;
c) Crew and passengers. data relating to crew and passengers;
d) class and certificate. class and certificate related data;
e) Security. mainly related to ISPS data;
f) Service related. data relating to the services required by the ship, including message headers and customs clearance requirements and status;
g) Ship elements. static data of the ship;
h) ship operations. data relating to operations or navigation, including physical data of changes, such as draughts that vary with loading;
i) Waste and the environment. Currently, this article includes waste information.
The core meta-grouping is for convenience only and does not affect the structure of the EPC message. In addition, the data elements defined in the XSD file will not
With any formal grouping, all data elements have the same namespace.
2 Normative references
The following documents are indispensable for the application of this document. For dated references, only dated versions apply to this article.
Pieces. For undated references, the latest edition (including all amendments) applies to this document.
ISO 3166-1 National and subordinate area name codes Part 1. Country codes (Codesfortherepresentationof
namesofcountriesandtheirsubdivisions-Part 1.Countrycodes)
ISO 6346 container code, identification and marking (Freightcontainers-Coding, identification and marking)
ISO 9711-1 Information on containers and ship-borne containers Part 1. Box coordinates (Freightcontainers-In-
formationrelatedtocontainersonboardvessels-Part 1.Bayplansystem)
ISO /IEC 10646.2003 Information Technology Generic Coded Character Set (UCS) [Information technology-Universal
Multiple-OctetCodedCharacterSet(UCS)]
IETFRFC3986 Uniform Resource Identifier (URI). Generic Syntax (UniformResourceIdentifier(URI). Generic
Syntax)
International Maritime Dangerous Goods Code (IMDG), IMO]
MEPC.1/Circ.644 Standard format for pre-notification of port receiving facilities waste (Standardformatfortheadvancenotifi-
Cationformforwastedeliveryofportreceptionfacilities)
UNECER21 (UNECERecommendationNo.21) passenger, cargo type and packaging material code (including package name)
Complement code) [Codesforpassengers, typesofcargo, packagesandpackagingmaterials(withcomplementary
Codesforpackagenames)]
UNTDD administrative, commercial and transportation electronic data exchange directory (Unitednationsdirectoriesforelectronicdatainter-
Changeforadministration, commerceandtransport)
3 terms and definitions, abbreviations
3.1 Terms and definitions
The following terms and definitions apply to this document.
3.1.1
Character character
The minimum unit of text specified in ISO /IEC 10646.2003.
Note. Legal characters include. labels, carriage returns, line feeds, and legal characters in the Unicode Standard and ISO /IEC 10646. The version referenced in this section is
Previously released for use; new characters may be added to modified or future versions of the Unicode Standard and ISO /IEC 10646.
3.1.2
Core data element coredataelement
See Chapter 7 definitions in this section.
Note. The core data element represents the content between the XML start and end tags. The tag has the same name as the core data type, except that the tail string is omitted.
"Type".
3.1.3
Core data type coredatatype
The data types specified in Chapter 7 of this section.
Note. The tail string "Type" is included in all core data type names, and the trailing character is canceled when the data type is used as the core data element.
3.1.4
Data type datatype
The core data type (3.1.3) or other data types specified in Chapter 5 or Chapter 6 of this part.
Note. All data types end with "Type".
3.1.5
Electronic port clearance electronicportclearance; EPC
The port authority and the user exchange electronic messages through a single window to achieve customs clearance at the port.
3.1.6
Voyage leg
A non-stop voyage between Hong Kong and Hong Kong.
3.1.7
Oil, bulk, ore (transport) ship OBO; oil-bulk-orecarrier; O/Ocarrier
Designed to be similar to conventional bulk carriers but equipped with piping, pumps and inert gas units to facilitate loading of oil in designated compartments.
3.1.8
Route voyage
The ship sails from the port of origin to the port of destination with or without intermediate stops.
Note 1. The route is determined by the ship operator or the shipowner.
Note 2. See the voyage (3.1.6).
3.1.9
XML schema XMLschema
The structure definition of an XML file, see XML Schema Language (XSD).
Note. The XML schema language itself is a valid XML structure.
3.2 Abbreviations
The following abbreviations apply to this document.
BLU. Bulk carrier loading and unloading 1) (BulkLoading and Unloading)
DG. Dangerous Goods 2) (DangerousGoods)
HS. World Customs Organization's Harmonized System (World Customs Organization's Harmonized System)
FAL. International Maritime Organization Facilitation Committee and Standard Form as defined in the FAL Convention (Facilitation, IMO's
FacilitationCommitteeandstandardformsdefinedintheFALConvention)
IRI. International Resource Identifier [19] (InternationalizedResourceIdentifier)
ISM. International Safety Management 3) (International Safety Management)
ISPS. International Ship and Port Facility Security Code 4) (InternationalShipandPortfacilitySecurity)
RORO. Ro-Ro ship (Rol-on/Rol-off (ship)]
TDED. Trade Data Element Directory [2] (TradeDataElementsDictionary)
URI. Uniform Resource Identifier
URL. Uniform Resource Locator (UniformResourceLocator)
XML. Extensible Markup Language (ExtensibleMarkupLanguage)
XSD. XML Schema Definition Language (XMLSchemaDefinitionLanguage)
1) The BLU rules can be found in the appendix to the IMOA.862 Resolution.
2) Sometimes “hazardous and toxic substances” are used instead of “dangerous goods”.
3) The definition of the ISM Code can be found in Chapter IX of Reference [6].
4) ISPS rules are defined in Ref. [6] Chapter XI-2.
4 General regulations
4.1 Use of the XML namespace
4.1.1 XSD Namespace
All data elements defined in references [16], [17] and used in this section use the same namespace "xs". Therefore, the number
The type name prefix is "xs". The XSD definition file header includes the following features.
\u003cxs.schema..
4.1.2 ISO 28005-1 namespace
The data types defined in this section are defined in the namespace "epc". Therefore, the data type name prefix is "epc.". XSD
The header of the file includes the following features.
\u003cxs.schema..
4.2 Principles for Creating Tag Names in Message Files
The data types defined in this section can be used to create XML messages to facilitate the exchange of information between ships and ports. In the XML file
The information element should have a tag name derived from the core data type defined in this section. The rules are as follows.
a) If the information element in the XML file is related to the core data type defined in this section, the tag name and core of the information element
The data type is the same without the suffix "Type" or "ContentType" of the core data type;
b) If a new information element is created, its name and type shall reflect the principles given in this section.
4.3 Structure of data type definition
4.3.1 Name
All data types defined in this section should have a name that should be included in the front of the header of the definition data type.
The data type name should conform to the XML tag naming convention [15] with the following additional restrictions.
a) Names end with the string "Type".
b) The suffix of the enumerated data type is "ContentType".
Note 1. Some core data elements also end with "Type". In this case, the suffix of the corresponding core data type is "TypeType".
c) This section uses “big camel spelling” in all core data types, for example when the tag name consists of a series of conjunctions.
Each word should begin with an uppercase letter;
d) The name consists of characters in the set (A~Z), (a~z), and (0~9).
Note 2. The content of communication between ships and ports in port customs clearance is easy to understand. The name uses common British English without any special characters.
The name is usually in singular format. When the data element includes a list of items, the label name is in plural format.
4.3.2 Definition
Each data type is defined, and in the definition, the content that the data element should include and the clear table in which the case is valid are given.
Said. This is the first paragraph after the chapter head.
4.3.3 Type
Each data type is defined as a segment of the XSD code. This section covers the actual data type definition but is not a valid XML text.
Pieces. Appendix M gives an overview of the syntax elements used. For the description of the definitions, users of this section should refer to reference [16].
4.3.4 Expression
For the normalization of data fields, see the paragraph. For example, this paragraph will give a normative reference to the official source code of the enumeration.
4.4 Principles for defining enumerated types
An enumerated type, for example, a type associated with a fixed set of code values, is defined in one of three ways.
a) When the code set is small and undefined and maintained by an authority other than this part, the allowable code value is the same as the XSD limit
Listed in the data type definition.
b) If the code set is large and not defined by an external authority, the code set is in the normative appendix. Defined in a single XML file in 8.2
How many code sets can be embedded.
c) When the code set is maintained by an external authority, define the data type as a tag and as a discovery code set and how the code set is
The reference used in the core data element. Some of the most commonly used codes are usually included in the informative appendix. 8.2 can be used to compile XML
The value in .
Note. It is not possible to verify the use of code defined in items b) and c) above using XSD mode.
4.5 Character Sets for Data Fields
This section allows all character sets supported by XML (see 8.1). The expression in the data type definition section may impose additional restrictions.
4.6 Unused XML attributes
The data types defined in this section do not use XML attributes. All information is included in the XML start and cutoff tags.
4.7 empty label
Mandatory labels (unmarked minOccurs=“0”) should normally contain valid data. Optional tags are usually not counted in the message, it may be
Empty, such as no end tag, or the tag content is empty. The recipient of the message should handle all empty tags in the same way.
4.8 minOccurs and maxOccurs default values
According to reference [16], the default value of minOccurs and maxOccurs is 1. In order to define the chapter in the data type in this section
Medium shortened type regulations.
5 Improved XSD data types
5.1 Overview
The definition of the improved XSD data type used in this section can be found in Ref. [17]. 5.2~5.10 contains the use of this part of the application
Additional restrictions on these data types.
5.2 epc. anyURI---generic URI
definition.
This data type includes a valid universal URI. It may be an email address prefixed with "mailto." or an external file with the prefix
"file.".
Types of.
\u003cxs.simpleTypename=\"anyURI\"\u003e
\u003cxs.restrictionbase=\"xs.anyURI\"/\u003e
\u003c/xs.simpleType\u003e
Expression.
All common URIs allowed by reference [17] (possibly compiled to IRI) are also allowed in this section. However, to ensure compatibility with older systems,
It is recommended that users use URL-type strings (seven-character sets) until the IRI concept is fully implemented.
5.3 epc.Boolean---Boolean variable
definition.
Data types include data variables with logical values that are true or false.
Types of.
\u003cxs.simpleTypename=\"boolean\"\u003e
\u003cxs.restrictionbase=\"xs.boolean\"/\u003e
\u003c/xs.simpleType\u003e
Expression.
All variable values allowed by the XSD definition given in Ref. [17] are permissible. When the value in the Boolean type is used to represent the pair
When the answer to the yes/no question is true, it means "yes" and false means "no".
5.4 epc.date---regular date
definition.
Data types include dates, except for additional time or time zone information.
Types of.
\u003cxs.simpleTypename=\"date\"\u003e
\u003cxs.restrictionbase=\"xs.date\"/\u003e
\u003c/xs.simpleType\u003e
Expression.
Is the date in the standard XSD format, without any time zone encoding.
The sender of the date information should not include time zone information. The recipient should be prepared to receive the time zone code, but will be in subsequent data processing.
ignore.
5.5 epc.dateTime---Time and date with time zone
definition.
This data type includes the date, including time and time zone information.
Types of.
\u003cxs.simpleTypename=\"dateTime\"\u003e
\u003cxs.restrictionbase=\"xs.dateTime\"/\u003e
\u003c/xs.simpleType\u003e
Expression.
Is the date and time in the standard XSD format, including time zone encoding.
The sender of the date and time information should include time zone information. The recipient should be prepared to receive the no time zone code. In this case, time zone
Undefined, the system should take appropriate action to process the data.
Note 1. The time zone value "Z" is a valid code referring to GMT or UTC time.
Note 2. The second zone can include a value of 60 (when a leap second occurs).
5.6 epc.decimal---carrying system
definition.
This data type is used to specify the accuracy.
Types of.
\u003cxs.simpleTypename=\"decimal\"\u003e
\u003cxs.restrictionbase=\"xs.decimal\"/\u003e
\u003c/xs.simpleType\u003e
Expression.
The carry type represents a subset of real numbers and is generally represented by a carry system. The value of the space fraction is obtained by multiplying the integer by the negative power of 10.
The set of numbers, for example i x 10^-n, where i and n are both integers and n ≥ 0. Accuracy is not reflected in the value space; numbers 2.0 and 2.00
There is no significant difference. The order relationship of the carry system is consistent with the real number and is limited to this subset.
The carry system has a finite length sequence of decimal places separated by decimal points (
\u003c/xs.simpleType\u003e
Expression.
This type specifies the time period according to reference [17]. The common format is "[-]PnYnMnDTnHnMn.
|