Automation 'Standards': The Search for Consistency and Repeatability

By: eRouhiainen / 2016-1-19 10:00 PM

The implementation of equipment  and process automation, has been an increasingly important topic in container terminal operations. There are important initiatives driving the market demand to concentrate on standardization; with more and more automated container terminals being implemented there is a beautiful opportunity to implement successfully more standard solutions and learn from each other. System Integration has become one of the biggest bottlenecks in successful implementation of semi and fully automated systems at terminals. There is much uncertainty around system integration. And software needs to be gradually developed and deployed with multiple vendors and with features that will ultimately take over fundamental operational areas. 
 
What does the current environment look like for implementing automation at terminals?  What is the key to enable a more professional and agile approaches on system integration? And what are the main areas that terminals will need to focus on for a consistent and repeatable automation implementation in the future?
 
Complexity and Technical Integration
 
An automated terminal operation requires many different hardware and software systems to satisfy various business needs; complexity is a natural outcome. The necessary technical integration is complex and impacts equipment, systems and people. Typical projects have more than 35 interfaces that connect different software systems and pieces of equipment. In addition, automation requires time to develop the designs and concepts that need to be well defined up front and flexible enough for iterative development and tuning. 
 
Navis terminal operating system integration with third party technologies has proven to be a very significant necessity to meet go-live operational readiness. The number and variety of components involved in automation has created significant challenges to deploying a complete and integrated solution. Some of these challenges include:

• Functional specifications and interaction schemes need to be well defined in advance. The current process involves a time consuming and prescriptive process for software development that has led to an extended period of additional testing and solution refinement after go-live.
• Generic communication channels are needed from/to TOS to/from 3rd party technologies that are clearly defined with standardized data exchange patterns organized by equipment type.
• Areas of equipment management need better definition from an operational perspective because the effort to address these areas in after the go-live has impeded operational performance significantly.

To mitigate the risks of going live with automation, all the components must pass through comprehensive testing during the integration process, prior to go-live.  Testing should address direct operational processes to prepare personnel for exception management with solutions. Qualified personnel should be on hand with consistent processes for testing to figure out root causes of issues and deliver agile solutions. Quality is the responsibility of the entire team.  
 
Standard Integration Patterns
 
The terminal automation industry is striving for standards and generic integration patterns on interfaces and interactions, yet there is still a high rate of customization and configuration that needs to take place for each project, depending on lay-out configuration, equipment specifications, etc. The industry needs to develop a clear definition for interfaces and solution modularity to handle the ‘automation puzzle’. It also needs to align the processes that drive specifications, development, testing and deployment with clear criteria for go-live readiness.
 
From a technical integration perspective, Navis has a clear initiative to focus on standardization when developing products and delivering services for implementing automation at terminals. Principals to consider that will help with consistency and reliability of integration include:

• The systems not only need to interface, they also need to “understand” to each other, defining clearly:
  • what, when and how the different systems communicate
  • the data involved in those communications
• Flexible and open architecture that will allow:
  • system providers to extend their product capabilities
  • better and proactive communication and interaction between systems
• A modular and de-coupled approach that will:
  • improve the testing and optimization of the system integration
  • provide data to analyze real operational performance
  • create a long term system framework  

The equipment and operational intelligence that terminal operators are investing in for automation include TOS and Equipment Control System (ECS), which are the eco-system ‘spinal cord’ at automated container terminals.



TOS-ECS Integration
 
Dealing with the complexity of the system from TOS to ECS to the equipment is one of the major challenges that automated terminals need to deal with.
 
From a technology perspective, ECS software providers are taking a step forward, but the maturity of existing solutions is not where they need to be. ECS software companies are focusing on increasing their software efforts on design, architecture, testing and deployment practices and seek to standardize their efforts to reduce future integration complexity and cost.
 
There are several discussions taking place in this industry on ‘who is doing what function’. With the development of automated systems, Navis is focused on providing a single optimized logistics solution for both manned and automated terminals within the same technology footprint. This will serve to ease the adoption of automation and convert equipment and systems over time with less technical risk and capital investment.



The technical integration and operational interaction between TOS and ECS is fundamental. While Navis believes that ECS vendors should focus on optimizing execution and coordination of equipment, there are some important aspects to consider that will enable both TOS and ECS to perform their expected functions effectively and in an integrated fashion. This will ultimately impact operational readiness and minimize the time to value and enable consistency and repeatability when implementing automated systems at container terminals.

 
The Way Forward for Consistency and Repeatability
 
