MRU / Portion /SPRO config /Rate /Rate Type /Master table of billing

Installation: EANL

Meter Read Doc.: EABL | Installed Register: ETDZ

Operand: (Operand Categories or Types- TE375 and Operands- TE221) List of Operand Transaction
Create – EA50 and Display - EA52

Price: EPREI

Bill Doc: ERCH | Billing order: ETRG | Outsortings Table for Billing: ERCHO | MRU:TE422 |Portion:TE420

Billing Line Item: DBERCHZ1 | Individual line items (device data): DBERCHZ2 | Individual line items
(amount and price data): DBERCHZ3

Invoice Doc: ERDK | Outsortings Table for Invoicing: ERDO

Order Creation Doc:

Fact Groups: TE067

Rate Cat. Facts: Rate category & Operand: ETTAF

Rate Type - EF-O-CH1 (Charge Rate 1 Register) | TE069 (Master Table) | Transaction EA54

[Classification of a register for Billing, create a rate category for every register that is billed with its own rate.
Flat rate or reference value for billing purposes. In conjunction with rate category, the rate type is used
to determine the rate]

[It is classification of register, flat rate or reference value for billing purposes. Rate type is commonly
allocated to register to classify the register type such as on peak, off peak, mid peak etc. It could also be
allocated to device or installation level for use as a classification of flat rate or be a classification of
reference value. In conjunction with rate category, it determines rates to be applied during rate
determination.]

Two rates types are required for our billing example:

 On-peak rate active energy (this rate type is also used in the case of a single-rate meter)

 Off-peak rate active energy

Rate category - ELE_RES_C (Electricity Residential Credit) | ETTA (Master Table) | Transaction Create –
EA53 and Display - EA57

[ Classification of an installation for billing purposes. In conjunction with rate type, the rate category is
used to determine the rate]

[It is classification of an installation for billing purposes. It contains one valid billing schema. It
determines which out-sorting billing checks occur during billing. In conjunction with rate type, it
determines rates to be applied during rate determination process.]
Rate Determination – ERTFND | Transaction EA87

We do not enter the rate in the master data. Rather, the rate is determined dynamically (at runtime)
from the rate type of the register and the rate category of the installation.

Example

For our billing example, rate determination is performed for both of the rates E1_1 and E1_2:

    Rate type      Rate category       Rate

1.    1001     +        E1     ---->   E1_1
2.    1002     +        E1     ---->   E1_2
3. EF-O-CH1 + ELE_RES_C ---> EF_CH1
4. EF-O-CH2 + ELE_RES_C ---> EF_CH2

Rate - EF_CH1/GF_CH1 Rate List Transaction: EA32 | | ETRF (Master Table) | Transaction EA32

[Billing rule for a register or a reference value that refers to all the billing-related steps executed during
billing. A rate consists of one or more variant programs, which are part of the billing schema]

[It stores billing rules which are executed during billing run. It consists of steps and values of how to
calculate billing quantity and amount. Each step is executed with variant program. Values of input and
output parameters of rate steps (quantity, price, factor, amount etc) are determined historically at run
time.]

Facts: They are concrete values (such as 100 KW) or keys (for prices etc) that are allocated to operands
and are valid for a specific period. According to the level on which facts are allocated, they can refer to
installation facts, rate category facts or rate facts.

Installation facts have precedence over rate category facts and rate category facts have precedence over
rate facts.

Rate fact group: Grouping of individual facts that are allocated to a rate. Several rate fact groups can be
allocated to one rate. Rate fact groups enable you to use the same rate

but apply different operand values.

Flow: Rate Category->Rate Type-> Rate

Variant Program - Transaction ‘EA99’ [It is a functional module in rates or schemas that contains a billing
rule]

A variant program is contained in the rate and it performs exactly one calculation (for example, QUANT x
PRICE).

 QUANTI01 Valuation of a quantity using a price

 LUMSUM01 Billing of a flat rate
 SETTLE01 Determination of a rental price
 REFVAL01 Valuation of a reference value using a price
  COMPUT* Variant programs with arithmetical operations
 DISCNT* Discount variant programs
 INFACT* Variant programs for writing values to the installation facts

 COMPUT01 - Subtract Two Amounts

 COMPUT02 - Add Two Amounts
 COMPUT03 - Multiply/Divide Two Factors
 COMPUT04 - Add Two Factors
 COMPUT20 - Calculate Number of Days in Billing Period
 ZLUMSUM2 - Bill Amount

Operand: Individually determined symbolic name for the assigned values that are used as input and
output parameters in variant programs.

Schema: Transaction EA35 – Create and EA37 – Display

Structure that defines the order in which variant programs for rates to be billed must be executed.

In other word In the schema, we establish which rates are billed and in which sequence the rates and
variant programs are to be executed.

