DCSA Reference Documentation / Standards / Standard Releases / Verified Gross Mass / Verified Gross Mass v1.0.1

DCSA Interface Standard for VGM 1.0.1 - Conformance Scenarios

This page is republished as part of the complete documentation set for this version. No content changes were made compared to the 1.0.0 version.

Contents

• 1. What is Conformance?
• 2. Conformance Scenarios
  • 2.1 POST scenarios
  • 2.2 GET scenarios for all required query parameter filters
  • 2.3. GET scenario for any optional query parameter filters
• 3. Conformance Validations
  • Custom validations

1. What is Conformance?

Conformance refers to the validation process used to assess whether an implementation of the VGM API adheres to the expected technical and business requirements defined by DCSA.

The objective is to ensure interoperability across the ecosystem by demonstrating that VGM Declarations are exchanged using the correct format and content through the GET and/or POST standard endpoints.

2. Conformance Scenarios

2.1 POST scenarios

These scenarios measure the conformance of VGM Producers who send out VGM Declarations to the POST endpoints of registered VGM Consumers.

• POST VGM Declaration

The “POST VGM Declaration” conformance action prompts the user to have their system POST a message containing at least one VGM Declaration.

2.2 GET scenarios for all required query parameter filters

These scenarios measure the conformance of VGM Producers who implement the GET endpoint and send out VGM Declarations in response to GET requests from VGM Consumers.

There is one scenario for each query parameter filter that VGM Producers are required to support.

• Supply parameters (CBR) + GET VGM Declaration

• Supply parameters (CBR+ER) + GET VGM Declaration

• Supply parameters (TDR) + GET VGM Declaration

• Supply parameters (TDR+ER) + GET VGM Declaration

• Supply parameters (ER) + GET VGM Declaration

The “supply parameters” action prompts the user to enter a JSON representation of the specified required query parameters filter that, when used by the sandbox in a GET request, would fetch from the adopter system the associated VGM Declarations.

For example, “Supply parameters (CBR+ER)” prompts the user to provide the carrier booking reference and the equipment reference to be used in building a GET request with those query parameters.

2.3. GET scenario for any optional query parameter filters

These scenarios measure the conformance of VGM Producers who implement the GET endpoint and send out VGM Declarations in response to GET requests from VGM Consumers.

There is a single scenario available, which can be used with any optional query parameter filter that VGM Producers can choose to support.

• Supply parameters + GET VGM Declaration

The “supply parameters” action prompts the user to enter a JSON representation of the query parameters filter that, when used by the sandbox in a GET request, would fetch from the adopter system the associated VGM Declarations.

In this generic optional scenario, the “Supply parameters” conformance action provides as part of the prompt a full set of query parameters that can be included, and starts with a default empty object in the input area, allowing users to specify any combination of query parameters. The synthetic VGM Consumer running in the sandbox sends a GET request built using the query parameters provided by the user.

3. Conformance Validations

Conformance reports contain the text of each relevant custom validation below, either with a ✅ or with a 🚫 depending on whether the validation succeeded or failed.

• Default validations (URL, response code, schema) are included.

• Custom validations: user-defined rule that checks specific business or data requirements on top of the default technical validations during conformance testing.

Custom validations must be identical for the GET and the POST scenarios.

Custom validations

• “At least one VGM Declaration must be included in a message sent to the sandbox during conformance testing”

• “At least one VGM Declaration must demonstrate the correct use of the ‘VGM’ object”

  • “The ‘VGM’ object within at least one VGM Declaration must demonstrate the correct use of the ‘weight’ object”

    • “The ‘VGM.weight’ object within at least one VGM Declaration must demonstrate the correct use of the ‘value’ attribute (positive number)”

    • “The ‘VGM.weight’ object within at least one VGM Declaration must demonstrate the correct use of the ‘unit’ attribute (‘KGM’ or ‘LBR’)”

  • “The ‘VGM’ object within at least one VGM Declaration must demonstrate the correct use of the ‘method’ attribute (‘SM1’ or ‘SM2’)”

• “At least one VGM Declaration must demonstrate the correct use of the ‘equipmentDetails’ object”

  • “The ‘equipmentDetails’ object within at least one VGM Declaration must demonstrate the correct use of the ‘equipmentReference’ attribute (not empty or blank)”

• “At least one VGM Declaration must demonstrate the correct use of the ‘shipmentDetails’ object”

  • “The ‘shipmentDetails’ object within at least one VGM Declaration must demonstrate the correct use of the ‘carrierBookingReference’ or ‘transportDocumentReference’ attribute (not empty or blank)”

• “At least one VGM Declaration must demonstrate the correct use of the ‘responsibleParty’ object”

  • “The ‘responsibleParty’ object within at least one VGM Declaration must demonstrate the correct use of the ‘partyName’ or ‘contactDetails.name’ attribute (not empty or blank)”

• “At least one VGM Declaration must demonstrate the correct use of the ‘authorizedPersonSignatory’ attribute (not empty or blank)”