The following points are highlighted by Navis as the main drivers of the ‘way forward’:

• Interaction schemes: Clear definition for interface and solution modularity. Interactions between different software applications supporting container flows need to be defined upfront and well maintained to support both the basic and exceptional container flows. These interaction schemes must be defined in a modular way to gradually and consistently allow the connection of the different terminal equipment types while commissioning equipment and preparing the terminal for operations with live equipment testing.
• Accuracy of the information: System providers must find effective mechanisms to push out data from software applications. This will improve the integration, and, information congruency problems could be solved. Information from real-time planning needs to be used in a consistent way. It is crucial to keep accurate information as move-times, transfer point occupancy or drive times change.
• Data Transport Technology: Even though there are different transport mechanisms and technologies that support various communications between systems, the industry needs to promote the modern data technology and infrastructure that supports automation. While richer and more accurate data will enable real equipment intelligence, technologies providing reliability on system performance, traceability on equipment events and maintainable data consistency will be fundamental. 
• Optimization: Navis opened the N4 TOS architecture to include 3rd party software optimizers to perform algorithms as an integrated part of the TOS platform.  As such, the TOS is in the best position to perform job allocations utilizing a holistic view of the entire operation and leveraging the complete set of operational data and business rules to provide feedback to the planning process and an integrated approach to exception handling. 
• Standardization efforts: Standardization efforts have been pursued recently by PEMA and need traction to improve software compatibility between TOS providers, equipment manufacturers, automation software providers and the end-users (i.e. terminal operators). Standardization efforts must include definition not only on the technical interfaces and on the required data to be exchanged, but also on interaction schemes by equipment type and  on testing processes, and alignment of processes to deliver acceptance criteria for operational integration readiness.
• Integration Management: A more professional and agile approach to system technical integration is needed. Project management with qualified resources that know every single interface across the implementation is required. Further, collaboration between the terminal operator and multiple parties needs to have these project management counterparts involved to deploy the integrated solution.

 
There is a good opportunity for our industry to set standardization as a priority. Technical integration is complex and impacts equipment, systems and people.  The areas of focus are well defined and the benefits on getting a clear path for consistency and repeatability for terminal operators and system providers will be huge and necessary for automation to be successful in this industry.

Navis Jobs - Consultant I, Professional Services (S)

Consultant I, Professional Services (S)

All times are in Eastern African Time.

Requisition Number 

2016-1923

Job Locations 

NL

Region 

EMEA

Posted Date 

2/24/2016

Type 

Regular Full-Time

More information about this job:

Overview:

Why Navis?

Navis is the global market leader in building and implementing terminal operating systems and optimization solutions for ports around the world. From Long Beach to Hong Kong, Dubai to Brazil, and Rotterdam to Busan, Navis delivers enterprise software that is at the heart of running a terminal and services to optimize operations. Navis’ latest projects involve advanced algorithms, new web technologies and application development that are leading the way in automation and optimization in the industry and will drive the future of supply chain operations.

The Job

As a Consultant I, this position will we responsible for performing system implementation tasks for consulting projects. In addition, the Consultant I determines business and technology requirements in terms of operational processes and technology and works as part of a team providing technical solutions for the implementation of products.

Responsibilities:

In this role, you can expect to:

• Implement solutions with customers using our Implementation Methodology
• Work closely with customers to define, prioritize, and document business and operational requirements for enterprise-level distribution center supply chain management solutions
• Define interface requirements to integrate   solutions with customer's existing systems
• Assess solution options and define conceptual solution design, in conjunction with client operational and IT systems engineers
• Serve as customer advocate throughout solution design, development, and test phases to ensure delivered solution meets customer objectives
• Provide domain expertise, especially in the areas of ocean cargo, warehousing, logistics, and terminal operations, throughout the project life cycle
• Assist with building a growing consulting practice to include practice aids and templates for use at multiple clients

Qualifications:

What you must have to be successful in the role:

