DCSA envisions a digitally interconnected container shipping industry. Our mission is to be the de facto standards body for the industry, setting the technological foundation for interoperable IT solutions. Together with our member carriers, DCSA creates vendor-neutral, technology-agnostic standards for IT and non-competitive business practices. By working towards the widespread adoption of these standards, our aim is to move the industry forward in terms of customer experience, efficiency, collaboration, innovation and respect for the environment. Please refer to the DCSA website for more information.
The objective of the DCSA Data and Interface Standard program is to strengthen the container shipping industry’s ability to send and receive data across all parties in the industry. Furthermore, it aims to enhance inter-carrier cooperation based on shared requirements and to ensure interoperability by using a shared data language. This language is inspired by existing standards and is aligned with the industry process definitions put forth in the DCSA Industry Blueprint.
The standards published by DCSA are technology agnostic. DCSA does not point to the use of specific vendors’ technologies or systems but relies on open-source, shared requirements for the industry that can be used by all parties, regardless of their choice of technology.
This chapter describes the purpose, scope, conformance and supporting publications of this document.
The objective of the DCSA Interface Standard for the Booking process is to simplify the exchange of information between shippers and carriers, as related to a booking. In doing so, this publication supports standardisation of the fundamental information exchanged between shippers and carriers. The focus of this publication is to ensure agreement on the shared requirements and standards that must be followed to streamline inter-operational functionality and data sharing across relevant industry participants.
Agreement on standards will ensure that data exchange interfaces, including functionality and data provided, will follow the same definitions and design. The aim is to ensure that the end-user experience remains consistent across all industry participants who use these standards. Hence, the interface elements must remain consistent whether they are built using EDI messaging, interactive UIs, APIs, manual data exchanges or any other interface technology.
The DCSA Interface Standard aims at standardizing the communication between data consumer and data provider. While the standardised processes and terminology can be applied to any messaging media (e.g. email, EDI, etc.), APIs (Application Programming Interfaces) are the modern standard for interoperable, digital data communication, enabling real-time data exchange, faster innovation and great customer experience. In collaboration with its member carriers, DCSA has developed OpenAPI specifications supporting the use cases and user stories defined in the DCSA Interface Standards.
The Interface Standard for the Booking process focuses on the process steps “Booking Request” and “Booking confirmation” as part of the end-to-end documentation process:
In defining a technology-agnostic interface standard, the interface describes all exchanges of information between any two parties. For the exchange of information regarding Booking request and Booking Confirmation, the most relevant parties are:
Shipper or booking party
Carrier
Other parties involved in the exchange of information regarding bookings, such as container depots and customs authorities are not in scope of this publication.
All parties in the container shipping industry are encouraged to implement and follow the data and interface requirements outlined and specified in this document. The requirements are linked to the UML version 2.0 diagrams for design requirements as well as the Logical Data Model and data definitions for information requirements, which must be implemented to conform to the agreed standards within the DCSA framework.
This document is supported by a range of supplementary DCSA publications. The supporting publications are listed in the table below and can be found on the DCSA website.
Publication | Descriptions |
---|---|
DCSA Interface Standard for the Bill of Lading 3.0 Beta-1 | The DCSA Interface Standard for the Bill of Lading outlines a framework for sharing the fundamental Transport Document information provided across the carrier liner domain through documentation interfaces. |
DCSA Booking process 2.0 Beta 1 Data overview | This document contains a complete list of the attributes that are relevant input for the use cases defined in the Interface Standard for the Booking process 2.0 Beta 1, including a stipulation as to whether the fields are mandatory, conditional, or optional per process step. |
DCSA Information Model 2023.Q4 | The DCSA Information Model has been created to organise and catalogue the information being generated or consumed in connection with the processes described in the DCSA Industry Blueprint. The information model is also used as a collective term to describe all products that model data. The information model includes a diagrammatic representation of selected data entities and their relationships with one another. |
DCSA Information Model 2022.2 Reading Guide | This document helps to set the context for DCSA initiatives. The Reading Guide provides insight into the different concepts and methods utilised in the production of the Information Model and suggests ways in which the document can be used. |
DCSA Glossary of Terms | This document promotes alignment of terms across all DCSA stakeholders in the container shipping industry. The Glossary is published on the DCSA website in the context of the DCSA Industry Blueprint. |
DCSA Industry Blueprint 2023.3 | This document provides insights into as-is carrier processes. The DCSA Industry Blueprint comprises processes related to the movement of a container/equipment from one location to another, processes that are linked to a shipment/booking, processes that are considered critical for industry digitisation and standardisation efforts, and finally processes that are not considered commercially sensitive or of competitive advantage. |
DCSA Event Naming Convention 2.2, and Event Structure Definitions 2.2 | This document provides a standard naming convention that enables a common understanding of customer-facing track and trace events. |
DCSA Schedule Definitions 1.0 | This document standardises the terminology and definitions with respect to communication of operational deep-sea (inter-regional) vessel schedules between Vessel Sharing Agreement (VSA) partners. The purpose is to facilitate standardisation and accuracy in partner communication and hence reduce the pain-points that carriers raised in this area. It is understood that not all VSA’s (or carriers) apply all processes, but for the sake of completeness, the full process definitions are shared with all members. The purpose is to standardise what and when partners communicate (and to whom) with respect to operational vessel schedules and related exception-management. |
DCSA Interface Standard for Operational Vessel Schedule 1.0 and respective Reading Guide | The DCSA Operational Vessel Schedule (OVS) Interface Standard simplifies the exchange of vessel schedule-related information between vessel operators, and to support the standardisation of the fundamental information provided across the vessel operator liner domain. The reading guide provides insight into the different concepts and methods utilised in the production of the OVS Interface Standard and suggests ways in which the document can be used as a foundation for future implementations. |
DCSA Interface Standard for Track and Trace 2.2 and respective Reading Guide | The DCSA Track and Trace Interface Standard outlines a framework for sharing essential information within the carrier liner domain to facilitate track and trace operations. The Reading Guide provides insight into the different concepts and methods utilised in the production of the Track and Trace Interface Standard and suggests ways in which the document can be used as a foundation for future implementations. |