Billable Item Class Lifecycle

Описание: The Three Configuration Statuses (Figure 46)
Figure 46 ("Configuration Status of Billable Item Class") shows these as three stages in a progression from left to right: In Processing → Transportable → Released as Productive. Each stage has specific characteristics regarding what changes are allowed and whether transport is possible.
Configuration Status: "In Processing"
This is the initial configuration status that the system sets automatically when a new billable item class is created. The course describes it as:
• All changes are allowed — you have complete freedom to add, remove, or modify interface components, customer fields, table sets, and any other configuration element
• No transport is possible — the configuration cannot be moved to another system
Significance: This is the sandbox stage where the BIT class is being designed. You can experiment freely, add and remove interface components, test different configurations, and make mistakes without any risk to other systems. The course's Exercise 3 confirms this: when the student creates BIT class TD##, the course notes "The new billable item class TD## has the configuration status 'In Processing'."
Example: Telcom One is designing a new BIT class for its "Data High Speed" product line. The configuration team is still deciding whether to include the Deferred Revenue interface component. At this stage, they can add it, test it, remove it, and add it again — all without affecting the test or production environments.
Configuration Status: "Transportable"
This is the intermediate stage. The course describes it as:
• All changes are still allowed — the same freedom as "In Processing"
• Transport is now possible — a transport order is offered, and the configuration can be moved to other systems
Significance: This status signals that the configuration is considered mature enough to be shared with other systems, but it is not yet locked down. The key distinction from "In Processing" is solely about transportability. The course explains the transport mechanism: "You can transport this Customizing data into a test system as soon as you change the status of the configuration to 'Transportable'. The transport connection is integrated as standard in the transaction for configuring billable item classes. The system ensures that only complete and consistent configurations are transported."
Example: The Telcom One team has finalized the interface component selection for BIT class TD## and wants to transport it to the quality assurance system for integration testing. They change the status to "Transportable," which triggers a transport request. The QA system receives the Customizing data and can then generate the actual database tables and function modules locally.
Configuration Status: "Released as Productive"
This is the final and most restrictive stage. The course describes it as:
• Configuration can be transported to other systems and generated
• Only compatible enhancements to the configuration are supported
The allowed enhancements are explicitly listed:
• Add new interface components
• Add new fields
• Add new storage tables for billed items
• Create new indexes
Significance: This is the most important status for production governance. Once a BIT class reaches "Released as Productive," destructive changes — such as removing interface components, deleting fields, or removing table sets — are no longer permitted. This protection exists because the BIT class is now assumed to have live data in production. Removing a field that contains data in millions of existing billable items would cause data loss and system inconsistencies. Only additive, non-breaking changes are allowed.
Additionally, the course notes a crucial auditing feature: "As soon as a class has the configuration status 'Released as Productive', the system writes a history of the active versions. You can use this history to see when changes were made to the configuration. You can view the history by choosing Display Configuration Versions." This version history provides a complete audit trail of every change made to the productive BIT class — essential for regulatory compliance and troubleshooting in high-volume billing environments.
Example: Telcom One's BIT class TDAT has been in production for six months, billing millions of data service CDRs. A new business requirement arises: the company now needs to support deferred revenue for prepaid annual subscriptions. Because TDAT is "Released as Productive," the team can add the Deferred Revenue interface component (a compatible enhancement). However, they cannot remove the existing Payment Card Data interface component, because existing billable and billed items depend on that structure.