• Degree in Business, MIS, Computer Science, Industrial Engineering, or related disciplines
• 2-3 years experience in container terminal projects or complex logistics automation projects.
• Extensive knowledge of networking technologies and relational database structures or web-based enterprise solutions and technologies
• Strong leadership and organizational skills
• Detail oriented, hard working and self-motivated
• Willing to travel up to 80%
• Excellent written and oral communications skills in English.
• Able to work extended hours under tight deadlines
• Able to multi-task and successfully meet objectives
• Experience with related systems such as transportation management systems, cargo tracking technologies, warehouse management systems, or radio frequency identification, RTLS and OCR systems

Additional skills that would be beneficial in the role:

• Experience with Unix, Windows, Oracle, EDI, Oracle, SQL Server and Java (Groovy)
• Experience in the deployment of software
• Strong technical and troubleshooting skills in several applications and technologies
• Working knowledge of use case modeling and process modeling techniques
• Experience in the deployment of IT infrastructure such as handheld devices, servers and clusters

Apply Here

FEB 22, 2016

HAMBURG PORT CONSULTING BECOMES NEWEST NAVIS SERVICE SOLUTIONS PARTNER

STRATEGIC COLLABORATION BEGINS WITH N4 TOS IMPLEMENTATIONS AT HHLA TERMINALS; EXPANDS TO FUTURE CONTAINER TERMINAL PROJECTS WORLDWIDE

Navis, a part of Cargotec Corporation, and provider of operational technologies and services that unlock greater performance and efficiency for the world’s leading terminal operators, announced that HPC Hamburg Port Consulting GmbH (HPC), a subsidiary of Hamburger Hafen und Logistik AG (HHLA),  has signed on as Navis’ newest implementation service partner, supporting the rollout and optimization of the Navis N4 terminal operating system (TOS) at container terminals worldwide. In one of its first projects as a Navis partner, HPC will support the implementation of N4 at all three Hamburger Hafen und Logistik AG (HHLA) container terminals.

HPC is an established and well-respected port consultancy with expertise in TOS deployment and technology at container terminals. As a certified Navis Service Solutions partner, HPC offers a vast range of experience to compliment Navis’ Professional Services implementation teams, ensuring that N4 customers are positioned for success with their software—before, during and after the go-live. HPC’s involvement with Navis at HHLA and beyond will substantially augment the outside consulting skills available to Navis’ professional services group.

“The collaboration with Navis for the roll-out of the N4 terminal operating system in ports and handling companies worldwide complements our strongly expanding strategic IT consulting business unit. We are able to contribute our extensive knowledge of ports to this collaboration, where we benefit in particular from our many years of experience with the integration of processes at the interface between people, machines and IT systems. Our strategic goal is to establish a global competence center for consulting and training in connection with terminal management systems. In view of our collaboration with Navis, it is important to us that we will continue to be able to provide expert and impartial advice to our port and terminal customers when it comes to IT strategy and other matters.”  said Henning Kinkhorst, Managing Director of HPC Hamburg Port Consulting GmbH.

“We are delighted to have the opportunity to work with Hamburg Port Consultants as a Navis Service Solutions partner,” said Guenter Schmidmeir, General Manager of EMEA, for Navis. “By combining our expertise of terminal operations and implementations of terminal operating systems, we will be able to offer our customers improved efficiency and reliability for their TOS implementations.”

Navis Service Solutions Partners are composed of a select group of experienced and certified third-party Navis TOS organizations who provide integration and implementation services for new and existing Navis customers.  IT experts at HPC underwent a specialized certification program with an emphasis on customer requirements and training in preparation for the N4 rollout program.

What is Navis Doing to Support SOLAS in N4 and Express?

What is Navis Doing to Support SOLAS in N4 and Express?

By: JHallin / 2016-3-3 12:00 AM (Navis website Blogs)

Introduction

IMO’s Maritime Safety Committee (MSC) adopted changes to the Safety of Life at Sea (SOLAS) convention mandating container weight verification on shippers.  Beginning July 1, 2016 container weight verification will become a condition for vessel loading.

The goal of this program is to ensure all containers loading to a vessel have verified weights. This will allow terminal personnel, Chief Mates and Masters aboard vessels to assess the load plans, ensuring proper balancing of the vessel for its voyage to the next Port of Call.

What is Navis doing about SOLAS in N4 and Express?
  
Both products are being developed based on the same functional requirements document.We will extend the data models to include the following new fields:
 

