Basic Function Important

5 Scope of Business Functions
Budget Billing Plan

A utility company does not always bill its services until the end of a supply peri-
od, as is the case in annual consumption billing, for example. Therefore, through-
out the current period it charges budget billing amounts instead of the amount the
customer is expected to owe, so that the utilitys liquidity is maintained. The bud-
get billing plan sets the due dates and the budget billing amounts and is, there-
fore, the basis for budget billing collection.
Generally, the system automatically creates budget billing plans during invoicing
or move-in processing. However, you can create them manually.
Contracts that have to be invoiced together are assigned a common budget billing
plan. All other contracts in the contract account can have their own separate bud-
get billing plan.
Fig. 5-21: Budget Billing Procedures Supported by IS-U/CCS

Budget billing amounts can be stored either as down payments (statistical receiv-
ables) or as partial bills (debit entries) in Contract Accounts Receivable and Payable
and are therefore subject to all dunning and payment procedures.
IS-U/CCS also supports average monthly billing and budget billing as special
budget billing procedures applicable to North America. They are discussed more
fully below.
5-42
Scope of Business Functions 5
In budget billing, an average amount is determined either through simulation or Budget Billing
manually. The customer pays that average amount for a period of 12 months. At (North America)
the same time, the customers actual consumption is billed, and the results are
printed on the bill. In addition, the difference between the customers actual con-
sumption and the average amount is calculated, updated monthly, and printed on
the bill. In the last month of the meter reading period, the actual amount and the
accumulated difference are billed.
In average monthly billing or equalized billing, the customer is charged an aver- Average Monthly Billing/
age amount based on billings over the last x months (you define the number of Equalized Billing
months, including minimum and maximum number of months, in Customizing).
(North America)
In addition, the customers actual consumption is billed, and the results are print-
ed on the bill. The amounts due for later months are calculated using the average
of the previous monthly bills, the current bill and the accumulated difference.
That difference is updated monthly and is printed on the bill.
The due dates for the budget billing amounts are calculated directly from the por- Budget Billing Amount
tion applicable to the contract and from the parameter record. The following data Due Dates
is defined:
The length of the budget billing period (a number of months or a year)
The budget billing cycle, meaning the equal distribution of dates over the pe-
riod (one or more months)
However, you can override the preset values from the portion either in the budget
billing plan itself or in a contract. While changes made in the budget billing plan
take effect immediately, entries made in the contract do not take effect until the
budget billing plan is created again.
The system calculates the budget billing amount on the basis of the expected meter Budget Billing Amount
reading results. The section Device Reading describes the extrapolation of meter Calculation
reading results. Extrapolation can be based on the following information:
Amounts from the last bill
The extrapolation lines for the budget billing amounts are generated automat-
ically during periodic billing.
Periodic consumption
Reference value in the rate
Manual specification of the budget billing amounts
The following functions are also available for calculating the budget billing amount:
In the case of an interim billing, you can specify whether the remaining bud-
get billing amounts are to be adjusted.
In the case of budget billing, you can also perform mass changes. Mass chang-
es are necessary when there are changes to prices, fees, or taxes.
5-43
Budget Billing Request Direct debit customers receive budget billing requests as a notification about when
the amounts due will be debited. Cash payers receive budget billing requests as
payment forms, which can be sent out in a variety of ways (for example, all pay-
ment forms included with the bill or one separate payment form on each due date).
Fig. 5-22 Printout of Budget Billing Forms
Including External Billing Documents in Invoicing

You can invoice billing documents from IS-U/CCS together with documents from
the billing component of the Sales and Distribution component, and in Release 4.51
you will be able to invoice billing documents together with documents from non-
SAP systems, such as heating costs billing or telecommunications. To transfer
billing documents from non-SAP systems, you need a suitable interface program.
The purpose of that interface program is to create standardized IS-U/CCS billing
documents from the billing documents of the non-SAP system so that they can
then be processed in IS-U/CCS invoicing.
5-44
Contract Accounts Receivable and Payable

Contract Accounts Receivable and Payable (FI-CA) is a form of subledger accounting
designed for industries that typically deal with large numbers of business part-
ners and large volumes of documents. In IS-U/CCS, the large numbers of post-
ings from billings and budget billing requests are managed in Contract Accounts
Receivable and Payable instead of in the general ledger. Each individual business
transaction, that is, each posting and each document for a given customer, is stored
in order to guarantee itemization. These FI-CA documents are cumulated and trans-
ferred at certain intervals to the general ledger of the Financial Accounting compo-
nent or to a non-SAP system.
When an FI-CA document is posted, general ledger account determination auto-
matically occurs for the General Ledger Accounting (FI-GL) component. The system
automatically determines all receivables, payables, revenue, and expense accounts
based on account assignment details in the line items.
A standard interface between Sales and Distribution and FI-CA ensures the com-
plete integration of service invoices in FI-CA. This means that you can combine
consumption and service billings into a single bill, invoice them jointly, post them
to a customer account, and print them out.
Basic Functions
Postings are always stored as documents. The document, the smallest unit in fi- Postings and Documents
nancial accounting, constitutes the proof of a business transaction. It can only be
posted if the balance of the items contained in it is zero.
In FI-CA, a document consists of a header and various line items:
The document header contains data that is applicable to all the document lines,
such as document date, posting date, and document type. The document type
classifies documents according to specific business transactions.
Receivables lines (reconciliation lines) contain all the data relevant to pay-
ment transactions, dunning, and the receivables account (reconciliation ac-
count) to which debits and credits are posted.
Revenue lines contain the data for the profit and loss statement and the sales
tax data.
Budget billing plans and installment plans are stored as repetition items in
order to save memory. However, in a contract account display, repetition items
appear as normal items and can be processed as such.
A document does not have to contain all these lines. For example, with normal
payments that result in the complete clearing of the receivables lines concerned,
the system only creates a new document header for the payment because it can
derive the data relevant to account assignment from the receivables lines.
In addition to line items that are created in association with bills, payments, or
credit memos and are updated in the general ledger, you can also post statistical
line items, which are merely recorded in the contract account, or subledger. You
can use statistical postings to post budget billing requests or dunning costs. Statis-
tical postings can serve as noted items or, in the case of a payment, they can be
converted to actual postings.
5-45
In addition, documents can be posted to multiple company codes. This enables

you to perform convergent billing. For more information on this topic, please re-
fer to the section titled Business Services for Other Utilities.
Budget Billings Budget billings can be stored in FI-CA either as down payments (statistical post-
ings) or as partial billings (debit positions) and are therefore subject to all dunning
and payment procedures. Budget billing requests are shown in the document as
repetition lines. For more information on budget billings, please refer to the sec-
tion titled Budget Billing Plan under Invoicing.
Reversal You can reverse documents if a customer complains about a bill. You can execute
a reversal for a document or for a collective bill. The system generates a reversal
document, which together with the reversed document has a zero balance. Dur-
ing reversal these two documents are linked to each other.
You can use reversals with the following posting transactions:
Incoming or outgoing payments
When reversing payments, the allocated item (meaning the receivable or cred-
it memo) is identified as open again. This means that, in terms of its due dates,
and payment and dunning data, it is returned to the status it had before the
incoming or outgoing payment.
Receivables or credits
With regard to receivables or credits, the system distinguishes between the
reversal of consumption billing documents and the reversal of other items. In
the case of billing documents, the system distinguishes between a full reversal
and an invoicing reversal. Full reversal reverses the billing documents in ad-
dition to the invoicing document.
Settlement or write off
The reversal process for settlement and write off is similar to the reversal pro-
cess for payments.
Interest
The original receivables on which interest was calculated are also adjusted in
addition to the reversal of the actual interest item.
Manual Document Entry In most cases, the system automatically enters documents. However, you can also
enter receivables and credit memos manually. You do this by entering a predefined
process for each business transaction. This predefined process then automatically
determines the general ledger accounts or tax accounts and notes them in the
receivables and revenue lines.
The documents are classified based on the document type entered. The system
automatically determines the due date using the payment conditions in the contract
account. Receivables and credit memos can be cleared immediately or in incre-
ments over time.
By specifying a start date, receivables lines with different due dates can be repeat-
ed at monthly or daily intervals, for example in the case of budget billing or in-
stallment plans.
5-46
Open items are uncompleted transactions. An unpaid billing line item, for exam- Open Items
ple, is managed as an open item in the contract account until it has been paid and
cleared. This allows you to check which receivables or payables are still outstand-
ing. The open items in an account can be cleared immediately or in increments
over time. With incremental clearing, the item is divided into a cleared item in the
amount of the cleared part and an open item containing the remaining amount.
Open items can be cleared in the following ways:
Posting documents
Account maintenance
Posting payment lots
Payment programs
Reversing documents
Clearing budget billing payments made as part of annual consumption billing
The system can automatically create correspondence for a business transaction. Correspondence
Examples include documents for automatic payment settlement (checks and bank
transfers) and customer notifications. The following notifications can be created
automatically or manually depending on the business transaction involved:
Account statements contain a list of a customers open items and the total
receivables amount.
Dunning notices contain a list of a customers overdue open items and their
total amount.
Notifications about agreements for payment by installment contain the in-
dividual installment amounts for the installment agreement entered into with
the customer, including the amounts and due dates.
Notifications about budget billing requests contain information on set bud-
get billing amounts and due dates in the event that a new budget billing plan
was created or an existing one was altered.
Notifications about deferral agreements contain information on payment de-
ferral agreements.
Returns notifications contain information on the event initiating a return and
a listing of the items affected.
Mutual help requests, which are sent to another utility company, contain a
request for mutual help (see section titled Mutual Help).
Interest notifications contain a listing of the items on which interest has been
calculated and an overview of interest calculation.
5-47
Business Transactions
The processing of business transactions in FI-CA is largely automated. You define
how processing is controlled in Customizing. The business transactions are de-
scribed briefly below.
Payments In most cases, the system settles payments automatically. However, you can also
enter them manually, for example, for individual incoming or outgoing payments
made at the cash desk.
Fig. 5-23: Overview of Payments Processing

