N4 supports EDIFACT standard COREOR message, release D & version 95B.
UI Navigation: Administration > EDI > Message Types
A Container Release Order Message is a notification from Shipping Line to Terminal about an order to release a full container. Optionally it can be used to release empty transport equipment prior to packing.
This specification provides the definition of the Container Release Order Message (COREOR) to be used in Electronic Data Interchange (EDI) between shipping agent and the terminal.
The following sections of this document explain how COREOR message is handled in N4 and scope of its implementation.
COREOR D 95B Inbound Supported Segments
Following table illustrates the segments of EDIFACT standard COREOR D 95B message & scope of each segment in N4.
S.No |
Group |
Segment ID |
Supported Qualifier |
Description |
Supported in N4? |
Mapped Elements |
Reason/ Comments |
---|---|---|---|---|---|---|---|
|
|
UNB |
|
Interchange Header (sender, receiver) |
Supported |
Sender Identification --> InterchangeSender and InterchangeReceipient |
Sender is identified by the contents of the interchange |
|
|
UNH |
|
Message Header (message type, id, version, release number, message reference number) |
Supported |
Interchange Control Reference --> InterchangeNumber |
ID, Version, Release Number is identified by the contents of the interchange |
|
|
BGM |
|
Beginning of message |
Supported |
msgFunction and ediCode |
msgFunction is not handled as of now but we mapped so that it can be used in the future if needed. |
|
|
FTX |
|
Free Text |
Not Supported |
|
|
|
|
RFF |
REO |
Reference |
Supported |
Reference Number --> pinNbr |
|
|
SG1 |
TDT |
|
Details of Transport |
Supported |
a) Conveyance Reference Number --> inVoyageNbr |
|
|
|
RFF |
|
Reference |
Not Supported |
|
|
|
|
LOC |
|
Location |
Not Supported |
|
|
|
|
DTM |
|
Date/Time |
Supported |
Date/Time --> estimatedTimeArrival |
|
|
SG2 |
NAD |
CA |
Name and Address |
Supported |
shippingLine element |
|
|
|
CTA |
|
Contact information |
Not Supported |
|
|
|
|
RFF |
|
Reference |
Supported |
|
|
|
|
DTM |
|
Date/Time |
Not Supported |
|
|
|
SG3 |
GID |
|
Goods Item Details |
Not Supported |
|
|
|
|
HAN |
|
Handling instructions |
Not Supported |
|
|
|
|
FTX |
|
Free Text |
Not Supported |
|
|
|
SG4 |
NAD |
|
Name and Address |
Not Supported |
|
|
|
|
DTM |
|
Date/Time |
Not Supported |
|
|
|
|
RFF |
|
Reference |
Not Supported |
|
|
|
|
MEA |
|
Measurement |
Not Supported |
|
|
|
|
PCI |
|
Package Information |
Not Supported |
|
|
|
SG5 |
SGP |
|
Split Goods Placement |
Not Supported |
|
|
|
|
MEA |
|
Measurement |
Not Supported |
|
|
|
SG6 |
DGS |
|
Dangerous Goods |
Not Supported |
|
|
|
|
FTX |
|
Free Text |
Not Supported |
|
|
|
|
MEA |
|
Measurement |
Not Supported |
|
|
|
SG7 |
EQD |
|
Equipment Details |
Supported |
a) Equipment Identification Number --> releaseIdentifierNbr |
|
|
|
RFF |
SQ, TF, AEL, ZZZ |
Reference |
Supported |
releaseReferenceId |
Check for the value in the following order AEL (or) ZZZ (or) SQ (or) TF |
|
|
TSR |
|
Transport Service Requirements |
Not Supported |
|
|
|
|
MEA |
|
Measurement |
Not Supported |
|
|
|
|
DIM |
|
Dimensions |
Not Supported |
|
|
|
|
TMP |
|
Temperature |
Not Supported |
|
|
|
|
RNG |
|
Range Details |
Not Supported |
|
|
|
|
SEL |
|
Seal Number |
Not Supported |
|
|
|
|
FTX |
|
Free Text |
Not Supported |
|
|
|
|
EQA |
|
Attached Equipment |
Not Supported |
|
|
|
SG8 |
TDT |
|
Details of Transport |
Supported |
|
|
|
|
LOC |
|
Location |
Not Supported |
|
|
|
|
DTM |
|
Date/Time |
Not Supported |
|
|
|
SG9 |
NAD |
|
Name and Address |
Supported |
ediTruckingCompany |
|
|
|
DTM |
|
Date/Time |
Not Supported |
|
|
|
|
CTA |
|
Contact information |
Not Supported |
|
|
|
|
COM |
|
Communication contact |
Not Supported |
|
|
|
|
CNT |
|
Control Total |
Not Supported |
|
|
|
|
UNT |
|
Message Trailer |
Not Supported |
|
|
|
|
UNZ |
|
Interchange Trailer |
Not Supported |
|
|
COREOR D 95B Inbound - Message Functions
As per EDIFACT standard, COREOR has various message function codes in BGM segment. But N4 supports similar to other EDI messages (Original & Update function codes i.e create/update). As per Line Operator, Message functions are indicated in EDI files as CANCEL (code 1) and REPLACE (5) for COREOR along with ORIGINAL (9).
2.2.1 REPLACE
Units which are not sent in Replace message but already attached to the IDO should be detached from IDO and UNIT_CANCEL_RESERVE event should be logged. If Unit is already Departed or currently being delivered (unit in ECOUTE status) against the IDO, appropriate error message will be thrown.
BGM code 5 Original -> mapped as X
2.2.2 CANCEL
The Attached unit should be detached from IDO and UNIT_RESERVE event should be logged. if Unit is already Departed or currently being delivered(unit in ECOUT status) agaisnt the IDO, appropriate error message will be thrown. If there are no units attached to the IDO, the IDO should be deleted. The hold/permission applied to the unit based on the Original COREOR message should be reverted i.e. Hold should be restored or permission should be revoked.
BGM code 1 Original -> mapped as D
For information on the EDI message functions supported by COREOR, see Supported EDI message functions (on page 1).
COREOR D 95B Inbound Pre-requisites
The following section lists the pre-requisites for setting up and testing a COREOR message using COREOR EDI message to release/hold a container in N4.
Required fields in the XML
msgClass attribute values should be "RELEASE"
msgTypeId attribute value should align with the Message Type ID defined in the N4 (example: COREOR)
releaseIdentifierType attribute value should be "UNITRELEASE"
ediCode attribute value. Currently the following assumption is made in the mapping. The customer needs to create their custom maps and map the values accordingly.
if BGM - 1225 - message function code is 1 --> LINEHLD (LINE HOLD which is defined in N4 in holds/permissions UI)
if BGM - 1225 - message function code is other than 1 --> RELEASE (RELEASE which is defined in N4 in holds/permissions UI)
releaseReferenceId attribute value is set as follows
Pick from RFF+AEL segment - 1154 - if found (else)
Pick from RFF+ZZZ segment - 1154 - if found (else)
Pick from RFF+SQ segment - 1154 - if found (else)
Pick from RFF+TF segment - 1154 - if found.
releaseIdentifierCategory attribute is set based on the EQD - Equipment Status element (2 - EXPRT, 3 - IMPRT, 6 - TRSHP and THRGH if nothing specified)
Other Requirements
The customer needs to create a EDI Release Map for the specified ediCode (Example: LINEHLD for hold and RELEASE for release)
Trucking company should exist in the system if it is provided
The flag type used for the EDI code should be applies only to "UNIT" entity
Line operator should exist in the system if it is provided
Shipping line should be mapped to release shipping line element. (Note: The user should not map to ediVesselVisit - shipping line element as it is not used).
Enable the "Use PIN Number in Delivery" checkbox in Line Operator UI if the pin number needs to be posted. Else the system will throw the below error "attempted to set PIN number when the line doesn't support PIN Unit[INKU2584149:2ADVISED:IMPRT:FCL:]"
Other Optional Requirements
Vessel visit should exist in the system for the given details and the specified configuration (EDI Release Map). Need to enable the AutoCreationOfVesselVisit setting if the vessel visit needs to be created for the given details if not found.
Provide the vesselCallFacility details if it refers to the facility at which the vessel(Inbound/Outbound) actually calls
Enable the setting "RLS_VALIDATE_LINE_OPERATOR " to true so that line is validated to release the Unit. By default the setting is set to false.
Enable the setting "RLS_VALIDATE_UNIT_IN_YARD" to validate whether the specified unit is in Yard. If the setting is set it to true the unit must exist in the system
COREOR D 95B Inbound N4 Built-in Map
N4 serves a built-in map which is used to convert COREOR Edi message into Navis standard manifest xml. This xml in turn used for further processing.
Following are the related files, part of N4 application and can be downloaded:
coreor_D_95B.mgt - GoXml map
coreor.dic - Edifact standard dictionary
cusres.xsd - Navis standard release xml schema
How to Configure N4 for COREOR Inbound?
N4 needs to be set up to process an incoming COREOR message. As COREOR is responsible to Hold/Release containers, there may be few rules to be defined based on particular user's business requirement.
To process COREOR:
Create a Hold/Permission (Configuration - Services - Holds/Permissions).
Open COREOR message type in "Message Types" UI and go to "Release Map" tab.
Add a mapping to the Hold/Permission with unique Map CodeRelease Xml message should contain the Map Code in "/releaseTransactions/releaseTransaction@ediCode" attribute.
N4 identifies the Hold/Permission to be applied using the Map Code
4.1.1 EDI Release Map
As per EDIFACT standard, customs may send delivery instructions as Edi codes in Cusres Edi. In N4, release map is a way of mapping those Edi codes to N4 specific Hold/Permission flags.
N4 has a way of validating some business conditions which might be applicable for some clients and not for some. So those validations are made configurable, the user may turn it on if the particular validation is needed or turn it off if not needed.
The following table lists such configurable settings applicable for COREOR EDI message:
Name |
Description |
Edit UI |
Usage |
---|---|---|---|
RLS_VALIDATE_LINE_OPERATOR |
Validate Line is allowed to release the Unit |
Session - Settings |
The given line operator and the unit's line operator should match else the system will throw an error. |
RLS_ALLOW_FOREIGN_VESSEL_VISIT |
Allow auto creation of foreign vessel visit |
Session - Settings |
N4 creates vessel visit on the fly if the vessel visit referred in COREOR is not present in N4 & this setting is set to TRUE. |
RLS_VALIDATE_UNIT_IN_YARD |
Validate whether unit is in Yard |
Session - Settings |
If the setting is set it to true the unit must exist in the system and should be in yard. |