• VGM Weight – This field stores the Verified Gross Mass
• VGM Verifier – This text field captures the party/entity authorizing the VGM Weight (ex. “Scale weight facility or person”)
• GrossWeightSource – This field represents the source that generated the Gross Weight of the unit (ex. “overwritten by VGM”)

N4 Update

General 

Within N4 the Verified Gross Mass (VGM) Weight can be updated through a variety of sources:

• The following EDI maps will support mapping VGM Weight and VGM Verifier to the new fields in N4:
  • Posting (Inbound)
    • VERMAS
    • Stow Plan (Baplie)
    • Loadlist and DischList (Coprar)
    • Activity (322, CODECO, and COARRI)
    • Booking (COPARN, 301)
    • BaseMapping XSD
  • Extraction (Outbound)
    • Baplie
    • Activity (322, CODECO, and COARRI)
• ​Users with appropriate privileges will be able to set the value of the VGM Weight and VGM Verifier using the N4 User Interface
• Individual terminals may choose to develop customized solutions using Code Extensions and Configuration to provide the value of the VGM Weight and the VGM Verifier field. Terminals that want to generate the VGM Weight (as an example by using scales at the terminal) could use this mechanism to populate the VGM Weight field in N4. Navis Field Development may be engaged to assist with Code Extensions, as needed.

Configuration Tasks

XPS and XPS-Client use the value of the Gross Weight of the unit when making planning and decking decisions. In order to make XPS use the VGM Weight, an Auto Update Rule should be triggered on VGM Weight changes. The rule will copy the VGM Weight to the Gross Weight of the Unit and set the GrossWeightSource to ‘VGM’. This may be done by the terminal N4 admin staff.  

There is potential that the Gross Weight updated by the VGM Weight may be subsequently overwritten, causing a discrepancy between the Gross Weight and VGM Weight. This may be triggered if a subsequent EDI message comes in that updates the VGM weight, or it is possible a scale weight may override a VGM Weight. If this happens, the GrossWeightSource can help determine if the value of the Gross Weight is the VGM Weight by indicating “Not VGM source” anymore. This means you may have a hold in N4 based on the VGM not being null and the gross weight data source being VGM.
 
N4 should be configured to place a vessel load hold on full export containers for which the GrossWeightSource is not ‘VGM’. This will result in a Vessel Stop in XPS-Client and will prevent these containers from being loaded to vessel. 

Testing of this solution in your test system will be important to validate the use cases and expose any configuration questions you may have. 

User Interface

For N4, the VGM Weight, VGM Verifier and GrossWeightSource will be visible in the Units view and Unit Inspector. Users will have access to Gross Weight (as they do now) and the new field representing GrossWeightSource in the XPS-Client.

Express Update

For Express clients the following messages will be modified to support VGM for customers using UNEDIFACT and/or ANSI.

• Posting (Inbound) – Baplie, COPRAR LOAD and VERMAS, 301
• Extraction (Outbound) – BAPLIE, CODECO , COARRI, and 322.

Navis is anticipating that many sites will move to the new Express 2.9_P137 branch.  However, we will need to engage and work with terminals individually that do not wish to upgrade to this patch. SOLAS will be implemented and initially released thru EXP29_P137 on April 1, 2016.  

*We do not have any plans to update SPARCS; the host will manage the SOLAS requirements. 

Configuration Tasks

Access to VGM fields will be configurable based on the user role assignment. Vessel load holds for full export containers which do not have values for VGM fields will be controlled by a parameter setting. The details will be included in the requisite Release Notes. 

User Interface

The Verified Gross Mass and Units field will be visible and updateable in identified Vessel Stow plan entry, Export Module and Container update screens. These details will be included in the requisite Release Notes.

Service Offering

In addition to the approach outlined in this letter, we would like to extend our offer of support should you require any assistance in the following areas with implementing the SOLAS – VGM regulations within your terminal:

•  Configuration
•  Integration
•  Process mapping 
•  EDI mapping
• General support

Having the TOS compliant is the first phase of what is a two phase process and we can work with you to successfully leverage this regulation to the benefit of your business.

You may reach out directly to your Regional Services leadership, or Service Delivery Sponsor.

References

Below is the link to our blog for additional material and exposure to past conversations.
https://collaboration.navis.com/BlogDetails?id=90616000000M8F1AAK