MRU: A meter reading unit, Group of utility Installations (the devices and registers installed in them)
according to regional criteria for meter reading purposes.

It contains the schedule dates for doing meter readings for installation

Portion: Which is Control Billing Schedule. Determine frequency of Periodic billing

Full installation - We can install devices in the following ways:

 The device is installed in the device location with respect to technical data. - EG33 -
Technical Installation
- The system stores technical data for the register.
- Device relationships may have been created and a device location is created.
 The device is allocated to an installation for billing. - EG34 - Billing Installation
So, full Installation is the single step which includes both Tech and Billing installation.

EG31 - Full installation.

FQEVENTS: FQEVENTS is a transaction for FICA related solutions and which enables easy and quick
navigation to customization points within the solution. 
 Tables: From the following tables, the function module FKK_FUNC_MODULE_DETERMINE sequentially
determines the event modules defined in Customizing that are to be processed:

Table Sort Description

TFKFBM Sample function modules
TFKFBS Standard function modules for Industry solutions
TFKFBC Installation-Specific Function Modules (Customer
Function Modules)

Flags Concept:
Flag Description
Additional Functions Specifies whether several function modules can
be processed in this event or a maximum of one.
TFKFBM-MEHR
>If the indicator is set, several function modules
of the corresponding industry solution and
several customer-specific function modules can
be processed. 
  The modules that the application area has
defined are called first, and then the customer-
specific modules.     
> If this indicator is not set, only one function
module is called. In this case, a customer function
module has priority over an application-specific
function module.        
No Customer Module If this indicator is set, customer function modules
are not taken into account for this event in the
TFKFBS-NOCUS
application area in question.

Programming Restrictions 

You must not use the following language elements in events, unless they were explicitly declared to be
allowed for the given event:

 COMMIT WORK
 ROLLBACK WORK
 CALL FUNCTION 'DEQUEUE ALL'
 Deletion of locks that you have not set yourself
 Implicit database commits triggered by RFC calls or by a WAIT statement

Function Modules and EXIT used in SAP Scripts

 Exit before loop
 Exit during loop
 Exit after loop
 We use some function modules to develop SAP Scripts, explained below.

OPEN_FORM
This is used to open a form for execution by loading it into memory.

WRITE_FORM
It is used to write Some information on the SAP Script form using Text Element.

CLOSE_FORM
It is used to close the form which is opened by open form.

START_FORM
It is used to call another SAP Script into current SAP Script (Nested Scripts).

END_FORM
It is used to end the form which started by START_FORM.

Create Payment Scheme

The creation process is split into three parts:
 Select a utility contract.
 Enter the payment scheme frequency and the first due date. You do not have to enter a
payment screen category. You can define default values for the frequency and the category in
Customizing under SAP Utilities -> Invoicing -> Budget Billing Plan -> Payment Scheme -> Basic
Settings -> Control Parameters for Payment Scheme in IC Web Client.
 The existing open items are available for selection so that you can include them directly in
the payment scheme when you create it.
Once you have completed the creation process, the system displays the payment scheme
in Change mode.

EVENTS:
Events Sort Description Sample Module
R517 IS-U BBP Payment   Scheme: ISU_SAMPLE_R517
Activate Payment Scheme
R518 IS-U BBP Payment   Scheme: ISU_SAMPLE_R518
Checks for First Payment Day
R512 IS-U BBP [Link]:   ISU_SAMPLE_R512
Determine BB Amount for
Payment Scheme
R513 IS-U BBP [Link].:   Adjust ISU_SAMPLE_R513
[Link]. for Period/Interim Bill.
R532 IS-U BBP Pay.   Scheme: ISU_SAMPLE_R532
Determine Deactivation Reason
 for PS
R527 IS-U BBP Payment   Scheme: ISU_SAMPLE_R527
Rules for Amount Rounding in
PS

Function Groups: EA61PS

Function Modules:
Function Module Description
SU_GET_ACT_PAYSCHEME_VKONTO Selection of a Payment Scheme for a Contract Account  
ISU_PAYSCHEME_ACTIVATE   Activate a Payment Scheme
ISU_PAYSCHEME_DELETE   Delete a Payment Scheme (Draft)
ISU_PAYSCHEME_REVERSE   Reverse Periodic/Interim Bill Adjustment for PS
ISU_PAYSCHEME_UPDATE   Payment Scheme Update
ISU_INV_PS_ADJUST_UPDATE Update PS for Adjustment in Invoicing

SAP ISU Billing Master Date.

 Billing schema
 Class
 Rate
 Facts
 Rate facts group
 Price key
 Operand
 Rate category
 Rate type
 Rate determination
 Master data creation (BMD + TMD)

Meter to Cash Process:

Meter Read order created -> (Read provided during range)-> Billing order created -> Bill doc generated->
Invoicing -> Printing

Form Class Transaction: EFCM