Skip to main content
Release: 24.03 (deprecated)

CX - 0046 Demand and Capacity Management Process and Core Business Logic v1.0.0

DISCLAIMER REGARDING DEMAND AND CAPACITY MANAGEMENT DATA EXCHANGE

This document describes and standardizes certain data exchange business processes, data models and/or APIs in connection with cross-company demand and capacity management (DCM) based on the Catena-X data ecosystem. Nothing in this document is meant to determine the contractual terms and conditions for the purchase, supply, delivery or licensing of any products or services among the participants of the DCM data exchange. These terms and conditions are separately negotiated and agreed among suppliers and customers in individual purchase, supply or license agreements. In case of any inconsistencies with the content of this document, the provisions of individual agreements among the participants shall prevail over the content of this document.

ABSTRACT

Resilience has become an imperative within Supply Chain Management especially over the past years. Disruptions of global Supply Chains in terms of material availability but also from logistics perspective during the SARS-CoV-2 crisis showed the need for additional countermeasures and technologies with regards to resiliency. Inside the volatile and highly complex surrounding of the automotive industry, several interfaces of individual IT-solutions exist inside and between the multiple players along the value chain. There is no common understanding of the process established across all the partners. Demand and Capacity Management (DCM) focuses on the exchange of demand and capacity data between a customer and a supplier.

The purpose of this document is to outline a common understanding of relevant processes and data for a one-to-one business relationship in the context of DCM and prepare a baseline for a more efficient and proactive collaboration.

Companies need this common understanding to enable an exchange of the related data across different business partners and their systems.

This document is meant to describe the data exchange and a common core business logic to interpret them, thereby following the same approach for all partners involved in the DCM process.

The core business logic MUST be implemented in applications participating in the process and enabling the exchange of data between the partners involved in DCM.

1. INTRODUCTION

1.1 AUDIENCE & SCOPE

This section is non-normative

This document addresses the following actors:

  • Data Provider / Consumer
  • Business Application Provider

For a better understanding of the roles and responsibility of each actor, please refer to chapter 2.2

The following regulations are in scope of the standard description:

All actors (Data Providers, Data Consumer, Business Application Providers) MUST follow Catena-X standards with regards to:

NumberStandard
CX-0001EDC Discovery API, Version 1.0.1 (see chapter 2.8)
CX-0003SAMM Aspect Meta Model, Version 1.0.1
CX-0006Registration and initial onboarding, Version 1.1.1
CX-0010Business Partner Number (BPN), Version 1.0.1
CX-0015IAM & Access Control Paradigm, Version 1.0.1
CX-0047Demand and Capacity Management Data Models, Version 1.0.0
CX-0048Demand and Capacity Management APIs, Version 1.0.0

To run the DCM process, customers and suppliers depend on accurate planning capabilities, as well as the ability to quickly adapt to changes.

Standardization of data and methods in DCM means that data consumers, data providers or business application providers MUST adopt a consistent core business logic to enable an interoperable data exchange.

This document refers to a direct one-to-one business relationship between two parties (customer & supplier). Further relationships and collaboration in an extended supply chain and/or a network will be part of future standardization packages.

DCM focuses on a tactical future horizon where demand and capacities can be managed (for details refer to chapter 2.5).

How customers or suppliers calculate their respective demand or capacity data is excluded from this standardization. Derivation of measures in the respective companies is excluded, too.

Visuals/pictures as well as actors and their roles are used to exemplify concepts or processes and are not intended for mandatory use.

1.2 CONTEXT

This section is non-normative

DCM is a critical aspect of Supply Chain Management, as it impacts the ability of suppliers to meet customers' demand while controlling costs. Effective DCM requires a balance between forecasting demand, optimizing production capacity and managing inventory levels to quickly adapt to changes.