The below link is a group we created on the NCC where we will host an open forum on the SOLAS topic. Please check this resource occasionally to get updates from Navis.
https://collaboration.navis.com/_ui/core/chatter/groups/GroupProfilePage?g=0F9160000000DFhCAM

Key Contacts
  
For any follow-on questions, please initially refer to the above links.  

Alternately, please contact either:

• Jon Hallin, Director of Customer Programs – jon.hallin@navis.com

Or your assigned Customer Sponsor

SOLAS Regulation for Verification of Gross Weight of Export Containers Obligation by law from 1st of July 2016

Starting on the 1 st of July 2016, the gross weight of all export-bound containers loaded with cargo will have to be determined by a certified and approved method right on time before being loaded onto any container vessel in the port. Moreover, the verified gross weight (official term: Verified Gross Mass or VGM) of each full container will also have to be submitted right on time to the shipping line and container terminal parties.

The legal foundation behind this regulation is in accordance with the International Maritime Organization’s (IMO) SOLAS Convention (International Convention for the Safety of Life at Sea). This global law was implemented as a national law in each country of the world. Incorrect weight details of loaded containers have been the cause of ship accidents in the past. This new, obligatory regulation is meant to ensure the safety of people, transportation means, cargo and the environment. As of 1st of July 2016, not a single export-bound, cargo-loaded container will be loaded on any container vessel without first determining the verified (confirmed) gross weight (VGM). 

It is the responsibility of the Shipper (Exporter) to submit the documentation stating the verified gross weight of the cargo-loaded container. The Shipper will have to evidence appropriately that an actual weight verification procedure was performed. The verified gross weight of the cargo-loaded container must either appear on an existing shipping document or a stand-alone document, both of which have to be signed by an authorized person of the Shipper. An electronic submission of the document is also permitted, in which case the name of the authorized person will suffice. In any case, the verified gross weight of the container must be explicitly stated in the document. 

There are two methods to determine the Gross Weight of cargo-loaded containers in conformity with the proof requirements:

 Method 1: Weighing of the Cargo-Loaded and Sealed Containers: 

This method 1 is, in case you do not have a calibrated (certified and approved) scale in your own premises, cost intensive. Costs arise for double weighing the container and the truck before and after loading of the container at the premises of the shipper. Moreover, multi-stop (detours and time loss) charges will have to be taken into consideration as the truck will have to be driven to an approved weighing facility (ideally one located near the premises of the Shipper). However, Method 1 is obligatory if commodities such as bulk materials or scrap are involved. 

Please note that the Shipper (Exporter) must still submit the gross weight of the cargo for Export Customs Clearance (issuance of the Export Customs Document with MRN) before the cargo is loaded into the container. Also, a timely submission of the weighing certificates and the document containing the verified gross weight of the cargo-loaded container is difficult considering the long information chain: Weighing Facility → Truck Driver → Trucking Company → Shipper → Forwarding Agent → Shipping Line → Container Terminal. As a rule the posterior weighing of the loaded container at the seaport container terminal is too late for the stowage plan of the vessel and is cost intensive. Important Notice for Exporters Loading Containers to Overseas Countries! 

Method 2: Calculating the Gross Weight of the Loaded and Sealed Container

The shipper must weigh each package meant to be stuffed in the container including the packaging and securing material. An estimated weight is not permitted. The shipper must calculate the sum of the weight of each package including the weight of the packaging and securing material and has to add the tare weight of the utilized empty container. 

The sum of this calculation is the Verified Gross Mass (VGM) of the container: 

VERIFIED WEIGHT OF ALL PACKAGES + VERIFIED WEIGHT OF PACKAGING & SECURING MATERIAL + WEIGHT OF EMPTY CONTAINER = VGM. 

The tare weight (empty weight) of the container is printed on the outside door of the container. This information can be obtained from the loading personnel once the cargo loading procedure has taken place. 

As far as the calculation of the cargo weight is concerned, every single package (including packaging material, stowage material and securing material) that is intended to be loaded into the container unit has to be weighed by a calibrated scale in your premises.

The advantage of Method 2 is that the verified gross weight can be documented (e.g. on the Shipping Order or Container Packing List) as soon as the container loading has been finished. 

Current State of Implementation of the SOLAS Regulations by the National Authorities: 

