Naming Conventions

Overview

The tSM platform enforces consistent naming conventions to ensure clarity and integration across the system. Every configuration entity is identified by three elements:

• ID: An internal UUID, generated automatically (not visible on the UI).
• Code: A structured, human-readable identifier used in APIs and configurations. This is often partly created by the configurator.
• Name: A descriptive label provided by the configurator, which forms the basis for the Code.

Hierarchy & Associated Configurations

• Hierarchical Naming:
  Related configurations share common prefixes. For example, all internet order types in the Residental segment should start with: Residental / Internet /

• Associated Configurations:
  Primary entities (e.g., Order Type) often have related setups (e.g., Configuration Profile, Processes, Forms). They inherit the main entity’s name with an added module prefix to clearly identify their role.

• User Configured Registers:
  Each register has an associated form for data entry and a listing definition, using similar naming patterns.

Naming Playground

Try the interactive playground below to see these naming rules in action. Enter a concise name and module to preview the generated Code and associated naming for related configurations.

Naming Tester

Module: Ord - OrderCust - CustomerAcc - AccountTck - TicketConf - ConfigurationForm - FormProc - Process

Type Name: 

Typ Entity	Title	Code
Order Type	Residental / Internet / Soft suspend	Residental.Internet.SoftSuspend
Configuration Profile	Order / Residental / Internet / Soft suspend	Ord.Residental.Internet.SoftSuspend
Form New	Order / Residental / Internet / Soft suspend - Form New	Ord.Residental.Internet.SoftSuspend_Form.New
Form Detail	Order / Residental / Internet / Soft suspend - Form Detail	Ord.Residental.Internet.SoftSuspend_Form.Detail
Process	Order / Residental / Internet / Soft suspend	Ord.Residental.Internet.SoftSuspend

Shared vs. Dedicated Entities

Some entities, such as characteristics, may be used across multiple configurations. The naming strategy differs based on their intended use:

• Shared Entities:
  These are used by various configurations (e.g., Ticket, Order). They should have a general naming that does not include a module-specific prefix.

• Dedicated Entities:
  If an entity (like a characteristic) is meant to be used solely with one type of configuration, its name should be prefixed with the associated module type (e.g., Ord for Order) to indicate its dedicated usage.

Since it is not always clear at creation time whether an entity will be shared or dedicated, use common sense and standard guidelines to determine the most appropriate naming.

Code Generation Rules

When you enter a concise name, the system auto-generates the Code by:

1. Removing Accents & Trimming: Converts accented characters to ASCII and removes extra spaces.
2. Normalizing Punctuation: Replaces any sequence of dots (.), dashes (-), slashes (/), or underscores (_) with a single dot (.).
3. Removing Special Characters: Eliminates characters other than letters, digits, spaces, and dots.
4. CamelCase Conversion: Splits the cleaned string into segments (by dots), converts each word to CamelCase, and rejoins them with dots.

This process ensures that the generated code is:

• Structured: Reflecting the hierarchy and related configuration,
• Readable: Clearly showing the entity’s purpose,
• Consistent: Following the same rules across all modules.