The core business logic described in this document enables companies to share data in a sovereign way as well as to utilize a common process understanding, ensuring interoperability and enabling the involved parties to achieve the following goals:

  • early identification of upcoming potential bottlenecks, as well as surplus capacity
  • better monitoring and control of resources and facilities
  • collaboration and decision-making between supplier and customer in order to resolve bottleneck or surplus situations
  • enabling automation of processes
  • improvement of efficiency and accuracy

1.3 ARCHITECTURE OVERVIEW

This section is non-normative

Not applicable.

1.4 CONFORMANCE

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY, MUST, MUST NOT, OPTIONAL, RECOMMENDED, REQUIRED, SHOULD and SHOULD NOT in this document document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

1.5 PROOF OF CONFORMITY

This section is non-normative

All participants and their solutions will need to proof, that they are conform with the Catena-X standards. To validate that the standards are applied correctly, Catena-X employs Conformity Assessment Bodies (CABs). Please refer to: [!LINK Conformity Assessment] for the process of conformity assessment and certification.

Any actor participating in the Catena-X DCM use case, MUST implement and follow the following standards:

  • The DCM core business logic – described in this standard
  • The DCM standardized API – described in the [CX-0048] standard
  • The DCM standardized Data Models – described in the [CX-0047] standard

Please be aware that dependent on the process step, different (sub-) standards may be relevant. For instance, when exchanging material demands information, only the standard API MaterialDemand as well as the standardized data model for WeekBasedMaterialDemand are relevant.

In case of exchange of capacity information, the same logic is relevant (I.e. only the standard API for CapacityGroup as well as the standardized data model for WeekBasedCapacityGroup MUST be used).

1.6 EXAMPLES

Any application provider that develops DCM solutions has to grant the fulfillment of these requirements:

  • The solution has been designed to specify requirements for a trusted usage environment (e.g. identity verification and /or verification process),
  • The solution is designed to require a contractual agreement in compliance with antitrust requirements in the usage environment (e.g. data contracts as a prerequisite for carrying out a data exchange). For reference see Chapter 2.8 and follow EDC guidelines in [CX-0018]. Both customer and supplier agreed upfront to share data related to DCM.
  • The solution has been designed to limit visibility and/or access to concrete data content as much as possible (e.g. data offer does not yet allow data access).
  • The solution has been designed to require the implementation of notice and/or acknowledgement concepts to raise awareness of antitrust issues during use (e.g. helpdesk or pop-up info).
  • The solution has been designed to ensure traceability/reconstructability of processes through appropriate documentation and at the same time data sovereignty over concrete data content (e.g. through access, deletion or destination rights).

Any customer and supplier in the DCM process (I.e. data provider and/or data consumer) MUST fulfil following requirements:

  • Each application enabling and/or participating in the exchange of data as part of the damand and capacity management process MUST implement the core business logic defined in Chapter 2.
  • Standardization of data and methods in DCM means that data consumers, data providers or business application providers MUST adopt a consistent core business logic as defined in Chapter 2 to enable an interoperable data exchange.
  • Customer and supplier are in a contractual relationship with each other and agree to share data related to DCM
  • Access authorization to a DCM solution and to its related data will be self-managed by the customer and supplier companies themselves.
  • Customer and supplier MUST be technically able to apply these EDC policies in order to enable a secure collaborative data exchange
  • Customer and supplier MUST follow the antitrust requirements
  • Customer and supplier MUST agree on a common unit of measure (see Table 1 in ANNEXES) defined at product level to be used for data exchange purposes (e.g. demand & capacities)
  • Both parties are technically able to participate within the DCM process.
  • The supplier MUST be able to receive the material demand from the customer.
  • The customer owns and MUST publish its own demand with its supplier for the future horizon and it is highly RECOMMENDED to avoid any gaps as far as possible and to share demand data at least till month 9, to ensure DCM participants to have also sufficient demand data to work with.
  • Demand quantities refer to a period of one calendar week (weekly buckets)
  • Demands MUST be considered that are not yet fixed, but related to "opportunities" (e.g. projects) that will realistically materialize as single-orders
  • Demand data & quantities MUST refer to one of the categories defined in the table in chapter 2.5.1 of this document
  • Demand MUST be consistent with other exchanged data, e.g. call-offs/scheduling agreements
  • Material demands data MUST be updated and provided to supplier, whenever changes apply
  • The supplier owns and MUST publish capacity data to the customer, referring to material demand data shared
  • Capacity information MUST be used as follows:
    • the "actual capacity" is the planned available capacity of a supplier
    • and the "maximum capacity" is the maximum releasable capacity of a supplier (it MAY be equal or MAY be larger than the "actual capacity" but MUST NOT be smaller than actual capacity)
    • When the maximum capacity is larger than the "actual capacity", the difference is called "flexible capacity".
  • The customer MUST be able to receive the capacity group incl. the capacity information.
  • The supplier that uses the capacity group MUST link at least one material demand information to it, however often several material demand information are linked. This builds up the foundation to reflect the corresponding capacity situation of the supplier.
  • The aspect model WeekBasedCapacityGroup MUST be used by a supplier to provide capacity information to the customer.
  • Based on the aspect model WeekBasedCapacityGroup and WeekBasedMaterialDemand, both supplier and customer MUST apply the matching logic defined in Chapter 2.7 to ensure a common interpretation of the data.
  • Business application provider, data provider or data consumer MUST enable their DCM system to recognize the matching situation based on the table below and MUST be able to interpret the matching result accordingly.