The utilization of Method 2 must be certified and approved by the authorities of the country where the loading and sealing procedures of the container was completed. Any weighing equipment used to weigh the contents of the container must meet the applicable accuracy standards and requirements of the country in which the equipment is being used. 

NAVIS (SPARCS N4) – a SIMPLIFIED USER GUIDE

1. NAVIS (SPARCS N4) - Introduction:

 SPARCS N4, developed by NAVIS (SPARCS N4), part of Zebra Enterprise Solutions, is the industry's most scalable, open, deployable, adaptable and maintainable terminal operating system (TOS) available today. SPARCS N4 TOS is a fully integrated solution from gate to yard to vessel and vice versa, thereby eliminating the manual processes and costly errors required to keep disjointed systems in sync. Employing a Java "Rich-Thin Internet Client" technology, SPARCS N4 makes it easy to standardize into a single, homogeneous system, managing business processes across multiple operations. This Java-based solution provides inherent cross-platform portability, alleviating the impact of a heterogeneous hardware infrastructure that may arise through natural technology evolution and upgrades. 

2. TPT - NAVIS (SPARCS N4) Overview:

 NAVIS (SPARCS N4) is currently fully operational at ALL the TPT container terminals except for DCT, which is expected to “Go-live” early in 2011. TPT is also the pioneer for NAVIS (SPARCS N4) currently, in that it is the first site, worldwide, to employ the MULTI TERMINAL/FACILITY component of NAVIS (SPARCS N4). TPT has also developed a “Customer Access Portal” from which our clients can interact with the NAVIS (SPARCS N4) system remotely via WEB connection. This initiative should be available to our clients shortly and a “CAP” user guide is available upon request. 

3. TPT – Operations Past to Present:

 Transnet Port Terminals originally started out as “SAR+H” (South African Railways and Harbours), utilizing a paper based process of conducting day to day business. As the age of computers dawned, a green screen system, called COSMOS was implemented. The recent shift to the more modern “Graphical User Interface” terminal management system of NAVIS (SPARCS N4) has given TPT the opportunity to streamline and enhance their port operations and facilities optimally. 

4. Process Flow Business Process and N4 in the TPT Terminals:

5. EXPORT 

5.1 Shipping Line submits vessel nomination / vessel visit created 

The first action for EXPORT containers in order for TPT to facilitate a shipping line’s vessel, is the submission of the “vessel nomination” document. This document must be submitted at least 14 days before vessel arrival but can be submitted even 2-3 months before vessel arrives. No export bookings can be made via the web or EDI unless the vessel has been nominated. It is therefore imperative that the shipping line ensures that nominations are sent to TPT before they start processing bookings for a vessel/voyage. On TPT’s N4 system, a “vessel visit” is created. It is important for the shipping line to note, that TPT must have the FULL port rotation for the nominated vessel. This should also be present in the BAPLIE_IN (bay-plan) EDI file received from the shipping line for a nominated vessel.

5.2 Shipping Line create “Export Bookings”

 In order for TPT to be aware of the volume of containers and then planning and execution of facilitating physical units, the shipping line has to create Export Bookings via their WEB access on the N4 system or via the COPARN EDI message. This booking typically indicates the freight kind, quantity, ISO code, POD and vessel detail. Screen below shows illustrative view of a manual booking creation and pre-advise. 

5.2.1 On N4: Create Export bookings

5.2.1 On N4: Create Export bookings (cont)

5.3 Shipping Line “Pre-advises” units The “Pre-advising”

 for RAIL units is currently an automated process within TPT, with electronic files received from TPT’s sister company, TFR. Pre-advising ROAD units currently takes place at GATE_IN (entry) but will be required to be submitted prior to the truck arriving at the Terminal in the near future.The Pre-advice can be done via the Web or via a COPARN – EDI message. 

5.3.1 On N4: Manually pre-advise units - selection 

5.3.2 On N4: Manually pre-advise units – view Units pre-advised.

5.4 Truck / Train arrives at terminal

 When the container physically arrives at the terminal either on a TRUCK or a TRAIN wagon, it is offloaded and placed in the terminal YARD. The planning for the vessel is completed after receiving and loading the BAPLIE_IN (bay-plan) file from the shipping line. The vessel is now “worked” according to the plan, in other words “loaded” and/or “discharged”. Once the terminal has completed “working” the vessel, an “Outbound” EDI or BAPLIE_OUT file is generated and E-Mailed to the shipping line. The vessel then “Departs” the terminal. 

