Skip to content

docs(0012): add extension to business partner relations#322

Draft
nicoprow wants to merge 1 commit into
catenax-eV:mainfrom
nicoprow:docs/standards/0012/relation-updates
Draft

docs(0012): add extension to business partner relations#322
nicoprow wants to merge 1 commit into
catenax-eV:mainfrom
nicoprow:docs/standards/0012/relation-updates

Conversation

@nicoprow
Copy link
Copy Markdown

@nicoprow nicoprow commented May 21, 2026

Summary

This PR extends the CX-0012 standard to align it with relation features already shipped in the reference implementation (Eclipse Tractus-X BPDM 7.x). Four additions are bundled together because they form a coherent model: new relation types, a new address-level relation concept, and the supporting validity period and reason code structures that apply to all relations.

Changes

New legal entity relation type: IsOwnedBy

Added alongside IsAlternativeHeadquarterFor and IsManagedBy. It represents a majority ownership stake of the legal entity target over the legal entity source (e.g. a parent company owning a subsidiary). The same acyclicity constraint as IsManagedBy applies — only one level of ownership is representable. Like IsManagedBy, it has no effect on data exchange in the current standard release and MAY only be used for hierarchy management.

Address Relations

Addresses can now carry directed relations to other addresses, structurally parallel to legal entity relations. The first relation type is IsReplacedBy: a former legal address (source) has been succeeded by a new legal address (target) due to a headquarter relocation. The source address may remain active as an additional address — there is no requirement for it to become inactive as a result of this relation.

Validity Periods on all relations

All relations (legal entity and address) now carry a non-empty list of validity periods, each with a Valid From date and an optional Valid To date. Three constraints apply: at least one period is required, Valid From must not be after Valid To, and multiple periods of the same relation must not overlap.

Reason Codes on all relations

All relations optionally reference a reason code by its technical key, providing human-readable context for why the relation exists. The standard places no restriction on which reason codes are available or whether different sets apply to different relation types. The reason code catalogue is a read-only reference list managed by the Pool implementation and exposed via the required GET /reason-codes metadata endpoint.

Motivation

The reference implementation has supported these relation features since BPDM 7.x. Without this update, implementations conforming strictly to the standard text could not represent majority ownership hierarchies, could not model address succession on headquarter relocations, and had no standardised way to qualify when and why a relation holds.

Change Request

https://github.com/catenax-eV/product-standardization-prod/issues/666

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant