Bill and Payment Processing

New Deregulation Functions:
Bill and Payment

Processing
SAP Utilities
1
Rechnungsstellung und Zahlungsabwicklung
This document describes the new deregulation functions in the Intercompany Data Exchange
component (SAP IS-U/IDE). These are template solutions and, if necessary, can be changed to meet
country-specific requirements.
The functions described in this document can be implemented globally, even if the German market is
referred to specifically in certain examples.
The new deregulation functions are available with the following support packages:
• Release 4.64 as of Support Package SAPKIPUJ17 (IS-U/CCS 464: patch 0017)
• Release 4.71 as of Support Package SAPKIPUK06 (IS-U/CCS 471: patch 0006)
All menu paths or Customizing paths are valid as of SAP IS-U 4.71.
In SAP IS-U/CCS 4.64, you have to call the relevant transactions directly. To make your Customizing
settings, call the relevant maintenance object using the transaction codes specified.
2
Table of Contents
1. Infrastructure: Bill and Payment Processing ................................................................................... 5
2. Bill Creation ..................................................................................................................................... 7
2.1. General Conditions ...................................................................................................7
2.2. Process Flow ............................................................................................................8
2.2.1. Posting Individual Customer Documents ..........................................................8
2.2.2. Aggregated Posting Taking Statistical Budget Billing Plans and Partial Billing
Procedures into Account ...................................................................................................8
2.2.3. Creating the Aggregated Bill...........................................................................10
2.2.4. Writing Off and Doubtful Entries .....................................................................11
2.2.5. Sending the Bill...............................................................................................13
3. Incoming Payment......................................................................................................................... 16
3.1. General Conditions .................................................................................................16
3.2. Process Flow ..........................................................................................................16
3.2.1. Payment Advice Note Receipt ........................................................................16
3.2.2. Additional Scenario.........................................................................................18
4. Dunning the Supplier ..................................................................................................................... 29
5. Bill Receipt..................................................................................................................................... 32
5.1. Process Flow ..........................................................................................................32
5.1.1. Identification of Header Data ..........................................................................32
5.1.2. Identification of Document Data......................................................................32
5.1.3. Check Before Information is Copied ...............................................................32
5.1.4. Copying Information........................................................................................33
5.1.5. Check After Information is Copied ..................................................................33
5.1.6. Data Transfer..................................................................................................33
5.2. System Settings......................................................................................................33
5.2.2. Additional Scenarios .......................................................................................34
6. Outgoing Payment......................................................................................................................... 39
6.2. Process Flow ..........................................................................................................39
6.2.1. Read Service Provider Agreement .................................................................39
6.2.2. Execute Aggregated Posting ..........................................................................39
6.2.3. Execute Payment Run ....................................................................................41
6.2.4. Creating Payment Advice Notes .....................................................................42
6.2.5. Sending the Payment Advice Note .................................................................42
7. Manual Processing of Bill and Payment Advice Note Data........................................................... 46
7.1. Manual Entry of Bill and Payment Advice Note Data..............................................46
7.1.1. Prerequisites...................................................................................................46
7.1.2. Manual Entry of Bill Data ................................................................................46
7.1.3. Manual Entry of Payment Advice Note Data...................................................47
7.1.4. Manually Changing Bill and Payment Advice Note Data ................................48
7.1.5. Manually Changing Bill Data...........................................................................48
7.1.6. Manually Changing Payment Advice Note Data .............................................48
7.2. General Functions of the Dialog Transactions........................................................48
7.3. Bill/Document Status ..............................................................................................51
7.3.1. Bill/Payment Advice Note Status ....................................................................51
7.3.2. Bill/Payment Advice Note Document Status ...................................................51
7.3.3. Possible Actions Depending on Status ...........................................................52
7.4. Authorizations .........................................................................................................54
8. Appendix........................................................................................................................................ 55
3
8.1. Function Modules for Processing Documents ........................................................55

8.1.1. Introduction .....................................................................................................55
8.1.2. Identification Modules .....................................................................................55
8.1.3. Check Modules Before Data is Copied ...........................................................56
8.1.4. Copy Modules.................................................................................................57
8.1.5. Check Modules After Data is Copied ..............................................................59
8.1.6. Transfer Modules............................................................................................59
8.1.7. Complaint Modules .........................................................................................60
8.1.8. Reversal Modules ...........................................................................................60
8.1.9. Display Modules .............................................................................................61
8.1.10. Other Modules ................................................................................................61
8.2. Legend for Flowcharts ............................................................................................62
4
1. Infrastructure: Bill and Payment Processing

In the deregulated energy market, distributors send grid usage bills and budget billing requests to
suppliers for clearing. This includes the following processes:
Process Short description

Billing party Bill creation • Billing and invoicing for
grid usage at individual
(Distributor)
customer level
• Aggregated posting of
receivables to supplier’s
account
• Sending bill to supplier
Incoming payment • Processing incoming
payments from supplier
• Receipt of payment
advice notes
• Processing complaints
regarding the bill
Dunning • Dunning the supplier
Bill recipient Bill receipt processing • Processing received bills
(Supplier) • Checking bills (formal
check and contents
check)
• Copying data required for
own bill
• Communicating
complaints regarding the
bill
• Reversing the bill
Outgoing payment • Posting bills
• Arranging payment to
distributor
• Sending payment advice
notes
In SAP IS-U/IDE, the terms processing service provider and service provider market partner are used
instead of distributor and supplier.
The processing service provider is the service provider who executes the processes (for example,
registration/termination of grid usage, bill/payment advice note receipt processing) in his system. The
processing service provider is always the Service Provider in Own System.
The market partner is the other service provider, with whom the processing service provider has a
business relationship and communicates data. The market partner can also be a Service Provider in
Own System (in affiliated companies, for example).
Distributors and suppliers can both be either processing service providers or market partners
depending on the current perspective and the role they play in the marketplace.
5
For the remainder of this document we will, for clarity and readability purposes, continue to use the
terms distributor and supplier, which describe the roles that the parties play in the marketplace.
The individual processes are described in further detail in the order in which they appear above.
6
2. Bill Creation
This section describes the process of bill creation. This includes:
• Billing and invoicing for grid usage at individual customer level
• Posting aggregated receivables to the supplier’s account
• Sending bills to the supplier
In a deregulated market, the distributor bills the contract partner (generally the supplier) for
consumption billings, budget billing requests, and other postings for the points of delivery to which the
supplier supplies energy. For monitoring purposes, the receivables that are posted to a supplier’s
account are aggregated. This results in the following requirements:
• Bill creation for statistical budget billing requests or partial bill and consumption billings
• Verification of the cleared budget billing payments in consumption billing
• Point of delivery-related sending of messages (VDEW-INVOIC, for example)
• Periodic generation of full bill documents or account billings for the supplier (that is, with or
without a detailed list of individual receivables at end customer level)
• Option to choose the communication format for the individual bill including a form class for
printing full bill documents or account billings
• Enhancements to the account balance display
2.1. General Conditions

Contracts that are settled by a third party can belong to contract accounts that are entered as tenant
accounts in a collective bill. Documents that are posted to these contracts, and documents allocated to
contract accounts that are also settled by a third party are, however, not included in the collective bill.
This restriction is useful for affiliated companies that map grid contracts and supply contracts in one
contract account, even though they belong to separate companies. In this case, the supply contract
can be included in the collective bill. Affiliated companies can include the supply contract (generally
the contract that is directly settled by the end customer) in the collective bill without having to change
its allocation to the grid contract (generally the contract that is settled by a third party service provider).
The system does not process “mixed print documents” for affiliated companies that use the two-
contract model (that is, print documents that contain items to be invoiced to the end customer as well
as items to be invoiced to the company’s “own” supplier) for the following reasons:
• The processing of mixed print documents would have an impact on bill creation and bill printout.
This would cause repercussions for individual customers and suppliers.
• Even though the bills would be processed together, the budget billing plans would have to be
generated separately.
Therefore, you must create a separate print document for the grid contract.
You cannot reverse aggregated posting in the standard solution, as it is generally only necessary to do
so if program errors occur. If you need to reverse an individual customer bill, you only reverse the bill
in question and then repost it with a new aggregated document. The aggregated document in which
the bill was originally included, is not changed.
7
2.2. Process Flow

Invoicing/
Invoice reversal
Set print
lock
Enhance with
Request Information from Docs
BB amounts/Reversal supplier
EDI
contract account
Invoic
Other postings/
Define
Reversal
Data for comm. channel Paper bill
aggregated Yes + format
posting/
Sending bill
Other
Grouping of items/ Group with file
Consumptn formats
send bill Yes other items,
billing?
individually set status Send individually?
No
BB
No Yes Set status
request?
End
No
Trigger
Aggr. docs
aggr. No
posting
Account billing aggr.

Invoice
or Yes Read aggregated bill document
supplier
full bill docs
account
2.2.1. Posting Individual Customer Documents

The above process controls the individual customer posting if the Service Provider and the Invoicing
Service Provider fields in the contract contain different values, and if a payment class is specified. You
must specify that you want a bill to be created by setting the Inv.SP (invoicing service provider)
parameter to active in the corresponding service provider agreement.
If the posting is for consumption billing, a print lock is set in the print document. You can override the
print lock in event R412.
The item is written to an intermediate table (DFKKTHI). This table can contain customer-specific fields
that can be filled using an enhancement (Event Posting: R202; Event Reversal: R203).
2.2.2. Aggregated Posting Taking Statistical Budget Billing Plans

and Partial Billing Procedures into Account
You carry out aggregated posting in transaction ETHIM.
Items are aggregated if the following data is the same:
• Sender
• Recipient
• Due date for the supplier
• Activity (Invoice/other vs. budget billing request)
• Transaction currency
• Company code
8
You can create other groupings or individual postings for specific customers in the service provider
agreement. You can use the following as grouping characteristics:
• Point of delivery group
• Billing class
• Account determination ID
The grouping characteristics are automatically taken into account for aggregated postings. In order to
ensure a clear overview of the supplier accounts, we recommend that you use as few additional
grouping criteria as possible, as this increases the number of postings to these accounts.
You can set the individual posting flag for every grouping characteristic that you have defined. As a
result, a separate document is created in the invoicing service provider’s contract account for all
individual customer postings with this characteristic. We recommend that you only set this flag for
characteristics that are not likely to get many postings. If a large number of individual postings are
generated for the invoicing service provider’s contract account, the account will become complicated
and it will take longer to call the account balance display.
2.2.2.1. Prerequisites
• Document items from the individual customer accounts have been electronically sent or
processed using transaction REDISND1 or MEER.
• The selection date for the aggregated posting includes the planned date of payment by a third
party.
• The account determination for internal main transaction 4000 and its internal subtransactions
has been maintained.
Note that, for all subtransactions of the main transaction, you can only use one G/L account in
posting area R001 for each company code and account determination characteristic. In this
case, enter the Clearing Account from the example below.
This clearing account is used later on for payment distribution.
2.2.2.2. Posting Logic

...
1. Receivables posted to individual accounts

2. Aggregated posting to service provider’s contract account (in this case the supplier)
3. Cash received by bank
4. Clearing of service provider account (3. and 4. are one step in Contract Accounting)
5. Clearing of individual accounts using the distribution lot (from the service provider’s payment
advice note or from the bill processing data)
6. Receivables on individual account reversed
7. Aggregated posting that generates a credit memo for the supplier account
8. Payment created
9. Receivables posted to individual account to take back payments that have already been made
10. Cash paid by the bank (10. and 8. one step in IS-U)
9
Customer 1 Customer 2 Receivables Revenues

(1) 100 100 (5) (1) 80s 80 (5)
(1) 180 180 (5) 180 (1)
(9) 100 100 (6) (6) 100
(9) 100 100 (6)
Supplier 1 Supplier Clearing Clearing

(2) 180 180 (4) (2) 180 180 (4) (5) 180 180 (2)
(8) 100 100 (7) (8) 100 100 (7) (7) 100 100 (9)
Receipt by Bank
(3) 180
100 (10)
Bank Settlement
FI-CA FI
(4) 180 180 (3)
(Subledger) (General ledger) (10) 100 100 (8)
Note:
For clarity reasons, postings to the customer accounts in the example do not include taxes or budget
billing requests.
Taxes and additional account assignments are posted in the same way as standard postings at
individual customer level.
The aggregated posting to the supplier’s contract account is not a statistical posting. Posting occurs in
the general ledger via two clearing accounts, which must be balanced at the end of the year.
Aggregated posting uses gross amounts. Taxes are posted to the individual customer account. When
you create a list of open items, do not include the aggregated postings, as this will distort the actual
amounts.
2.2.3. Creating the Aggregated Bill

Since, for technical reasons, aggregated postings should occur regularly (preferably on a daily basis)
but aggregated bills are created less regularly (weekly or monthly), several posting documents from
the supplier account are combined in the aggregated bill. In Germany, this combined document is only
used for information purposes. Generally, only the individual bills are relevant. In other countries,
however, the combined document has bill characteristics, so that invoicing the supplier account
generates a separate billing object with its own number assignment, the option of repeat printing, as
well as an independent archive.
Therefore, a print document is generated that references all incoming documents posted to the
supplier account. You can trigger bill printout from the bill document.
10
The combined document consists of the following elements:

Sum of individual bills
- Cleared down payments
+ New budget billing requests
+ Other items
+ Tax*
End total
* This is the sum of the tax amounts from the individual bills. It cannot be calculated from
the end total because of possible rounding differences.
In the full bill procedure, all individual bills are issued in their complete form, that is, including meter
readings and consumption values. The bill recipient needs the complete bill information for the bill
receipt check.
In the service provider agreement, you can choose to send the individual bills separately so that the
combined bill is only relevant for account billing. You can also choose not to create aggregated bill
documents.
If you want to send aggregated bills in printed format, you must generate an application form for form
class IS_U_IN_AGGR_BILL. This form is entered in the supplier’s contract account.
In addition to bills and budget billing requests, bill reversals can also be communicated to the supplier.
If you want to send individual bills in printed format, you must enter a suitable form from
form class IS_U_BILL in the service provider agreement. You also define whether
individual bills are sent in printed format or as IDocs in the service provider agreement.
2.2.4. Writing Off and Doubtful Entries

