Skip to main content
Version: 2.4

Ordering Module

In telecom, ordering is the business-control layer between customer demand and operational execution. It captures what the customer (or partner) requests, structures it into actionable order lines, and drives fulfillment processes.

In tSM, Ordering is a business module built on top of the same low-code platform patterns:

  • dynamic attributes in chars (TsmChars),
  • form-driven UI and validation,
  • process automation for fulfillment lifecycle,
  • public APIs and TM Forum aligned contracts.
Terminology Clarification
  • Order: commercial/business envelope for one request. It carries customer/account context, dates, status, and shared metadata.
  • OrderLine: executable unit inside an order (what to add/remove/update/move/takeover/link).
  • OrderType: configuration of order behavior (process selection, filtering, mnemonic generation, sorting).
  • OrderStatus: lifecycle state registry for orders (installation-specific values and transitions).

Business Capability Context​

From business perspective, an order creates a controlled precondition for realization of a commercial relationship.

In practice:

  • order is always linked to customer context, and can also be linked to contract and/or offer context,
  • orders are managed end-to-end (create, edit, track current status, audit history),
  • orders can be connected with related entities (contact, address, contract, product, offer),
  • orders can be searched by multiple criteria, historical changes can be reviewed, and result sets can be exported,
  • orders are workflow-driven to ensure required realization steps are executed,
  • activities can be created from orders and managed through activity calendar capabilities.

Product Order Business View in tSM​

Product order is created based on product offers defined in catalog and captures customer-specific requests over that offer baseline (dates, options, actions, location, parties, billing context).

tSM supports the full basic work cycle with product orders:

  • create and edit order,
  • track current state and history,
  • add products from product catalog,
  • optionally add services from service catalog (simplified service provisioning pattern),
  • link order to customer, contracts, contacts, addresses, billing, and related entities.

Common example lifecycle labels in deployments include:

  • NEW (Nová),
  • IN_PROGRESS (Rozpracovaná),
  • TECHNICAL_SURVEY (Technické šetření),
  • REALIZATION (Realizace),
  • COMPLETED (Ukončená),
  • CANCELLED (Zrušena).

Status sets and transitions are installation-specific and configurable. Entire order lifecycle is typically mapped to process orchestration.

TMF Business Semantics Snapshot​

  • Product Order (TMF622): order placed from product offer definitions in catalog. Main attributes typically include identifier, state, priority, category, dates, related billing account, related parties, and product order items.
  • Service Order (TMF641): order describing operations on services (one service order item per service). Item-level action describes operation such as add, change, terminate. Service order and items typically carry richer lifecycle states, dates, party references, and contact context needed for fulfillment.
  • Resource Order (TMF652): order describing operations on resources (resource-level implementation actions in fulfillment chains).

For item-level entities (order lines/items), key attributes typically include ordered offering/object, operation/action, lifecycle state, characteristics, and location or delivery context.

Focused TMF Order Types vs Fulfillment​

TM Forum separates focused order interfaces by domain concerns:

ConceptTMF APIFocus
Product OrderTMF622commercial request over product offer and product order items
Service OrderTMF641operational request over service operations (one service order item per service)
Resource OrderTMF652operational request over resource operations
Service ActivationTMF640 (adjacent activation/configuration domain)execution of activation/config changes during fulfillment

General Service Provisioning / Fulfillment is broader than any single API. It includes validation, decomposition, design, allocation, activation, field work, verification, and documentation.

Pragmatic tSM Operating Models​

tSM supports multiple operating models:

  1. ISP / small operator: one practical layer is often enough. Product catalog + single order + single process can cover business and technical execution.
  2. Telco operator: product catalog and service catalog may be distinct, but execution can still run under one provisioning order with separate product/service sections.
  3. Tier-1 operator: full BSS/OSS split is common (often separate deployments, teams, SLAs/KPIs, and responsibility boundaries). Even with a strict deployment split between product and service layers, tSM can run a dedicated tsm-service-ordering microservice for service orders and fulfillment processes. This service is a specialization of the general tsm-ordering microservice: it derives the base order model and APIs, and extends them with specialized provisioning and activation methods. See Specialization pattern.

Scope and Responsibility​

Ordering is responsible for:

  • capturing and storing order header data (OrderPublic),
  • maintaining line-level execution units (OrderLinePublic),
  • linking lines to catalog definitions (entityCatalogSpecificationId) and runtime inventory (entityInstanceConfigurationId),
  • governing lifecycle through configurable order type/status code tables,
  • triggering and coordinating process execution for fulfillment.

Downstream modules typically involved are Catalog, Inventory, Service Orchestration, WFM, Billing, and CRM.

Detailed Subdocuments​

Configuration Model​

Ordering follows the tSM configuration-first approach:

  • dynamic business attributes are stored in chars,
  • order semantics are parameterized by OrderType and OrderStatus,
  • process execution is selected from configuration (defaultProcessExpr, catalog-driven process codes),
  • standard fields are extensible by processingData for transient processing context.

In practice:

  1. configure OrderType and OrderStatus registries,
  2. configure forms and characteristic schemas for order/order-line context,
  3. bind order types to process logic,
  4. execute and monitor order lifecycle through status and process state.

TM Forum Governance​

Ordering aligns to TM Forum ordering domains:

  • TMF622 Product Ordering for product-order interactions,
  • TMF641 Service Ordering for service-order interactions,
  • TMF652 Resource Ordering for resource-order interactions,
  • cancel-task patterns via CancelProductOrder, CancelServiceOrder, and CancelResourceOrder resources.

Activation and configuration execution is adjacent to ordering and commonly mapped through service activation patterns (for example TMF640 scope).

tSM applies pragmatic alignment: TMF payloads are external contracts, while Order* entities remain the internal system-of-record model.