Skip to main content
Version: 2.4

Inventory Module

In telecom, inventory is the operational register of what is actually running in the network and customer base now, what is planned next, and what existed in the past.

In tSM, this module is the runtime control layer for:

  • product instances (commercial view, aligned to TMF637),
  • service instances (CFS/RFS operational view, aligned to TMF638),
  • resource instances (technical/network asset view, aligned to TMF639),
  • and other domain types represented through the same generic EntityInstance model.

Catalog defines what may exist (Specification, relationships, characteristics, lifecycle rules). Inventory stores what does exist at runtime, as configured from that catalog design.

Terminology Clarification
  • EntityInstance: Entity means Product, Service, Resource, and other domain objects. Instance clarifies this is runtime inventory data, not catalog design.
  • EntityInstanceConfiguration: configuration in time. It captures how one instance looks at a specific point in lifecycle (draft, pending, current, history).
  • EntityCatalogSpecification (also shortened to Specification): Entity means Product/Service/Resource/etc. Catalog means design-time definition, opposite to runtime instance. Specification means it defines expected behavior, structure, and rules of the instance.

The term Service is heavily overloaded in telecom. In this documentation, always distinguish service as design (Specification in Catalog) from service as runtime (EntityInstance + EntityInstanceConfiguration in Inventory).

From architecture perspective, Inventory is a business module built on top of the same low-code platform patterns:

  • dynamic runtime attributes in chars,
  • configurable forms and profiles,
  • process and script automation for lifecycle transitions,
  • public APIs and TM Forum aligned contracts.

Scope and Responsibility​

Inventory is responsible for:

  • persistent identity of runtime objects (EntityInstance),
  • time-aware runtime snapshots (EntityInstanceConfiguration),
  • explicit runtime links between configurations (EntityInstanceConfigurationRelationship),
  • runtime status governance (EntityInstanceConfigurationStatus),
  • optional runtime cost lines (EntityInstanceConfigurationCost).

Downstream and adjacent modules (Order, Service Orchestration, Ticketing, Billing, CRM) consume or update these runtime entities.

Detailed Subdocuments​

Configuration Model​

Inventory follows the same tSM characteristics pattern used across business modules:

  • runtime attributes are stored in chars (TsmChars) on configuration entities,
  • UI and validation are driven by configuration profiles and forms,
  • status governance is code-table driven,
  • lifecycle and validity are time-bound and auditable.

In practice:

  1. define/validate design-time specifications in Catalog,
  2. create and evolve runtime inventory configurations aligned to those specifications,
  3. control transitions between pending/current/history,
  4. expose normalized runtime state through APIs and integrations.

TM Forum Governance​

Inventory module aligns to TM Forum inventory API domains:

  • TMF638 Service Inventory,
  • TMF637 Product Inventory,
  • TMF639 Resource Inventory.

tSM applies pragmatic alignment: TMF payloads are integration projections, while EntityInstance* entities remain the system-of-record model internally.