2.2.4.1. Writing Off
Individual items are not automatically excluded from being written off. You can, however, use event
5010 to prevent items from being written off for specific customers.
If individual items are written off anyway, the supplier is not informed. An aggregated posting to the
supplier’s account takes place in order to keep the account balance consistent.
2.2.4.2. Doubtful Entries and Individual Value Adjustment

It is not possible to create doubtful entries or adjust individual values for aggregated receivables.
There is no restriction for individual items.
2.2.4.3. Effects on Billing

Unavailable billing functions: Adjustment Reversal
The Adjustment Reversal function is not permitted because the electronic data exchange formats do
not recognize it. In addition, we cannot assume that the market partner uses an SAP system. In some
cases an adjustment reversal would not be possible.
If necessary, you can fully cancel and then repost bills.
11
2.2.4.4. Effects on Invoicing

Unavailable invoicing functions:
{ The transfer posting of receivables/credit to receivables/credit for consumption billing
does not take place.
{ You can only invoice manual billing documents if an automatic billing document exists for
the same contract.
Available with restrictions (as of SAP IS-U 4.64 AOSP 017):
{ Period-end billing
You can only invoice a separate period-end billing if the cross reference number was
assigned in invoicing rather than in billing. The cross reference number is assigned in
invoicing as standard.
2.2.4.5. Effects on the Budget Billing Plan

Special features:
{ In order to ensure that the budget billing plans are taken into account when the bill is
created, you must select the Dereg. Active field in Customizing:
(Customizing for SAP Utilities → Invoicing → Budget Billing Plan → Define
Control Parameters for Budget Billing Amount (field TE633-DEREG_ACTIV)
{ You can only bill the invoicing service provider once a budget billing request has been
made. Technically, table DFKTTHI is only updated when the budget billing request is
made.
{ Until then, the contract accounting document items of the budget billing plan contain the
clearing restriction “P” (Not payable before budget billing request (deregulation)). The
contract accounting document does not contain any repetition items.
Unavailable functions:
{ The due dates are not combined in the event that several budget billing amounts are
requested.
{ You cannot reset the change lock once a budget billing request has been made (this is
possible for “normal” budget billing plans).
{ If a due date has been requested, you can no longer delete the budget billing plan.
{ You cannot change the amounts when you change the budget billing plan (transaction
EA62). This includes entering amounts directly at cumulated level and at contract level
as well as using the pushbuttons.
{ Unlock item (Change Budget Billing Plan (transaction EA62))
{ Cycle change (Change BB Plan (transaction EA62))
{ Activate prepayment (Change BB Plan (transaction EA62))
{ Automatic budget billing amount adjustment (transaction E61M or report REASBSL1)
{ Interim billing with budget billing amount adjustment (invoicing)
{ Rate maintenance (transaction EC30)
{ Adjustment to changed dates (Portion Change (transaction EA65))
{ Yearly advance payment
Available function:
{ Extend budget billing plan
12
2.2.4.6. Effects on Contract Accounting

Unavailable functions for the line items of the contract accounts receivable and payable that are
paid by a third party service provider (generally for all document line items that contain a service
provider that invoices the contract):
{ Transfer open items
{ Submit to collections agency
{ Dunning of individual customers
{ Payment run for individual customers (item ID 151: Bill processing by third party
(deregulation))
The payment block reason from posting area R070 is used.
Note that this payment block is not in the item itself but is only used during the run.
{ Creditworthiness update by writing off items
Special features:
You can only use the account maintenance to clear document line items that contain an
invoicing service provider for items that have the same invoicing service provider. The same
applies for all incoming payment transactions. The only exception to this rule is the payment lot,
as long as it is a distribution lot
You cannot reverse or write off aggregated postings.
2.2.5. Sending the Bill

2.2.5.1. Preparation
...
1. Define an identification type. For this identification type, define external IDs for the received
service types and then allocate them to line types.
(Customizing for SAP Utilities under Intercompany Data Exchange → Bill and Payment
Advice Note Processing → Define ID for Bill and Payment Advice Note Parts; transaction
SM34, VC_EDEREG_SERINT)
The ID type and the main transactions, subtransactions, and document line types defined
for it are used to determine the ID of the provided service.
2. Define a service provider agreement for the distributor. You define service provider agreements
using the Change Service Provider transaction.
(In the SAP Easy Access Menu choose Utilities Industry → Intercompany Data Exchange
→ Service Provider → Change; transaction EEDMIDESERVPROV02)
Use a service provider agreement type that is based on the deregulation process INV_OUT.
(Customizing for SAP Utilities → Intercompany Data Exchange → Service Provider
Agreements → Define Service Provider Agreement Types; transaction SM30,
V_EDRGSPAGRTYPE)
(Also see Customizing for SAP Utilities → Tools → System Modifications → User-
Defined Enhancements for IDE → Define Deregulation Processes; transaction SM34,
VC_EDEREGPROC)
Use a suitable parameter value for the Bill Issue parameter (for example, send individual bills
before aggregated posting).
Enter an identification type.
Enter a contract account for aggregated bill posting and define a separate bank connection for
the account.
13
3. Define a data exchange process for the distributor.

This data exchange process should be based on basic process INV_OUT. You must also define
an appropriate data exchange format for the data exchange process. In the German market, for
example, you can use the VDEW_INVOIC format, for which function module
ISU_COMPR_VDEW_INVOIC_OUT and IDoc basic type ISU_VDEW_INVOIC are defined.
(Customizing for SAP Utilities → Tools → System Modifications → User-Defined
Enhancements for IDE → Define Data Exchange Basic Processes; transaction SM34,
VC_DEXBASICPROC)
(Customizing for SAP Utilities under Intercompany Data Exchange → Data Exchange
Processes → Define Data Exchange Processes; transaction SM34, VC_DEXPROC)
4. You must define a partner profile before you can send an IDoc. To do this use message type
ISU_BILL_INFORMATION as the output parameter.
(In the SAP Easy Access Menu choose Tools → Business Communication → IDoc Basis
→ Administration → Partner Profile; transaction WE20)
2.2.5.2. Execution
Starting Bill Issue
You can start the bill issue process using the Generate Electronic Bill transaction or the mass activity
of the same name.
→ Electronic Bill → Generate Electronic Bill; transaction REDISND1
or
In the SAP Easy Access Menu choose Utilities Industry → Intercompany Data Exchange
→ Electronic Bill → Mass Activity: Generate Electronic Bill; transaction MEER)
Monitoring Bill Issue

You can monitor bill issue using the Monitoring of Data Exchange Tasks transaction.
(You can find the Monitoring of Data Exchange Tasks transaction in the SAP Easy
Access Menu under Utilities Industry → Intercompany Data Exchange → Data Exchange
Processes → Monitoring; transaction EDATEXMON01)
If formal or technical errors occur during bill issue, you can find more information in the IDoc List
transaction.
(You can find the IDoc List transaction in the SAP Easy Access Menu under Tools →
Business Communication → IDoc Basis → Display IDoc; transaction WE02)
2.2.5.3. Notes
• IDoc processing takes place when you use the VDEW_INVOIC format in function module
ISU_COMPR_VDEW_INVOIC_OUT. The format and the function module are used as a copy
template for customer-specific changes.
You can define customer-specific formats and modules in Customizing for basic process
INV_OUT:
Enhancements for IDE → Define Data Exchange Basic Processes)
• You must enter the external number of the distributor and of the supplier for identification
purposes:
14
15
3. Incoming Payment
This section describes the process of incoming payment. This includes:
• Receiving and processing payment advice note and complaint data
• Incoming payment
• Clearing receivables at supplier and end customer level

An automatic clearing of receivables at supplier level can only be synchronized with the clearing of
receivables at end customer level with restrictions.
The system does not support the clearing of individual items based on incoming payments from the
supplier for items at end customer level. These items can only be cleared by creating and posting
payment lots.
Reversals (from complaint processing, for example) are always processed in a new aggregated
posting. You should take this into account for bill complaints if a direct debit authorization exists. This
is because the payment run always posts the original billed amount, which is only reduced by the
reversal credit memo value on a subsequent due date.
You cannot post lots immediately if the settings specify that the individual items are only posted on
receipt of aggregated payment from the supplier.
3.2. Process Flow

Receiptof
paymentadvice
notes and
complaints
Payment
Or
advicenote Create Distribution Clearindividual Posting
and complaint distribution lot lot accounts document
data
Yes
Generation frombill
processingdata
Agent
Clearsupplier Check
Incomingpayment Available? No notification
account distribution lot
workflow
Reprocess Check Process

Justified? Yes
data complaint complaint
No
Clarify
3.2.1. Payment Advice Note Receipt

Payment advice note data and complaint data is sent to the distributor electronically (Receipt of
Payment Advice Notes and Complaints).
Alternatively, you can enter the payment advice note data manually.
For more information on manual entry, see the “Manual Processing of Bill and Payment Advice
Note Data” unit.
VDEW format REMADV, for example, supports the electronic transfer of payment advice notes. You
can also use this format to exchange information regarding unpaid bills. You use the Difference
16
Reason and Corrected Bill Amount fields for this purpose. If you use this function, the information is
saved and can be used in case of dispute.
You can also use other electronic formats in addition to the REMADV format.
Payment advice notes can also be received in printed format. If this is the case, however, you must
enter the data manually.
As a general rule, the information exchanged is payment advice note information. There are, however,
times when it is not necessary to exchange payment advice notes (if the supplier account has a direct
debit authorization, for example, or if the supplier is a Supplier in Own System). In these cases, the
payment lot for clearing individual items can be created from the communication data used in billing
the supplier (generation from bill processing data). The distributor can normally assume that a
complete incoming payment will follow. The option to remove queried items from the payment lots is
still available.
The payment advice note contains information regarding paid and partially paid bills. This data is
saved when the incoming payment is processed. A payment lot is then created from the data for
payment distribution (Create Payment Lot). When you create the payment lot, you must specify one of
the following points in addition to the payment advice note ID:
• Only create lot
• Close lot immediately
• Post lot immediately
The relevant payment advice note items are read and copied to the items of one or more payment lots.
The posting of the lots is dependent on the conditions of an incoming payment from the supplier. This
takes place in Contract Accounting by means of an enhancement event. The sending supplier must be
defined as a service provider in the distributor’s system.
If the bill is processed within a company, without using cash, a distribution lot is generated and posted
directly for all open items allocated to the company’s own supplier (clearing individual accounts). Items
from the supplier account can be cleared using a payment run with clearing account posting. Another
example of where you can create and post the distribution lot directly is if the distributor is authorized
to automatically debit the supplier’s account. In this case, a payment run would clear all open items on
the supplier’s account and the distribution lot could be created and posted directly in order to clear the
individual accounts. An incoming payment advice note is not required.
All open items on the end customer’s account are flagged in the system as To Be Paid by Third Party
Service Provider. The items cannot be cleared by individual payments at this level. The only way to
clear these items is to post the payment lot that was created by the distribution run described above.
3.2.1.1. Preparing for Receipt of Payment Advice Notes

...
1. Define a data exchange definition for the supplier that is based on basic process IMPREMADV.
For example, use data exchange format REMADV, for which function module
ISU_COMPR_PEXR2002_IN and IDoc basis type PEXR2002 are defined.
VC_DEXBASICPROC)
2. You must define a partner profile before you can receive an IDoc. For the input parameter, use
message category REMADV with message variant ISU. You can use ISU_REMADV_IN as the
process code. This is based on function module ISU_COMEV_PEXR2002_IN.
17
3.2.1.2. Execution
The system can receive the payment advice note automatically. You can monitor IDoc receipt using
the IDoc List transaction and you can monitor receipt processing using the Monitoring of Data
Exchange Tasks transaction.
You can find the IDoc List transaction in the SAP Easy Access Menu under Tools →
Business Communication → IDoc Basis → Display IDoc (transaction WE02)
You can find the Monitoring of Data Exchange Tasks transaction in the SAP Easy
Processes → Monitoring (transaction EDATEXMON01)
You can monitor the further processing of received payment advice notes in the Monitoring Bill Receipt
transaction (transaction INVMON) and start further processing manually for individual payment advice
notes.
3.2.1.3. Notes
• If you use format REMADV, the IDoc is processed in function module
ISU_COMPR_PEXR2002_IN. This module serves as a copy template for customer-specific
modifications. You can define customer-specific formats and modules in Customizing for basic
process IMPREMADV:
Enhancements for IDE → Define Data Exchange Basic Processes) (transaction SM34,
VC_DEXPROC)
• You must enter the external number of your own service provider and of the supplier for
identification purposes:
In the SAP Easy Access Menu choose Utilities Industry → Intercompany Data Exchange
→ Service Provider → Change (transaction EEDMIDESERVPROV02)
3.2.2. Additional Scenario

3.2.2.1. Receipt of the Electronic Complaint Notification
...
1. Define a partner profile with partner type LS (logical system), message category REMADV, and
message variant ISU. For example, you can use process code ISU_REMADV_IN, which is
based on event module ISU_COMEV_PEXR2002_IN.
In the SAP Easy Access Menu choose Tools → Business Communication → IDoc Basis
→ Administration → Partner Profile (transaction WE20)
2. Define a data exchange process for basic process IMPREMADV and set parameter
INV_AVISTYPE to R. Add this data exchange process to the supplier’s service provider
agreement in order to receive the complaint notification. For example, you can use data
exchange format REMADV, which is based on process module ISU_COMPR_PEXR2002.
VC_DEXBASICPROC)
18
The distributor receives a complaint notification in the same way as a regular payment advice note,
with the exception that it is not possible to create a payment lot from the complaint note. As a result,
the complaint notification is processed manually.
3.2.2.2. Incoming Payment

The items from the supplier’s account are cleared (Supplier Account Cleared) once payment has been
received (Incoming Payment). A check determines whether or not a corresponding distribution lot
exists (Check Payment Lot). If no distribution lot exists, or if it does not correspond with the incoming
payment, a message is generated and sent to the responsible agent (Agent Notification Workflow).
Alternatively, the distribution run can be started in the background by means of a user-defined
workflow template. You can find the corresponding events in object type IUEEPLOT01.
If the distribution lot does correspond to the incoming payment, the payment lot is posted and the
items from the individual accounts are cleared (Individual Accounts Cleared). Once this subprocess is
complete, payment is posted. The items are cleared at the level of the supplier and the individual
customer. If returns need to be processed at aggregated payment level, a reversal with clearing reset
occurs on the supplier’s account. Since the relevant receivables have already been cleared at this
point, you must use a mass reversal to reset the distribution run.
3.2.2.3. Complaint Processing

You can monitor and postprocess received payment advice notes and complaint data (Postprocess
Data). You can save information regarding unpaid or partially paid bills in REMADV inbound
processing. You can enter the data manually for other formats and communication channels (for
example, telephone). The verification check for a complaint is a separate process that is supported by
the system (Check Complaint).
If the complaint is justified, the original receivable item from the corresponding end customer account
is reversed. If payment is made anyway and a distribution run takes place, the amount paid is posted
to the contract or contract account in question. The aggregation run for the subsequent period
includes the reversal. The supplier is notified of this in the follow-up bill. This does not affect the
reinvoicing of the incorrect amount.
If the complaint is not justified, the individual items are sent to manual clarification processing. The
item is given the status Clarify Manually and is not relevant for payment lot creation.
At the end of the subprocess, the complaints have been dealt with, and either the bills have been
corrected or the supplier has canceled the complaint.
3.2.2.4. Creating Distribution Lots from the Payment Advice Note

Creating distribution lots from payment advice notes is part of Bill and Payment Advice Note
Processing. It is executed as a subprocess in the Transfer Data process step. First, you must define a
transfer group in Customizing and also define function module ISU_DEREG_INV_TRANS_AVIS1 as a
process module.
Advice Note Processing → Define Process Control; transaction SM34,
VC_INVRCPT_CUST)
System Settings
Preparation
...
1. Setting the parameter values for distribution runs

You set the parameter values for executing distribution from the payment advice note in
Customizing for distribution type Distribution from Payment Advice Note.
(Customizing for SAP Utilities under Intercompany Data Exchange → Payment Control
→ Define Parameter(s) for Distribution of Aggregated Payments; transaction SM30;
IUEEDPPLOTAVPPV)
19
For more information read the Customizing Changes document, which you can find in
the SAP Service Marketplace under http://service.sap.com/utilities. Choose Product
Information → IS-U/CCS → Intercompany Data Exchange → Cookbooks&Guidelines.
2. Settings for interpreting a payment advice note item
You make the settings for the interpretation of a payment advice note item in Customizing for
the algorithm ID. This is the identification used in Customizing. The algorithm ID is defined in the
service provider agreement.
→ Define Algorithms for Interpretation of Payment Advice Note Items; transaction SM34;
VC_IUEEINA)
3. Defining the parameters for the Bill Issue/Incoming Payment (INV_OUT) deregulation process in
the service provider agreement of the participating service providers.
You must enter values for the following parameters in all parameter configurations of the
agreement between the service providers playing a role in distribution (the supplier sends the
payment advice note and the distributor receives payment):
(In the SAP Easy Access Menu go to Utilities Industry → Intercompany Data Exchange
{ CA Aggr.BillPo. (Contract Account for Aggregated Bill Posting)
The contract account for aggregated bill posting is created for the bill recipient (payment
advice note sender) with a contract account category for invoicing service providers. The
postings for the distribution lot take place for the leading company code in the contract
account. This company code is also used to check other details, such as whether the
Clearing Account Aggr./Payment Distribution was created in this company code.
{ Clearing Account Aggr./Payment Distribution
The Clearing Account Aggr./ Payment Distribution is used in the general ledger as an
offsetting account for postings to the supplier’s reconciliation account. Since the account
is used as a bank clearing account in all distribution lots, you must define it in
Customizing as a bank clearing account for payment lots for the leading company code
of the contract account for aggregated bill posting.
(Customizing for Financial Accounting → Contract Accounts Receivable and Payable →
Business Transactions → Payments → Incoming/Outgoing Payment Processing →
Define Bank Clearing Accounts for Payment Lots; transaction FQZT)
{ Post Distribution Lot
The Post Payment Lot parameter controls whether distribution lots are posted
immediately or whether they can only be posted on receipt of aggregated payment from
the service provider that invoices the contract. The aggregated payment is classed as
received once the payment documents posted to the contract account of the invoicing
service provider have been allocated to the distribution lots by means of the Process
Distribution Lot (Aggregated Payment) function.
(In the SAP Easy Access menu, choose Utilities Industry → Intercompany Data
Exchange → Generate Postings and Display Account Balance → Processing Distribution
Lot → Process Distribution Lots (Aggregated Payment); transaction
IUEEDPPLOTAALC3)
...
20
To activate the Post Payment Lot parameter, select Post Lot as the further processing
step for distribution type Distribution from Bill Processing in Customizing.
IUEEDPPLOTAVPPV)
{ Algorithm ID
The algorithm ID is the identification used for interpreting payment advice note items in
Customizing (see bullet point 2: Settings for interpreting a payment advice note item).
Execution
Start Bill and Payment Advice Note Processing from the following transactions:
• Monitor Payment Advice Note
Exchange → Bill and Payment Advice Note Processing → Monitor Bill/Payment
Advice Note Processing; transaction INVMON)
...
1. Select the payment advice note that you want to process and navigate to the document
display.
2. Choose Process Data to create the distribution lot.
3. Choose Log to display the status and the messages.
4. In the event that errors occur, you can reset the status manually by choosing Reset Status.
You can now reexecute the process.
• Manual Payment Advice Note Entry
Exchange → Bill and Payment Advice Note Processing → Enter Payment Advice
Note; transaction INVADV01)
Once you have made the entries, you use the same interface for process execution as the one
described in Monitor Payment Advice Note.
• Mass Process Bill and Payment Advice Note Processing
Exchange → Bill and Payment Advice Note Processing → Mass Process
Bill/Payment Advice Note Processing; transaction INVMASSPROC)
...
1. In the Run identification group box, make entries in the Date ID and ID fields.
2. Enter 002 (Payment Advice Note) as the type of bill/payment advice note (PAN).
3. Enter selection criteria for the sender and recipient of the payment advice note and, if
necessary, for the due date and the document status.
Note that the original recipient of the bill is now the sender of the payment advice note
(Field: Int. ID of Bill Sdr).
4. Save your entries and start the mass process.
5. You can display the status and messages on the Logs tab page under Application Log.
3.2.2.5. Creating Distribution Lots from the Bill

You use the Create Distribution Lot from Bill function if the service provider that invoices the contract
does not send a payment advice note. In this case, set the Auto PAN parameter in the service
provider agreement.
21
Lot → Create Distribution Lot from Bill Processing; transaction IUEEDPPLOTAALC2)
System Settings
Preparation
...
1. Setting the parameter values for distribution runs

You set the parameter values for executing distribution from the payment advice note in
Customizing for distribution type Distribution from Bill Processing.
IUEEDPPLOTAVPPV)
2. Defining the parameters for the Bill Issue/Incoming Payment (INV_OUT) deregulation process in
the service provider agreement of the participating service providers.
You must enter values for the following parameters in all parameter configurations of the
agreement between the service providers playing a role in distribution (the supplier sends the
payment advice note and the distributor receives payment):
{ CA Aggr.BillPo. (Contract Account for Aggregated Bill Posting)
The contract account for aggregated bill posting is created for the bill recipient (payment
advice note sender) with a contract account category for invoicing service providers. The
postings for the distribution lot take place for the leading company code in the contract
account. This company code is also used to check other details, such as whether the
Clearing Account Aggr./Payment Distribution was created in this company code.
{ Clearing Account Aggr./Payment Distribution
The Clearing Account Aggr./ Payment Distribution is used in the general ledger as an
offsetting account for postings to the supplier’s reconciliation account. Since the account
is used as a bank clearing account in all distribution lots, you must define it in
Customizing as a bank clearing account for payment lots for the leading company code
of the contract account for aggregated bill posting.
Business Transactions → Payments → Incoming/Outgoing Payment Processing →
Define Bank Clearing Accounts for Payment Lots; transaction FQZT)
{ Auto PAN
The Auto PAN parameter controls whether the distribution lot can be created from bill
processing.
If the parameter is activated, the bill processing data is treated as an automatic
payment advice note (Auto PAN).
If the parameter is not activated, a payment advice note is required to distribute
aggregated payments. In this case, the Create Distribution Lots from Bill
Processing function is terminated.
22
{ Post Distribution Lot

The Post Distribution Lot parameter controls whether distribution lots are posted
immediately or whether they can only be posted on receipt of aggregated payment from
the service provider that invoices the contract. The aggregated payment is classed as
received once the payment documents posted to the contract account of the invoicing
service provider have been allocated to the distribution lots by means of the Process
Distribution Lot (Aggregated Payment) function.
IUEEDPPLOTAALC3)
...
To activate the Post Distribution Lot parameter, select Post Lot as the further processing
step for distribution type Distribution from Bill Processing in Customizing.
IUEEDPPLOTAVPPV)
It only makes sense to post the distribution lot immediately for affiliated companies or if a
direct debit authorization exists. This is because, in all other cases, an immediate posting
would make it more difficult to keep track of the receivables in the event that payment is
not made.
23
Execution
...
1. Call the Create Distribution Lot from Bill Processing transaction.

Lot → Create Distribution Lot from Bill Processing; transaction IUEEDPPLOTAALC2)
2. Make entries in the following group frames:
{ Run identification
A distribution run is identified by the values of parameters Run Date, Time, and Run ID.
Run Date/Time: The current system date and the current time are used as default
values. You can overwrite both values.
Run Identification: The 10-figure run ID is a freely definable code. The input help
for this field takes into account the parameter values that you entered in the Run
Identification, Run Date, and Time fields.
If you did not enter any values in these fields, the selection is not restricted.
If you made entries in the Run Identification and Run Date fields, all runs are selected
that took place on the specified date with the specified ID. If you made an entry in the
Time field, all runs are selected that took place within one hour before or after the
specified time.
The run identification also makes up part of the search criteria for the created distribution
lot. The search criteria consists of the fixed value THI-RUNKEY of the run ID and the run
date. This makes it easier to search for distribution lots that belong to a certain
distribution run.
{ Proration of Aggregated Bill
Enter selection criteria for the aggregated bill. These criteria are:
Bill Sender: Internal ID of the sender of the aggregated bill (sending service
provider)
The input help only offers values that are defined in the system as Transfer
Records for Bill Processing by Third Party (table DFKKTHI).
Bill Recipient: Internal ID of the bill recipient (receiving service provider)
Again, the input help only offers values that are defined in the system as Transfer
Date of Bill Processing: Date on which the bill was transferred to the third party
Aggregation Document: Document number of the aggregated bill posting to the
contract account of the bill recipient
Individual Contract Account/Individual Document Number: Proration of the
individual contract accounts or individual bill documents that are to be cleared by
distribution
{ Distribution Control
Value Date: The date the value was entered.
If a value date is requested in the field status group of the general ledger account,
it is required for posting a payment document. Therefore, enter the value date for
the distribution postings.
24
• Percentage of Sum to Distribute: This refers to the portion of the total amount that
will be distributed. Distribution on a percentage basis is necessary if a business
partner is unable to pay the full amount owed, for example.
• Check Distribution Lot: This indicator controls whether or not items are copied to
the distribution lot.
The system saves the reference between the bill item and the distribution lot item
for all items that are copied to the lot. If these items are distributed again at a later
point, you can check whether distribution lots already exist. This prevents the
unnecessary creation of multiple lots.
3. Start the distribution run.
After the check, the parameters are transferred to a function module, which is called as a
background process.
4. Choose Log to check the status and the messages in the application log.
The messages are displayed in a dialog box. The column on the left contains the grouping
criteria (problem classes) and the column on the right contains the actual messages. Choose
Refresh to update the status and the messages during the run.
The first message is included in the Additional Information problem class and displays the
current status. The following statuses exist:
{ Distribution Running: n percent
The distribution run is still in process. The percentage of the process that is complete is
displayed. Choose Refresh to update the status.
{ Distribution Complete
The distribution run has ended without errors. This occurs if no bill items were selected
for distribution with the specified criteria, or if all of the bill items for distribution were
transferred to distribution lots and all of the further processing steps that you entered in
Customizing were completed. The following statuses are set if the further processing
steps were not completed for all items:
Not all created
Not all of the items could be transferred to distribution lots.
Not all closed
All items are included in distribution lots. The highest further processing step was
Close Lot. However, not all of the relevant lots could be closed.
Not all posted
All items are included in distribution lots. All distribution lots for which Close Lot or
Post Lot was selected were closed. The highest further processing step was Post
Lot. However, not all of the relevant lots could be posted.
{ Distribution Terminated
The distribution run could not end because an error occurred.
The messages are displayed in problem class Other in the order they occurred.
Note
You can display the log as an application log using transaction SLG1.
• Object: IUEEDPPLOT (Distribution of aggregated payments)
• Subobject: THI (Distribution run from bill processing)
• Ext. Identification: Run identification
25
To display the log data from previous runs, select the parameters from the selection help for the Run
Identification field and choose Log.
3.2.2.6. Process Distribution Run (Aggregated Payment)

You use this function to further process distribution lots created for a contract account for aggregated
bill posting once the aggregated payment document has been posted.
Prerequisites
• The distribution lots were created using the Create Distribution Lot from Payment Advice Note
function or the Create Distribution Lot from Bill Processing function.
• A document already exists for the aggregated payment. That is, the document was posted to a
service provider’s contract account for aggregated bill posting.
Activities
...
1. Call the Process Distribution Lot (Aggregated Payment) transaction.

IUEEDPPLOTAALC3)
2. Enter values for the following selection parameters:
{ Aggregated Payment
Doc. No. of Aggregated Payment (required entry)
Contract Account
Payment Recipient
Sold-To Party
{ Select Distribution Lot
Here you specify whether you want to reprocess a distribution lot that has already been
allocated to a payment document in this transaction.
The Process Distribution Lot function allows you to allocate distribution lots to an aggregated
payment document. Once this allocation is made, the aggregated payment for a distribution lot
is regarded as received and can be posted. You do not have to activate the Post Payment Lot
parameter in the service provider agreement.
3. Start processing
Three processing areas are displayed. You can execute the following functions for each
processing area:
{ Processing area: Payment Document Header Data
Doubleclick on the document number to branch to the document display. Alternatively,
choose Goto → Payment Document in the menu.
{ Processing area: Distribution Lot Header Data
In addition to the list display functions, the following functions are also relevant for
processing:
Display Items
Select a distribution lot. Choose Display Items to display the item data for the
selected lot in the lower processing area.
26
Save Document Allocation

Select one or more distribution lots. Choose Save Document Allocation to save
the allocation of the selected lot to the displayed payment document. This is
necessary for posting the lot if the Post Payment Lot parameter is not set in the
corresponding service provider agreement.
Reset Document Allocation
This cancels the document allocation.
Close Lot
Select one or more lots. Choose Close Lot to close all selected lots.
Post Lot
Select one or more lots. Choose Post Lot to post all selected lots. If the Post
Payment Lot parameter is not set in the corresponding service provider
agreement, posting does not take place. In this case, execute the Save Document
Allocation function first.
Delete Lot
Select one or more lots. Choose Delete Lot to delete all selected lots. If lots have
a status that does not allow you to delete them, you may need to execute a mass
reversal of the reconciliation key that is used in the lot.
{ Processing area: Distribution Lot Item Data
processing:
Display Item
Select a lot item. Choose Display Lot to branch to the detailed display.
Save Document Allocation
This saves the allocation of the displayed payment document to item levels.
Reset Document Allocation
This function allows you to cancel the document allocation.
3.2.2.7. Process Distribution Lot (Clearing Reset)

You use this function to process distribution lots created for a contract account for aggregated bill
posting after a clearing reset has been posted. It is mainly used to delete or reverse distribution lots.
Prerequisites
• The distribution lots were created using the Create Distribution Lot from Payment Advice Note
function or the Create Distribution Lot from Bill Processing function.
• A document already exists for the clearing reset. That is, the document was posted to a service
provider’s contract account for aggregated bill posting.
Activities
...
1. Call the Process Distribution Lot (Clearing Reset) transaction.

(In the SAP Easy Access menu choose Utilities Industry → Intercompany Data Exchange
→ Generate Posting and Display Account Balance → Processing Distribution Lots →
Process Distribution Lot (Reset Clearing); Report RIDEPLOT04 or transaction
IUEEDPPLOTAALC4)
2. Enter values for the following selection parameters:
{ Document No. of Clearing Reset (required entry)
27
{ Contract Account
{ Payment Recipient
{ Sold-To Party
{ Lot Generated From/To
3. Start Processing.
3 processing areas are displayed. You can execute the following functions for each processing
area:
{ Processing area: Reset Document Header Data
Doubleclick on the document number to branch to the document display. Alternatively,
choose Goto → Payment Document in the menu.
{ Processing area: Distribution Lot Header Data
processing:
Display Items
Select a distribution lot. Choose Display Items to display the item data for the
selected lot in the lower processing area.
Delete Lot
Select one or more lots. Choose Delete Lot to delete all selected lots. If lots have
a status that does not allow you to delete them, you may need to execute a mass
reversal of the reconciliation key that is used in the lot (in the menu: Environment
→ Mass Reversal).
{ Processing area: Distribution Lot Item Data
In addition to the list display functions, the following function is also relevant for
processing:
Display Item
Select a lot item Choose Display Lot to branch to the detailed display.
28
4. Dunning the Supplier

In some markets, companies are legally required to produce a detailed statement for receivables that
are selected for dunning. You cannot use the aggregated receivables for this purpose as dunning is
carried out at individual customer level.
Since the clearing of open items on the supplier accounts does not necessarily reflect the clearing of
open items on the individual accounts, it is not possible to dun the open items of the supplier account
and then read the corresponding individual receivables. This applies once the supplier account has
been cleared or partially cleared.
It makes sense, therefore, to always keep supplier accounts as G/L accounts. This means that
incoming payments clear open items. The open items on the supplier accounts do not have a unique
relationship with the individual accounts to be cleared. At the same time, however, the incoming
payments are evaluated in such a way that the individual account items are cleared according to their
reasons for payment. Before every dunning run, ensure that the allocation between incoming
payments and individual accounts has been made and that the aggregated bill was posted. This
results in a minimum variation between the sum of the individual items and the open items on the
supplier account.
The open items on a supplier account are selected in the dunning run. At the same time, all individual
accounts with a reference to a supplier account are checked for open items. If open individual items
are found, they are checked for due date and dunning history and, if necessary, they are copied to the
dunning tables. There are no plans to change the dunning proposal.
If there is reason to put a dunning block on an individual account, you can exclude receivables that
belong to these accounts from dunning when creating the dunning run. The standard solution does not
include a dunning block but you can set one for event 0311.
When a dunning form is created (as part of a dunning activity), the balance of the supplier account and
all existing open individual receivables are printed out with their corresponding dunning levels. The
sum of the receivables on the supplier account corresponds to the current status of the supplier
account. It does not, however, necessarily correspond to the amount to be dunned and is only used
for information purposes. The list of receivables sorted by dunning level does meet the legal
requirement to provide a detailed statement of receivables.
System Settings
You make the basic settings for the dunning run and the dunning activities in Customizing for Financial
Accounting under Contract Accounts Receivable and Payable → Business Transactions → Dunning
Notices.
Preparation
You have to make the following settings before you can dun the service provider that invoices the
contract.
...
1. Define the following function modules as customer-specific modules:

{ Event 308 – Function module ISU_DEREG_INV_DUNNING_0308
{ Event 311 – Function module ISU_DEREG_INV_DUNNING_0311
Customizing for Financial Accounting → Contract Accounts Receivable and Payable →
Program Enhancements → Define Customer-Specific Function Modules
2. Define the dunning activities in Customizing for Financial Accounting under Contract Accounts
Receivable and Payable → Business Transactions → Dunning Notices → Configure Dunning
Activities.
29
3. Allocate an application form that can display dunning items in the deregulated scenario to the
dunning activity. If the application form from form class IS_U_CA_DUNNING uses item
description DEREG_ITEM (see transactions EFRM and EFCS), it can display items in the
deregulated scenario. In addition to the usual data, you can also print the point of delivery (field
EXT_UI) for these items.
4. Configure a dunning procedure for the service provider that invoices the contract and define the
procedure in the service provider’s contract account.
Business Transactions → Dunning Notices → Configure Dunning Procedure)
5. Ensure that the contract account category of the invoicing service provider’s contract account is
defined as such.
(Customizing for SAP Utilities → Intercompany Data Exchange → Payment Control →
Define Contract Account Category for Service Prov. that Invoices Contract (transaction
SM30, TE002A))
Define a separate number range interval for this contract account category so that you
can dun the service provider that invoices the contract in separate runs.
Execution
You can use the Dunning Proposal (transaction FPVA) to dun the service provider that invoices the
contract. First of all, you create a dunning proposal. This contains the due items from the contract
account of the service provider that invoices the contract that were not posted using the main
transaction 4000 (Receivables from InvServProvider). It also contains all due items from the contract
accounts (end customer accounts) that the service provider that invoices the contract will clear. The
due dates of these items are determined in the corresponding service provider agreement. The due
date is not included in the end customer document but is entered in a separate table (DFKKTHI).
You can create printed dunning notices using the dunning activity run (transaction FPVB). You can
use the form in the dunning activity to display the points of delivery of the end customer accounts.
Notes
• Before you start the dunning run, all incoming payments must be linked to distribution lots and
the distribution lots must have been posted. If this is not the case, end customer items could be
dunned by mistake.
• You can only create a dunning proposal if there is at least one due item in the contract account
of the service provider that invoices the contract.
• End customer documents are only included in the dunning proposal if the corresponding bill has
already been sent to the service provider that invoices the contract.
• You can also allocate dunning blocks to documents (also end customer documents). These
documents are not included in the dunning proposals.
• Dunning charges are posted to the contract account of the service provider that invoices the
contract.
• You can branch to the dunning history from the account balance display of the service provider
that invoices the account (Go to Environment → Account → Dunning Notices in the menu bar).
However, you cannot branch directly from the items of an end customer document to the
dunning history for technical reasons.
• Dunning runs should only take place once incoming payments have been processed. That is,
the distribution lots that were created on receipt of the payment advice note should already have
been posted
• The usual dunning functions are available. You can, therefore, create dunning groups based on
dunning levels. You can use these dunning groups for the dunning activity in a number of
different ways. In other words, you can create a variety of dunning forms.
30
To reduce run times, we recommend that you carry out separate dunning runs for invoicing service
providers regardless of other business partners and contract accounts.
31
5. Bill Receipt
This section describes the process of bill receipt processing. The section begins with an explanation of
the individual steps involved in the bill receipt process before looking at the actual process in the
system.
In addition to importing bill documents into the system by IDoc, you also have the option to enter the
data manually.
For more information on manual entry, see the “Manual Processing of Bill and Payment Advice
Note Data” unit.
5.1. Process Flow

Receiving a bill for grid usage triggers bill receipt processing. This can be the receipt of individual
customer bills or full bills with attached individual bills. The bill data is recorded and can be displayed
in the system.
The unprocessed bill data is then checked and copied in the subsequent steps. Each step must be
completed successfully before you can proceed to the next one. If errors occur, you can reprocess the
data and repeat the step. Any errors that occur are recorded in a log file.
In the first step, the sender and the billed point of delivery or customer are identified. Once they have
been identified, a technical and contents-based check can be performed on the bill data. If the check
is successful, the necessary supplier data (for example, meter readings) is copied to the
corresponding SAP IS-U data objects. The bills are then checked and prepared for posting or
payment. The individual subprocesses can be processed as mass data or using parallel processing.
This ensures a high level of performance.
Full or individual Bill Identify Copy

Check Check
bill data hdr + doc data
data bill
receipt data to IS-U
Yes Yes Yes
Identified? Check Copy

Postprocess Check
passed? successful?
bill data passed?
No No
No No
Yes
Trnsfr
data
Posting and
Log
payment relevant
data
5.1.1. Identification of Header Data

You can use the header data identification to determine the sender and the recipient of the bill by
means of the bill data. You can reprocess the bill data if necessary.
5.1.2. Identification of Document Data

You can use the document data identification to determine the point of delivery and the business
partner. Any problems that occur are logged and can be solved by reprocessing the data.
Reprocessing the bill data triggers a new identification.
5.1.3. Check Before Information is Copied

The bill data check before the information is copied ensures that basic checks are executed (for
example, do I supply energy to this customer?). Any messages (errors, warnings, or information) are
recorded in a log file. You can reprocess the bill data if necessary. If you do reprocess the data, the
entire process is restarted.
32
If the check is successful, the next process is triggered.
5.1.4. Copying Information

In this step, additional information, such as meter reading results, is copied from the bill to SAP IS-U.
Any messages that are issued are recorded in a log file. You can reprocess the data if necessary. If
you do reprocess the data, the process of bill receipt processing is restarted. You can also copy other
data from SAP IS-U (for example, account assignment data, quantities) to the bill or payment advice
note.
5.1.5. Check After Information is Copied

The bill data check after the information is copied ensures that basic checks are executed. This can be
a check of the end amount, for example. Any messages that are issued are recorded in a log file. You
can reprocess the bill data if necessary. If the check is successful, the next process is triggered.
5.1.6. Data Transfer

The bill data is transferred in order to prepare the bill data for posting to IS-U. If the data is transferred
successfully, bill receipt processing is complete.
5.2. System Settings

In this scenario, we assume that the distributor sends bills to the supplier by EDI.
5.2.1.1. Preparation
...
1. Define a service provider agreement for the distributor using the Change Service Provider
transaction.
Use a service provider agreement type that is based on the deregulation process INV_IN.
V_EDRGSPAGRTYPE)
(Also see Customizing for SAP Utilities → Tools → System Modifications → User-
Defined Enhancements for IDE → Define Deregulation Processes; transaction SM34,
VC_EDEREGPROC)
Enter parameter values for the Bill and Payment Advice Note Type and Document Type
parameters.
Also make an entry in the ID Type parameter. This is required for the interpretation of the
service ID.
If you want to override the basic settings in Customizing, also maintain the parameter values for
parameters Check Group Before Data is Copied, Check Group After Data is Copied, Copy
Group, Transfer Group, Identification Number, and Complaint Group.
2. Define a data exchange process for the distributor.
This data exchange process should be based on basic process IMPINVOICE. Also define a
suitable format. In the German market, for example, you can use the VDEW_INVOIC data
exchange format, for which sample module ISU_COMPR_VDEW_INVOIC_IN and IDoc basic
type ISU_VDEW_INVOIC are defined.
VC_DEXBASICPROC)
33
3. You must define a partner profile before you can receive an IDoc. To do this, use message type
ISU_BILL_INFORMATION as the input parameter.
In the German market, you can use ISU_VDEW_INVOIC as the process code. This is based in
function module ISU_COMEV_VDEW_INVOIC_IN.
5.2.1.2. Execution
The system can receive the bill automatically. You can monitor IDoc receipt using the IDoc List
transaction and you can monitor receipt processing using the Monitoring of Data Exchange Tasks
transaction.
(You can find the IDoc List transaction in the SAP Easy Access Menu under Tools →
Business Communication → IDoc Basis → Display IDoc; transaction WE02)
(You can find the Monitoring of Data Exchange Tasks transaction in the SAP Easy
Processes → Monitoring; transaction EDATEXMON01)
You can monitor IDoc receipt using the IDoc List transaction.
You can monitor the further processing of received bills using the Monitor Bill/Payment Advice Note
Processing transaction. You can also start further processing for individual bills there.
(In the SAP Easy Access menu, go to Utilities Industry → Intercompany Data Exchange
→ Bill and Payment Advice Note Processing → Monitor Bill/Payment Advice Note
Processing; transaction INVMON)
Alternatively, you can start further processing of received bills as a mass activity.
Exchange → Bill and Payment Advice Note Processing → Mass Process Bill/Payment
Advice Note Processing; transaction INVMASSPROC)
The checks, data copy, and data transfer are executed in further processing. This forms the basis for
the subsequent posting of bills in Financial Accounting.
5.2.1.3. Notes
• In the German market, IDocs are processed in function module
ISU_COMPR_VDEW_INVOIC_IN, for example. This module serves as a copy template for
customer-specific modifications. You define customer-specific modules for basic process
IMPINVOICE in Customizing:
• You must enter the external number of the processing service provider and of the market
partner for identification purposes.
• You can no longer make changes to documents that are transferred to Accounting for posting.
5.2.2. Additional Scenarios

5.2.2.1. Complaint Notification
In this scenario, let us assume that a distributor has sent grid usage bills to a supplier. During the bill
check, the supplier determined some inconsistencies and wants to query certain individual bills.
The supplier creates a complaint notification in order to provide the distributor with all the relevant bill
data. The complaint notification contains data from the original bill as well as identification data. For
34
example, it contains the bill number of the distributor, the internal bill number of the supplier, point of
delivery information, bank information, complaint reason, and so on.
The supplier can send the complaint notification in paper format or in electronic format.
Preparation
...
1. Define a service provider agreement for the distributor with the category Complaint
(deregulation process COM_OUT).
V_EDRGSPAGRTYPE)
Set the Outgoing Complaint parameter to Complaint at Individual Bill Level.
If you want to print out the complaint notification, define the Print parameter and set the value to
X.
If you want to send the complaint notification by EDI, leave the Print parameter empty.
2. If you do not want to use the basic settings from Customizing, define a service provider
agreement for the distributor with the category Bill and Payment Advice Note Processing
(deregulation process INV_IN).
V_EDRGSPAGRTYPE)
Define a Bill/Payment Advice Note Type parameter with the value Complaint Notification
(Outgoing), and a Document Type parameter with the value Payment Advice Note and allocate
them a transfer group.
3. If you want to send a complaint notification electronically, define a data exchange process for
basic process EXPREMADV and set the INV_AVISTYPE parameter to R.
If you want to send a complaint notification electronically, add this data exchange process to the
service provider agreement of the distributor. For example, you can use data exchange format
REMADV_CMPLN, which is based on process module
ISU_COMPR_PEXR2002_CMPLNT_OUT. Alternatively, you can define other data exchange
formats and process modules for basic process EXPREMADV.
VC_DEXBASICPROC)
4. Define complaint reasons in Customizing (difference reason for payments) to send by EDI.
Advice Note Processing → Define Difference Reasons; transaction SM30,
TINV_C_ADJ_RSN)
5. Print the complaint notification.
If you want to print out a complaint notification, define form class
IS_U_IDE_REMADV_CMPLNT for correspondent type R006 (complaint notification), and define
an application form (for example, IS_U_IDE_REMADV_CMPLNT or, as of SAP IS.U/CCS 4.71,
IS_U_IDE_REMADV_CMPLNT_SF) for the correspondence type.
35

Basic Functions → Correspondence → Define Standard Form Classes for
Correspondence; transaction SM30; view V_TFK070_FRMCLS)
Basic Functions → Correspondence → Define Application Forms for Correspondence;
transaction SM30; view V_TFK070F)
6. Send the complaint notification.
If you want to send a complaint notification electronically, define a partner profile for the
distributor with partner type SP, message category REMADV, and message variant ISU. You
can use PEXR2002 as a basis type (output parameter).
Execution
...
1. In Monitoring for Bill/Payment Advice Note Processing, select a bill for complaint.
(In the SAP Easy Access menu, choose Utilities Industry → Intercompany Data Exchange →
Bill and Payment Advice Note Processing → Monitor Bill/Payment Advice Note Processing;
transaction INVMON)
2. In the application toolbar, choose Status: Set to Complain and then select a complaint reason
(difference reason for payments).
A complaint notification and a reference to it are generated when the bill is processed. If
function module ISU_DEREG_REMADV_CMPLNT_CREAT is used when the complaint
notification is generated, processing continues immediately. If this function module is not used,
further processing of the complaint notification takes place in one of the following ways:
{ Individually via Process Data
{ Via the mass processing transaction
(In the SAP Easy Access menu, choose Utilities Industry → Intercompany Data Exchange →
Bill and Payment Advice Note Processing → Mass Process Bill/Payment Advice Note
Processing; transaction INVMASSPROC)
3. The following alternative options exist depending on the settings made in the service provider
agreement:
{ An entry is generated in the correspondence container
You can use the Correspondence Printing transaction to print the complaint notification.
As input parameters, use the business partner of the distributor and correspondence
type R006.
(In the SAP Easy Access menu choose Utilities Industry → Contract Accounts
Receivable and Payable → Periodic Processing → For Contract Accounts →
Correspondence → Print; transaction FPCOPARA)
{ An IDoc is sent directly in the defined format (for example, data exchange format
REMADV_CMPLN)
Note
• You cannot select bills for complaint that have already been reversed, ended manually, or
transferred.
• If you use the data exchange format REMADV_CMPLN, an IDoc for structure PEXR2002 is
used to send the advice note by EDI. This IDoc has been used in Accounts Payable Accounting
since SAP R/3 Release 4.0B (software component SAP_APPL). Therefore, the IDoc contains
the same logic and the corresponding content.
36
Also, the structure contains all of the necessary fields required to create the EDIFACT format
according to VDEW regulations.
Also see Data Format: DEMADV and REMADV_OUTBOUND_MAPPING (ISU), which

you can find on the SAP Service Marketplace under http://service.sap.com/utilities.
Choose Product Information → IS-U/CCS → Intercompany Data Exchange →
Cookbooks&Guidelines
• You make entries in the IDoc in function module IS_U_IDE_REMADV_CMPLNT. This module
serves as a copy template for customer-specific modifications.
You can define customer-specific modules for basic process EXPREMADV and select the value
R for parameter INV_AVISTYPE in Customizing.
VC_DEXBASICPROC)
• The complaint reason number (difference reason for payments) is entered directly in the IDoc
for segment AJT (when you use function module IS_U_IDE_REMADV_CMPLNT). Therefore, it
is necessary to take association regulations into account when you define complaint reasons.
• You must enter the external number of your own service provider (that invoices the contract)
and of the bill issuing service provider for identification purposes.
(In the SAP Easy Access Menu go to Utilities Industry Intercompany Data Exchange →
Service Provider → Change; transaction EEDMIDESERVPROV02)
• You can use the Monitoring transaction to monitor the progress of the complaint notification. If
errors occur, check the error log in the monitoring transaction for the data exchange tasks. You
can branch to the corresponding IDoc as well as to the original complaint notification from this
transaction.
→ Data Exchange Processes → Monitoring; transaction EDATEXMON01)
5.2.2.2. Budget Billing Requests

In this scenario, let us assume that a distributor has sent grid usage bills to a supplier in printed
format. The bills already contain future budget billing requests.
In order to be able to take the budget billing requests with their due dates into account, they must be
recorded in the system when the bill is received. They are then processed further on the
corresponding due date.
Execution
In the Record Bill transaction, enter a bill with budget billing requests and process the document.
→ Bill and Payment Advice Note Processing → Record Bill; transaction INVDOC01)
A new bill is created for every budget billing request line. You can use the references to branch to the
new budget billing requests.
Note
• The data from each budget billing request line (start of period, end of period, due date) is copied
to the newly generated document at header level.
5.2.2.3. Reversal
There are two ways to reverse an original document:
...
1. The market partner sends a reversal document (by EDI or in printed format)
37
The reversal document is either received by EDI or it is entered manually.

2. An original document is reversed manually.
A reversal document is generated automatically.
Preparation
• Define reversal reasons:
Advice Note Processing → Define Reversal Reasons; transaction SM30,
TINV_C_CNCL_RSN)
Execution
Receive a reversal document by EDI or enter a reversal document in the Record Bill transaction.
Ensure that the reversal document contains the same data as the original document and flag it as a
reversal document using the document type. Ensure that the external bill/payment advice note number
corresponds to the external number of the original document and that the +/- signs of the amounts are
the opposite of those in the original document.
Alternatively, to generate a reversal document from the original document display, choose Status →
To Be Reversed in the application toolbar and select a reversal reason. To branch to the generated
reversal document, choose References and select the reversal document.
The original document is fully reversed when you process the reversal document. If the original
document had already been transferred, the reversal document is also transferred. If the original
document was the subject of complaint, the corresponding complaint notification is also reversed (as
long as it has not yet been sent).
Note
• If possible, process the reversal document before you process the original document. This
ensures that documents are not needlessly transferred to Financial Accounting. Therefore,
when the reversal document is generated, the due date is set to the current date.
38
6. Outgoing Payment
This section describes the process of outgoing payment. It includes the aggregated posting of
incoming bills for suppliers, payment to the billing party, and creation of the payment advice note. A
prerequisite for outgoing payment is the completion of the bill receipt process.
Distributors generally send individual bills to suppliers. These individual bills can also be part of a full
bill and are sent either by EDI, as a file, or in paper format. Incoming bills that have been checked
successfully are posted and paid together for performance reasons. An electronic payment advice
note containing information on the paid individual bills is created for the payments. The payment
advice note is sent to the distributor and forms the basis for tracking receivables. The German
Electricity Association suggests the use of EDI format REMADV in the German market, for example.

The individual bills are posted to the account of the billing party in aggregated form. Bills are not
posted individually due to the large amount of incoming bills. This would have a negative effect on
processing the distributor’s account.
You can only create payment advice notes in paper format and in EDI-REMADV format. You can,
however, use the EDI format as a basis for other formats.
Incoming budget billing requests from the distributor are posted directly as expenses (not statistically
at first; a preliminary statistical posting with subsequent transfer posting for year-end billing is too
complex and too expensive).
6.2. Process Flow

Posting- and
payment-
relevantdata
Payment
advice
note
(REMADV)
Read Execute Create
Triggeraggregated Execute
serviceprovider aggregated paymentadvice
A/Pposting paymentrun
agreement posting note Payment
advice
note
(paper)
Log
6.2.1. Read Service Provider Agreement

The service provider agreements (deregulation processes INV_OUT, REM_OUT, INV_IN, PAY_OUT)
contain the information that 2 service providers have agreed upon regarding the processes that
concern them both. They also include information required for the outgoing payment process, such as
information on the posting account or on the individual customer receivables:
• Based on the definition in the service provider agreement, the documents are either posted to a
vendor account from the FI-AP component, or to a contract account from the FI-CA component.
• For individual customer receivables to the distributor, you have to take various agreements into
account.
6.2.2. Execute Aggregated Posting

The data from table TINV_INV_TRANSF forms the basis for the aggregated posting. Entries are made
in this table after the appropriate checks have been made in the bill receipt process. You must take
39
certain criteria into account when aggregating the individual bill amounts. You can only aggregate
individual bill lines if the following data is the same:
...
• Billing service provider

• Currency
• Company code (the company code is different for each service provider relationship)
• Bill category (this can refer to various accounts)
This characteristic is not included in the standard solution. The allocation of the bill category to
the individual bills is customer-specific. If you make customer-specific settings, however, the bill
category is taken into account for aggregated posting, even in the standard solution.
• Due date
• Tax code (tax type and tax rate)
Distributors generally include a number of bank accounts on their bills to which payment can be
transferred. Suppliers must use one of the specified accounts. Different bank accounts can also be
specified for individual bills within one aggregated bill. This is because payment received by the
distributor is processed over several bank accounts based on the regional structure, for example. If
bank accounts are provided, payments must also be grouped according to this characteristic for
aggregated posting. The bank account is copied from the bill in each case.
If the grid usage bill for an individual customer results in receivables from the distributor, a number of
agreements are processed in payment processing. Some distributors do not want credit from the
supplier to be cleared by other receivables. If this is the case, the supplier is not permitted to clear
receivables with outgoing payment. Therefore, these receivables must be posted separately and
assigned a payment block. They must also be posted separately because the distributor is expected to
make payment for each individual receivable. The distributor can also use this procedure to make a
full payment. Whether receivables that arise as a result of grid usage billing are posted individually or
not depends on the amount in question. Some distributors only clear credit from the supplier with
receivables up to a specific amount; any credit that exceeds this amount is paid out. This amount can
be defined separately for each service provider agreement and refers to the amount from an individual
bill.
You must take taxes into account for aggregated bill posting so that the supplier can apply for any
input tax receivables that are due. The tax portions must be copied from the individual bills and added
together. You cannot use the tax percentage rate to calculate the tax portion from the aggregated bill
sum because of the rounding differences that would arise. This only refers to tax types that are
deductible from input tax. Based on the definition in the service provider agreement, the documents
are either posted to a vendor account in the FI-AP component, or to a contract account in the FI-CA
component. Bill reversals and credit from the distributor can be processed if the distributor
communicates a bill reversal.
You can also include CO account assignment during the aggregated posting of the incoming grid
usage bill. You can determine account assignments for individual customers. The following CO
account assignments are taken into account:
• Cost center
• Profit center
• Order
• WBS (work breakdown structure) element
It is important for utility companies that the consumption quantities are available in CO. The quantities
are updated as closely as possible to actual consumption rather than waiting for the annual
consumption billing. You must create certain customer-specific functions before you can use this
function.
40
Preparation
...
1. If you use Contract Accounts Receivable and Payable as the posting module, define appropriate
external transactions for internal main transaction 4500 and subtransactions 0010, 0020, 0110,
and 0120.
Basic Functions → Postings and Documents → Document → Maintain Document
Assignments → Maintain Transactions for Industry-Specific Component Utilities)
2. Maintain the account determination for these transactions.
Basic Functions → Postings and Documents → Document → Define Account
Assignments for Automatic Postings → Automatic G/L Account Determination → IS-U:
Define Acct Assmt Data Relevant to Main Transactions)
and
Basic Functions → Postings and Documents → Document → Define Account
Assignments for Automatic Postings → Automatic G/L Account Determination → IS-U:
Define Acct Assignment Data Relevant to Transactions)
3. If necessary, define default values for the aggregated posting of incoming bills.
(Customizing for SAP Utilities → Intercompany Data Exchange → Payment Control →
Define Defaults for Aggregated Posting of Incoming Bills)
Execution
...
1. Call the Aggregated Posting of Incoming Bills transaction.

→ Generate Posting and Display Account Balance → Aggregated Posting (Outgoing
Payment)
2. Specify the Date and Identification run parameters.
3. Restrict the selection by making entries in the Sender, Recipient, and Net Due Date fields. The
Net Due Date field is automatically assigned the system date. However, you can change the
date.
4. Specify the necessary posting parameters. The Posting Date and Reconciliation Key fields are
preassigned by the system. However, you can change the entries. The document types of
postings in Contract Accounts Receivable and Payable or in Accounts Payable Accounting are
predefined in Customizing. However, you can change the document types.
5. In the Logs tab page, you can choose the log class.
6. Save the parameters and execute the transaction.
...
...
6.2.3. Execute Payment Run

You execute the payment run in this step. Payment is made to the distributor as a total amount.
Depending on the posting variant you select, payment to the vendor is made via the FI payment
program, and posting to FI-CA contract accounts is made via the FI-CA payment program.
Also see the documentation for this function.
41
6.2.4. Creating Payment Advice Notes

In this step, you create the payment advice note and send it to the distributor. You use electronic
format REMADV for this purpose. The relevant data from the individual bills is added to the payment
information from FI-CA or FI regarding the cleared receivables and payables. This data is prepared
and sent in REMADV format.
6.2.5. Sending the Payment Advice Note

This step describes the process in which the service provider that invoices the contract sends the
payment advice note to the billing party. The payment advice note allows the distributor to allocate
incoming payments to the bill items that they clear.
You send the payment advice note from Contract Accounts Receivable and Payable or from Accounts
Payable Accounting. The settings you have to make and the programs you have to execute vary
depending on where you create the advice note and where you send it from.
Based on the settings in the service provider agreement, you can send the payment advice note by
EDI or in printed format. The different areas contain the same data basis for creating application forms
or SAP IDocs. The data basis primarily consists of the individual bills (including the corresponding PoD
ID for end customers) that the invoicing service provider receives from the billing party.
Preparation
Preparation for Contract Accounts Receivable and Payable (FI-CA):
...
1. In the program specifications for creating the note to payee type, enter module
ISU_DEREG_PAYMEDIUM_DETAILS for your payment medium format and activate it.
Business Transactions → Payments → Incoming/Outgoing Payment Creation →
Maintain Note to Payee Type for Payment Medium)
2. In Customizing for Financial Accounting under Contract Accounts Receivable and Payable →
Business Transactions → Payments → Incoming/Outgoing Payment Creation → Define
Payment Methods, define your own payment method and maintain the necessary data for the
responsible company code and bank determination. Also include this payment method in the
contract account of the billing party. This payment method is then specified for outgoing
payments as well as for incoming payments.
3. Select the Always Issue Payment Advice Notes field for your payment medium format in the
company code.
Customizing for Financial Accounting → Contract Accounts Receivable and Payable →
Business Transactions → Payments → Incoming/Outgoing Payment Creation → Define
Specifications for Responsible Company Code)
4. In Customizing for Financial Accounting under Contract Accounts Receivable and Payable →
Program Enhancements → Define Payment Medium Formats, define module
ISU_DEREG_PAYMEDIUM_31 for event 31 in the payment medium format.
5. If you want to print the payment advice note, define an application form, in which you use
payment advice note item DEREG_INFO with point of delivery data from form class
IS_U_CA_PAYMENT.
(In the SAP Easy Access Menu, choose Accounting → Contract Accounts Receivable
and Payable for Media Sales and Distribution → Print Workbench → Application Form →
Edit; transaction EFRM)
Define this application form in Customizing for Financial Accounting under Contract Accounts
Receivable and Payable → Basic Functions → Correspondence → Define Application Forms for
Correspondence (correspondence type ‘0006’: Payment Advice Notes)
If you want to use the payment advice notes for other payments, you must use the same
correspondence type and the same application form as for aggregated payments. In the
42
application, you use structure DEREG_INFO to decide which data to include in the
payment advice note. This structure only contains data for aggregated payments.
Preparation for Accounts Payable Accounting (FI-AP):

...
1. If you want to print the payment advice note define a SAP script form (for example,
F110_D_AVIS).
(Customizing for Financial Accounting → Accounts Receivable and Accounts Payable →
Business Transactions → Outgoing Payments → Automatic Outgoing Payments →
Payment Method/Bank Selection for Payment Program → Set Up Paying Company
Codes for Payment Transactions)
2. Define your own payment method in Customizing for Financial Accounting → Accounts
Receivable and Accounts Payable → Business Transactions → Outgoing Payments →
Automatic Outgoing Payments → Payment Method/Bank Selection for Payment Program → Set
Up Payment Methods per Country for Payment Transactions.
Select Use Payment Medium Workbench for the payment medium and define an appropriate
format (for example, DTAUS0). Allocate this payment method to the corresponding vendor.
Preparation for both areas (FI-CA and FI-AP):
...
1. Create a service provider agreement for outgoing payments for the distributor (deregulation
process REM_OUT).
In the parameter configuration for the outgoing payment advice note, enter the value Full
Payment Advice Note for Aggregated Payment and set the Print Payment Advice Note
parameter.
{ If you want to print the payment advice note, enter the value X
{ If you want to send the payment advice note by EDI, leave the parameter empty
2. If you want to send a payment advice note electronically, define a data exchange process for
basic process EXPREMADV and set the INV_AVISTYPE parameter to C (FI-CA) or A (FI-AP).
3. If you want to send a payment advice note electronically, add this data exchange process to the
service provider agreement of the distributor. For example, you can use data exchange format
REMADV, which is based on process module ISU_COMPR_PEXR2002_OUT. Alternatively,
you can define other data exchange formats and process modules for basic process
EXPREMADV.
VC_DEXBASICPROC)
4. Define a partner profile (transaction WE20) for the distributor with partner type SP.
In the SAP Easy Access Menu go to Tools → Business Communication → IDoc Basis →
Administration → Partner Profile (transaction WE20)
As the output parameter, add message category REMADV with message variant ISU and IDoc
basic type PEXR2002. Also add a recipient port.
43
Execution
You can send the payment advice note either in combination with a payment run or once the payment
run is complete. In a payment run, the (usually aggregated) open items from the contract account or
vendor account specified in the service provider agreement are paid and cleared.
Execution in Contract Accounts Receivable and Payable (FI-CA):
...
1. Execute a payment run and select the contract accounts for payment. Also define a suitable
variant for payment medium program SAPFKPY3. You send the payment advice note by EDI
from the payment medium program.
(In the SAP Easy Access menu choose Utilities Industry → Contract Accounts Receivable
and Payable → Periodic Processing → For Contract Accounts → Payment Run; transaction
FPY1)
2. Once the payment medium program has been executed, you can print the form from the
corresponding service provider agreement. You must also execute a correspondence run for the
Payment Advice Note correspondence type.
(In the SAP Easy Access menu choose Utilities Industry → Contract Accounts Receivable
and Payable → Periodic Processing → For Contract Accounts → Correspondence → Print;
transaction FPCOPARA)
Execution in Accounts Payable Accounting (FI-AP):
...
1. Execute a payment run (transaction F110) and select the accounts payable for payment.
(In the SAP Easy Access Menu choose Accounting → Financial Accounting → Accounts
Payable → Periodic Processing → Payment; transaction F110)
2. On the Printout/Data Medium tab page, in the Lists group frame, define a suitable selection
variant for program ISU_DEREG_REMADV (for example, limit to certain payment methods).
When you start the actual run, select the Create Lists field.
You send or the payment advice note by EDI or print it in program ISU_DEREG_REMADV.
Note
• An IDoc from structure PEXR2002 is used to send payment advice note by EDI. This IDoc has
been used to send payment advice notes in Accounts Payable Accounting since SAP Release
4.0B. Therefore, the IDoc contains the same logic and the corresponding content.
Also, the structure contains all of the necessary fields required to create the EDIFACT format
according to VDEW regulations.
Also see Data Format: DEMADV and REMADV_OUTBOUND_MAPPING (ISU), which

you can find on the SAP Service Marketplace under http://service.sap.com/utilities
Choose Product Information → IS-U/CCS → Intercompany Data Exchange →
Cookbooks&Guidelines
• You can maintain the IDoc using function module ISU_COMPR_PEXR2002_OUT. This module
serves as a copy template for customer-specific modifications. You define customer-specific
modules for basic process EXPREMADV in Customizing:
• In Contract Accounts Receivable and Payable (FI-CA), you can send the same payment advice
note as often as you want by restarting the payment medium program for the same parameter.
• In Accounts Payable Accounting (FI-AP), you can only send a payment advice note once by
EDI.
44
If you restart program ISU_DEREG_REMADV, the payment advice note is printed and
not sent, even if this does not conform to the service provider agreement.
• You must enter the external number of your own service provider (supplier) and of the
distributor for identification purposes.
• You can monitor the progress of the payment advice note in Monitoring.
You can find the Monitoring of Data Exchange Tasks transaction in the SAP Easy Access
Menu under Utilities Industry → Intercompany Data Exchange → Data Exchange
Processes → Monitoring (transaction EDATEXMON01)
45
7. Manual Processing of Bill and Payment Advice

Note Data
7.1. Manual Entry of Bill and Payment Advice Note Data
In addition to importing bill and payment advice note documents into the system by IDoc, you also
have the option to enter the data manually. You use transaction INVDOC01 to enter bill data manually
and transaction INVADV01 to enter payment advice note data manually.
→ Bill and Payment Advice Note Processing → Enter Payment Advice Note; transaction
INVADV01)
You can also use these dialogs to process existing bill and payment advice note data, as long as the
status of the documents allows it.
7.1.1. Prerequisites
You must make the necessary Customizing settings before you can enter bill or payment advice note
data.
7.1.2. Manual Entry of Bill Data

This section describes the process of entering bill document data. This includes:
...
1. Selecting the bill type

If multiple bill types are available in Customizing, you must select one and choose Next Step.
If only one bill type is available in Customizing, it is chosen automatically.
2. Entering bill header data
Required entries:
{ Document type
{ Sender
{ Recipient
{ Date of receipt
{ Bill date
All other entries are optional.
Once you have entered all the necessary data for the bill header, choose Next Step to enter
other data. This is only possible if SAP IS-U recognizes the sender or recipient that you entered.
The ID does not necessarily have to match the ID on the original bill.
You cannot make changes to the Sender and Recipient fields after this point.
3. Entering the bill reason data, consumption data, and budget billing requests
If you entered the bill header data successfully, you can now enter basic bill data (line type, time
period, quantity, price, and so on) as well as consumption data, and budget billing data. You
enter this data on separate tab pages.
The following applies for the basic bill data:
{ You must enter at least one bill line, whereby a totals line (under the ALV grid control) is
sufficient.
{ You must enter a currency.
46
{ The currency that you entered applies to the full amount.

4. Entering the end amount data
On the Basic Bill Data tab page, you can enter total amounts for the entire document that are
then saved as totals lines.
5. Saving the data
Once you have entered all the data, choose Save to copy it to the database.
Once you have saved the bill document, both it and the corresponding bill are assigned the status
New.
Once you have completed the first bill document, you can either create another document for this bill
(New Document), or you can enter a new bill directly (New Object).
7.1.3. Manual Entry of Payment Advice Note Data

You enter payment advice note data (transaction INVADV01) in the same way as you enter bill data.
The only difference between the dialogs is the data that is entered.
• Selecting the payment advice note type
If multiple payment advice note types are available in Customizing, you must select one and
choose Next Step.
If only one payment advice note type is available in Customizing, it is chosen automatically.
• Entering payment advice note header data
Required entries:
{ Document type
{ Sender
{ Recipient
{ Date of receipt
{ Bill or payment advice note date
All other entries are optional.
Once you have entered all the necessary data for the payment advice note header, choose Next
Step to enter other data. This is only possible if SAP IS-U recognizes the sender or recipient
that you entered. The ID does not necessarily have to match the ID on the original bill.
You cannot make changes to the Sender and Recipient fields after this point.
• Entering the payment advice note data
If you entered the payment advice note header data successfully, you can now enter the line
data for the payment advice note document.
Proceed as follows:
a. Enter the currency for the payment advice note.
This currency applies to the full amount.
b. Select a line type and enter the values for the corresponding payment advice note
document lines.
c. Choose Copy to copy the data from the input fields to the ALV grid control.
d. Enter the document totals in the corresponding fields.
• Saving the data
Once you have entered all the data, choose Save to copy it to the database.
47
Once you have saved the payment advice note document, both it and the corresponding payment
advice note are assigned the status New.
Once you have completed the first payment advice note document, you can enter a new payment
advice note directly (New Object).
7.1.4. Manually Changing Bill and Payment Advice Note Data

To change bill or payment advice note data, you must first select the corresponding bill or payment
advice note document.
(In the SAP Easy Access Menu, go to Utilities Industry → Intercompany Data Exchange
→ Bill and Payment Advice Note Processing → Monitor Bill/Payment Advice Note
Processing; transaction INVMON)
or
(In the SAP Easy Access menu choose Utilities Industry → Intercompany Data Exchange
→ Data Exchange Processes → Monitoring; transaction EDATEXMON01)
The following prerequisites must be met before you can change bill or payment advice note data:
• Manual changes to the document data and to the bill/payment advice note type must be
permitted for the combination of sender/recipient in the parameter configuration of the service
provider agreement for deregulation process INV_IN.
• The user must have the authorization to make changes to the document data.
• The document must have an appropriate status (for example, a document with the status
Completed can no longer be processed).
7.1.5. Manually Changing Bill Data

...
1. Choose a bill document.

This is opened in the display mode. If you are permitted to make changes to the bill document,
the Display/Change pushbutton is active. Choose this pushbutton to switch to change mode.
2. Change the data.
3. Save the data so that it is copied to the database.
The document status is set to Changed Manually and the changes are recorded in the log.
7.1.6. Manually Changing Payment Advice Note Data

You change payment advice note data in the same way as you change bill data.
The fields for entering line data are empty, allowing you to make new entries directly. If you want to
change existing line data, first copy the lines to the ALV grid control input fields by double-clicking on
them. You can now process the data.
Choose Change to copy the data back to the original lines. Choose Copy to add the modified data to
the existing document lines.
In the ALV grid control, you can delete, cut, paste, and copy individual lines.
The manual changes to the payment advice note data are recorded in the log.
7.2. General Functions of the Dialog Transactions

Both dialog transactions include general functions, which are described briefly in this section.
• Log display
The log display records the actions used and their results.
• Object services
The object services provider a generic toolbox. It allows you to add notes or attachments to
the object.
48
• Display references
You can allocate references to a documents. For example, when you generate a document
from an IDoc, you can add an IDoc reference to the document. You can then choose Display
Reference to display the IDoc.
You can also use references to generate follow-up documents (complaint documents, for
example) that are linked to the original document by means of the references.
• Creation data
The creation data shows who created the document and who last changed the document.
• Display internal bill/document number
The display for the internal bill/document number is only relevant for SAP (to determine errors,
for example).
• Process bill/payment advice note data
This function triggers the processing of the current document data. It includes the following
steps:
o Identification of header data
You can use the header data identification to determine the sender and the recipient
of the bill by means of the bill data. You can reprocess the bill data if necessary.
o Identification of document data
You can use the document data identification to determine the point of delivery and
the business partner. Any problems that occur are logged and can be solved by
reprocessing the data. Reprocessing the bill data triggers a new identification.
o Check before information is copied
The bill data check before the information is copied ensures that all the basic checks
are executed (for example, do I supply energy to this customer?). Any messages
(errors, warnings, or information) are recorded in a log file. You can reprocess the bill
data if necessary. If you do reprocess the data, the entire process is restarted.
o Copying information
In this step, additional information, such as account assignment data, is copied from
the bill to SAP IS-U. Any messages that are issued are recorded in a log file. You can
reprocess the data if necessary. If you do reprocess the data, the process of bill
receipt processing is restarted.
o Check after information is copied
The bill data check after the information is copied ensures the content checks are
executed (checking the end amount, for example). Any messages that are issued are
recorded in a log file. You can reprocess the bill data if necessary.
o Data transfer
The bill data is transferred in order to prepare the bill data for posting to IS-U. If the
data is transferred successfully, bill receipt processing is complete.
The process is logged for every step and the document status is adjusted accordingly.
49
Full or Bill Identify Copy data

Check Check
indiv idual data doc + header to
data bill
bill receipt data IS-U
Y es Y es Y es
>Check Copy
Postprocess Identif ied? Check
passed? successf ul?
bill data passed?
No
No No No
Y es
Trnsf r
data
Posting and
Log
Py mnt relev ant
data
• Manually changing the document status

You can use this function to reset an incorrect document or release a document manually, for
example. You can perform the following actions:
{ Release document manually
The document has the status Manually Released.
{ Reset document status
The document has the status Manually Reset.
{ Set document status to Completed.
{ Set document status to For Complaint.
{ Set document status to Reverse.
Changing the document status has a direct effect on processing. This is described in the
following section.
50
7.3. Bill/Document Status

This section describes the bill status and document status as well as the related transactions, actions,
and dependencies.
7.3.1. Bill/Payment Advice Note Status

The bill or payment advice note can have the following statuses:
• New
This is the initial status of a bill or payment advice note. This status is valid until you start
processing one of the related documents.
• To Be Processed
As soon as you start processing a bill or payment advice note document, the bill or payment
advice note is given the status To Be Processed.
• Completed
Once you have successfully completed processing all documents belonging to a bill or payment
advice note, the bill or payment advice note is given the status Completed.
7.3.2. Bill/Payment Advice Note Document Status

The bill or payment advice note document can have the following statuses:
• New
The document has been created but not yet processed.
• In Process
The document has not been completely processed. There are still more processing steps to
carry out.
• Incorrect
The document has not been processed successfully. There are still more processing steps to
carry out.
• Changed Manually
An agent has changed the document manually in the dialog.
• Reset Manually
The document status has been reset. This is the same as document status New.
• Manual Processing Required
This status means that an agent needs to process the document manually.
• Manual Release Required
This status means that an agent needs to release the document manually.
• Released Manually
A document is given this status after it has been released manually. Processing can continue.
• For Complaint
If the document status is changed to For Complaint, a complaint notification is not created
immediately but once the document is being processed.
• Complained
When a document that is selected for complaint is being processed, a complaint notification is
created and a reference to it is generated. The document is then given the status Complained.
• To Be Reversed
A reversal document has been created for the document. When you process the reverse
document, the status of the original document is permanently set to Reversed.
• Reversed
The document has been reversed successfully. A reversal document was generated and
processed successfully.
51
• Transferred
The document data was transferred successfully for subsequent processing.
• Completed
Processing has been completed.
7.3.3. Possible Actions Depending on Status

Depending on the status of the document, there are a number of actions you can carry out. Note that
you must either change the status manually or ensure that it is changed as a result of processing the
process modules in Customizing.
Depending on the initial status and your authorizations, you can carry out the following actions:
• Process Data
This function triggers the processing of the document. You can determine the result from the
new document status or from the document log. The function that is carried out when
processing the document is defined in Customizing and can be changed.
• Status: Release Manually
If the document status was set to Manual Release Required when you were processing the
document data, you can use this function to resume processing. The document is then given the
status Released Manually and you can continue processing it.
• Status: Reset
This function sets the document status to Reset and changes the document back to its initial
status. This means that the document is processed as if it has the status New. As a result, you
may have to execute completed processing steps again. For example, it may be necessary to
recopy the data. Take this account in the conception of the process steps.
• Status: Set to Completed
Setting the status to Completed, ends processing immediately. Actions that have already been
executed are not taken into account.
• Status: Set to For Complaint
You can only use this function for bill documents and not for payment advice note documents.
The document status is set to For Complaint. Further processing generates a complaint
notification for the document in question. As a result of processing the complaint notification, the
document is given the status Complained. Actions that have already been executed are not
taken into account.
• Status: Set to To Be Reversed
You can only use this function for bill documents and not for payment advice note documents. A
reversal document is generated for the document in question and the document status is set to
To Be Reversed. As soon as the reversal document has been processed, the document status
is set to Reversed. Actions that have already been executed are not taken into account.
The following table shows which actions you can execute in the dialog for which initial status:
52
Initial Status / Action Process Data Status: Status: Reset Status: Set Status: Set Status: Set to
Release to to For To Be
Manually Completed Complaint Reversed
New Yes X Bill only Bill only
In Process Yes X X Bill only Bill only
Incorrect Yes X X Bill only Bill only
Changed Manually Yes X X Bill only Bill only
Reset Manually Yes X Bill only Bill only
Manual Processing Required Yes X X Bill only Bill only
Manual Release Required No X X X Bill only Bill only
Released Manually Yes X X Bill only Bill only
For Complaint Yes X X Bill only
Complained No X X Bill only
To Be Reversed No
Reversed No
Transferred No
Completed No
53
7.4. Authorizations
It is also necessary to take the authorization checks into account in relation to bill processing and bill
display. In addition to using the relevant transaction codes, you can also use authorization object
E_INV_DOC to carry out the authorization checks. The following parameters are used to control this
authorization object:
• INV_ACTIVT
Action to be executed. The following allocations apply:
{ 1 - Display
{ 2 - Change
{ 3 - Create
{ 4 - Delete
{ 5 - Complain
{ 6 – Start Processing
{ 7 – Change Status
{ 8 – Release Manually
• BEGRU
Authorization group defined in bill document or payment advice note.
• INV_RELLVL
Release level of document. This is only taken into account for the Release Manually action.
• INV_INBTYP
Bill receipt type (fixed value):
{ Receipt by IDoc
{ Manual entry
{ Receipt by BAPI
{ Generated automatically
• INV_INVTYP
Bill/payment advice note type (Customizing)
• INV_SENDER
Bill/payment advice note sender
• INV_RECEIV
Bill/payment advice note recipient
Bill and Payment Processing
8. Appendix
8.1. Function Modules for Processing Documents
8.1.1. Introduction
This section describes the standard function modules used to process documents. You can define
these function modules in Customizing:
Advice Note Processing → Make Basic Settings; transaction SM34,
VC_INVRCPT_CUST2)
Advice Note Processing → Define Process Control (Part 1); transaction SM34,
VC_INVRCPT_CUST)
Advice Note Processing → Define Process Control (Part 2); transaction SM34,
VC_INVRCPT_CUST3)
You can group the modules as follows:

• Identification modules
• Check modules before data is copied
• Copy modules
• Check modules after data is copied
• Transfer modules
• Complaint modules
• Reversal modules
• Display modules
8.1.2. Identification Modules

You use identification modules to identify business partners. They are allocated to function group
EE_DEREG_INV_IDENT.
• Identification of service provider (ISU_DEREG_INV_IDENT_010)
This function module is used to identify the bill header data. It allows you to identify the sender
(distributor) and the recipient (supplier) by means of their external IDs in the bill header.
• Identification of POD/BP BILL (ISU_DEREG_INV_IDENT_020)
This function module allows you to identify the point of delivery and the business partner in a
bill. You can determine the point of delivery by means of the external point of delivery ID and
you can determine the business partner by means of the external partner number or the name
and address.
• Identification of POD/BP PAN (ISU_DEREG_INV_IDENT_025)
This function module allows you to identify the point of delivery and the business partner in a
payment advice note. You can determine the point of delivery by means of the external point of
delivery ID and you can determine the business partner by means of the external partner
number or the name and address.
55
• Identification of POD/BP BILL (ISU_DEREG_INV_IDENT_030)

This function module allows you to identify the point of delivery in a bill. You determine the point
of delivery using the external point of delivery ID.
• Identification of POD/BP PAN (ISU_DEREG_INV_IDENT_035)
This function module allows you to identify the point of delivery in a payment advice note. You
determine the point of delivery using the external point of delivery ID.
8.1.3. Check Modules Before Data is Copied

Check modules before data is copied carry out consistency checks on unprocessed document data.
They are allocated to function group EE_DEREG_INV_CHCKB.
• Check point of delivery for valid supply scenario (ISU_DEREG_INV_CHECKB_010)
This module is a sample module that checks whether the point of delivery has a valid
deregulation scenario.
The following checks are made:
{ Does the document belong to the individual bill category or the aggregated bill category?
{ Does a deregulation scenario exist for the point of delivery?
{ Does the bill period lie within the validity period of the deregulation scenario?
• Check point of delivery for valid supply installation (ISU_DEREG_INV_CHECKB_020)
This module is a sample module that checks whether the point of delivery has a deregulation
scenario with valid utility contracts.
{ Do contracts exist for this deregulation scenario, in which the recipient is defined as
service provider?
{ Does exactly one contract exist with service type Supply (utility contract)?
{ Does the bill period lie within the validity period of the utility contract?
• Check point of delivery (supply scenario + supply installation)
(ISU_DEREG_INV_CHECKB_030)
This module is a sample module that checks whether the point of delivery has a valid
deregulation scenario with valid utility contracts.
{ Does the document belong to the individual bill category or the aggregated bill category?
service provider?
This module combines the checks from modules ISU_DEREG_INV_CHECKB_010 and

ISU_DEREG_INV_CHECKB_020 and is therefore the preferred option.
• Check point of delivery (deregulation scenario + service provider agreement)
(ISU_DEREG_INV_CHECKB_040)
56
This module is a sample module that checks whether a deregulation scenario exists with valid
service provider agreements.
{ Does a valid service provider agreement exist for the sender and recipient?
• Check point of delivery (scenario + agreement + installation) (ISU_DEREG_INV_CHECKB_050)
This module is a sample module that checks whether a deregulation scenario exists with valid
service provider agreements and a valid utility contract.
{ Does a valid service provider agreement exist for the sender and recipient?
service provider?
This module contains more extensive checks than module

ISU_DEREG_INV_CHECKB_040.
• Check bill period against line periods (ISU_DEREG_INV_CHECKB_060)
This module checks whether the period specified in the bill lines lies within the period specified
at document level. If no period is specified at document level, the system copies the earliest
from-date and the latest to-date from the bill lines to the Start Period and End Period fields.
Run this module before the other check modules as the check modules are partially
based on the bill period.
8.1.4. Copy Modules

You use copy modules to enhance and complete unprocessed document data. They are allocated to
function group EE_DEREG_INV_DATA.
• Enter CO account assignment data (ISU_DEREG_INV_DATA_010)
This module is a sample module that enters the CO account assignment data in the document
lines relevant to transfer.
In the module, the system selects the installation with the service type of the market partner for
the point of delivery. If this installation does not exist, the system selects the installation with the
service type of the processing service provider. The system then selects the contract that
belongs to the installation and determines the CO account determination key.
The system uses the CO account assignment key to select the corresponding cost center, order
number, profit center, and WBS element for transfer to FI-CA. This data is copied to the
corresponding document lines.
For the transfer to FI-AP, the system again selects the CO account assignment data from the
CO account assignment key. The transaction data is not taken into account.
• Entry of quantities for settled budget billing amounts (ISU_DEREG_INV_DATA_020)
57
This module is a sample module that enters quantities for posting-relevant document lines with
budget billing amounts that have already been settled.
This includes the following steps:

{ Check to determine whether the gross amount in the deduction line corresponds to the
gross amounts in the individual billing lines (in the document in process).
{ Selection of all budget billing requests that lie within the billing period and have already
been transferred.
{ Check to determine whether the gross amount in the deduction line corresponds to the
gross amounts in the individual billing lines (in the selected budget billing requests).
{ If the check results are positive, the combined quantities of the individual budget billing
lines are copied to the deduction line as a total quantity.
• Determination of budget billing amount (synthetic profiles) (ISU_DEREG_INV_DATA_030)
This module is a sample module that enters the quantities and the unit of measurement for a
budget billing request.
The system uses the profiles that are allocated to the installation as a basis for determining the
quantities. To ensure that the profiles are taken into account, you must set the Update During
Billing indicator for the role that is used to allocate the profiles to the installation.
The system takes all profiles into account that meet these requirements as well as the
corresponding usage factors. The individual quantities that result are added together.
• Checking and processing a reversal document (ISU_DEREG_INV_DATA_040)
This module is a sample document that processes reversal documents (document category: Bill
reversal or reversal of advance payment request).
The system first looks for the original document to determine the external bill number (field:
EXT_INVOICE). If the original document is uniquely identified and has not yet been transferred,
the document is reversed and the reversal document is not processed further. However, if the
original document has already been transferred, the reversal document can be processed
further and transferred.
If the original document was selected for complaint and the complaint notification has not yet
been printed or sent, the complaint notification is reversed.
• Identification of bank at bill level (ISU_DEREG_INV_DATA_050)
This module is a sample module that identifies and enters the bank details ID.
The system first determines the external bank details (country, account, sort code) of the market
partner at document level.
{ If no vendor is defined, the bank details ID from the business partner is used.
{ If a vendor is defined, the system assumes that a posting to accounts payable account
will take place in a subsequent process step. Therefore, the partner bank category
defined for the vendor is entered as the bank details ID.
{ If the bank details have not been defined for the business partners/vendors, the system
issues an error message.
• Entry of total quantity in the final amount line (ISU_DEREG_INV_DATA_060)
This module is a sample module that enters the total quantity in the final amount line.
All of the quantities from posting-relevant lines are added together with type Normal
Bill/Payment Advice Note Lines to determine the total quantity. The budget billing lines (line type
11) are not added together as the sum of the budget billing amounts is accounted for in the
deduction line. The total quantity is then copied to the final amount line.
• Allocation of bills to usage data and profiles (ISU_DEREG_INV_DATA_070)
58
This module is available as of SAP IS-U/CCS 4.72. It creates references to imported usage data
and profiles for bills and consumption billing. The references are characterized by the
corresponding data exchange tasks.
The module first checks whether the bill is an individual bill or an aggregated bill (bill
category), and whether the document is a bill document (document category).
If the check is successful, the system selects all data exchange tasks belonging to basic
processes IMPUSAGE and IMPPROFIL that lie within (or adjacent to) the bill period and
records them as references to imported usage data or imported profiles.
8.1.5. Check Modules After Data is Copied

You use these check modules to check the enhanced document data after the data has been copied.
They are allocated to function group EE_DEREG_INV_CHCKA.
• Bill simulation + manual action (ISU_DEREG_INV_CHECKA_010)
This function module determines whether a grid usage contract exists for the point of delivery. If
the grid usage contract does exist, the system simulates this contract for the bill period and
saves a reference to the simulated billing document. If no grid usage contract exists, the supply
contract is simulated. The system replaces the rating model from the supply contract with the
corresponding rating model from the grid and saves a reference to the simulated billing
document.
The status of the document is set to Manual Processing.
• Check Payment Advice Note Data (ISU_DEREG_INV_CHECKA_030)
This module is a sample module that checks incoming payment advice notes. Payment advice
notes with a difference reason (field RSTGR) are not checked.
The following is checked:
{ The Contract Account for Aggregated Bill Posting in the service provider agreement for
bill issue and incoming payment.
{ The bank details of the recipient from the contract account data (company code and own
bank details).
{ The own bill number (cross reference number).
{ The exact bill amounts against the incoming payment amounts according to the entries in
table DFKKTHI.
{ The currency of the amounts according to the entries in the DFKKTHI table.
8.1.6. Transfer Modules

You use the transfer modules to complete processing the document data. It is important that all the
document data is complete and correct, as you cannot make any changes once the data has been
transferred. They are allocated to function group EE_DEREG_INV_TRANS.
• Creation of payment lot from payment advice note (ISU_DEREG_INV_TRANS_AVIS1)
This module is a sample module that transfers payment advice notes to distribution lots
(payment lot).
The payment advice note items are copied to parameter XY_PROCESS_DATA. The transfer-
relevant items are read from component INV_LINE_A and transferred to distribution lot items
(payment lot item).
• Creating budget billings for transfer (ISU_DEREG_INV_TRANS_BDGT_BLLNG)
This module is a sample module that processes manually entered information regarding budget
billing requests.
59
Each budget billing request (line type 0009) is posted as a new, processable document in the
system. The dates specified at line level (start of period, end of period, due date) is copied to
the newly generated document at header level.
If you want to use information lines with other line types, you have to make the necessary
changes in the coding.
• Transfer data to table TINV_INV_TRANSF (ISU_DEREG_INV_TRANS_TRANSF)
This module is a sample module that transfers the transfer-relevant bill data
(TINV_INV_LINE_B) to the transfer table (TINV_INV_TRANSF). The transferred data forms the
basis for postings to accounting. All transferred document data, especially account assignment
data and tax data, must be complete and correct, as you cannot make any subsequent
changes.
• Print/Send Complaint Notification (ISU_DEREG_REMADV_CMPLNT_PRCSS)
This module is allocated to function group EE_DEREG_REMADV.
This function module is a sample module that processes complaint notifications. Based on the
settings in the corresponding service provider agreement, the complaint notification is either
prepared for correspondence print or it is sent by EDI.
8.1.7. Complaint Modules

You use the following complaint modules to generate and process complaint notifications. They are
allocated to function group EE_DEREG_REMADV.
• Bill complaint (ISU_DEREG_REMADV_CMPLNT_CREAT)
This function module is a sample module that generates complaint notifications for bill selected
for complaint. The complaint notification is generated and processed immediately in the system.
The generated complaint notification belongs to bill/payment advice note type ‘003’. The
document type is ‘008’. The payment advice note line belongs to type ‘0006’ and the payment
advice note totals line belongs to type ‘0007’.
• Bill complaint and advice note processing (ISU_DEREG_REMADV_CMPLNT_CREATE)
This function module is a sample module that generates complaint notifications for bill selected
for complaint. The complaint notification is generated in the system. However, the posted
complaint notification is not processed further.
The generated complaint notification belongs to bill/payment advice note type ‘003’. The
document type is ‘008’. The payment advice note line belongs to type ‘0006’ and the payment
advice note totals line belongs to type ‘0007’.
8.1.8. Reversal Modules

You use the following reversal modules to generate reversal documents. They are allocated to
function group EE_DEREG_INV_REVERSAL.
• Generation of reversal document (ISU_DEREG_INV_REVERSAL)
This module is a sample module that generates a reversal document from the original
document.
The document category of the reversal document depends on the document category of the
original document. The following allocations are made:
Document category of original document → Document category of reversal document
001 (Bill for Grid Usage) → 005 (Reversal: Bill for Grid Usage)
002 (Budget Billing for Grid Usage) → 005 (Reversal: Budget Billing for Grid Usage)
003 (Credit Memo for Grid Usage) → 005 (Reversal: Credit Memo for Grid Usage)
The system also copies all relevant data from the original document directly to the reversal
document.
60
Data that is not copied includes the date of receipt, the bill/payment advice note date, and the
due date. This data is replaced by the current system date.
8.1.9. Display Modules

You use the following display modules to display document references. You can define them in view
cluster VC_INVRCPT_CUST2 under Type of Reference.
• Display bill document/payment advice note (INV_DISPLAY_REFERENCE_INV_ADV)
This function module displays bill and payment advice note documents. The internal document
number of a bill/payment advice note document is used as the import parameter. For example,
references to the original document are generated when the reversal document is processed.
You can then use this module to display the original document.
• Display IDoc INV_DISPLAY_REFERENCE_IDOC)
This function module displays the IDoc. The IDoc number is used as the import parameter. For
example, references to the received IDoc are generated when bills are received. You can then
use this module to display the IDocs.
• Display billing document (ISU_DEREG_INV_SHOW_BILL)
This function module displays billing documents. The billing document number is used as the
import parameter. For example, a reference to the billing document is generated when grid
usage billing is simulated. You can then use this module to display the billing documents.
• Display FI follow-on document (ISU_DEREG_RECTRANSF_DISP_F_DOC)
This function module displays follow-on documents in FI-CA or FI-AP. The internal document
number is used as the import parameter. For example, a reference to the internal document is
generated when a bill is transferred. If an FI document is posted in a further processing step, it
can be displayed using this module.
• Display payment lot (ISU_DEREG_INV_DOCREF_PLOT_DISP)
This function module displays payment lots. The payment lot number is used as the import
parameter. For example, a reference to the payment lot is generated when a payment advice
note is transferred. You can then use this module to display the billing document.
• Display data exchange task (ISU_DEREG_INV_COM_SHOW_DEXTASK)
This function module is available as of SAP IS-U/CCS 4.72. It display data exchange tasks. The
IDoc number that is defined for a data exchange process is used as the import parameter. For
example, references to received usage data or profiles are generated when data is transferred.
You can then use this module to display the data exchange tasks.
8.1.10. Other Modules

• Simulation of grid usage billing for check purposes (ISU_DEREG_INV_SIMBILL_001)
This function module determines whether a grid usage contract exists for the point of delivery. If
a grid usage contract does exist, the system simulates this contract for the bill period.
If no grid usage contract exists, the supply contract is simulated. The system replaces the rating
model from the supply contract with the corresponding rating model from the grid.
61
8.2. Legend for Flowcharts
Process activity Document
Decision
File output
Complex
Process activity
Output
on paper
Database
table
Reference
to
Data store process
End of process
manual
entry/dialog
Read
data objects in
process flow
Call transaction
Manual
activity
Event
62
© Copyright 2003 SAP AG. All rights reserved.
No part of this publication may be reproduced or transmitted in any form or for any purpose without
the express permission of SAP AG. The information contained herein may be changed without prior
notice.
Some software products marketed by SAP AG and its distributors contain proprietary software
components of other software vendors.
Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are registered
trademarks of Microsoft Corporation.
IBM®, DB2®, DB2 Universal Database, OS/2®, Parallel Sysplex®, MVS/ESA, AIX®, S/390®, AS/400®,
OS/390®, OS/400®, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere®,
Netfinity®, Tivoli®, Informix and Informix® Dynamic ServerTM are trademarks of IBM Corporation in USA
and/or other countries.
ORACLE® is a registered trademark of ORACLE Corporation.
UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of the Open Group.
Citrix®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®, VideoFrame®,
MultiWin® and other Citrix product names referenced herein are trademarks of Citrix Systems, Inc.
HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World Wide Web
Consortium, Massachusetts Institute of Technology.
JAVA® is a registered trademark of Sun Microsystems, Inc.
JAVASCRIPT® is a registered trademark of Sun Microsystems, Inc., used under license for technology
invented and implemented by Netscape.
MarketSet and Enterprise Buyer are jointly owned trademarks of SAP AG and Commerce One.
SAP, SAP Logo, R/2, R/3, mySAP, mySAP.com, and other SAP products and services mentioned
herein as well as their respective logos are trademarks or registered trademarks of SAP AG in
Germany and in several other countries all over the world. All other product and service names
mentioned are the trademarks of their respective companies.
63

Bill and Payment Processing

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Bill and Payment Processing

Uploaded by

Copyright:

Available Formats

New Deregulation Functions:

Bill and Payment

8.1. Function Modules for Processing Documents ........................................................55

1. Infrastructure: Bill and Payment Processing

Process Short description

2.1. General Conditions

2.2. Process Flow

Account billing aggr.

2.2.1. Posting Individual Customer Documents

2.2.2. Aggregated Posting Taking Statistical Budget Billing Plans

This clearing account is used later on for payment distribution.

2.2.2.2. Posting Logic

1. Receivables posted to individual accounts

Customer 1 Customer 2 Receivables Revenues

Supplier 1 Supplier Clearing Clearing

2.2.3. Creating the Aggregated Bill

The combined document consists of the following elements:

2.2.4. Writing Off and Doubtful Entries

2.2.4.2. Doubtful Entries and Individual Value Adjustment

2.2.4.3. Effects on Billing

2.2.4.4. Effects on Invoicing

2.2.4.5. Effects on the Budget Billing Plan

2.2.4.6. Effects on Contract Accounting

2.2.5. Sending the Bill

3. Define a data exchange process for the distributor.

Monitoring Bill Issue

3.1. General Conditions

3.2. Process Flow

Reprocess Check Process

3.2.1. Payment Advice Note Receipt

3.2.1.1. Preparing for Receipt of Payment Advice Notes

3.2.2. Additional Scenario

3.2.2.2. Incoming Payment

3.2.2.3. Complaint Processing

3.2.2.4. Creating Distribution Lots from the Payment Advice Note

1. Setting the parameter values for distribution runs

3.2.2.5. Creating Distribution Lots from the Bill

1. Setting the parameter values for distribution runs

{ Post Distribution Lot

1. Call the Create Distribution Lot from Bill Processing transaction.

3.2.2.6. Process Distribution Run (Aggregated Payment)

1. Call the Process Distribution Lot (Aggregated Payment) transaction.

 Save Document Allocation

3.2.2.7. Process Distribution Lot (Clearing Reset)

1. Call the Process Distribution Lot (Clearing Reset) transaction.

4. Dunning the Supplier

4.1. General Conditions

1. Define the following function modules as customer-specific modules:

5.1. Process Flow

Full or individual Bill Identify Copy

Yes Yes Yes

Identified? Check Copy

5.1.1. Identification of Header Data

5.1.2. Identification of Document Data

5.1.3. Check Before Information is Copied

If the check is successful, the next process is triggered.

5.1.4. Copying Information

5.1.5. Check After Information is Copied

5.1.6. Data Transfer

5.2. System Settings

5.2.2. Additional Scenarios

(Customizing for Financial Accounting → Contract Accounts Receivable and Payable →

Also see Data Format: DEMADV and REMADV_OUTBOUND_MAPPING (ISU), which

5.2.2.2. Budget Billing Requests

Save Document Allocation