Description
This report is used to transport the following billing master data:

• Operands


• Prices


• Discounts


• Rates


• Billing schemas


• Rate categories


• Rate determinations


• The number range intervals of the logical rate step
numbers and of the discount keys (if necessary) arealso transported and overwritten in the target system.
Transporting the prices and discounts is optional. Read thedocumentation for the selection parameters:
transport prices and transport discounts.
This report generates a request for the given tables. The entirecontent of these tables is transported after the request has beenreleased. Only that data is collected and transported which exists inthe current client from which the program is started.
Note that this report can only be started in the system and client inwhich you perform Customizing activities for billing master data.
To import to the target system, you must call the tp program atthe level of the operating system as follows:
tp import <(><<)>request> <(><<)>sid> u1
To import to a different client in the target system, you must call thetp program as follows:
tp import <(><<)>request> <(><<)>sid> client=<(><<)>targetclient>
u1
The variables (..) are defined as follows:
<(><<)>request> ,, = request number of the rate transport
<(><<)>sid> ,, = system ID of the target system
<(><<)>targetclient> ,, = target client in the targetsystem

Precondition
Note the following restrictions:
This report should only be run by the system administrator.
Both the source and target system must have the same IS-U release, thesame put level, and the same AOP level.
The tables of the cited objects are transported completely, meaning theentire content of the tables is copied from the source system to thetarget system. It is not possible to transport individual operands, forexample. All operands, all prices, all ratedeterminations, and so forth, are transported.
Existing operands, prices, etc. in the target system are deleted as aresult of the transport, and are replaced by the content of the sourcesystem. For this reason, you should only perform the transport if youdevelop billing master data only in the source system and afterwardstransport to the dependent target systems. Otherwise changes in thetarget system could be lost due to the transport.
Example:
Source system: contains rates TA, TB, TC
Target system before the transport: contains rates TA, TZ
Target system after the transport: only contains rates TA, TB, TC; rateTZ was deleted
If you wish to delete billing master data in the source system, use awhere-used list. For example, you cannot delete a billing schema if itis still used in a rate category. The where-used list, however, doesnot cover the target systems to which the transport occurs. You candelete a schema in the source system, even if it is still used in thetarget system. During the transport, the schema is also deleted in thetarget system. If you delete billing master data in the source system,you must ensure that this data is not used in any target system.
When you delete operands, prices and discounts that you no longer wishto use in billing, you should note that they can also be used in theinstallation facts. If you delete operands, prices or discounts in thesource system, you must ensure that they are no longer used in theinstallation facts in the target systems. Otherwise the installationfacts will be inconsistent and can no longer be processed. In addition,you are not permitted to delete data still used in the target systemand then create the data again with new characteristics. For example:
Operand NUMBER from operand category FACTOR is used in the installationfacts in the target system.
You delete the operand NUMBER in the source system.
In the source system you recreate operand NUMBER as an operand from thecategory INTEGER.
Following the transport, the installation facts in the target systemare inconsistent since the operand value does not match the new operandcategory.
Billing master data should only be transported between systems forwhich the environment for the billing master data has been customizedthe same. This refers to the following data:
Currency codes
Units of measurement
Allocation of divisions to division categories

Meter reading group
Validation classes
Independent validations
Dependent validations
Weighting keys
Billing classes
Rate types
Price classes
Price levels
Price adjustment clauses
Rate fact groups
Backbilling groups
Franchise fee groups
Outsorting check groups
Sort criteria for bill printout
Period control
Line item types
If you use customer-defined variant programs
, then the control tables and the corresponding function modulesmust be available in the target system.
The sub-transactions that you use in the rate stepsmust also be available in the target system. In particular, thosecombinations of debit and credit sub-transactions used in the rates ofthe source system must also be permissible in the target system.
The change documents for the billing master data are not transported.
After the transport you can check the consistency of certain billingmaster data using the report:REA_BILL_CUSTOM_DATA_CHECK