Automatic payment settlement refers to the automated execution of postings for
incoming payments, outgoing payments, and settlements. It is used in the follow-
ing cases:
Automatic incoming payments
In this case, incoming payment data from legacy systems, financial institu-
tions, or agencies is processed. The system creates a payment posting for the
relevant business partner and allocates the payments to one or more receiv-
ables items. Any credit items that have been released for settlement are also
taken into account.
In exceptional cases it may not be possible to allocate an incoming payment to
an item. That payment may then be posted on account at the contract account
level and subsequently processed manually.
Collection procedure
Payments via collection or direct debiting by financial institutions are pro-
cessed and the corresponding output media are created.
Credit refunds
Credits via check, bank transfer, or postal remittance are refunded automati-
cally, and the corresponding output media are created.
Payment settlement can be executed at the following levels:
Business partner
Contract account
Item
Collective bill
5-48
Depending on the type of payment, payments may be processed via the cash desk Processing of Payments
or by means of payment lots. In the case of cash desk processing, the cash pay-
ment made by a customer is entered in the system and processed individually.
Payment lots group together payments to be processed jointly. You create them by
manually entering data from checks or payment orders or automatically transfer-
ring the data from account statements using data medium exchange (DME).
Payments are allocated to the open items according to industry-specific rules. The
system then automatically clears the allocated items. Overpayments can be post-
ed on account, and underpayments can be posted as partial payment.
You can create incoming and outgoing payments using the payment program. Creation of Payments
The payment program executes the following steps:
1. It determines the open items to be settled using the selection criteria that were
entered for the payment run and the due dates of the open items.
2. It combines the due items as payments or debit memos in accordance with
industry-specific or customer-specific rules.
Credits and receivables are settled if no payment methods are set at the document
level.
3. It selects payment methods and bank details.
4. It posts payment documents and clears open items.
5. It provides data for the payment media.
6. It creates the data media (currently for the Austrian DME format only).
Fig. 5-24: Creating Payments using the Payment Program
5-49
The system supports the most common payment procedures direct debit, debit memo
collection, bank transfer, and check as well as internal direct debit from a deposit
account. With minimum amount limits, you can avoid settling very small amounts.
Returns Returns may occur as:
Payments returned by financial institutions as a part of the debit memo and
collection procedure
Incoming checks returned due to insufficient funds or incorrect data
Undeliverable postal remittances
Returns are combined to form returns lots. You can create these lots manually
using returns slips, or the system can create them automatically by using the re-
turns data from the financial institution.
The system automatically processes returns in the following manner:
Payment settlement is canceled. The receivables or payables cleared by the
debit memo revert to being managed as open items.
A return document is created containing the offsetting entries for the items in
the payment document.
Other postings required in relation to taxes, expenses, or charges are created.
The system automatically calculates bank charges and posts them to the gen-
eral ledger. You can bill the business partner for the bank charges and your
own charges. This may be a statistical posting or a posting to general ledger.
Follow-up actions are initiated. Examples include customer notification, the
setting of a deferral date, and a payment or dunning block.
Follow-up actions depend on the creditworthiness of the business partner and
the frequency of returns. Returns can, in turn, affect the creditworthiness of
the business partner.
Fig. 5-25: Processing a Return
5-50
A down payment is made in anticipation of a bill that has not yet been invoiced. Down Payments
Down payments may be either budget billing payments for energy consumption
or down payments for services, such as the installation of a service connection.
For certain services, the system uses a workflow link for incoming payments that
result from a down payment request, for example, for notifications to field service
employees.
When they are made, all down payments are initially payables with respect to the
customer. They are automatically processed when the bill is invoiced, meaning
they are transferred and offset.
You can apply special conditions to customers with bad payment histories or bad Advance Payments and
creditworthiness: Security Deposits
Advance payments as part of a budget billing plan
Advance payments can be requested only as part of a budget billing plan. The
budget billing requests are due before or at the beginning of the actual con-
sumption period instead of in the middle or toward the end of the period. The
budget billing payment is thus made before the energy is consumed.
Security deposits
The system distinguishes between cash deposits and noncash deposits:
Cash security deposits
Cash deposits are usually requested at the beginning of a utility service
relationship and can be charged automatically when a customer move-in
is processed. You agree upon the amount of cash deposit with the custo-
mer, or you calculate it according to an extrapolation formula, which you
can define.
Cash deposit requests and payments are posted for a contract account or
for a specific contract.
Cash deposit payments are retained until the customer has developed a
positive payment history over an extended period of time or until the con-
tractual relationship with the customer comes to an end. They are refun-
ded as part of a final billing.
Cash deposits or interest on cash deposits can also be refunded, settled or
offset for periods of less than one year. The system calculates interest for
the entire period if desired or if required by law.
Noncash security deposits
Noncash deposits may, for example, include savings books or guarantees
of payment. You enter a business partner as the guarantor.
Payment reminders, or dunning notices, remind business partners of overdue Dunning

payables. The dunning program monitors the payment history of the customer
and, where appropriate, automatically initiates a dunning run. The dunning pro-
cedure concerned plays a central role. The utility company defines the number of
dunning levels for each dunning procedure and how they are determined. The
dunning level is stored in each open item and incremented with each dunning
notice.
5-51
You can combine the items in freely definable dunning groups and group them by
business partner, contract, or division. This allows you to send a business partner
a separate dunning notice for each division.
A dunning activity is initiated relative to the highest dunning level of all the items
in the dunning group. The dunning history, such as the last dunning date, is also
taken into account. You can also define dunning activities. A dunning letter is
printed in most cases. However, you can also create a workflow for a device dis-
connection or for starting legal dunning proceedings.
A dunning run determines the following:
The contract account to be dunned and its open items
The dunning level of the items in a dunning group
The dunning activities based on the dunning level concerned
Fig. 5-26: Determination of Dunning Level and Dunning Activity

In addition, dunning offers the following functions:
Dunning charges
The system can calculate dunning charges for each dunning notice, subject to
the dunning level of the open items and the creditworthiness of the business
partner. You can elect to post dunning charges to general ledger or as a statis-
tical document.
Dunning of budget billing requests
Dunning of installment plans
You can define that the system automatically deactivates an installment plan
or initiates an alternative dunning procedure (such as immediate disconnec-
tion) when a certain dunning level is reached.
5-52
Interest calculation
You can call interest calculation for the items subject to dunning from the dun-
ning run.
Reversal
You can reverse the last dunning. You can reverse either a complete dunning
run (for example, if the dunning notices have not yet been printed) or individ-
ual dunning notices (for example, if a business partner submits a complaint).
Dunning history
The dunning history contains the dunning data for each dunned item, such as
the dunning level of the processed items and the dunning amount. This en-
sures that you have a log of the dunning activities that were carried out.
Maximum and minimum amounts
With maximum and minimum amounts, you avoid dunning for very small
amounts.
Dunning block
You can exclude individual items or contract accounts from dunning. With
regard to the contract account, you can also impose a time limit on that block.
You can calculate interest on individual items both debit and credit items for Interest Calculation
the contract accounts of a business partner. This allows you to assess debit interest for Individual Items
for bad payment patterns and to reward good payment patterns with credit inter-
est.
During the interest run, the system calculates and posts interest, and the data
required for a customer notification is made available. The system can only calcu-
late interest if it can identify an interest key. The interest key controls interest cal-
culation and can be assigned to contract accounts, individual items, or dunning
levels.
You can calculate interest on the following items:
Open or cleared debit items and budget billing requests
Installment plans
Cash security deposits
Credit items, such as credit memos
Yearly advance payments on a budget billing plan
You can credit a business partner with a yearly advance payment bonus for pay-
ing in advance the total amount due under a budget billing plan (Release 4.51).
That bonus is calculated as part of interest calculation.
You can calculate interest on debit items using the following functions:
Individual processing
Interest is calculated on the items of a business partner or of a contract ac-
count.
Initiation from invoicing or dunning run
Interest calculation for cash security deposits in particular can be initiated
from invoicing. The interest is printed on the bill or the dunning notice.
Mass interest calculation
As of Release 4.51, you can call interest calculation from a mass run. In this
case, interest notifications are created.
5-53
For credit items, you can calculate interest only with individual processing.
Interest calculation also supports the following functions:
Maximum and minimum amounts allow you to avoid billing a business part-
ner for very small amounts.
Interests blocks allow you to exclude items or specific business transactions
(such as reversals) from interest calculation.
You can maintain individual interest rates for business partners or business
transactions.
You can post interest to the general ledger and post debit interest as a statisti-
cal posting.
The interest supplement records how the interest amount was determined.
The interest history records the interest calculation period for each item. This
ensures that interest on an item is calculated once only in any given period.
Deferral and Installment If a customer is unable to meet payment obligations, you can set up an installment
Plan agreement or a deferred payment agreement for one or more receivables.
In an installment plan, you define the number of installments, the individual
amounts of the installments, and their due dates. The system uses the individual
installments for dunning purposes or for a payment run instead of the original
receivable. When the customer pays the final installment, the system automatical-
ly deactivates the installment plan. However, you can also deactivate an install-
ment plan manually, in which case the original receivable is again used in pay-
ment settlement and dunning.
The functions available with the installment plan include the following:
You can create customer notifications.
You can delete installments that are still outstanding, change amounts and
due dates, and create installments.
You can accept partial payments toward installments.
The dunning run can deactivate an installment plan when a specific dunning
level is reached.
If you want to defer an open item, you can enter a date that is different from the
actual due date. The item is then given this deferral due date. As a result, that item
is neither dunned nor are payments collected. If the deferral date is exceeded, the
item continues to be dunned relative to the original due date, and the bank collec-
tion process resumes.
Write Offs Uncollectible receivables are written off. Credits can also be written off. It is planned
to support these functions as of Release 4.51.
Authorization control is used to define what an employee is allowed to write off:
Receivables
Credits and receivables
Receivables without final billing
5-54
Additionally, you can automatically write off credits and receivables of little value
as small amounts. You can define separate amount limits for writing off small
amounts for debits and credits.
Collective bills enable you to send documents relating to different contract ac- Collective Bill
counts or business partners jointly to a single collective bill recipient, who is re-
sponsible for making payments. The individual documents are grouped together
under a collective bill document number, which is used to identify all the individ-
ual documents. Collective bills are used, for example, for property management
companies, municipal authorities, and large companies.
Collective bills may be used for the following functions:
Invoicing or joint bills (cover sheet)
Payment settlement
Dunning
Reversal
Returns
In the collective bill contract account, the recipient and the payment and dunning
procedures are defined for all contract accounts that belong to that collective bill.
You can display not only the collective billing documents, but also the individual
documents. You can view individual items in the contract accounts of the relevant
business partner, and the total amount of a collective bill in the collective bill
contract account.
Business Services for Other Utilities

In a later release, two utility companies will be able to establish a mutual help Mutual Help
service, which will allow them to demand payment of outstanding bills by cus-
tomers who have relocated to the service area of the other utility.
If a utility company requests mutual help, a letter to the partner utility containing
an account statement for the relevant customer account is created. This process
does not change the actual items in the customer account.
If a utility company provides mutual help, a corresponding contract account has
to be created. A statistical item equal to the amount being requested can be posted
to that contract account. A subsequent incoming payment is then posted as an
open credit and can be transferred to the requesting utility as an outgoing pay-
ment.
In intercompany invoicing, one company is responsible for billing and collecting Intercompany Invoicing
payments for other independent companies. These companies generally present
themselves to the customer as a single unit. The customer receives a bill with
general ledger account assignments affecting more than one company code.
Intercompany invoicing requires that the contracts be allocated to the relevant
independent accounting units (company codes). You must specify a managing
company code for any shared accounts, such as cash clearing accounts.
5-55
Intercompany invoicing has an effect in the following cases:

Consolidated balance sheets
A corporate group bills its subsidiaries using various company codes. Those
company codes are then consolidated in the balance sheet.
Convergent billing
Convergent billing allows a utility to manage the services of other utility com-
panies and to include the billing amounts on its own bill. Examples include
waste disposal charges for city sanitation departments, cable charges for tele-
communications companies, and drainage charges for local-government wa-
ter alliances. Convergent billing is employed, in particular in deregulated util-
ity scenarios, when a company (generally the distribution company, the ener-
gy sales company, or a billing service company) invoices individual billing
line items (in addition to its own) or all the billing line items and carries out
collection for a third party.
The customer receives a joint bill for orders to the utility company, service
provider, and third party. The utility company handles open-item processing
for the services of the third party and forwards information and payments to
the appropriate third party.
The contract being processed for a third party is managed under a separate
company code, which is not reflected in the utility companys balance sheet.
The postings managed in that company code are of an informational nature
with regard to the third party.
Integration with the General Ledger

Because of the large volume of documents, posting in FI-CA does not entail imme-
diate updating of transaction figures in the general ledger. The FI-CA documents
are instead transferred in summary form to the general ledger of the Financial
Accounting component or to a non-SAP system. This improves performance and
limits the volume of documents in the general ledger.
As a result, when FI-CA documents are posted, special FI-CA documents, known
as totals records, are updated. The totals records are formed from the individual
FI-CA documents if permitted by the account assignment and posting data. All
the usual account assignments can be used in the FI-CA line item, for example,
from:
G/L accounting (company code, business area, and G/L account number)
Overhead cost management
Profitability analysis (for example, cost center, order, and project)
The totals records are allocated to a user-defined reconciliation key. You must spec-
ify the reconciliation key if you are posting manually. In mass processing, the sys-
tem creates it automatically and stores it in the document header of the FI-CA
document.
5-56
Fig. 5-27: Transfer of FI-CA Documents to the General Ledger

When a reconciliation key is closed, it is blocked for further postings. This means
that no other FI-CA documents can be entered in the totals records. A closed totals
record can be transferred to general ledger and posted there as an accounting
document. Since the reconciliation key is recorded in those Financial Accounting
documents, a link is created between FI-CA documents and FI documents. Conse-
quently, you can itemize the totals posted in general ledger and reconcile FI-CA
and the general ledger.
If a document is posted for a customer in FI-CA, automatic account determination Account Determination
determines the reconciliation account, the associated offsetting account, and one
or more tax accounts, and enters them in the document. These accounts corre-
spond to the G/L accounts to be posted in the general ledger.
During year-end closing, it is necessary to create an itemized list at the customer Reconciliation
level for the G/L accounts to which postings were made from FI-CA. This list is
created as notes to the balance sheet, which provide an explanation of the balanc-
es on the basis of the associated individual documents. The balances for the gen-
eral ledger accounts therefore need to be reconciled regularly with the balances
from the individual documents in FI-CA. Reconciliation between FI-CA and the
general ledger analyzes all the open item documents that belong to a totals record
and forms the corresponding totals. Any differences are logged and must be in-
vestigated.
A posting in FI-CA causes an immediate (synchronous) posting in R/3 Treasurys Cash Management
Cash Management (TR-CM) component. The liquidity forecast and the cash posi-
tion of the cash management function are therefore always current.
5-57
Controlling Documents that are generated in General Ledger Accounting when totals records are
posted are not different from normal Financial Accounting documents, and, therefore,
also result automatically in the updating of other ledgers and of Controlling.
Fig. 5-28: Integration with General Ledger, Controlling, and Cash Management
Closing Operations
Foreign Currency Valuation Foreign currency valuation recalculates the value of the current assets and payables
that were posted in a foreign currency. This means that the receivables and payables
accounts are corrected for balance sheet preparation.
Generally, foreign currency valuation operates on the items open on the key date,
that is, it uses single valuation. If this is not possible, the account balance is valuated.
You can run foreign currency valuation in the local currency and in any parallel cur-
rencies being maintained, such as the group currency or hard currency.
Doubtful Receivables Receivables valuation is an accounting procedure designed to recognize that the
posted value of a receivable may be different from the actual value of that receiv-
able. This function is planned for Release 4.51.
Receivables are divided into three groups:
Correct receivables
Valuation adjustment is not necessary for correct receivables.
Doubtful receivables
Doubtful receivables are entered in accounting as doubtful and, if necessary,
are adjusted individually by the probable lost amount of the receivable. No
document is created. Instead, the open item is identified as doubtful in IS-U/
CCS and the posting is forwarded to the general ledger. You can access infor-
mation on doubtful receivables and individual valuation adjustments via
contract account information.
If the valuation of an item is adjusted individually first, then the full amount
is automatically classified as doubtful.
Uncollectible receivables (see also Business Transactions/Write Offs)
Uncollectible receivables are written off in their full amounts. Any sales tax is
automatically adjusted. Statistical items, such as dunning costs, can also be
written off.
5-58
Information System
Account display gives the user an overview of the debit and credit items for a Account Display
business partner or contract account. Selection criteria (for example, cleared items
only or statistical items only) allow you to limit the selection of items to be dis-
played.
The following configuration variants control how the items are displayed:
Variants for open items determine which information is displayed.
Totals variants determine the criteria for the cumulation of individual items.
Sorting variants determine the sequence in which the items are displayed.
From the account display you can branch to the following areas:
Business partner, contract account, and contract
Dunning, returns, and clearing histories
Payment usage
Installment and budget billing plans
Original receivable of an installment plan
Fig. 5-29: Account Display

The following analyses in FI-CA are planned for Release 4.51: Analyses
Lists for notes on the balance sheet:
m List of open items based on key date
Open items are calculated and shown by customer and G/L account for a
key date (end of month, quarter, or fiscal year). The system also displays
the balance carried forward as of the last key date.
5-59
m Document aging structure list

A list of items open on the key date is created based on the due date. This
list is the basis for write offs and valuation adjustments as of the balance
sheet key date.
m Customers with credit balances
Customers with credit balances are identified for each receivables account.
This list is the basis for transfer postings to the payables account.
Analyses of the days business
It is important for the days business in FI-CA to analyze the document vol-
ume of the open items according to special criteria (such as overdue receiv-
ables). This allows you to initiate additional actions with regard to the cus-
tomer (such as manual disconnection).
Customer Service
As energy markets undergo liberalization, the fast and efficient processing of cus-
tomer inquiries becomes a decisive competitive advantage. The essential ingredi-
ents here are quick access to all the important customer data and an efficient user
interface that incorporates the latest technologies.
The most important component of customer service is the Customer Interaction
Center (CIC), the work environment in IS-U/CCS for employees in the front of-
fice or call center.
Customer Interaction Center (CIC)

You can control all the business processes in the front office via the CIC of IS-U/
CCS. The CIC gives you the capability to access almost all the important business
data and processes of your utility company, in particular the data and processes
that you manage in direct contact with the customer.
From the CIC you can carry out the following processes of customer contact man-
agement:
Identification
For example, searching for a customer, prospective customer, connection ob-
ject, or premise
Information or consulting
For example, information about payments, billing dates, contacts, and orders
Immediate execution of simple business processes
For example, creating an installment plan, entering a fault report
Start of a workflow
For example, setting up a service connection, including the creation of a quotation
Because front-office employees usually handle customer contact by phone, you
increase their efficiency in customer contact management enormously by inte-
grating telephone functions. Using an interactive user interface designed special-
ly for call center operations, CIC serves in IS-U/CCS as a router to all information
and process handling functions.
CIC also has an HTML-based customer overview, which you can configure freely
according to your own requirements within the preset categories.
5-60
IS-U/CCS/CCS is shipped with several standard configurations, which you can

also configure according to your own needs.
Call State
Data Finder
Business Data
User-Definable
Customer
Overview
Action Box
Fig. 5-30: The CIC Interface

The Call State component displays the current status of each caller. This gives you Call State
constant control over which caller is active, which caller is participating in a con-
ference call, and which caller is on hold.
It can also identify the number called (for example, the technical fault report or
energy consulting department). If the CTI middleware provides the callers num-
ber, the system can identify the caller, and display information (like the name) in
the Call State display.
Occasionally, the system cannot identify the caller because the caller may be call- Data Finder
ing from a different phone than the one listed in the system or because the caller is
a new customer who has not yet been entered into the customer file. In these
cases, you can use the Data Finder component. The Data Finder is a tool for search-
ing for IS-U data objects, such as business partners and connection objects.
The Data Finder uses powerful search functions across a large number of selection
fields to identify objects.
Consequently, you can search according to the following criteria:
Name and address of the customer
Address of the connection object or premise
Customer number
Social security number
5-61
In addition, you can:

Add any number of fields to the Data Finder (such as for a device number)
Combine search criteria as needed
Search with incomplete criteria (for instance, all names beginning with Ma)
Limit the search to specific objects (such as just the electricity division)
Conduct the search according to a search log
Example The Data Finder allows you, for example, to search for all customers who:
- Live on Main Street in a specific city and have a nonresidential contract
- Live at 32 Schiller Street on the third floor and receive water service
Business Data Display The Business Data Display is the memory area for managing all the business objects
(the callers customer or reporting data, service reports, sales order) and data that
has already been collected during the current customer contact. The Business Data
Display allows you to display at any time the details of various objects or to use
those objects to execute further actions.
User-Definable Customer The customer overview currently provides you with information about a custom-
Overview ers data at the following levels:
Customer
Contract account
Premises
Contracts
Below those levels, you can decide yourself which detailed information you need,
and you can make the corresponding settings in Customizing. Depending on the
settings you make in Customizing, you can obtain information on the following:
Bills
Rates
Balances
Budget billing plans
Consumption history
Customer contacts
Service reports or service orders
This new customer overview provides extremely flexible options for tailoring the
presentation of the relevant data on a customer to your needs. Your individually
designed HTML pages can be stored in the R/3 Web Repository and then en-
riched with current R/3 data at runtime. The finished pages are displayed in an
HTML browser control. This allows you to use all the design options provided by
HTML 4.0 for creating your own screens.
In addition, all the displayable R/3 data from the customer environment are avail-
able as JavaScript objects. You can therefore embed active components (like Java
applets and ActiveX controls) in an HTML page and supply them with R/3 data.
The JavaScript library shipped with CIC offers tools that display internal R/3
tables as HTML tables and implement HTML hyperlinks, which allow you to nav-
igate in R/3 business object methods. You can, of course, also construct links to
any other links to any Web pages in an intranet or the Internet.
5-62
The action box gives you access to all the transactions you need for your daily Action Box
work. This may be in the form of either information views, change actions, front-
office processes, or workflows that are executed or initiated from CIC. (For more
information, see the section on Front-Office Processes and Workflows).
You add the data for the customer or other object to the action. You do this either
by searching for a new object or by selecting an object that has already been edited
from the business data display. You can also configure an action in such a way that
you process data from the fields of the Data Finder. This capability is particularly
useful if you have added your own fields to the Data Finder.
The actions are organized by means of a register; you assign actions to different
registers in Customizing, for example, the information or change register.
Front-office processes allow you to model all the most common business process- Front-Office Processes and
es. Front-office processes are tailored exactly to the processing of specific business Workflows
transactions. All the important information and entry fields are displayed in just a
few screens.
A front-office process is a freely definable sequence of individual actions in which
data is passed on from step to step. These processes also accommodate a certain
degree of repetition and conditional processing.
Among the front-office processes and workflows covering the most common
business processes that are shipped in the standard configuration are:
Change customer data
Move-in and move-out
Interim bill
Technical initial data creation
Budget billing adjustment
Complaint about a bill (workflow)
Laying a service connection (a workflow with optional quotation creation)
Disconnection or reconnection (a workflow at request of customer)
More complex business processes that are run with time delay or are subsequent-
ly processed by more than one employee in the back office can be controlled with
SAP business workflows. Using the standard R/3 Systems Workflow Management
(BC-BEW-WFM), you can apply and create workflows. Depending on the
workflow, the process is executed with time delay (after the necessary events have
occurred) and by various employees.
For more information on these workflows, please refer to the section titled Business
Processes. Future releases of IS-U/CCS will support additional workflows.
The major differences between front-office processes and workflows are:
Front-office processes are not persistent, that is, their lifetime is limited to the
life of the calling front-office session. This reduces administration overhead
and improves runtime performance.
All the steps in a front-office process are executed by precisely one employee
the owner of the calling front-office session. This removes the need for the
clerk determination that is normal in the case of a workflow step.
5-63
However, a front-office process can also initiate a workflow to take over the sub-
sequent processing of the business transaction. If an employee is not responsible
for processing a particular customer request, the employee can also generate a
follow-up for the appropriate clerk, taking information that is then passed on as
reference information.
Integration of External Call Integration with external systems allows call center functions to be supported in
Center Systems CIC. The following functionality is available in addition to the CIC functionality:
Computer telephony integration (CTI)
The connection to appropriate CTI middleware allows not only incoming cus-
tomer calls, but also calls from the computer to be made
Intelligent voice response (IVR)
Through the use of IVR software, you can either answer inquiries directly, or
connect the customer to the appropriate person.
Automatic number identification (ANI) and caller line identification (CLI)
The connection to CTI middleware allows you to identify incoming calls auto-
matically.
These call center functions are considerably enhanced when implemented togeth-
er with SAPphone, which enables conference calls, call forwarding, consultation
calls, and call back.
Fig. 5-31: Connecting CIC to Additional Technologies
Customizing You can use Customizing to integrate additional information views in CIC and to
define your own front-office processes and workflows. You can combine the steps
shipped by SAP and the steps that you develop in-house.
You can adapt the CIC with a variety of configurations to the usage site concerned,
such as a different CIC for customer window and field service. This means that
you can handle a business transaction in the front office or the back office where
enhanced processing options may be available. Depending on the organizational
5-64
structure of your company, various scenarios can be implemented for processing

business transactions:
Parking in the front office, processing in the back office
Entering and processing simple transactions in the front office, processing large
transactions in the back office
Entering and processing in the back office
Customer Environment
You can use the CIC action box to call up a graphical display of the environment
for a particular customer.
Overviews provide you with all the data on a customer or a connection object.
Environments show which installations, contracts, budget-billing plans, and so
on are allocated to a customer, connection object, or device. You can branch from
those information screens to other views that give detailed information about in-
dividual subareas.
With the IS-U/CCS Navigator (see section titled Information System), you can cre-
ate environments for additional objects and determine how finely segmented the
displays for any given environment will be.
Fig. 5-32: The Environment of a Business Partner
5-65
Business Processes
Predefined business processes allow you to process with a high level efficiency
those customer-related actions that occur most frequently in a utility company.
The following business processes can be integrated in the front office and called
from there:
Initial data creation for a premise
Customer consolidation
Disconnection and reconnection
Rate maintenance
For a detailed description, please refer to the section titled Business Processes.
Customer Contacts
IS-U/CCS can automatically log customer contacts. This applies equally to con-
tacts originated by the customer like phone calls and to contacts initiated by
the utility company like written notifications or dunning notices. The genera-
tion of customer contacts usually takes place automatically within an action.
Fig. 5-33: Classification of Customer Contacts into Contact Classes and Contact Action
While dealing with a customer, you can create a reference to data objects. For
example, a complaint about a bill can contain a reference to that bill. You can use
the note function to enter notes on a customer contact, such as the reason for a
budget-billing adjustment.
5-66
In order to classify customer contacts, you can define various contact classes (such
as complaints or service) in Customizing. You can also assign various contact types
to those classes to define actual processes, such as budget billing changed, install-
ment plan created, or information provided.
Customer contacts can be listed according to contact class and time period. Anal-
ysis of customer contacts provides information about the efficiency of the business
processes and the capacity utilization of the customer service representative.
Marketing
Starting with Release 4.51, IS-U/CCS will offer marketing functions in connection
with the integration of functions from the standard R/3 System. These functions
are based on the storage of customer or prospective customer (customer with no
contract accounts or contracts) information that is relevant to marketing. This in-
formation can be collected during customer contacts in customer service offices or
during field service work (for example, for customers with outdated heating sys-
tems) or derived from existing contracts (for all customers in gas service territo-
ries who do not use that type of service). SAP also plans to connect IS-U/CCS to
the SAP Marketing component.
The important characteristics of this system support for marketing are:
Additional fields in business data
Information on the targeted market segment of a company is often very in-
dustry specific. Therefore, a system that is supposed to support a market strat-
egy must be very flexible when collecting and organizing market data.
In addition to the designated information and attributes for sales support,

you can also collect customer-specific data in the following relevant entities of
IS-U/CCS:
Business partner
Contract account
Premise
Individual rate category
Customer contact management
Customer contact management supports marketing by collecting and analyz-
ing customer-specific information that may be relevant to expansion of the
business relationship. Relevant information about a potential need for supply
or other services can be recorded in sales call reports and analyzed specifically
according to various criteria.
Active marketing
Marketing activities are actively supported by the system starting with Re-
lease 4.51. This is largely achieved by utilizing the Sales Support (SD-CAS) com-
ponent in IS-U/CCS. As a result, you can execute mailing and telemarketing
campaigns for selected target customers or prospects. You can also monitor
the response to mailing campaigns.
5-67
Products and product catalog (Release 4.51 and higher)

You can model your companys services as products that are collected togeth-
er in a product catalog. If a customer wants to change a service or use a new
service or product, you can select the appropriate product, and the system
then automatically initiates all the actions, changes, and subsequent transac-
tions. This makes customer processing resulting from changes in service sim-
ple and efficient.
Product Catalog Example For example, suppose a customer wants to change from a single-rate meter to a
double-rate meter. You select the appropriate product, the system automatically
generates a service order for reading and dismantling the old meter and for in-
stalling the new meter. It also changes the service contract, assigns a new rate, and
initiates a confirmation letter.
Analyses and data extracts
Through the IS-U/CCS Information System, you can create the necessary anal-
yses for sales support. It allows you to edit data for sales employees according
to such criteria as divisions, regions, and so on and to download that informa-
tion to non-SAP systems.
Work Management
In a utility company, large numbers of work orders are received, planned, costed,
executed, and in some cases, billed to the customer. To manage those orders, IS-
U/CCS uses existing functions from various components of the standard R/3
System. These functions are combined in Work Management to form IS-U/CCS-
specific business processes, to which industry-specific functions are then added.
Work Management uses an especially large number of functions from the Plant
Maintenance and Service Management component. For a detailed description of those
functions, refer to the application help documentation for Plant Maintenance.
Work Orders
There are two types of work orders, external work orders, which relate to the
customer (services), and internal work orders.
External work orders are generated upon customer request or as the result of con-
tracts concluded with customers. They are modeled using service orders from the
Service Management component. Examples of external work orders are:
Creation and amplification of service connections
Energy consulting
Unplanned meter readings
Meter or device replacement upon customer request
Disconnection and reconnection (electricity, gas)
Services resulting from customers maintenance contracts (for example, pre-
ventive maintenance of a gas plant)
5-68
Internal work orders relate to the utility company itself and are modeled using
maintenance orders from the Maintenance Order Management (PM-WOC) compo-
nent. Examples include:
Internal maintenance tasks
Repairs
Installation, modification, or removal of technical equipment belonging to a
utility company (for example, a warehouse)
Both types of work orders are referred to below simply as orders.
To create an order efficiently, IS-U/CCS uses.
Fig. 5-34: Interaction of the Work Management Components

The following components from the standard system are used in work manage-
ment:
Plant Maintenance and Service Management
Planning, control, and processing of preventive maintenance and inspec-
tion
Maintenance and service management of technical systems and installati-
ons delivered to customers
Sales and Distribution
Sales activities through flexible functions for pricing, quotation processing,
order processing, and on-time delivery
Direct link to profitability analysis
5-69
Project System (PS)

Coordination and control of all phases of a project from quotation to plan-
ning and approval, to resource management and billing in conjunction with
Purchasing and Controlling
Subledger accounting for managing the large number of customer accounts
Periodic transfer of posting transactions to the general ledger
Asset Accounting
Integrated system of planning, controlling, and monitoring instruments ap-
plied to a companys internal processes and capital investment measures
Interfaces
The openness of the R/3 System also enables you to incorporate non-SAP systems
into the business processes:
Geographical information systems (GIS)

An interface in the Plant Maintenance and Service Management component enables
you to exchange data between a geographical information system (GIS) and tech-
nical objects (equipment and functional locations). Business and technical data is
managed in the Plant Maintenance component, while graphical and geographical
data is managed in the GIS.
This means that in the area of energy distribution you can couple connection ob-
jects and connections with a GIS. In the area of energy transmission, transformer
plants, transformer stations or line segments, for example, can be linked to an
object in a GIS.
You can find a list of the GIS providers and GIS systems currently authorized for
these interfaces in SAPNet.
Scheduling and Dispatching Systems (CADS Systems)

You can use non-SAP systems to schedule large numbers of short-term orders
(such as aperiodic meter reading, disconnection, or meter replacement). These
external systems computer-aided dispatching and scheduling systems or CADS
systems schedule the orders and allocate them to work groups. Orders are often
downloaded to mobile data appliances, such as handheld devices or laptops).
The CADS system carries out detailed planning and distribution of orders on the
basis of certain criteria. These criteria include:
Required skills
Distance between the location of the employee and the site
Priorities
Fixed deadlines
5-70
The interface to a CADS system consists of:

The transfer of the order data from the R/3 System to the CADS system
The transfer of confirmation information (such as time or material) and of
status information from the CADS system to the R/3 System
Information on the current processing status of an object in either direction.
Outage Management Systems (OMS)

An outage management system (OMS) analyzes customer-reported outages in
the supply grid. When it detects an accumulation of outages in a given segment of
the grid, it determines whether the cause is a central outage (such as a transformer
failure). The OMS can manage the correction of an outage and identify all the
customers affected. It does this using the connectivity model, which is the model
of all the connections or operational conditions in the supply grid.
The interfaces to an OMS are based on those used with a CADS system. In addi-
tion, the following functions are included:
The return of the outage data for the object concerned
A list of customers affected by the outage
It may also be important to transfer data about customers and their devices from
the R/3 System to the OMS.
Master Data
Service territory data is needed for the planning, executing, and billing orders. It Service Territory Data
is stored in the postal regional structure. In addition to geographical data, service
territory data also includes institutional and billing-related data.
Examples of service territory data include:
Soil condition
Approval data
Building authorities
Construction cost subsidies
You usually access service territory data using an address. You can integrate com-
pany-specific data using a simple extension concept.
A compatible unit is used as a simplified means of creating frequently recurring or- Compatible Units
ders, such as laying a service connection. The compatible unit is modeled in work
management by a configurable task list (or more precisely a general maintenance task
list in Plant Maintenance). Once it is configured, the task list is included in the order,
which means that all the data belonging to the task list is then available in the order.
A compatible unit consists of:
A description of the compatible unit
A list of operations
A list of materials and production resources
A schedule for the installation, modification, or replacement of a compatible unit
Billing information
A list of required documents
5-71
Service Product Service products describe a service that is offered to customers. A service (materi-
al) master record describes the service and also contains price information. Since
the service has to be either provided by the utility itself or purchased from a third
party, a configurable task list is assigned to the service master record.
Product Configuration Starting from a manageable number of standardized products, the service is con-
figured to the requirements of each individual customer. The characteristics of the
configuration define the service product and also specify exactly how the task list
is converted to a work order.
Fig. 5-35: Service Product and Configuration for a Service Connection
Order Processing
Order Creation As soon as the data for the order description has been entered, order creation runs
largely automatically. To do this, the system uses, among other data, the informa-
tion stored in the service territory data and compatible units.
The configuration of the task list allows you broad flexibility when you create the
order. It therefore represents the compatible unit in concrete form.
A configuration is made up of a number of characteristics, such as the length of
the connection or the meter. You either provide these manually, or the system
provides them automatically. When you generate orders, automatic characteristic
value assignment enables you to transfer data from non-SAP systems via stan-
dard interfaces without changing the program.
Relationships between the individual elements of the compatible unit are described
by object dependencies (for example, between the soil condition and the type of
cable).
5-72
The following options are supported for order creation:

Order with customer reference
You can directly enter an order for a sales order item. The system uses the
configuration in the sales order item to create the order automatically. In this
process, you can use all the functions of the Sales Order (SD-SLS-SO) compo-
nent. This makes it possible to create several orders simultaneously for a giv-
en customer.
Technical reference objects
You can assign a technical reference object to certain orders. The system can
use the configuration data of the technical object to describe the order. You can
also create a new technical object via an order.
Order hierarchies
The system can generate order hierarchies in order to model more complex
orders. This can be done by using a multilevel configuration to evaluate nest-
ed compatible units and to incorporate them into the orders.
You can estimate the costs of a sales order. First, you create a customer quotation. Estimated Costs
Then the system calculates the costs of the service order and transfers them to the
customer quotation.
In customer quotation costing, a quotation for the relevant service is created for Customer Quotation Costing
the customer. The system can derive the quotation price from the configuration of
the product (flat-rate processing). Alternatively, it can calculate the price by indi-
vidual costing of the work order and then transfer it to the quotation.
The system determines the default values for the account assignment of an order Account Assignment
and enters them in the order. Examples of account determination keys include:
Order type
Technical reference object
Service territory
Division
The Task Lists (PM-PRM-TL) component primarily supports orders with relative- Work Scheduling
ly long runtimes, such as laying a service connection, or installation extension of
an installation. The worklist of preplanned orders is scheduled for work groups
or individuals. To do this, the work scheduler uses the planning board, which is in
the form of a table or graphic. The flexible layout of the planning table allows you
to display the contents in detailed or compressed form and to enter additional
data for each user.
Scheduling for the large numbers of short-term orders is handled via a link to
non-SAP systems. (For more information, see Interfaces).
Once the work is completed, you can bill the customer. You can create the bill Billing
either in reference to the sales order or to the quotation (flat-rate processing) or, to
reflect actual expenses, on the basis of the consumed resources in the work order.
The functions used are those from billing in the Sales and Distribution component.
5-73
Other Functions
Work Management supports the subsequent allocation of construction cost subsi-
dies to the customer. Construction cost subsidies are shown on quotations and bills
and posted to the relevant accounts when payment is received. To process subse-
quent allocations, the system stores the awarded construction cost subsidies for a
given supply area and takes account of them when creating new connections.
In the utilities industry, a number of processes must be handled separately. Subse-
quent processes cannot be executed without them. Such processes include:
Approvals
Before an order can be executed, it may be necessary to obtain approvals from
authorities or other institutions or companies. As soon as all the approvals
have been obtained, work can begin.
Traffic flow operations
Certain orders require temporary changes in traffic flow operations. In such
cases, not only do approvals have to be obtained from the appropriate author-
ities, but additional work, such as closing a road, is also required.
Mark-outs
When work is done on a section of street, digging may affect the transmission
lines of other companies. Those lines are marked on the surface of the street.
Mark-outs may be carried out by the utility company itself or requested by

other companies.
The data for these processes is once again provided by the compatible units and
service territory data.
Waste Management
A waste disposal company provides various types of waste management services.
The spectrum of services includes periodic services, such as the regular collection
of waste from containers, and also aperiodic services, such as on-call collection
requests.
These business processes are implemented in the R/3 System using the Waste
Management (IS-U-WA) component of IS-U/CCS. This component also uses func-
tions from the Service Management component. For a detailed description of those
functions, refer to the brochures for Service Management and Plant Maintenance.
Service Orders
All aperiodic services are modeled by service orders.
Examples include:
On-call collection of waste from a container
Delivery of an empty container and the simultaneous removal of a full con-
tainer
Delivery of a new container
Removal of a container when service is terminated
5-74
Once an order has been created, the necessary resources, such as vehicles, drivers
and containers, can be transferred to an external scheduling and dispatching sys-
tem. This is a non-SAP system that is linked by interfaces to Waste Management,
and that enables the assignment of orders to vehicles, plus scheduling and route
planning for those orders. Since geographical factors play an important role in
cost optimization, a link to an external geographical information system is also
provided for as of Release 4.51.
Fig. 5-36: Interaction of the Waste Management Components

The following standard R/3 components are used in Waste Management:
Service Management
Planning and processing services
Maintenance and service management for special purpose containers
Sales and Distribution
Sales activities through flexible functions for pricing, order processing, and
on-time delivery
Direct link to Profitability Analysis
Subledger accounting for the management of a large number of customer
accounts
Periodic transfer of posting transactions to the general ledger
Service Contracts
Periodic services for commercial customers are modeled by service contracts. Ex-
amples include:
Periodic collection on fixed dates of waste from a container
Periodic replacement of a full container with an empty container
The service contract data relevant to planning, such as service, service address,
and service day, is transferred to an external route planning program that creates
an optimum route.
5-75
You can combine service contracts with aperiodic services from service orders.
The resulting order data is forwarded via interfaces to external route planning
and scheduling systems.
IS-U/CCS Contracts
Periodic services for residential customers are modeled by IS-U/CCS contracts.
An example of this is periodic collection on fixed dates of waste from a container.
The IS-U/CCS contract and its associated objects are particularly well suited to
modeling simple contract conditions as a result of the lean data storage in the R/
3 System. This means that high-performance processing is possible even with large
amounts of customer master data.
As of Release 4.51 you can forward the resulting order data via interfaces to exter-
nal route planning and scheduling systems.
Interfaces
To achieve efficient route planning, it is necessary to link to external geographical
information systems and planning systems (Release 4.51).
Geographical information systems
A waste management interface allows service address data to be forwarded to
an external GIS. The scheduling and dispatching system uses the geo-coordi-
nates to determine the routes.
Scheduling and dispatching systems
These non-SAP systems are used to plan aperiodic orders and to execute route
planning for periodic orders. Orders are scheduled according to criteria and
resources, including the following
Available resources, such as vehicles, drivers, and containers
Required skills
Distance between service address, garbage dump address, and vehicle lo-
cation
Priorities
Fixed deadlines
Master Data
Container Data The resources necessary for the optimization process are stored in the R/3 Sys-
tem. Examples of container data include:
Maximum load volume and weight
Dimensions
Compaction factor of compactor
You can integrate company-specific data by using a simple extension concept.
Vehicle Data The resources necessary for the optimization process are stored in the R/3 Sys-
tem. Vehicle data constitutes a particular restriction with regard to the ability to
meet the deadlines of an order.
5-76
Examples of vehicle data include:

Use
Maximum load weight and volume
Dimensions
You can integrate company-specific data by using a simple extension concept.
A person can be defined as a driver or co-driver. Using skills data, the system can Personal Data
automatically identify suitable individuals for specific orders. The scheduling and
dispatching system actually selects and assigns individuals to vehicles. Examples
of personal data include:
Working hours
Skills
Identification data
The term service frequency refers to the regularity with which a service (such as Service Frequency
collection of waste from a container) takes place. SAP has developed a new trans-
action that allows management of the service data at the container level so you
can model service dates for the containers.
You can maintain the service frequency either for an installation of the division
category waste management or for a service order from the Sales and Distribution
and Plant Maintenance and Service Management application components. Before you
can create the service frequency, you must allocate containers either to the instal-
lation or to the service contract.
You can transfer the dates resulting from the various service frequencies to the sched-
uling and dispatching system for optimal resource and route planning purposes.
Service products describe a service that is offered to the customer. A material master
record is defined, which describes the service and also contains price information. Service Products
Typical services are, for example, waste collection from a certain type of container
or from a specific container. The service product describes the actual service. If
that service references a specific object, such as a special purpose container, that
reference object is specified separately in the order.
Order Processing
For aperiodic service requests, you enter individual orders. The service to be pro- Aperiodic Service Requests
vided is assigned as a material, and appropriate vehicles can be assigned in the
order. Once the order data has been entered, it is forwarded directly or at regular
intervals to the external scheduling and dispatching system. The external system
determines the available resources from the R/3 System and executes the sched-
uling of the order.
Periodic service requests are modeled in the R/3 System as service contracts or IS- Periodic Service Requests
U/CCS contracts. The service to be provided is also assigned to the contract as a
material or reference value. At the same time, service days are assigned to the
service product. This data is forwarded at regular intervals to the scheduling and
dispatching system.
The external system determines the available resources from the R/3 System and
executes the route planning for identical service requests.
5-77
Information System
IS-U/CCS maintains statistics on the master data and the most important pro-
cesses and therefore provides fast access to all the relevant data of a utility compa-
ny. This data can be analyzed and displayed graphically.
IS-U/CCS provides you with stock statistics, transaction statistics, and sales sta-
tistics. The data needed for the individual statistical analyses is stored in separate
files; the sales statistics are integrated with the Logistics Information System (LIS)
component.
You can use LIS analysis tools in the evaluation of any of the three types of statis-
tics. You can even use non-SAP programs (such as Microsoft Excel) for analysis
purposes. In addition, user exits are available for enriching the statistics with in-
formation from other applications and data editing operations in the utility com-
pany. Integration with the SAP Business Warehouse (SAP BW) component is planned
for a later release.
Statistics
Stock Statistics Stock statistics reflect the current stock of master data in IS-U/CCS. The system
also maintains other statistics (for example, devices or reference values). In the
case of master data managed with histories, the current time slices are always
determinative.
Example of Stock Statistics You can list the current stock of utility installations with a given installation status
for a company code and division. You can also list stock according to political
areas of the regional structure.
Transaction Statistics Transaction statistics are updated on a monthly basis, with the execution date
(current date) of the transaction or process being the determining date. Statistics
are managed for such activities as:
Master data
Initial data creation
Bank and dunning data
Installation and removal
Billing
Example of Move-In You can determine the number of move-ins entered in a given month differentiat-
Determination ed according to company code, billing class, rate category, and political regional
structure.
Sales Statistics You use sales statistics to create the necessary analyses, required statistics, and
statements for associations and organizations, showing the quantities sold and
the resulting sales revenues. These statistics are based on the billing documents
that are created in billing and then invoiced.
The following information is covered:
Billed quantities and amounts
Discounts
5-78
Surcharges
Price components that are not posted separately (for example, franchise fees
in Germany)
Original quantities (for example, before conversion from operating cubic meters
to standard cubic meters for gas)
This ensures that the quantities and amounts used in billing are also included in
the sales statistics.
The data is reduced to its statistically relevant parts and transferred to the Logis-
tics Information System. From this data, the relevant information is compiled and
summarized for the analyses in question.
Since requirements vary from utility company to utility company, IS-U/CCS con-
tains a number of sample statistical reports. Additional statistical analyses are
easy to design to meet individual company needs.
The analyses are based on, for example, the following key fields or characteristics:
Company code
Division
Rate
Price
Industry
Planning
Planning is expected to be available with Release 4.51. It contains functions for
forecasting and unbilled revenue reporting.
Unbilled revenue reporting determines expected sales revenue for a closing bal-
ance period. In addition to quantities and sales revenues already billed, you can
calculate quantities and sales revenues that have not yet been billed. This kind of
reporting is very important, especially in rolling annual billing.
Reporting
IS-U/CCS reporting provides standard reports in ready-made format for all func-
tional areas. Availability of this function is planned for Release 4.51. The reports
are based on selection parameters that retrieve the data in a predefined sequence
and with specific information content according to the functional area or related
topics. The system supports further selections made on the basis of these data
extracts.
A number of standard reports are already available. These include monitoring
billing orders, an open item list (with the option of sorting by due date), and a
periodic replacement list.
However, you can also create customized reports, queries, and ad hoc reports in
IS-U/CCS using ABAP/Query and Report Writer.
For information on ABAP/Query and Report Writer, refer to the documentation
for the R/3 Basis Services/Communication Interfaces (BC-SRV) component.
5-79
FERC Reporting
FERC reporting simplifies the reporting process in the US for reports to the Feder-
al Energy Regulatory Commission (FERC).
IS-U/CCS Navigator
The IS-U/CCS Navigator allows you to obtain a quick overview of the data envi-
ronment of any given IS-U/CCS object by graphically displaying the interrela-
tionships between the individual data objects. To review an example, refer to the
section Customer Service/Customer Information.
Among other things, the Navigator can display:
All the contract accounts, contracts, utility installations, and devices belong-
ing to a customer
All the premises in a connection object, with the associated installations and
customers
You can use each data object displayed as a starting point to navigate further. As a
result, you obtain an overview of the data objects environment. This means that
you can start from a customer associated with a specific premise and determine
what other premises that customer has. Starting from any given entry point, you
can navigate through the entire data environment.
Tools
Print Workbench
The Print Workbench enables you to print not only letters that have a simple logical
structure, but also forms constructed on the basis of a complex data hierarchy. On
the one hand, it is very flexible and meets a wide range of needs. But on the other
hand, it is also a high-performance tool that supports the mass printing of forms.
The flexibility of the Print Workbench is based on the following elements:
Form classes
Form classes are data structures that are preset for specific applications. They
contain all the data that can be used in the application forms that are associat-
ed with them. Bills, welcome letters, and meter reading documents are exam-
ples of form classes.
Form classes are shipped as a part of IS-U/CCS. However, you can also create
your own form classes if you have experience with ABAP and relational data-
base technology.
Application forms
Application forms are created on the basis of form classes. You can define
more than one application form for each form class, for example, different
bills for residential customers, nonresidential customers, and employees. IS-
U/CCS contains a number of sample forms that you can use as models for
your own application forms. User exits allow you to adapt application forms
to meet your needs.
5-80
Print action records

