There is no limit to the number of steps you can include in a billing schema. In principle you can create a billing schema with any number of steps. Very large billing schemas are firstly difficult to maintain, and secondly have a negative influence on the performance of billing.
Maintenance:
In principle, you can include all the rates for a joint division and billing class in the same schema. However, SAP recommends that you create billing schemas with a maximum of a few hundred steps. Smaller schemas are easier to maintain and analyze. There is a limit as to how small a billing schema may be; all rates that are found using a rate category must exist in the associated billing schema.
Performance:
The performance of the billing program is dependent on the number of steps to be executed. If billing involves many schema steps, the runtime can be very long. You should note this when designing billing schemas.
The number of schema steps that are executed internally is also vital for performance.
Example:
A billing schema contains steps for the rates T1, T2T10
When you bill a contract, the system only finds rate T1.
The runtime of the billing is therefore dependent on the number of schema steps that belong to rate T1. The number of schema steps for rates T2 to T10 is of no importance in this case.
Some schema steps are executed more than once for schemas with backbilling or dynamic period control. If, for example, a backbilling takes place for the past 10 months, there are schema steps that are executed 10 times internally in the billing. Billing schemas with many steps affect the runtime accordingly when you perform a backbilling.
There is no simple answer to explain how the number of schema steps influences the runtime of the billing program. It is due to the fact that runtimes of some program components (such as database accesses) are dependent on the length of the schema. The runtime of other program components is to a certain extent proportional (for example, analysis of operand values). There are also program components whose runtime is over proportional (analysis of dependencies between the schema steps. The analysis is required for the update).
Experience shows that the runtime is greatly independent of the schema layout when billing residential customers with simple rates. Billing an contract with 15 schema steps requires little more time than a contract with 8 steps.
This does not apply for very large billing schemas. The analysis of billing schemas and dependencies between the schema steps influences the total runtime. SAP highly recommends the following:
Try to enter as few schema steps in the schema layout as possible.
Test the runtime at an early stage using test cases.
Avoid a large number of schema steps if the schema is to be used for many contracts.
Experience shows that persons who are proficient in designing schemas find it easier to map complex requests using few schema steps. If you want to create very complex schemas, it may be appropriate to allow an experienced specialist to check the concept at an early stage.