Rate types do have at least two main purposes:
They classify different categories of registers (e.g. on-peak and off-peak) for the device installation, and on the other hand they provide (together with the rate category) the rate determination.

The first aim is nearly only relevant in case of register or device related rate types, whilst the second aim is relevant for all rate types with the exception of rate types for period end billing rates (see below).The database table for the rate type is TE069 and it's maintained in IMG via the path 'SAP Utilities' -> 'Contract Billing' -> 'Billing Master Data' -> 'Rate Structure' -> 'Define Rate Types'. The rate type is division specific. The billing class is part of the definition of a rate type but it's not obligatory.Within the definition of a rate type it has to be maintained where this rate type is permitted for. There are several possible usages for rate types:

• Register
• Device
• Facts
• Interval Meters
• Period End Billing

The permissibility of a rate type can be choosen freely in the maintenance, until it's used the first time. After this the permissibility can't be changed any more. The permissibility of the rate type is directly related to the permissibility of the rate(s) that are found via rate determination (for more info see there).The last field in the definition of a rate type (ESTI_ANL) is designed to control the estimation of a register. It can only be set in a register permissible rate type. I don't know any customer using this functionality.

As said before the billing class is not obligatory in the definition of the rate type. If it's filled it will be checked during creation of rate determination (see function module ISU_CHECK_TARIFNR_FOR_ERTFND).

In any case a rate fact group can be maintained together with the rate type where it's maintained depending on the permissibility. A change of rate type or rate fact group will be taken into account during billing. Usually this leads to a change in rate determination.

The following sub-chapters are dealing with the different permissibilities of the rate type:

Register

A rate type on register level is stored in table EASTS, field EASTS-TARIFART. The rate fact group is filled in EASTS-KONDIGR. It can be maintained with transaction EC30 (Maintain Rate), EG42 (DeviceModification) or EG70 (Change Rate Data). In addition it can be maintained in any functionality to install a device. The register related rate type can not be changed any more in timeslices that are already billed.

The field INTSIZEID (Interval Length ID) in the corresponding entry of ETDZ (Technical Data for Installed Register) for this register must not be filled.

The rate type on register level has a strong relationship with the field ZWNABR (Register not relevant to billing) in EASTS. The four possible combinations of these two fields are described in the documentation for data element ZWNABR.

If the rate type is changed in the register usually it's necessary to maintain a reading for this register with reading reason '17' (Reading for change of inst. Structure) on the day before the change. But if the rate type is changed using transaction EG42 one will get a combination of two readings with reading reason '16' (Meter reading before program./adjustment) and '11' (Meter reading after program./adjustment).

Device

A rate type on device level is stored in table EASTL, fields EASTL-TARIFART. The rate fact group is filled in EASTL-KONDIGR. It can be maintained with transaction EC30 (Maintain Rate), EG42 (Device Modification) or EG70 (Change Rate Data). In addition it can be maintained in any functionality to install a device.

The device related rate type can not be changed any more in timeslices that are already billed. Usually the rate that is determined with a device permissible rate category includes steps to bill settlement or rental prices. Infact it's possible to use operands of type SPRICE (Settlement price) only in rates that are either permissible for registers or for dvices. Therefore there exists a strong relationship to the field GVERRECH (Pay rental price) in EASTL. Only those devices where this field is marked will be taken into account while calculating a rental price during billing.

If the rate type is changed in the device usually it's necessary to maintain a reading for all registers related to this device with reading reason '17' (Reading for change of inst. Structure) on the day before the change. But if the rate type is changed using transaction EG42 one will get a combination of two readings with reading reason '16' (Meter reading before program./adjustment) and '11' (Meter reading after program./adjustment).

Facts

A rate type that is permissible for facts can be maintained either in the facts for an installation or for a rate category. It's not possible to maintain a rate type in a rate fact group for a rate directly. In general there are two possibilities to store a rate type in the facts:
Either it's done as a value of an operand of type RATETYPE, or it's done in addition to a normal value for an operand that is defined with the marker TAZUORD (Indicator: allocation to a rate type is required) set. So nearly every operand (except operands of type SEASON) may carry a rate type, not only operands of type RATETYPE.

On installation facts level the rate type is filled in the field ETTIFN-TARIFART with the rate fact group in field ETTIFN-KONDIGR or in field ETTIFB-TARIFART with the rate fact group in field ETTIFB-KONDIGR if the operand is of type REFVALUE. They are maintained with transaction ES31 (Change Installation).

On rate category level the rate type is filled in the field ETTAF-TARIFART with the rate fact group in field ETTAF-KONDIGR. They are maintained with transaction EA54 (Change Rate Category). Rate types on facts level are usually used to determine rates that are generally used without a linkage to a register or a device.

To bill a flat rate installation (without any device installed) it's obligatory to have at least one rate type on facts level.

But not only a flat rate installation uses facts permissible operands; in many cases the rates that do the calculation of posting relevant lines are facts permissible and the register related rates are only forwarding the quantity information to these rates (e.g. by using variant program QUANTI14). One usefull feature when using rate types on facts level is the following scenario: If a special discount shall be given just for a ceratin timeframe in billing period then it's advisable to use a discount-operand that has the field TAZUORD set in TE221. The rate that is determined by the rate type in this operand shall contain the necessary steps to execute the discount. With this approach it's possible to define the period where the rate shall be executed exactly the same as the validity of the discount.

Interval Meters

A rate type that is permissible for interval meters has the same usage as a register permissible rate type. It's also maintained in table EASTS-TARIFART, but it can only maintained here, if the field INTSIZEID (Interval Length ID) in the corresponding entry of ETDZ (Technical Data for Installed Register) is filled (see form object_checks in function group E20Q).

 Period End Billing

A rate type that is permissible for period end billing can be maintained in the facts like a rate type that is facts permissible. Since the period end billing rate is directly maintained in the header of the schema it seems to be senseless to define a special rate type for period end billing. But this rate type is the only possibility to differentiate between different rate fact groups, that are maintained together with the rate type in the facts.