1.7 TERMINOLOGY

This section is non-normative

TermDescription
Capacity1) The capability of a system to perform its expected function. 2) The capability of a worker, machine, work center, plant, or organization to produce output per time period. (Source: ASCM Supply Chain Dictionary, 17th edition)
Capacity GroupThe capacity group is the functional entity where material demand and capacity information are matched and compared for the purpose of a collaborative DCM.When the term is written as one word (WeekBasedCapacityGroup), the term refers specifically to the respective aspect model.
Actual Capacityis the planned available capacity of a supplier, which should be approximately realistic to achieve a material output per calendar week with a certain unit of measurement for one customer. The actual capacity is based on the supplier's assessment of its own capabilities and/or inventories as well as known commitments.
Maximum CapacityIs the maximum releasable capacity of a supplier which SHOULD be possible to achieve a material output per calendar week with a certain unit of measurement for one customer. The maximum capacity is based on temporary, capacity-increasing measures, agreed by the parties involved. Capacity-increasing measures can be, for example, a longer utilization of the available production resources, a shift extension or additional shifts. Secondarily, additional resources can also be activated.
Supplier Flex CapacitySupplier Flex Capacity = Difference/Area between maximum capacity and actual capacity.Available flex capacity is indicated if the actual capacity still below the maximum capacity. Flex Capacity describes the remaining ability to apply capacity-increasing measures that needs no additionally agreement upon the parties involved. In particular, measures to extend the weekly utilization of the available production resources come into question.
Calendar WeekA calendar week refers to all 7 days of a week. The counting of the calendar week within a year is based on the Thursday and starts at one ("1") with the week whose Thursday is first in the current year. Example: Week 1 of 2026 = Mon: 29 December 2025, Thu: 01.01.2026, Sun: 4.1.2026.
(Material) demandA need for a particular product or component. The demand could come from any number of sources (e.g., a customer order or forecast, an interplant requirement, a branch warehouse request for a service part, or the manufacturing of another product). At the finished goods level, demand data is usually different from sales data because demand does not necessarily result in sales (i.e., If there is no stock, there will be no sale (Source: ASCM Supply Chain Dictionary, 17th edition).Material demand may comprise multiple demand time series by location and demand categories.When the term is written as one word (WeekBasedMaterialDemand), the term refers specifically to the respective aspect model.
BottleneckA facility, function, department, or resource whose capacity is less than the demand placed upon it. For example, a bottleneck machine or work center exists where jobs are processed at a slower rate than they are demanded (Source: ASCM Supply Chain Dictionary, 17th edition)
Surplus (capacity)A situation in which an oversupply exists (Source: ASCM Supply Chain Dictionary, 17th edition). For example, a machine or work center exists where jobs could be processed, but demand does not require them.

Additional terminology used in this standard can be looked up in the glossary on the association homepage.

2 MAIN CONTENT

This section is normative

2.1 Contextual Description

The DCM process REQUIRES the following fundamental steps:

  • Material demands made available by a customer
  • Capacities made available by a supplier
  • Capacity groups created as an entity, where material demands and capacities are matched and compared
  • A business application that supports the fundamental steps above mentioned

The data required to run these steps MUST be always up-to-date and shared among involved partners in a direct business relationship (customers and suppliers) in order to enable a comparison process and start the collaborative approach, in case of need – for details see Chapter 2.7

2.2 Actors and Roles

The DCM core business logic considers three general actors: the customer, the supplier and the business application provider. Please be aware, that an individual business partner may have several direct one-to-one business relationships in which he will act in different roles. For instance, in one to one business relationship the business partner may act in the role of a customer of his suppliers. In a different business relationship, he may act as a supplier to his customers. All actors might have different role titles, depending on their respective organizational structures. However, all have specific responsibilities and requirements:

ActorsDescription
Customeris a business partner that provides a demand forecast to and receives goods from his supplier. As such, a customer is responsible for providing consistent and up-to-date demand and this role is also a data consumer in regard to capacity data.
Supplieris a business partner that supplies goods to a customer. As such, a supplier is responsible for providing consistent and up-to-date capacity and this role is also a data consumer in regard to demand data.
Business application provideris a party that provides and operates an application / tool which enables demand and capacity management and follows the core business logic and other standards as described in this document.

Examples of typically impacted roles on customer side are:

  • Demand Planner
  • Supplier Capacity Manager
  • Logistic Planner/Manager
  • Buyer

Examples of typically impacted roles on supplier side are:

  • Production / Supply Planner
  • Demand Planner
  • Product Manager
  • Sales Manager/Customer Service

Examples of typically impacted roles on business application provider side are:

  • Solution / Product Manager
  • Developer
  • System Architect
  • Operations Manager / Responsible
  • Support Engineer

2.3 Process Representation

Figure.1.png Figure 1: Process Chart DCM

Process details can be retrieved in Annex Figures.

2.4 Prerequisites for a Collaborative Demand and Capacity Management

The following functional prerequisites MUST be met before starting data exchange:

  • Customer and supplier are registered in the Catena-X network and follow the Catena-X guidelines
  • Customer and supplier are in a contractual relationship with each other. Among other things, they MUST agree on a common unit of measure (see Annex Tables) defined at product level to be used for data exchange purposes (e.g. demand & capacities)
  • Both parties are technically able to participate within the DCM process with their respective business application

Based on these prerequisites, the exchange of demand and capacity data is enabled.

2.5 Provisioning Demand Data to Supplier

2.5.1 Detailed Description of Demand

A customer provides demand data and respective changes to the supplier, who is responsible for producing/manufacturing and delivering the material to the customer. Thereby, the customer is acting as a data provider and the supplier as a data consumer of the exchanged material demand.

The supplier MUST be able to receive the material demand from the customer.

A demand reflects the need for a particular product or part or component for a certain period of time.

The customer owns and MUST publish its own demand with its supplier for the future horizon and it is highly RECOMMENDED to avoid any gaps as far as possible and to share demand data at least till month 9, to ensure DCM participants to have also sufficient demand data to work with.

If more demand data is available (i.e. demand related to a horizon that spans beyond month 9), the customer MAY ideally provide them until month 24. If a customer has even more demand data available (i.e. demand related to a horizon that spans beyond month 24), he MAY also provide this to his supplier.

The data series MAY start already from week n+2.

Although the data series MAY start already from week n+2 and can be elaborated from a technical perspective, the DCM process have a clear focus on the tactical mid- to long-term horizon (typically considered from month 4 to 24) to enable a more resilient supply chain.

For further technical details refer to chapter "2.2.2 Data Exchange" of the API standard [CX-0048]

CustomersMUST follow the below mentioned guidelines (to be applied along the entire Supply Chain) to deliver real demand data with high qualityand enable an efficient demand vs. capacity comparison:

  • Demand quantities MUST refer to a period of one calendar week (weekly buckets)
  • Demands MUST be considered that are not yet fixed, but related to "opportunities" (e.g. projects) that will realistically materialize as single-orders

Figure.2.png Figure 2: Visualized example for Demand Data*

  • Demand data & quantities MUST refer to one of the categories defined in the following table:
Demand CategoryDescriptionDemand Category Code** (Based on Data Model)**
DefaultNo Assignment0001
After-SalesAfter sales demand of spare partsA1S1
SeriesDependent demand e.g. production, assembly, raw materialSR99
Phase-In-periodRamp up of a new product or new material introductionPI01
Single-OrderDemand outside the normal spectrum of supplyOS01
Small seriesShort time frame for demand and pose to higher volatilityOI01
Extraordinary demandTemporary demand on top of standard demandED01
Phase-Out-periodRamp down. Product or material retires from the market.PO01
  • Demand MUST be consistent with other exchanged data e.g. call-offs/scheduling agreements
  • Material demands data MUST be updated and provided to supplier, whenever changes apply

For technical details for implementing these demand categories refer to [CX-0047].

Further guidelines MAY apply:

  • Updating of demand data SHOULD be carried out at least once a month at a certain date or point in time during the month
  • Unnecessary demand fluctuation SHOULD be avoided or limited, because a stable demand plan enables better capacity planning

2.5.2 Material Demand Structure

A material demand data set consists of information about the material itself and the related customer vs. supplier relationship and more detailed information about the requested quantities per time period (demand series).

The picture below illustrates the material demand structure in a simplified way:

Figure.3.png Figure 3: Simplified Material Demand Structure

For further details refer to the semantic model standard document CX-0047 DCM Data Model MaterialDemand & CapacityGroup.

In the next picture it is exemplified how the different material demand information MAY be visualized, whereas the data can be differentiated between "header data" and "time series data" :

Figure.4.png Figure 4: Visualized example of a material demand structure

2.5.3 Data Model Week Based Material Demand

For a detailed description of the material demand attributes and material demand series, please refer to the [CX-0047] and [CX-0048] standards.

2.6 Provisioning Capacity Data to Customer

2.6.1 Detailed Description of Capacity Data

The supplier MUST publish capacity data to the customer, referring to material demand data shared. Thereby, the supplier is acting as a data provider and the customer as a data consumer of the exchanged capacity group.

The customer MUST be able to receive the capacity group incl. the capacity information.

Capacity information MUST be used as follows:

  • the "actual capacity" is the planned available capacity of a supplier
  • and the "maximum capacity" is the maximum releasable capacity of a supplier (it MAY be equal or MAY be larger than the "actual capacity" but MUST NOT be smaller than actual capacity)
  • When the maximum capacity is larger than the "actual capacity", the difference is called "flexible capacity".

For further technical details refer to chapter "3.2.2 Data Exchange" of the API standard [CX-0048].

For a detailed description of these capacity definitions please refer to TERMINOLOGY.

The picture below illustrates and exemplifies:

  • The black line illustrates the actual capacity
  • The dotted grey line illustrates the maximum capacity
  • The difference between the two lines is understood as "flexible capacity"

Figure.5.png Figure 5: Visualized example of Capacity Data

2.6.2 Capacity Group structure

The capacity group is the entity where material demand and capacity information are matched and compared for the purpose of a collaborative DCM. Thereby, the capacity group builds the common view on the data exchanged with each other. The entity capacity group MAY be used, for example, as a means to combine capacities related to one or more machines, facilities or plants.

The supplier that uses the capacity group MUST link at least one material demand time series information to it, however often several material demand information are linked. This builds up the foundation to reflect the corresponding capacity situation of the supplier.

Figure.6.png Figure 6: Visualized example for possible assignments of material demand time series to capacity groups

This functional capacity group is technically handled via the so-called aspect model WeekBasedCapacityGroup.

The aspect model WeekBasedCapacityGroup MUST be used by a supplier to provide capacity information to the customer.

For further details refer to the semantic model standard [CX-0047].

Figure.7.png Figure 7: Simplified WeekBasedCapacityGroup structure

Data is exchanged via two different aspect models (WeekBasedMaterialDemand and WeekBasedCapacityGroup) between two partners. A partner with role of supplier could send a capacity group to his partner in role of customer and it is important to understand on which data elements the linked demand series in the capacity group MUST be included in the solution of the customer to ensure that the same demand series are considered:

  • supplier
  • customer
  • CustomerMaterialNumber
  • customerLocation
  • DemandCategory

In case there is no (complete) matching of data between supplier and customer it is highly recommended to start collaboration outside the business application.

2.6.3 Data Model Week based Capacity Group

For a detailed description of the capacity group attributes and data, please refer to the [CX-0047] and [CX-0048] standards.

2.7 Comparison of Demand and Capacity Data within a Capacity Group

Based on the aggregated demands, the capacity data will be matched, and a comparison started. This approach allows partners to timely identify imbalances (e.g. demands are higher than capacities and/or demands are lower than capacities) and facilitates solving those imbalances, utilizing the already shared data. The following picture exemplifies this process:

Figure.8.png Figure 8: Process Chart DCM

2.7.1 Matching Results and Resolution

Based on the WeekBasedCapacityGroup and WeekBasedMaterialDemand aspect models, each supplier and customer MUST apply the same logic when comparing the demand with the corresponding capacity values to ensure that the matching results are interpreted in the same way.

For a better understanding the table below describes all scenarios that may apply in a business context.

Business application provider, data provider or data consumer MUST enable their DCM system to recognize the matching situation based on the table below and MUST be able to interpret the matching result accordingly. The DCM system MAY visualize the matching result in a respective color as well, based on the example below.

ScenariosMatching situations (MUST)Matching result (MUST)Color coding for example picture below (MAY)
1Demand > actual capacity (only in case no maximum capacity is applied)Bottleneck is identifiedred
2Demand > maximum capacityBottleneck is identifiedred
3Demand > actual capacity < maximum capacityBottleneck is identifiedred
4Demand = actual capacity = maximum capacityZero deviationgreen
5Demand < actual capacitya surplus capacity is identifiedgreen
6Demand = actual capacity < maximum capacityZero deviationgreen

For a better understanding of how this can be displayed in a DCM system, we provide the example below, even if it is not exhaustive.

Figure.9.png Figure 9: Visualized example of Demand and Capacity Data Matching and Comparison

In case a bottleneck or surplus is identified, a DCM collaborative alignment between customer and supplier is highly RECOMMENDED.

2.8 EDC Policies

A central part of managing business partner relationships within Catena-X is the definition and appliance of EDC policies, which enable and protect data exchange. Customer and supplier MUST be technically able to apply these policies in order to enable a secure collaborative data exchange.

DCM relies on the following policies:

CategoryPolicy NameDescriptionVariables
Access PolicyLimit access to the data offered to a list of specified BPNs (to the connectors with the BPN attribute listed in the policy)This and any other policy which are based on attributes stored in DAPS can be enforced by the connector. So, if a connector is registered in DAPS with attributes such as BPN, Recycler, Germany, an access policy based on any combination of these attributes can be defined and technically enforced by the EDC
Access PolicyCountry-restricted Data UsageThe usage of the data is only allowed in a specific country.ISO Country Code as defined in [ISO3166]
Usage PolicyDuration-restricted data policyThis policy specifies for how long the data contract is valid. After the expiry of the data contract, no data exchange under the conditions of this contract can take place. Since the connector is aware of when the contract was electronically signed, it can monitor the validity period and can invalidate the contract.
Usage PolicyRole-restricted data policyThese are the policies that require each use case to define their own set of "roles" such as quality engineer etc. These policies can only be enforced by the consumer applications. Note: keep in mind that this policy is different from any future access policy(ies) that would rely on a role of a company (such as Recycler). These roles, just like the BPN-based access policy, can be enforced by the connector
Usage PolicyPurpose-restricteddata policyThese are the policies that require each use case to define their own set of "purposes" such as "CO2 emissions" etc. These policies can only be enforced by the consumer applications.
Usage PolicyDeletion Usage PolicyThe data is deleted after a specific time of access / usage. One has to keep in mind that the consumer cannot be expected to delete all potentially effected data backups or database recovery systems.
Modification DataModify Data (in Transit)Prohibits data modification in transit. There might be cases where data MUST be modified or e.g. partially anonymized before it is allocated to the user. The data modification MUST be done before permission to use the data is granted.
ModificationModify Data (in Rest)Prohibit data modification in rest. It demands the modifications to be done when data is stored, for example in a database. The Data Consumer is only allowed to use the data after certain modifications have been applied to the stored data.

3 REFERENCES

3.1 NORMATIVE REFERENCES

[CX-0001] EDC Discovery API, Version 1.0.1

[CX-0003] SAMM Aspect Meta Model, Version 1.0.1

[CX-0006] Registration and initial onboarding, Version 1.1.1

[CX-0010] Business Partner Number, Version 1.0.1

[CX-0015] IAM & Access Control Paradigm, Version 1.0.1

[CX-0018] Eclipse Data Space Connector (EDC), Version 1.0.1

[CX-0047] Demand and Capacity Management Data Models, Version 1.0.0

[CX-0048] Demand and Capacity Management APIs, Version 1.0.0

3.2 NON-NORMATIVE REFERENCES

[ISO3166] ISO 3166 Country Codes

3.3 REFERENCE IMPLEMENTATIONS

This section is non-normative

Not applicable.

ANNEXES

FIGURES

This section is non-normative

Following figures describes the complete DCM process, with respect to main actors/roles and responsibilities.

Figure.Annex.png

TABLES

This section is non-normative

  1. Unit of Measure
DimensionUN CodeDescription (English)Description (German)UN SymbolC-X Symbol
MassGRMgramGrammgg
MassKGMkilogramKilogrammkgkg
MassTNEmetric tonMetrische Tonnett
MassSTNton (US) or short ton (UK/US)US Tonneton (US)ton
MassONZounceUnzeozoz
MassLBRpoundPfundlblb
LengthCMTcentimetreZentimetercmcm
LengthMTRmetreMetermm
LengthKTMkilometreKilometerkmkm
LengthINHinchZollinin
LengthFOTfootFußftft
LengthYRDyardYardydyd
AreaCMKsquare centimetreQuadrat-zentimetercm2cm2
AreaMTKsquare metreQuadratmeterm2m2
AreaINKsquare inchQuadratzollin2in2
AreaFTKsquare footQuadratfußft2ft2
AreaYDKsquare yardQuadratyardyd2yd2
VolumeCMQcubic centimeterKubikzentimetercm3cm3
VolumeMTQcubic meterKubikmeterm3m3
VolumeINQcubic inchKubikzollin3in3
VolumeFTQcubic footKubikfußft3ft3
VolumeYDQcubic yardKubikyardyd3yd3
VolumeMLTmillilitreMillimetermlml
VolumeLTRlitreLiterll
VolumeHLThectolitreHektoliterhlhl
QuantumH87pieceStück-pc
QuantumSETsetSatz-set
QuantumPRpairPaar-pr
QuantumZPpageBlatt-pg
MechanicKWHkilowatt hourKilowattstundekW·hkwh
(blank)xxx

Copyright © 2024 Catena-X Automotive Network e.V. All rights reserved. For more information, please visit here.