6. IMPORTS 

6.1 Shipping Line submits vessel nomination / vessel visit created The same scenario follows as with the EXPORT flow in the terminal, a vessel nomination document is received from the shipping line, and then a vessel visit is created. 

6.2 Shipping line submits “IN_BOUND” BAPLIE Once the terminal receives the INBOUND BAPLIE file from the shipping line, it is uploaded into the N4 system. 

6.3 Shipping line submits COPRAR file or Rail/Transshipment lists The COPRAR EDI file is received after the IN_BOUND BAPLIE file, and is loaded into N4, after the BAPLIE file. The COPRAR EDI file performs the same function as the manual “RAIL” lists and “Transshipment” lists supplied to the terminal. These lists are the instruction from the shipping line, as to which containers will leave the terminal via RAIL and which containers are “Transshipment” containers and leave the terminal on an “on carrier vessel”. 

6.4 TPT Plans Discharge sequence 

Once the BAPLIE and COPRAR files are loaded, and the Rail and Transshipment lists processed, the terminal now plans the “working” of the vessel, hence the “Discharge” sequence. The containers that must be “Discharged” from the vessel are taken off and placed in the terminal YARD. This is also referred to as “stacking”

. 6.5 Shipping line releases unit(s) and assigns Trucking company

 There are various types of holds that can be placed on containers by a number of parties. Holds can be placed by SARS (Customs stops) and these can be lifted by the Shipping Line. It is extremely important that the Shipping Line has obtained a release from SARS before uplifting a hold on a container.

 If a “Customs stop” has been placed on a container which has been routed by rail to an inland destination and SARS instruct that the container can be released for an inspection at a local facility, it is imperative that the rail routing be cancelled and changed to a road routing before the hold is lifted from the container by the Line. 

If this is not done there is a high risk that the container will be railed as originally planned and SARS will require that the container be returned to the discharge port for inspection. This will result in additional costs being incurred by the Line. 

When the container arrives on the vessel, there is an automatic “IMPORT HOLD” on the unit. In order for them to remove their containers from the terminal, the shipping line has to perform a “RELEASE” of their respective units on N4. This can either be done with an EDI file called a COREOR, or a manual action on N4. (Screen below shows illustrative view of “releasing” units).

6.5.1 On N4: Releasing IMPORT units 

All the IMPORT units inbound to the terminal has an automatic “IMPORT HOLD” on them. The shipping line performs the release of units, either manually on N4 or then electronically via the COREOR EDI file. 

6.6 UNITS loaded onto Truck/Train and “DEPARTS” terminal

The terminal allows the Trucking companies to collect the UNITS, provided that the “LINE HOLD” has been updated in other words the unit has been systematically “RELEASED” on N4. The same applies for the RAIL units. (For an illustrative view of the “Gate process”, see screens below) 

6.6.1 GATE IN and GATE OUT for Trucks: 

For IMPORT units the HOLD on the unit first has to be released, either “manually”via the web or via COREOR EDI file, before it may leave the terminal. (refer section number 6.5 of this guide). Then a TRUCKING COMPANY has to be assigned. This can be done “manually” as well as via COREOR EDI file. Note a TRUCKING COMPANY has to “EXIST” on N4 if it is collecting a unit from the terminal, or then be assigned. For EXPORT units, the booking and pre-advise is currently processed as the truck enters the gate at the terminal but the pre-advice will be required to be submitted either via the web, or via the EDI COPARN message prior to the truck arriving at the terminal entrance. The trucks entering the terminal have to be in possession of an RFID card for the AUTO GATE which includes their BAT number. A truck has to be licensed and be in possession of its TNPA permit as well. The automated gates within TPT are managed by CAMCO with their GOS system (gate operating system) integrating through to N4.

7. Transhipments

 7.1 Shipping line submits vessel nomination for both pre- and on carrier After receiving the vessel nominations for both the pre-vessel visit and then the “On-carrier” visit for the Transhipment units, the systematical vessel visits will be created by TPT on the N4 system. 

