SAP ISU Billing

Below  are some important basic terminology for SAP ISU Billing and it needs to be configured first.

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

Business master data.
1) Business partner: A person or legal entity with whom the organization has business relationship. It can be a customer, a vendor, an employee. 
Transaction code: FPP1

2) Contract Account: Customer's account that has information about billing method, payment method,collection method and more.
Transaction code: CAA1

3) Contract: It is an agreement between business partner and the utility company.
Transaction code: ES30 (Contract is automatically created when customer is moved in to a premise)

Technical Master data:
1) Connection Object: It's a building, piece of property or other facility that is connected to the supply grid.
Transaction code: ES55

2) Premise: It is an enclosed spatial unit that is supplied with energy such as an apartment or a factory.
Transaction code: ES60

3) Device location: It provides the physical location of device (meter)
Transaction code: ES65

4) Installation: It stores billing properties for one or more devices at the premise.
Transaction code: ES30

Billing configuration:
1) Billing schema: Structure that defines the order in which variant programs for rates to be billed must be executed.
Transaction code: EA35

2) Billing class: It classifies installation for billing (example: residential, non-residential, non metered etc). Change in billing class also requires change in rate category. Final billing is not necessary upon changes. It can be valid for several rate categories. It serves the purpose of validation and statistical criterion. It controls the determination of the MRU in in the regional structure.

3) Variant program: It is a functional module in rates or schemas that contains a billing rule.
For example, one of the billing rule is consumption quantity(KWH)Xprice ($)= Total charge amount ($) is accomplished by variant program QUANTI01

4) Rate: 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.

5) 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.


6) 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.

Example: Different prices for Victoria North & Victoria South for SOLARIS & UNITED respectively

7) Price key:

8) Operand: Individually determined symbolic name for the assigned values that are used as input/output parameters in variant programs. One or more operands are allocated to an operand category.

Transaction code: EA50

9) Rate Category: It is classification of an installation for billing purposes. It contains one valid billing schema. It determines which outsorting billing checks occur during billing. In conjunction with rate type, it determines rates to be applied during rate determination process.

Transaction code: EA53

10) Rate type: 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.

11) Rate determination: In conjunction with rate category, rate type is used to determine the rate.

Transaction code: EA87

Billing errors

You have sent BQ request using transaction ZBQR but it is not showing up in BQ table.

Solution:
One of the issue could be MROs that you created are not in order. Check if the MROS you created are within the current date period. Example, today is Demember 10, 2014 and one of the MROs you created is for January 2015. If this is so, remove January MRO and send BQ request again.

Another issue can be that the device date and contract date does not match. For example device date is January 2014 and contract start date is December 2013. This means that there was no device installed at this premise in December 2013 when customer was moved in to this premise. We cannot bill the account without having a meter installed. In this situation, investigate and check records and update the device installation date or contract start date in such a way that the contract start date is on or after the device installation date.

Another issue can be that there is no USDP ID assigned to the account. So check in ES32, under point of delivery, click on Grid, and check if USDP ID is showing up. If not, arrange to assign one to the account.



While invoicing you are getting the error EXTUI from INTUI

Solution:

This is normally indicating that the point of delivery date is not matching with contract start date or USDP ID date. In SAp many of the errors are related to the dates mismatch or not in order with related events. So here, check the contract start date and make sure that point of delivery date is on or BEFORE the contract start date. If it is not so, reverse all bill docs and then using transaction ES31, you can change the point of delivery date and it would solve the problem

When the scheduled bill date falls on the same date with meter removal or new meter installation date, and you try to invoice the account, you may receive error "existing billing documents cannot be invoiced"

Solution:

In this situation, we normally delete the schedule bill date MRO so that we can keep only one event for that date. Bu doing this, we are essentially invoicing 2 period together instead of one and this way it will allow you to invoice. However, when the account is on budget billing, it is mandatory that it needs to be billed monthly and hence even after removing scheduled bill date as suggested above, it won't let you invoice it.

For budget billing accounts, we need to change the MRU so that we have a different scheduled bill date than the earlier scenario. For example if the scheduled billing date and CMO falls on December 10, then change MRU and now you have scheduled bill date falls on December 9 and CMO on December 10. Reverse all MROs and send BQ request so you can get all the readings. Now invoice the account and once done successfully, change the MRU back to what it originally was. This is a work around which would prevent having problems in invoicing when there are multiple allocations falling on the same date.

Segment missing error
While creating invoices, the use is getting this error.

Solution:

There are 3 possibilities.
1) The rate category is NON-TOU and registers are TOU o vice versa. If this is so, update them correctly and this error should not appear again.

2) On the register tab in ES32, one or more of the component is missing. For example, For a TOU rate category, on peak rate register is missing. If this is so, update it correctly and this should be resolved now.

3) There are multiple installations attached to CA and in the contract, joint invoicing condition is set as mandatory. But when you invoice the account, it is missing billing for one of the installations. If this is so, invoice the account together and this should be resolved.

IF variant incompatibility error

While invoicing this account, the user receives this error.

Solution:
This error normally indicates that there is a gap between the dates of meter removal and new meter installed. Example: Meter removed on December 5 and subsequent new meter is installed on December 11. Normally new meter should be installed on the very next day to meter removal so that the customer can be billed continuously on their contract.
To solve this error you can either terminate the contract with the meter removal and enter a new contract with the new meter installed. This is recommended if the gap between meter removal and new meter installation is large. Otherwise you can change the new meter installed date on the next day to meter removal date and should be able to invoice the account without any errors.

Existing billing documents can not be invoiced error

Solution:
This is error is due to 3 possibilities.
1) When you try to invoice manual doc (credit memo) alone without selecting billing doc...you can correct it by selecting billing doc and manual doc together
2) When you have an outsort that is not released/reversed yet. To correct it, using transaction EA05, you can either release or reverse the outsort and try to invoice again and it should allow you to do so now
3) The CA (contract account) has multiple installations/contracts attached to it with joint invoicing condition and while invoicing you are selecting only 1 contract to invoice. To correct this, sort the bill start/end date so that you can invoice all the bill docs for the same periods together. If you see billing docs of only 1 contract while invoicing, it means that the other contract may have been invoiced alone. If it is so, reverse those invoices using transaction EA15 and then invoice both contracts together now.

Very high amount invoice

Solution:
There can be 2 possibilities.
1)Meter overflow causing this issue. Normally when you enter meter readings, they are in order and current month reading is higher than previous month reading. But due an incorrect meter reading entry or device issue, the current month reading is lower than previous month, when you try to invoice for current month, you would see a very high amount of invoice. To correct this, check the readings again and correct the readings and invoice again.
2) There may be an actual reading that shows very high consumption for a particular billing period. For example, during festival time, when customers display lightings at their homes, the consumption is tend to be higher than normal or seasonally for summer months due to higher usage of air conditioning, the consumption tend to be higher than normal. Check historical pattern to see if this higher consumption makes sense. If it is multiple times higher than normal than this needs to be verified by re-reading the meter or investigating any device issue.

SAP ISU tables

Master data:

EKUN  ISU business partner data
BUT050  Business partner relationships
BUT100  Business partner roles
BUT020  Business partner address
ADRC  Addresses
BUT000  Business partner
DFKKLOCKS  Business locks
FKKVKP  Contract account for partner
FKKVK  Contract account

Billing and invoicing:

ERDK  Print doc header
ERDO  Outsorting for invoices
ERDB  CA document for print document
ERCHO  Outsorting for billing document
ERCHC  Invoicing reversal history
ERCH  Billing doc header
DBERCHZ (1-8)  Billing doc lines
DBERDL  Print doc lines
DBERDLB  Billing doc-print doc line reference

Billing master data:

ETTA  Rate category
ETTAF  Rate category facts
TE221  Operands
ETRF  Rates
EKDI  Rate facts
ESCHS  Billing schema steps
ESCHS  Billing schema header
EPREIH  Price history
EPREI  Prices header
TE069  Rate types
ETTIF/ETTIFN/ETTIFB  Installation facts
ERTFND  Rate determination

Technical master data

EANL  Installation
EVBS  Premise
EHAUISU  Connection object
EANLH  Installation time slice
EGPLTX  Device locations
EUI HEAD  PoDs
EUITRANS  PoD internal to external Ids

Device Management

ETDZ  Registers
EPROFASS  Registers-profiles
EASTI  Register relationships
EUILZW  Register- Pod
EASTS  Installation-register
EADZ  Multiple installation billing data registers
EZWD  Register Groups
EZUZ  Device allocation for registers
EGERH  Historical device data
EGERS  master device data
EGERR  Device info for Pod
EUILNR  Device Pod
ETYP  Device category- material data
EZUG Device allocation for device

Scheduling

TE422  Meter reading units
TE418  Schedule records- meter reading units
TE420  Portions
TE419  Parameter records
TE417  Schedule records for portion
ETRG  Billing orders
EABL  Meter reading document
EABLG  Meter reading reasons