You can use print action records to add to your notifications without having
to make changes to the application forms. If you want to send additional in-
formation to certain customers, or if you want to insert flyers as part of a
promotion, you can use print action records. They contain information speci-
fying which text or which flyer is to be printed and how many times.
The Print Workbench uses the word processing functions of SAPscript to print ap-
plication forms. SAPscript either edits the data itself and sends it to the printer, or
it transfers the data to the raw data interface. In that case, a non-SAP system han-
dles layout and printing.
The print manager is used to manage (combine, delay, and cancel) print requests.
It should be fully available with Release 4.51.
Migration
The first-time transfer of master and transaction data, that is, migration, from
your old system to IS-U/CCS takes place via an open interface. Migration is per-
formed according to the requirements of IS-U/CCS, which means that neither the
data model nor the functional concept of the old system are needed or used.
To guarantee data consistency following migration, the data is grouped according
to business process criteria to form migration objects and then transferred to IS-
U/CCS. Object-oriented transfer of data is made possible by the service function
modules of the IS-U/CCS business objects. These are modules that use direct in-
put, thereby avoiding the performance disadvantages of batch input.
Fig. 5-37: Migration to IS-U/CCS
5-81
Structures are assigned to a migration object. The structural organization of the

migration objects is defined in IS-U/CCS. Since the structures are located in the
Data Dictionary, customer enhancements can be processed.
Because IS-U/CCS does not understand the data model of your old system, you
need a program to extract data from the legacy system. That program does not
have to edit the data in accordance with the IS-U/CCS data model; it simply needs
to make it available with the correct type parameters (for example, INT with length
10). You define the layout of the data records in the migration workbench. SAP
programs are available for extracting data from RIVA.
The following functions support migration:
Test functions
Transferred data is first tested using a small number of data records. To do
this, you create new data records so that you do not need any data from your
old system. As soon as the data has been transferred with no errors, you de-
velop the program for extracting the data from your old system.
Documentation
The structural form of the migration objects is documented in detail and can
also be displayed as a list. You can print out the list and the documentation
and export it to other programs, like Microsoft Excel.
In addition to the normal field documentation, there is migration-related doc-

umentation of the fields in the migration objects. This documentation tells
you, for example, which fields must be supplied with data and which fields
do not require data.
Status information
You can obtain information about the status of the migration and find out, for
example, which data has already been successfully transferred.
Tabs
Tabs simplify screen configuration. They allow you to define which entry fields
you want to display on the screen and in what sequence. There are tabs for such
objects as the following:
Contract
Device category
Meter reading order
Move-in
A tab contains a number of pages that themselves contain field groups. You can
assemble different pages together to make views. You can then easily switch from
one view to another.
5-82
The assignment of the input fields to the field groups is preset. You can set any-
thing else either in Customizing or via the IS-U/CCS menu.
Fig. 5-38: Hierarchy of a Tab
Notes
Notes are used to record non-standardized additional information on individual
IS-U/CCS entities, such as utility installation, contract, or premise. In notes you
can record actions that have to be performed for a future event or information that
has to be transferred to the next employee.
Notes are edited using SAPscript. You can define the number and type of notes
per entity in Customizing.
History
You can use the history function to maintain various statuses of certain IS-U/CCS
entities (such as installations) in the system. These statuses are valid for a certain
time slice so that you can recover the status of a given entity at a selected time.
This way, you can enter changes to entities that will apply in the future. The histo-
ry function also enables you to correctly manage in the system information that
became known late.
In order to manage historical data for entities, the system stores the date as of
which and the date until which the stored status is valid. The change date is also
stored for information purposes.
However, a new time slice is not created for every change. For each entity type,
the system specifies which field changes generate new time slices. However, chang-
es made to entities or fields can be recorded in change documents even if those
changes do not result in a new time slice.
5-83
Logs
IS-U/CCS distinguishes between errors that occur in individual processing and
those that occur in mass processing. If an error occurs in individual processing,
the procedure is terminated, and the system displays an error message. If an error
occurs in mass processing, the procedure is only terminated if the error is serious.
In all other cases, the entity with the error is skipped and the next entity is pro-
cessed. The errors that occur are logged.
5-84

Basic Function Important

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Basic Function Important

Enviado por

Direitos autorais:

Formatos disponíveis

5 Scope of Business Functions

Budget Billing Plan

Fig. 5-21: Budget Billing Procedures Supported by IS-U/CCS

Fig. 5-22 Printout of Budget Billing Forms

Including External Billing Documents in Invoicing

Contract Accounts Receivable and Payable

In addition, documents can be posted to multiple company codes. This enables

Fig. 5-23: Overview of Payments Processing

Fig. 5-24: Creating Payments using the Payment Program

Fig. 5-25: Processing a Return

Payment reminders, or dunning notices, remind business partners of overdue Dunning

Fig. 5-26: Determination of Dunning Level and Dunning Activity

Business Services for Other Utilities

Intercompany invoicing has an effect in the following cases:

Integration with the General Ledger

Fig. 5-27: Transfer of FI-CA Documents to the General Ledger

Fig. 5-29: Account Display

m Document aging structure list

Customer Interaction Center (CIC)

IS-U/CCS/CCS is shipped with several standard configurations, which you can

Fig. 5-30: The CIC Interface

In addition, you can:

Fig. 5-31: Connecting CIC to Additional Technologies

structure of your company, various scenarios can be implemented for processing

Fig. 5-32: The Environment of a Business Partner

In addition to the designated information and attributes for sales support,

Products and product catalog (Release 4.51 and higher)

Fig. 5-34: Interaction of the Work Management Components

Project System (PS)

Geographical information systems (GIS)

Scheduling and Dispatching Systems (CADS Systems)

The interface to a CADS system consists of:

Outage Management Systems (OMS)

Fig. 5-35: Service Product and Configuration for a Service Connection

The following options are supported for order creation:

Mark-outs may be carried out by the utility company itself or requested by

Fig. 5-36: Interaction of the Waste Management Components

Examples of vehicle data include:

Print action records

Fig. 5-37: Migration to IS-U/CCS

Structures are assigned to a migration object. The structural organization of the

In addition to the normal field documentation, there is migration-related doc-

Fig. 5-38: Hierarchy of a Tab

Você também pode gostar