7.2 Shipping line submits INBOUND BAPLIE and COPRAR TPT then receives the INBOUND BAPLIE (bayplan) file, which is loaded onto N4 for the specific vessel visit. As in the case of the IMPORT units the COPRAR file or RAIL/TRANSHIPMENT lists are processed onto N4, after the BAPLIE_IN file has been successfully loaded. (Screens below for illustration) 

7.3 TPT Plans Discharge sequence/ working the vessel

 Once the EDI files have been loaded and lists processed, the vessel “discharge” sequence is planned by the vessel planners in the terminal. When the vessel arrives and berths, she is “worked”, discharged and loaded. The units that are discharged are placed in the terminal YARD (stacked) according to POD. 

7.3.1 UNITS Planned for On-Carrier/Loaded onto On-Carrier/Vessels DEPART

 The “Transshipment” units in stack, per POD, are now planned for their respective “On-Carrier” vessels expected at the terminal. Once these vessels arrive, the “Transshipment” units are LOADED onto their respective “On-Carrier” vessels. Vessels DEPART. 

8. EDI messaging on N4:

  

8 .1 EDI messages – chronological flow: 

8.1.1 BAPLIE_INBOUND = File received from shipping line, uploaded onto N4 - manually 

8.1.2 COPRAR = File received from shipping line, uploaded onto N4 – manually 

8.1.3 BAPLIE_OUTBOUND = File generated from N4 to trading partners - manually 

8.1.4 COREOR = File received from shipping line, uploaded onto N4 – automatically 

8.1.5 COARRI_DISCHARGE = File generated from N4 to trading partners - automatically 

8.1.6 COARRI_LOAD = File generated from N4 to trading partners - automatically 

8.1.7 CODECO_OUT = File generated from N4 to trading partners – automatically 

8.1.8 COPARN (booking) = File received from shipping line, uploaded onto N4 – automatically 

8.1.9 COPARN (pre-advise) = File received from shipping line, uploaded onto N4 – automatically

8.1.10 CODECO_IN = File generated from N4 to trading partners – automatically

9. EDI frequently asked Questions & Answers:

Q: Created a booking/coreor in my system but do not see it in NAVIS? 

A: It takes app. 15-20mins for a booking to be uploaded in NAVIS from FTP -> File Server -> NAVIS. 

Q: I have released my container via COREOR but the trucking company in NAVIS reflects as BLANK? 

A: This is incorrect as the code you have used does not have a valid trucking company assigned to it, check for the correct/corresponding trucking company and code and resend COREOR message 

Q: I am amending my Booking from 2 containers to 1 container but NAVIS give me error, QTY_LESSER_THAN_PREADVISED_OR_RECEIVED_QTY, what does this mean? 

A: There have already been more containers gated in for this booking than that, which you are trying to amend the quantity to. 

Q: My APERAK says COULD NOT FIND A VESSEL VISIT FOR CONVENTION [LLOYDS], VALUE [3FWL4] AND O/B VOYAGE [113E] AT FACILITY PNTP1, what does this mean? 

A: This either means that the vessel visit is not created in our system as yet or that the call sign/voyage you have provided for the vessel does not correspond with the one we have on system for this vessel. 

Q: My APERAK says EQUIPMENT ORDER DOESN’T EXIST FOR id 12345678, LINE MOL AND VESSEL VISIT…what does this mean? 

A: This error means that you have sent through a replace/cancellation COPARN for a booking that does not already exist in NAVIS, you cannot update/cancel a booking that does not exist. 

Q: My APERAK says VESSEL WITH LLOYDS [3FWL4] not found, what does this error mean? 

A: This error means that there is no vessel on our system corresponding to the call sign that you have provided in your EDI message. 

Q: I have sent through my COPRAR file but have not yet received an APERAK for it, why? 

A: The COPRAR message is manually uploaded into our system as it can only be loaded once the BAPLIE for the vessel has been loaded, therefore once the BAPLIE is loaded then the COPRAR is loaded. You will then receive the APERAK message. 

Q: My APERAK says that the trucking company code that I have used in my COREOR message is incorrect? 

A: The Trucking Company code list would have to be rechecked, it is more than likely that the code you have used is no longer in use/has been deleted. 

Q: The COPRAR APERAK reflects the following error PLACE KHH TW NOT AS POL OF CALL (VS PIPRM 027W) - PILASA – PNTDB, what does this mean? 

A: Errors such as these are usually resolved by the Terminal, if your input is required then the Terminal will notify you.