SAP Convergent Invoicing

PUBLIC
Document Version: 26.04.2012

Copyright
Copyright 2012 SAP AG. All rights reserved.

SAP Library document classification: PUBLIC

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.
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, Excel, Outlook, PowerPoint, Silverlight, and Visual Studio are registered
trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x,
System z, System z10, z10, z/VM, z/OS, OS/390, zEnterprise, PowerVM, Power Architecture,
Power Systems, POWER7, POWER6+, POWER6, POWER, PowerHA, pureScale, PowerPC,
BladeCenter, System Storage, Storwize, XIV, GPFS, HACMP, RETAIN, DB2 Connect, RACF,
Redbooks, OS/2, AIX, Intelligent Miner, WebSphere, Tivoli, Informix, and Smarter Planet are
trademarks or registered trademarks of IBM Corporation.

Linux is the registered trademark of Linus Torvalds in the United States and other countries.
Adobe, the Adobe logo, Acrobat, PostScript, and Reader are trademarks or registered
trademarks of Adobe Systems Incorporated in the United States and other countries.

Oracle and Java are registered trademarks of Oracle and its affiliates.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.

Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are
trademarks or registered trademarks of Citrix Systems Inc.

HTML, XML, XHTML, and W3C are trademarks or registered trademarks of W3C, World Wide
Web Consortium, Massachusetts Institute of Technology.

Apple, App Store, iBooks, iPad, iPhone, iPhoto, iPod, iTunes, Multi-Touch, Objective-C, Retina,
Safari, Siri, and Xcode are trademarks or registered trademarks of Apple Inc.

(C) SAP AG

IOS is a registered trademark of Cisco Systems Inc.

RIM, BlackBerry, BBM, BlackBerry Curve, BlackBerry Bold, BlackBerry Pearl, BlackBerry Torch,
BlackBerry Storm, BlackBerry Storm2, BlackBerry PlayBook, and BlackBerry App World are
trademarks or registered trademarks of Research in Motion Limited.

Google App Engine, Google Apps, Google Checkout, Google Data API, Google Maps, Google
Mobile Ads, Google Mobile Updater, Google Mobile, Google Store, Google Sync, Google
Updater, Google Voice, Google Mail, Gmail, YouTube, Dalvik and Android are trademarks or
registered trademarks of Google Inc.

INTERMEC is a registered trademark of Intermec Technologies Corporation.

Wi-Fi is a registered trademark of Wi-Fi Alliance.

Bluetooth is a registered trademark of Bluetooth SIG Inc.

Motorola is a registered trademark of Motorola Trademark Holdings LLC.

Computop is a registered trademark of Computop Wirtschaftsinformatik GmbH.

SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP BusinessObjects Explorer,
StreamWork, SAP HANA, 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 other
countries.

Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal
Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services
mentioned herein as well as their respective logos are trademarks or registered trademarks of
Business Objects Software Ltd. Business Objects is an SAP company.

Sybase and Adaptive Server, iAnywhere, Sybase 365, SQL Anywhere, and other Sybase
products and services mentioned herein as well as their respective logos are trademarks or
registered trademarks of Sybase Inc. Sybase is an SAP company.

Crossgate, m@gic EDDY, B2B 360, and B2B 360 Services are registered trademarks of
Crossgate AG in Germany and other countries. Crossgate is an SAP company.

All other product and service names mentioned are the trademarks of their respective companies.
Data contained in this document serves informational purposes only. National product
specifications may vary.

(C) SAP AG

These materials are subject to change without notice. These materials are provided by SAP AG
and its affiliated companies ("SAP Group") for informational purposes only, without representation
or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to
the materials. The only warranties for SAP Group products and services are those that are set
forth in the express warranty statements accompanying such products and services, if any.
Nothing herein should be construed as constituting an additional warranty.

(C) SAP AG

Icons in Body Text

Icon

Meaning
Caution
Example
Note
Recommendation
Syntax

Additional icons are used in SAP Library documentation to help you identify different types of
information at a glance. For more information, see Help on Help
General Information Classes
and Information Classes for Business Information Warehouse on the first page of any version of
SAP Library.

Typographic Conventions
Type Style

Description

Example text

Words or characters quoted from the screen. These include field names, screen
titles, pushbuttons labels, menu names, menu paths, and menu options.
Cross-references to other documentation.

Example text

Emphasized words or phrases in body text, graphic titles, and table titles.

EXAMPLE TEXT

Technical names of system objects. These include report names, program

names, transaction codes, table names, and key concepts of a programming
language when they are surrounded by body text, for example, SELECT and
INCLUDE.

Example text

Output on the screen. This includes file and directory names and their paths,
messages, names of variables and parameters, source text, and names of
installation, upgrade and database tools.

Example text

Exact user entry. These are words or characters that you enter in the system
exactly as they appear in the documentation.

<Example text>

Variable user entry. Angle brackets indicate that you replace these words and
characters with appropriate entries to make entries in the system.

EXAMPLE TEXT

Keys on the keyboard, for example, F2 or ENTER.

(C) SAP AG

SAP Convergent Invoicing .................................................................................................................. 15

Billing in Contract Accounts Receivable and Payable................................................................... 15
Basic Concepts of Billing in Contract Accounts Receivable and Payable ............................... 18
Billable Item .............................................................................................................................. 19
Billable Item Class .................................................................................................................... 20
Billable Item Types ................................................................................................................... 20
Source Transaction .................................................................................................................. 20
Source Transaction Type ......................................................................................................... 21
Billable Item Packages............................................................................................................. 22
Interface Component................................................................................................................ 22
Basic Data for Billing ............................................................................................................ 23
Receivables/Payables (Reduced Interface) ....................................................................... 24
Receivables/Payables (Extended Interface)....................................................................... 25
Subitems ............................................................................................................................... 25
External Reference of the Billable Item ............................................................................... 26
External Master Data Reference ......................................................................................... 27
Contract Reference .............................................................................................................. 27
Billing Quantity ...................................................................................................................... 27
Usage Period ........................................................................................................................ 27
Tax Jurisdiction Code ........................................................................................................... 28
External/Internal Account Assignment ................................................................................ 28
Deferred Revenues - Time-Based....................................................................................... 29
Deferred Revenues - Event-Based ..................................................................................... 29
Offsetting in Invoicing ........................................................................................................... 29
Basic Data for Payment Processing .................................................................................... 30
Payment Reference .............................................................................................................. 30
Card Payment ....................................................................................................................... 30
Payment Card Data .............................................................................................................. 31
Externally-Determined Tax Data ......................................................................................... 31
Assigning External/Internal Tax Codes ............................................................................... 31
External/Internal Tax Type for Other Taxes ....................................................................... 32
Tax Codes for Externally Determined Tax.......................................................................... 32
SAP Convergent Charging................................................................................................... 33
CRM Order ............................................................................................................................ 33
Basic Data for Telecommunications Taxes (US)................................................................ 34
External Provider Contract Reference ................................................................................ 34

(C) SAP AG

Prepaid .................................................................................................................................. 35
Refill of Prepaid Quantities/Packages................................................................................. 35
Refill of Credit on Prepaid Accounts ................................................................................... 35
Billable Item Status................................................................................................................... 36
Record Type ............................................................................................................................. 37
Billing Process .......................................................................................................................... 38
Subprocess ............................................................................................................................... 39
Billing Type................................................................................................................................ 40
Type of Billing Document Item................................................................................................. 41
Billing Target Date .................................................................................................................... 41
Billing Cycle .............................................................................................................................. 41
Scheduling in Billing ................................................................................................................. 42
Parallel Processing Criteria in Billing ...................................................................................... 44
Generierung von Pflegedialogen fr Verbrauchspositionen ..................................................... 45
Configuration of Billable Item Classes ........................................................................................ 47
System Landscape ................................................................................................................... 49
Interfaces for Billable Item Classes ......................................................................................... 51
Customer Fields in Billable Item Classes ............................................................................... 52
Interface Generation................................................................................................................. 52
Generierung von Pflegedialogen fr abrechenbare Positionen ............................................ 54
Billable Item Management ........................................................................................................... 57
Processing Rules and Program Enhancements .................................................................... 57
Transferring Raw Data into Billable Status ............................................................................. 59
Changing of Raw Data and Error Handling ............................................................................ 60
Data Storage ............................................................................................................................. 60
Displaying Billable Items .......................................................................................................... 61
Reversing Billable Items .......................................................................................................... 62
Deleting Billed Items................................................................................................................. 63
Billing Processes in Contract Accounts Receivable and Payable ............................................ 64
Flow of Billing Processes ......................................................................................................... 65
Flow Control for Billing ......................................................................................................... 66
Data Selection....................................................................................................................... 67
Selection of Billable Items ................................................................................................ 67
Controlling the Selection .................................................................................................. 69
Creation of Billing Units ........................................................................................................ 69
Aggregation of Billable Items ............................................................................................... 70
Example 1.......................................................................................................................... 72

(C) SAP AG

Example 2.......................................................................................................................... 73
Example 3.......................................................................................................................... 74
Example 4.......................................................................................................................... 75
Example 5.......................................................................................................................... 77
Example 6.......................................................................................................................... 78
Billing Document....................................................................................................................... 79
DDIC Structures and Layer Model ...................................................................................... 80
Billing Document Header.................................................................................................. 81
Billing Document Items ..................................................................................................... 82
Reversal Data.................................................................................................................... 83
Tax Items ........................................................................................................................... 83
Payment Data Items ......................................................................................................... 83
Source Items ..................................................................................................................... 84
Additional Items................................................................................................................. 85
Entering the Document Number and Assigning the Document Type ............................... 85
Enhancements of the Billing Document .............................................................................. 87
Automatic Billing: Creating Billing Documents ........................................................................... 87
Creating Billing Documents in Dialog ......................................................................................... 88
Reversing a Billing Document in Dialog ..................................................................................... 90
Archiving Billing Documents ........................................................................................................ 91
Enhancement Options in Billing .................................................................................................. 91
Integration of Billing in Other Applications.................................................................................. 96
Billable Item Transfer ............................................................................................................... 96
Account Assignments ........................................................................................................... 97
Transactions.......................................................................................................................... 97
Tax Codes for Internal Tax Determination .......................................................................... 98
Tax Codes for Externally Determined Tax.......................................................................... 98
Tax Type for Externally Determined Other Taxes .............................................................. 99
Integration with SAP Customer Relationship Management ................................................ 100
Integration with SAP Convergent Charging .......................................................................... 101
Updating Billable Items to SAP NetWeaver BW .................................................................. 105
Invoicing in Contract Accounts Receivable and Payable ............................................................ 106
Basic Terms of Invoicing in Contract Accounts Receivable and Payable .............................. 107
Invoicing Processes ............................................................................................................... 108
Invoicing Functions................................................................................................................. 109
Source Document Categories ............................................................................................... 110
Source Document Types ....................................................................................................... 111

(C) SAP AG

Invoicing Types ....................................................................................................................... 111

Invoicing Categories ............................................................................................................... 112
Target Date for Invoicing ........................................................................................................ 112
Billing Cycle ............................................................................................................................ 112
Scheduling for Invoicing ......................................................................................................... 113
The Term Invoice in Invoicing................................................................................................ 116
Invoicing Processes in Contract Accounts Receivable and Payable (FI-CA) ........................ 117
Process Flow of Invoicing Processes ................................................................................... 119
Processing Options ............................................................................................................ 120
Activating/Deactivating Invoicing Functions ..................................................................... 121
Examples: Activating/Deactivating Invoicing Functions ............................................... 122
Mandatory Invoicing Functions ...................................................................................... 123
Activation/Deactivation of Invoicing Functions.............................................................. 124
Customer-Defined Invoicing Functions ......................................................................... 125
Data Selection..................................................................................................................... 125
Invoicing Orders .............................................................................................................. 125
Selection Control ............................................................................................................. 127
Creating Invoicing Units ..................................................................................................... 128
Notes and Examples for Configuring Grouping Variants ............................................. 129
Event 2601 ...................................................................................................................... 132
Selection of Open Items ..................................................................................................... 133
Documents .............................................................................................................................. 134
Invoicing Documents .......................................................................................................... 134
DDIC Structures and Layer Model ................................................................................. 135
Invoicing Document Headers ..................................................................................... 137
Invoicing Document Items .......................................................................................... 137
Reference Table of Posting Documents.................................................................... 138
Invoicing and Reversal History Source Documents ................................................. 139
Reversal Data for Invoicing Document ...................................................................... 139
Charges and Discounts for Invoicing Documents..................................................... 139
History Records for Charges and Discounts in Invoicing Document....................... 140
Offsetting Items of Invoicing Document..................................................................... 141
Enhancements to the Invoicing Document ................................................................... 143
Document Number Assignment and Document Type .................................................. 143
Posting Documents ............................................................................................................ 144
Document Number Assignment and Document Type .................................................. 145
Functions of Invoicing in Contract Accounts Receivable and Payable............................... 146

(C) SAP AG

Invoicing of Billing Documents ........................................................................................... 146

Linking the Documents ................................................................................................... 147
Transactions .................................................................................................................... 147
Invoicing Items ................................................................................................................ 148
Business Partner Items .................................................................................................. 149
Summarization Transaction ........................................................................................ 150
Account Determination ............................................................................................... 150
General Ledger Items ..................................................................................................... 151
Account Determination ............................................................................................... 151
CO Account Assignment ............................................................................................ 152
Making System Settings for the CO-PA Account Assignment ............................. 152
Linking the Line Items ..................................................................................................... 153
Tax Calculation ............................................................................................................... 154
Internal Tax Calculation .............................................................................................. 155
Determination of the Tax Code .............................................................................. 155
Displaying Tax in Invoices ...................................................................................... 156
Maintaining Keys for the Tax Display................................................................. 156
Clearing Tax Differences ........................................................................................ 157
External Tax Calculation ............................................................................................. 158
External Tax Calculation with Internal Handling ....................................................... 159
Calculation of Telecommunications Tax.................................................................... 160
External Account Derivation ........................................................................................... 161
Supplementing Posting and Invoicing Items ................................................................. 162
Deferred Revenue Postings ........................................................................................... 162
Invoicing of SD Documents................................................................................................ 163
Invoicing of SD Documents with FI-CA Sample Document ......................................... 166
Invoicing of SD Documents Without FI-CA Sample Document................................... 168
Invoicing SD Billing Documents (VBRK) ....................................................................... 169
Reversal of SD Billing Documents (VBRK) ................................................................... 171
Invoicing Billing Requests .............................................................................................. 171
Reversing Billing Document Requests .......................................................................... 172
Collective Invoicing ............................................................................................................. 173
Invoicing Individual Accounts ......................................................................................... 174
Invoicing Collective Bill Accounts .................................................................................. 175
Invoicing List ....................................................................................................................... 176
Preselect Invoicing Document for Invoicing List ........................................................... 177
Create Invoicing List ....................................................................................................... 177

(C) SAP AG

10

Creation of Preliminary Invoices ........................................................................................ 178

Additional Functions ........................................................................................................... 180
Surcharges and Discounts ............................................................................................. 181
Selecting Open Items for Additional Functions ......................................................... 181
Charges and Discounts .............................................................................................. 182
Individual Charges and Discounts ............................................................................. 184
Debit Entry of Statistical Documents ............................................................................. 184
Calculating Interest on Open Items ............................................................................... 185
Calculation of Interest on Cash Security Deposits ....................................................... 186
Releasing/Adjusting Cash Security Deposits ................................................................ 186
Activating Line Items Posted Before Invoicing.............................................................. 187
Transferring Open Items................................................................................................. 189
Automatic Account Maintenance ................................................................................... 189
Manual Account Maintenance (Dialog Call).................................................................. 190
Enhanced Automatic Account Maintenance ................................................................. 190
Enhanced Manual Account Maintenance...................................................................... 191
Reversal of Statistical Line Items................................................................................... 192
Subitems .......................................................................................................................... 192
Setting Installment Plan to Due...................................................................................... 193
Writing Off........................................................................................................................ 193
Dunning ........................................................................................................................... 194
Payment Forms ............................................................................................................... 194
Payment History .............................................................................................................. 195
Determination of the Payment Method .......................................................................... 195
Official Document Number Assignment ........................................................................ 196
Rounding per Posting Document................................................................................... 197
Rounding per Invoicing Document ................................................................................ 197
Creation of Additional (Customer-Specific/Industry-Specific) Documents.................. 198
Plausibility Checks for Source Documents ................................................................... 199
Plausibility Checks for Invoicing Documents ................................................................ 200
Offsetting in Invoicing ..................................................................................................... 201
Activating Documents from Revenue Distribution ........................................................ 204
Stamp Tax ....................................................................................................................... 205
Ad Hoc Invoicing ............................................................................................................. 205
Invoicing Additional Periodic Source Documents ......................................................... 206
Payment Reference ........................................................................................................ 207
Card Payment (Payment Method) ................................................................................. 208

(C) SAP AG

11

Card Payment with Immediate Clearing........................................................................ 209

Balance Change of Prepaid Account ............................................................................ 209
Account Maintenance for Prepaid Account ................................................................... 210
Manual Account Maintenance for Prepaid Account ..................................................... 211
Determination of Due Date ................................................................................................ 211
Update ..................................................................................................................................... 212
Performing Invoicing .................................................................................................................. 213
Reversing Invoicing Documents................................................................................................ 214
Making System Settings for Invoicing Reversal ................................................................... 215
Performing Invoicing Reversals............................................................................................. 217
Reversing Billing Documents .................................................................................................... 217
Making System Settings for Billing Reversal ........................................................................ 219
Reversing Billing Documents................................................................................................. 219
Special Features When Reversing Billing Documents from Billing in FI-CA...................... 220
Making System Settings for Reversing Billing Documents from Billing in FI-CA ............... 220
Reversing Billing for Documents from Billing in FI-CA ........................................................ 221
Special Considerations for Reversal of Billing Documents from External Systems .......... 221
Invoice Printing ........................................................................................................................... 222
Making System Settings for Invoice Printing ........................................................................ 223
Program Enhancements in Events ........................................................................................ 224
Displaying the Invoicing Document ........................................................................................... 225
Clarification in Invoicing ............................................................................................................. 226
Validation ................................................................................................................................ 227
Plausibility Checks for Source Documents ....................................................................... 228
Plausibility Checks for Invoicing Documents .................................................................... 229
Contract Account Check .................................................................................................... 230
Error Messages................................................................................................................... 231
Validation in the Invoicing Process.................................................................................... 231
Validation in the Billing Process ........................................................................................ 233
Validation in Invoice Order Analysis .................................................................................. 233
Validation in Billing Document Display .............................................................................. 234
Validation in Billing Document Transfer ............................................................................ 234
Clarification Case ................................................................................................................... 235
Data Model .......................................................................................................................... 235
Data Storage ....................................................................................................................... 236
Statuses and Processing Statuses of Clarification Cases ............................................... 238
Clarification Case Category ............................................................................................... 240

(C) SAP AG

12

Clarification Reason ........................................................................................................... 241

Control Document............................................................................................................... 241
Clarification Processing.......................................................................................................... 242
Clarification Processing in Dialog ...................................................................................... 242
Automatic Clarification Processing .................................................................................... 245
Enhancement Options in Invoicing ........................................................................................... 245
Program Enhancements ............................................................................................................ 246
Archiving in Invoicing in Contract Accounts Receivable and Payable ................................... 246
Integration of Invoicing in Other Applications ........................................................................... 246
Integration of Invoicing with Sales and Distribution (SD) .................................................... 246
Integration of SAP Customer Relationship Management .................................................... 248
Making System Settings in the CRM System ................................................................... 249
Making Settings for the Account Determination in the ERP System .............................. 249
Determination of Contract Account in ERP System ......................................................... 251
Notes for Mapping CRM Billing Documents in the ERP System .................................... 251
Integration of Billing Systems ................................................................................................ 253
Transferring Billing Documents ......................................................................................... 253
Billing Document from Data Transfer ............................................................................ 254
Inbound Interface for Billing Documents ....................................................................... 256
BAPI BAPI_ISTBILLDOC_CREATEMULTIPLE ....................................................... 257
BAdI Methods for Inbound Interface ...................................................................... 260
Enhancement of Tables of Billing Document ........................................................ 261
Enhancement of Tables of Billing Document .................................................... 263
Billing Document Headers ...................................................................................... 264
Billing Document Items ........................................................................................... 267
Items Relevant for Posting and Printing............................................................. 271
Internal Tax Determination.................................................................................. 272
Billing Document Tax Items .................................................................................... 274
Account Determination with External Tax Calculation ...................................... 276
Account Determination with External Tax Calculation ...................................... 277
Billing Document Additional Items ......................................................................... 277
Creating Billing Documents .................................................................................... 278
Reversing Billing Documents with BAPI_ISTBILLDOC_CANCEL .............................. 279
Reversing Uninvoiced Billing Documents.................................................................. 280
Reversing Invoiced Billing Documents ...................................................................... 282
Calling BAdI Methods in the BAPI BAPI_ISTBILLDOC_CANCEL .......................... 284
Testing Reversals of Billing Documents .................................................................... 286

(C) SAP AG

13

Adjusting Billing Documents with BAPI_ISTBILLDOC_ADJUST ................................ 287

Adjusting Uninvoiced Billing Documents ................................................................... 289
Adjusting Invoiced Billing Documents........................................................................ 290
Repeating Adjustment of Invoiced Billing Documents.............................................. 291
Reversing Adjustment Billing Documents ................................................................. 292
Testing Adjustments of Billing Documents ................................................................ 293
ALE Interfaces................................................................................................................. 294
Displaying Billing Documents......................................................................................... 294
Update to SAP NetWeaver BW ............................................................................................. 295
DataSource 0FC_INVDOC_00 .......................................................................................... 296
BW Extraction Orders......................................................................................................... 297
Event 2710 .......................................................................................................................... 298
Extracting Documents ........................................................................................................ 298
Extraction of Invoiced Billable Items ................................................................................. 300
Extraction Method for SAP NetWeaver BW (BW) ............................................................ 300
Master Data in SAP Convergent Invoicing ................................................................................... 301
Product ........................................................................................................................................ 303
Provider Contract ....................................................................................................................... 305
System Settings for Accessing Provider Contracts.............................................................. 307
Displaying and Changing Provider Contracts....................................................................... 308
Authorization Objects for Provider Contracts ....................................................................... 311
Referencing of Provider Contracts ........................................................................................ 311
Replication of Business Partners and Accounts ...................................................................... 312

(C) SAP AG

14

SAP Convergent Invoicing

Together the Billing in Contract Accounts Receivable and Payable and Invoicing in Contract
Accounts Receivable and Payable components form SAP Convergent Invoicing.

Integration
SAP Convergent Invoicing offers you the possibility of integrating the following applications:
SAP Convergent Charging
SAP Customer Relationship Management
Contract Accounts Receivable and Payable
This comprehensive integration enables you to implement the business process from the
consumption of a service through pricing and billing right up to dispatch of the invoice to the
customer.

SAP
Convergent Charging

SAP
Convergent Invoicing
SAP ERP

Consumption

Mediation

Rating
Charging

Billing

Invoicing

Contract
A/R & A/P

Consume to Cash Scenario

Billing in Contract Accounts Receivable and Payable

Billing in Contract Accounts Receivable and Payable (FI-CA) manages billable items and groups
them together into billing documents, which you process further in Invoicing in Contract Accounts
Receivable and Payable through to the creation of the invoice to the customer.

Integration
Billing in Contract Accounts Receivable and Payable processes one-off charges that you make in
SAP Customer Relationship Management (CRM). You can integrate one-off charges from SAP
CRM directly with Billing in Contract Accounts Receivable and Payable.
In addition, Billing in Contract Accounts Receivable and Payable is integrated with SAP
Convergent Charging.
(C) SAP AG

15

SAP Convergent Charging offers service industries the following functions for billing services
(such as, telephone calls for telecommunications providers):
Price modeling for services (transactions)
Rating
Charging
Based on this integration, you can adopt billable items directly from SAP Convergent Charging to
Billing in Contract Accounts Receivable and Payable. SAP Convergent Invoicing subsequently
groups the priced services into invoices that you send to customers, and posts the invoice
amounts in Contract Accounts Receivable and Payable.
Example
The following illustrates the integration of SAP Convergent Charging and SAP Convergent
Invoicing using an example from the telecommunications industry.
A customer has a cellular network contract with a telephone company; the telephone company
bills the customer monthly for services (phone calls and SMS).
1. Consumption
The customer sends an SMS with his cellular phone. He thereby consumes a service of
the telephone provider. The telephone network transfers the SMS usage data, that
means that the content of the SMS is sent to the recipient. The telephone provider
records information about the SMS consumption, such as the date, the time and the
telephone number, and passes on this data.
2. Mediation
The telephone provider converts the payment-relevant information for the SMS
consumption into a uniform format.
3. Rating
SAP Convergent Charging determines a price for the SMS based on the rate in the
cellular network contract; the rating process converts the service data into a monetary
amount.
4. Charging
SAP Convergent Charging, using the technical information for the SMS consumption
(such as the telephone number), determines the invoice recipient and the customer
account to be debited.
5. Billing
Billing in Contract Accounts Receivable and Payable takes over the billing-relevant data
for the SMS consumption and processes this data. Billing groups the data together with
other existing SMS consumption of the customer and summarizes the data in a billing
document. This means the system performs a preliminary aggregation of structured data
records (billable items) according to technical and business criteria.
Note

(C) SAP AG

16

Billing in Contract Accounts Receivable and Payable works without time zones. That
means that Billing in Contract Accounts Receivable and Payable adopts the unconverted
date and time from the external rating and charging system.
End of the note.
6. Invoicing
Based on the billing document and possibly additional source documents from other
systems, Invoicing in Contract Accounts Payable and Receivable creates an invoice for
the customer for the total monthly amount and posts this total amount to the contract
account of the business partner as a receivable.
7. Contract Accounts Receivable and Payable
You manage the receivable using the standard processes of Contract Accounts
Receivable and Payable and collect the receivable from the customer (incoming
payment, dunning).
End of the example.

Features
Billing in Contract Accounts Receivable and Payable groups the billable items into billing
documents. The document flow is as follows:
1. Transfer and storage of billable items from external systems (for example, SAP
Convergent Charging)
2. Management of billable items and creation of billing documents using the processes of
Billing in Contract Accounts Receivable and Payable.
3. Further processing of billing documents using the processes of Invoicing in Contract
Accounts Receivable and Payable
4. Archiving of Billing Documents
The processes shown in the figure can run asynchronously.

(C) SAP AG

17

Runtime

Contract
Account
2

Items
Items

Archiving

Billable Items
Transfer

Billing
Document

Billing

Billable Items

Billed Items

Design time

Billable Item
Management

Billing

Document Flow of Billing

Basic Concepts of Billing in Contract Accounts

Receivable and Payable
The following sections give you an overview of the concepts and parameters:
That define and control billing processes
With which you can design the billing process and adjust it to your needs
In addition to the most important concepts, the following sections also explain the usage of the
individual elements, the possibilities available when using them are explained on the basis of
examples and the settings in the Implementation Guide are discussed.

(C) SAP AG

18

Runtime

Contract
Account

unit
Billing
Unit

Billing Process

Billing
Document

Billable Item

Design Time
Billing Process

Selection
Variant

Grouping
Variant

Subprocess

Invoicing
Category

Billing Type

Billing Process

Billable Item
The billable item represents an item that is to be billed. The creation of billable items is triggered
by a business transaction or a business event.

Structure
The billable item class determines the technical properties of a billable item.
A billable item can have various statuses. Billing considers only those billable items that have the
status Billable. Once the items have been successfully processed in billing, the system assigns
them the status Billed. The system manages the various statuses of billable items from a
technical perspective by using different database tables. The system stores billable items in a
separate database table for each status and billable item class. An exception to this rule is the
status Billed. For this status, you can specify in Customizing how many tables you want to use
and how these are used. In relation to the database tables used, the system also differentiates
based on the following record types:
Main items
These represent the actual receivable or payable.
Record types dependent on main items
These represent attachments to the main items.

(C) SAP AG

19

The main items and the dependent record types use separate database tables.

Billable Item Class

The billable item class determines the technical properties of a billable item. These technical
properties include:
Database tables in which the system stores billable items depending on their status and
their record type
Function modules that accept billable items
Function modules that save the billable items in the respective database tables
Specific fields of billable items that you have added either through the selection of
interface components or through customer fields

Billable Item Types

A billable item type (item type), in conjunction with the subprocess, defines the business
significance of the billable item. Each item type is assigned to one or more subprocesses.

Using the item type, you can influence the scope of the selection for billable items when you
define the selection variant. You also have the option of using the item type to determine a
grouping variant for aggregation.
You define the billable item type in Customizing for Contract Accounts Receivable and Payable
under Billing in Contract Accounts Receivable and Payable Basic Data Define Item Types
.

Source Transaction
The source transaction is defined by the source transaction type and the source transaction ID. A
source transaction represents a group of billable items that are related in a business sense. You
define the business significance and processing rules for a source transaction with the source
transaction type.

The system processes billable items by source transaction, consisting of the source transaction
ID and the type of source transaction. A source transaction can include billable items of different
record types.
Note

(C) SAP AG

20

SAP does not define the source transaction. At the same time, the system fully supports source
transactions with regard to selection, navigation and transparency. The source transaction should
comprise the items of a common business transaction.
If you are using the integration between SAP Convergent Charging and SAP Convergent
Invoicing, the ID of the set of priced items acts as the source transaction, since the billable items
come from pricing.
End of the note.

Source Transaction Type

The source transaction type defines the business significance of the source transaction ID both
from the point of view of Billing in Contract Accounts Receivable and external systems. The
source transaction type also defines the rules for interpreting the source transaction ID and the
source transaction in follow-on processes.
Together with the source transaction ID, the type of source transaction forms a source
transaction.
You define the source transaction type in Customizing for Contract Accounts Receivable and
Payable under Integration Billing in Contract Accounts Receivable and Payable Basic Data
Define Source Transaction Types . Here you can set the following processing rules for the
source transaction type:
Individual processing of billable items in a source transaction
The standard is for the system to process all billable items of a source transaction
together. Select this processing rule only if you want to process the individual items of
your source transactions separately.
Note
The system groups logically-related billable items in packages in the inbound interface.
As a rule, the system assigns billable items to an individual package. The composition of
packages of billable items differs, however, when dependent record types are used (see
Billable Item Packages).
End of the note.
Internal assignment of the source transaction ID by billable items
If you make this setting, the system assigns the source transaction ID internally. Each
billable item receives a unique source transaction ID (GUID).
Note
The system fully supports the source transaction in terms of selection and navigation in
billing. Therefore, select this processing rule only if you are not able to assign the source
transaction a useful external value.
Note that internal assignment of the source transaction is only supported if you do not
use dependent record types. Otherwise errors occur during the transfer of billable items.

(C) SAP AG

21

End of the note.

Example
As standard, SAP Convergent Charging transfers all priced items with the source transaction type
CCCIT to SAP Convergent Invoicing.
End of the example.

Billable Item Packages

Billing in Contract Accounts Receivable and Payable supports document-like administration and
processing of logically-related billable items in packages. The system composes these packages
during the transfer of billable items according to the following attributes of billable items:
Source transaction
Subprocess
Master data
Related payment and tax data (see Record Type)

The system always regards and processes the items of a package as a unit. In particular, the
system bills the items together or withdraws them from processing together. Individual items of a
package are identified using sequence numbers.
Note
A package of billable items generally corresponds to a source transaction. In this case the
package number is equivalent to the internal number of the source transaction. Note the
recommendations in the Source Transaction section.
End of the note.

Example
In an internet download you want to pay multiple items of a source transaction together with an
externally authorized credit card item. During the transfer, the system groups the affected items
into a common processing package (package of billable items). The individual items of a package
cannot be processed separately in follow-on processes.

Interface Component
An interface component maps a business process from the billing point of view. It defines which
business transactions are represented by a class of billable items (such as deferred revenues
and clearance of down payments). Interface components constitute the interface for a class of
billable items.

(C) SAP AG

22

SAP supplies preconfigured interface components that can be used immediately. These include
basic components required for a record type as well as additional optional components that you
can add to a class.
Note
You cannot use customer-defined interface components.
End of the note.
You can find an overview of available interface components in Customizing for Contract Accounts
Receivable and Payable under Integration Billing in Contract Accounts Receivable and
Payable Billable Item Classes Define Interface Components .
When you define billable item classes, you assign interface components to the classes. On the
basis of this assignment, the system generates interfaces in which it automatically integrates the
fields of the interface component. An interface, in turn, comprises function modules that transfer
the data as well as tables in which the system stores the data.
Note
Some interface components correspond to invoicing functions in Billing in Contract Accounts
Receivable and Payable or augment them.
End of the note.

Structure
Initially, an interface component is comprised of such information as an interface name and a
description. It can also have a data element that documents the interface. Going further, an
interface component is also defined by the following settings:
The assigned structures
Structures are assigned based on the record type and the status. You can also define
that entries that do not belong to the record type of the main item are only active
conditionally.
Prerequisite components
This setting indicates which interface components function as prerequisites. The basic
components are not listed here; these are defined separately.
Program Enhancements
These are function modules that the system calls at the defined times. The function
modules are used for enrichment and checks.

Basic Data for Billing

(C) SAP AG

23

The interface component Basic Data for Billing is the basis for billable items. It contains the most
important selection and administrative data of the billable item.

This interface component is a basic component that is active in every class of billable items. It is
relevant is for the main items record type.
If this interface component is active, you can select additional customer fields for main items
when configuring the classes of billable items. For more information, see Customer Fields in
Billable Item Classes.
Note
Note that in the standard billing scenario, you can only process billable items that contain, in
addition to the basic data, account assignment information as part of the structure of the billing
document. You can add the corresponding fields using, for example, the interface component
Receivables/Payables (Reduced Interface).
End of the note.

Receivables/Payables (Reduced Interface)

The interface component Receivables/Payables (Reduced Interface) provides the fields in the
interface for the transfer of billable items with which you derive the principal account assignment
information for the structure of a billing document in invoicing.

When the billable items are transferred from an external system, there is no prerequisite that they
have the formats and values of the account assignment attributes known in the SAP system.
Activate this interface component if account assignment information required for posting is
unknown to the sending system and you want to derive the information from the externally-set
attributes of the billable items.
The system derives the account assignments from the settings in Customizing for Contract
Accounts Receivable and Payable under Integration Billing in Contract Accounts Receivable
and Payable Billable Item Transfer Account Assignment Derivation in the following
activities:
Define Account Assignments
Define Main Transactions and Subtransactions (for billable items that do not have
account assignment to a product)
Define Main and Subtransactions for Items with Product Account Assignment (for billable
items that have account assignment to a product)
Additionally, in posting area 8123 you can derive the tax code from an external tax code (activity
Define Tax Code for Internal Tax Determination).

(C) SAP AG

24

This interface component corresponds to interface component Receivables/Payables (Extended

Interface); however, the interface is restricted to the attributes of billable items required for the
derivation of account assignment information.

Receivables/Payables (Extended Interface)

The interface component Receivables/Payables (Extended Interface) provides the fields in the
interface for the transfer of billable items with which you transfer the principal account assignment
information for the structure of a billing document in invoicing.

Activate this interface component if you can already transfer or derive the account assignment
information at the interface and the corresponding fields have not already been provided by other
interface components.
If the billable items do not contain account assignment information, you must ensure that the
system interprets the items correctly in the billing program (if necessary in the customer
implementation of an event). You do this either by deriving the account assignments in billing or
applying other functions.
When the billable items are transferred from an external system, there is no prerequisite that they
have the formats and values of the account assignment attributes known in the SAP system. You
can assign external account assignments to internal account assignments using the interface
component External/Internal Account Assignment.
Interface component Assigning External/Internal Tax Codes is also available. Alternatively, you
can use interface component Receivables/Payables (Reduced Interface), in which the
aforementioned derivations are executed automatically.

Subitems
The interface components Subitems of Billable Items and Subitems of Billed Items cause the
system to take subitems into account in its administration of the statuses billable and billed for
main items.
These interface components are optional; they are relevant for the main items record type.

(C) SAP AG

25

Main Items

Linked via BITPACKCNO_IT

Subitems

Relationship Between Main and Subitems

If this interface component is active, you can define which fields remain in the main item and
which in the subitem when configuring the classes of billable items in Customizing. You make this
setting in Customizing for Contract Accounts Receivable and Payable under Integration
Billing in Contract Accounts Receivable and Payable Billable Item Classes Maintain Billable
Item Classes with the Optimize button.
Example
A rating system collects the main items for a particular customer throughout the day. At a
particular point in time, the system transfers the data to Billing in Contract Accounts Receivable
and Payable. The values of the main items differ in only a few fields.
To optimize performance and data retention, you summarize the matching values in a main
record and store the divergent values separately in a supplementary table. To do this, activate the
interface component Subitems of Billable Items or Subitems of Billed Items. If one of the interface
components is active for a class, you can use the Optimize button when configuring the classes
of billable items in Customizing to define which fields are assigned to the subitems the ones for
which you expect deviating values.
End of the example.

External Reference of the Billable Item

(C) SAP AG

26

The interface component External Reference of the Billable Item provides the external reference
of the billable item in the billable items structure.

The external reference of the billable item is found in the raw data of all record types by default.
The field is used for the unique identification of a billable item in the inbound interface. If the
external reference is to be available within billing or after billing, you can ensure this using the
External Reference of the Billable Item.

External Master Data Reference

The interface component External Master Data Reference is used in the derivation of master data
from external master data references. It contains the contract account number and the business
partner number in the external system.

Activate this interface component only if you want to transfer billable items that have no contract
account or business partner data and for which you want to derive the master data from the
external references.

Contract Reference
The interface component Contract Reference contains the contract reference.

You use this interface component in the classes of billable items whose items you want to be able
to explicitly link to a contract.

Billing Quantity
The interface component Billing Quantity makes it possible to store the billing quantity in the
billable item.

Usage Period
You use the interface component Usage Period in your billable item classes in order to specify a
usage period based on dates and times. The interface component contains the following fields:
Date From

(C) SAP AG

27

Time From
Date To
Time To
The interface component Basic Data for Billing already contains the fields Date From and Date
To. If you also need to be able to enter times, use the interface component Usage Period in
addition.
Example
The usage period encompasses the time from the start to the end of a telephone call.
End of the example.

Tax Jurisdiction Code

The interface component Tax Jurisdiction Code contains the tax jurisdiction code.

You use this interface component in the billable item classes to transfer the tax jurisdiction (for
example for tax determination in the US).
The interface component Receivables/Payables (Reduced Interface) is the prerequisite for the
interface component Tax Jurisdiction Code.

External/Internal Account Assignment

The interface component External/Internal Account Assignment is used for the derivation of
internal account assignments of billable items from the account assignment information from the
external system.

When the billable items are transferred from an external system, there is no prerequisite that they
have the formats and values of the account assignment attributes known in the SAP system.
Instead, you can transfer the account assignments of the external system to the interface in the
predefined fields (external item IDs) and use them to derive the account assignments for the
billable items to be used in the SAP system.
The interface component External/Internal Account Assignment contains the external item IDs for
the derivation of the following account assignments of the billable items:
Company code
Division
Business area

(C) SAP AG

28

Segment
Main transaction
Subtransaction
The system derives the account assignments using the settings in Customizing for Contract
Accounts Receivable and Payable under Integration Billing in Contract Accounts Receivable
and Payable Billable Item Transfer Account Assignment Derivation Define Account
Assignments in the following activities:
Define Account Assignments
Define Main Transactions and Subtransactions (for billable items that do not have
account assignment to a product)
Define Main and Subtransactions for Items with Product Account Assignment (for billable
items that have account assignment to a product)
Function module FKK_BIX_IFCOMP_ACC_ASSG_MAP_30 executes the required steps.
The interface component External/Internal Account Assignment requires that the structure of the
billable item contains the aforementioned account assignment fields. These are provided, for
example, by the interface component Receivables/Payables (Reduced Interface).

Deferred Revenues - Time-Based

The interface component Deferred Revenues - Time-Based provides the fields in the interface for
the transfer of billable items that you use to transfer the application and control data to invoicing
that is required for the invoicing function Deferred Revenues.

Activate this interface component only if you use the invoicing function Deferred Revenues.

Deferred Revenues - Event-Based

The interface component Deferred Revenues - Event-Based provides the fields in the interface
for the transfer of billable items that you use to transfer the application and tax data to invoicing
that is required for the invoicing function Event-Based Deferred Revenues.

Activate this interface component only if you use the invoicing function Event-Based Deferred
Revenues.

Offsetting in Invoicing

(C) SAP AG

29

The interface component Offsetting in Invoicing provides the fields in the interface for the transfer
of billable items that you use to transfer the application and control data to invoicing that is
required for the invoicing function Offsetting in Invoicing.

Activate this interface component only if you use the invoicing function Offsetting in Invoicing.

Basic Data for Payment Processing

The interface component Basic Data for Payment Processing is a basic component.

If the interface component is active:

The system adds the payment data items record type to a class of billable items
You can add customer fields to the record type payment data items when configuring
classes of billable items in Customizing
For more information, see Customer Fields in Billable Item Classes.

Payment Reference
The interface component Payment Reference provides the fields for generation of the payment
reference in invoicing in the interface for the transfer of billable items.

The payment reference is used in the payment of posting items derived from the billable items.

Card Payment
The interface component Card Payment provides the fields in the interface for the transfer of
billable items that are used to transfer the card data for payment processing of the receivables
that result from billable items.

The invoicing functions Card Payment (Payment Method) and Card Payment with Immediate
Clearing process the card data.
Activate this interface component only if you use one of these invoicing functions.

(C) SAP AG

30

Payment Card Data

The interface component Payment Card Data augments the interface component Card Payment.

This interface component provides the fields in the interface for the transfer of billable items with
which you transfer detail information (in particular authorization data) about payment cards.
The system does not store the card data details transferred through the interface directly in the
billable items but in a card data supplement (table DFKK_PCARD). The system stores the key for
the card data supplement as a reference to the card data details in the billable item.

Externally-Determined Tax Data

The interface component Externally-Determined Tax Data is a basic component.

If the interface component is active:

The system adds the tax items record type to a class of billable items
You can add customer fields for the record type tax items when configuring classes of
billable items in Customizing
For more information, see Customer Fields in Billable Item Classes.

Assigning External/Internal Tax Codes

The interface component Assigning External/Internal Tax Codes is used to derive the internal tax
code or tax determination code from an external tax code for billable items with the tax
determination type Internal Tax Calculation (01).

When the billable items are transferred from an external system, there is no prerequisite that they
have the values known in the SAP system for the tax account assignment. You can transfer the
tax code from the external system using the External Tax Code field in the interface. The
interface component Assigning External/Internal Tax Codes contains the field for the external tax
code as the basis for deriving the tax code or tax determination code. The system performs the
derivation based on the settings in Customizing for Contract Accounts Receivable and Payable
under Integration Billing in Contract Accounts Receivable and Payable Billable Item
Transfer Account Assignment Derivation Define Tax Code for Internal Tax Determination .

(C) SAP AG

31

External/Internal Tax Type for Other Taxes

The interface component External/Internal Tax Type for Other Taxes is used to transfer billable
items with the tax determination type External Tax Calculation (Other Tax) (02).

With external tax handling the tax is not calculated in Contract Accounts Receivable and Payable
but in the external billing system. The external system transfers the billable items with the
complete tax items to billing in the SAP system, which transfers the items to Contract Accounts
Receivable and Payable using invoicing. The billing document created by invoicing indicates the
items as tax items. Contract Accounts Receivable and Payable posts and treats the items not as
tax items but as revenue items. However, generally the values and the format of the tax account
assignments sent by the external system do not match the account assignments for other taxes in
Contract Accounts Receivable and Payable. It is necessary to derive the internal codes from the
external codes. The interface component External/Internal Tax Type for Other Taxes contains
fields through which you can transfer the values for external tax codes and from which the system
then derives the codes for posting other taxes in the SAP system. The system performs the
derivation based on the settings in Customizing for Contract Accounts Receivable and Payable
under Integration Billing in Contract Accounts Receivable and Payable Billable Item
Transfer Account Assignment Derivation Define Tax Type for Other Taxes Determined
Externally .
Activate this interface component only if you want to transfer billable items for which the tax has
already been determined externally and which you post as other taxes in the SAP system.

Tax Codes for Externally Determined Tax

The interface component Tax Codes for Externally Determined Tax is used to transfer billable
items with the tax determination type External Tax Calculation with Internal Handling (03).

The external system transfers billable items to Accounting in the SAP system that already contain
all tax-relevant information (including tax amounts). Accounting in the SAP system forwards these
items to Contract Accounts Receivable and Payable through Invoicing. The billing document
created by Invoicing indicates these items as tax items. Contract Accounts Receivable and
Payable posts them as tax items.
If the external tax codes do not correspond with the internal IDs of the SAP system, you must
derive the internal codes from the external ones. The interface component External Tax
Calculation with Internal Handling contains fields through which you transfer the values for
external tax codes and from which the system then derives the codes for posting taxes in the
SAP system. The system performs the derivation based on the settings in Customizing for
Contract Accounts Receivable and Payable under Integration Billing in Contract Accounts
Receivable and Payable Billable Item Transfer Account Assignment Derivation Define Tax
Code for Tax Determined Externally .
Activate this interface only if you want to transfer billable items with previously determined tax
amounts.

(C) SAP AG

32

SAP Convergent Charging

The interface component SAP Convergent Charging is used for the transfer of billable items from
SAP Convergent Charging.
Note
If you activate the SAP Convergent Charging interface component, the system automatically
activates the interface component Receivables/Payables (Reduced Interface).
End of the note.

CRM Order
The interface component CRM Order derives the internal account assignments of the billable
items from the account assignment information from Customer Relationship Management (CRM).

When the billable items are transferred from CRM, there is no prerequisite that they have the
formats and values of the account assignment attributes known in the SAP system. Instead, you
can transfer the account assignments of the external system to the interface in the defined (by
SAP CRM) fields and use them to derive the account assignments for the billable items to be
used in the SAP system. The interface component CRM Order contains the external values for
the derivation of the following account assignments of the billable items:
Billing subprocess
Billable item class
Type of the billable items
Company code
Division
Business area
Segment
Main transaction
Subtransaction
The system performs the derivation on the basis of the settings in the activities under Transfer of
One-Off Charges from Customer Relationship Management in Customizing for Contract Accounts
Receivable and Payable under Integration Billing in Contract Accounts Receivable and
Payable Billable Item Transfer .
The interface component CRM Order requires that the structure of the billable item contains the
aforementioned account assignment fields. These are provided, for example, by the interface
(C) SAP AG

33

component Receivables/Payables (Reduced Interface). This interface component also requires

interface components External Reference of the Billable Item and Contract Reference.

Basic Data for Telecommunications Taxes (US)

The interface component Basic Data for Telecommunications Taxes (US) is an optional interface
component. It is relevant is for the main items record type. It contains specifications for the
calculation of telecommunications taxes in the US and Canada.

Select the interface component Basic Data for Telecommunications Taxes (US) only if you need
to calculate telecommunications taxes for billable items, as is the case for telephone connections
and text messages to the US or Canada.

External Provider Contract Reference

The interface component External Provider Contract Reference contains a reference to a provider
contract.
You use the interface component External Provider Contract Reference in billable item classes
with items that relate to contract items of a provider contract.
When the billable items are transferred from an external system, there is no prerequisite that they
have the formats and values of the account assignment attributes known in the SAP system.
Instead, the system adopts the following account assignment attributes from the provider contract
item:
Company code
Division
Business area
Segment
Profit center
The system derives the main transaction and subtransaction from the settings in Customizing for
Contract Accounts Receivable and Payable under Integration Billing in Contract Accounts
Receivable and Payable Billable Item Transfer Account Assignment Derivation Define Main
and Subtransactions for Items with Product Account Assignment .
The interface component requires that the structure of the billable item contains the account
assignment fields mentioned above. These are provided, for example, by the interface
component Receivables/Payables (Reduced Interface).

(C) SAP AG

34

Prepaid
The interface component Prepaid makes the basic fields available for billable items that are
needed for processing actions on prepaid accounts.
The interface component Prepaid is mandatory for processing billable items that relate to prepaid
usage and refills.
For refill items, the interface component Refill of Credit on Prepaid Accounts is also required.
This interface component can process only those billable items that fulfill these prerequisites:
The Prepaid (PREPAID) field contains the value X.
The Prepaid Account (PPACC) field contains a valid prepaid account.
Prepaid usages are processed in invoicing by the invoicing function Invoicing of Billing
Documents. This processing is very much similar to the processing of postpaid usages.
Prepaid refills are processed in invoicing by the invoicing function Balance Change of Prepaid
Account.

Refill of Prepaid Quantities/Packages

The interface component Refill of Prepaid Quantities/Packages makes the necessary fields for
refilling quantities or packages on prepaid accounts available on the interface for billable items.
The interface component Refill of Prepaid Quantities/Packages is optional for the processing of
prepaid refill items. The interface component Refill of Credit on Prepaid Accounts is a prerequisite
for this interface component.
A refill package can consist of up to three components, also called refillable units. The refill of a
prepaid account using a refill package is transferred to the interface by a single item with the
status Raw. In the REFPK field, this item contains the refill package, and transfers the refillable
units and their number in the following field pairs:
TUSE1 CNTU1 (Requested Number for Component 1)
TUSE2 CNTU2 (Requested Number for Component 2)
TUSE3 CNTU3 (Requested Number for Component 3)
When the billable items are created, the interface component generates a separate item for each
component. In this item, the refillable unit and the related number are transferred to the fields
Refillable Units (TUSEX) and Requested Number (CNTUX).

Refill of Credit on Prepaid Accounts

(C) SAP AG

35

The interface component Refill of Credit on Prepaid Accounts makes the necessary fields for
refilling credit on prepaid accounts available on the interface for billable items.
The interface component is mandatory for processing billable items for prepaid refills. The
interface component Prepaid is a prerequisite for this interface.
The interface component can process only those billable items that fulfill these prerequisites:
The Balance Change (PPREFILL) field contains the value X.
The Prepaid (PREPAID) field contains the value X.
The Prepaid Account (PPACC) field contains a valid prepaid account.
Prepaid refills are processed in invoicing by the invoicing function Balance Change of Prepaid
Account.

Billable Item Status

A billable item has one of the following statuses:
0 (Raw)
1 (Raw excepted)
2 (Billable)
3 (Billable excepted)
4 (Billed)

(C) SAP AG

36

Billable

Billed
Billed
Billed
Billable
Excepted

Raw
Raw
Excepted

Interaction Between Billable Item Statuses

Upon transfer, billable items in Contract Accounts Receivable and Payable get the status billable.
If the system cannot identify master data, billable items receive the status Raw. You can also
influence this behavior using upload rules (see Upload Rules and Program Enhancements).
The billing process changes billable items from the status billable to the status billed.
The system uses separate tables for each status. For more information, see Transferring Raw
Data into Billable Status and Changing Billable Items and Error Handling.

Record Type
The record type groups characteristics of billable items which are related in a business sense.

Structure
The system administers data of the following record types separately in the database and the
main memory:
IT (main items)
PY (payment data items)
TX (tax items)

(C) SAP AG

37

Billable items of the record type IT are required and provide the fundamental data for billing. The
other record types are dependent record types that the system cannot bill without existing IT
records (such as credit card supplements).
The system uses separate tables for each record type.

Main Items

Linked via PY_GROUP

Payment Data
Items

Linked via TAX_GROUP

Tax Items

Linking of Main Items with Dependent Record Types

Billing Process
The billing process is the umbrella term for the execution of billing in Contract Accounts Payable
and Receivable according to defined rules. These rules are defined by parameters that you use to
control the billing process.

When defining a billing process, you specify which billable items the system selects for billing.
You can also influence the grouping and the aggregation level of the billable items. This flexibility
adds to the flexibility of using modification-free enhancements by means of includes and events.
Note
In the following situations there is a link to billing processes:
Billing processes serve as selection parameters of the mass activity for billing in Contract
Accounts Receivable and Payable.

(C) SAP AG

38

They define number ranges for billing documents that are dependent on the billing
processes.
End of the note.
You create new billing processes in Customizing for Contract Accounts Receivable and Payable
under Integration Billing in Contract Accounts Receivable and Payable Billing Processes
Define Billing Processes .

Structure
A billing process specifies which subprocesses it supports. At least one subprocess is mandatory.
You can control the following at the level of the subprocess:
Selection of items to be billed
You have to assign a selection variant to each subprocess. This selection variant controls
the selection of the items to be billed in billing for a certain contract account.
Grouping of billable items into billing units
To group billable items in invoicing into a common invoice, you can assign each
subprocess a separate grouping variant that the system uses to automatically group
together billable items.
Using the billing types assigned to it, the billing process also classifies the billing documents from
a business perspective.
In billing, you can use the billing process to control the aggregation of billable items using an
additional grouping variant.

Subprocess
The subprocess in combination with the item type represents the business significance of a
billable item.

Each subprocess is assigned to one or more billable item classes. The subprocess is an
independent processing branch within the billing process with regard to selection and the
grouping of billable items and their processing for a billing document. The system assigns the
billable items to one of the subprocesses as soon as they are created. You cannot process these
billable items together with the billable items of other subprocesses in a common billing
document.
The following control options exist:
Selection of the billing worklist
For each subprocess you can define which billable item classes the system is to select
and process. You can further refine the selection by specifying per class the type and
source transaction type of the billable item.
Grouping of the billable items in billing units

(C) SAP AG

39

You can assign to each subprocess an individual grouping variant for automatic
summarization of billable items for which the system creates a common invoice.
Definition of the billing type
You create new subprocesses in Customizing for Contract Accounts Receivable and Payable
under Integration Billing in Contract Accounts Receivable and Payable Basic Data Define
Billing Subprocesses .

Example
You have two distinct groups of billable items (for example from two different industries).
The system should do the following with these items:
Bill them at different intervals
Select them according to different considerations
Group them into billing units and process them in billing documents
You achieve this by assigning the groups their own subprocesses.
You can then process the two subprocesses together or in separate billing processes.
If business-related dependencies exist between the subprocesses, such as with music downloads
and royalties, it may be useful to assign both subprocesses to the same billing process. A
business dependency in the music download example may occur if, for example, there is a
requirement that royalties only be billed once the corresponding music downloads (payables)
have been billed.

Billing Type
The billing type characterizes the composition of billing units and classifies billing documents.

You can use the billing type optionally instead of the determination of the document type and the
source document type of the billing document. The billing type is also available in events for
billing (for example, in the events 8120, 8125, and 8130).
You create new billing types in Customizing for Contract Accounts Receivable and Payable under
Integration Billing in Contract Accounts Receivable and Payable Billing Processes Define
Billing Types .

Example
You want to distinguish between billing documents that belong to periodic billing and billing
documents that arise due to the contract being ended (final billing documents). You make this
distinction using the billing type.
For final billing documents, you want to add additional informational items that are not relevant for
posting. At event 8125, you use the billing type to control the creation of the additional billing
document items.

(C) SAP AG

40

Type of Billing Document Item

The type of billing document item (ITEMTYPE) describes the business significance of the
document items of a billing document.

The system derives the type of billing document item from the subprocess and the item type of
the billable item linked with the document item. As a result, the business significance of the
billable item is represented by the item type of the billing document item, and is transferred, for
example, to invoicing and invoice printing.
You assign the type of billing document item to the attributes subprocess and item type of billable
item in Customizing for Contract Accounts Receivable and Payable under Integration Billing
in Contract Accounts Receivable and Payable Billing Processes Assign Billing Item Types .

Billing Target Date

The target date for billing is the earliest possible billing time for a billable item.

The billing target date defines that a billable item may not be billed until the specified date has
been reached (in relation to the billing date).
Only in expert mode for billing can you bill billable items before they reach the target date.
The system determines the target date for billing using scheduling. You can specify in
Customizing the date that you want to serve as the baseline date for the determination. Based on
the baseline date, the system determines the target date for billing using the determination rules
that you also define in Customizing. You define both the baseline date and the calculation rules in
Customizing for Contract Accounts Receivable and Payable under Integration Billing in
Contract Accounts Receivable and Payable Basic Data Scheduling Define Rules for
Determining the Billing Date .
Example
You specify the baseline date as the creation date of the billable item and always bill the billable
items on a fixed day.
End of the example.

Billing Cycle
The billing cycle is used to specify billing periods. The billing cycle specifies the period end and
the length of a billing period.

(C) SAP AG

41

The actual billing time span can differ from the billing period.
Example
You do not transfer billable items from the month of January into the system until February. The
invoice for the month of February, therefore, has a billing time span that goes back into January,
whereas the billing period consists only of the month of February.
End of the example.
You define the billing cycle in Customizing for Contract Accounts Receivable and Payable under
Integration Billing in Contract Accounts Receivable and Payable Basic Data Scheduling
Define Billing Cycle or under Integration Invoicing in Contract Accounts Receivable and
Payable Invoicing Invoicing Processes Scheduling for Invoicing Define Billing Cycle .
Then you enter the technical key of the billing cycle in the contract accounts or in the provider
contract items of your business partners.
Depending on the configuration of the billing cycle, you can overwrite the period end date at the
level of the contract account.
You can use the billing cycle in scheduling for determining the target date of billing or the target
date of invoicing.

Scheduling in Billing
Using scheduling, the system determines the target date for billing, that is, the earliest possible
date for billing of billable items (see Target Date for Billing).

Features
Scheduling helps both to technically distribute the load on the system, as well as allowing you to
specify a customer-specific billing date.
You can use the billing cycle to influence the determination of the target date of billing and the
target date of invoicing. If a billing cycle is entered in the contract account, then it applies (if no
further changes are made) to both billing and invoicing.
You can enter a different billing cycle in the provider contract items than in the contract account.
As a result, billing could take place on a weekly basis and invoicing take place every two weeks.
If you do not need this separate control, then it is sufficient to enter the billing cycle either in the
contract account or in the provider contract. If you do not want to use cycle-based billing or
invoicing for certain billable items or source documents, you can define different rules for these
objects.
Regardless of whether or not you use billing cycles, you can influence the billing date and
invoicing date as follows:
You can specify grace days, such as two days after the creation of the invoicing order.
You can define periods, such as every 14 days.
You can configure special factory calendars.

(C) SAP AG

42

If you want special dates to be valid for certain contract accounts, you can define different rules
for them that are dependent on the selection characteristic for scheduling.
Note
The standard system determines the billing date and the invoicing date cycle-based at the end of
the period as long as a billing cycle is entered in the contract account or provider contract and
no different rules for determining the times of execution are entered in the system. In all other
cases, the rules for determining the target date of billing and the target date of invoicing specify
the times when billing or invoicing is executed.
End of the note.

Activities
You make the system settings for scheduling in Billing in Contract Accounts Receivable and
Payable in Customizing for Contract Accounts Receivable and Payable under Integration
Billing in Contract Accounts Receivable and Payable Basic Data Scheduling as follows:
1. In the activity Define Selection Characteristic of Scheduling, you have the option of
entering an indicator for finer control of scheduling. Using the selection characteristic, you
can influence the determination of the target date of billing and invoicing at the level of
the contract account.
2. If you want to use billing cycles in scheduling, in the activity Define Billing Cycle, define a
billing cycle and configure the controls for determining the periodicity and for determining
the billing period. You also specify here if these properties can be overwritten in the
contract account.
3. In the activity Enter Rules for Determining the Billing Date, you define the rules for
determining the target date for billing. In addition, you specify if the target date of billing is
synchronized with the billing cycle (in relation to either the beginning or the end of the
billing period).
4. In the activity Assign Rules for Determining the Billing Date, you define the derivation of
the rule for determining the billing date.

Example
Your customers receive an invoice for each contract (provider contract). The date of the invoice
creation is determined from the date the contract was signed. If the customer has several
contracts, then payment is to be made using a common contract account. To ensure that all
billing-relevant data is in the system at the time of billing, you define a waiting period for billing of
2 days after the end of the billing period. Invoicing is to take place directly after billing.
1. You define the billing cycle ZMC1, which uses the validity start of the provider contract
item as the day of the period end. As the frequency, you use M1 (monthly).
2. You assign billing cycle ZMC1 to the items of the provider contract.
3. You define the rule Z001 for determining the billing date. The date of creation of the
billable item should serve as the baseline date for the calculation.
4. In addition, the rule should be cycle-based in regard to the period end. In the calculation
rules, you enter 2 additional days.

(C) SAP AG

43

A customer signed a contract on November 5. For a billable item created on December 17, the
following dates result based on the system configuration:
Baseline date for determining the target date of billing is December 17.
Billing is cycle-based in relation to the period end. The system determines the end of the
billing period in which December 17 lies. The period determined in this way extends from
December 6 to January 5 of the following year. (The period end corresponds to the date
the contract was signed.)
The system adjusts the baseline date for determining the target date to the period end
that was determined. That means that the baseline date is January 5.
The calculation rule Z001 adds two additional days to the baseline date.
The target date for billing the billable items from December 17 is therefore January 7 of the
following year.

Parallel Processing Criteria in Billing

Features
For mass processing of billable items in processes that run in parallel, the system divides the
data into multiple billing packages. This ensures that each parallel process can exclusively
process one or more billing packages.
The system already divides billable items into individual billing packages when the billable item is
created, by deriving an attribute (KEYPP) in the billable item for the billing package.
For parallel billing, the system divides the total of the billable items into a maximum of 1000 billing
packages. In the standard system, the system assigns all billable items of a business partner to a
single billing package. The items are thereby processed by a single process. By specifying
additional parallel processing criteria, you can distribute these items to several billing packages.
You can thereby benefit from parallel billing of business partners with a high volume of billable
items in multiple processes running in parallel. You can use any fields of the billable item as
parallel processing criteria.
Recommendation
Use only those criteria as parallel processing criteria that, owing to their business significance,
should lead to the processing of billable items in different billing documents. Examples of these
criteria include the contract account, contract, currency and billing period.
End of the recommendation.
Example
If you use the contract account as a parallel processing criterion, then different billing processes
running in parallel process the different contract accounts of a business partner.
If you use the source transaction as a parallel processing criterion, then different billing processes
running in parallel process billable items with different source transactions.
End of the example.

(C) SAP AG

44

Note
If you use parallel processing criteria, the system normally creates at least one billing document
for a contract account for each billing package. You can merge these billing documents into a
common invoicing document in invoicing. You also have the option of limiting the maximum
number of billing packages for each contract account, which thereby limits the number of billing
documents.
End of the note.

Activities
You create parallel processing criteria in Customizing for Contract Accounts Receivable and
Payable under Integration Billing in Contract Accounts Receivable and Payable Billing
Processes Define Parallelization Criteria .

Generierung von Pflegedialogen fr Verbrauchspositionen

Um Verbrauchspositionen manuell erfassen zu knnen, mssen Sie im Customizing aus
aktivierten Klassen von Verbrauchspositionen Pflegedialoge generieren.

Voraussetzungen
Sie haben im Customizing Klassen fr Verbrauchspositionen konfiguriert und die Konfiguration
aktiviert.

Aktivitten
Pflegedialoge fr Verbrauchspositionen generieren Sie im Customizing des
Vertragskontokorrents unter Integration Abrechnung im Vertragskontokorrent Klassen fr
Verbrauchspositionen Pflegedialoge fr Klassen von Verbrauchspositionen generieren .
Um einen Pflegedialog zu generieren, markieren Sie die gewnschte Klasse in der Liste und

whlen Sie

(C) SAP AG

Generieren (Generierung

45

durchfhren) . Die Generierung erfolgt aufgrund der generierten Version der Schnittstelle und der
Datenablage der Klasse.
Hinweis
Bei der Generierung lscht das System bereits vorhandene generierte Objekte der Pflegedialoge.
Ende des Hinweises.
Ferner stehen Ihnen in der Drucktastenleiste die folgenden Funktionen zur Verfgung:
Mit der Drucktaste

(
Generierung prfen) prfen Sie die generierten Pflegedialoge der ausgewhlten Klasse.
Beim Aufruf der Transaktion vergleicht das System die Felder der generierten
Datenablage mit den generierten Pflegedialogen. Das System prft, ob
Schnittstellenkomponenten und Kundenfelder ergnzt oder gendert wurden.

(C) SAP AG

46

Mit der Drucktaste

vorhandene Objekte lschen.

Lschen (Generierte Objekte lschen) knnen Sie

Mit der
Drucktaste

Objekte (Generierte Objekte anzeigen) knnen Sie die generierten Objekte anzeigen. In
der Objektliste knnen Sie zu den Objekten navigieren.

Configuration of Billable Item Classes

By configuring billable item classes you specify the technical properties that suit your needs for
billable items. The settings determine the structures of the database tables as well as the
interfaces for the data transfer.

(C) SAP AG

47

Prerequisites
To be able to select customer fields in a class, you must fill the corresponding Customizing
includes (see Customer Fields in Billable Item Classes).
For more information, see also Integration of SAP Convergent Charging and Integration of SAP
Customer Relationship Management.

Process
You create and configure new classes in Customizing for Contract Accounts Receivable and
Payable under Integration Billing in Contract Accounts Receivable and Payable Billable
Item Classes Maintain Billable Item Classes .
Once you have completely defined a billable item class and set the configuration and activation
status, you generate the interfaces (see Interface Generation).
You conduct the configuration of billable item classes in the following steps:
1. Selection of interface components
SAP supplies interface components that you can activate for each class.
2. Selection of customer fields
You can include customer-defined fields in the interface and data store.
3. Administration of DB table sets
If you choose the pushbutton
DB Table Set (Maintain DB Table Set), you can access
the configuration of the tables for billed items and the tables for simulated billed items.
Here, you can define the desired number of table sets. Afterwards you can perform the
Customizing activity Make Settings for Data Storage to determine how you would like to
use the table sets.
4. Administering indexes for database tables
To optimize performance, you can choose the pushbutton
Indexes (Maintain Indexes)
to create your own indexes in database tables. The active customer fields and the fields
of the active interface components are available for use in the index fields.
5. Selection of fields for optimizing data retention
The optimization is only available if the usage of subitems by means of the selection of
the corresponding interface components is active (see Subitems).
6. Changing the configuration status
After creation, the class has the configuration status In Processing. You can change a
class with this status as you like. If you activate the class, the system does not include it
in a transport order. The system only includes the class in a transport order when you
have set the status to Transportable. You can also make as many changes as you like in
this status.
When you set the configuration status to Released as Productive, you can only make the
following compatible changes:
o

(C) SAP AG

Selecting additional interface components not yet active

48

Selecting additional customer fields not yet active

Adding table sets

Creating, displaying, and changing indexes

Note
Please remember that this can result in conversions of table content already
present.
End of the note.

7. Activating the configuration

You can only activate a class if it is thoroughly consistent. In particular, this means that it
must be without errors.
At a given time, there can only ever be one active version of a billable item class. If you
make changes to the active version of a class without activating it, the system creates a
working version in addition to the active version. When you activate the configuration, the
working version becomes the active version. You can also return to the last active version
of the configuration from the working version.
When you activate the configuration, the system checks the completeness of the work
structures for billable items used in the processing programs. The system can then
automatically add fields of the class that are are not already contained in the work
structures. These fields are added in the related Customizing includes of the work
structures.
As soon as a class with the Productive configuration status is present, the system writes
a history of the active versions. This allows you to reproduce when changes were made
to the configuration.
If you activate a class with the configuration status Transportable and Released as
Productive, the system creates a transport order for the class with which you can
transport the active status of the class to follow-up systems.

System Landscape
Structure
The configuration and generation of billable item classes are orientated towards a three-level
system landscape as can be seen in the following figure.

(C) SAP AG

49

Customizing
System

Transport

Test
System

Transport

Production
System

System Landscape
In Customizing, you configure the billable item classes (see Configuration of Billable Item
Classes). The system saves the configuration as Customizing data. You can transport this
Customizing data into a test system as soon as you change the status of the configuration to
Transportable. The transport connection is integrated as standard in the transaction for the
configuration of billable item classes. The system ensures that only complete and consistent
configurations are transported. The transport object FKKBIXBIT_CONF is used for the transport.
Taking the transported Customizing data as a basis, you can generate the corresponding
workbench objects (such as RFC function modules for the data transfer, database tables for data
storage) for the classes in the test system. Then you can test the classes with test data.
Once you have successfully concluded your tests, you can transport the Customizing data into
the production system to generate objects for the classes there.
Caution
You can change the configuration of billable item classes. This gives you the possibility of
regenerating workbench objects for classes in the test and production system.
However, as soon as you wish to use a class in the production system for production data, you
should set the configuration status for the class to Released as Productive in Customizing. This
status only permits compatible changes with regard to the configuration of the class in
Customizing. This means that you may insert a new field in the table for example, however, you
may not delete a field. The regeneration in the production system ensures that no production data
is lost.
End of the caution.

(C) SAP AG

50

Interfaces for Billable Item Classes

Features
Billing in Contract Accounts Receivable and Payable offers the following Application
Programming Interfaces (APIs) as RFC function modules for billable item classes.
FKK_BIX_BITCAT_LIST_GET_API
The API returns a list of the productive usable billable item classes.
FKK_BIX_BITCAT_LIST_GET_SAPCC
The API returns a list of billable item classes that are released as productive and that you
have created for SAP Convergent Charging.
FKK_BIX_BITCAT_STRUC_GET_API
The API returns the technical definitions for a billable item class, such as the field names
in the interface for the class.
The system generates a separate RFC function module for every billable item class. With this
RFC function module you transfer billable items for a class to Billing in Contract Accounts
Receivable and Payable. The naming convention of the function module is
/1FE/xxxx_BIT_CREATE_API, where xxxx stands for the four-character class name.
The parameters of the generated RFC function module are adjusted to the structure of the billable
item class. If, in addition to the main items, you use other record types (payment data or tax
data), the system transfers this data to the RFC function module in the following, separate table
parameters:
IT_BIT_IT (main items)
IT_BIT_PY (payment data)
IT_BIT_TX (tax data)
The following table parameters return the result of the transfer of billable items for each record
type xx (see also Transfer Rules and Program Enhancements):
ET_BIT_xx_ERROR: Items with errors
ET_BIT0_xx: Items added as raw data
ET_BIT2_xx: Items added as billable
In addition the system returns the respective source transactions in the corresponding
parameters.
As standard, a COMMIT WORK (or ROLLBACK WORK in the case of an error) occurs every time
the RFC function module is called. This means that every RFC function module represents a
logical unit of work (LUW) as standard. You can override this in the I_NO_COMMIT_WORK
parameter. Please observe the documentation in the system.

(C) SAP AG

51

If the RFC function module is called, the system writes an application log for the processing of the
transferred billable items. You can display this application log with the transaction SLG1 for the
object FKKBIX and the subobject CREATE.

Customer Fields in Billable Item Classes

Features
You can include customer-specific fields in the interface and data store of billable item classes.

Activities
To be able to use customer fields in the configuration of billable item classes, you must first add
these fields (for each record type) in one of the following Customizing includes.
CI_FKKBIXBIT_IT (data for main items)
CI_FKKBIXBIT_PY (payment data items)
CI_FKKBIXBIT_TX (tax items)
Note
To ensure that customer fields are taken into account during the processing of billable items, the
system checks the completeness of the work structures when the configuration of the billable item
class is activated. The system automatically adds any missing customer fields to these structures.
These fields are added in the related Customizing includes of the work structures.
End of the note.

Interface Generation
From classes of billable items, you generate the interfaces for the transfer of billable items as well
as the data storage for the billable items.

Prerequisites
In the Customizing activity Maintain Billable Item Classes, you have configured classes and
activated their configuration. In order to be able to generate interfaces for a class of billable items,
the configuration of the class must be active.

Features
You generate classes of billable items in Customizing of the Contract Accounts Receivable and
Payable under Integration Billing in Contract Accounts Receivable and Payable Billable
Item Classes Generate Interfaces for Billable Item Classes .
In order to generate the interface and data storage for a class of billable items, you select the
class in the list and choose the pushbutton
Generate (Execute Generation) in the toolbar.
Generation is possible when a corresponding generation status exists.

(C) SAP AG

52

Note
During generation, the system deletes existing generated objects if necessary. That means that
you can lose the data. The system behavior is according to the configuration status of the class:
In Processing
The system deletes existing objects completely and regenerates them. You lose data in
this case.
Transportable
The system deletes existing objects completely and regenerates them. You lose data in
this case.
Released as Productive
If you generate a class for the first time in the Released as Productive status, the system
deletes all existing objects and regenerates them. You lose data in this case.
For all other generations for a class in the Released as Productive status, the system
only regenerates objects that either did not yet exist or that need to be adjusted. All of the
data that existed up to that point remains.
End of the note.
In the context of generation, the following functions are available in the toolbar. In order to use
one of the functions, select a class of billable items and choose the desired pushbutton:
Checking generation
When calling up the transaction, the system checks the entries that were already made in
the configuration, including additions to interface components, customer fields, table sets
and indexes. A detailed comparison based on changes of the generated function
modules only occurs if you explicitly check the generation by choosing the (Check
Generation) pushbutton.
Deleting generated objects
If objects already exist and the configuration status of the interface is not Released as
Productive, you can delete these objects. To do so, choose the (Delete Generated
Objects) pushbutton.
Displaying generated objects
In order to display generated objects and to navigate to the objects, select the pushbutton
Objects (Display Generated Objects).
Displaying the generation history
The generation history provides an overview of the executed generations. You can
display the respective generation log and the generated configuration for a generation.
To do so, choose the pushbutton
History (Display Generation History).
Displaying the generation log

(C) SAP AG

53

The generation log shows the activities that the system executed during the generation.
Call up the log using the pushbutton
Log (Display Generation Log).
Displaying the generated configuration
Using the pushbutton
Configuration (Display Active Configuration), you can display
the configuration of the class that you generated most recently.
Releasing and locking classes for use
You use the release status of the interface of a class to control whether data for this class
can or cannot be transferred. The following statuses are possible:
o
o

__ Not released for use

Released for Productive Use
A class can only contain this status if its configuration has also been released for
productive use.

Released for Test Use

A class can contain this status in the development or test system only if the
status of the configuration is In Processing or Transportable. This gives you the
option of testing a class in advance.

If you execute generation for a class of billable items, the interface is released for the
transfer of billable items by default. If you would like to temporarily lock the transfer of
billable items for a class on a technical basis, choose the pushbutton (Lock Class for
Usage). If you want the class to be available again for data transfer, select the
pushbutton (Release Class for Usage).

Generierung von Pflegedialogen fr abrechenbare

Positionen
Um abrechenbare Positionen manuell erfassen zu knnen, mssen Sie im Customizing aus
aktivierten Klassen abrechenbarer Positionen Pflegedialoge generieren.

Voraussetzungen
Sie haben im Customizing Klassen abrechenbarer Positionen konfiguriert und die Konfiguration
aktiviert.

Aktivitten
Pflegedialoge fr abrechenbare Positionen generieren Sie im Customizing des
Vertragskontokorrents unter Integration Abrechnung im Vertragskontokorrent Klassen
abrechenbarer Positionen Pflegedialoge fr Klassen abrechenbarer Positionen generieren

(C) SAP AG

54

Um einen Pflegedialog zu generieren, markieren Sie die gewnschte Klasse in der Liste und

whlen Sie
Generieren (Generierung durchfhren) . Die Generierung erfolgt aufgrund der
generierten Version der Schnittstelle und der Datenablage der Klasse.
Hinweis
Bei der Generierung lscht das System bereits vorhandene generierte Objekte der Pflegedialoge.
Ende des Hinweises.
Ferner stehen Ihnen in der Drucktastenleiste die folgenden Funktionen zur Verfgung:
Mit der Drucktaste

(
Generierung prfen) prfen Sie die generierten Pflegedialoge der ausgewhlten Klasse.
Beim Aufruf der Transaktion vergleicht das System die Felder der generierten
Datenablage mit den generierten Pflegedialogen. Das System prft, ob
Schnittstellenkomponenten und Kundenfelder ergnzt oder gendert wurden.

(C) SAP AG

55

Mit der Drucktaste

Lschen (Generierte Objekte lschen) knnen Sie vorhandene Objekte lschen.

(C) SAP AG

56

Mit der Drucktaste

Objekte (Generierte
Objekte anzeigen) knnen Sie die generierten Objekte anzeigen. In der Objektliste
knnen Sie zu den Objekten navigieren.

Billable Item Management

Features
The management encompasses the processing steps that billable items run through after their
transfer. The following section gives you an overview of the basic terms and functions of billable
item management.

Processing Rules and Program Enhancements

Upload Rules
You use upload rules to control how the system processes data. The upload rule decides what
the system does with the billable items. The options are:
Adding them directly in the table of billable items
Adding them in the raw data table
Returning them as incorrect
In the first step, the system checks the transferred items to determine whether further processing
is possible. If at least one item has a serious error (for example, unknown source transaction
type) further processing of all items is terminated immediately. The system issues an error
message. If further processing is possible, another check is performed. This check of a billable
item can have the following results:
Contains errors

(C) SAP AG

57

The item contains an error.

Incomplete
The item has no errors, however a correct master data assignment is missing.
Consistent
The item contains no errors and is complete.
Program Enhancements
You can add customer-defined checks and enrichments for various events for each billable item
class. The following table shows which events are supported.
Event Description

Sample function module

05

Enrichment and check of raw data

FKK_SAMPLE_TFK8101EV_05

10

Enrichment and check of the billable items

FKK_SAMPLE_TFK8101EV_10

15

Check when excepting the raw data

FKK_SAMPLE_TFK8101EV_15

17

Check when restoring the raw data

FKK_SAMPLE_TFK8101EV_17

20

Check when excepting billable items

FKK_SAMPLE_TFK8101EV_20

22

Check when restoring billable items

FKK_SAMPLE_TFK8101EV_22

33

Check at reversal of billed items

FKK_SAMPLE_TFK8101EV_35

Integration with SAP NetWeaver BW

For each billable item class you can specify whether it is relevant for the sales statistics. For more
information see Updating Billable Items to SAP NetWeaver BW.

Prerequisites
The billable item class must be present in an active form. For this to be the case, define the class
as an active class in Customizing for Contract Accounts Receivable and Payable under
Integration Billing in Contract Accounts Receivable and Payable Basic Data Activate
Billable Item Classes .

Activities
1. Make the (client-dependent) settings for the billable items classes. To do so, in
Customizing for Contract Accounts Receivable and Payable, choose Integration
Billing in Contract Accounts Receivable and Payable Billable Item Management
Define Processing Rules and Program Enhancements .
2. Specify a transfer rule for the class.
With this setting, you specify whether and how the system adds the items depending on
the check result. For more information, see the documentation for the field Transfer Rule
in Customizing.

(C) SAP AG

58

3. Where necessary, define function modules for customer-specific checks and enrichments
for the various events for each class.

Transferring Raw Data into Billable Status

For the billing in Contract Accounts Receivable and Payable to be able to start processing, the
items delivered must have the status Billable.

Features
The system checks the items delivered. If the result is successful, the system stores the items as
billable items. If the check finds an error, the items remain unchanged in the raw data.
The system checks all the items of a package (BITPACKUUID) in a logical unit. An error in one
item causes the check to terminate for all the other items in the package. The object for parallel
processing for the mass activity is the subarea (KEYPP).
When the data is being transferred from the feeder systems, it is generally saved directly as
billable items in Contract Accounts Receivable and Payable. Then you can bill these. However,
for the following reasons, the system first saves the data as raw data:
In Customizing for the transfer rule, you specified that the items are to be added as raw
data (see Customizing for Contract Accounts Receivable and Payable under Billing in
Contract Accounts Receivable and Payable Billable Item Management Define
Processing Rules and Program Enhancements ).
You have added a corresponding check in events 05 and 10 of the program
enhancements (see Customizing for Contract Accounts Receivable and Payable under
Billing in Contract Accounts Receivable and Payable Billable Item Management
Define Processing Rules and Program Enhancements ).
The system was unable to clearly identify the master data (contract account and business
partner), and for this reason added the item to the raw data.

Activities
1. To transfer raw data to the Billable status, on the SAP Easy Access screen, choose
Billing Processing of Raw Data Transfer from Raw Data to Billable Items .
2. Enter a date and an ID that you can use to identify the run later.
3. Limit your selection accordingly on the General Selections tab page.
4. Schedule the program run. To do so, choose the
Schedule Program Run (F8)
pushbutton in the toolbar. For more information, see Functions for Scheduling Program
Runs.
The system transfers the items matching the selection from the status Raw to the status Billable.

(C) SAP AG

59

Changing of Raw Data and Error Handling

In the monitor for raw data, you can do the following in case of error:
Manually change the contents of individual fields
Use mass change to manually change several field values for several items at the same
time

Prerequisites
In Customizing for Contract Accounts Receivable and Payable under Integration Billing in
Contract Accounts Receivable and Payable Billable Item Management Define Changeable
Fields of Billable Items , you set the fields that are allowed to be changed. In the standard
system, you are not permitted to modify any fields.

Features
If you change values for a raw data item, the system updates the change history. In the change
history, all item changes are listed chronologically.
Using mass change, you can change the fields of any number of items. The system also updates
the change history when mass change is used.

Activities
To change billable items and resolve errors, choose
SAP menu.

Billing

Monitoring

Raw Data

in the

Data Storage
Prerequisites
You have activated billable items for the client in Customizing for Contract Accounts Receivable
and Payable under Integration Billing in Contract Accounts Receivable and Payable Basic
Data Activate Billable Item Classes . In addition you have defined the table set in the
configuration of the class.

Features
The system can store the billed items and simulated billed items separately if you have made the
Customizing settings named.

Activities
1. To configure data storage, in Customizing for Contract Accounts Receivable and Payable
choose Integration Billing in Contract Accounts Receivable and Payable Billable
Item Management Make Settings for Data Storage .
2. Specify data storage for billed items.

(C) SAP AG

60

3. Make an entry for each billable item class.

Note
This is the prerequisite for billing. If there is no entry present for a class, billing cannot
take place.
End of the note.
4. Enter a table set for the class and specify from which date the set is to be used.
Note
When making the configuration, take account of possible restrictions regarding the possibility of
deleting a table set (see Deleting Billed Items).
End of the note.

Displaying Billable Items

You can display billable items regardless of their processing status based on your selection
criteria and analyze them.

Activities
1. On the SAP Easy Access screen, choose

Billing

Display

Billable Items

2. Limit the selection.

You can either select billable items individually and include all processing statuses of
billable items, or you can use the selection variants defined by SAP for the different
processing statuses of billable items.
In addition to the processing status of billable items, you can limit the selection further by
master data, source transactions and other criteria (all parameters of the billable item
classes active in the system).
3. Run the program.
The system displays the billable items that match your selection criteria in the form of an ALV list.
You can use the following functions in the list:
You can display statistics on the number of items found and their processing status.
You can analyze the items belonging to a source transaction.
You can display information such as business partner, contract account, billing
document, and invoicing document for an item.
You can display the reversal request for billable items that are flagged for reversal or are
already reversed.

(C) SAP AG

61

If items were processed in the meantime, you can update the display to reflect the current
status.
For more information, see the program documentation.

Reversing Billable Items

The following business transactions, for example, can make it necessary to reverse billable items
in billing:
In SAP Customer Relationship Management, you take back one-off charges that you
already transferred to SAP Convergent Invoicing.
SAP Convergent Charging performs rerating for transactions, for which there are already
billable items in SAP Convergent Invoicing.

Prerequisites
You made the system settings for the reversal of billable items in Customizing for Contract
Accounts Receivable and Payable under Integration Billing in Contract Accounts Receivable
and Payable Reversal of Billable Items .

Features
In the case of rerating, SAP Convergent Charging determines a new price for already priced
items. It then transfers these, along with new items, to Billing in Contract Accounts Receivable
and Payable. Billing then reverses the billable items that have become invalid due to the rerating.
The system determines the billable items to be reversed using the source transactions in
conjunction with the contract account and contract reference.
The reversal of a one-off charge in CRM leads to a direct reversal of the billable items of the
affected source transaction in billing.
The system stores the reversal query in a reversal request. Depending on your Customizing
settings, the system either processes the reversal request immediately, or you process the
reversal request in a separate step from the SAP Easy Access screen under Billing
Processing of Billable Items Reverse Billable Items . If the system cannot automatically
process all billable items of a reversal request, you have to process the reversal request
separately there also (standard case).
Note
The system reverses items that are ready for billing, and for which a reversal request already
exists, in advance during processing of the reversal request; these items are not billed.
End of the note.
You can monitor reversal requests from the SAP Easy Access screen under
Monitoring Reversal Requests for Billable Items .

Billing

For more information, see the documentation of the programs.

(C) SAP AG

62

Note
It is only possible to reverse all items of a source transaction and contract account together.
End of the note.
Reversal is supported for all statuses of billable items:
Not yet billed items, that is items with status raw (0 ) or billable (2 ) are excluded
by the system; they receive the status raw excepted (1 ) or billable excepted (3
).
Already billed items (with status billed (4 or )) keep their status. To compensate
for it, the system creates offsetting items with reversed positive/negative signs that are
included as a credit for the invoice by means of the next billing.
Items with the status raw excepted (1
status.

) and billable excepted (3

) keep their

Deleting Billed Items

In order to reduce the load on your database, you can delete billed items.

Prerequisites
For you to be able to delete billed items, the following criteria must be met:
All the billed items of a table set are invoiced.
The billed items have reached the residence time that you enter in the selection.
You first specify the residence time globally in Customizing, but you can shorten it in the
transaction for deleting billed items.
You are not currently using the table set for storing billed items.
Note
To be able to delete items billed in simulation (simulation data), the corresponding table set must
not be currently being used to store items billed in simulation.
No other limitations apply for simulation data.
End of the note.
In Customizing for Contract Accounts Receivable and Payable, under Integration Billing in
Contract Accounts Receivable and Payable Billable Item Management Make Settings for
Data Storage , you specify from when the system is to use a table set for the corresponding
classes of billable items (From date). The time at which you make the settings for the data
storage effects the check on the residence time for the billed items. The system uses the date of
the latest entry for a table set to check the residence time. For more information about using table
sets to store billed items, see Data Storage.

(C) SAP AG

63

Make sure that you are not currently using the table sets to be deleted for a billable item class for
storing billed items. If this is the case, in the Customizing activity Make Settings for Data Storage
enter a different table set for storing billed items.

Features
The system stores billed items for each billable item class in a separate table and groups these
into table sets. The system sequentially numbers the table sets that exist for a billable item class.
At runtime, the billing determines the table set to be used for storing billed items.

Activities
To delete the billed items stored in the system, on the SAP Easy Access screen, choose
Invoicing Delete Data Billed Items .
For more information, see the program documentation.

Billing Processes in Contract Accounts Receivable

and Payable
Based on the billing information, Billing in Contract Accounts Receivable and Payable creates
billing documents.

Prerequisites
You activated Invoicing in Contract Accounts Receivable and Payable in Customizing for
Contract Accounts Receivable and Payable under Basic Functions Postings and
Documents Basic Settings Maintain Central Settings for Posting .
You have entered the master data of the business partners and contract accounts to be
billed.
There are billable items.

Process
The billing process comprises the processes in Billing in Contract Accounts Receivable and
Payable that group billable items into billing documents. They represent the business transaction
that creates billing documents, which are then processed further in invoicing. Billing processes
perform the following tasks:
The system selects and groups billable items together in a billing document.
The system creates billing documents that form the basis for invoicing.
You can process the dataset in parallel. Billing processes use the functions of mass processing in
Contract Accounts Receivable and Payable to apportion the dataset and distribute processing
over several processes in order to reduce the runtime.

(C) SAP AG

64

ERP
Master Data Administration
Contract
Account

CRM

Billing in Contract Accounts Receivable and Payable

Invoicing
Order

Invoicing
Processes

Inbound
Interface

Selection
Mapping

ALE

External
Document Data

BAPI

External
Billing System

Business
Partner

Billable Item

Grouping

Billing
Document

The Billing Process in Contract Accounts Receivable and Payable

Flow of Billing Processes

Billing takes place in individual process steps.

Process
The process steps are listed below:
Data selection:
During data selection, the system selects the billable items for the billing process.
You define the selection criteria for the data selection in selection variants for the billing
process.
Creation of billing units
The system groups together the selected billable items into billing units for each contract
account. Multiple billing units can be created for each contract account.
Billing in Contract Accounts Receivable and Payable creates one billing document for
each billing unit.
You define the criteria that are used to create the billing units in grouping variants for the
billing process.

(C) SAP AG

65

Aggregation of billable items

The system includes the selected billable items of a billing unit in the billing document.
More exactly, the billable items are summarized in billing document items. The individual
items that belong to this summarization are linked with the billing document item.
Update
The system writes the billing document created for the billing unit and the individual billed
items to the database, and at the same time deletes the processed billable items.

Data Selection

Billable Items
Creation of Billing Units

Billed Items

Aggregation
of Billable Items

Update

Billing Document

Invoicing Order

Flow of Billing Processes

Flow Control for Billing

The flow control for billing assists you in adapting the internal process flows of billing to your
requirements.

Features
The process flow of billing in Contract Accounts Receivable and payable is dependent on the
following parameters:
Billing process
Subprocess

(C) SAP AG

66

Billing type
Based on this multi-level control, you have a great deal of flexibility in adapting billing in Contract
Accounts Receivable and Payable to meet your requirements. The system determines these
parameters each time a contract account is processed as follows:
When starting billing in Contract Accounts Receivable and Payable, the user enters the
billing process explicitly. The billing process is made up of one or more subprocesses.
The main task of the subprocesses is to specify which billable items are processed. The
selection variant and grouping variant are entered in the subprocess.
Exactly one billing type is assigned to each subprocess. The billing type determines the
document type and the source document type of the billing document.

Data Selection
Features
During the data selection process step, the system selects the billable items for the billing
process.

Activities
You specify the selection rules in Customizing using the selection variant for the configuration of
a subprocess for a billing process (see Integration Billing in Contract Accounts Receivable
and Payable Billing Processes Define Billing Processes ).

Selection of Billable Items

The selection variant specifies the classes of billable items that the system is to select and
process in the billing process.

Activities
1. You define selection variants in Customizing for Contract Accounts Receivable and
Payable under Integration Billing in Contract Accounts Receivable and Payable
Billing Processes Define Selection Variants as follows:
You can further refine the selection by specifying per class the type and source
transaction type of the billable items. In the process, you can specify individual values of
these attributes that you would like to include or exclude from the selection. You can
exclude values by setting the Exclude Value from the Selection indicator.
The configuration also supports the specification of combinations of values of the named
attributes.
2. Enter the selection variant during the configuration of the desired billing process in
Customizing of the Contract Accounts Receivable and Payable under Integration
Billing in Contract Accounts Receivable and Payable Billing Processes Define
Billing Processes on the level of the subprocess.

(C) SAP AG

67

Note
Please note that you can only use a selection variant to select items whose class has been
explicitly defined in the variant. Hence, at least one class of billable items must be assigned to a
selection variant.
End of the note.
Example
Example 1
The variant is to select all billable items of the classes CAT1 and CAT2.
Solution
In the selection variant,define both classes with the selection sequence number 0000. No further
specifications are required.
End of the example.
Example
Example 2
The goal is the same as in example 1, but the variant in class CAT1 is to select the types of
billable items TEL1 and TEL2.
Solution
Proceed as described in example 1 and define the types of billable items TEL1 and TEL2 in
addition to the class CAT1.
End of the example.
Example
Example 3
The goal is the same as in example 2, but the variant in class CAT1 is not to process the source
transaction type BTA1.
Solution
Proceed as in example 2, but define the source transaction type BTA1 in addition to the class
CAT1 and set the Exclude Value from the Selection indicator for the source transaction type
BTA1.
End of the example.
Example
Example 4
The goal is the same as in example 3, but the variant is not to process source transaction type
BTA1 only in conjunction with the type of billable item TEL2.

(C) SAP AG

68

Solution
1. Proceed as in example 3. However, split the entry for class CAT1 into two entries; one
with the selection sequence number 0001 and the type of billable items TEL1 and one
with the selection sequence number 0002 and the type of billable items TEL2.
2. In addition, assign the source transaction type BTA1 to class CAT1 with the selection
sequence number 0001 and set the Exclude Value from the Selection indicator for source
transaction type BTA1.
End of the example.

Controlling the Selection

At event 8112, you can change the result of a selection by the selection variant.

Features
Event 8112 (BIX: Filter and Check Selection of Billable Items) is processed at the start of billing.
The billable items are already selected at this event in accordance with the selection control of
the billing process. You can check the scope of the selection and reduce it as necessary in the
function module processed at event 8112.
Note
You may only remove complete (processing) packages of billable items from the hit list (see
Billable Item Packages).
End of the note.

Creation of Billing Units

If the system processes more than one billable item when billing a contract account, it is often
necessary not to process these billable items in one common billing document. Instead, they are
to be grouped according to criteria such as common currency or common billing period and a
separate billing document is to be created for is group. Billing in Contract Accounts Receivable
and Payable decides on this issue by creating billing units.
A billing unit groups all billable items together that are processed together in a billing run and for
which the system creates a common billing document.
The creation of billing items can be performed automatically using the rules stored for grouping
control for the billing process. You can also manually control the creation of billing units in the
billing dialog processing.

Process
The automatic creation of billing items is performed in the following steps:
Step 1

(C) SAP AG

69

The system groups all selected billable items together which share the following properties:
Contract account
Business partner
Subprocess
The system does not add billable items to the billing unit that do not correspond in one of these
fields.
Step 2
The system determines the grouping variant. You determine which grouping variant is to be used
depending on the billing process, subprocess and (optionally) invoicing process in Customizing
for Contract Accounts Receivable and Payable in the activity Define Billing Processes. If no
grouping variant can be determined for the billing process, the system processes all billable items
selected for the billing process and contract account in a common billing document. If the system
can determine a grouping variant with rules, these are applied and may further divide the billing
units formed in the first step. For more information on how you can use these rules, see the
description and examples for configuring grouping variants under Aggregation of Billable Items.
Step 3
Billing runs through event 8114. Here, you can make further divisions of the billing units or group
them together using customer-specific implementations.
Step 4
If you execute billing in dialog and use the expert mode there, the system offers the billing
documents created up to that point for selection in a dialog box. You can change the assignment
of billable items to billing units manually there.
You can access billing in dialog on the SAP Easy Access screen under Billing Billing in
Expert
Dialog Create Billing Document . To switch to expert mode, choose the pushbutton
Mode (Billing Process in Expert Mode) in the toolbar.
Note
You can test the system settings of the grouping variants and the implementation of event 8114 in
the expert mode of Billing in Contract Accounts Receivable and Payable.
End of the note.

Aggregation of Billable Items

Grouping variants are used to aggregate billable items.

Features
A grouping variant is used for the following:
To automatically group billable items into billing units

(C) SAP AG

70

To specify the level of aggregation of billable items in the items of the billing document
The billing program internally creates a raw billing item for each billable item. The structure of a
raw billing item (FKKBIX_BILLITEM_IT) consists of the original fields of the billable items and the
fields of the billing document items. The rules defined using grouping variants relate to the fields
of this raw billing item.
Note
The system aggregates billable items in separate billing document items, if one of the following
characteristics is different for the item:
Subprocess
Billable item class
Billable item type
You can control the degree of aggregation at the level of these characteristics, for example in
order to aggregate billable items for each billable item type.
The system processes billlable items that have different subprocesses in separate billing
documents.
End of the note.

Activities
You define grouping variants in Customizing for Contract Accounts Receivable and Payable
under Integration Billing in Contract Accounts Receivable and Payable Billing Processes
Define Grouping Variants as follows:
1. In the subdialog Maintain Grouping Characteristics, you first specify the fields you want to
use in the rules.
As grouping fields, you can use all fields of the raw billing item (structure
FKKBIX_BILLITEM_IT). If you think that an important field of the billable item for
grouping is missing in the raw billing item, you can add it to the raw billing item using the
Customizing include CI_FKKBIX_BILLITEM_IT.
Example
You want to process billable items with different currencies separately for each currency
key. You define a grouping characteristic that has the same name as the field Currency
of the Billable Item (BIT_CURR) of the raw billing item.
End of the example.
In addition to the grouping characteristics with a direct relationship to the fields of the
structure of the raw billing item, you can also define characteristics with a value you
derive in your own function module. Use this kind of characteristic if it is not possible to
get the value for the grouping directly from the fields of the raw billing item.
Example

(C) SAP AG

71

You want to process billable items that belong to different periods in separate billing
documents, but you do not have a suitable field for this in the billable item. You define the
PERIODE field and assign a function module to this field. The module derives the value
for this field from the fields Start and End of Period of the billable item (fields
BITDATE_FROM and BITDATE_TO). These fields consist of the month and year. You can
then use this period in the rules you create.
End of the example.
2. In the next step, you define your grouping variants in the subdialog Grouping Variant.
This means that you assign a key and enter a short text.
3. In the next subdialog Assign Grouping Characteristics, you enter all grouping
characteristics that you want to use in this grouping variant. For each grouping
characteristic, you have to enter the use for the characteristic values.
For more information about the meaning of these usage rules, see the examples that
follow.
4. If necessary, in the last subdialog Assign Alternative Grouping Values, you can enter
alternative characteristic values and their alternative use.

Example 1
Requirement
You would like to to group billable items in an invoice only if they correspond in terms of currency
and source transaction type.
Configuration of the grouping variants
In the subdialog Maintain Grouping Characteristics, you select the following fields:
Grouping characteristic

Name

Function module

BIT_CURR

Currency

SRCTATYPE

Source transaction type

In the Assign Grouping Characteristics subdialog, you store the following entries:
Grouping characteristic

Rank

Use

BIT_CURR

Use original field value

SRCTATYPE

Use original field value

In the subdialog Assign Alternative Grouping Values, you do not make any settings.
Billing
You bill a contract account for which five billable items exist with the following properties:

(C) SAP AG

72

BITREF

BIT_CURR

SRCTATYPE

USD

WEB1

USD

WEB1

USD

WEB2

EUR

TOLL

EUR

TOLL

In the process, the system forms the following billing units:

Billing unit number

BITREF

BIT_CURR

SRCTATYPE

USD

WEB 1

USD

WEB 1

USD

WEB 2

EUR

TOLL

EUR

TOLL

Reason
With this grouping variant, the system groups billable items into a billing unit only if they have the
same currency and the same source transaction type. In this example, that is only the case for
billable items with reference 1 and 2 or 4 and 5.

Example 2
Requirement
You would like to to group billable items in a billing document only if they correspond in terms of
the currency and the source transaction type.
Exception
The system is to process items with the source transaction type WEB1 with items with source
transaction type WEB2 in one billing document.
Configuration of the Grouping Variants
You configure the grouping variant as in example 1. In addition, in the subdialog Assign
Alternative Grouping Values for the grouping characteristic Source Transaction Type you make
the following entry:

(C) SAP AG

73

Characteristic
Value

Alternative Use

Alternative
Value

WEB 2

Characteristic value corresponds with alt. characteristic

value

WEB 1

Billing
If you bill the same billable items as in Example 1, the system forms the following billing units:
Billing Unit Number

BITREF

BIT_CURR

SRCTATYPE

USD

WEB1

USD

WEB1

USD

WEB2

EUR

TOLL

EUR

TOLL

Reason
With this grouping variant, the system groups items 1, 2 and 3 in one billing unit, as the source
transaction type WEB2 is replaced with WEB1 for item 3. However, this only applies for the
formation of the billing units and not for the subsequent processing of item 3.

Example 3
Requirement
You would like to to group billable items in a billing document only if they correspond in terms of
the currency. The source transaction type is not relevant here.
Exception
The system should not group items with source transaction type TOLL together with items with
other source transaction types.
Configuration of the Grouping Variants
In the subdialog Assign Grouping Characteristics you store the following entries:
Grouping Characteristic

Rating

Use

BIT_CURR

Use original field value

SRCTATYPE

Use initial value (SPACE)

(C) SAP AG

74

In the subdialog Assign Alternative Grouping Values you define the following entry for the
grouping characteristic Source Transaction Type:
Characteristic
Value

Alternative Use

Alternative
Value

TOLL

Characteristic value corresponds with alt. characteristic

value

TOLL

Billing
If you bill the same items as in Example 1, the system forms the following billing units:
Billing Unit Number

BITREF

BIT_CURR

SRCTATYPE

USD

WEB1

USD

WEB1

USD

WEB2

EUR

TOLL

EUR

TOLL

Reason
With items 1, 2 and 3 the system sets the source transaction type for the grouping to the initial
value (SPACE). In items 4 and 5, the system uses the value TOLL for the source transaction
type.

Example 4
Requirement
You would like to to group billable items in a billing document only if they correspond in terms of
the currency and source transaction type.
Exception
The system should group items that belong to product 997 irrespective of the currency and
source transaction type.
Configuration of the grouping variants
In addition to currency and source transaction type, you enter the Product field in the Maintain
Grouping Characteristics subdialog and store a function module that provides the field with a
value:
Grouping characteristic

Name

Function module

BIT_CURR

Currency

(C) SAP AG

75

SRCTATYPE

Source transaction type

PRODUCT

Product

Z_CUSTOMER_MODULE

In the Assign Grouping Characteristics subdialog, you store the following entries:
Grouping characteristic

Rank

Use

BIT_CURR

Use original field value

SRCTATYPE

Use original field value

PRODUCT

Use initial value (SPACE)

In the Assign Alternative Grouping Values subdialog, you define the following entry for the
grouping characteristic Product:
Characteristic value

Alternative use

Alternative value

997

You can assign 0 to any groups.

Billing
You bill a contract account for which five billable items exist with the following properties:
BITREF

BIT_CURR

SRCTATYPE

PRODUCT

USD

WEB1

997

USD

WEB1

997

USD

WEB2

997

EUR

TOLL

100

EUR

TOLL

200

The system forms the following billing units:

Billing unit number

BITREF

BIT_CURR

SRCTATYPE

PRODUCT

USD

WEB1

997

USD

WEB1

997

USD

WEB2

997

EUR

TOLL

100

EUR

TOLL

200

Reason

(C) SAP AG

76

Items 4 and 5 differ only in terms of the product. However, the system replaces the values 100
and 200 with the initial value SPACE for the product. Both items are therefore included in one
billing unit. For items 1, 2 and 3, the rule "0 can be assigned to any billing unit" is used due to
product 997. This rule overrides the different values for the currency and source transaction type.
Hence, the system also includes items 1, 2 and 3 in the existing billing unit.

Example 5
Requirement
You would like to to group billable items in an invoice only if they correspond in terms of the
currency and source transaction type.
Exception
The system should group items that belong to product 997 with every other item in a billing
document, irrespective of the source transaction type. However, it is necessary to take into
account the currency for items with product 997.
Maintaining grouping variants
In the subdialog Assign Grouping Characteristic, you store the following entries:
Grouping characteristic

Rank

Use

BIT_CURR

Use original field value

SRCTATYPE

Use original field value

PRODUCT

Use initial value (SPACE)

Note
Note the different values here in the Rank column.
End of the note.
In the subdialog Assign Alternative Grouping Values, you define the following entry for the
grouping characteristic Product:
Characteristic value

Alternative use

Alternative value

997

1 as 0, if all characteristics of higher rank match.

Billing
If you bill the same items as in Example 4, the system forms the following billing units:
Billing unit number

BITREF

BIT_CURR

SRCTATYPE

PRODUCT

USD

WEB1

997

(C) SAP AG

77

USD

WEB1

997

USD

WEB2

997

EUR

TOLL

100

EUR

TOLL

200

Reason
Product 997 overrides the different source transaction types for items 1, 2 and 3. However, the
grouping characteristic currency has a higher rank (rank 0 is higher than rank 1). Hence, different
currencies are taken into account and have the effect that the system forms two billing units.

Example 6
Requirement
You would like to to group billable items in a billing document only if they show the same currency
and the same source transaction type. Items that were already billed and whose billing was
reversed should also be grouped as they were in the original (reversed) billing.
Maintaining grouping variants
In addition to the currency and source transaction type, you store the field Document Number
(BILLDOCNO_OLD) of the last (reversed) billing of the billable item in the Maintain Grouping
Characteristic subdialog.
Grouping characteristic

Name

BIT_CURR

Currency

SRCTATYPE

Source transaction type

BILLDOCNO_OLD

Document number of the last billing

In the subdialog Assign Grouping Characteristic, you store the following entries:
Grouping characteristic

Rank

Use

BIT_CURR

Use original field value

SRCTATYPE

Use original field value

BILLDOCNO_OLD

Use original field value

In the subdialog Assign Alternative Grouping Values, you do not store any entries.
Billing
You bill a contract account for which five billable items exist with the following properties:

(C) SAP AG

78

BITREF

BIT_CURR

SRCTATYPE

BILLDOCNO_OLD

USD

WEB1

4711

USD

WEB1

4711

USD

WEB1

EUR

TOLL

EUR

TOLL

The system forms the following billing units:

Billing unit number

BITREF

BIT_CURR

SRCTATYPE

BILLDOCNO_OLD

USD

WEB1

4711

USD

WEB1

4711

USD

WEB1

EUR

TOLL

EUR

TOLL

Reason
Since items 1 and 2 were already billed together previously in a reversed billing document, the
system now regards them as together again.

Billing Document
Billing in Contract Accounts Receivable and Payable uses billing documents of origin process
0007.
Instead, you can also transfer billing documents from an external system (see Transfer of Billing
Documents in the documentation for Invoicing in Contract Accounts Receivable and Payable).

Structure
The billing document is comprised of the following parts:
Billing document header
Billing document items
Reversal data for the billing document
Optional parts are:

(C) SAP AG

79

Payment data items

Source items
Additional items

Source Item

Additional Item

S_Include Industry

S_Include Industry

C_Include

C_Include
*

*
1..*

1
*

Billing Document
Item

S_Include Industry

Billing Document
Header

0..1

Reversal Data

S_Include Industry

C_Include
1..*

C_Include
1..*

Payment Data Item

Tax Item

S_Include Industry

S_Include Industry

C_Include

C_Include

Structure of the Billing Document

DDIC Structures and Layer Model

For billing documents, in terms of the ABAP Dictionary (DDIC), a distinction is made between the
following layers:
Database layer
Logical layer
Display layer
In the database layer, the system saves billing documents in the seven transparent tables named
in the previous sections. The database tables are only used in the update or in access modules.
In the billing program, the billing documents are maintained in logical tables. Additional display
structures are available for the display functions.
The following table provides an overview of the DDIC structures of the individual layers for the
individual components of the billing document:

(C) SAP AG

80

Database Layer

Logical View

Display View

Header

DFKKINVBILL_H

FKKINVBILL_H

FKKINVBILL_H_DISP

Items

DFKKINVBILL_I

FKKINVBILL_I

FKKINVBILL_I_DISP

Tax items

DFKKINVBILL_T

FKKINVBILL_T

FKKINVBILL_T_DISP

Payment data items

DFKKINVBILL_PY

FKKINVBILL_PY

FKKINVBILL_PY_DISP

Additional items

DFKKINVBILL_A

FKKINVBILL_A

FKKINVBILL_A_DISP

Source items

DFKKINVBILL_S

FKKINVBILL_S

FKKINVBILL_S_DISP

Reversal data

DFKKINVBILL_R

You can read a billing document from the database with the static method SELECT_SINGLE of
class CL_FKKINV_BILL_DOC. The method reads a billing document from the database and
converts it into the structures of the logical layer.
The structures of the display layer are almost identical to those of the logical layer. They contain
an additional customer include with which you can add additional fields for the display.
Note
You can enhance the display structure of the invoicing document item FKKINVBILL_I_DISP with
additional display fields using the include CI_FKKINVBILL_I_DISP. This enhancement does not
affect the database layer or the logical layer. You must fill the fields of the customer include in an
implementation of event 2678.
End of the note.

Billing Document Header

The billing document header contains information that applies for all document items of a billing
document.

Structure
It contains, but is not limited to, the following general data:
The key of the contract account and business partner
The billing process and billing type, along with other data needed for creating the
document, such as the creation date
Posting parameters
Indicators or data that reflect the processing status, such as simulated item, number of
the reversal document

(C) SAP AG

81

The system stores this data in the transparent table DFKKINVBILL_H under the number of the
billing document.

Source Item

Additional Item

DFKKINVBILL_S
MANDT
BILLDOCNO
BILLDOCSRCITEM

DFKKINVBILL_A
MANDT
BILLDOCNO
BILLDOCADDITEM

1..*

1
*

Billing Document
Item

DFKKINVBILL_I
MANDT
BILLDOCNO
BILLDOCITEM

1..*

Billing Document
Header

0..1

DFKKINVBILL_H
MANDT
BILLDOCNO

Reversal Data
DFKKINVDOC_R
MANDT
BILLDOCNO

1..*

Payment Data Item

Tax Item

DFKKINVDOC_PY
MANDT
BILLDOCNO
BILLDOCPAYITEM

DFKKINVDOC_T
MANDT
BILLDOCNO
BILLDOCTAXITEM

Billing Document: Database View

Billing Document Items

Each billing document contains one or more billing document items.

Structure
The billing document item is comprised of the following fields:
Type of billing document item (field ITEMTYPE)
Account assignment information (fields BUKRS, GSBER, SEGMENT, HVORG, and
TVORG)
Tax information (type of tax determination, fields MWSKZ and ERMWSKZ; see External
Tax Calculation)
Various indicators, such as relevant for posting, relevant for printing, simulated
Method used for creating billing document items (field ITEM_CRMET)
Quantities and amounts

(C) SAP AG

82

Fields for linking billing document items with other parts of the billing document:
o

Grouping of tax items (TAX_GROUP)

Grouping of payment data (PY_GROUP)

Grouping of additional items (ADD_GROUP)

Grouping of source items (SRC_GROUP)

The system stores this data in the transparent table DFKKINVBILL_H under the number of the
billing document and the sequential number of the document item.
Also see the documentation for the fields of the structure FKKINVBILL_I.

Reversal Data
The system stores reversal data and adjustment data for every billing document in a separate,
transparent table (DFKKINVBILL_R).

Structure
The data part contains the number of the reversal document or adjustment document. The
reversal reason as well as date and time of the reversal are also stored.

Tax Items
Tax items are optional. The system fills the tax items if the tax calculation has already been
carried out in the external system (tax calculation type External Tax Calculation (Other Tax) (02)
or External Tax Calculation with Internal Handling (03)). The system generates tax items for the
billing document based on the respective record type of the billable item.

Structure
The required grouping field TAX_GROUP links the billing document tax item with the billing
document items. The grouping allows an N:M link. In other words, one or more tax items can be
linked with one or more items.

Payment Data Items

Payment data items are optional. The system fills the payment data items when payment data
items from an external system are to be transferred. The payment data items define the following:
Payment method (automatic debit, credit card, alternative payer)
Later payment amount

(C) SAP AG

83

Priorities of the payment types (such as preference for already authorized credit card
amounts for payment over amounts that have not yet been authorized)
The system generates payment data items for the billing document based on the respective
record type of the billable item.

Structure
The required grouping field PY_GROUP links the payment data item with the billing document
items. The grouping allows an N:M link. In other words, one or more payment data items can be
linked with one or more items.

Source Items
Billing in Contract Accounts Receivable and Payable (origin process 0007) saves the source
transactions processed in the billing process for each billing document in a separate, transparent
table (DFKKINVBILL_S).

Structure
The data part contains, among other things, the following information about the billing document
or reversal billing document:
Grouping field SRC_GROUP
The required grouping field SRC_GROUP links the source items with other parts of the
billing document.
What part the source item is linked with is determined by the record type of the billing
document. The grouping allows an N:M link. In other words, one or more source items
can be linked with one or more items.
The record type of the billing document
The record type of the billing document (field BILLDOCRECTYPE) defines which part of
the billing document the source item refers to.
A source item can refer either to the billing document header or to items in the billing
document (normal billing document items or tax and payment data items).
The creation date of the billing document
The class and record type of the billed item
The technical name of the database table in which the billed item is stored
For more information about determining the database table, see Data Storage.
The grouping key of the billed items of a source item in the billing document
A source item contains one or more billed items.
This data structure enables complete traceability of the aggregation of billed items from the billing
through the billing reversal.

(C) SAP AG

84

Billable Item (Billed Status) /1FE/0SCC24IT00

BILLDOCNO BIT_GRPNO SRCTAID

4711

BIT_AMOUNT

12347

1.-

SUBPROCESS BITTYPE BITDATE BITTIME

1000

2000

01/17/2010 21:42:07

Billable Item (Billed Status) /1FE/0SCC14IT00

BILLDOCNO BIT_GRPNO SRCTAID

SUBPROCESS BITTYPE BITDATE BITTIME

BIT_AMOUNT

4711

12345

3.-

1000

1000

01/14/2010 10:52:07

4711

12345

5.-

1000

1000

01/15/2010 11:15:59

4711

12345

2.-

1000

1000

01/15/2010 19:54:22

4711

12346

10.-

1000

1000

01/13/2010 13:11:34

4711

12346

7.-

1000

1000

01/18/2010 16:37:45

4711

12347

2.-

1000

2000

01/11/2010 07:24:48

Billable Items
Source Item DFKKINVBILL_S
BILLDOCNO SRC_GROUP BIT_GRPNO BITCAT SRCREF SUBPROCESS BITRECTYPE

BIT_DBTAB

4711

0815

SCC1

12345

1000

IT

/1FE/0SCC14IT00

4711

0816

SCC1

12346

1000

IT

/1FE/0SCC14IT00

4711

0817

SCC1

12347

1000

IT

/1FE/0SCC14IT00

4711

0817

SCC2

12347

1000

IT

/1FE/0SCC24IT00

Billing Item DFKKINVBILL_I

BILLDOCNO BILLDOCITEM HVORG AMOUNT
4711

00001

0300

10.-

4711

00002

0010

17.-

4711

00003

0650

3.-

QTY

SRC_GROUP

0815
500.00

0816
0817

Billing Document

Source items

Additional Items
Additional items are additional parts of the billing document.

You can add additional (for example customer-specific) items to a billing document (see
Enhancements of the Billing Document).
If the cardinality of the information does not exactly correspond to the billing document items, you
can store customer-specific information in the billing document additional items or link customerspecific tables and data records with the billing document.
You can fill the additional items when the billing documents are transferred in BAPI
BAPI_ISTBILLDOC_CREATEMULTIPLE (see Transferring Billing Documents in the
documentation for Contract Accounts Receivable and Payable).

Entering the Document Number and Assigning the

Document Type
The billing document number is the key that uniquely identifies a billing document for each client.

(C) SAP AG

85

Features
Billing document numbers are numeric. The system determines document numbers internally.
External number assignment is not supported. Within a number range, the numbering of the
billing documents is sequential and gap-free.
Note
You can use the same document type for all billing documents.
However, it is recommended to at least use different document types for real and simulated billing
documents, and to assign these document types to different number ranges.
For reversal documents it is also recommended to use separate document types and number
ranges.
End of the note.

Activities
To define the number ranges for assigning document numbers to billing documents, in
Customizing for Contract Accounts Receivable and Payable choose Integration Billing in
Contract Accounts Receivable and Payable Billing Processes . Then perform the following
steps:
1. In the activity Maintain Number Ranges for Billing Documents, you initially define the
number ranges for the billing in Contract Accounts Receivable and Payable. To do this,
enter intervals with lower and upper limits for the number range object Billing Document
(FKKINVBILL).
In the number assignment itself, a distinction is made between individual and mass
processing. The namespace for the number ranges for individual processing is purely
numeric. The namespace for the number ranges for mass processing is not numeric.
For the individual processing one single number range is sufficient, while in the mass
processing billing documents can be created in parallel in multiple processes. Therefore,
you define as many number ranges (per document type) as you require in the parallel
billing process.
The document type controls the document number assignment of the billing documents
by assigning one or more number ranges to it. The document type classifies the billing
documents, is determined in the billing process, and is stored in the billing document
header (field DOCTYPE).
2. In the activity Maintain Document Types and Assign Number Ranges you define the
document types for billing documents and assign these in the subdialogs Number
Ranges for Individual Processing and Number Ranges for Mass Processing.
3. In the activity Define Source Document Types for Billing Documents, you define source
document types for the source document type Billing Document (INVBI).
4. Define the determination of the document types for billing documents by assigning
document types. The determination is performed depending on the billing process or
billing type.

(C) SAP AG

86

Enhancements of the Billing Document

You can enhance billing documents in events.

Features
You can enhance billing documents in the following events:
Event Function
8120

For event 8120 you can fill or change customer-defined fields of the billable items of a
billing unit. The event is processed at the start of processing of a billing unit.
The event 8125 is run through for every billing unit after the standard enrichment of the
billing document. The billing document is already completely created at this point except for
the billing document number.

8125
In the function module processed for 8125, you can create additional customer-defined
billing document items. The system automatically flags the created items for further
processing with a corresponding mode of creation.
Event 8135 is processed for every billing unit shortly before the billing document is posted
to the database. The billing document is already completely created at this point except for
the billing document number.
8135
In the function module processed at event 8135, you can fill or change the customerdefined fields of the billing document. In addition, you can also change some standard
fields.
With the function modules called at event 8137, you can trigger additional actions if a
billing document has been created in Contracts Accounts Receivable and Payable. In
8137
addition, you can check the billing document, including the environment, for a last time
before posting.
In the function modules called at event 8139, you can conclude the additional actions that
you initiated in event 8137. The completely created billing document is available for this.
8139

Note
Only enhance the assigned document numbers in the internally noted data that is to be
updated on the database later.
End of the note.

Automatic Billing: Creating Billing Documents

(C) SAP AG

87

In automatic billing, you combine large volumes of billable items in billing documents in a mass
run.

Prerequisites
If you want to process billable items of business partners with large data volumes in multiple
parallel processes, then you specified parallel processing criteria for each subprocess in
Customizing for Contract Accounts Receivable and Payable under Integration Billing in
Contract Accounts Receivable and Payable Billing Processes Define Parallelization Criteria
.

Features
In the standard system, the system divides the total of the billable items into a maximum of 1000
billing packages for parallel billing. In doing so, the system assigns all billable items of a business
partner to one single billing package and processes this package in one process.
If a business partner has a large volume of billable items, long runtimes can result in billing. You
can optimize the runtime for billing for this business partner by using parallel processing criteria. If
you enter additional parallel processing criteria in Customizing, you can distribute the billable
items of a business partner to multiple billing packages. This makes it possible to perform parallel
billing for the business partner in multiple processes running in parallel. This is controlled at the
level of each subprocess of billing.

Activities
1. To create billing documents automatically, on the SAP Easy Access screen, choose
Billing Automatic Billing Create Billing Document .
2. Enter a date and an ID that you can use to identify the run later.
3. Limit your selection on the General Selections tab page. Enter the billing process and the
desired contract account interval.
4. Enter a billing date on the Add. Parameters tab page. This date specifies the time up to
which the program run considers billable items, based on their billing target date.
Under End of Runtime you can specify that the run ends when the date and time entered
have been exceeded. For more information, see the documentation for the fields.
5. Schedule the program run. To do so, choose the
pushbutton in the toolbar.

Schedule Program Run (F8)

For more information, see Functions for Scheduling Program Runs.

When you start the run as a simulation run, the system creates simulated billing documents, but
does not generate any invoicing orders.

Creating Billing Documents in Dialog

When billing in dialog, you manually group individual billable items into billing documents.
You create billing documents in dialog if:

(C) SAP AG

88

For example, in a final billing you want to specify a special billing type (and thereby
document type) denoting the billing document as a final billing document
You want to make another selection or aggregation that differs from your standard
procedure
A grouping variant does not fulfill the desired purpose
This can be the case, for example, if the grouping variant stored in Customizing for the
billing process separates billable items that should be together from the customer's point
of view.

Activities
1. To create billing documents, on the SAP Easy Access screen, choose
in Dialog Create Billing Document .

Billing

Billing

2. Enter the billing process.

3. Enter a billing date.
This date specifies the time up to which the program considers billable items, based on
their billing target date.
4. Limit the selection based on the contract accounts and business partners.
5. Run the program. To do so, choose the

(Execute (F8)) pushbutton.

The system displays in a dialog the billable items corresponding to your selection. By
removing the flag in the Selected column you can exclude individual billable items from
the posting.
6. Choose

(Save (F8)).

The following dialog shows the billing units formed by the system.
7. Choose

(Save (F8)).

The following dialog shows statistical information for the posting. Choose the
(Display Log) pushbutton to display a detailed log.

Log

When you set the Simulation Run flag, the system creates simulated billing documents, but does
not generate any invoicing orders.
When you execute the program by choosing the
No Dialog (Execute Billing Without Dialog)
pushbutton, the system performs the posting in the background (without displaying dialogs).
When you choose the

Expert Mode (Billing Process in Expert Mode) pushbutton, you can:

Also process billable items before they have reached their earliest billing date (billing
target date)
Override the billing type for each billing unit
Example

(C) SAP AG

89

If a grouping variant does not reflect the business relationship (for example, it separates billable
items that belong together, from the customer's point of view), the background processing is
terminated. In this case, you correct the system's automatic grouping proposal in the expert
mode.
End of the example.
In the menu under Goto Variants Save As Variant , you can store the content of
selection parameters as personal favorites under an ID. In this way you can, for example, hide
fields on the selection screen. By choosing the (Get Variants ...) pushbutton you can access
your variants directly.

Reversing a Billing Document in Dialog

You can reverse billing documents.

Prerequisites
You made the necessary settings in the activities in Customizing for Contract Accounts
Receivable and Payable under Integration Billing in Contract Accounts Receivable and
Payable Reversal of Billing Documents .

Features
The billing document reversal:
Reverses the billing document
The system designates the billing document as reversed in the appropriate fields
(number of the reversal document REVERSALDOC).
Creates a reversal billing document
The header of the reversal billing document contains the number of the reversed
document (REVERSEDDOC).
For a billing reversal, the system considers whether the billing document to be reversed was
already invoiced.
If the billing document was not yet invoiced, and no postings were made in Contract Accounts
Receivable and Payable, then the billing reversal creates the reversal billing document and
designates the original billing document as reversed. The reversal also deletes the original
invoicing order so that the reversed document can no longer be invoiced. In the header of the
billing document, the system sets the Invoicing Order Deleted indicator.
If the billing document was already invoiced and postings were already made in Contract
Accounts Receivable and Payable, the billing reversal reverses the billing document. The original
invoicing order no longer exists, since the billing document was already invoiced. The system
also creates a reversal billing document.
For clearing the postings in Contract Accounts Receivable and Payable, the reversal billing
document contains offsetting items for clearing the items to be reversed. At the same time, the
system creates a new invoicing order, so that the reversal billing document and the related
offsetting items can be posted.

(C) SAP AG

90

Note
The reversal billing document and the reversed billing document are linked to each other.
You cannot reverse simulated billing documents.
End of the note.
For more information on the reversal of billing documents, see Special Features for Reversal of
Billing Documents.

Activities
1. To reverse a billing document, on the SAP Easy Access screen, choose
Billing in Dialog Reverse Billing Document .

Billing

2. To select the document to be reversed, either enter the document number directly, or
enter the business partner and contract account.
3. Specify a reversal reason.
4. Run the program. To do so, choose the

(Execute (F8)) pushbutton.

5. In the dialog box that appears, select the documents you want and choose
(OK).

Continue

In the dialog box that appears, the system displays the status of the reversal. Choose the
(Display Log) pushbutton to see more information about the reversal transaction.

Log

Archiving Billing Documents

In order to reduce the load on your database, you can archive billing documents.
For more information see Archiving Billing Documents (FKKINVBILL).

Activities
To archive billing documents, on the SAP Easy Access screen, choose
Data Billing Documents .

Invoicing

Archive

Enhancement Options in Billing

Features
Billing in Contract Accounts Receivable and Payable provides the following enhancement options
for customers and industry business solutions:
Events based on the event concept of Contract Accounts Receivable and Payable

(C) SAP AG

91

You can find the available events in Customizing for Contract Accounts Receivable and
Payable under Program Enhancements Define Customer-Specific Function Modules
using the search term Billing in FI-CA.
Events in inbound processing of billable items (see Upload Rules and Program
Enhancements)
SI includes and CI includes in runtime structures
SI includes and CI includes in document structures of the billing document
Enhancement of the Billing Document
The enhancement of the billing document is focused on the performance needs of invoice printing
along with the requirements of other downstream processes.
Note that each billing document item is linked to the billed item that belongs to it. You specify the
granularity of this link, and thereby also the level of detail of the billing document, using the
aggregation control for the billing process. Using this link, you can therefore make the information
from the billed items available in invoicing, in invoice printing, and for BW extraction.
The linked billed items are a part of the billing document. The enhancement of the billing
document from Billing in Contract Accounts Receivable and Payable (origin process 0007) for
adding the information contained in the billed items is therefore not necessary.
Using the table of additional items of the billing document, you can link the additional information
from customer-specific tables with the billing document and its items.

Source Item

Additional Item

DFKKINVBILL_S
MANDT
BILLDOCNO
BILLDOCSRCITEM

DFKKINVBILL_A
MANDT
BILLDOCNO
BILLDOCADDITEM

1..*

1
*

Billing Document
Item

DFKKINVBILL_I
MANDT
BILLDOCNO
BILLDOCITEM

1..*

Billing Document
Header
DFKKINVBILL_H
MANDT
BILLDOCNO

0..1

Reversal Data
DFKKINVDOC_R
MANDT
BILLDOCNO

1..*
*

Payment Data Item

Tax Item

DFKKINVDOC_PY
MANDT
BILLDOCNO
BILLDOCPAYITEM

DFKKINVDOC_T
MANDT
BILLDOCNO
BILLDOCTAXITEM

Structure of the Billing Document

Enhancement of the Invoicing Document
(C) SAP AG

92

If you enhance the structures of the invoicing document with your own customer fields in CI
includes, be aware that each invoicing item is linked with an item of the billing document.
Therefore at the time of invoicing, invoice printing, and BW extraction, the information from the
related billing documents is also available.
Therefore it is not necessary to enhance the invoicing document with information contained in the
billing document. The system can enrich posting items in Contract Accounts Receivable and
Payable (FI-CA) and Profitability Analysis (CO-PA) during the invoicing runtime with additional
information from the related billing document items or billed items.

(C) SAP AG

93

Billable Item (Billed Status) /1FE/0SCC24IT00

BILLDOCNO BIT_GRPNO SRCTAID

4711

BIT_AMOUNT

12347

SUBPROCESS BITTYPE BITDATE BITTIME

1.-

1000

2000

01/17/2010 21:42:07

Billable Item (Billed Status) /1FE/0SCC14IT00

BILLDOCNO BIT_GRPNO SRCTAID

SUBPROCESS BITTYPE BITDATE BITTIME

BIT_AMOUNT

4711

12345

3.-

1000

1000

01/14/2010 10:52:07

4711

12345

5.-

1000

1000

01/15/2010 11:15:59

4711

12345

2.-

1000

1000

01/15/2010 19:54:22

4711

12346

10.-

1000

1000

01/13/2010 13:11:34

4711

12346

7.-

1000

1000

01/13/2010 16:37:45

4711

12347

2.-

1000

2000

01/11/2010 07:24:48

Billable item (Billed status)

Billable Items

source item

Source Item DFKKINVBILL_S

BILLDOCNO SRC_GROUP BIT_GRPNO BITCAT SRCREF SUBPROCESS

BIT_DBTAB

4711

0815

SCC1

12345

1000

/1FE/0SCC14IT00

4711

0816

SCC1

12346

1000

/1FE/0SCC14IT00

4711

0817

SCC1

12347

1000

/1FE/0SCC14IT00

4711

0817

SCC2

12347

1000

/1FE/0SCC24IT00

Source item

billing item

Billing Item DFKKINVBILL_I

BILLDOCNO BILLDOCITEM HVORG AMOUNT
4711

00001

0300

10.-

4711

00002

0010

17.-

4711

00003

0650

3.-

QTY

SRC_GROUP

0815
500.00

0816
0817

Billing Document
Billing item

invoicing item

Invoicing Item DFKKINVDOC_I

INVDOCNO HVORG AMOUNT

081500

0300

10.-

081500

0010

17.-

081500

0650

3.-

QTY

SRCDOCCAT SRCDOCNO SRCITEMCAT SRCDOCITEM OPBEL

500.00

INVGR PSGRP

INVBI

4711

BILLI

00001

370001

INV1

GR1

INVBI

4711

BILLI

00002

370001

INV1

GR1

INVBI

4711

BILLI

00003

370001

INV2

GR1

Invoicing Item
Invoicing item

posting document

G/L Item DFKKOPK

OPBEL HKONT AMOUNT
370001
370001

175000
175001

27.3.-

QTY
500.00

PSGRP INVGR
GR1
GR1

INV1
INV2
Invoicing item

G/L item

Business Partner Item DFKKOP

OPBEL HKONT AMOUNT PSGRP
370001

140000

30.-

GR1
Invoicing item

G/L item

business partner item

Posting Document

Invoicing Document: Link of Document Items

(C) SAP AG

94

Billable Items
Billable Item /1FE/0SCC14IT00
BILLDOCNO

BIT_GRPNO

BITTYPE

BIT_AMOUNT

4711

SRCTAID SUBPROCESS

12345

1000

1000

3.-

01/14/2010 10:52:07

4711

12345

1000

1000

5.-

01/15/2010 11:15:59

4711

12345

1000

1000

2.-

01/15/2010 19:54:22

4711

12346

1000

1000

10.-

01/13/2010 13:11:34

4711

12346

1000

1000

7.-

01/18/2010 16:37:45

4711

12347

1000

2000

3.-

01/11/2010 07:24:48

BITDATE

BITTIME

Customizing
Billable Item Type TFK8102B
SUBPROCESS

BITTYPE

ITEMTYPE

1000

1000

ZUSAGE

ITEMTYPE Text

Consumption

1000

2000

ZBASE

Basic Charge

Billing Document
Billing Item DFKKINVBILL_I
BILLDOCNO

BILLDOCITEM

ITEMTYPE

HVORG

AMOUNT

4711

00001

ZUSAGE

0300

10.-

4711

00002

ZUSAGE

0010

17.-

4711

00003

ZBASE

0650

3.-

QTY

SRC_GROUP

0815
500.00

0816
0817

Invoicing Item
Invoicing Item DFKKINVDOC_I
INVDOCNO

INVDOCITEM

ITEMTYPE

081500

00001

ZUSAGE

HVORG AMOUNT

0300

10.-

081500

00002

ZUSAGE

0010

17.-

081500

00003

ZBASE

0650

3.-

QTY

500.00

Invoice 081500

Basic charge
Consumption

SRCDOCCAT SRCDOCNO

SRCITEMCAT

SRCDOCITEM

INVBI

4711

BILLI

00001

INVBI

4711

BILLI

00002

INVBI

4711

BILLI

00003

Date 10/22/2010

[ZBASE]
[ZUSAGE]

Invoice amount

3 EUR
27 EUR
------------30 EUR

Invoicing Document: Link Using Item Type

(C) SAP AG

95

Integration of Billing in Other Applications

You can integrate Billing in Contract Accounts Receivable and Payable with SAP Customer
Relationship Management and SAP Convergent Charging.

Billable Item Transfer

To be able to invoice a customer for services, you first need to transfer the valuated usage
instances to Billing in Contract Accounts Receivable and Payable.

Process
The following graphic shows the processing of a valuated item right up to the creation of the
billing document.
SAP Convergent Invoicing
Contract
Account

Items
Items

Billable Items
Transfer

Billing

Billed Items

Billable Items
Billable
Excepted

Billing
Document

Exception
Handling

Items Status
Raw

Raw Excepted

Transfer Raw
Data into
Billable

Transfer and Administration of Billable Items

The following sections explain the values that control the transfer and further processing of
billable items as well as providing examples for their usage and discussing the necessary
Customizing settings.
Note

(C) SAP AG

96

Billing in Contract Accounts Receivable and Payable works without time zones. That means that
Billing in Contract Accounts Receivable and Payable adopts the unconverted date and time from
the external rating and charging system.
End of the note.

Account Assignments
Prerequisites
The system only derives the account assignment for a billable item class if the interface
component External/Internal Account Assignment is active.

Features
When the billable items are transferred from an external system, there is no guarantee that they
have the values known in the SAP system for the account assignment attributes: company code,
division, business area, and segment. Instead, you have the possibility of providing the account
assignments of the external system in the predefined external item IDs. The account assignments
define how the system translates the item IDs of the external system into the internal account
assignment attributes. The derivation is performed using posting area 8120 on the basis of:
The subprocess
The type of the billable item
Up to four external keys

Activities
Define the derivation for the account assignment attributes company code, division, business
area and segment in the Customizing for Contract Accounts Receivable and Payable under
Integration Billing in Contract Accounts Receivable and Payable Billable Item Transfer
Account Assignment Derivation Define Account Assignments .

Transactions
Prerequisites
The system only derives the transactions for a billable item class if the interface component
External/Internal Account Assignment is active.

Features
When the billable items are transferred from an external system, there is no guarantee that they
have the values known in the SAP system for the the main transactions and subtransactions.
Instead you have the possibility of providing information for deriving the transactions in the fields
for the external item IDs. In posting area 8121 you define how the item IDs of the external system
are to be translated in the main transactions and subtransactions of Contract Accounts
Receivable and Payable. The derivation is performed in the basis of:
The subprocess

(C) SAP AG

97

The type of the billable item

Up to four external keys

Activities
You define the derivation for main transactions and subtransactions as follows:
To define the account assignments for billable items that do not have account
assignment to a product, in Customizing for Contract Accounts Receivable and Payable,
choose Integration Billing in Contract Accounts Receivable and Payable Billable
Item Transfer Account Assignment Derivation Define Main Transactions and
Subtransactions .
To define the account assignments for billable items that do have account assignment to
a product, in Customizing for Contract Accounts Receivable and Payable, choose
Integration Billing in Contract Accounts Receivable and Payable Billable Item
Transfer Account Assignment Derivation Define Main and Subtransactions for Items
with Product Account Assignment .

Tax Codes for Internal Tax Determination

Prerequisites
The system only derives the tax codes for internal tax determination for a billable item class if the
interface component External/Internal Tax Code Assignment is active.

Features
When the billable items are transferred from an external system, there is no prerequisite that they
have the values known in the SAP system for the tax account assignment. Instead of this, you
have the possibility to transfer the tax code of the external system in the predefined field for the
external tax code. You translate the tax code of the external system into the internal tax codes or
tax determination codes. The derivation on the basis of the posting area 8123 is only performed
for billable items for which the type of tax determination has the value 01 (Internal Tax
Calculation for External Tax Code).

Activities
You define how the derivation for tax on sales/purchases code and tax determination codes is to
be performed in Customizing for Contract Accounts Receivable and Payable under Integration
Billing in Contract Accounts Receivable and Payable Billable Item Transfer Account
Assignment Derivation Define Tax Code for Internal Tax Determination .

Tax Codes for Externally Determined Tax

Prerequisites
The system only determines tax codes for externally determined taxes for a billable item class if
the interface component Assigning of Tax Codes for Externally Determined Tax is active.

(C) SAP AG

98

Features
Contract Accounts Receivable and Payable posts the externally determined tax as other tax.
The external system transfers billable items to Billing in the SAP system that already contain all
tax-relevant information (including tax amounts). Billing forwards these items to Contract
Accounts Receivable and Payable via Invoicing.
The billing document created by Billing indicates these items as tax items. Contract Accounts
Receivable and Payable posts them as regular tax items. If the external tax codes do not
correspond with the internal codes of the SAP system, it is necessary to derive internal codes
from the external ones. You define how the external tax codes are to be translated into the
internal codes of the SAP system, with which Contract Accounts Receivable and Payable posts
the tax items. The derivation on the basis of the posting area 8124 is only performed for billable
items for which the type of tax determination has the value 03 (External Tax Calculation with
Internal Handling).

Activities
You define how the derivation for tax on sales/purchases code, transaction key for tax transaction
and condition type is to be performed in Customizing for Contract Accounts Receivable and
Payable under Integration Billing in Contract Accounts Receivable and Payable Billable
Item Transfer Account Assignment Derivation Define Tax Code for Tax Determined
Externally .

Tax Type for Externally Determined Other Taxes

Prerequisites
The system only determines the tax type for externally determines other tax if the interface
component Assignment of External/Internal Tax Type for Other Taxes is active.
You have defined the tax type and tax item category In Customizing for Contract Accounts
Receivable and Payable under Basic Functions Particular Aspects of Taxation Procedure
Define Other Tax Codes .

Features
When transferring billable items from an external system, you can handle the taxes internally or
externally. With external tax handling the tax is not calculated in Contract Accounts Receivable
and Payable but in the external billing system. The external system transfers the billable items
with the complete tax items to billing in the SAP system which transfers these items to Contract
Accounts Receivable and Payable using invoicing. The invoice document created by Invoicing
identifies these items as tax items. However, Contract Accounts Receivable and Payable does
not post them as tax items but as revenue items. You define how the external tax ID in the
internal ID of the revenue are to be translated in the SAP system. The derivation on the basis of
the posting area 8125 is only performed for billable items for which the type of tax determination
has the value 02 (External Tax Calculation (Other Tax)). Every tax item that you transfer from an
external billing system must have an ID for the tax type (tax code for other tax) of a particular
company code. You assign this tax type to a particular tax item category.

(C) SAP AG

99

Activities
Define how the derivation for tax codes for other taxes and the category of the tax item for other
tax codes should be conducted. To do so, in Customizing for Contract Accounts Receivable and
Payable, choose Integration Billing in Contract Accounts Receivable and Payable Billable
Item Transfer Account Assignment Derivation Define Tax Type for Other Taxes Determined
Externally .
You make the settings for the transfer of billable items with externally determined tax that
Contract Accounts Receivable and Payable posts as other tax.

Integration with SAP Customer Relationship

Management
In addition to the option of transferring priced services (such as telephone calls or SMS in the
telecommunications area) as billable items from SAP Convergent Charging, you can transfer oneoff charges as billable items directly from the SAP Customer Relationship Management system
into Billing in Contract Accounts Receivable and Payable in the ERP system. If a charge is
reversed in CRM, you can reverse it also in billing.
Example
An example of one-off charges are activation fees.
End of the example.

Prerequisites
You have performed the following steps in SAP Customer Relationship Management:
You have created business partners.
You have created a sales order and triggered the transfer to the ERP system.
For more information see Customizing for Customer Relationship Management under IndustrySpecific Solutions Telecommunications One-Off Charges Define Settings for One-Off
Charges .
In Customizing for Contract Accounts Receivable and Payable in the ERP system under
Integration Customer Relationship Management Business Agreements Determine
Template for Contract Account for Replication you store a contract account template for every
business agreement class in CRM. The system uses this template to create contract account
master data for business agreements in CRM. The contract account template that you use during
integration with SAP Convergent Invoicing must contain a company code group that contains all
company codes.
Example
If you used company codes for Germany as well as the US, the company code group must
contain all company codes that you use for both countries.
End of the example.

(C) SAP AG

100

Features
The data of the billable items is based on the CRM contract data. The ERP system transfers a
part of the data directly. The ERP system derives another part of the data from the posting areas
8170, 8171 and 8172. The derivation using these posting areas in performed in the same way as
for the derivation using posting areas 8120 and 8121 (see External/Internal Account Assignment).

Activities
In Billing in Contract Accounts Receivable and Payable, perform the following steps:
1. In Customizing for Contract Accounts Receivable and Payable, configure a
corresponding class of billable items by choosing Integration Billing in Contracts
Accounts Receivable and Payable Billable Item Classes Maintain Billable Item
Classes . Activate the interface component CRM Order for the class.
2. For the class, store the processing rule Add Items with Errors as Raw Data in
Customizing for Contract Accounts Receivable and Payable under Integration Billing
in Contract Accounts Receivable and Payable Billable Item Management Define
Processing Rules and Program Enhancements .
3. Generate the objects for the class in your test system and live system. To do so, in
Customizing for Contract Accounts Receivable and Payable, choose Integration
Billing in Contract Accounts Receivable and Payable Billable Item Classes
Generate Interfaces for Billable Item Classes .
4. Derive the billable item classes, account assignments and transactions for the posting
from CRM values. To do so, in Customizing for Contract Accounts Receivable and
Payable, choose Integration Customer Relationship Management Transfer of OneOff Charges .
In event 8170 you can enhance the derivation of selected standard fields and customerdefined fields in the billable items.
Define the corresponding function modules and store these at the mentioned events in
Customizing for Contract Accounts Receivable and Payable under Program
Enhancements Define Customer-Specific Function Modules .
5. For the reversal of one-off charges, derive exception reasons from external reversal
reasons. To do so, in Customizing for Contract Accounts Receivable and Payable,
choose Integration Billing in Contract Accounts Receivable and Payable Reversal
of Billable Items Define Derivation of Exception Reasons from Ext. Reversal Reasons
.

Integration with SAP Convergent Charging

SAP Convergent Charging handles the rating (pricing) and charging (determination of invoice
recipient) of services. As a result billable items are created that you transfer to Billing in Contract
Accounts Receivable and Payable and that for example in the case of rerating you can also
reverse.

(C) SAP AG

101

Features
Billing in Contract Accounts Receivable and Payable offers the following Application
Programming Interfaces (APIs) as RFC function modules. SAP Convergent Charging uses these
APIs:
FKK_BIX_BITCAT_LIST_GET_SAPCC
This API supplies the list of billable item classes that are released as productive and that
you have created for SAP Convergent Charging.
FKK_BIX_BITCAT_STRUC_GET_API
This API supplies the technical definitions for a billable item class, such as the field
names in the interface for the class.
/1FE/<billable item class>_BIT_CREATE_API
This API is generated for a billable item class and sends the items to SAP Convergent
Invoicing.
Note
You do not have to configure a destination in order to send billable items. A destination is
only required if you process telecommunications tax data.
End of the note.
FKK_BIX_BIT_REVERSE_CHECK_CC
For a record consisting of source transactions, contract account, and contract reference,
this API provides the information about whether reversal is allowed in SAP Convergent
Invoicing for the related billable items.
FKK_BIX_BIT_REVERSE_CC
This API reverses all billable items for a record consisting of source transactions, a
contract account and a contract reference. For already billed items, the system generates
offsetting items, which compensate for the original items. The system first stores the
request for reversal as a reversal request on the database. The reversal request is either
processed immediately by the system, or you process the reversal request in a separate
step.
Billing in Contract Accounts Receivable and Payable also offers the API
FKK_BIX_BITCAT_LIST_GET_API. This API supplies the list of billable item classes that are
released as productive. SAP Convergent Charging does not use this API.
In Customizing under Integration Convergent Charging Display Interfaces to SAP CC ,
you can get an overview of the interfaces between Contract Accounts Receivable and Payable
(FI-CA) and SAP Convergent Charging (SAPCC). You receive a list of all interfaces. You can limit
the display by choosing a group. To see detailed information on an interface, double click on the
interface.

Activities
To adopt billable items from SAP Convergent Charging and process them in Billing in Contract
Accounts Receivable and Payable, you perform the following steps in your ERP system:

(C) SAP AG

102

1. Configure an appropriate billable item class in Billing in Contract Accounts Receivable

and Payable.
To do so, in Customizing for Contract Accounts Receivable and Payable, choose
Integration Billing in Contract Accounts Receivable and Payable Billable Item
Classes Maintain Billable Item Classes .
2. Activate the interface component SAP Convergent Charging for the class.
3. Activate the billable item class. To do so, in Customizing for Contract Accounts
Receivable and Payable, choose Integration Billing in Contract Accounts Receivable
and Payable Basic Data Activate Billable Item Classes .
4. Enter transfer rules for the billable item class.
To do so, in Customizing for Contract Accounts Receivable and Payable, choose
Integration Billing in Contract Accounts Receivable and Payable Billable Item
Management Define Processing Rules and Program Enhancements and enter the
transfer rule Add Items with Errors as Raw Data.
5. Generate the objects for the class in your test system or live system.
To do so, in Customizing for Contract Accounts Receivable and Payable, choose
Integration Billing in Contract Accounts Receivable and Payable Billable Item
Classes Generate Interfaces for Billable Item Classes .
6. Make the basic settings for the reversal of billable items; define the standard exception
reasons for reversal; and specify if reversal requests are processed immediately or in a
separate process. To do so, in Customizing for Contract Accounts Receivable and
Payable, choose Integration Billing in Contract Accounts Receivable and Payable
Reversal of Billable Items Make Basic Settings and Define Processing Rules.
7. Create a user from the SAP Easy Access screen under Tools Administration User
Maintenance Users . On the Logon Data tab, enter the User Type Communication
Data.
8. Assign this user the authorizations for the authorization objects F_KKBIXBIT and
F_KKBIXCON.
Using the access data of this user, SAP Convergent Charging calls the APIs in SAP
Convergent Invoicing in the ERP system.
9. Assign authorization for authorization object S_TABU_DIS to this user. Using the access
data of this user, SAP Convergent Charging calls the SAP NetWeaver API
BAPI_CURRENCY_GETLIST in the ERP system.
Now perform the following steps in SAP Convergent Charging to configure the charging master
data for the service provider. For more information, see the documentation for SAP Convergent
Charging.
1. Create a catalog in the Core Tool.
2. Create a mapping for billable items and a charged item class.
SAP Convergent Charging offers a list of the billable item classes that you have created
in Billing in Contract Accounts Receivable and Payable. Choose a billable item class.

(C) SAP AG

103

SAP Convergent Charging automatically creates a mapping for billable items and a
charged item class that is based on the billable item class you choose.
3. Create a chargeable item package and a chargeable item class.
4. Create the charges.
5. Create a charge plan and assign charges.
In each charge of a charge plan, you configure the generation of charged items and
billable items. That means you specify which values the system adopts in the individual
fields. You can reuse values from rating or charging or the processing of chargeable
items.
Example
SAP Convergent Charging automatically derives the field Amount of the Billable Item
(BIT_AMOUNT) from the charged amount.
End of the example.
You can assign multiple charge plans to a product.
6. If it is relevant for your processes, create master data for the refill of prepaid accounts.
7. Create a subscriber account in SAP ERP or SAP CRM.
Specify the connection of the master data to Billing in Contract Accounts Receivable and
Payable. In the external account key, enter the number of the contract account in Billing
in Contract Accounts Receivable and Payable. Under External Billing System, enter the
number of the business partner in Billing in Contract Accounts Receivable and Payable.
8. Create a provider contract in SAP CRM.
9. Create an incoming entry.
You can change billable item classes in Billing in Contract Accounts Receivable and Payable.
The changes that are allowed depend on the configuration status of the class (see Configuration
of Billable Item Classes).
Note
Note:
If a class has the configuration status In Processing or Transportable, you can change
the interface in any way you like. In particular, this means that you can delete fields from
the interface. Since SAP Convergent Charging does not support the deletion of individual
fields in a charged item class, you have to create a new mapping for billable items with a
new charged item class. You also have to adjust all dependent objects in SAP
Convergent Charging accordingly (such as the charges in the charge plan).
If a billable item class has the configuration status Released as Productive, you can only
make compatible changes to the interface. This means that you can only add fields to the
interface. The system adds the new fields to the end of the structures in the interface. As
a result, you can continue to adopt billable items using the corresponding generated RFC
function module, without it being necessary for SAP Convergent Charging to fill these
new fields (offset problematic with RFC calls). If SAP Convergent Charging is to fill these

(C) SAP AG

104

new fields with values, you must identify all changes to the configuration so that SAP
Convergent Charging can generate or convert the corresponding data. You also have to
determine the method for converting these changes. For more information, see the
configuration guide for SAP Convergent Charging.
End of the note.
SAP Convergent Charging determines amounts with up to six decimal places. You can process
these amounts in the ERP system. For more information, see Handling Amounts with Increased
Precision.

More Information
For more information about SAP Convergent Charging, see the SAP Help Portal at
http://help.sap.com SAP Business Suite SAP Convergent Charging .

Updating Billable Items to SAP NetWeaver BW

Features
Extraction of billable items that have not been billed yet
The data retention for billable items is designed so that for every status that billable items can
have, the system stores the data in a separate database table (see Data Storage). Thus only
those tables containing items already billed grow continuously. In contrast, the size of the tables
containing items not billed, that is items with the status Raw, Raw Excepted, Billable or Billable
Excepted, remain generally stable, or the growth is generally negligible. This fact makes it
possible to perform an extraction based on key dates for the complete content (full upload) of the
tables for billable items with the following status:
Raw
Raw Excepted
Billable
Billable Excepted
You perform the extraction with your own generic extractor, which you define in transaction
RSO2.
Note
Note that for every data extraction, the system loads the complete data content of the tables to be
extracted. You can distinguish the results of the individual extractions using the request number
for the data transfer (extraction request number). However, it is recommended that before a new
extraction, you delete the results of previous extractions in SAP NetWeaver BW.
End of the note.
Extraction of Invoiced Billable Items
You can extract billed and invoiced billable items within the transfer of the invoicing documents in
SAP NetWeaver BW. In Customizing you can define that a billable item class is relevant for the
sales statistics (see Processing Rules and Program Enhancements). The effect of this setting is

(C) SAP AG

105

that at the time of the extraction, the system adds the detailed information of the related billed
items to the extraction data of the invoicing document. In doing so, the system distributes the
information of the individual invoicing items to the related billed items. For more information, see
section Updating to SAP NetWeaver BW in the documentation for the invoicing in the Contract
Accounts Receivable and Payable.

Invoicing in Contract Accounts Receivable and

Payable
Purpose
Invoicing in Contract Accounts Receivable and Payable makes it possible to create convergent
invoices that you send to your customers, and posts the invoice amounts in Contract Accounts
Receivable and Payable (FI-CA).
Invoicing in Contract Accounts Receivable and Payable is adjusted to meet the requirements of
the application that uses FI-CA (for example, industry component Telecommunications).
Together with Billing in Contract Accounts Receivable and Payable [Seite 15], it offers a
comprehensive back end solution for the mass processing of invoice creation based on billable
items [Seite 19].

Integration
In conjunction with Billing in Contract Accounts Receivable and Payable, Invoicing in Contract
Accounts Receivable and Payable forms SAP Convergent Invoicing [Extern].
Invoicing in Contract Accounts Receivable and Payable merges billing information from SAP
billing systems, such as Billing in Accounts Receivable and Payable, and billing systems from
other providers into customer invoices.
You can integrate billing from the Sales and Distribution (SD) component directly into Invoicing in
Contract Accounts Receivable and Payable. You can connect external billing systems or CRM
Billing to FI-CA using a BAPI/IDoc interface.
Using the print workbench, you can create invoices (or invoice raw data).
When you post invoices in FI-CA, the system updates General Ledger Accounting (FI-GL) and
Profitability Analysis (CO).
You can transfer the data from Invoicing in Contract Accounts Receivable and Payable to SAP
NetWeaver Business Warehouse (SAP BW).
The processes displayed in the following figure can run asynchronously. The document flow is as
follows:
...

1. Transfer billing documents from external systems.

2. Save billing documents in the SAP system.
3. Process billing documents in FI-CA using processes in Invoicing in Contract Accounts
Receivable and Payable.
4. Create postings in FI-CA and create invoicing documents as the basis for invoice printing
and updating to SAP NetWeaver Business Warehouse.

(C) SAP AG

106

Runtime

Contract
Account
1

Positionen
External
Billing

FI-CA
Document
2

Inbound
Process

Printing
Process

Invoicing

Billing
Document

Invoice

Invoicing
Document

Archiving

BW Extraction
BW Output

Design Time
Print Form
Inbound
Mapping

Invoicing
DataSource

Basic Terms of Invoicing in Contract Accounts

Receivable and Payable
The following sections introduce terms:
That describe and control the invoicing processes
That you can use to portray the invoicing processes
That you can use to design and adjust invoicing processes to meet your requirements
In addition to the definition of the most important terms, the following also describes the use of
the individual elements, the options for using them using examples, and the settings in the
Implementation Guide.
Design of the Invoicing Process

(C) SAP AG

107

Runtime
FakturierungsInvoicing
Unit
einheit

Invoicing Process
Contract
Account

Event
2603

Invoicing
Order

BillingBilling
Document
Document

FI-CA
Document

Invoicing
Document

Design Time
Document
Selection

Grouping
Variant

Invoicing Process

FakturierungsInvoicing
funktionen
Functions

Invoicing
Category

Open Item
Selection

Invoicing Type

Invoicing Processes
Definition
Forms the superordinate term for the execution of invoicing functions in Contract Accounts
Receivable and Payable according to defined rules. These rules are defined by parameters that
you can use to control the invoicing process.

Use
In addition to invoicing processes delivered by SAP, you can define your own invoicing
processes. For each process, you can adjust the behavior of the SAP invoicing program to your
own requirements such that only the required invoicing functions are run and this takes place
under the consideration of your individual settings for these functions. This flexibility is in addition
to non-modification enhancements using includes, BAdIs, and events.
You cannot change the order in which the activated invoicing functions are
performed. This order is fixed by the main invoicing program. You should also note
that customer enhancements in an invoicing function are only performed if this
invoicing function is active. Reference is made to invoicing processes at the
following points (among others):
Invoicing processes are used as selection parameters for mass activities for
Invoicing in Contract Accounts Receivable and Payable.
Number ranges for invoicing documents are defined dependent on the
invoicing processes.
Invoicing processes are a differentiation characteristic for the activation of
optional invoicing functions.
(C) SAP AG

108

You can create new invoicing processes in Customizing for Contract Accounts Receivable and
Payable under Integration
Invoicing in Contract Accounts Receivable and Payable
Invoicing
Invoicing Processes
Define Invoicing Processes.

Structure
At the level of the invoicing process, you can use the following controls:
Selection of the source documents to be invoiced
For each invoicing process, you can define which categories of source documents (for
example, billing document, SD billing document) are selected by and processed for this
process.
Grouping of source documents into invoicing units
You can assign an individual grouping variant for automatically grouping source
documents, for which a joint invoice is to be created, to each invoicing process.
Selection of invoicing functions
Using this selection you define the type and scope of the functions to be supported in an
invoicing process.
To ensure data and program consistency, some invoicing functions are always active.
Other invoicing functions are optional and are only executed in invoicing processes for
which they have been activated.
Fine control of invoicing functions
Most invoicing functions have their own control options (for example, item selection for
account maintenance, interest calculation). You can configure this control dependent on
the invoicing process in which the invoicing function is performed.
In addition, the invoicing process classifies invoicing documents from a business and accounting
perspective by means of the invoicing types assigned to it.

Example
You want to perform invoicing runs that only process (normal) billing documents, and invoicing
runs that only process collective bill documents.
You define one invoicing process that selects only source documents of the category Billing
Document, and one invoicing process that selects only collective bill documents.

Invoicing Functions
Definition
Invoicing in Contract Accounts Receivable and Payable consists of numerous processing steps.
From a business point of view, some of these processing steps form complete business
transactions and are known as invoicing functions.

Use
In the definition of an invoicing process, you define which invoicing functions are to be performed.
This has the following advantages:
The invoicing functions selected make visible which invoicing processing steps Invoicing in
Contract Accounts Receivable and Payable performs in an invoicing process.

(C) SAP AG

109

The invoicing program recognizes invoicing functions not required with no loss of runtime
and does not execute them.
You can use a multilevel control to activate or deactivate invoicing functions that are not
required in all cases.
The invoicing program defines the order in which the invoicing functions are performed and you
cannot change this.

Source Document Categories

The source document category classifies source documents that can be processed in Invoicing in
Contract Accounts Receivable and Payable. These source documents are designated by values
for the characteristic Source Document Category.
The source document category contains information about the technical makeup of the source
document and where it is stored.

When configuring the invoicing process, you specify which source document categories the
invoicing process processes. Invoicing processes can process source documents of the following
source document categories:
INVBI - Billing document
A document that was created by Billing in Contract Accounts Receivable and Payable, or
by another SAP system or third-party system, and was transferred to Invoicing in
Contract Accounts Receivable and Payable using an interface especially designed for
this purpose.
SD - SD document
An SD billing document that was created in the Sales and Distribution (SD) component
and is to be posted or processed into an invoice in invoicing.
COLBI - Collective bill
A collective bill that was created by invoicing the individual accounts of a collective bill
account, and is to be processed into a collective invoicing printout through invoicing of
the collective bill account.
ACTIT - Open posting item to be activated
An open item posted before invoicing and that has a special clearing restriction and that
is to be requested by invoicing.
SUBIN - Single invoicing document of an invoicing list
An invoicing document that is to be added to an invoicing list.
CYCLE - Invoicing order for creating periodic invoicing
An invoicing order that was created by period control for invoicing.
(C) SAP AG

110

ADHOC - Invoicing order for creating ad hoc invoicing

Example
You want to process billing documents of source document category INVBI, which were created
in Billing in Contract Accounts Receivable and Payable, in an invoicing process. To be able to do
so, you have to enter source transaction category INVBI in the selection control of this invoicing
process, and activate the invoicing function Invoicing of Billing Documents in the invoicing
process.

Source Document Types

The source document type describes the business meaning of a source document of a certain
source document category.

You can use the source document type when creating invoicing orders to classify the source
documents.

Example
You only want to process billing documents of a certain source document type in an invoicing
process. To achieve this, when configuring the invoicing process, you enter the given source
document type in the extended selection control for the invoicing process.

Invoicing Types
Definition
Characteristic that characterizes the composition of invoicing units. It is used to classify invoicing
documents and controls the invoicing functions within an invoicing process.

Use
For each invoicing process you have to define one or more invoicing types. To do this, you can
either define a standard value in the configuration of the invoicing process, or determine the
invoicing type dynamically in the invoicing run dependent on the composition of the invoicing unit
in event 2603. To help you to make this decision, you can use the table where the invoicing
orders to be processed in the current invoicing unit are recorded.

Example
You differentiate between billing documents that belong to a periodic billing from billing
documents that have arisen due to the end of a contract (final billing documents). Interest can
only be calculated on cash security deposits and cleared against the invoice receivable for the
invoicing of final billing documents. To do this, proceed as follows:
...

1. You define an invoicing type Standard and assign it to the invoicing processes.
2. You define a further invoicing type, Final Billing.

(C) SAP AG

111

3. In event 2603, you check whether final billing documents are processed. If yes, set the
invoicing type Final Billing.
4. In event 2622, you define that interest is only calculated on cash security deposits for
invoicing type Final Billing.
5. In posting area 2630 (account maintenance), you permit the clearing of cash security
deposits for invoicing type Final Billing only.

Invoicing Categories
Definition
Key that references the contract account reference in Invoicing in Contract Accounts Receivable
and Payable Together with the invoicing type [Seite 111] and invoicing process [Seite 108], it
controls the invoicing functions.

Example
Invoicing in Contract Accounts Receivable and Payable is to calculate a discount for a specific
customer group. To do so, proceed as follows:
...

1. Create several invoicing categories.

2. In the contract accounts, maintain the invoicing category dependent on the customer group
of the business partner.
3. In posting area 2617, define discounts for the invoicing categories.

Target Date for Invoicing

The target date for invoicing is the earliest possible date for invoicing a source document. It
defines that a source document cannot be invoiced until the date specified is reached (refers to
the document date of invoicing).
Only in expert mode for invoicing is it possible for you to invoice source documents before they
have reached their target date for invoicing.
The system determines the target date for invoicing using scheduling. In scheduling you can
select the date that serves as the baseline date for the determination. Based on this baseline
date, determination rules determine the target date for invoicing.
You make these settings in Customizing for Contract Accounts Receivable and Payable under
Integration Invoicing in Contract Accounts Receivable and Payable Invoicing Invoicing
Processes Define Rules for Determination of Invoicing Date .

Billing Cycle

(C) SAP AG

112

The billing cycle is used to specify billing periods. The billing cycle specifies the period end and
the length of a billing period.
The actual billing time span can differ from the billing period.
Example
You do not transfer billable items from the month of January into the system until February. The
invoice for the month of February, therefore, has a billing time span that goes back into January,
whereas the billing period consists only of the month of February.
End of the example.
You define the billing cycle in Customizing for Contract Accounts Receivable and Payable under
Integration Billing in Contract Accounts Receivable and Payable Basic Data Scheduling
Define Billing Cycle or under Integration Invoicing in Contract Accounts Receivable and
Payable Invoicing Invoicing Processes Scheduling for Invoicing Define Billing Cycle .
Then you enter the technical key of the billing cycle in the contract accounts or in the provider
contract items of your business partners.
Depending on the configuration of the billing cycle, you can overwrite the period end date at the
level of the contract account.
You can use the billing cycle in scheduling for determining the target date of billing or the target
date of invoicing.

Scheduling for Invoicing

Using scheduling, the system determines the target date for invoicing, that is, the earliest possible
date for invoicing of source documents (see Target Date for Invoicing).

Features
Scheduling for invoicing helps both to technically distribute the load on the system, as well as
allowing you to specify a customer-specific invoicing date.
You can use billing cycles to influence the determination of the target date of billing and the target
date of invoicing. If a billing cycle is entered in the contract account, then it applies (if no further
changes are made) to both billing and invoicing. For billing, however, you can enter a different
billing cycle in the provider contract items than in the contract account. As a result, billing could
take place on a weekly basis and invoicing take place every two weeks. If you do not need this
separate control, then it is sufficient to enter the billing cycle either in the contract account or in
the provider contract. If you do not want to use cycle-based billing or invoicing for certain billable
items or source documents, you can define different rules for these objects.
Regardless of whether or not you use billing cycles, you can influence the billing date and
invoicing date as follows:
You can specify grace days, such as two days after the creation of the invoicing order.
You can define periods, such as every 14 days.
You can configure special factory calendars.

(C) SAP AG

113

If you want special dates to be valid for certain contract accounts, you can define different rules
for them that are dependent on the selection characteristic for scheduling.
Note
The standard system determines the billing date and the invoicing date cycle-based at the end of
the period as long as a billing cycle is entered in the contract account or provider contract and
no different rules for determining the times of execution are entered in the system. In all other
cases, the rules for determining the target date of billing and the target date of invoicing specify
the times when billing or invoicing is executed.
For periodically invoicing contract accounts, even if there are no source documents to be invoiced
in the system, use the mass activity for creating additional periodic source documents (invoicing
orders). You specify the processing rules for these special source documents (invoicing orders) at
the level of the source document types. They are processed in the invoicing function Invoice
Additional Periodic Source Documents.
End of the note.

Activities
You make the system settings for scheduling Invoicing in Contract Accounts Receivable and
Payable in Customizing for Contract Accounts Receivable and Payable under Integration
Invoicing in Contract Accounts Receivable and Payable Invoicing Invoicing Processes
Scheduling as follows:
1. In the activity Define Selection Characteristic of Scheduling, you have the option of
entering an indicator for finer control of scheduling. Using the selection characteristic, you
can influence the determination of the target date of billing and invoicing at the level of
the contract accounts.
2. If you want to use billing cycles in scheduling, in the activity Define Billing Cycle, define a
billing cycle and configure the controls for determining the periodicity and for determining
the billing period. You also specify here if these properties can be overwritten in the
contract account.
3. In the activity Define Rules for Determination of Invoicing Date, you define the rules for
determining the target date for invoicing. In addition, you specify if the target date of
invoicing is synchronized with the billing cycle (in relation to either the beginning or the
end of the billing period).
4. In the activity Allocate Rules for Determination of Invoicing Date, you define the
derivation of the rule for determining the invoicing date. The derivation can be made
using the billing cycle, the selection characteristic for scheduling, the source document
category, and the source document type.
You make the system settings for creating additional periodic source documents in Customizing
for Contract Accounts Receivable and Payable under Integration Invoicing in Contract
Accounts Receivable and Payable Invoicing Invoicing Processes Scheduling Additional
Source Documents for Periodic Invoicing as follows:
1. In the activity Define Source Document Types for Additional Source Documents, you
define source document types for the additional source documents for the source
document category CYCLE.

(C) SAP AG

114

2. In the activity Define Processing Rules for Source Document Types, at the level of the
source document type, you define rules for creating invoicing orders and for processing
these additional periodic source documents in invoicing.
In defining these rules, you specify grace periods that the system takes into account
when creating the invoicing order. In addition, you specify if the invoicing of these
additional source documents should be suppressed if there are no further source
documents to be invoiced or if the invoicing document does not contain any items (zero
invoice).
3. In the activity Define Control for Additional Source Documents, you specify if the system
creates additional periodic source documents. You make this specification dependent on
the invoicing category and the billing cycle.
4. In the activity Maintain Number Ranges for Additional Source Documents, you define the
number range intervals for the creation of additional source documents. The system
determines the number range interval using a randomized algorithm.
5. You enter the invoicing function Invoice Additional Periodic Source Documents in
Customizing for Contract Accounts Receivable and Payable under Integration
Invoicing in Contract Accounts Receivable and Payable Invoicing Invoicing
Processes Define Invoicing Processes .
6. You activate the invoicing function Invoice Additional Periodic Source Documents in
Customizing for Contract Accounts Receivable and Payable under Integration
Invoicing in Contract Accounts Receivable and Payable Invoicing Invoicing
Processes Define Invoicing Types .
7. You enter the key for scheduling and the billing cycle in the contract accounts of your
business partners.

Example
Your customers receive an invoice once a month for a billing period that encompasses one
calendar month. To ensure that all billing-relevant data of the calendar month is in the system at
the time of invoicing, you define a waiting period for invoicing of 2 days after the end of the billing
period. As a result, invoices are created on the second day of the following month, at the earliest.
1. You define billing cycle ZME1 that specifies 31 as the ending day of the period, that is, the
last day of the month. As the frequency, you use M1 (monthly).
2. You assign billing cycle ZME1 to the contract accounts of your business partners.
3. You define the rule Z001 for determining the invoicing date. You specify that the baseline
date for the calculation is the date the source document was created. In addition, the rule
should be cycle-based in regard to the period end.
4. In the calculation rules, you enter two additional days.
For a source document created on December 17, the following dates result:
Baseline date for determining the target date of invoicing is December 17.
Invoicing is cycle-based in relation to the period end. The system determines the end of
the billing period in which December 17 lies. The period that the system determines
extends from December 1 to December 31. The baseline date for determining the target

(C) SAP AG

115

date is corrected to the end of the period determined, so that the baseline date is
December 31.
The calculation rule Z001 adds two additional days to the baseline date.
The target date for invoicing the source document from December 17 is therefore January 2 of
the following year.

The Term Invoice in Invoicing

From a business perspective, the invoice amount of an invoice can contain either current
receivables only, or it can contain the account balance of the business partner, taking into
account old receivables and credits as well as current receivables. From the invoice amount
alone it is not possible for the system to interpret an invoice; from the perspective of invoicing, the
invoice amount serves informational purposes only. An invoice can only be interpreted based on
the information from the individual invoice items.
In the standard case, the invoicing document consists solely of the items of the billing document.
In that case, the net amount plus the tax amount comprises the gross amount of the invoice
(invoice amount).
In addition to these regular invoice items (receivables and tax items), you can also print additional
items and include them in the final invoice amount. You decide if the system should consider
these items in the final invoice amount. In invoice formatting, you can describe how the invoice
amount originated (for example, "invoice amount contains cash deposit to be paid of $200"). If, for
example, you have printed open receivables, returned cash security deposits, deactivated
installment plans, or created final invoices, then the gross amount of the invoice does not consist
of the billing document items plus the tax due. The invoice can only be explained based on the
individual items.

Example
Example 1
You include an old receivable in the invoice and in the final invoice amount. Therefore, this
invoice (the invoice amount) is made up of all receivables and credits that are still open. For the
old receivable, you do not calculate taxes any more, since the receivable is already posted. The
system increases the final invoice amount (gross) accordingly by the amount of the old
receivable. The tax amount of the invoice, however, relates solely to the current open
receivables, since a tax calculation is made only for items that are new in the current invoice. If
you look at the net amounts of all the new receivables and add the calculated tax, the gross
invoice amount is less than the final invoice amount.
Example 2
A customer terminates his contract. You now have to pay out the cash security deposit of USD
200 that was made by the customer. In final invoicing, you find that the customer owes a
remaining receivable of USD 100 net (USD 19 tax). You have the following options for
representing this business transaction:
You create an invoice for the amount of USD 119. That means that you post a receivable
of USD 119 and pay out the cash security deposit of USD 200 separately.

(C) SAP AG

116

You configure invoicing so that when a cash security deposit is paid out, this amount
flows into the final invoice amount. Therefore, you include the credit of USD 200 resulting
from the security deposit in the invoice. The invoice amount is therefore USD -81, the tax
amount USD 19. (Security deposits are not taxed.) The net amount is USD 100.
Note
The system calculates gross amounts, net amounts, and taxes at the level of the invoicing
document header. However, the amount that the system displays in the invoicing document
header (TOTAL_AMOUNT) as the invoice amount depends on how you define the scope of
invoices in your system. The standard system, therefore, cannot guarantee the the sum of the net
amount and the tax amount equals the gross amount of the invoice.
As part of the integration with SAP CRM (Interaction Center for Financial Customer Care), you
can adapt the amounts in the events 2788 and 2789 to the scope of invoices you defined in your
system.
End of the note.

Invoicing Processes in Contract Accounts

Receivable and Payable (FI-CA)
Purpose
Based on billing information, Invoicing in Contract Accounts Receivable and Payable creates
invoices that you post in Contract Accounts Receivable and Payable (FI-CA).

Prerequisites
You have activated Invoicing in Contract Accounts Receivable and Payable in Customizing for
Contract Accounts Receivable and Payable under Basic Functions
Postings and Documents
Basic Settings
Maintain Central Posting Settings.
You have entered the master data of the business partners and contract accounts to be invoiced.

Process Flow
The invoicing processes cover the processes of Invoicing in Contract Accounts Receivable and
Payable that create invoices and integrate billing documents in FI-CA. They map the business
transaction that processes the billing documents, creates the invoice, and posts the invoice
synchronously. In detail, they perform the following tasks:
Billing documents from different billing systems are selected, grouped, and displayed
together on one invoice. (See Transferring Billing Documents [Extern] and Billing
Documents [Seite 79])
Billing documents are transferred to postings documents in FI-CA synchronously.
The invoice display of the tax amounts can influence the tax to be posted.
Invoicing documents are created. These save the information for the invoice and are the
basis for the physical invoice printing.
Simultaneously, correspondence containers are created for invoice printing [Seite 222],
and additional data is updated for providing data to Business Information Warehouse (BW)
(See also Update in SAP Business Information Warehouse (BW) [Seite 295].)

(C) SAP AG

117

Current information for the customer account, such as open invoice receivables, can be
displayed on the invoice.
You can integrate further FI-CA business transactions in the invoicing processes such that
the customer can be informed of changes to the customer account with the invoice. For
invoice creation and posting, Invoicing in Contract Accounts Receivable and Payable uses
FI-CA functions. For example, in an invoicing run, you can change the contract accounts of
the customers processed by the run. The invoicing run can clear open items of an invoice
with credit memo items of a contract account.
Invoicing orders must exist in order for an invoicing process to be started.
Invoicing orders are created when a billing document is created and are used for specific
selection of the billing documents not yet processed by an invoicing process. If the invoicing of a
billing document is successful, the related invoicing order is deleted.
In addition to billing documents that arise in the SAP system from the transfer of billing
documents from external systems or from Billing in Contract Accounts Receivable and Payable,
SD billing documents from the component Sales and Distribution and collective bills from FI-CA
can also be understood as invoiceable billing documents. Special invoicing processes can
process these source documents. (See Collective Invoicing [Seite 173].)
Using scheduling, you can generate additional source documents. These enable periodic
invoicing, independently of the existence of further source documents to be billed.
Parallel processing of the dataset is always possible. The invoicing processes use the function of
the mass activity in FI-CA to split the dataset and distribute processing to different processes in
order to reduce the processing time.
Invoicing Processes in Contract Accounts Receivable and Payable (FI-CA)
ERP

Master Data Maintenance

Contract
Account

SD

Business
Partner

Invoicing in FI-CA

Invoicing
Processes

SD Billing
Request

FI-CA

Selection

External
Billing System

Grouping

Invoicing
Order

Functions

RW-IN

Invoicing
Document

Billing
Document
Inbound
Interface

Extraction
Order

ALE

Mapping

BAPI

External
Document _Data

(C) SAP AG

Correspondence
Container

FI
CO
FM

Invoice
Printing

BI Extraction

118

Process Flow of Invoicing Processes

Purpose
Invoicing is performed in the following steps:
...

1. Data Selection
During data selection, the system selects the invoicing orders for the invoicing process.
You define the selection criteria for the data selection for the invoicing process.
2. Creation of Invoicing Units
The system groups the selected invoicing orders into invoicing units for each contract
account. You can create several invoicing units for each contract account. For each
invoicing unit, Invoicing in Contract Accounts Receivable and Payable creates one
invoicing document.
You define the criteria for creating the invoicing units for the invoicing process.
3. Processing of Billing Documents
The system includes the selected billing documents for an invoicing unit in the invoicing
document. The billing document items are linked with the items of the invoicing document,
and the derivations required for the posting in Contract Accounts Receivable and Payable
(FI-CA) are performed.
4. Performance of Additional Functions
In addition to processing billing documents, in Invoicing in Contract Accounts Receivable
and Payable, you can integrate further functions of FI-CA. For example, these include
interest calculation, creation of dunning proposals, or the calculation of charges and
discounts. You define which additional functions are performed for each invoicing process.
5. Account Maintenance
Using the account maintenance integrated in Invoicing in Contract Accounts Receivable
and Payable, you can perform clearing between the posting documents entered in
Invoicing and the open items of the contract account posted before invoicing. You define
the criteria for clearing in the clearing control.
6. Update
The system writes the invoicing documents created for the invoicing unit and the posting
documents to the database, and deletes the processed invoicing orders.
Along with the invoicing unit, a correspondence container for invoice printing and an
extraction order for the update to BW are created.
Process Flow of Invoicing Processes

(C) SAP AG

119

Data Selection

Invoicing
Order
Creation of
Invoicing Units
Billing
Document
Processing of Source Documents
FI-CA
Document

Processing of
Billing
Documents

Processing of
Collective Bills

Processing of SD
Billing
Documents

SD Billing
Document

Additional Functions
Interest
Calculation

Dunning

Charges/
Discounts

Account
Maintenance

FI-CA
Document

Update

Invoicing
Document

Processing Options
Purpose
Adjustment of the internal process flows of Invoicing in Contract Accounts Receivable and
Payable to your requirements.

Process Flow
The process flow of Invoicing in Contract Accounts Receivable and Payable depends on the
following parameters:
Invoicing process [Seite 108]
Invoicing Type [Seite 111]
Invoicing Category [Seite 112]
This multi-level control enables you to run Invoicing in Contract Accounts Receivable and
Payable according to your requirements. The parameters specified above are determined as
follows during the processing of each contract account:
The user specifies the invoicing process explicitly when starting Invoicing in Contract
Accounts Receivable and Payable. The main task of the invoicing process is to define
which categories of source documents are to be processed. It also defines the process flow
for the invoicing functions. There is a differentiation between mandatory and optional
invoicing functions.
Each invoicing process proposes an invoicing type. You can override the invoicing type at
event 2603. Using the invoicing type, you can react individually to the composition and the

(C) SAP AG

120

properties of the invoicing unit. The invoicing type also defines, for each invoicing unit,
which optional invoicing functions are performed.
At master data level, you can influence the process flow of Invoicing in Contract Accounts
Receivable and Payable using the invoicing category; this is transferred from the contract
account.

Activating/Deactivating Invoicing Functions

Purpose
Adjustment of the process flows of Invoicing in Contract Accounts Receivable and Payable to
customer-specific/industry-specific requirements by activating and deactivating invoicing functions

Process Flow
The system decides whether an invoicing function is performed for each invoicing unit using the
following criteria:
..

1. Assignment of invoicing function to invoicing process

The system checks whether the function is assigned to the invoicing process.
2. Assignment of invoicing function to invoicing type
The system checks whether the function is assigned to the invoicing type.
3. Selection of function in dialog
If Invoicing in Contract Accounts Receivable and Payable is run in dialog or in expert
mode, the system checks whether the user has selected the invoicing function .
Step 1
When you define an invoicing process (see Implementation Guide for Contract Accounts
Receivable and Payable
Integration
Invoicing in Contract Accounts Receivable and Payable
Invoicing
Invoicing Processes
Define Invoicing Processes), in the subdialog Invoicing
Functions, you have to assign one or more invoicing functions to an invoicing process. When you
start Invoicing in Contract Accounts Receivable and Payable with an invoicing process, the
assignment of the invoicing functions has the following effect:
Invoicing functions assigned where the indicator Function Can Be Activated is not selected are
performed. The run cannot be prevented in step 2 or 3.
Invoicing in Contract Accounts Receivable and Payable does not perform invoicing functions
that are not explicitly listed in the assignment. This decision can also not be changed by
step 2 and 3.
For invoicing functions assigned where the indicator Function Can Be Activated is selected,
step 2 or 3 defines whether they are performed .
Step 2
In the definition of the invoicing types, in the subdialog Invoicing Functions, you can assign all
invoicing functions that are designated as can be activated/deactivated to the combination of
invoicing type and invoicing category. In the assignment you must also maintain the activation
status. Invoicing in Contract Accounts Receivable and Payable interprets this assignment as
follows:
Functions that can be activated and that are not assigned to the invoicing type are not
performed. This decision cannot be changed by step 3.

(C) SAP AG

121

Functions that can be activated that have been assigned to the invoicing type with activation
status 1 Function active, cannot be deactivated in dialog, are performed. This decision
cannot be changed by step 3.
Functions that can be activated that have been assigned to the invoicing type with activation
status 2 Function active, can be deactivated in dialog, are performed. This decision can be
changed by step 3.
Functions that can be activated that have been assigned to the invoicing type with activation
status 3 Function not active, can be activated in dialog, are not performed. This decision
can be changed by step 3.
Step 3
If you run Invoicing in Contract Accounts Receivable and Payable in dialog, and select the expert
mode, you have another influencing option. Invoicing functions (step 1) that can be activated
according to the invoicing process can be activated or deactivated in a dialog step if the activation
status (step 2) permits this.

Examples: Activating/Deactivating Invoicing

Functions
Example 1
You assign the following functions to invoicing process 01:
Function

Can Be Activated

INV_BILL_DOC

ACCT_MAINT

HIST_ITEMS

CHARGE_DISC

INTEREST_SEC

You assign the following invoicing functions to invoicing type 02 and invoicing category 03:
Function

Activation Status

ACCT_MAINT

2 Function active, can be deactivated in dialog

HIST_ITEMS

1 Function active, cannot be deactivated in

dialog

INTEREST_SEC

3 Function not active, can be activated in

dialog

You run the invoicing program with invoicing process 01. An invoicing unit with invoicing type 02
and invoicing category 03 is processed.
Result
The following invoicing functions are performed:
INV_BILL_DOC

(C) SAP AG

122

ACCT_MAINT
HIST_ITEMS

Example 2
The same conditions as in example 1 apply. However, you run invoicing in dialog or expert mode.
Result
INV_BILL_DOC is performed (no selection option).
HIST_ITEMS is performed (no selection option).
For ACCT_MAINT, execution in dialog is proposed.
You can deactivate the function.
For INTEREST_SEC, in dialog the system proposes not to run the function.
You can activate the function.

Mandatory Invoicing Functions

Definition
Invoicing functions that must be performed

Use
In the definition of the invoicing process, in the subdialog Selection Control, you define which
source document categories are processed in this invoicing process. Dependent on the selection
control, the following invoicing functions are mandatory:
If you select billing documents, you have to assign the invoicing function INV_BILL_DOC.
The opposite also applies: If, for example, you do not select billing documents, you must
not assign the invoicing function INV_BILL_DOC to the invoicing process.
If you select collective bills, you have to assign the invoicing function INV_COLLBILL.
If you select SD documents, you have to assign the invoicing function INV_SD_DOC.
If you select open posting items to be activated, you have to assign the invoicing function
ACTIVATE_OI.
If you select single invoicing documents of an invoicing list, you have to assign the
invoicing function SUBINV_LIST.
If you select source documents of the source document category CYCLE, you have to
assign the invoicing function Invoice Additional Periodic Source Documents INV_CYCLE.
The invoicing function REVERSAL is also mandatory, since it is required for reversals.

(C) SAP AG

123

Activation/Deactivation of Invoicing Functions

Use
As the examples above have shown, you can make the performance dependent on the
composition of the invoicing unit using invoicing functions that can be activated/deactivated.
These functions also allow the user to make an individual selection in dialog.

Features
From a technical point of view, you can define that all functions can be activated/deactivated, with
the exception of the mandatory functions listed above. Whether or not this is useful depends on
your business requirements. It is particularly useful for the following functions:
ACCT_MAINT
HIST_ITEMS
INTEREST_DEB
INTEREST_SEC
CHARGE_DISC
For example, you can fulfill the following business requirements with a function
that you can activate/deactivate.
Use the invoicing category of the contract account to differentiate between
residential customers and industry customers. For residential customers you
require automatic account maintenance. However, for industrial customers,
account maintenance is to be carried out manually by clerks.
You use different invoicing types to differentiate between periodic billing and
unscheduled interim billing. There is to be no automatic account
maintenance for interim billing.
In expert mode, the clerk should be able to activate or deactivate automatic
account maintenance for residential customers.

Example
...

A residential customer has a credit memo as a result of the adjustment to the last invoice. This
credit memo was offset against the receivables in the new invoice.
The customer calls and requests the credit memo be paid out. The current invoice is due for
payment on the new due date.
The clerk reverses the current invoice and invoices it again in expert mode. To do this, he has to
deactivate automatic account maintenance.
1. To do this, in the Implementation Guide for Contract Accounts Receivable and Payable,
choose Integration
Invoicing in Contract Accounts Receivable and Payable
Invoicing
Invoicing Processes.
2. In the definition of the invoicing process in the activity Define Invoicing Processes, define
that the function ACCT_MAINT can be activated/deactivated.
3. In the definition of the invoicing types in the activity Define Invoicing Types, choose the
following settings:

(C) SAP AG

124

Invoicing Type

Invoicing Category

Activation Status

Periodic

Residential Customer

Active, deactivate in dialog

Interim

Residential Customer

Not active, activate in dialog

Customer-Defined Invoicing Functions

Use
You can also define your own invoicing functions and assign them to invoicing processes or
invoicing types.

Activities
You define own invoicing functions in the Implementation Guide for Contract Accounts
Receivable and Payable under Integration
Invoicing in Contract Accounts Receivable and
Payable Program Enhancements
Add Invoicing Functions.
Note that the SAP standard does not perform installation-specific invoicing functions. You have to
provide the call by implementing an event. At the place where you implement the call, you must
first check whether the function is active. To do this, call the function module
FKK_INV_FUNCTION_ACTIVE_CHECK. The function module exports an indicator that is set
when the invoicing function is active.
SAP recommends that you only define your own invoicing functions if you want to use the options
for activating/deactivating as described above. Otherwise it is sufficient to call customer-defined
program enhancements directly and you therefore do not need to define the invoicing function.

Data Selection
Purpose
In data selection, the invoicing orders are selected for the invoicing process. You define the
selection rules in the Selection Control in the configuration of an invoicing process in the IMG.

Invoicing Orders
Definition
Temporary data record in the transparent table DFKKINV_TRIG that represents a source
document that has not been invoiced yet (for example, billing document, SD document).

Use
An invoicing order enables you to specifically select the source document in the invoicing process
and it is deleted once the source document has been successfully invoiced.

(C) SAP AG

125

You can only invoice a contract account if there is at least one invoicing order for the contract
account.
Invoicing orders are created at different times and by different processes dependent on the
source documents to be processed:
On the transfer or creation of billing documents
On creation of the billing document request, that is, on the transfer of the SD billing
document to accounting
In invoicing processes that process contract accounts that belong to a collective bill
The invoicing orders are uniquely indicated by the source document number and source
document category, whereby the following values are permitted for the source document
category characteristic:
INVBI Billing Documents
Indicates source documents that are created by any SAP systems or systems from
other providers and that are transferred to Invoicing in Contract Accounts
Receivable and Payable by means of a defined interface
VBRK SD Billing Document
Indicates source documents created by the component Sales and Distribution (SD)
and to be posted or processed into an invoice in Invoicing in Contract Accounts
Receivable and Payable.
SD SD Documents (FI-CA Sample Document)
Indicates FI-CA sample documents created by the component Sales and
Distribution (SD) and to be posted or processed into an invoice in Invoicing in
Contract Accounts Receivable and Payable.
COLBI Collective Bill Documents
Indicates source documents created during invoicing of the individual accounts of a
collective bill.
ACTIT Open Posting Item to Be Activated
Open item posted before invoicing and that has a special clearing restriction and
that is to be requested by invoicing.
SUBIN Single Invoicing Document of an Invoicing List
Invoicing document that is to be entered in an invoicing list.
CYCLE Periodic Invoicing
Invoicing order that was created by scheduling.
ADHOC Ad-hoc Invoicing
Invoicing order for creation of ad-hoc invoicing when there are no source documents
to be invoiced.
During the reversal of an invoicing document, invoicing orders are created
again for the source documents processed in this invoicing document.
The source document category contains information about the technical makeup of the source
document and where it is stored. You can use the source document type to differentiate among
the source documents of a source document category according to their business significance.

(C) SAP AG

126

Structure
Invoicing orders contain the following information:
General data that enables targeted and fast selection, such as the key of the relevant
contract account and business partner and reference details from the contract, division,
company code
An indicator (Control of Invoicing Unit SEPARATE_INV) that defines whether a source
document may be invoiced with other documents
An earliest date of invoicing (field INVOICE_FIRST) that prevents the processing of the
source documents until the document date for invoicing has reached the date specified
A due date for the selection of the invoicing orders (field FAEDN_SEL), provided this is
known for the source document to be invoiced, for example, for collective bills
The document number of the last invoicing of the source document (field
INVDOCNO_OLD); this specifies the reversed invoicing document that was last used to
invoice a source document to be invoiced.
The field can be used during invoicing when invoicing units are created; for example, if you
want only source documents that were originally in one joint invoicing document to be
covered when you invoice the invoicing document again.
This data is stored in the transparent table DFKKINV_TRIG under the number of the
source document and the source document category that make up the key.
In addition to the fields relevant for selection, the invoicing order also contains
information that controls the creation of the invoicing units.
Therefore, to improve the performance of invoicing, it can make sense to add
additional customer-specific fields used in creating invoicing units to the invoicing
order using a CI include and to fill these fields when the invoicing order is written.

Selection Control
Use
In the definition of the invoicing process, you define in Customizing which source document
categories are processed in the invoicing process.

Activities
If, for example, you want to perform invoicing runs that process exclusively billing documents, and
separate invoicing runs that only process collective bills, define one invoicing process that selects
only source documents of the category "Billing Document", and a further process that selects only
collective bills.
At the same time, for the selection of the source document categories, you can define whether
source documents of this category in the process defined can trigger invoicing of the contract
account, or whether the source documents can only be invoiced together with source documents
of other categories. You control this using the Main Selection indicator. Therefore, a contract
account only qualifies for invoicing in the mass process if, among the invoicing orders, there is at
least one source document of the source document category selected with the indicator Main
Selection.

(C) SAP AG

127

The system only interprets the Main Selection indicator in the mass invoicing
process in Invoicing in Contract Accounts Receivable and Payable during the
determination of the contract accounts to be invoiced.
Individual invoicing does not consider this indicator. All source documents of a
contract account can be invoiced that have a source document category that is
processed by the underlying invoicing process.
The following figure explains the influence of the Main Selection indicator on the determination of
the contract accounts to be invoiced in the mass process of Invoicing in Contract Accounts
Receivable and Payable:
Invoicing Orders

Contract
Account V1

Source Document
Category INVBI
Source Document
Category SD

Selection Control

Process

Source Doc.
Category

Main Selection
Indicator

01

INVBI

01

SD

02

SD

03

COLBI

Invoicing Process 01
General Selections: Contract Account V1 V2
Contract account V1 is processed
Invoicing Process 02
General Selections: Contract Account V1 V1

Contract
Account V2

Source Document
Category SD

Contract account V1 is processed

Invoicing Process 02
General Selections: Contract Account V1 V2
Contract accounts V1 and V2 are processed
Invoicing Process 03
General Selections: Contract Account V1 V2
Neither contract account V1 nor V2 is processed

Creating Invoicing Units

Purpose
If more than one source document is processed during the invoicing of a contract account, the
question arises as to how many invoicing documents are to be created. If there are two source
documents for one contract account, these can be grouped in one invoice, or two independent
invoices can be created.
Invoicing in Contract Accounts Receivable and Payable decides this question by creating
invoicing units. Each invoice leads to a separate invoicing document and thus to a separate
invoice. If there are several source documents for a contract account, using a multilevel
procedure, the system defines which source documents are grouped in an invoicing unit and how
many invoicing units are created.

Process Flow
Step 1
(C) SAP AG

128

The system groups all source documents that have the same properties:
Contract account
Business partner
For source documents of the category Collective Bill, the due date must also agree. Source
documents where the value in one of these fields does not agree cannot be grouped in one
invoicing unit.
Then the value of the Control of Invoicing Unit field is considered:
If the invoicing unit control has the value 0 Do not invoice document with other document,
the document is assigned to a separate invoicing unit.
If the invoicing unit control has the value 1 Only invoice document together with other
document, the system checks whether the current invoicing unit contains a further
document with the value SPACE No Restriction. If there is no such document, the
document with value 1 is not assigned to an invoicing unit. It is only invoiced if it is
subsequently assigned to an invoicing unit in step 3 (see below).
Step 2
The system determines the grouping variant. In Customizing for Contract Accounts Receivable
and Payable, in the activity Define Invoicing Processes, you can define which grouping variant is
to be used dependent on the invoicing category and invoicing process (see subdialog Alternative
Grouping Variant).
If no alternative grouping variant has been maintained, the system uses the grouping variant
defined in the invoicing process.
If no grouping variant is maintained there either, the second step is not carried out. This means
that where there is no grouping variant, there is a maximum grouping of source documents and a
minimum number of invoicing documents. This also applies for the case where a grouping variant
is used, but no grouping characteristics and rules are assigned to the variant.
If the system can determine a grouping variant with rules, these rules are applied and split the
invoicing units created in the first step further. For details of how to use these rules, see the
examples below.
Step 3
Event 2601 is processed. There, using a customer-defined implementation, you can split the
invoicing units further or group them.
Step 4
If you run the invoicing transaction in dialog, and use the expert mode, in a fourth step, the
invoicing units created so far appear in a dialog box for selection. There you can change the
assignment of source documents to invoicing units manually.
You can test the system settings of the grouping variants and the
implementation of event 2601 in expert mode in Invoicing in Contract Accounts
Receivable and Payable.

Notes and Examples for Configuring Grouping

Variants
...

(C) SAP AG

129

At the time of invoicing, for each source document there is a related invoicing order. The rules
defined in the grouping variants refer to specific fields of these invoicing orders. In the definition of
the grouping variants, you must therefore first specify the fields that you want to use for the
subsequent rules.
In addition to the fields of the invoicing order (that is, structure FKKINV_TRIG), you can also
specify your own customer fields as grouping fields. For your own fields, you have to define a
function module that provides the field with a value. For performance reasons, you should avoid
database accesses as far as possible in the function module. If you feel that an important field for
creating invoicing units is missing in the invoicing order, you may find it useful to include it in the
customer include CI_FKKINV_TRIG.
Example
1. In Customizing for Contract Accounts Receivable and Payable, choose Integration
Invoicing in Contract Accounts Receivable and Payable
Invoicing
Invoicing
Processes
Maintain Grouping Variants.
2. You want to make it dependent on the company code whether or not source documents
are grouped in an invoicing unit. Therefore, you configure the grouping characteristic
BUKRS (company code). You do not have to specify a function module, since the value is
adopted from the invoicing order.
3. Define the field PERIOD and assign a function module to this field (field does not belong to
an invoicing order). From the start and end of the document period (fields DATE_FROM
and DATE_TO in the invoicing order), the function module determines a period consisting
of month and year. This period can be used for the subsequent rules.
4. In the next step you configure the grouping variants. Define a key and enter a short text.
5. In the subdialog that follows, configure all grouping characteristics that you want to use in
this grouping variant. For each grouping characteristic, you have to configure the use of the
characteristic values. The meaning of this use rule is explained in the following examples.
6. If necessary, in the last subdialog, you can maintain alternative characteristic values and
an alternative use.
Case 1
You only want to group source documents in one invoice if the company code and division are
the same.
Configuration of Grouping Variants
Under Maintain Grouping Characteristics, select the following fields:
Grouping Characteristic

Description

BUKRS

Company code

SPART

Division

Function Module

In the subdialog Assign Grouping Characteristics, you make the following entries.
Grouping Characteristic

Rank

Use

BUKRS

Use Original Field Value if No

Alternative Value Defined

SPART

Use Original Field Value if No

Alternative Value Defined

(C) SAP AG

130

You do not have to configure anything in the subdialog Assign Alternative Grouping Values.
Invoicing
The following figure shows the creation of invoicing units during invoicing of a contract account for
which there are five billing documents with the same currency and properties displayed:
Configuration of Grouping Variant
Grouping Characteristics:
Company Code
Division
Fields of Invoicing Order
(FKKINV_TRIG)

Creation of Invoicing
Units

Src.
Doc.

Company
Code

Division

Char. 1

Char. 2

Src.
Doc.

Invoicing
Unit

10001

0001

0001

10001

10002

0001

0001

10002

10003

0002

0002

10003

10004

0003

0003

10004

10005

0003

0003

10005

With this grouping variant, billing documents are only grouped in one invoicing unit if they use the
same company code and the same division. In the example, this is only the case for billing
documents 100004 and 100005.
Example 2
You only want to group source documents in one invoice if they have the same company code
and division with the exception of documents with company code 0002. These documents are
to be grouped in one invoice with documents from company code 0001.
Configuration of Grouping Variants
You configure the grouping variants as in example 1. In addition, in the subdialog Alternative
Grouping Values for Grouping Characteristic Company Code, configure the following entry:
Characteristic

Characteristic Value

Alternative Use

Alternative Value

BUKRS

0001

Characteristic value
corresponds to

0001

Invoicing
The following figure shows the creation of invoicing units during the invoicing of the contract
account from example 1.

(C) SAP AG

131

Configuration of Grouping Variant

Alternative Grouping Values for Grouping

Characteristic Company Code

Grouping Characteristics:

Val.

Alternative Value

Company Code

0002

0001

Division
Fields of Invoicing Order
(FKKINV_TRIG)

Creation of Invoicing
Units

Src.
Doc.

Company
Code

Division

Char. 1

Char. 2

Src.
Doc.

Invoicing
Unit

10001

0001

0001

10001

10002

0001

0001

10002

10003

0002

0001

10003

10004

0003

0003

10004

10005

0003

0003

10005

With this grouping variant, billing documents 100001 and 100003 are grouped in one invoicing
unit since in billing document 100003, company code 0002 is replaced with company code 0001.
This only applies for the creation of the invoicing units and not for the subsequent processing of
document 100003.
For further examples of the creation of invoicing units, see the documentation for configuring
grouping variants in Customizing for Contract Accounts Receivable and Payable.

Event 2601
Definition
In the function module processed for event 2601 Grouping of Invoicing Orders to Invoicing Units,
you can override the composition of the invoicing units proposed by the invoicing program.

Use
Table C_INVTRIG_2601_TAB for invoicing orders is transferred at the interface. In the field
Number of Invoicing Unit (INV_UNIT_NO_2601), these invoicing orders contain a proposal for the
creation of invoicing units. This field is not set in the invoicing orders that are not to be considered
in the current invoicing run.
If several invoicing units are to be invoiced in the current invoicing run for a contract account,
these are processed in the sort sequence of their internal invoicing unit number. In the standard
system, if invoicing for one of these units terminates, the processing of the next invoicing units for
the contract account continues.
If this system behavior is not required, you can set the indicator Grouping Key for Invoicing Units
(INV_UNIT_GR_2601) to group invoicing units that belong together logically in order to optimize
error handling. Assign a joint grouping value to the invoicing units that belong together logically. If

(C) SAP AG

132

the processing of an invoicing unit terminates, the following invoicing units of this group are not
invoiced.
Note that the grouping within an invoicing unit must be unique.

Selection of Open Items

Use
Some of the invoicing functions integrated in an invoicing process process the open items posted
before invoicing.

Features
As standard, the invoicing program provides all open items of the contract account to be invoiced
and the related business partner, whereby invoicing-related clearing restrictions (for example, 2,
7, 8, I) are considered automatically.
In some applications, however, it may make sense to restrict this selection - dependent on the
composition of the invoicing unit and the invoicing functions integrated in Invoicing in Contract
Accounts Receivable and Payable for example, by selecting only items with a reference to the
contracts to be processed during invoicing.
By restricting the selection, you can improve the transparency of the invoicing process and the
performance of the invoicing run.
In the modules processed for event 2605, you can influence the scope of the open items to be
selected during invoicing.
The invoicing parameters and information about the composition of the invoicing unit are
transferred to the program.
The program expects table C_SELTAB to be returned with selections. However, the creation of
the selections for the contract account and business partner is not necessary at this point the
invoicing program does this automatically.
You can also return the clearing restrictions to be considered in the selection in table
C_AGRTAB.

Example
In the invoicing unit, billing documents for contracts (VTREF) 4711 and 4712 are processed.
During invoicing, only open items for these contracts are to be selected. Therefore, return the
following selection in C_SELTAB:
SELNR

SELFN

SELCU

0001

VTREF

4711

0002

VTREF

4712

SELCO

You also want to select items without contract reference. Therefore, return the following values in
C_SELTAB:
SELNR

SELFN

SELCU

0001

VTREF

4711

0002

VTREF

4712

(C) SAP AG

SELCO

133

0003

VTREF

You want to select items as above, but only those that are due within the next 14 days, based on
the invoicing document date. If the document date is June 5, 2005, return the following values in
C_SELTAB:
SELNR

SELFN

SELCU

0001

VTREF

4711

0001

FAEDN

0002

VTREF

0002

FAEDN

0003

VTREF

0003

FAEDN

SELCO

20050619
4712
20050619

20060619

Note that different numbers in SELFNR represent an OR link between the

selection criteria; the same number indicates an AND link.

Documents
Definition
The following sections contain information about the documents created in the invoicing process.

Invoicing Documents
Definition
The successful processing of an invoicing unit in an invoicing process leads to the creation of an
invoicing document. The invoicing document stores information required for printing an invoice
and is therefore the basis for invoicing printing that, due to this data retention, can be decoupled
and performed as a downstream process. The invoicing document also documents the invoicing
process, retains data for subsequent processes, such as invoicing reversal, and saves data for
display and evaluation.

Structure
In particular, the invoicing document provides information about:
The invoice data provided to the customer (for example, invoice number, invoice due date,
invoice amount)
How the invoice for a contract account arose (for example, invoicing process, invoicing
type and category, time of creation)
The processing mode in which invoicing was performed (simulated, posted, reversed)

(C) SAP AG

134

Which source documents were processed in an invoicing unit and were therefore grouped
to one invoice
How the individual source documents were processed in the invoicing process for the
invoice display and in accounting
Which further invoicing items were displayed on the invoice and processed in accounting
(for example, tax items, items from additional information)
Which posting documents were created or processed in an invoice and what their business
meaning is from the view of the invoicing document
You cannot delete real (not simulated) invoicing documents. If the content of a billing document is
not correct, it can be reversed. During the reversal, a reversal invoicing document is created. The
posting documents created during invoicing are reversed within the program with a document
reversal from FI-CA. You can the invoice the source documents again.
Invoicing documents are simulation documents if the invoicing process that creates them was
started in simulation mode. Simulation documents have no influence on the subsequent update
run of the invoicing process; specifically, when you create simulation documents there are no
postings in FI-CA. Simulations are used for check and test purposes. You cannot reverse the
simulation documents.

DDIC Structures and Layer Model

For invoicing documents, in relation to the ABAP Dictionary (DDIC), a distinction is made
between the following layers:
Database layer
Logical layer
Display layer
In the database layer, the invoicing documents are stored in the six transparent tables named in
the previous section. The database tables are only used for updates or in access modules. In the
invoicing program, the invoicing documents are managed in logical tables. Additional display
structures are available for the display functions.
The following table gives an overview of the DDIC structures of the individual layers for the
individual components of the invoicing document:
Component

Database Layer

Logical Layer

Display Layer

Header

DFKKINVDOC_H

FKKINVDOC_H

FKKINVDOC_H_DISP

Items

DFKKINVDOC_I

FKKINVDOC_I

FKKINVDOC_I_DISP

Reference Posting Document

DFKKINVDOC_P

FKKINVDOC_P

FKKINVDOC_P_DISP

Source Document History

DFKKINVDOC_S

FKKINVDOC_S

FKKINVDOC_S_DISP

(C) SAP AG

135

Offsetting Items

DFKKINVDOC_O

FKKINVDOC_O

Reversal Data

DFKKINVDOC_R

Charges/Discounts

DFKKINVDOC_C

Charge/Discount History

DFKKINVDOC_CH FKKINVDOC_CH

FKKINVDOC_C

If you want to read an invoicing document from the database, you can use function module
FKK_INVDOC_SELECT_SINGLE from function group FKKINV_DB_INVDOC, for example. This
reads an invoicing document from the database and converts it into the structures of the logical
layer.
The structures of the display layer are almost identical to those of the logical layer. They contain
an additional customer include with which you can add additional fields for the display.
You can add additional display fields to the display structure of the invoicing document items
FKKINVDOC_I_DISP using the include CI_FKKINVDOC_I_DISP. This enhancement does not
affect the database layer or the logical layer. You must fill the fields of the customer include in an
implementation of event 2676.

Reversal Data
0..1
1

Invoicing Document 1..*

Item

Invoicing Document 1
Header

S_Include Telco

S_Include Telco

S_Include Industry

S_Include Industry

C_Include

C_Include

1..*

Invoicing/Reversal
History

Offsetting
Item

1..*

*
*

Reference Table of
Posting Document

0..1

Charges and
Discounts

Charges /Discounts
History

S_Include Telco
S_Include Industry
C_Include

Structure of Invoicing Documents

(C) SAP AG

136

Invoicing Document Headers

Definition
Contain information that is valid for all line items of an invoicing document equally

Structure
The header contains the following general data:
The key of the relevant contract account and the business partner
Invoicing process, category, and type as well as further data required for creating
documents (for example, date of creation, mode of creation)
Posting parameters
Various indicators or data that reflect the processing status (for example, posted,
simulated, print date, number of reversal document)
This data is stored in the transparent table DFKKINVDOC_H under the number of the invoicing
document as the key.

Invoicing Document Items

Definition
For each invoicing document there are one or more invoicing document items.

Structure
Invoicing document items contain the following fields, among others:
Type of invoicing item (field ITEMTYPE)
This describes the business meaning of the line items, makes the invoicing document
easier to read, and is used in invoice printing. In addition to numerous invoicing item types
that SAP delivers and that the invoicing program uses, you can also define invoicing item
types in the customer namespace and use them to create additional customer-specific
documents when you create your own invoicing document items, for example, in event
2650.
Invoicing function (field INV_FUNCTION) that creates the invoicing document item
Category and number of the source document or source document item (fields
SRCDOCCAT, SRCDOCNO, SRCITEMCAT, SRCDOCITEM)
These uniquely identify the original item to which the invoicing document item relates.
Fields for linking invoicing document items that are relevant for posting with the posting
documents or line items derived from them. These are:
Reference document type of the posting document for invoicing (field
CADOCTYPE; see Reference Table for Posting Documents [Seite 138])
Number of FI-CA document (field OPBEL; see Reference Table for Posting
Documents [Seite 138])
Grouping key for line items (field PSGRP)

(C) SAP AG

137

This grouping key is assigned internally during the invoicing of billing documents
and is used to link invoicing items with the business partner items of an FI-CA
document. Using the grouping key, you can see, for example, the receivables
account to which an invoicing item (and the related billing item) was posted in the
general ledger. The grouping key also links the business partner items with the
related G/L items.
Grouping key for invoicing (field INVGR)
This grouping key is assigned internally during invoicing of billing documents and is
used to link invoicing items with the general ledger items of an FI-CA document.
Using this grouping key, you can see, for example, the general ledger/CO/FM
account assignments with which an invoicing item (and the related billing item) was
posted in General Ledger Accounting, Controlling, or Funds Management.
Amounts and quantities
Tax information
Indicators for posting-relevant, print-relevant, simulated
This data is stored in the transparent table DFKKINVDOC_I under the number of the invoicing
document and the sequential number of the line item.

Reference Table of Posting Documents

Definition
An invoicing document can reference to one or more posting documents created or processed by
different invoicing functions in the invoicing process. This reference to posting documents is
stored in the transparent table DFKKINVDOC_P under the number of the invoicing document and
a sequential number.

Structure
The reference table contains:
Document and item number or repetition item number of the posting document
Reference document type of the posting document (field CADOCTYPE) this describes
the business meaning of the document from the view of Invoicing in Contract Accounts
Receivable and Payable.
In addition to numerous reference document types that SAP delivers and that the invoicing
program uses, you can also define reference document types with special use in the
customer namespace and use them to create additional customer-specific documents
when you create your own posting document, for example, in event 2650.
The reference document type controls whether the posting document can be reversed with
a reversal from Contract Accounts Receivable and Payable or only with an invoicing
reversal.
An indicator (field XNEWDOC) that states that the document has been posted in Invoicing.

(C) SAP AG

138

Invoicing and Reversal History Source Documents

Definition
For each invoicing document, the source documents processed in the invoicing process are
stored in a separate, transparent table (DFKKINVDOC_S).

Structure
In addition to the number of the invoicing document, the source document number and category
are keys of this table; the data part contains some information about the invoicing document or
reversal invoicing document:
Indication that the document is posted or simulated
Number of the document that reversed the invoicing document or the number of the
reversed invoicing document
This data design supports the recording of an invoicing and reversal history for the source
documents and fast access to the history.

Reversal Data for Invoicing Document

The system manages additional reversal information for each reversed invoicing document.

Features
The transparent table DFKKINVDOC_R contains additional reversal information for the invoicing
document, such as the reversal reason or the reversal date.

Charges and Discounts for Invoicing Documents

Definition
If the function Charges and Discounts or Individual Charges and Discounts is active in the
invoicing process and you calculate charges and discounts, the system stores additional
information about charges and discounts for the invoicing document.

Structure
The transparent table DFKKINVDOC_C stores the following data for the charges item posted in
the invoicing process:
Charge key (field CHGKEY) used to define the rules for determining the charges and
discounts
Base amount (field BASAMT) for calculating charges and discounts
Charge and discount amount (field CHGAMT)
A period that the charge/discount refers to (fields DATE_FROM, DATE_TO)

(C) SAP AG

139

An indicator that individual history records are recorded (field CHGHIST, see History
Records for Charges and Discounts in Invoicing Documents [Seite 140])
If charges or discount items have been entered for an invoicing document, this is noted in the
invoicing document header (field DFKKINVDOC_H-CHGDOC_EX).

History Records for Charges and Discounts in

Invoicing Document
Definition
In Customizing of the definition of the charge and discount key used for determining charges and
discounts, you can define whether history records are to be entered for the line items used for
calculating the base amount for the charge/discount determination.

Structure
If history records are entered, for the charges item calculated and posted in the invoicing
document, the invoicing items used for calculating the base amount are saved under a sequential
number in the transparent table DFKKINVDOC_CH. The recording of these items enables you to
evaluate the history of charges and discounts levied on original document items.
If individual history records are entered and available for each original document, this is noted in
the charges and discounts of the invoicing document.
Invoicing Document Database Layer

(C) SAP AG

140

Invoicing Document
Header

Invoicing Document
Item
DFKKINVDOC_I
MANDT
INVDOCNO
INVDOCITEM

1..*

1..*

DFKKINVDOC_S
MANDT
SRCDOCCAT
SRCDOCNO
INVDOCNO

DFKKINVDOC_H
MANDT
INVDOCNO

CHGDOC_EX =

Invoicing
Reversal History

*
*
Charges/Discounts
History
DFKKINVDOC_CH
MANDT
INVDOCNO
OPBEL
OPUPK
CONSNO

Reference Table for

Posting Document

1
Charges/Discounts

1..*

DFKKINVDOC_C
MANDT
INVDOCNO
OPBEL
OPUPK

DFKKINVDOC_P
MANDT
INVDOCNO
CONSNO

Offsetting Items of Invoicing Document

If the function Offsetting in Invoicing is active in the invoicing process, and offsetting was either
preselected or cleared, then the system stores additional information about offsetting for the
invoicing document.

Structure
The system stores the following data (in addition to other data) in transparent table
DFKKINVDOC_O for the offsetting item that was preselected or cleared:
Offsetting reference key (field OFFSET_REFID)
The key, together with the offsetting category, uniquely identifies a preselected offsetting
(for example, an offsetting item for the period of March).
Offsetting category (field OFFSET_CAT)

(C) SAP AG

141

The offsetting category, together with the offsetting reference key, uniquely identifies a
preselection and controls the offsetting in Invoicing in Contract Accounts Receivable and
Payable.
Offsetting procedure (field OFFSET_PROC)
The offsetting procedure specifies the posting logic and offsetting logic in Invoicing in
Contract Accounts Receivable and Payable.
Grouping of offsetting items (field OFFSET_INVGR)
The grouping links items that should be offset against one another in Invoicing in
Contract Accounts Receivable and Payable.
Status of offsetting processing (field OFFSET_STATUS)
The status specifies if offsetting is preselected, or if an existing offsetting is cleared.
Number of the invoicing document with which the offsetting was preselected (field
INVDOCNO_REQ)
A time period that the offsetting relates to (for example, budget billing time period; fields
DATE_FROM_REQ and DATE_TO_REQ)
Reference to the FI-CA posting document of the preselected offsetting (fields
OPBEL_REQ, OPUPW_REQ and OPUPK_REQ).

Reversal Data
DFKKINVDOC_R
MANDT
INVDOCNO

Invoicing/Reversal
History

0..1
1

Invoicing Document
Item
DFKKINVDOC_I
MANDT
INVDOCNO
INVDOCITEM

1..*

Invoicing Document 1
Header
1

1..*

DFKKINVDOC_H
MANDT
INVDOCNO

CHGDOC_EX = 2

1*

DFKKINVDOC_S
MANDT
SRCDOCCAT
SRCDOCNO
INVDOCNO

1
1

1
*

DFKKINVDOC_P
MANDT
INVDOCNO
CONSNO

1.

Offsetting Item

Charges/Discounts

DFKKINVDOC_O
MANDT
INVDOCNO
INVDOCOITEM

DFKKINVDOC_C
MANDT
INVDOCNO
OPBEL
OPUPK

Reference Table
Posting Document

1
*

Charges/Discounts
History
DFKKINVDOC_CH
MANDT
INVDOCNO
OPBEL
OPUPK
CONSNO

Database View of Invoicing Document

(C) SAP AG

142

Enhancements to the Invoicing Document

Use
In events 2645 and 2611 you can make customer-specific enhancements to the invoicing
document.

Features
Event 2645
In event 2645, you can provide the customer-defined fields of the invoicing document with data at
the time of invoicing. In the function modules processed for this event, you can fill the customerdefined fields of all enhanceable parts of the invoicing document. At this event, the individual
process steps of invoicing up to the update have run in the invoicing program, the invoicing
document and the posting documents have been created, but not yet posted.
The complete invoicing document is provided on the interface. In this document, you can change
all fields included in the customer include and some standard fields of the invoicing document
header, such as the fields for the period identification of the invoicing document.
Event 2611
To add data to the invoicing document from the billing document data, you can use event 2611.
This event is processed on creation of the invoicing and posting documents for a billing document
FKKINVBILL in the invoicing program. Data can be provided for the customer-specific fields of the
invoicing and posting document (for example, information from the billing document) in the
function modules called for this event.
In addition, in this event replace the type of invoicing item in the invoicing items with your own
value. The new value must be in the customer namespace.

Document Number Assignment and Document Type

Use
The invoicing document number is the key that uniquely identifies an invoicing document per
client.
The invoicing document numbers are numerical and are determined internally. External number
assignment is not supported. Within a number range, the numbering of invoicing documents is
sequential and has no gaps.

Features
For the document number assignment of the invoicing documents, perform the following activities
in the Implementation Guide for Contract Accounts Receivable and Payable under Integration
Invoicing in Contract Accounts Receivable and Payable Invoicing
Document Account
Assignment Invoicing Documents:
...

Firstly, in the activity Maintain Number Ranges for Invoicing, maintain the number ranges for
Invoicing in Contract Accounts Receivable and Payable by specifying intervals with upper
and lower limits for the number range object Invoicing Documents FKKINVDOC.
The number assignment differentiates between individual processing and mass
processing. The naming convention for the number ranges for individual processing is

(C) SAP AG

143

numerical; the naming convention for the number ranges for mass processing is not
numerical. For individual processing, one number range is sufficient; in mass processing,
invoicing documents can be created in parallel in several processes. Therefore, define as
many number ranges (per document type) as you need in parallel invoicing processes.
The document type controls the document number assignment of the invoicing documents.
You assign one or more number ranges to the document type. The document type
classifies the invoicing documents; it is determined in the invoicing process and saved in
the invoicing document header (field DOCTYPE).
In the activity Maintain Document Types and Assign Number Ranges, define the document
types for invoicing documents and in the subdialog, assign the number ranges for
individual and for mass processing to the document types.
Define the determination of the document types for invoicing documents by defining
document types for invoicing documents. As standard, the determination is per invoicing
process. However, you can differentiate this further by invoicing type and invoicing
category.
You can use the same document type for all invoicing documents. However, we
recommend that you use different document types for real and for simulated
invoicing documents and assign different number ranges to these document types.
We also recommend using separate document types and number ranges for the
reversal documents.

Posting Documents
Definition
Invoicing functions in an invoicing process can create one or more posting documents.
The invoicing function Invoicing Billing Documents derives postings in FI-CA
from the billing data. These postings are saved in the form of posting documents
and can therefore be displayed in the system.

Structure
In FI-CA, the system stores a posting document under a unique document number. The
document consists of header data, items for contract accounts, and items for G/L accounts:
The system stores this data uniquely in the document header in table DFKKKO. Two separate
tables are selected for the line items:
DFKKOP contains the items for the subledger.
DFKKOPK contains the items for the general ledger.
The posting documents created in Invoicing in Contract Accounts Receivable and Payable are
linked with the invoicing document by means of the reference table DFKKINVDOC_P (see
Reference Table for Posting Documents [Seite 138]).
Structure of Posting Document and Link to Invoicing Document

(C) SAP AG

144

Posting Document

BP Item
(DFKKOP)

1..*

Invoicing Document

Posting Doc.
Header
(DFKKKO)

S_Include Telco

S_Include Telco

S_Include Industry

S_Include Industry

C_Include

C_Include
1
1..*

Reference Table
Posting Document
DFKKINVDOC_P
MANDT
INVDOCNO
CONSNO

G/L Item
(DFKKOPK)
S_Include Telco
S_Include Industry
C_Include

Document Number Assignment and Document Type

Use
In the system, each posting document is stored under a unique document number. The
assignment of the number is controlled using the document types that classify the documents of
Contract Accounts Receivable and Payable (FI-CA).

Features
Invoicing in Contract Accounts Receivable and Payable creates posting documents in different
invoicing functions. These documents are classified in the context of the invoicing document by
the reference document types (CADOCTYPE) that describe the business meaning of the posting
document (for example, interest document, account maintenance document). In Customizing, you
assign the document types for creating the posting documents to these reference document
types. This enables you, for example, to reserve a specific number range only for documents
from a specific invoicing function.

Activities
For the document number assignment of posting documents in Invoicing, perform the following
activities: In the Implementation Guide for Contract Accounts Receivable and Payable, choose:
...

Basic Functions
Postings and Documents
Basic Settings
Maintain Document
Number Ranges and maintaiin the document number ranges required.
Basic Functions
Postings and Documents
Document Maintain Document Account
Assignments
Document Types and define the document types for posting documents in
Invoicing in Contract Accounts Receivable and Payable, and, in the subdialog, assign
these to the number ranges for individual processing and for mass processing.

(C) SAP AG

145

Integration
Invoicing in Contract Accounts Receivable and Payable
Invoicing
Document Account Assignment Posting Documents Define Document Types for
Posting Documents from Invoicing and assign document types from FI-CA to the posting
documents.
As standard, the assignment is per invoicing process and reference document type.
However, you can differentiate further by invoicing type and invoicing category.

Functions of Invoicing in Contract Accounts

Receivable and Payable
Use
Invoicing in Contract Accounts Receivable and Payable (FI-CA) enables you to invoice source
documents from different source document categories (for example, documents from external
billing systems, SD documents). It integrates a series of business transactions from FI-CA (for
example, interest calculation, account maintenance) that are performed during invoice creation.
These functions are described in more detail in the following sections.

Invoicing of Billing Documents

Use
The invoicing function Invoicing of Billing Documents processes documents of the source
document category INVBI Billing Document.

Features
The billing results are included in the invoicing document; postings in FI-CA are derived from the
billing data.
The tax can be determined during invoicing for the billing document (optional).
An invoicing history is updated for the billing document processed.
You can process several billing documents in one invoicing document. As standard, one joint
posting document is posted for all of these billing documents. Alternatively, in the configuration for
the invoicing process, you can configure that a separate posting document is posted for each
billing document. In event 2610, you can also define:
The order in which the billing documents are to be processed and displayed in the invoice
The billing documents for which a joint posting document is to be created
During processing of a billing document, the invoicing program carries out the following logical
processing steps:
...

1. Creation of invoicing items for the billing document

2. Creation of the business partner items for the posting in FI-CA
3. Creation of the general ledger items for the posting in FI-CA
4. Determination of the tax amounts and the creation of invoicing items for the tax display
The individual processing steps are described in detail in the following sections.
(C) SAP AG

146

Linking the Documents

Use
Linking invoicing documents with invoiced source documents and FI-CA documents posted
during invoicing

Features
The billing documents processed in Invoicing in Contract Accounts Receivable and Payable are
linked with the invoicing document by means of the invoicing history DFKKINVDOC_S with the
source document category SRCDOCCAT = INVBI (Billing Document).
The posting documents created during invoicing of the billing documents are linked with the
invoicing document by means of the reference table (DFKKINVDOC_P) with reference document
type CADOCTYPE = 0BIL (Posting Document for Billing Document).

Transactions
Use
Invoicing of billing documents uses the main and subtransactions for the invoice display and for
controlling the posting of the billing document in Contract Accounts Receivable and Payable (FICA).

Features
Transactions during invoicing serve the following purposes:
Explanation of the billing items on the invoice printout
The main and subtransactions of the billing document items document which billing detail is
the basis for each respective item. During invoicing, the invoicing items created for the
billing document items inherit the main and subtransactions of the billing document items.
An explanatory text is assigned to each main and subtransaction, and you can use this text
in invoice printing.
Automatic determination of the account assignment for the business partner items
From the billing document items relevant for posting (generally, a billing item relevant for
printing is also relevant for posting), the system creates business partner items with the
posting of the invoice receivable or credit memo.
Typically, detailing the business partner items according to the transactions of the billing
document is not required. In this case, you can replace the main and subtransactions of the
billing items with summarization main and subtransactions when you create the business
partner items. This helps you to optimize the number of business partner items. The
receivables or payables accounts are determined based on these summarization
transactions.
Automatic determination of the account assignment for the general ledger items
The system creates general ledger items for the posting document from the billing
document items relevant for posting. The main and subtransactions of the billing items are

(C) SAP AG

147

used for the determination of the G/L accounts (revenues or expenses) and the CO/FM
account assignment.
Main and Subtransactions in Billing Document Items
Billing Item DFKKINVBILL_I

BUKRS

SPART

KOFIZ

HVORG

TVORG

0001

06

01

0300

0010

0001

06

01

0010

0030

0001

06

01

0650

0020

Invoicing Item DFKKINVDOC_I

Posting Area
2612

BUKRS

SPART

KOFIZ

HVORG

TVORG

0001

06

01

0300

0010

0001

06

01

0010

0030

0001

06

01

0650

0020

Business Partner Item DFKKOP

BUKRS SPART

HVORG + TVORG

0001

KOFIZ HVORG TVORG HKONT

06

01

0100

0010

140000

Posting Area
2611

G/L Item DFKKOPK

Posting Area
2610

BUKRS

HKONT

GSBER

KOSTL

PA OBJNR

0001

175000

0001

KS01

0815

0001

175001

0001

KS01

0816

COKEY

TFKCOK

CO Account Assignment

COPAK = X

TFK2610

Derivation of CO-PA
Profitability Segment

Invoicing Items
Definition
Invoicing in Contract Accounts Receivable and Payable processes billing document items that are
indicated as relevant for printing or posting (that is, PRINTREL = X and POSTREL = X). For
every one of these items, the system creates an invoicing document item DFKKINVDOC_I.

Structure
Apart from the amount data, only a small amount of data from the billing document item that is
relevant for the invoicing process flow is transferred, such as company code, division, account
determination characteristic, main and subtransaction. Instead, the invoicing document item
receives a unique reference to the billing document item from which it arose. In subsequent
document processing (for example, invoice printing, BI update), this means that access to the
relevant billing data in particular to the customer fields of the billing document item - is possible
for each invoicing item.
The link is by means of the following fields:
SRCDOCCAT: Category of Source Document To Be Invoiced
SRCDOCNO: Number of Source Document To Be Invoiced
SRCITEMCAT: Category of Source Document Item Invoiced
SRCDOCITEM: Item of Source Document Invoiced

(C) SAP AG

148

The link is according to the following pattern:

DFKKINVDOC_I

Fixed Value

SRCDOCCAT

INVBI

SRCDOCNO

DFKKBILLDOC_I

BILLDOCNO

SRCITEMCAT

BILLI

SRCDOCITEM

BILLDOCITEM

From the billing document items, various indicators (posting-relevant, print-relevant, simulated)
are transferred to the invoicing items.
The amount of the invoicing document item is indicated as relevant for the final invoice amount
(field TOTALREL= X) if:
The related billing document item is not simulated and is indicated as relevant for printing
and posting
The billing document item does not have an initial Substitute Group for Invoice Printing
PRINT_SUBSTITUTE (special case)
For details, see the sections on transferring billing documents. The amount of the invoicing item
relevant for the final invoice amount is considered in the final invoice amount in the header of the
invoicing document.
The invoicing items are indicated with the invoicing item type ITEMTYPE = 0INVBILL (Item of
Billing Document).
You can use event 2610 to provide customer-specific/industry-specific fields of the invoicing item
with data. Here you can also assign own invoicing item types ITEMTYPE to the items. The new
value must be in the customer namespace.
The meaning of further fields of the invoicing item is explained in the following sections in the
context of their use.
The simulated billing items (items with ITEM_SIMULATED X) are treated the
same way as the non-simulated items when the invoicing items are created.
However, the simulated items are not considered in either the final invoice amount
or the posting document. It is displayed in the invoice for information purposes only.
For example, as part of the display of billing results with a different rate that is not
effective for the invoice.

Business Partner Items

Definition
From the non-simulated billing document items relevant for posting (POSTREL = X and
ITEM_SIMULATED <>X), the system creates business partner items (DFKKOP) with the
receivables posting.
The following main and subtransactions can be used in the business partner items:
Corresponding main and subtransaction of the billing document item
Summarization main and subtransaction determined on the basis of the main and
subtransaction of the billing document items

(C) SAP AG

149

Summarization Transaction
Use
Although, in most cases, you need a very differentiated billing display in invoice printing, and a
differentiated revenue and CO account assignment, in the customer account a compact display of
the posting of the invoice receivable is sensible. To achieve this, you can reassign the
transactions for the creation of business partner items from the billing document to an alternative
transaction (summarization transaction). Several billing transactions can be coded to one joint
transaction, thus enabling the creation of one joint business partner item for the relevant billing
document items.

Activities
You can assign the summarization transactions using posting area 2612. In the Implementation
Guide for Contract Accounts Receivable and Payable, choose Integration
Invoicing in Contract
Accounts Receivable and Payable
Invoicing
Document Account Assignment Posting
Documents
Define Summarization Transactions for Business Partner Items.
Maintenance of this activity is optional. If you do not make any entries here, the transactions of
the relevant billing document items are used in the business partner items (= no summarization).
The optional keys of the posting area include the main and subtransaction. This means that you
can assign a summarization main and subtransaction to every main and subtransaction of the
billing item.
You achieve maximum summarization if you do not use the optional keys and in this posting area,
define one main and one subtransaction each for debit and credit postings. All billing document
items are therefore summarized to business partner items with this transaction.
The configuration of the posting area permits a combination between the explicit and the generic
assignment of transactions, for example, if you want to transfer certain transactions of the billing
item to the business partner item and summarize the rest to one joint transaction.

Account Determination
Use
Determination of accounts to be posted to

Features
The receivables accounts for the business partner account assignment are determined uniformly
using posting area 2611 dependent on:
Company code
Division
Account determination ID
Main transaction
Tax code (optional)

(C) SAP AG

150

Access to the posting area is with the main transaction of the business partner item (in most
cases the summarization main transaction).
If you require account determination differentiated by substransactions of the billing document
items, you have to assign different summarization main transactions to these subtransactions.
For each tax on sales and purchases code you have to assign different receivables accounts.
Generally, posting area 2611 corresponds, for example, to the industry-specific
posting areas P000, R000, T000.

Activities
You access the posting area 2611 in the Implementation Guide for Contract Accounts Receivable
and Payable under Integration
Invoicing in Contract Accounts Receivable and Payable
Invoicing
Document Account Assignment Posting Documents
Define Account
Assignment for Business Partner Items.

General Ledger Items

Definition
From the non-simulated billing document items relevant for posting (POSTREL = X and
ITEM_SIMULATED <>X), the system creates general ledger items (DFKKOPK) for the revenue
posting.

Account Determination
Use
Determination of accounts to be posted to

Features
The revenue accounts are determined uniformly using posting area 2610 dependent on:
Company code
Division
Account determination ID
Main transaction
Subtransaction
The access to the posting area is by means of the main and subtransaction of the billing
document item.
Posting area 2610 corresponds, for example, to the industry-specific posting
areas P001, R001, and T001.

(C) SAP AG

151

Activities
You access the posting area in the Implementation Guide for Contract Accounts Receivable and
Payable under Integration
Invoicing in Contract Accounts Receivable and Payable
Invoicing
Document Account Assignment
Posting Documents
Define Account Assignment for
General Ledger Items.

CO Account Assignment
Use
If you use the component Controlling, you have to make the settings for determining the
corresponding CO account assignment.

Features
To forward the invoiced quantities and revenues to the Controlling components, in the general
ledger items in Invoicing, the system notes the relevant CO additional account assignments. The
following account assignments are supported:
Segment
Profit center
Cost center
Order
WBS element
Profitability Segment (CO-PA)
The segment account assignment (SEGMENT) is determined from posting area 0301; all other
account assignments are determined from the CO account assignment key defined in posting
area 2610 (CO account assignment field).
In the CO account assignment key (field COKEY), the respective valid combination of the CO
additional account assignments are encrypted. Using this key, you can also activate the account
assignment to a profitability segment (CO-PA integration). You maintain the CO account
assignment key in the Implementation Guide for Contract Accounts Receivable and Payable
under Basic Functions
Postings and Documents
Document Define Account Assignments
for Automatic Postings
Define CO Account Assignment Key .

Making System Settings for the CO-PA Account

Assignment
Procedure
If you want to update billing document data in Profitability Analysis (CO-PA), you have to activate
Profitability Analysis. In the Implementation Guide for Controlling, see Profitability Analysis
Flows of Actual Values
Activate Profitability Analysis. Activate the controlling areas and
operating concerns for which data is to be updated in CO-PA.

(C) SAP AG

152

You also have to define how the characteristics of the operating concerns are to be provided with
data from the billing document data. You do this in the activity Define CO-PA Characteristic
Derivation in the Implementation Guide for Contract Accounts Receivable and Payable under
Integration
Invoicing in Contract Accounts Receivable and Payable
Invoicing
Document
Account Assignment Posting Documents. Here you assign source fields that are to provide the
data to the characteristics of the operating concern. The source fields are fields from the data
environment of a billing document; they must be included in the structure FKKINV_COPACRIT.
Instead of the source field assignment, in this table you can also define a customer module for
the characteristic that derives the characteristic data from the billing document data and its
environment.
If necessary, you can add your own fields to the structure of the billing
document and provide the characteristics of the operating concern from these fields.
Invoicing in Contract Accounts Receivable and Payable derives the profitability segment for each
billing document item when creating the general ledger item. The derivation takes place if:
There is a cost element for the general ledger account determined (determination via
posting area 2610)
The account assignment to the profitability segment is active in the CO account
assignment key determined (determination via posting area 2610)
For each billing item, in accordance with the settings in the activity Define CO-PA Characteristic
Derivation, values from the billing item and its environment are assigned to the characteristics of
the operating concern and a profitability segment (PAOBJNR) is derived.

Linking the Line Items

Use
To make it possible to track posting transactions, line items are linked.

Features
The system links the billing document, invoicing document, business partner item, and general
ledger item with each other so that, at any time, you can see:
From which billing item an invoicing item arose
With which FI/CO/FM account assignment a billing document item was transferred to the
corresponding components
In the invoicing document items, the link is by means of the following fields:
Fields for linking invoicing document items with the billing document
SRCDOCCAT (Category of Source Document to Be Invoiced)
SRCDOCNO (Number of Source Document to Be Invoiced)
SRCITEMCAT (Category of Source Document Item Invoiced)
SRCDOCITEM (Item of Source Document Invoiced)
Fields for linking invoicing document items with the business partner items
OPBEL (Number of a Document in Contract Accounts Receivable and Payable)
PSGRP (Grouping Key for Line Items)

(C) SAP AG

153

The system assigns the key internally during invoicing. The key provides the link
between invoicing items and business partner items. Using the grouping key, you
can see, for example, the receivables account to which an invoicing item (and the
related billing item) was posted in Financial Accounting. The grouping key also links
the business partner items with the related G/L items.
Fields for linking invoicing document items with the general ledger items
OPBEL (Number of a Document in Contract Accounts Receivable and Payable)
INVGR (Grouping Key for Invoicing)
The system assigns the key internally during invoicing. The key provides the link
between invoicing items and general ledger items. Using this grouping key, you can
see, for example, the general ledger/CO/FM account assignments with which an
invoicing item (and the related billing item) was posted in Financial Accounting,
Controlling, or Funds Management (FI/CO/FM).
Linking the Line Items
Billing Item DFKKINVBILL_I
HVORG BETRAG MENGE

BILLDOCNO

BILLDOCITEM

4711

00001

0300

10.-

4711

00002

0010

17.-

4711

00003

0650

3.-

Billing Item

500,00

Invoicing Item

Invoicing Item DFKKINVDOC_I

INVDOCN
HVORG BETRAG MENGE SRCDOCCAT SRCDOCNO SRCITEMCAT SRCDOCITEM OPBEL
O

081500

0300

10.-

081500

0010

17.-

081500

0650

3.-

500.00

Invoicing Item

INVGR PSGRP

INVBI

4711

BILLI

00001

370001

INV1

GR1

INVBI

4711

BILLI

00002

370001

INV1

GR1

INVBI

4711

BILLI

00003

370001

INV2

GR1

Posting Document

G/L Item DFKKOPK

OPBEL HKONT
370001
370001

175000
175001

BETRAG MENGE PSGRP INVGR

27.3.-

500.00

GR1
GR1

INV1
INV2
Invoicing Item

G/L Item

Business Partner Item DFKKOP

OPBEL HKONT
370001

140000

BETRAG

PSGRP

30.-

GR1
Invoicing Item

G/L Item

Business Partner Item

Tax Calculation
Use
You have the choice of calculating tax during invoicing in Contract Accounts Receivable and
Payable (internal tax calculation [Seite 155] ); or you can transfer tax that was determined before
invoicing to invoicing by means of the billing document (external tax calculation [Seite 158] ).
The system also supports a combination of external and internal tax calculation. This means that
you transfer the tax that was determined before invoicing to invoicing using the billing document,
and invoicing performs a recalculation of the tax (external tax calculation with internal handling).

(C) SAP AG

154

If you post telecommunications tax, you can transfer the necessary tax information using billable
items of Billing in Contract Accounts Receivable and Payable to Invoicing in Contract Accounts
Receivable and Payable. (See Calculation of Telecommunications Tax [Seite 160]).

Internal Tax Calculation

Use
Determination of tax within Invoicing in Contract Accounts Receivable and Payable

Features
Invoicing in Contract Accounts Receivable and Payable calculates the tax for billing documents
that have the value 01 (Internal tax determination) in the Type of Tax Calculation field
(TAX_DET_TYPE) of the billing document header.
The Tax Included in Amount (TAX_INCLUDED) indicator specifies if the amount of the billing
document item is a net or gross amount. The system calculates the tax differently depending on
how this indicator is set. If the indicator is not set, then the system calculates the tax using the
amount of the document item. If the indicator is set, the system calculates the amount so that the
end amount is reached.
The tax is calculated using the tax code (MWSKZ) that is either transferred in the billing
document item or determined during invoicing.
In some countries, the calculation of the tax is also dependent on the tax jurisdiction. For
consideration in the tax calculation during invoicing, the tax jurisdiction must be transferred to the
invoicing program in field TXJCD of the billing document item.
The function module defined for event 1110 calculates the tax.
For the tax display, the system creates invoicing document items with the following types of
invoicing item:
Tax Item for Net Amount Billing Document Items (0TAXITEM)
Tax Item for Gross Item for Gross Amount Billing Document Items (0TAXINCL)

Determination of the Tax Code

Use
The tax code controls the tax calculation.

Features
The following data combinations can arise in the determination of the tax code (MWSKZ):
If there is an entry for the tax code in the billing document item, this is used for the tax
determination.
If there is no entry for the tax code, but an entry for the tax on sales and purchases
determination code (ERMWKZ), the tax code is determined from table TE011. The type of
tax date (TAX_DATE_TYPE) in the billing document header is also interpreted.

(C) SAP AG

155

If there is no entry for MWSKZ or ERMWSKZ in the billing document items, the tax code is
determined using posting area 2610 in the same way as the revenue account.

Displaying Tax in Invoices

Use
In invoice preparation, there may be different requirements with regard to the display of the tax
amount in the invoice depending on the invoice layout. Depending on the requirement, the tax
can be displayed on the total invoice, or the tax information can be displayed for each invoice
block defined (for example, division, company code).

Features
As standard, the invoicing document items are grouped by the following fields (required entry) for
the tax display:
Tax Code (MWSKZ)
Tax Jurisdiction (TXJCD)
Line Item Is Simulated (ITEM_SIMULATED)
For the tax display in the invoice, the simulated items are treated the same as
the non-simulated items. However, the tax for the simulated items is not considered
in either the final invoice amount or the posting document. It is displayed in the
invoice for information purposes only. For example, as part of the display of billing
results with a different rate that is not effective for the invoice.
You can adjust this grouping.
You define the rules for grouping the invoicing document items for the tax display by means of the
configuration of the key for the tax display. You maintain the key for the tax display in the
Implementation Guide for Contract Accounts Receivable and Payable under Integration
Invoicing in Contract Accounts Receivable and Payable
Invoicing
Invoicing Processes
Maintain Key for Tax Display. In the activity Define Invoicing Types, you assign the key to the
invoicing type.
In Invoicing, tax calculation is for each grouping of invoicing document items determined. The
balance of the net amounts of a group is the base amount for the tax calculation. This means that
in the invoice display per group, an exact tax amount can be displayed.
The grouped invoicing document items and the tax items determined for them receive a common,
unique value in the invoicing document items in the field TAXGR Grouping Key for Tax Display.
This represents a link between the net items and the related tax items.

Maintaining Keys for the Tax Display

In the key for the tax display, you define the grouping fields to be used to group the invoicing
document items. You can define several grouping fields. You can use any field of the structure of
the invoicing document item FKKINVDOC_I as grouping field. Two invoicing document items are
assigned to one joint group if they all have the same value for the grouping fields specified (and
the mandatory fields MWSKZ, TAXJCD, and ITEM_SIMULATED) in the key for the tax display.

(C) SAP AG

156

Examples
Requirement

Solution

Display tax for each invoicing document

No grouping fields required

Display tax for each company code

In the key for the tax display, define the

grouping field Company Code (BUKRS).

Display tax for each billing document and for

the billing period

Define the grouping fields Source Document

Number (SRCDOCNO) and Start of Period of
Line Item (DATE_FROM) (or another suitable
field for the period assignment).

If necessary, you can define an alternative characteristic value for each value of the grouping field
and maintain the alternative use. This means that you can assign a joint grouping value to several
values of a grouping field.
Examples
Requirement

Solution

Display tax for each company code, whereby

joint tax display is required for company codes
0001 and 0003

In the key for the tax display, define the

grouping field Company Code BUKRS. In the
subdialog Assign Alternative Grouping Values,
assign the alternative characteristic value 0003
to the company code value 0001.

Display tax in two company code groups:

Company codes 0001 and 0003 are to form
one group, all other company codes the other
group.

In the key for the tax display, define the

grouping field Company Code BUKRS, and in
the field Use, assign the value 1 (Use initial
value if no alternative value defined). In the
subdialog Assign Alternative Grouping Values,
assign the alternative characteristic value 0003
to the company code value 0001.

If you cannot portray your grouping requirement using the grouping fields, you can perform
grouping in a separate function module and assign this module to the key for the tax display. The
interface of the function module corresponds to that of the sample function module
FKK_SAMPLE_TFK2613.

Clearing Tax Differences

Use
The grouping of invoicing items for tax display in the invoice can differ from the summarization of
G/L items during the calculation of the tax to be posted. Therefore, small differences can arise
between the displayed tax and the posted total tax amount as a result of rounding. The system
automatically clears these differences in the posting document. This means that the tax amounts
to be posted correspond to the tax amounts displayed in the invoice.

Features
In clearing, the system adjusts the amounts of the tax items to be posted and the related gross
amounts of the business partner items.

(C) SAP AG

157

Example
The figure shows an example for a tax difference clearing.
Invoice 4711

Date: 10/22/2005

Posting Document Before Difference Clearing

DFKKOP
1000
Contract:
Amount: 1140,84

Contract 1000 August 2005

Basic Price
Energy Price
Tax on Sales/Purchases (16%)
Subtotal:
Contract 1000 September 2005
Basic Price
Energy Price
Tax on Sales/Purchases (16%)
Subtotal:
Invoice Amount
Contains Tax on Sales/Purchases

300.00
180.39
76.86
------------557.25

300.00
203.09
80.49
------------583.58
1140.83

DFKKOPK
Account:
Amount:

10023 (Rev. A)
600.00

Account:
Amount:

10024 (Rev. B)
383.48

Account:
Amount:

100030 (Tax)
157.36

Difference due to different summarization rules in

invoicing document and posting document

Posting Document After Difference Clearing

DFKKOP
1000
Contract:
Amount: 1140.83

157.35
2

DFKKOPK
Account:
Amount:

10023 (Rev. A)
600.00

Account:
Amount:

10024 (Rev. B)
383.48

Account:
Amount:

100030 (Tax)
157.35

Correction of tax posting with adjustment of receivables

posting

In the example, the tax on sales and purchases is displayed separately for each month of
reference in the invoice. However, the revenue postings are bundled by energy price and basic
price. The tax is calculated for each revenue item and posted summarized to the tax account.
This results in a difference of EUR 0.01 between the tax displayed in the invoice and the tax to be
posted in the general ledger. There is then an automatic adjustment of the tax on sales and
purchases to be posted to the tax on sales and purchases displayed in the invoice.
For each grouping of the invoicing document items and the general ledger items for the tax
calculation, the maximum tax difference between the invoice document and the posting document
permitted is EUR 0.01 (or the smallest currency unit).
If the maximum amount is exceeded, the system terminates invoicing with the error message
Difference too large for tax difference clearing. Otherwise there is an automatic adjustment of the
tax posted to the tax displayed on the invoice.

External Tax Calculation

Use
Invoicing in Contract Accounts Receivable and Payable can process billing documents whose tax
amounts have been determined before invoicing.

Features
These billing documents have the value 02 External Tax Calculation in the field Type of Tax
Calculation (TAX_DET_TYPE) in the billing document header. In the field STRKZ, the line items

(C) SAP AG

158

DFKKINVBILL_I contain the tax code for other taxes. The tax information is stored in the tax
items of the billing document (DFKKINVBILL_T).
Invoicing transfers the tax information to the invoicing document and creates posting items.
During invoicing, there is no new tax determination for the billing documents
with external tax calculation. For these documents, an exactly correct totals display
in the invoice with rounding difference clearing in the posting document is not
possible.
For each tax item of the billing document, Invoicing in Contract Accounts Receivable and Payable
creates an invoicing billing item with the following link information:
DFKKINVDOC_I

Fixed Value

SRCDOCCAT

INVBI

SRCDOCNO
SRCITEMCAT
SRCDOCITEM

DFKKBILLDOC_T

BILLDOCNO
BILLT
BILLDOCTAXITEM

This invoicing document item has the type of invoicing item (TAX_EXT) Tax Determined
Externally.
In the billing document, the billing document items are linked with the related tax items by means
of the grouping field TAX_GROUP. This grouping information is also transferred to field TAXGR
Grouping Key for Tax Display in the related items of the invoicing document. However, a new
grouping value is assigned for the invoicing document items to ensure a unique grouping of the
billing documents during invoicing.
In the posting document, no real tax items are created for the tax items of the billing document;
instead, tax items are created for other taxes. Instead of the tax code (MWSKZ), these tax items
use the field STRKZ for other taxes in the posting items. The account determination takes place
using posting area 0015.
If you want to assign a main and subtransaction to the invoicing items created for external tax (for
example, for text determination on invoice preparation), you can define a main and
subtransaction per other tax (STRKZ) in posting area 0025 (and optionally for each category of
tax item (KSCHL)).

External Tax Calculation with Internal Handling

Invoicing in Contract Accounts Receivable and Payable can process billing documents for which
the tax amounts have been determined before invoicing and can recalculate this tax.

Features
You can recognize billing documents, for which tax was already determined before invoicing,
because they have the value 03 (External Tax Calculation with Internal Handling) in the Type of
Tax Calculation (TAX_DET_TYPE) field of the billing document header. The document items
DFKKINVBILL_I contain the tax code for calculating the tax in the field MWSKZ. The tax
information is stored in the tax items of the billing document (DFKKINVBILL_T).

(C) SAP AG

159

Invoicing copies the tax information of the billing document to the invoicing document, and
creates real tax items in the posting document for the tax items of the billing document.
Note
For billing documents with external tax calculation and internal handling, invoicing determines the
tax again. The tax that is displayed in the invoice is the externally determined tax amounts; the
system automatically clears any rounding differences between the externally determined tax and
the internally calculated tax in the posting document.
End of the note.
For each tax item of the billing document, Invoicing in Contract Accounts Receivable and Payable
creates an invoicing document item with the following linkage information:
DFKKINVDOC_I

Fixed Value

SRCDOCCAT

INVBI

SRCDOCNO
SRCITEMCAT
SRCDOCITEM

DFKKBILLDOC_T

BILLDOCNO
BILLT
BILLDOCTAXITEM

The system designates this invoicing document item with the Type of Invoicing Item (TAX_EXT)
Externally Determined Tax with Internal Handling.
In the billing document, the billing document items are linked with the tax items belonging to them
by the grouping field TAX_GROUP. The system also adopts this grouping information in the
related items of the invoicing document in the field TAXGR (Grouping Key for Tax Display).
However, the system assigns a new grouping value for the invoicing document items, in order to
ensure that the assignment to a group is unique across the billing documents contained in
invoicing. In the posting document, the system creates real tax items for the tax items of the
billing document; the system updates the tax code (MWSKZ) in the posting items. Account
determination takes place as it does for an internal tax calculation.

Calculation of Telecommunications Tax

Provided that you have integrated Billing in Contract Accounts Receivable and Payable with SAP
Convergent Charging, Invoicing in Contract Accounts Receivable and Payable supports the
calculation and reporting of telecommunications tax by external tax systems in the United States
and Canada.
Note
If you are not using SAP Convergent Charging, then there are no functions available for
calculating telecommunications tax and updating an external system.
End of the note.

(C) SAP AG

160

Features
If Billing in Contract Accounts Receivable and Payable is integrated with SAP Convergent
Charging, then Invoicing in Contract Accounts Receivable and Payable processes billing
documents of Billing in Contract Accounts Receivable and Payable that contain
telecommunications tax data in the billed items.
The external tax system is integrated with SAP Convergent Charging. The first tax calculation for
a transaction (such as a telephone call or SMS) takes place there to determine the gross price for
the transaction. SAP Convergent Charging transfers the basic data required for the tax
calculation to Billing in Contract Accounts Receivable and Payable as attributes of the billable
item. This basic data includes the base amount for the tax calculation, the type of
telecommunications service, the tax date, and various location codes (such as, the originating
address of the phone call, the target address, and the address of the invoice recipient).
Invoicing in Contract Accounts Receivable and Payable calculates the tax again.
If invoicing created posting documents, then it updates the telecommunications tax data in the
external tax system. To do so, invoicing calls functions in SAP Convergent Charging.
In the standard system, there is no direct interface between SAP Convergent Invoicing and the
external system for telecommunications tax. Implicitly, the tax software is used that SAP
Convergent Charging also uses.

Activities
To be able to transfer the basic data for telecommunications tax from SAP Convergent Charging
to Billing in Contract Accounts Receivable and Payable, make the necessary fields available
using the billable item class. To do so, in Customizing for the billable item class, choose the
interface component Basic Data for Telecommunications Tax (U.S.A.) (USCOMMTAX). (See
Customizing for Contract Accounts Receivable and Payable under Integration Billing in
Contract Accounts Receivable and Payable Maintain Billable Item Classes ).
Note
If you are not using SAP Convergent Charging and you want to calculate telecommunications tax
in Invoicing in Contract Accounts Receivable and Payable, then you have to program the desired
functions using events 0413 and 0414 for your installation. Define the necessary function
modules and register these in Customizing for Contract Accounts Receivable and Payable under
Program Enhancements Define Customer-Specific Function Modules .
End of the note.

External Account Derivation

Use
External account derivation serves to customer-specifically and industry-specifically derive the
posting attributes when setting up the posting items and invoicing items for a billing document.

Features
At event 2612 you can predefine, for each settlement item, the posting attributes that are required
for setting up the invoicing items and the posting items, in particular for the FI/CO/FM account
assignment. This account assignment is used instead of the standard account assignment that is

(C) SAP AG

161

to be stored in the Customizing of the invoicing. Furthermore, you can set up multiple invoicing
items and posting items for a settlement item, or suppress the posting.

Supplementing Posting and Invoicing Items

Use
Provision of values for customer-specific and industry-specific fields

Features
You supplement posting and invoicing items in event 2611. You can provide data for the
customer-specific and industry-specific fields of the invoicing and posting document (for example,
information from the billing document) in the function modules called for this event.
Processing takes place per billing document. At this event, the invoicing document items and
posting document items have already been created, but the posting document items have not
been grouped. They are linked with the corresponding items of the billing document in the
transfer structure by means of the fields SRCDOCNO and SRCDOCITEM.
In addition, in this event replace the type of invoicing item in the invoicing items with your own
value. The new value must be in the customer namespace.

Deferred Revenue Postings

Deferred revenue is posted for services that are not recognized as revenue when they are
invoiced. The point in time when the services have an effect on revenue is either known at the
time the service is invoiced (time-based deferred revenues), or it is determined at a later point
when a certain event is triggered (event-based deferred revenues).

Features
Time-Based Deferred Revenues
To trigger a deferred revenue posting for invoiced services, you have to trigger an update of
additional data in invoicing for the deferred revenue recognition. You have the following options:
As long as the controlling information for posting the deferred revenues is explicitly
contained in the billing items, the invoicing program uses these transfer posting dates.
This is the case especially if the transfer posting dates are included in the items (that is,
when the category of deferred revenue is time-based deferred revenue).
In addition, or as an alternative, you can use event 2615 to change or redetermine the
transfer posting dates and the amounts for deferred revenue postings for each
transferred revenue item.
Event-Based Deferred Revenues
The function includes the following process steps:

(C) SAP AG

162

Post invoiced service to account for deferred revenues

Process event for transferring deferred revenues to revenue account
You use this invoicing function when you invoice billing documents whose items contain
controlling information about posting and activating event-based deferred revenues. In more
detail, this means that this invoicing function is used for billing document items that reference the
deferred revenue category Event-Based Deferred Revenues and that contain an entry in their
action code field defining if:
Their amount is posted as deferred revenue to a deferred revenue account
This amount remains on this account until an event occurs that triggers the posting to a
revenue account.
The items trigger an event for revenue recognition
Then the amount of the item is transferred from the deferred revenue account to the
appropriate revenue account.
When the event-based deferred revenues are processed in invoicing, the program updates
additional data for the deferred revenue recognition. You can add your own customer-specific
data to this data in event 2616.
Note
To be able to use event-based deferred revenue, you have to add the structure
FKKINVBILL_I_DEFREV to customer include CI_M_FKKINVBILL_I. You can do so using
transaction FKKINV_ENH_DEFREV.
End of the note.

Invoicing of SD Documents
Use
You can invoice SD billing documents in Contract Accounts Receivable and Payable, and
together with other source documents of invoicing, you can process and post them, and print
invoices for them.

Prerequisites
To be able to process SD billing documents in Contract Accounts Receivable and Payable (FICA), you have to transfer the billing documents to FI-CA. You define this for each account group.
In the account group, you specify whether the customers are transferred to Accounts Receivable
Accounting (FI-AR) or FI-CA during SD billing.
For the transfer of SD billing documents to FI-CA, you have made settings in Customizing for
Contract Accounts Receivable and Payable under Integration Sales and Distribution
Define
Posting to FI-CA for Customer Account Groups. As an alternative, you can make these settings in
Customizing for Sales and Distribution under Billing
Billing Documents
Integration with
Contract Accounts Receivable and Payable (FI-CA)
Define Posting to FI-CA for Customer
Account Groups. See also the documentation for the activity.

(C) SAP AG

163

You can create a direct posting for SD billing documents in FI-CA, or Invoicing in Contract
Accounts Receivable and Payable can process the posting. To do so, you can choose from the
following integration scenarios:
Transfer of an SD billing document to Invoicing in Contract Accounts Receivable and
Payable using sample documents
Direct transfer of an SD billing document to Invoicing in Contract Accounts Receivable and
Payable without an FI-CA sample document

Features
Regardless of which scenario you choose, the following functions are available:
Function

Process Flow and Activities in FI-CA

Derivation of main and subtransaction

The system derives the main and

subtransactions in FI-CA during the transfer of
SD billing documents using your Customizing
settings. You enter these in Customizing for
Contract Accounts Receivable and Payable
under Integration Sales and Distribution
Derive Main/Subtransaction from SD
Information.
You can use the fields Billing Document Type,
Item Category, Account Assignment Group
Material, and Account Key as key fields for
deriving transactions.
With the function module processed in event
4030, you can determine alternative
transactions.

Account determination

The reconciliation and revenue accounts are

determined using the SD standard account
determination. In the reconciliation account
determination of SD, you have to specify the
receivables accounts for Contract Accounts
Receivables and Payable. (See Customizing
for Sales and Distribution under Basic
Functions
Account Assignment/Costing
Reconciliation Account Determination.)

Document type

The system derives the document type during

the transfer of SD billing documents using your
Customizing settings. You enter these in
Customizing for Contract Accounts Receivable
and Payable under Integration
Sales and
Distribution
Derive Document Type from SD
Billing Doc Data.

(C) SAP AG

164

Tax determination and tax calculation

Tax is determined and calculated during the

creation of the SD billing document in the Sales
and Distribution component. The system
passes on these tax amounts that were already
determined before invoicing in Contract
Accounts Receivable and Payable. This means
that the tax that is displayed on the invoice, as
well as the tax to be posted in Contract
Accounts Receivable and Payable is already
determined.

Two-step update of SD billing documents in

Accounting

The transfer to FI-CA subdivides the update of

the SD billing documents in Accounting into
two events. In the first event, the SD billing
document updates FI-CA.
All other components of accounting, such as
Profit Center Accounting (EC-PCA), Profitability
Analysis (CO-PA), or Overhead Cost
Controlling (CO-OM) are not considered in the
transfer of the billing document. These
components are updated in a second step
during the transfer of the summarized FI-CA
data to Financial Accounting (FI). Then all
components of accounting that were not
considered in the first step are updated.
Reconciliation between the individual
components can only be made for closed
posting periods and for points in time at which
all Contract Accounts Receivable and Payable
reconciliation keys have been transferred
completely to the general ledger (FI-GL).

Document supplementation

The system enriches the customer line items of

the SD billing document that is transferred to
the financial accounting interface with the
following information:
General information (for example,
reference details)
Information from the contract account
(for example, account determination ID)
Information on main and
subtransactions for each company code
and division (such as dunning, interest,
payment)
The system creates the business partner item
in Contract Accounts Receivable and Payable
from the customer line item. The information is
derived using event 4000, which is called to
supplement customer items and G/L account
items.

(C) SAP AG

165

The communication between Sales and Distribution and FI-CA, as well as between FI-CA and
accounting takes place using the accounting interface (RWIN). The update to accounting also
takes place in two steps. The use of the accounting interface, however, differs in the different
integration scenarios.
If you update Profitability Analysis (CO-PA) directly in the RWIN interface (for example,
during direct posting to FI-CA without using invoicing), the system determines the value fields
dependent on the condition type.
If you update Profitability Analysis (CO-PA) in FI-CA (for example, during processing of SD billing
documents in invoicing), the system determines the value fields dependent on the cost element.

Invoicing of SD Documents with FI-CA Sample

Document
You can transfer SD billing documents to Invoicing in Contract Accounts Receivable and Payable
using FI-CA sample documents.

Prerequisites
The transfer of SD billing documents to Contract Accounts Receivable and Payable (FICA) is active.
SD billing documents, which you transfer to Invoicing in Contract Accounts Receivable
and Payable using FI-CA sample documents, have to have the SD billing category U.
There has to be an invoicing order of the source document category SD.
There has to be a billing request for the integration in Invoicing in Contract Accounts
Receivable and Payable.

Features
When you perform the invoicing function, the system adopts the data of the billing request in the
invoicing document and generates the postings in FI-CA. For the billing requests, this results in
the following special functions during the transfer to FI-CA (through internal program queries of
the billing category U that is used):
Generation of an FI-CA sample document
Contract Accounts Receivable and Payable generates a special reference document,
from which the system proposes data when creating an accounting document. Unlike an
accounting document, an FI-CA sample document does not update any transaction
figures. The FI-CA sample document serves only as a source of data for an accounting
document. The FI-CA sample document has the same components as the accounting
document, with document header (DFKKMKO), business partner items (DFKKMOP) and
G/L items (DFKKMOPK). The sample document header contains the origin 10 (SD Billing
Document), the reference transaction (VBRK), and as reference key the SD billing
document number.

(C) SAP AG

166

Creation of an invoicing order

If Invoicing in Contract Accounts Receivable and Payable is active in FI-CA, then the
sample function module FKK_SAMPLE_4050 in event 4050 (Update Additional Data for
Sample Documents) generates an invoicing order of the source document category SD
(SD Documents for Sample Document). The setup of this billing category simultaneously
suppresses the assignment of an output determination procedure to the billing type. In
this way, the system ensures that you cannot print an invoice in standard SD.
Invoicing in Contract Accounts Receivable and Payable

SD

Invoicing
Processes

DFKKINV_TRIG

Invoicing
Order SD

Posting
Document

Selection
Grouping

DFKKMOP

SD Billing
Request

SD Order

Invoicing
Document

Invoicing SD
Documents

Billing Category U

SD Billing
Dcoument

CO-PA

AC Interface
1

SD Invoice

AC Interface
2

FI
CO

Transfer of SD Billing Document to Invoicing in FI-CA with FI-CA Sample Document

Activities
Billing in Sales and Distribution (SD) decides based on the SD billing type used, if Invoicing in
Contract Accounts Receivable and Payable processes an SD billing document as a billing
request. To create billing requests that are processed by Invoicing in Contract Accounts
Receivable and Payable:
1. Create billing documents with a billing type with billing category U. To do so, in the Sales
and Distribution menu, choose Billing Billing Document Create .
2. Release the billing documents. To do so, in the Sales and Distribution menu, choose
Billing Billing Document Blocked Billing Docs . By releasing the documents you
transfer the data to Accounting.
Note
The reversal billing type of a billing type with billing category U also has to have billing category U.
If the reversal billing type has a different billing category, you cannot reverse the billing type.

(C) SAP AG

167

End of the note.

Invoicing of SD Documents Without FI-CA Sample

Document
You can transfer SD billing documents directly to Invoicing in Contract Accounts Receivable and
Payable, that is, without creating an FI-CA sample document.

Features
When you transfer the SD billing documents to Accounting, the system does not update Contract
Accounts Receivable and Payable. The system only creates an invoicing order for Invoicing in
Contract Accounts Receivable and Payable with the source document category SD Billing
Document (fixed value VBRK). The system processes this invoicing order using the invoicing
function Invoicing SD Billing Documents VBRK, which calls the AC interface again to derive the
postings in Contract Accounts Receivable and Payable. The system generates posting
documents. If necessary, you can clear down payments.
SD

Invoicing in Contract Accounts Receivable and Payable

Invoicing Processes

Selection

Posting
Document
DFKKINV_TRIG

SD Order

Invoicing
Order
VBRK
AC Interface
(Exit)

Grouping

Invoicing
VBRK
Documents

Invoicing
Document

AC Interface
(Project)

SD Billing
Document

CO-PA

SD Invoice

FI
CO

AC Interface

Direct Transfer of SD Billing Documents to Invoicing in FI-CA Without FI-CA Sample Document
Note
If you transfer SD billing documents directly, then there is no time gap between the processing of
the SD billing documents and posting. Also the intermediate step of creating FI-CA sample
documents is not necessary. This results in the following advantages:

(C) SAP AG

168

Reconciliation between Sales and Distribution and Contract Accounts Receivable and
Payable is simplified.
No redundant data is generated, since the creation of FI-CA sample documents and
original documents causes the number of documents to be double.
Instead of the FI-CA sample document, the SD document flow shows the invoicing
document of the SD billing document.
The invoicing document references the SD billing document directly, rather than an FI-CA
sample document.
The reference to the SD billing document is made in the invoicing order using the fields
Source Document Category (VBRK) and Source Document Number, which is the same
as the SD billing document number.
Invoicing in Contract Accounts Receivable and Payable derives the posting document
data. This data is not already fixed in the FI-CA sample document. As a result, you can
better use functions in FI-CA, such as the clearing of down payments already made.
End of the note.

Activities
You enable a direct integration without FI-CA sample documents in Customizing for Contract
Accounts Receivable and Payable. You do so by specifying for each SD billing type and customer
group if further processing should take place in Invoicing in Contract Accounts Receivable and
Payable. To do so, in Customizing for Contract Accounts Receivable and Payable, choose
Integration Sales and Distribution Define Settings for Transfer to Invoicing . As an
alternative, you can make these settings in Customizing for Sales and Distribution under Billing
Billing Documents Integration with Contract Accounts Receivable and Payable (FI-CA) .

Invoicing SD Billing Documents (VBRK)

Using the invoicing function Invoice SD Billing Documents, you can process documents that
Sales and Distribution (SD) creates and then posts in invoicing, or that you want to process into
an invoice. The objects involved here are source documents to be invoiced of the source
document category SD Billing Document (VBRK). Source documents of the source document
category SD Billing Document are special SD billing documents with a billing type that is intended
for Invoicing in Contract Accounts Receivable and Payable.

Prerequisites
There are invoicing orders for the SD billing document, and the SD billing document is contained
in the list of invoicing orders for the contract account to be invoiced.

Features
If the source document category SD Documents (VBRK) is set by the Main Selection indicator,
then an SD billing document can trigger invoicing of the related contract account.

(C) SAP AG

169

When an SD billing document is invoiced, the system adds the billing document to an invoicing
unit and generates an invoicing document for each invoicing unit. The system posts the SD billing
document in Contract Accounts Receivable and Payable and displays it in the invoice.
The determination and calculation of taxes already took place when the SD billing document was
created in Sales and Distribution (SD). So the tax displayed on the invoice, as well as the tax to
be posted in FI-CA is already specified.
In the invoicing document, the SD items are designated with invoicing item type 0VBRK_IT.
These items are considered in the final invoice amount.
The system manages an invoicing history and reversal history for the SD billing document.
Document Links
Invoicing links the SD billing document with the invoicing document by means of the invoicing
history (DFKKINVDOC_S) with source document category SRCDOCCAT = VBRK (SD Billing
Document).
The posting documents created during invoicing of the SD billing document are linked with the
invoicing document by means of reference table (DFKKINVDOC_P) with reference document
type CADOCTYPE = VBRK (Posting Document for SD Billing Document).
Creation of the Posting Document
The posting document is created using the accounting interface.
Creation of Invoicing Items
The system creates the invoicing items in the invoicing document based on the posting document
of the SD billing document. An invoicing document item (DFKKINVDOC_I) is created for each
business partner item. Along with the amount data, the invoicing document item adopts data such
as the company code, account determination ID, and main and subtransaction.
The invoicing items are designated with the invoicing item type ITEMTYPE = 0VBRK_IT (SD
Billing Document). These items are relevant for printing, posting, and the final invoice amount.
This means that the system considers the amount of the invoicing items in the final invoice
amount in the header of the invoicing document.
The invoicing document item also receives a reference to the SD billing document from which it
originates. This link is established by means of the fields SRCDOCCAT (Category of Source
Document to Be Invoiced VBRK) and SRCDOCNO (Number of Source Document to Be
Invoiced).

Activities
You enable the integration between Sales and Distribution (SD) and Invoicing in Contract
Accounts Receivable and Payable (without FI-CA sample documents) in Customizing for Contract
Accounts Receivable and Payable. You do so by specifying for each SD billing type and customer
group if further processing should take place in Invoicing in Contract Accounts Receivable and
Payable.
You make the specification for direct transfer to invoicing without sample documents in
Customizing for Contract Accounts Receivable and Payable under Integration Sales and
Distribution Define Settings for Transfer to Invoicing .

(C) SAP AG

170

As an alternative, you can make these settings in Customizing for Sales and Distribution under
Billing Billing Documents Integration with Contract Accounts Receivable and Payable (FICA) .

Reversal of SD Billing Documents (VBRK)

You can reverse a billing document in Sales and Distribution (SD).

Features
The following rules apply for reversing SD billing documents:
If Invoicing in Contract Accounts Receivable and Payable has not yet processed the SD
billing document, you can reverse it in Sales and Distribution (SD).
The system posts the SD billing document as well as the SD cancellation billing
document. The system identifies them as completed in the SD document flow. There is
no further processing by Invoicing in Contract Accounts Receivable and Payable.
If Invoicing in Contract Accounts Receivable and Payable has already processed the SD
billing document, you cannot reverse it in Sales and Distribution (SD).
In that case, you can only make the reversal in Contract Accounts Receivable and
Payable by posting an invoicing reversal. For SD billing documents, that means that the
system creates the needed invoicing orders and you can invoice these again. There is no
direct reversal of the underlying SD billing documents.

Invoicing Billing Requests

Use
Using the invoicing function Invoicing of SD Documents, you can process billing requests from
the Sales and Distribution (SD) component. Invoicing in Contract Accounts Receivable and
Payable adopts the source documents of source document category SD in the invoicing
document. This makes them available for invoice printing and for posting in Contract Accounts
Receivable and Payable.

Features
The system creates a posting document for each billing request. In the invoicing document, this
posting document has reference document type 0SD.
The system updates the invoicing history for the billing request.
During processing of an SD document, the invoicing program carries out the following logical
processing steps:
Creation of posting document
Creation of invoicing items for the SD document
Document Linking

(C) SAP AG

171

Invoicing links the billing requests with the invoicing document by means of the invoicing history
(DFKKINVDOC_S) with the source document category SRCDOCCAT = SD (SD document).
The posting documents created during invoicing of the billing requests are linked with the
invoicing document by means of the reference table (DFKKINVDOC_P) with reference document
type CADOCTYPE = 0SD (Posting document for SD document).
Creation of posting document
For each billing request, the system creates a posting document from the data of the sample
document. With the exception of certain data that is determined during invoicing, the default
values of the sample document are transferred. Business partner items and general ledger items
are created unchanged for the reference items of the sample document. Amounts, units, and
account assignment information are already defined when the billing request is updated in FI-CA,
for example. However, the function module called at event 1320 enables you to add data to the
document. The posting parameters of the invoicing process are transferred to the posting
document. The following invoicing data is assigned as new:
Reconciliation key
Source
Document type
Due date
Creation of the Invoicing Items
In the invoicing document, the invoicing items are created based on the posting document of the
billing requests. An invoicing document item (DFKKINVDOC_I) is created for each business
partner item. In addition to the amount data, data such as company code, division, account
determination characteristic, main and subtransaction is transferred to the invoicing document
item.
The invoicing items have invoicing item type ITEMTYPE = 0SDITEM (SD Invoicing Items).
These items are relevant for printing, posting, and the final invoice amount. This means that the
amount of the invoicing items is considered in the final invoice amount in the header of the
invoicing document. The invoicing document item also receives a reference to the billing
document request from which it arose. The link is by means of the fields SRCDOCCAT (Category
of Source Document to Be Invoiced SD) and SRCDOCNO (Number of Source Document to Be
Invoiced).

Reversing Billing Document Requests

Use
Reversal of a billing document in Sales and Distribution (SD)

Features
When you reverse SD billing documents that have been posted as billing document requests in
SD, the following rules apply:
If the billing document request has not yet been included in an invoicing, you can reverse it
in Sales and Distribution (SD). The SD billing document and the related SD reversal billing
document are posted and marked as Completed in the SD document flow. There is no
further processing by Invoicing in Contract Accounts Receivable and Payable.

(C) SAP AG

172

If the billing document request has already been included in an invoicing, you cannot
reverse it in Sales and Distribution (SD). In this case, you can only perform the reversal in
FI-CA with the invoicing reversal. For the SD documents, this means that the
corresponding billing document requests are activated and reinvoiced. You cannot reverse
the underlying SD billing documents directly.

Collective Invoicing
Use
In addition to invoicing billing documents, you can also use an invoicing process to create
collective invoicings.

Features
Collective invoicing processes the invoicing orders of source document category COLBI. These
represent the collective bills (posting documents from FI-CA) that were posted during the
invoicing of the individual accounts of a collective bill. Collective invoicing groups collective bills
together into a collective invoicing document. You can then use the collective invoicing document
to create a collective invoicing printout (FI-CA) [Extern] using invoice printing. The collective bill
contract partner receives the collective invoicing printout and the related individual invoices
(invoices of the individual accounts of a collective bill). The creation of a collective invoicing
document covers two process steps:
...

1. Invoicing of the individual accounts assigned to a collective bill account

2. Invoicing of the collective bill account, that is, grouping of the collective bills created in the
first step into a collective invoicing document
Collective Invoicing

Individual
Contract
Account

Collective Bill
Contract Account

FI-CA
Document

Invoicing Order

Billing
Document

(C) SAP AG

Individual
Invoicing

Invoicing Order

Collective
Invoicing

Collective
Invoicing
Document

Invoicing
Document

173

Collective invoicing is based on the functions for processing collective bills [Extern] in Contract
Accounts Receivable and Payable where, when you post an individual document, this is linked
automatically to a collective bill (statistical posting document) that represents the individual
document in the subsequent business transactions (for example, payment, dunning). Several
individual documents can reference a joint collective bill. The amount of the collective bill is the
total of the amounts of the individual documents.

Invoicing Individual Accounts

Use
When invoicing individual accounts, the procedure described above for creating the collective bill
is followed. Parallel to the creation of individual documents (for example, when invoicing billing
documents), step by step a collective bill is created and updated.

Features
The posting items of the individual documents are summarized in one collective bill according to
the following criteria:
Source
Posting date
Due date
Due date for cash discount
Cash discount percentage rate
Currency
+/- sign of amount (credit/receivable)
A collective bill is only used for including further individual documents if:
It has not been (partially) cleared or reversed
It has not yet been processed in collective invoicing
It is not contained in a payment specification
In addition, in event 2225 (Collective Bill: Summarization Criteria), you can define additional
criteria for creating a collective bill, such as Invoicing Process and Invoicing Type.
A collective bill can group a maximum of 500 individual documents. If this number is exceeded,
the system automatically creates a new collective bill. Note that this restriction only applies to the
posting documents. The size of the individual documents (number of posting items for an
individual document) is irrelevant. No statement can be derived as to the maximum
recommended size of the collective bill master data construction (number of individual accounts
for a collective bill account).
The statistical collective bill items created during the invoicing of the individual accounts are
posted with the clearing restriction 7 Collective Bill: Payable Only after Collective Invoicing. This
has the effect that the collective bills and the related individual documents cannot be processed
until processing in collective invoicing (no clearing, no dunning, no interest calculation).
In addition, during posting of a collective bill (during invoicing of the individual account), an
invoicing order with the source document category COLBI (collective bill) is created for this
document for further processing in collective invoicing.

(C) SAP AG

174

The following functions are not supported in invoicing of individual accounts:

Additional function Dunning in Invoicing
Determination of Payment Method
Creation of Payment Form

Since Invoicing in Contract Accounts Receivable and Payable supports interest

calculation at individual account level as well as at collective bill account level, you
have to exclude multiple calculation of interest on items via a suitable system
configuration. You have the following options:
Define the interest key either only in the individual account or only in the
collective bill account.
Activate the invoicing function Calculation of Interest on Open Items either
only in the invoicing process for invoicing the individual account, or in the
invoicing process for invoicing the collective bill account.

Invoicing Collective Bill Accounts

Purpose
The collective invoicing is performed at collective account level. Its primary task is to bundle the
collective bills created in the invoicing of the individual accounts into a collective invoicing
document that is the basis for creating the collective invoice printout in invoice printing.
Perform this process step after invoicing of individual accounts and before collective bill printing.
You can start collective invoicing periodically for collective bill accounts.

Process Flow
Collective invoicing consists of the following logical processing steps:
1. Selection of Invoicing Orders
Selection is performed using the invoicing orders with the source document category
COLBI (Collective Bill Document) created during the invoicing of the individual accounts.
Apart from the collective bill contract partner and the collective bill account, the Due Date
for Net Payment is the most important selection criterion. It is interpreted as To Date. All
collective bills to be invoiced with an earlier or the same due date are selected.
2. Creation of the Invoicing Unit
The invoicing orders selected are bundled according to collective bill accounts and the
common due date of the invoicing units.
Using event 2601 (Creation of Invoicing Unit), you can group or separate the collective bills
according to your own criteria. In particular, you can group collective bills with different due
dates in one invoicing unit.
Since collective bills with the same due date are processed in one collective
invoicing, you can minimize the correspondence volume for each collective bill

(C) SAP AG

175

account by using a payment condition in the collective bill account. As a payment

target, this payment condition determines fixed days of a month - for example, due
on 15 th of the following month instead of in 14 days. This means that the collective
bill correspondence recipient only receives one collective invoicing printout each
month with the list of the collective bills to be paid.
3. Determination of Due Date
There is no further due date determination in collective invoicing. All statistical collective bill
items processed in a collective invoicing retain the due date originally determined during
invoicing of the individual accounts.
When you start collective invoicing, set the date in the Due Date for Net
Payment field sufficiently in the future so that the terms of payment of the individual
collective bills are retained.
If the due date of the collective bills processed in one collective invoicing is not unique (this
case can occur due to the use of event 2601), the due date of the next collective bill item
due is used as the due date of the collective invoicing. Alternatively the document date of
the collective invoicing is used if the due date of all collective bills involved has already
been reached.
4. Creation of Collective Invoicing Document
One collective invoicing document is created for the collective bills processed together.
This document is the basis for the creation of the collective invoicing printout in invoice
printing. For each collective bill, one invoicing document item with invoicing item type
0COLLBIL (collective bill) is created in the invoicing document.
5. Release of Collective Bills for Payment
The clearing restriction 7 set in the posting items of the collective bill during the invoicing of
the individual accounts is reset. This means that these items are released for further
processing in FI-CA.
6. Integration of the Additional Functions of Invoicing in Contract Accounts Receivable and
Payable
Collective invoicing supports the most important additional functions of Invoicing in
Contract Accounts Receivable and Payable, such as:
Account maintenance at collective bill account level
Selection of subitems for invoice display
Calculation of interest on open items of the collective bill account

Invoicing List
The invoicing list groups single invoicing documents together into an invoicing document.

Using the invoicing list, you can periodically list multiple, existing single invoicing documents in a
new invoicing document, and send the overview invoice to the recipients of the single invoicing
documents or to an alternative recipient.

(C) SAP AG

176

You create an invoicing list in two steps. Each of these steps is supported by the invoicing
functions Preselect Invoicing Document for Invoicing List and Create Invoicing List. Using the
invoicing function Preselect Invoicing Document for Invoicing List, you create an invoicing order
for an invoicing document for entering the invoicing document in an invoicing list. These invoicing
orders form the basis for creating the invoicing list in the Create Invoicing List invoicing function.
The invoicing document created by the Create Invoicing List invoicing function is essentially a list
of the single invoicing documents that were entered into it. The list contains information, such as
the document number, tax amount, and total amount of these single documents.

Preselect Invoicing Document for Invoicing List

If you activate this invoicing function, then the system creates an invoicing order for the invoicing
document for source document category SUBIN. This invoicing order is then processed further by
the invoicing function Create Invoicing List.

Prerequisites
You activated the creation of the invoicing order in Customizing for Contract Accounts Receivable
and Payable under Integration Invoicing in Contract Accounts Receivable and Payable
Invoicing Invoicing Processes Additional Functions Flag Invoicing Document for Invoicing
List .
You can use event 2637 for finer control of this configuration. There you can specify the earliest
invoicing date of the invoicing order and an alternative recipient for the invoicing list, in addition to
other specifications.

Features
Single invoicing documents, for which an invoicing order was created, are identified in the
document header in the field Invoicing Document Is Single Document of Invoicing List. The single
invoicing document does not lose its identity as a single document by being added to the
invoicing list. The document retains its characteristics, both with regard to invoice printing and
payment of the invoice amount. Activating this invoicing function is useful only if you defined at
least one invoicing process in which the invoicing function Create Invoicing List is active.

Create Invoicing List

This invoicing function Create Invoicing List processes invoicing orders (of source document
category SUBIN) that were created by the invoicing function Preselect Invoicing Document for
Invoicing List.

Features
In the standard system, the system creates the invoicing list for the contract account of the single
invoicing document. However, you can specify an alternative recipient for the invoicing list when
you set up the invoicing order in event 2637. You can create multilevel invoicing lists. This means
that you can create an invoicing list as a single invoicing document in another invoicing list (for
example, an invoicing overview for a subsidiary, which in turn is included in the overview of
subsidiary invoices for the headquarters of the parent company).

(C) SAP AG

177

Note
If you use constructs of this kind, it is important not to create invoicing lists of different levels in
the same invoicing process. To keep the lists separate, you can use a different source document
type (for source document category SUBIN) for each of the levels. For instance, using the above
example, you could use source document type XXX for the subsidiaries and source document
type YYY for the parent company. You then use these source document types in the selection
control of the invoicing process.
End of the note.
You assign the source document type in the invoicing function Preselect Invoicing Document for
Invoicing List when you create the invoicing order for the single invoicing document. The invoicing
list provides an overview of the single invoicing documents that were generated, and is not
intended to be used as a basis for handling payment of the single invoicing documents. The
invoicing list is created using only the information in the single invoicing documents, without
considering their clearing status or the related posting documents.
Note
To avoid inconsistencies in the invoicing list, you should refrain from displaying account balance
information in the list, as far as possible. In addition, do not use additional functions for posting
open items (such as, interest calculation, account maintenance) in the invoicing process that
creates the invoicing list.
End of the note.

Creation of Preliminary Invoices

For the purpose of internally checking invoices or for enabling customers to check their invoices,
you can create preliminary invoices without generating postings in Contract Accounts Receivable
and Payable or creating central correspondence.

Prerequisites
You have made the necessary settings in Customizing for Contract Accounts Receivable and
Payable under Integration Invoicing in Contract Accounts Receivable and Payable
Invoicing Invoicing Processes Additional Functions Enter Specifications for the Creation
of Preliminary Invoices .

Features
You create preliminary invoices using the invoicing function Creation of Preliminary Invoices. In
invoicing, the system creates an invoicing order of source document category PRLIN for each
preliminary invoice.
Depending on what settings you made in Customizing, the invoicing run also creates a
clarification case or a print request for your preliminary invoices.
You can take the following actions for a preliminary invoice:
Accept it by releasing the invoice

(C) SAP AG

178

When you release the invoice, the system selects the invoicing order for the preliminary
invoice and creates the invoicing document based on the elements making up the
preliminary invoice.
The result of releasing the invoice is that it is posted and printed.
Reject it by reversing the invoice
You reverse a preliminary invoice in the transaction for reversing invoicing documents.
On the SAP Easy Access screen, choose Invoicing Dialog Processing Reverse
Invoicing Document .
You clarify preliminary invoices from the SAP Easy Access screen under Invoicing in Contract
Accounts Receivable and Payable Monitoring Clarification Processing . Here you can:
Simulate correspondence
Create a print request (for each correspondence container)
Release the preliminary invoice
When you release a preliminary invoice, you can either start invoicing in dialog mode or
schedule invoicing for later.
During invoicing, the system generates an invoicing document from the invoicing order
for the preliminary invoice and posts the invoice in Contract Accounts Receivable and
Payable.
Reverse the preliminary invoice
You reverse the preliminary invoice in the dialog transaction for the reversal of invoicing
documents.
Note
The system creates the final invoice based on the information in the preliminary invoice. To avoid
differences between the preliminary invoice and the final invoice, you should activate the same
invoicing functions in both invoicing runs.
Invoicing creates a separate invoicing unit for each preliminary invoice.
End of the note.

(C) SAP AG

179

Release

e
o iicc e
IInnvvo

Release
Preliminary
Preliminary
Invoice

ryy
in aar
min
lliim
PPrree

Create
Create
Preliminary
Preliminary
Invoice

Check

Invoice

4711*

- Automatically After N Days

- Manually by User (CFC)

Invoice

Print Invoice
(Optional)

FI-CA: Account
D

4712

Create Clarification Case (CFC)

(Optional)

(Not Posted)

Reject
Preliminary
Invoice

saall
veerrs
RReev
4713

Life Cycle of a Preliminary Invoice

Additional Functions
Use
In addition to processing billing documents, in Invoicing in Contract Accounts Receivable and
Payable, you can integrate further functions from Contract Accounts Receivable and Payable (FICA) that represent complete business transactions in FI-CA from a business view.

Features
For example, you can integrate interest calculation, creation of dunning proposals, or the
calculation of charges and discounts in Invoicing. These invoicing functions are also called
invoicing additional functions. You define the performance of additional functions for the invoicing
process (see Activating/Deactivating Invoicing Functions [Seite 121] and Invoicing Functions That
Can Be Activated [Seite 124]).
The standard delivered by SAP supports various additional functions. The individual additional
functions are documented in the following section.
The invoicing program defines the order in which the additional functions are
performed and you cannot change this. They are usually performed after the
processing of the source documents.
The invoicing program performs the processing step of account maintenance after
the additional functions, such as activation of open items, creation of additional
documents, charges and documents, in order to be able to clear the new posting
items that have arisen in these invoicing functions. The invoicing functions Dunning
Proposal, Subitems, and Rounding of Final Invoice Amount, however, are
performed after clearing consideration and possible clearing of open items.

(C) SAP AG

180

Surcharges and Discounts

You can use the following functions to charge surcharges and grant discounts for invoices.
Example
You calculate a surcharge for the postage required for sending an invoice in the mail.
You grant a discount of 10% on an invoice.
End of the example.

Selecting Open Items for Additional Functions

Use
Some additional functions integrate FI-CA processes that operate on a selection of open items.

Features
An invoicing function integrated in the invoicing process (such as account maintenance, interest
calculation, or dunning) processes the open items that are to be posted during invoicing or that
have already been posted for the contract account to be invoiced and the related business
partner. For each of these invoicing functions there are Customizing settings for making the
(pre)selection of the open items to be processed.
You define the Customizing settings for controlling these invoicing functions using the posting
areas for controlling the additional functions in Invoicing in Contract Accounts Receivable and
Payable.
The posting areas for item selection are created according to a uniform pattern. The selection is
dependent on the invoicing process (mandatory). It can also be made (optionally) at the level of
the invoicing type and invoicing category and with regard to the transaction of the item.
If, in addition to the mandatory Invoicing Process key field, you also use other key fields
described above to control the item selection, you can also enter an asterisk (*) and, by means of
the access sequence, define the read steps whereby each individual step describes which key
fields are specified and which are read generically.
For more general information about the posting areas, see SAP Note 520127.
If the system finds a valid entry for a selected open item for a process in the posting area for item
selection, then the system decides, based on the selection rule and the grace days, if the item is
processed.
The item selection also controls which open amounts of the line items are to be included in the
determination of the final invoice amount.
For each of these processes, there is also an event for customer-specific item selection. You can
use this to override the Customizing settings defined for the item selection in the posting area.

Example
In invoicing process 01, regardless of the invoicing type and invoicing category, you want to:
Print only items that are due within 14 days (from document date of invoicing)

(C) SAP AG

181

Not print cash security deposit payments (represented by the transaction 0020 0010 in
the example)
Print payments on account (transaction 0060 0010) independently of their due date and
include them in the final invoice amount
In the Customizing activity Item Selection for Invoice Display (Subitems) (posting area 2635),
define the following specifications:
Inv.Process

Main
Transaction

Subtransaction

OI Selection

01

Grace

Rel.to Final
Amount

14

01

0020

0010

01

0060

0010

9
999

If you want item selection to be dependent on the invoicing type and invoicing category, you have
to use these key fields with the definition of the access sequence.

Charges and Discounts

Use
The function Charges and Discounts supports the levying of charges and the granting of
discounts in Invoicing in Contract Accounts Receivable and Payable. It enables you to calculate
charges or discounts on a base amount and post them in Contract Accounts Receivable and
Payable (FI-CA).

Features
With the function Charges and Discounts, from a base amount, you can calculate scaled or
blocked percentage charges and discounts, maximum or minimum charges and discounts, or a
combination of fixed and percentage charges and discounts.
You define the rules for calculating charges and discounts under the charge and discount key.
When you configure the charge and discount key, you define the calculation rules for the charge
to be made or the discount to be granted, dependent on the amount limits of the base amount.
By means of the indicator Charge/Discount is Block Charge/Discount, you specify if the system
interprets these amount limits as block limits or scale limits. If the indicator is set, the amount limit
is treated as a block limit. If the indicator is not set, the amount limit is treated as a scale limit.
During the calculation of a block charge/discount, the system breaks down the base amount into
the smaller amounts that are specified by the amount limits. Then the system applies the
calculation rule that is applicable for each of these amount limits.
When calculating a scale discount, the system only applies the calculation rule for the amount
limit in which the entire base amount falls.
The following example illustrates the configuration of block and scale discounts.
You define a key for a block discount that has the following amount limits for
the final invoice amount:

(C) SAP AG

182

Invoice Amount From

Discount Amount

100.01

10 %

200.01

5%

500.01

25

900.01

10

Based on this configuration, the system calculates the discount for a final
invoice amount of 750 as follows:
For the first 100.00 no discount is granted.
For the next 100.00 that fall between the limits of 100.01 200.00, a total
discount of 10 is granted.
For the next 300.00 that fall between the limits of 200.01 500.00, a total
discount of 15 is granted.
For the remaining 250.00 a flat discount of 25 is granted.
So for a final invoice amount of 750 , a total discount of 50 is granted.
The indicator Charge/Discount Is Block Charge/Discount is not set. You
define a key for a scale discount with the same amount limits as in the
example above for a block discount.
Based on this configuration, the system determines that the amount falls in
the scale between 500.01 and 900.01 for a final invoice amount of 750 .
Based on that, a total discount of 25 is granted.
As long as the base amount for determining charges and discounts is calculated from the
amounts of the open items, you can select these items in Customizing for Contract Accounts
Receivable and Payable under Integration
Invoicing in Contract Accounts Receivable and
Payable Invoicing
Invoicing Processes
Additional Functions
Define Item Selection for
Determination of Base Amount for Charge/Discount.
In a customer module, you can also implement an alternative base amount determination.
The charges or discounts are posted in FI-CA and displayed in the invoice. For these posting
documents, the reference document types 0CHG or 0DIS are used in the invoicing document.
In the invoicing document, the charge and discount items have type of invoicing item 0CHARGE
or 0DISCNT. These items can be considered in the final invoice amount.
There is an optional history management for the business partner items that have been included
in the calculation of the base amount.
Several charges and discounts can be posted in one invoicing.
You can assign the charge and discount keys to the invoicing process in Customizing for Contract
Accounts Receivable and Payable under Integration
Invoicing in Contract Accounts
Receivable and Payable
Invoicing
Invoicing Processes
Additional Functions
Assign
Charge and Discount Keys.
You can define that charges or discounts for a contract account are calculated
with a specific time interval. This enables you to prevent charges and discounts
being calculated every time you run the invoicing process for the contract account.

(C) SAP AG

183

Individual Charges and Discounts

The function Individual Charges and Discounts supports the levying of charges and the granting
of discounts in invoicing that you enter on an individual basis at the contract account level. Using
this function, you can calculate charges or discounts on a base amount and post them in Contract
Accounts Receivable and Payable.

Features
The invoicing function Individual Charges and Discounts provides the same scope for calculating
charges and discounts as provided in the invoicing function Charges and Discounts.
You can enter charges and discount keys individually in the contract account and assign them to
an invoicing process. (See Customizing for Contract Accounts Receivable and Payable under
Integration Invoicing in Contract Accounts Receivable and Payable Invoicing Invoicing
Processes Additional Functions Assign Charge and Discount Keys .)
The system posts the individual charges or discounts in Contract Accounts Receivable and
Payable and displays them in the invoice.
The invoicing document uses the reference document types 0CHG or 0DIS for the posting.
The individual charge and discount items are designated in the invoicing document as items with
the type of invoicing item 0CHARGE2 or 0DISCNT2. These items can be considered in the final
invoice amount.
For individual charges and discounts, there is an optional history management for the business
partner items that have been included in the calculation of the base amount.
In one invoicing, you can calculate and post multiple individual and general charges and
discounts.
You assign charge and discount keys to an invoicing process while entering a processing
sequence. In Customizing for Contract Accounts Receivable and Payable, choose Integration
Invoicing in Contract Accounts Receivable and Payable Invoicing Invoicing Processes
Additional Functions Assign Charge and Discount Keys .

Debit Entry of Statistical Documents

Use
Using this additional function, you can enter the statistical line items of Contract Accounts
Receivable and Payable (FI-CA) as debits in Invoicing. This results in real receivables that are
posted with the posting date, document date, and due date of the invoice.

Features
If the function Debit Entry of Statistical Documents has been activated in the invoicing process,
statistical posting items posted with statistical indicator G can be posted as receivables. This
results in a debit entry document with posting date, document date, and due date of the invoice.
For this document, the reference document type 0DEB is used in the invoicing document.

(C) SAP AG

184

The debit entry items posted are shown in the invoicing document as items with type of invoicing
item 0DEBSTAT. These items can be considered in the final invoice amount.
The statistical items are cleared by the debit entry.
You can select the open statistical items to be posted as receivables in the Implementation Guide
for Contract Accounts Receivable and Payable under: Integration
Invoicing in Contract
Accounts Receivable and Payable
Invoicing
Invoicing Processes
Additional Functions
Define Item Selection for Debit Entry of Statistical Documents.
You can use event 2625 for a finer control of the item selection.

Calculating Interest on Open Items

Use
Using this function, you can calculate interest on open due items from Contract Accounts
Receivable and Payable in Invoicing.
You can calculate interest both for open items posted before the invoicing, and for items that
were entered in the current invoicing where the due date for net payment was backdated to
before the document date.

Prerequisites
You have made the necessary system settings for interest calculation in Contract Accounts
Receivable and Payable. (See Customizing for Contract Accounts Receivable and Payable under
Business Transactions
Interest Calculation
Item Interest Calculation.)

Features
You can select the open items for which interest is to be calculated in invoicing in Customizing for
Contract Accounts Receivable and Payable under Integration
Invoicing in Contract Accounts
Receivable and Payable
Invoicing
Invoicing Processes
Additional Functions
Define
Item Selection for Calculation of Interest on Open Items. You can use event 2620 for finer control
of the item selection. Here you can also define whether the interest item is to be posted
statistically or as a real item (relevant for the general ledger).
If you calculate interest on open items, the system creates interest documents with the posting
date, document date, and due date of the invoice. In the invoicing document, this posting
document uses the reference document type 0INT. The interest items are indicated in the
invoicing document as items with type of invoicing item 0INT_DEB. You can consider these items
in the final invoice amount. You can clear the interest documents in the integrated account
maintenance in invoicing. They can be reversed with the FI-CA document reversal independently
of the invoice reversal.
The calculation of interest on receivables cleared before invoicing is not
supported.

(C) SAP AG

185

Calculation of Interest on Cash Security Deposits

Use
You can use the Calculate Interest on Cash Security Deposits function to calculate interest on
cash security deposit payments for the contract account in Invoicing.

Features
You can select the cash security deposit payments for which interest is to be calculated in
invoicing in Customizing for Contract Accounts Receivable and Payable under Integration
Invoicing in Contract Accounts Receivable and Payable
Invoicing
Invoicing Processes
Additional Functions
Define Item Selection for Calculation of Interest on Cash Security
Deposits.
You can use event 2622 for finer control of the item selection. Here you can also define whether
the interest item to be posted is to have clearing restriction 2.
If interest is calculated on cash security deposits, the system creates interest documents with the
posting date, document date, and due date of the invoice. You can define whether the interest
items are to have a clearing restriction.
In the invoicing document, the interest document receives the reference document type 0INT.
The interest items are indicated in the invoicing document as items with type of invoicing item
0INTSDEP. These items can be considered in the final invoice amount.
You can clear the interest documents in the integrated account maintenance in invoicing. They
can be reversed with the FI-CA document reversal independently of the invoice reversal.

Releasing/Adjusting Cash Security Deposits

Use
Using this function in billing you can:
Release cash security deposits for clearing and payment
Adjust cash security deposits amounts (for example, dependent on the consumption
behavior of the customer)

Features
The following options are supported:
Release Without Check
This means that the cash security deposit and related cash security deposit interest are
transferred to payments on account.
This function is only applicable to cash security deposits and interest that were not
previously released explicitly; this means items that have been assigned the clearing
restriction 2.
Unpaid cash security deposit requests are cancelled.
Release When 'Valid For' Date is Reached:
The same applies to this function as for the option described above, however with the

(C) SAP AG

186

'valid for' date of the cash security payment and the creditworthiness of the business
partner being taken into account.
Set the choice of cash security payments that are to be released in invoicing and the
determination of whether the release is to be made with or without a prior check in the
Implementation Guide of Contract Account Receivable and Payable under Integration
Invoicing in Contract Account Receivable and Payable
Invoicing
Invoicing Processes
Additional Functions
Defining Settings for Releasing Cash Security Payments. Event 2623 is
available for fine-tuning item selection.
If the cash security deposit is to be adjusted in invoicing then you can set the height of the cash
security deposit amount or the height of the cash security deposit receivable using event 2623
named above.
The posting documents produced as a result of this invoicing function are connected to the
invoicing document by reference document type 0SEC.
Released cash security deposits and cash security deposit interest are indicated in the invoicing
document as items with invoicing item type 0SEC_REL. These items can be taken into account in
the final bill amount.
Cash security deposit receivables are indicated as items with invoicing item type 0SEC_REQ.
These items can be taken into account in the final bill amount.
Cancelled cash security deposit requests are indicated as items with invoicing item type
0SEC_REV. These items are not taken into account in the final bill amount.

Activating Line Items Posted Before Invoicing

Use
Using the invoicing function Activate Open Items, you can request preselected open items from
Contract Accounts Receivable and Payable (FI-CA) for invoicing when invoicing is performed.
You can use this invoicing function for the following scenarios:
...

1. You want to request certain items posted between two invoice dates along with the regular
invoice (for example, dunning charges). It is not necessary to send separate
correspondence to the business partner for these items.
2. You want to use invoicing to create correspondence for certain items (such as requesting
an installment plan request).
In both cases, the items have clearing restriction (8) Items cannot be processed until next regular
invoice.

Features
Invoicing removes the clearing restriction from items of this kind and adjusts the due date to the
due date of the invoice. The items are displayed in the invoice and the amounts are considered in
the final invoice amount. The items can be paid with the invoice.
For installment plans and repetition documents, the clearing restriction has the effect that each
invoicing requests the next installment or repetition item.
You specify which open items receive clearing restriction 8 when they are entered by using
posting area 2627. In Customizing for Contract Accounts Receivable and Payable, choose

(C) SAP AG

187

Integration
Processes

Invoicing in Contract Accounts Receivable and Payable

Invoicing
Additional Functions
Preselect Items for Activation in Invoicing.

Invoicing

With regard to the selection behavior of the items to be activated in invoicing, the system
supports the following options:
Selection using the invoicing order (table DFKKINV_TRIG)
If you want certain open items that are to be activated to be able to trigger invoicing
themselves, there must be an invoicing order of the source document category ACTIT for
these items.
The invoicing order can then be created automatically when the open item to be activated
is posted. This is controlled by means of posting area 2627.
As a result, the items are activated by the invoicing processes that can process the source
document category ACTIT.
Selection without invoicing order
The system does not create an invoicing order for open items that can be selected in
invoicing without being able to trigger invoicing. This is controlled by means of posting area
2627.
You can select the items to be activated in invoicing in Customizing for Contract Accounts
Receivable and Payable under Integration
Invoicing in Contract Accounts Receivable and
Payable Invoicing
Invoicing Processes
Additional Functions
Define Item Selection for
Activation. You can use event 2628 for finer control of the item selection.
In the invoicing document, invoicing items with type of invoicing item 0ACTITEM or 0ACT_IPL
and the reference document type 0ACT are created for the posting items activated.
Use the clearing restriction explained above only if you have defined and
regularly execute at least one invoicing process that includes the invoicing function
for activating these items.
Function module FKK_INV_ACTIT_SAMPLE_0042 interprets the settings of posting
area 2627 in event 0042. For the settings to take effect, you have to assign this
module to event 0042 provided the module is not already defined as an industry
module (see Customizing for Contract Accounts Receivable and Payable under
Program Enhancements
Define Customer-Specific Function Modules).
The system processes event 0042 only in company codes for which the indicator
Include All Receivables in Total Invoice is set. (See Customizing for Contract
Accounts Receivable and Payable under Organizational Units
Set Up Company
Codes for Contract Accounts Receivable and Payable.)

Example
An interest receivable posted between two invoicings is to be invoiced to a customer with the next
invoicing and paid.
During posting the system assigns clearing restriction 8 to the interest receivable, so that clearing
the item is not possible.
With the creation of the invoice, you inform the customer of the interest receivable. The final
invoice amount contains the interest amount. It is due with the invoice.

(C) SAP AG

188

Transferring Open Items

Use
You can use this invoicing function to transfer post open items from any contract accounts to the
contract account to be invoiced.
You can continue processing the posting items resulting from this transfer during invoicing, for
example clearing the items during account maintenance in invoicing.

Features
The invoicing function integrates the standard business transaction for transferring open items in
Contract Accounts Receivable and Payable with the invoicing process.
In event 2633, you select the items to be transferred to the contract account being invoiced.
The invoicing program then creates a transfer document for these items. Reference document
type 0TRA is used in the invoicing document to reference this posting document.
The newly created posting items are marked in the invoicing document as items with the invoicing
item type 0TRANSFR. You can replace this value with a value of your own, for example
according to the transfer reason, in event 2633.

Automatic Account Maintenance

Use
Using the invoicing function Automatic Account Maintenance, you can clear line items posted in
Invoicing with other open items of the contract account.

Features
The integration of automatic account maintenance in Invoicing means that you can clear invoice
receivables or credits posted in Invoicing with other receivables or credits of the contract account.
Clearing postings take place; the system creates a clearing document. In the invoicing document,
this posting document receives the reference document type 0ACM. The cleared items posted
before invoicing are indicated in the invoicing document as items with type of invoicing item
0ACCTMNT. These items can be considered in the final invoice amount. You can follow the item
clearing in the account balance display.
You can select the open items for the clearing analysis in the Implementation Guide for Contract
Accounts Receivable and Payable under: Integration
Invoicing in Contract Accounts
Receivable and Payable
Invoicing
Invoicing Processes
Additional Functions
Define
Item Selection for Account Maintenance.
You can use event 2630 for a finer control of the item selection. Here you can select the
additional statistical items that are to be reversed without follow-on posting.
This selection decides on the participation of the open items in clearing analysis. You decide
whether items are to be cleared or partially cleared either in your module for event 2631 and/or
using the configuration of the clearing control. You assign the clearing type to be used for account
maintenance to each invoicing type (maintenance using the configuration of the invoicing type).
As standard you can use clearing type 77 (invoicing) as the clearing type. However, you can also

(C) SAP AG

189

use an own clearing type. This must be in the customer namespace and fulfill the following
criteria:
It must be indicated as usable in Invoicing
It must be permitted for account maintenance
Posting Several Clearing Documents
Normally, clearing takes place in a single clearing document. However, you can also
create several clearing documents in one invoicing unit. You group the items in
event 2630. You can process the clearing in event 2631. This is processed before
the call of the clearing control. For more detailed information, see the
documentation for events 2630 and 2631.
You can reverse the clearing document with the FI-CA document reversal
independently of the invoice reversal.
The invoicing program performs the processing step of account maintenance after the additional
functions, such as activation of open items, creation of additional documents, charges and
documents, in order to be able to clear the new posting items that have arisen in these invoicing
functions.

Example
With this function, you can clear the invoice amount with a payment on account or an invoice
credit with an open old receivable.

Manual Account Maintenance (Dialog Call)

Use
The invoicing function Account Maintenance in Dialog ensures that, in Invoicing, a dialog for
processing open items is processed that permits the user to process the automatic clearing
proposal manually.

Features
You can activate the invoicing function Account Maintenance in Dialog in expert mode in
Invoicing in Contract Accounts Receivable and Payable in individual processing. The function
corresponds to the invoicing function account maintenance, with the exception that manual
clearing processing is possible. In dialog, items are offerd that were created during the current
invoicing but that have not yet been posted. In the dialog, you can recognize these items from the
temporarily assigned document number that starts with // followed by the reference document
type of the related posting document and a sequential number.
Document number //0BIL/00001 states that this is a posting document for a
billing document that was processed during the current invoicing.

Enhanced Automatic Account Maintenance

(C) SAP AG

190

The invoicing function Enhanced Automatic Account Maintenance is essentially the same as the
Automatic Account Maintenance invoicing function, except that it supports cross-business partner
and cross-contract account clearing postings.

Features
Using this function in invoicing, you can :
Clear the bill receivable by applying credit from other contract accounts
Use a credit memo being posted to clear receivables from other contract accounts
The standard invoicing program only selects open items of the contract account or business
partner to be invoiced.
In event 2630, you can select open items from alternative contract accounts or business partners
participating in the clearing analysis.
The system designates the items of alternative contract accounts or business partners that are
considered during clearing as items with invoicing item type 0ACCTMTX in the invoicing
document. The alternative master data reference is stored in the Alternative Contract Account
and Alternative Business Partner fields.
Note
As an alternative to, or in addition to this invoicing function, the Transfer Open Items invoicing
function is also available.
End of the note.

Enhanced Manual Account Maintenance

The Enhanced Manual Account Maintenance invoicing function is essentially the same as the
Manual Account Maintenance function, except that it allows the creation of cross-businesspartner and cross-contract-account clearing proposals within an invoicing document.

Features
In manual clearing processing, you can select and add open items that do not belong to the
contract account or business partner being invoiced. For these items, you can create a clearing
proposal that differs from the cross-business-partner or cross-contract-accounts clearing
proposal.
Invoicing, when called in dialog mode, processes the Enhanced Manual Account Maintenance
invoicing function. This function provides you with the option of manually processing the clearing
proposal afterward. You can select items of alternative contract accounts or business partners in
the dialog.
In event 2630, you can define which open items of which alternative contract accounts or
business partners are allowed to be selected manually for the invoicing contract account or
business partner.

(C) SAP AG

191

Reversal of Statistical Line Items

Use
With the invoicing function Reverse Statistical Line Items, you can reverse statistical line items
without follow-on postings.

Features
The invoicing function Reverse Statistical Line Items enables you to clear statistical line items
such as dunning charges, returns charges, and debit interest without postings in the general
ledger. You can activate a statistical line item for the reversal without follow-on posting in event
2630. Alternatively, you can reverse it by means of clearing control in the account maintenance
integrated in Invoicing.
The invoicing document items created by this function have the type of invoicing item 0REVSTAT.
Note that you can only select statistical line items with statistical indicator G for
processing.

Example
You can post statistical line items to provide information about charges such as dunning charges,
returns charges, and debit interest on the invoice even if these are to be canceled as soon as the
main receivables are paid. When issuing invoices, you can reverse these items by activating the
invoicing function Reverse Statistical Line Items in a relevant invoicing process.

Subitems
Use
With the invoicing function Subitems, you can display selected open items that were posted
before invoicing on the current invoice for information purposes.

Features
You can select the open items for the invoice display in the Implementation Guide for Contract
Accounts Receivable and Payable under Integration
Invoicing in Contract Accounts
Receivable and Payable
Invoicing
Invoicing Processes
Additional Functions
Define
Item Selection for Invoice Display (Subitems). You can use event 2635 for a finer control of the
item selection. Here you can also define whether the selected subitems are to be considered in
the final invoice amount and whether they are to be deferred until the invoice due date. The
deferral enables you to have the subitems paid with the other posting documents of this invoice
regardless of their actual due date.
In the invoicing document, the subitems have invoicing item type 0HIST_IT.
The reference to these postings items in the invoicing document is with reference document type
0HIT for items relevant for the final invoice amount, and OHIS for items whose open amounts are
not to be considered in the final invoice amount.
In the final invoice amount, only items that have no clearing restriction can be
considered.

(C) SAP AG

192

Note that the due date of the open items does not change, even if you included the
subitems in the invoice balance on the invoice and thereby, under certain
circumstances, print a new due date for the open items.

Example
Print the last still unpaid invoice on the current invoice.

Setting Installment Plan to Due

Using the invoicing function Set Installment Plan to Due, you can have the system set all
installments of an installment plan, which are not yet due at the time of invoicing, to have the
same due date as the invoice.

Features
You can use this invoicing function during invoice creation (for example, issuing a final invoice) to
set all receivables of an installment plan to have the same due date as the invoice amount.
If this invoicing function is active during invoicing of a contract account, then the system
automatically sets all installment plans of this contract account to be due with the invoice.
At event 2730, you can program criteria for deciding if the installment plan should be set to due.
If the invoicing document is reversed, then the installments receive their original due dates again.
Note
You can use this invoicing function rather than manually canceling the installment plan.
End of the note.

Writing Off
Using the invoicing function Write Off, you can write off open receivables or credits in invoicing.

Prerequisites
To be able to use the invoicing function Write Off, you have made the necessary system settings
for writing off in Contract Accounts Receivable and Payable.
You can write off receivables if:
You are certain the business partner will not pay the receivable
The costs of collection exceed the amount due

(C) SAP AG

193

Features
Along with receivables, you can write off credits that you cannot pay out to customers.
In the standard system, invoicing does not write off any open items. Instead, you can select items
to be written off on a customer-specific basis using event 2735.

Dunning
Use
Using the invoicing function Dunning, you can dun due open items of the contract account within
the framework of invoicing. Using this approach allows you to send the dunning notice together
with the invoice, so that separate correspondence for dunning is unnecessary.

Features
Invoicing processes the Dunning function after integrated account maintenance in order to
consider possible clearing of open items due.
The system groups together the due items for dunning, and if applicable, determines the next
highest dunning level for these items.
You can only set dunning levels in invoicing that are allowed for invoicing.
The successful creation of a dunning proposal is the prerequisite for printing a dunning text during
the creation of the billing form. For this, the system updates a dunning counter in the invoicing
document header.
Keep in mind that invoicing does not perform any dunning activities. Instead,
the invoicing program simply sets the print date in the dunning history. Therefore,
for invoicing, you should not use any dunning levels that trigger dunning activities.
Note in particular that you cannot post dunning charges with the Dunning invoicing
function.

Payment Forms
Use
The invoicing function Payment Forms assigns a payment form number. It is defined in the
invoicing document and can be printed on the invoice.

Features
In invoice correspondence, you can send a payment form to the business partner. This groups all
open items that are considered in the final invoice amount. When the customer pays with the
payment form, you can select these open items using the payment form number.
To create a payment form in Invoicing, you have to activate this invoicing
function in the invoicing process and activate payment form determination in the
Implementation Guide for Contract Accounts Receivable and Payable under
Integration
Invoicing in Contract Accounts Receivable and Payable
Invoicing
(C) SAP AG

194

Invoicing Processes Define Specifications for Payment Method/Payment Form

Control. Here you can activate differentiated by the +/- sign of the invoice amount
and the cash payer/direct debit payer criteria of the payer.

Payment History
Use
You can print various documents on the invoice for information purposes to document payments
received since the last invoice.

Features
The payment history is mapped using events 2655 and 2656.
For event 2655, you can define, for a specific invoicing document or invoicing unit, what is to be
understood as the last relevant invoicing. For orientation, a table with all possible invoicing
document headers for the current invoicing and either the current invoicing document header
being processed (if the module is called during invoice printing) or the general data part of the
current invoicing unit being processed is transferred to the module. From this table, you can
determine the last relevant invoicing document for further consideration and return it. If no
document is determined in this event, the last invoicing document header created is used for
further processing, whereby you can define whether reversed documents and the reversal
documents are to be considered here and in further processing.
Alternatively, you can determine a date and time yourself. In this case, this data is the basis for
further processing. This means that in further processing, the system assumes that the last
relevant invoicing document has this creation data, regardless of whether invoicing took place at
this time.
With this data or with the time of creation of the document selected as last invoicing document,
various posting documents are selected in Contract Accounts Receivable and Payable (FI-CA)
all documents that had arisen up until this time and were cleared afterwards, all open documents
created after this time, and all security deposits. These documents are then transferred to the
module defined for event 2656. In this module the documents that are to appear as information
on the invoice are selected. If, for example, there are several contracts for a contract account,
and these are always invoiced separately, you can also separate the payments here accordingly.

Determination of the Payment Method

Use
You can use the invoicing function Payment Method Determination to determine a payment
method in accordance with the specifications in the contract account.

Prerequisites
You have activated the invoicing function Payment Method Determination in the relevant invoicing
process and made the corresponding system settings for the automatic determination of the
payment method in Contract Accounts Receivable and Payable (FI-CA).

(C) SAP AG

195

Features
The invoicing function Payment Method Determination supports payment method determination
based on the final invoice amount. If the final invoice amount is a receivable, Invoicing in Contract
Accounts Receivable and Payable tries to determine an incoming payment method. The incoming
payment method defined for the customer in the contract account, amount limits defined in
Customizing, and any incoming payment locks maintained in the contract account influence the
determination of the relevant payment method.
If the final invoice amount is a credit, Invoicing in Contract Accounts Receivable and Payable tries
to determine an outgoing payment method. The required outgoing payment methods defined for
the customer in the contract account, a prioritization of the outgoing payment methods to be
used, amount limits from Customizing, and outgoing payment locks that can be set in the contract
account influence the determination of the outgoing payment method.
The payment method determined is transferred to the invoicing document header. However, the
posting documents created during invoicing do not receive the payment method determined; this
enables payment together with other open items for the contract account. The items are
interpreted again by the payment run.
You can also use event 2641 to determine the payment method on an industry or customer basis
and, if necessary, to set a payment method at business partner item level. You can also exclude
the final invoice amount from payment until the next invoice.
Note that the payment method determined in Invoicing in Contract Accounts
Receivable and Payable is not automatically transferred to the individual business
partner items. This is because both the new business partner items to be posted
and the business partner items posted before invoicing (subitems) can be
considered in the final invoice amount. In Invoicing in Contract Accounts Receivable
and Payable, you cannot change the payment method in items that have already
been posted.
However, if you want to set a payment method in the new business partner items to
be posted, you can do this in event 2641 by setting the payment method in the
individual items (parameter PYMET_2641).

Official Document Number Assignment

Use
In some countries, an official document number is used to present documents and invoices to
end customers and the tax authorities. These official numbers are usually in a format defined
explicitly by the respective governments or controlling authorities and can consist of numbers and
letters.

Features
In Invoicing, the official document number is determined by a standard module of Contract
Accounts Receivable and Payable (FI-CA) that stores the exact determination in event 1190. To
enable you to recognize that this module is called from Invoicing in Contract Accounts Receivable
and Payable, it is given parameter I_CALLID = F.
For event 1190, SAP provides sample modules for solutions in Argentina, Brazil, Portugal, and
Italy. The document number determined is used for the posting documents created in Invoicing or
in the reversal and for the invoicing or reversal document. The official document numbers are

(C) SAP AG

196

stored in table DFKKEXTDOC. You can recognize the official document numbers created in
Invoicing in Contract Accounts Receivable and Payable by the indicator EXKID = 01.

Rounding per Posting Document

Use
Using the invoicing function Rounding per Posting Document, in Invoicing you can carry out
currency-specific rounding. In some countries, this rounding is required due to the currency used
in payment transactions.

Prerequisites
In Contract Accounts Receivable and Payable (FI-CA), you have defined the rounding rules for
currencies.

Features
With the invoicing function Rounding per Posting Document, you can round each posting
document such that the amounts are posted in multiples of the smallest currency unit and not the
currency unit itself. For example, cash payments can be made in currencies for which the
smallest coin (for example 5 Rappen) is larger than the smallest currency unit (1 Rappe).
The rounding amounts are posted to the customer account as rounding differences and written off
as revenue/expense as amount rounding.
In the invoicing document, the items created by the invoicing function Rounding per Posting
Document have the type of invoicing item 0ROUNDCU.

Rounding per Invoicing Document

Use
Using the invoicing function Rounding per Invoicing Document, you can round the final invoice
amount according to the rules defined in the rounding key.

Prerequisites
The rounding of the final invoice amount is only supported in an invoicing process if the invoicing
function Rounding per Invoicing Document is activated in this invoicing process and a rounding
key is assigned to the invoicing process.
Rounding items from the old invoice are released regardless of whether the
invoicing function Rounding per Invoicing Document is activated in this process. It is
only necessary that a rounding key that permits the release of the rounding item
from the old invoice is assigned to the invoicing process.

Features
You can write the rounding amount off as a small difference or leave it in the contract account
and consider it in the next invoicing. If a rounding amount is to remain in the contract account, the
corresponding posting item has clearing restriction I. The clearing restriction has the effect that
(C) SAP AG

197

the item cannot be processed until the contract account concerned is invoiced again (no clearing,
no dunning, no interest calculation). In the next invoicing, the clearing restriction is removed from
the rounding item; the rounding amount is considered in the final invoice amount of this invoicing.
In addition to the rounding rules, you can also define the minimum amounts for invoice receivable
and invoice credit for invoice payment. If these amount limits are not reached, the invoice amount
is rounded to zero and the difference amount either written off as a small difference or considered
in the next invoice. You can also configure that for rounding to zero, in Invoicing, all open items
included in the final invoice amount and the rounding item are cleared against each other in a
clearing document.
In the invoicing document, the items created by the invoicing function Rounding of Final Invoice
Amount have the type of invoicing item 0RND_NEW. The rounding item from the previous invoice
has the type of invoicing item 0RND_OLD. If the rounding amount was written off as a small
difference, the corresponding item in the invoicing document has invoicing item type 0RND_TOL.

Creation of Additional (Customer-Specific/IndustrySpecific) Documents

Use
Using the invoicing function Creation of Additional (Customer-Specific/Industry-Specific)
Documents, you can create additional (customer-specific/industry-specific) posting documents
that are integrated into the invoicing document.

Prerequisites
Customer-specific documents are only posted in an invoicing process if the invoicing function
Creation of Additional (Customer-Specific/Industry-Specific) Documents is activated in this
invoicing process and there is a corresponding customer implementation for event 2650.

Features
You can define a customer-specific function module as program enhancement for event 2650.
The system executes this customer implementation in an invoicing process if you activate the
invoicing function Creation of Additional (Customer-Specific/Industry-Specific) Documents in this
process. With the function module called for event 2650, you can create your own posting
documents in Invoicing in Contract Accounts Receivable and Payable that are integrated in the
invoicing document. You can create the invoicing items for these posting documents yourself, or
have them created automatically by the invoicing program.
In this event you can use the data of the invoicing unit.
You can transfer the tables of posting document headers C_FKKKO_2650_TAB, business
partner items C_FKKOP_2650_TAB, and general ledger items C_FKKOPK_2650_TAB to the
invoicing program. In table C_INVDOC_I_2611_TAB you can transfer the prepared invoicing
items.
You can create one or several documents. You differentiate the documents using the temporary
numbering of documents in field OPBEL.
The invoicing program takes over the posting documents unchanged and checks them for
completeness and consistency.

(C) SAP AG

198

You can use a separate reference document type (field FKKKO_2650-CADOCTYPE) per posting
document.
For each business partner item you can define whether the invoicing program is to create an
invoicing item automatically (by setting the indicator FKKOP_2650-INVDOC_I_REL). You can
also return the invoicing items you create in table C_INVDOC_I_2611_TAB.
For identification and display in the invoicing document, you can also assign the invoicing item
type to the business partner items (in the field FKKOP_2650-ITEMTYPE). You can also decide
whether the amount of the business partner items is to be included in the final invoice amount
(field FKKOP_2650-TOTALREL).
The event is triggered in invoicing before the function modules for account maintenance are
called. The postings documents created in this event are available for clearing, influence the final
invoice amount, and can be displayed in the invoice.
If you create the invoicing items C_INVDOC_I_2611_TAB yourself, make sure
that for each posting document, the balance of the business partners with
TOTALREL (in the field BETRW) agrees with the balance of the related invoicing
items (also with TOTALREL).
Customer-specific documents that were posted with an invoicing are also reversed with the
reversal of this invoicing.

Plausibility Checks for Source Documents

Use
The Source Document Plausibility Checks function supports you in creating clarification cases
[Seite 226] for the source document in Invoicing. You can use the function to determine and run
plausibility checks for a source document and to create clarification cases that belong to
clarification case category 01 according to the result.

Features
Industry- and Customer-Specific Check
You can use the Source Document Plausibility Checks function to check the individual source
documents that are grouped together in an invoicing unit. These checks are industry- and
customer-specific. If the checks outsource a source document on the grounds that it is "not
plausible", the system creates a clarification case with clarification case category 01.
You define the rules for checking the source document under the key Check Source Document.
Check Module
The check itself takes place in a customer-specific check module, which is assigned to the
check key. You can also enter currency-dependent amount or quantity limits for the check key for
different units, which are valid for a given period.
You can use these limit values (a maximum of three) when implementing the customer module.
Their meaning (for example, net or gross amounts) is only defined for the check module.
Function module FKK_SAMPLE_TFK2672 from function group FKKINV_EVENT is available as
a sample module and copying template. For a description of the function and interface, see the
function module documentation.

(C) SAP AG

199

Multiple Check
You run several checks on source documents and can specify the sequence in which the checks
are to be run when you assign them.
Termination of Invoicing Unit and Contract Account Processing
The plausibility check controls whether the system terminates processing of the invoicing unit
only when a document is outsorted, or both invoicing unit and contract account processing.

Activities
The system checks all the source documents in the invoicing unit that belong to one category. If
at least one source document is identified as implausible, the system cancels processing of the
invoicing unit. The system creates a clarification case of category 01 for each implausible source
document, using the source document category and number in the clarification case.
You define the plausibility checks and their assignment to the source document category in
Customizing for Contract Accounts Receivable and Payable under Integration
Invoicing in
Contract Accounts Receivable and Payable
Clarification Processing
Define Checks for
Source Document or Assign Checks for Source Document.

Plausibility Checks for Invoicing Documents

Use
The Invoicing Document Plausibility Checks function supports you in creating clarification cases
for the invoicing document in Invoicing. You can use the function to determine and run plausibility
checks for an invoicing document and to create category 03 clarification cases [Seite 226]
depending on the result.

Features
Industry- and Customer-Specific Check
You can use the Invoicing Document Plausibility Checks function to check invoicing documents
after the invoicing unit has been processed and before the invoicing data is updated. These
checks are industry- and customer-specific. If the checks determine that an invoicing document is
"not plausible", the system creates a clarification case with clarification case category 03.
Check Module
The check itself takes place in a customer-specific check module, which is assigned to the
check key. You can also enter currency-dependent amount or quantity limits for the check key for
different units, which are valid for a given period.
You can use these limit values (a maximum of three) when implementing the customer module.
Their meaning (for example, net or gross amounts) is only defined for the check module.
Function module FKK_SAMPLE_TFK2671 from function group FKKINV_EVENT is available as
a sample module and copying template. For a description of the function and interface, see the
function module documentation.

(C) SAP AG

200

Control Document
The system terminates processing of the invoicing unit. However, you can save the checked
invoicing document as a control document. It documents the invoicing situation that led to the
clarification case, particularly the composition of the invoicing unit.
The checked invoicing document is marked as a control document for the clarification case in the
invoicing document header. This is a simulation document, since no postings are made in
Contract Accounts Receivable and Payable.
You define the rules for checking the invoicing document under the key Check Invoicing
Document.
Multiple Check
You run several checks on invoicing documents and can specify the sequence in which the
checks are to be run when you assign them.
Termination of Invoicing Unit and Contract Account Processing
The plausibility check controls whether the system terminates processing of the invoicing unit
only when a document is outsorted, or both invoicing unit and contract account processing.
The check also controls the update of the control document.

Activities
You define the plausibility checks and their assignment to the invoicing document category in
Customizing for Contract Accounts Receivable and Payable under Integration
Invoicing in
Contract Accounts Receivable and Payable
Clarification Processing
Define Checks for
Invoicing Document or
Assign Checks for Invoicing Document.

Offsetting in Invoicing
Using the invoicing function Offsetting in Invoicing, you can offset preselected amounts for a
contract account for a specific purpose, such as partial bills and down payments, against the
invoice receivable of this contract account. This reduces or completely clears the receivable.

Prerequisites
To be able to use offsetting in invoicing for billing documents from Billing in Contract Accounts
Receivable and Payable, you have to ensure during the configuration of the billable items that the
necessary fields are available. For the data that has to be transferred to the billable items for
offsetting, we provide the interface component Offsetting in Invoicing (INV_OFFSET). You have
to select this interface component when you configure the structure of your billable items. In
Customizing for Contract Accounts Receivable and Payable under Integration Billing in
Contract Accounts Receivable and Payable Maintain Billable Item Classes , you specify
(among other things) the interface components for each billable item class.

(C) SAP AG

201

Features
Offsetting in Invoicing is purely an invoicing function, which, unlike automatic clearing, is not
controlled by clearing control and which does not necessarily lead to a clearing of open items.
The invoicing function Offsetting in Invoicing itself notes the documents to be offset and performs
the offsetting in invoicing. The controlling information for offsetting is contained in the source
document to be invoiced.
The process of offsetting in invoicing is divided into two steps:
1. Preselection for offsetting in the expectation of a following invoice or later offsetting
2. Offsetting of the invoice receivable of the previously preselected items
Both steps affect the same contract account and the same business partner. The system does
not support offsetting across contract accounts. Offsetting is always tied to a specific purpose.
This means that the system identifies both the preselected offsetting items, as well as the actual
invoice receivable that should be offset, using a common offsetting reference key and the
offsetting category.
The posting logic and the offsetting logic are derived from the offsetting procedure. The treatment
of the amounts preselected for offsetting is derived from the offsetting category.
Invoicing supports the following offsetting procedures:
Offsetting procedure 01 (Offset Payments on Request of Down Payments)
During the invoicing of the source document, the system posts down payment requests
that can be paid as part of receivables payment (for example, in the payment run or
payment lot). The system then uses the resulting down payments for offsetting the
invoice receivable (for example, a final invoice). This procedure is suitable for scenarios
in which the payments take place with invoicing (for card payments) or as part of a
subsequent payment run. Invoicing expects a down payment request (positive amount).
Example
o

Statistical budget billing request for the purpose of clearing budget billing
payments with a final invoice

Loading with payment card

End of the example.

Offsetting procedure 02 (Offset Prepayments)
This procedure is suitable for scenarios where no more payment has to be made, but
instead a tax-relevant credit is to be posted directly. Invoicing expects a down payment
(negative amount).
Offsetting procedure 03 (Offset Other Credit)
The procedure is the same as procedure 02 and is suitable for scenarios in which the
credit to be posted is not tax-relevant. Invoicing expects a negative amount (not a down
payment).
Example

(C) SAP AG

202

Scratch-off lottery ticket with credit to be activated

Mobile phone card (preloaded credit that is only applicable for mobile services)

Starting credit for a specific purpose when signing contract (limited to telephony;
for example, not applicable for mobile phone purchase)

End of the example.

Offsetting procedure 04 (Offset Partial Bills)
This procedure is suitable for budget billing scenarios with partial bill budget billing. This
means that successive partial bills are requested that are deducted from the final invoice
amount of a final invoice. Invoicing expects a receivable (positive amount). This can also
be paid with a payment card in invoicing.

Activities
1. If you want to use an offsetting procedure of Offsetting in Invoicing, define an offsetting
category for the offsetting procedure. To do so, in Customizing for Contract Accounts
Receivable and Payable, choose Integration Invoicing in Contract Accounts
Receivable and Payable Invoicing Invoicing Processes Additional Functions
Offsetting in Invoicing Define Offsetting Categories .
Using the OffsT (Total Amount Offset) indicator, the offsetting category controls the
amount to be offset in the invoice. The system interprets this indicator only if the
offsetting amount is greater than the amount of the invoice.
If the indicator is set, the system splits the offsetting item; after clearing the invoice
amount, the remaining amount of the offsetting item is transferred to a credit item.
If the indicator is not set, the down payment item is partially cleared, whereby the still
open partial amount remains on the customer account and can be offset against the next
invoice.
Note
If you use offsetting procedure 04 (Offset Partial Bills), the system interprets the OffsT
indicator as being set.
End of the note.
Offsetting the full amount is especially suited for budget billing scenarios, in which the
final invoice amount is cleared against the budget billing payment. If the budget billing
payment exceeds the invoice amount, the system transfers the remaining amount (for
example) to an open item.
Note
Do not set the OffsT indicator in scenarios in which a starting credit is successively
applied to pay following invoices.
End of the note.
2. Enter the main and subtransactions for the credit items that result from the still open
offsetting amounts from the transfer after offsetting. To do so, in Customizing for Contract
Accounts Receivable and Payable, choose Integration Invoicing in Contract

(C) SAP AG

203

Accounts Receivable and Payable

Functions Offsetting in Invoicing

Invoicing Invoicing Processes Additional

Define Transfer Posting Procedure for Offsetting

Note
This activity is mandatory if you use Offsetting in Invoicing and especially if you have set
the OffsT indicator.
End of the note.

Activating Documents from Revenue Distribution

Using the invoicing function Activate Documents from Revenue Distribution, you can request the
distribution documents that are preselected for invoicing with invoicing.

Features
Along with your own receivables, you can also manage receivables for third parties in Contract
Accounts Receivable and Payable. Revenue distribution ensures that the amounts received are
forwarded to the final recipients for whom they are intended.
Example
In the case of cooperation between authorities, the deregulated telephone market, or in the use of
added value services, a company can accept revenues on behalf of other companies.
A public authority accepts revenues on behalf of another company or public authority.
End of the example.
Documents that contain receivables for third parties are designated as original documents.
Revenue distribution posts distribution documents that show the corresponding amounts for the
final recipient.
You can specify in Customizing if invoicing should activate distribution documents. If you enable
this activation in Customizing, the system assigns clearing restriction 8 (Items cannot be
processed until next regular invoice) to the items of the distribution document when it is posted;
and it creates an invoicing order for them with source document category ACTIT and source
document type 003 (Revenue Distribution). Invoicing then creates invoices for the distribution
documents for each final recipient. Invoicing selects the distribution documents using the
mentioned invoicing orders, and processes them using this invoicing function. The line items
belonging to the documents are shown in the invoice and the amounts are considered in the final
invoice amount.
Depending on your Customizing settings, the system adjusts the due date of the document items
to the due date of the invoice, and removes clearing restriction 8 from the document items. As a
result, you can pay the document together with the invoice. In the invoicing document, for the
items of the distribution document, the system creates invoicing items with type of invoicing item
0ACT_RDI and reference document type 0RDI.

(C) SAP AG

204

Activities
You specify if invoicing should activate distribution documents in Customizing for Contract
Accounts Receivable and Payable under Business Transactions Revenue Distribution
Define Specifications for Invoicing .

Stamp Tax
The invoicing function Stamp Tax enables you to calculate, levy, and post stamp tax in Invoicing
for Contract Accounts Receivable and Payable.

Features
If the invoicing function Stamp Tax is active in the invoicing process, you can calculate and
charge stamp tax on postings relevant for stamp tax in invoicing.
If you pass on the stamp tax to your business partners, a separate posting document is created
with the posting date, document date, and due date of the invoice. This document is designated
in the invoicing document with the reference document type 0BOL. The actual business partner
items posted are shown in the invoicing document as items with type of invoicing item 0BOLLO.
These items can be considered in the final invoice amount.

Activities
You make settings for stamp tax in Customizing for Contract Accounts Receivable and Payable
under Basic Functions Particular Aspects of Taxation Procedure Stamp Tax (Bollo) (Italy)
.
For finer control of the stamp tax calculation in Invoicing in Contract Accounts Receivable and
Payable, you can use event 2657.

Ad Hoc Invoicing
Using the invoicing function Ad Hoc Invoicing, you can perform invoicing also for contract
accounts, for which there is currently no source document to be invoiced.

Prerequisites
If the following prerequisites are met, the system automatically offers the creation of Ad Hoc
Invoicing in the invoicing dialog:
The invoicing function Ad Hoc Invoicing is active in the invoicing process to be
performed.
There are no invoicing orders for the contract account to be invoiced.
Note

(C) SAP AG

205

If during the invoicing of a contract account, no source document is processed, and if the
invoicing document to be created does not contain any invoicing items and posting items,
then the system does not save the invoicing document.
End of the note.

Features
In addition to the invoicing of source documents, an invoicing process allows you to perform
various business transactions for a contract account, such as interest calculation, adjustment and
release of cash security deposits, automatic account maintenance, and listing of open items. You
can also create correspondence letters with an official document number and payment form.
An invoicing process processes only contract accounts for which there is at least one source
document to be invoiced.
Using the invoicing function Ad Hoc Invoicing, you can perform invoicing also for contract
accounts, for which there is currently no source document to be invoiced.

Invoicing Additional Periodic Source Documents

Using the invoicing function Invoice Additional Periodic Source Documents, you can invoice
contract accounts periodically independent of source documents.

Prerequisites
You made the system settings for creating and processing additional periodic source documents
in Customizing for Contract Accounts Receivable and Payable under Integration Invoicing in
Contract Accounts Receivable and Payable Invoicing Invoicing Processes Scheduling
Additional Source Documents for Periodic Invoicing as follows:
In the activity Define Source Document Types for Additional Source Documents you
defined source document types for the additional source documents for the source
document category CYCLE.
In the activity Define Processing Rules for Source Document Types, at the level of the
source document type, you defined rules for creating invoicing orders and for processing
additional periodic source documents in invoicing.
The rules specify grace days that the system takes into account when creating the
invoicing order. In addition, you specify if the invoicing of these additional source
documents should be suppressed if there are no further source documents to be invoiced
or if the invoicing document does not contain any items (zero invoice).
In the activity Define Control for Additional Source Documents, you specified if the
system creates additional periodic source documents.
You can make this specification dependent on the invoicing category and on the billing
cycle.
In the activity Maintain Number Ranges for Additional Source Documents, you defined
the number range intervals for the creation of additional source documents.
The system determines the number range interval using a randomized algorithm.

(C) SAP AG

206

Features
The invoicing function Invoice Additional Periodic Source Documents processes invoicing orders
of the source document category CYCLE, which are created by scheduling in invoicing.
The system creates periodic invoicing orders only for contract accounts to which a billing cycle is
assigned.
For generating periodic invoicing orders, you can use the mass activity Create Periodic Invoicing
Orders.
The mass activity stores a management record that contains data for scheduling (table
DFKKINV_CYCREQ).
If the invoicing function INV_CYCLE is active in the invoicing process to be executed, you can
perform periodic invoicing for contract accounts, for which, aside from the periodic invoicing
order, there is no other source document to be invoiced. You can perform various business
transactions (such as interest calculation, adjustment and release of cash security deposits,
automatic account maintenance, and listing of open items) for this contract account. You can also
create correspondence letters with an official document number and payment form.

Activities
1. To create periodic invoicing orders, on the SAP Easy Access screen, choose Invoicing
Parallel Processing Create Addit. Source Documents for Periodic Invoicing .
2. Enter a date and an ID that you can use to identify the run later.
3. Choose Continue.
4. Limit the data to be processed using the contract account or billing cycle, and, if needed,
enter a date up to which the run is to create periodic orders.
5. Schedule the program run. For more information, see Functions for Scheduling Program
Runs.

Payment Reference
Using the invoicing function Payment Reference, you can generate payment references for
invoicing documents that you can use to select open items of the invoicing document in the
payment lot.

Prerequisites
To be able to generate a payment reference in invoicing, you have activated the invoicing
function mentioned above in the invoicing process.
In addition, you have activated the invoicing function in Customizing for Contract Accounts
Receivable and Payable under Integration Invoicing in Contract Accounts Receivable and
Payable Invoicing Invoicing Processes Define Specifications for Payment Method/Payment
Form Control . Here you configure the activation differently based on the positive/negative sign
of the invoice amount, and based on whether the payer pays in cash or if direct debit is used.

(C) SAP AG

207

Note
For finer control of this configuration, you can use event 2641, where you can remove individual
items from the payment reference or add additional items to the payment reference. You can also
enter payment references there for your own customer-specific or industry-specific payment
reference category.
End of the note.
To be able to generate a payment reference in invoicing for billing documents from Billing in
Contract Accounts Receivable and Payable, you have to ensure during the configuration of the
billable items that the necessary fields are available. For the data that has to be transferred to the
billable items for a payment reference, we provide the interface component Payment Reference
(PAYM_REF). You have to select this interface component when configuring the billable item
class. In Customizing for Contract Accounts Receivable and Payable under Integration Billing
in Contract Accounts Receivable and Payable Maintain Billable Item Classes , you specify
(among other things) which interface components are used for each billable item class.

Features
In the standard system, the invoicing function Payment Reference creates a payment reference
of the category Invoicing Document (Reference Category 003), whose reference number is the
same as the number of the invoicing document. Using this reference, you can select all open
items in the payment lot or in the cash desk that were considered in the final invoice amount.
If information for a payment reference is entered in the payment data item of the billing document,
the system automatically generates payment reference records for the posting items of the billing
document regardless of whether the invoicing function Payment Reference is active in the
invoicing process.

Card Payment (Payment Method)

Using the invoicing function Card Payment (Payment Method), you can generate payment card
supplements for open items as the basis for processing card payments in the payment run.

Prerequisites
To be able to generate a payment card supplement in invoicing for billing documents from Billing
in Contract Accounts Receivable and Payable, you have ensured during the configuration of the
billable item classes that the necessary fields are available. For the data that has to be
transferred to the billable items for a card payment, we provide the interface component Card
Payment (PCARD_PAYM). You selected this interface component while configuring the structure
of billable items. In Customizing for Contract Accounts Receivable and Payable under
Integration Billing in Contract Accounts Receivable and Payable Maintain Billable Item
Classes , you specify (among other things) which interface components are used for each
billable item class.

Features
With the billing document, you can transfer card data for processing the payment of receivables.
The invoicing function Card Payment (Payment Method) processes this card data by generating

(C) SAP AG

208

payment card supplements (table DFKKOPC) for open items. The payment run then processes
these payment card supplements further.

Card Payment with Immediate Clearing

Using the invoicing function Card Payment with Immediate Clearing, you can enter payments for
open receivables in invoicing using payment cards (for instance, credit cards) and thereby clear
the receivable as part of invoicing.

Prerequisites
To be able to generate a card payment in invoicing for billing documents from Billing in Contract
Accounts Receivable and Payable, you have to ensure during the configuration of the billable
item classes that the necessary fields are available. For the data that has to be transferred to the
billable items for a card payment, we provide the interface component Card Payment
(PCARD_PAYM). You selected this interface component while configuring the billable item class.
In Customizing for Contract Accounts Receivable and Payable under Integration Billing in
Contract Accounts Receivable and Payable Maintain Billable Item Classes , you specify
(among other things) which interface components are used for each billable item class.

Features
With the billing document, you can transfer card data (containing authorization data along with
other data) for immediate payment of the receivable. This card data is processed by the invoicing
function Card Payment with Immediate Clearing. The invoicing function performs the following
activities:
Executes authorization checks
Creates payments with payment card
Updates card data supplements for the contract accounting document (DFKKOPC) for
further processing for the card billing
Clears the receivables immediately

Balance Change of Prepaid Account

The invoicing function Balance Change of Prepaid Account processes changes to the credit on a
prepaid account, such as refills.

Features
You use the invoicing function Balance Change of Prepaid Account for invoicing billing
documents, the items of which contain information for controlling the processing of changes to the
prepaid balance. A billing document item of this kind needs to contain a reference to a prepaid
account and it needs to be designated as a prepaid refill. For these items, the invoicing function
creates invoicing document items as the basis for invoice printing. Depending on the reason for
the balance change, the invoicing function also creates a posting on the prepaid account. The

(C) SAP AG

209

related posting document receives the reference document type 0PPR in the invoicing document.
A posting to a prepaid account is a posting to the assigned contract account, where the number
of the prepaid account is entered along with a reason for the balance change. The entries are
made in the posting item in the fields Prepaid Account (FKKOP-PPACC), Clearing Restriction
(FKKOP-AUGRS) and Reason for Balance Change (FKKOP-PPRSN).
Postings to prepaid accounts are excluded from all other processing, such as dunning, payment,
interest calculation, and clearing. This is ensured because the system sets the clearing restriction
in the FKKOP-AUGRS field to the value K. You can only clear postings to a prepaid account with
postings to the same prepaid account. For this type of clearing, you can use the invoicing function
Account Maintenance for Prepaid Account, for example.
You can refill credit on a prepaid account either with or without a payment being made. For a refill
with payment, the refill amount is the amount that the customer paid. A refill without payment is at
the expense of the service provider. Reasons can include granting of bonus credit when the
contract is renewed or for regularly recurring refills. You can also grant additional credit as a
means of settling a dispute with the customer. You can post paid credit on a prepaid account
either as a tax-relevant down payment received, or as other credit without taxes. The determining
factor for the type of posting is whether you have designated the reconciliation account in the
general ledger as a down payment account. Credit that is credited in other ways is always posted
by the system as other credit on the prepaid account.
The system aggregates usages and posts them using the invoicing function Invoicing of Billing
Documents. This is very similar to billing for postpaid services (for example, billing once a month).
Contract Accounts Receivable and Payable debits usages to the prepaid account. Following the
posting, the system automatically offsets the amount against the existing credit, for instance using
the invoicing function Account Maintenance for Prepaid Account that is activated in the invoicing
process. The handling of consumed prepaid services is very similar to that for postpaid services.
This thereby makes it possible to create invoices for customers, which they can use to claim back
taxes for their costs.
The charging system can calculate prices with up to six decimal places. Due to this and also due
to billing of usage to the second, rounding differences can arise between the exactly managed
totals for usage in the charging system and the accounting view in Contract Accounts Receivable
and Payable. Invoicing rounds the posting amounts to the actual number of decimal places for the
currency. Any rounding differences that occurred are carried forward for each prepaid account
from one invoice to the next.
Example
The first invoice is for an amount of USD 38.5044. Invoicing rounds the amount. This results in an
invoice amount of USD 38.50. The system records USD 0.0044 as a rounding difference.
The next invoice is for a total amount of USD 36.2092. By adding the recorded rounding
difference, the result for the second invoice is a total of USD 36.2136. Invoicing rounds this
amount to USD 36.21 and records USD 0.0036 as a rounding difference.
End of the example.

Account Maintenance for Prepaid Account

(C) SAP AG

210

You can use the invoicing function Account Maintenance for Prepaid Account to maintain prepaid
accounts during invoicing.

Features
The system posts all items to prepaid accounts with clearing restriction K. This includes the
receivables that arise from the usage of services, as well as all refills and other changes to the
credit balance. By activating the invoicing function Account Maintenance for Prepaid Account, you
can offset receivables or credits of a prepaid account posted in invoicing with other receivables or
credits of the same account. Clearing postings are made; the system creates a clearing
document. In the invoicing document, this posting document receives the reference document
type 0PPM. The cleared items posted before invoicing are indicated in the invoicing document as
items with type of invoicing item 0PPACCMT.
Clearing takes place based on the configuration of clearing control for clearing type 2A.
You can reverse the clearing document using the FI-CA document reversal, independently of the
invoice reversal.

Manual Account Maintenance for Prepaid Account

The invoicing function Manual Account Maintenance for Prepaid Account provides a dialog in
invoicing for processing the open items of a prepaid account. This dialog enables the user to
manually process the clearing proposal that was made automatically.

Features
You can activate the invoicing function Manual Account Maintenance for Prepaid Account in
expert mode for invoicing in individual processing.
The function is essentially the same as the invoicing function Account Maintenance for Prepaid
Account, with the difference being that it makes manual clearing processing possible.

Determination of Due Date

Use
Check of and change to invoice due date

Features
To determine the due date, Invoicing in Contract Accounts Receivable and Payable processes
event 1330 in the standard. The due date determined in this event, and, if applicable, the due
date for cash discount (with the relevant cash discount percentage specification) is transferred to
all new posting items created for the invoicing document and to the invoicing document header as
invoice due date. At event 1330, the final invoice amount is not yet known.
In some cases, the due date is already known when the billing documents are created. In these
cases, the due date is used as follows in the invoicing of the billing document:
If the due date is entered in the billing document item, Invoicing uses the value as due
date for the corresponding invoicing document item and posting item.

(C) SAP AG

211

If the due date is not entered in the billing document item, invoicing uses the default value
from event 1330 for the due date of the invoicing document item and posting item.
If all posting items (for example, posting items with reference to billing document items,
interest) created during invoicing have the same due date, this due date is transferred to
the header of the invoicing document.
If there are posting items with different due dates, the default value from event 1330 is
transferred to the header of the invoicing document.
In addition, event 2640 is available in Invoicing in Contract Accounts Receivable and Payable.
With this event, after the determination of the final invoice amount, you can check the due date
originally determined in event 1330 and change it if necessary (after integrated account
maintenance and the creation of subitems).
If posting documents or line items with different due dates are to be posted for the invoicing
document, you can assign the due date per invoicing/posting item in this event.
The invoicing process triggers the determination of the due date automatically.
No invoicing-specific settings are required.

Update
After successful processing of the invoicing unit, consisting of the processing of the assigned
source documents and the execution of the integrated invoicing functions, the final step is to
update the invoicing results to the database.

Process
The update is dependent on the mode of execution you selected for invoicing. If you started
invoicing as a simulation run, in which the invoicing documents are not saved (only possible using
the individual process), there is no data update.
If you started an invoicing simulation, in which the documents are saved, the invoicing document
created for the invoicing unit is updated and a correspondence container is created for invoice
printing. However, there are no postings and no further data from FI-CA is updated. You can
repeat a simulation run as often as necessary; it has no influence on the subsequent invoicing
update run.
In invoicing that is not started as a simulation, in addition to the invoicing document, the system
updates posting documents and possibly further tables from FI-CA that are accessed in the
different additional functions. In that case, the invoicing orders processed in the invoicing unit are
deleted, a correspondence container is created for invoice printing, and an extraction order is
created for the update in BW.
If you want to trigger additional actions when you save the invoicing results, or update further
customer-specific data, you can use events 2647 Transfer Completed Invoicing Document
(Without Document Number) and 2648 Transfer Completed Invoicing Document (with Document
Number). The system processes the event both in an update run and in simulation mode. Keep
this in mind when you update data that is processed in follow-on processes. You should only use
the event to add to the assigned document numbers in the data that is internally recorded in
event 2647 and is to be updated on the database later.

(C) SAP AG

212

Performing Invoicing
With the transaction Invoicing in Contract Accounts Receivable and Payable (Individual Creation),
you can create an invoicing document for individual business partners or for a contract account.
The function is also available as a parallel mass run for large numbers of business partners or
contract accounts to be invoiced.

Procedure
Analysis of Invoicing Orders
You can analyze invoicing orders from the SAP Easy Access screen by choosing Invoicing
Monitoring Invoicing Orders . You can process invoicing orders directly in the output list of
the program. For more information, see the program documentation.
Individual Invoicing: Update Run
1. To perform individual invoicing, on the SAP Easy Access screen, choose
Dialog Processing Create Invoicing Document .

Invoicing

2. Enter an invoicing process and the required contract partner or contract account. If you
specify an invoicing process that also handles collective bills, the system prompts you in
a dialog box to enter a due period (Due By).
3. Run the program.
4. On the following screen, select the source documents to be invoiced. To display a
document, click on the document number.
Individual Invoicing: Simulation
1. On the SAP Easy Access screen, choose
Invoicing Document .

Invoicing

Dialog Processing

Create

2. Enter an invoicing process and the contract partner or contract account.

3. Set the Simulation Run indicator. By setting the corresponding indicator, you can
determine whether the simulation is with or without an invoicing order, and whether the
invoicing document is saved.
4. Run the program.
In the simulation run, individual invoicing only creates simulated invoicing documents; it does not
post documents in FI-CA.
If you select Simulation Run and Without Invoicing Order on the initial screen, instead of the
selection screen for source documents, a dialog box appears where you can enter source
documents and their category.
Expert Mode
If you start individual invoicing in expert mode using the pushbutton
Expert Mode instead of
the pushbutton (Execute), you can use the following processing functions:

(C) SAP AG

213

After you have selected the source documents to be invoiced, you can also group the
documents by invoicing unit.
For each invoicing unit, you can activate or deactivate specific invoicing functions.
In addition, you can also invoice source documents before they have reached their target date for
invoicing.
Mass Invoicing
To create invoicing documents for a large number of business partners or contract accounts in a
parallel run, from the SAP Easy Access menu, choose Invoicing Parallel Processing
Create Invoicing Document . As for individual invoicing, you can also start the parallel run in
simulation mode.
By choosing the pushbutton Further Selections in the application toolbar, you can add additional
selection criteria. You can also restrict the runtime of the mass run. This has the effect that the
run ends if the date and time specified are exceeded. Contract accounts considered up to this
point are processed completely. You can process contract accounts that were not processed
because the runtime ended by starting the run again.

Reversing Invoicing Documents

Use
You can reverse invoicing documents.

Features
The invoicing reversal:
Reverses the invoicing document
The system marks the invoicing document as reversed in the appropriate fields.
Reverses the FI-CA documents posted with this invoicing document
If these postings have already been cleared (by a payment, for example), this clearing can
be automatically reset in the invoicing reversal. You can influence the behavior of the
invoicing reversal for items that have already been cleared in Customizing.
Creates invoicing orders for the source documents processed in the invoicing
This means that you can invoice these source documents again.
Creates a reversal invoicing document
This is the basis for creating the correspondence for the customers concerned.
Invoicing Reversal

(C) SAP AG

214

Runtime
FI-CA
Document

Invoicing Order

Billing
Document

Contract
Account

FI-CA
Document

Reversal

Invoicing
Document

Invoicing
Document

Correspondence
Container

Design Time
Reversal
Parameters

Making System Settings for Invoicing Reversal

Use
In Customizing, you define how the system is to behave in the case of reversals of invoicing
documents whose postings have already been cleared in Contract Accounts Receivable and
Payable (FI-CA).

Procedure
Define the reasons for the reversal of invoicing documents.
To do this, in the Implementation Guide for Contract Accounts Receivable and Payable,
choose Integration
Invoicing in Contract Accounts Receivable and Payable
Invoicing
Reversal Define Reasons for the Reversal of Invoicing Documents and specify the
reasons that lead to the reversal of an invoicing document. You can specify these reasons
as input data in the reversal transactions. However, you do not have to make entries in the
corresponding field - it is only intended to help you understand the invoicing reversal better;
you can also reverse an invoicing document without specifying reasons.
Make the basic settings for the invoicing reversal.
In the Implementation Guide for Contract Accounts Receivable and Payable, choose
Integration
Invoicing in Contract Accounts Receivable and Payable
Invoicing
Reversal Basic Settings for Invoicing Reversal.
In this activity, you define, for each application area and invoicing process, how the system
is to behave in the following situations for reversals:
For individual and for mass processing you define jointly:

(C) SAP AG

215

Whether the reversal date is to be adjusted if the posting period is already

closed
Whether a print document is to be created for a reversal
Whether, when clearing is reset, a new open item is created or the amount is
to be posted to a clarification account
You define separately for individual and mass processing:
For a reversal, whether a reset of clearing or partial clearing of an item
created in the invoicing document to be reversed is to be permitted
Whether the clearing reset also has to be confirmed in dialog
Whether collective invoicing documents may be reversed if they have been
cleared
Whether invoicing documents may be reversed if they have been included in
a collective bill
In order for the settings you make here to be applicable, the invoicing reversal must be
active in the situation concerned.
For the clearing reset, you have the following options:
No clearing reset
If the system determines cleared FI-CA items for the print document, the processing
of this document terminates with a message unless the system has created this
clearing during account maintenance in Invoicing.
Automatic clearing reset
The system automatically resets all cleared FI-CA documents and posts them on
account.
Automatic clearing reset with partial reset
The system behaves as under point 2, but also considers partial clearings.
Confirmation of reset in dialog
The system behaves as under point 2, but the user is informed about the reset
before it takes place and can continue or cancel the reversal once he has looked at
the documents. However, this option is only possible for the individual run.
For collective bills, you can define whether the reversal can be performed even if the
collective bill has already been cleared. Note that the clearing is not reset, even if you
permit the reversal of cleared collective bills. In this situation, the system only indicates the
collective invoicing printout as reversed.
For invoicing documents that refer to other documents (individual invoices for collective
bills), you can define whether a reversal is permitted if the collective bill has already been
created. If you permit this, the corresponding collective bill documents are adjusted without
the collective invoicing document having to be reversed.
Note that in this case, the invoice sent can have a different amount to the underlying
posting documents. If you want to avoid this, configure Customizing such that the individual
invoice cannot be reversed until after the collective bill in which it is included.

(C) SAP AG

216

Performing Invoicing Reversals

Use
You can reverse individual invoicing for a specific business partner, contract account, or invoicing
document.
Use the mass reversal if you want to reverse a larger number of invoicing documents in one
parallel run.

Procedure
Individual Reversal
...

1. From the SAP menu, choose Invoicing

Document.

Dialog Processing

Reverse Invoicing

2. Specify a reversal date and a reversal reason.

3. Specify a business partner or contract account as selection parameter.
4. Run the program.
5. A dialog box appears. Select the invoicing document(s) to be reversed.
As an alternative to specifying the business partner or contract account, you can use the input
help for the Invoicing Document field to select the required document specifically. The input help
for the invoicing document only offers documents that can be reversed for selection.
Mass Reversal
From the SAP menu, choose Invoicing
Parallel Processing
Reverse Invoicing Documents.
The input help for the invoicing document offers all reversible documents for selection.
Using the pushbutton Further Selections in the application toolbar, you can add additional
selection criteria. You can also restrict the runtime of the mass run. This has the effect that the
run ends if the date and time specified are exceeded. Contract accounts considered up to this
point are processed completely. You can process contract accounts that were not processed
because the runtime ended by starting the run again.

Reversing Billing Documents

You can reverse billing documents.

Prerequisites
You made the necessary settings in the activities in Customizing for Contract Accounts
Receivable and Payable under Integration Invoicing in Contract Accounts Receivable and
Payable Reversal of Billing Documents .

Features
The billing document reversal:
Reverses the billing document

(C) SAP AG

217

The system designates the billing document as reversed in the appropriate fields
(number of the reversal document REVERSALDOC).
Creates a reversal billing document
The header of the reversal billing document contains the number of the reversed
document (REVERSEDDOC).
For a billing reversal, the system considers whether the billing document to be reversed was
already invoiced.
If the billing document was not yet invoiced, and no postings were made in FI-CA, then the billing
reversal creates the reversal billing document and designates the original billing document as
reversed. The reversal also deletes the original invoicing order so that the reversed document
can no longer be invoiced. In the header of the billing document, the system sets the Invoicing
Order Deleted indicator.
If the billing document was already invoiced and postings were already made in FI-CA, the billing
reversal reverses the billing document. The original invoicing order no longer exists, since the
billing document was already invoiced. The system also creates a reversal billing document.
For clearing the postings in FI-CA, the reversal billing document contains offsetting items for
clearing the items to be reversed. At the same time, the system creates a new invoicing order, so
that the reversal billing document and the related offsetting items can be posted.
Note
The reversal billing document and the reversed billing document are linked to each other.
You cannot reverse simulated billing documents.
End of the note.
For more information on reversal of billing documents, see Special Features for Reversal of
Billing Documents.

Activities
1. To reverse a billing document, on the SAP Easy Access screen, choose
Dialog Processing Reverse Billing Document .

Invoicing

2. To select the document to be reversed, either enter the document number directly, or
enter the business partner and contract account.
3. Specify a reversal reason.
4. Run the program. To do so, choose the

(Execute (F8)) pushbutton.

5. In the dialog box that appears, select the documents you want and choose Continue.
In the dialog box that appears, the system displays the status of the reversal. Choose the Log
pushbutton to see more information about the reversal transaction.

(C) SAP AG

218

Making System Settings for Billing Reversal

Procedure
In Customizing for Contract Accounts Receivable and Payable under Integration Invoicing in
Contract Accounts Receivable and Payable Reversal of Billing Documents , you specify as
follows how the system behaves when billing documents are reversed.
1. In the activity Define Reasons for Reversal of Billing Documents, you define reasons for
the reversal of billing documents and reasons that lead to the reversal of billing
documents. You can enter these reasons in the reversal transaction as input data. If you
make an entry in this field, you can better track the billing reversal. The system stores the
reversal reason in the header of the reversed billing document.
2. In the activity Make Basic Settings for Billing Reversal, make the basic settings for billing
reversal. For each application area and origin process of the billing document, you
specify there how the system behaves during the reversal of the billing document. You
specify if:
o

The billing document is allowed to be reversed

The billing document is allowed to be reversed if it is already invoiced

The billing document is allowed to be reversed if it is already archived

The billing document is allowed to be reversed, if the document with which it was
invoiced is archived

Note
For billing documents of the origin process Billing in Contract Accounts Receivable and
Payable, in addition to the settings above, you have to make reversal settings for the
billing process with which the billing document being reversed was created.
End of the note.

Reversing Billing Documents

Procedure
To reverse an individual billing for a business partner, a contract account, or a billing document,
proceed as follows:
1. On the SAP Easy Access screen, choose
Billing Document .

Invoicing

Dialog Processing

Reverse

2. Specify a reversal reason.

3. Enter a business partner or contract account as the selection parameter.
4. Run the program.
5. Choose the billing document to be reversed in the dialog box that appears.

(C) SAP AG

219

Instead of entering the business partner or contract account, you can choose the document you
want directly from the input help for the Billing Document field. The input help for the billing
document only offers documents for selection that can be reversed.

Special Features When Reversing Billing Documents

from Billing in FI-CA
You can reverse billing documents that were created by Billing in Contract Accounts Receivable
and Payable. These billing documents are designated as having origin process 0007.
In addition to the functions that are available when you reverse billing documents, the system
stores information in the reversal billing document about the billable items that were processed
with the billing document being reversed. At the same time, the system generates billable items
that you can bill again. You can directly exclude these billable items during the reversal.

Making System Settings for Reversing Billing

Documents from Billing in FI-CA
Procedure
You have specified how the system behaves when reversing billing documents from Billing in
Contract Accounts Receivable and Payable. In Customizing for Contract Accounts Receivable
and Payable, choose Integration Billing in Contract Accounts Receivable and Payable
Reversal of Billing Documents .
In the activity Basic Settings for Billing Reversal, you specified if:
o

The billing document is allowed to be reversed

The billing document is allowed to be reversed if it is already invoiced

The billing document is allowed to be reversed if it is already archived

The billing document is allowed to be reversed, if the document with which it was
invoiced is archived

In the activity Make Specifications for Billing Processes, you have specified how the
system behaves for the reversal of a billing document created with the given billing
process. You specify if:
o

The billing document is allowed to be reversed

The billing document is allowed to be reversed if it is already invoiced

The billing document is allowed to be reversed if the billed items of this document
were already deleted

Note

(C) SAP AG

220

The system considers these settings only if billing reversal is active in the basic settings
for billing reversal for the origin process Billing in Contract Accounts Receivable and
Payable.
End of the note.
In the activity Define Reasons for Reversal of Billing Documents, you entered reasons
that lead to the reversal of billing documents. You can enter these reasons in the reversal
transaction as input data. If you make an entry in this field, you can better track the billing
reversal; the system stores the reversal reason in the header of the reversed billing
document.
You have made specifications for the reversal reason in the activity Make Specifications
for Reversal Reason.
You can specify there, dependent on the reversal reason for the billing document, that
billed items of a billing document cannot be billed again after the document is reversed.
You can choose to have the system not offer billed items with this reversal reason again
for billing, but instead have the system copy them directly to the table of excepted items.
If you do so, you can assign an exception reason to the reversal reason.

Reversing Billing for Documents from Billing in FI-CA

Procedure
To reverse an individual billing for a business partner, a contract account, or a billing document,
proceed as follows:
1. On the SAP Easy Access screen, choose
Document .

Billing

Billing in Dialog

Reverse Billing

2. Specify a reversal reason.

3. Enter a business partner or contract account as the selection parameter.
4. Run the program.
5. Choose the billing document to be reversed in the dialog box that appears.
Instead of entering the business partner or contract account, you can choose the document you
want directly from the input help for the Billing Document field. The input help for the billing
document only offers documents for selection that can be reversed.

Special Considerations for Reversal of Billing

Documents from External Systems
Use
You can reverse billing documents that have been transferred from external billing systems by
sending a reversal information about a billing document to be reversed to Invoicing in Contract
Accounts Receivable and Payable from the external billing system. This is saved in the system as
a reversal billing document.

(C) SAP AG

221

Features
If the billing document to be reversed has not been invoiced, the reversal billing document
ensures that this reversal document and the billing document to be reversed are not invoiced.
If the billing document to be reversed has already been invoiced, you have the following options:
You can also invoice the reversal billing document.
The document is processed in the same way as the reversed billing document, but with
reversed amount and quantity +/- signs. The system creates negative postings for the
posting of the original document.
You can reverse the invoicing document of the billing document to be reversed. In that
case, the system does not create an invoicing order for this billing document for renewed
invoicing, and deletes the invoicing order of the reversal billing document, so that both
billing documents are not invoiced.

Invoice Printing
Purpose
Based on correspondence containers, the print workbench creates invoices or invoice raw data
according to the application form defined for the invoicing process in Customizing.

Prerequisites
You use the correspondence tool and the print workbench and have made the system settings
described under Making System Settings for Invoice Printing [Seite 223].

Process Flow
Invoicing in Contract Accounts Receivable and Payable uses the correspondence type 0042
[Extern].
The invoicing documents are printed as for other print processes in Contract Accounts
Receivable and Payable with the Print Workbench [Extern] using Correspondence Printing
[Extern] (transaction FPCOPARA).
The correspondence printing is triggered by the correspondence containers [Extern]. These
contain the information required for printing (such as application form, recipient, address
numbers, print language) and control the printout.
When you create invoicing documents, Invoicing in Contract Accounts Receivable and Payable
creates a correspondence container for event 2685:
For every posted invoicing document, provided that it does not have a print lock
If an invoicing document is not to be printed, you can put a print lock on it in event 2645
(field PRINTLOCK in the invoicing document header).
For each reversal invoicing document, provided the reversed document has already been
printed
If the document has not been printed yet, in the reversal, the system deletes the
correspondence container of the reversed document.
Generally, there is one container for each invoicing document. If an additional recipient has been
defined for the business partner, the system creates a further container. The system does not
create correspondence containers for simulated invoicing documents, since these are not
supported for mass printing.

(C) SAP AG

222

For the creation of correspondence containers, SAP delivers the sample function module
FKK_SAMPLE_2685. You can use this as a template for your own implementations, and there
should be no differences.
In addition to the standardized data, the correspondence container contains the document
number of the invoicing document in the second correspondence data field for the entity
identification DOCN, and it contains the invoicing process in the first correspondence data field
for the entity identification IPRC.
For each correspondence container, correspondence printing calls up one application form and
creates one print document with this form. If the actual printout was successful, correspondence
printing sets the print date in the correspondence container and in the header of the invoicing
document.
Invoice Printing

Runtime

Master Data

Correspondence
Container

Printing
Process

Invoice

Invoicing
Document

Billing Document

Design Time
Print Form

Displaying Invoices
With the invoicing document, you can also display the simulation of the invoice printing and the
invoice preview. However, the print date and customer-defined fields are not updated. You can
also simulate the invoice for simulated invoicing documents.

Making System Settings for Invoice Printing

Use
To be able to print invoices, you have to make the following settings in Customizing for Contract
Accounts Receivable and Payable under Integration
Invoicing in Contract Accounts
Receivable and Payable (FI-CA).

Procedure
...

(C) SAP AG

223

1. Under Invoicing
Invoicing Processes
Define Application Form, define a unique key for
each application form required for printing invoicing documents.
The application form that you define here must belong to the form class FICA_INVOICE
and must exist in the client concerned, at least as a link. The hierarchy of the form class
FICA_INVOICE contains the data of the invoicing document to which you can add further
print-relevant information in event 2687 [Seite 224].
The application form is determined during invoicing. You can control the determination
dependent on the invoicing process, invoicing type, and other parameters. The system
saves the application form determined in the correspondence container and in the header
of the invoicing document.
You can archive the invoices optically during correspondence printing (see Optical
Archiving of Documents [Extern]).
2. Under Invoicing Processes, define the specifications for determining the application form.
Here you define the determination of the application form for printing an invoicing
document and the determination of a form ID for attached payment media.
For dialog processing (for example, invoice preview), you can also define an alternative
application form in this activity. This can be useful if the actual application form for mass
printing only produces raw data for an external output management system, but the clerk in
the SAP system should be able to display prepared print data in the invoice simulation.

Program Enhancements in Events

Use
In addition to Customizing settings, you can also use customer-specific or industry-specific
function modules that you define for specific events to influence the process flow of invoice
printing.

Features
The following table contains the events that you can use for customer-specific enhancements,
together with the scope of their functions.
Event

In this event, you can:

2681

Fill customer-defined fields in the document

header during invoicing printing.
You can define the customer-specific fields in
the structure C_FKKINVDOC_HEADER.
This event is processed for actual printing,
repeat printing, but not for a test print. If the
parameter I_REPRINT is active, this is a repeat
print.

2685

Trigger the processing of an invoicing printout

request

2686

Trigger the printing of an invoicing document

by the main correspondence program

(C) SAP AG

224

2687

Fill customer-specific or industry-specific fields

in the invoicing document for printing of the
invoicing document.
You can define the customer-specific or
industry-specific fields in the customer includes
or industry includes of structure
C_INVDOC_PRNT.

Activities
Program the required function modules and register them in Customizing for Contract Accounts
Receivable and Payable under Program Enhancements
Define Customer-Specific Function
Modules.

Displaying the Invoicing Document

The invoicing document display gives you an overview of all data contained in the invoicing
document.

Features
If the system determines one invoicing document based on the the selection criteria that you
enter, all document information is displayed immediately. The upper part of the screen shows the
header data of the invoicing document. All document data is displayed in list form below this.
If the system determines more than one invoicing document for the selection criteria you enter on
the initial screen, initially only the header data appears. The system can display the header data
for up to ten invoicing documents in the list on the upper part of the screen. If more than ten
invoicing documents satisfy the selection criteria, all further document headers are displayed on a
separate screen. By double-clicking on an invoicing document, you can navigate to the detailed
display of the document. The items, posting documents, and source documents for this document
are each displayed on a separate tab page. By means of icons on the tab pages, you can
immediately recognize which data is available.
Actions and Navigation
In the list of the document headers you can:
Simulate an invoice
Call up the invoice preview
Display an existing invoice from the optical archive
To perform one of these actions, in the list of document headers, select an invoicing document
and choose the appropriate pushbutton in the application toolbar.
If the selected invoicing document is an individual document of a collective bill, you can navigate
within the collective invoicing document. To do this, select the header line of the individual
document and choose the Collective Bill pushbutton.

(C) SAP AG

225

If the invoicing document selected is a collective invoicing document, you can display the list of all
the individual documents. To do this, select the header line of the collective invoicing document
and choose the Individual Documents pushbutton.
On the Posting Documents tab, you can navigate to the posting document display.
On the Source Documents tab, you can see the source documents of the invoicing document.
Depending on the source document category, you can navigate to the following views:
Source document category in the billing document display
Source document category of the collective bill
Source document category in SD document
You can also get an overview of the reversal history of the invoicing document. The tab page
shows which invoicing document has reversed the invoicing document displayed, or which
invoicing document was reversed by the invoicing document displayed. You can navigate to the
reversal document or reversed document.

Activities
1. On the SAP Easy Access screen, choose
Document .

Invoicing

Document Display

Invoicing

2. Enter your selection criteria on the initial screen and choose Execute.
In addition to the fields defined in the database, you can also display additional data. To display
additional data, define a function module for event 2676 in Customizing for Contract Accounts
Receivable and Payable under Program Enhancements Define Customer-Specific Function
Modules .
In event 2673, you can change the field catalog of the fields that are to be displayed, and in event
2674, you can program the navigation for the fields accessed by double-clicking.

Clarification in Invoicing
Purpose
When creating bills and processing billing documents situations can occur that demand the
termination of automatic processing and that postprocessing be performed manually in dialog by
the agent. The clarification in invoicing in the contract account receivable and payable helps you
to recognize these exception situations and to process them successfully.
The invoicing clarification covers the following processes and functions:
Recognize defined situations in invoicing processes in contract account receivable and
payable.
Create clarification cases automatically or manually
Specify a clarification process that supports the asynchronous, manual postprocessing of
the clarification case using an agent
Clarify clarification cases automatically
The Clarification Processing in invoicing is an application of the Clarification Framework
Controller (CFC) and can be called with transaction FKKINV_CFC.

(C) SAP AG

226

The Customizing for the processing of clarification worklist is delivered by SAP (Customizing
Contract Account Receivable and Payable
Technical Settings
Prepare Processing of
Clarification Worklist).

Process Flow
Validation
Validation [Seite 227] covers the system-side analysis and recognition of a clarification situation
when processing source documents or invoice documents and decides whether a clarification is
needed or not in an automated mass process.
The validation can refer to various different objects.
The following elements can be checked:
Source Documents [Seite 228]
Invoice Documents [Seite 229]
Contract Account [Seite 230]
Error Messages [Seite 231]
These checks can be processed in the Invoicing Process [Seite 108]
You can also perform Plausibility Checks for Source Documents [Seite 228] in Analyze Invoicing
Orders [Seite 233].
Billing documents can already be recognized as implausible in Transfer of Billing Documents
[Seite 253] and can be checked again in Display Billing Document [Seite 234].
Creating the Clarification Case
If there is a situation to be clarified then a Clarification Case [Seite 235] is created.
Clarification cases can be created either automatically in the Invoicing Process or Transfer of
Billing Documents or manually in the Analyze Invoicing Orders.
Clarification Processing
In Clarification Processing [Seite 242] the clarification cases can be either automatically or
manually clarified by the agent:
Clarification Processing in Dialog [Seite 242] enables the agent to process and complete
the clarification case. It delivers the clarification worklist, supports the individual choice of
clarification cases by the agent and displays the clarification case data in the detail screen.
Clarification cases can also be automatically [Seite 245] clarified when billing documents
are transferred and in the invoicing process.

Validation
Use
During validation, you can choose and apply validation rules for processing source documents or
invoicing documents, and you can run checks on various objects. If the result of the checks is that
clarification is required in invoicing, the system creates clarification cases automatically in mass
processing. It is not possible to invoice the source documents or the contract account until these
cases have been clarified, either automatically or manually.

(C) SAP AG

227

Features
You can check the following objects in an invoicing process:
Source documents [Seite 228]
Invoicing documents [Seite 229]
Contract accounts [Seite 230]
Error messages [Seite 231]
You can also run plausibility checks on source documents when analyzing invoicing orders [Seite
233] and displaying billing documents [Seite 234].
Billing documents are source documents of the source document category INVBI that were
created in Billing in Contract Accounts Receivable and Payable [Seite 15]. You can already check
billing documents at the time they are created. You can check billing documents that arise from
the data transfer of billing documents from external systems or that you modify. You do so in the
inbound interface of Invoicing in Contract Accounts Receivable and Payable that is specially
designed for this purpose.
You can make the following settings for this function in Customizing for Contract Accounts
Receivable and Payable:
Define plausibility checks for source documents and invoicing documents.
Define an exception list for error messages that not only end invoicing processing for a
contract account but also trigger generation of a clarification case.
Lock a contract account for invoicing processing so that clarification is necessary.

Plausibility Checks for Source Documents

Use
The Source Document Plausibility Checks function supports you in creating clarification cases
[Seite 226] for the source document in Invoicing. You can use the function to determine and run
plausibility checks for a source document and to create clarification cases that belong to
clarification case category 01 according to the result.

Features
Industry- and Customer-Specific Check
You can use the Source Document Plausibility Checks function to check the individual source
documents that are grouped together in an invoicing unit. These checks are industry- and
customer-specific. If the checks outsource a source document on the grounds that it is "not
plausible", the system creates a clarification case with clarification case category 01.
You define the rules for checking the source document under the key Check Source Document.
Check Module
The check itself takes place in a customer-specific check module, which is assigned to the
check key. You can also enter currency-dependent amount or quantity limits for the check key for
different units, which are valid for a given period.

(C) SAP AG

228

You can use these limit values (a maximum of three) when implementing the customer module.
Their meaning (for example, net or gross amounts) is only defined for the check module.
Function module FKK_SAMPLE_TFK2672 from function group FKKINV_EVENT is available as
a sample module and copying template. For a description of the function and interface, see the
function module documentation.
Multiple Check
You run several checks on source documents and can specify the sequence in which the checks
are to be run when you assign them.
Termination of Invoicing Unit and Contract Account Processing
The plausibility check controls whether the system terminates processing of the invoicing unit
only when a document is outsorted, or both invoicing unit and contract account processing.

Activities
The system checks all the source documents in the invoicing unit that belong to one category. If
at least one source document is identified as implausible, the system cancels processing of the
invoicing unit. The system creates a clarification case of category 01 for each implausible source
document, using the source document category and number in the clarification case.
You define the plausibility checks and their assignment to the source document category in
Customizing for Contract Accounts Receivable and Payable under Integration
Invoicing in
Contract Accounts Receivable and Payable
Clarification Processing
Define Checks for
Source Document or Assign Checks for Source Document.

Plausibility Checks for Invoicing Documents

Use
The Invoicing Document Plausibility Checks function supports you in creating clarification cases
for the invoicing document in Invoicing. You can use the function to determine and run plausibility
checks for an invoicing document and to create category 03 clarification cases [Seite 226]
depending on the result.

Features
Industry- and Customer-Specific Check
You can use the Invoicing Document Plausibility Checks function to check invoicing documents
after the invoicing unit has been processed and before the invoicing data is updated. These
checks are industry- and customer-specific. If the checks determine that an invoicing document is
"not plausible", the system creates a clarification case with clarification case category 03.
Check Module
The check itself takes place in a customer-specific check module, which is assigned to the
check key. You can also enter currency-dependent amount or quantity limits for the check key for
different units, which are valid for a given period.
You can use these limit values (a maximum of three) when implementing the customer module.
Their meaning (for example, net or gross amounts) is only defined for the check module.

(C) SAP AG

229

Function module FKK_SAMPLE_TFK2671 from function group FKKINV_EVENT is available as

a sample module and copying template. For a description of the function and interface, see the
function module documentation.
Control Document
The system terminates processing of the invoicing unit. However, you can save the checked
invoicing document as a control document. It documents the invoicing situation that led to the
clarification case, particularly the composition of the invoicing unit.
The checked invoicing document is marked as a control document for the clarification case in the
invoicing document header. This is a simulation document, since no postings are made in
Contract Accounts Receivable and Payable.
You define the rules for checking the invoicing document under the key Check Invoicing
Document.
Multiple Check
You run several checks on invoicing documents and can specify the sequence in which the
checks are to be run when you assign them.
Termination of Invoicing Unit and Contract Account Processing
The plausibility check controls whether the system terminates processing of the invoicing unit
only when a document is outsorted, or both invoicing unit and contract account processing.
The check also controls the update of the control document.

Activities
You define the plausibility checks and their assignment to the invoicing document category in
Customizing for Contract Accounts Receivable and Payable under Integration
Invoicing in
Contract Accounts Receivable and Payable
Clarification Processing
Define Checks for
Invoicing Document or
Assign Checks for Invoicing Document.

Contract Account Check

Use
You can use this function to outsort each bill for a contract account so that they can first be
manually checked and posted. This monitoring of bill creation can also take place for a limited
period.
The invoicing lock reason specified in the master record for the contract account determines
whether bill clarification is triggered in invoicing for the contract account. If the lock reason is
marked in its definition as "Clarify" and is assigned a clarification reason, a clarification case can
be created in invoicing for the contract account if the document date used is in the validity period
of the invoicing lock.
If there is a lock reason without clarification information, the invoicing lock in the contract account
prevents invoicing from taking place but the system does not create a clarification case.

(C) SAP AG

230

Activities
You can define the lock reasons for invoicing in the Customizing settings for Contract Accounts
Receivable and Payable under Integration
Invoicing in Contract Accounts Receivable and
Payable Invoicing
Invoicing Processes
Define Lock Reasons for Invoicing.

Error Messages
Use
In addition to recording error messages in the application protocol, you can create a clarification
case to effectively analyze and quickly solve error situations in invoicing that could lead to a
termination of bill creation.
You can create an exception list for messages which trigger a clarification case whereby you
assign one or multiple messages (message class and message number) to the Invoicing Process
[Seite 108], the Invoicing Type [Seite 111] and the Invoicing Category [Seite 112]. You can store a
clarification reason for the message. Company code 2673 is used for this.

Activities
Make these settings in Customizing the contract accounts receivable and payable under:
Integration
Invoicing in Contract Accounts Receivable and Payable
Clarification Processing
Maintain Exception List for Messages.

Validation in the Invoicing Process

Use
You can perform all types of validation in the invoicing process [Seite 108]:
Check each source document processed
Check the invoicing document created
Lock the contract account for invoicing
Trigger clarification cases with error messages

Clarified cases with a contract account reference (clarification case categories 03 to

06) do not influence validation in the invoicing process, irrespective of whether they
were clarified automatically or manually.
However clarified cases with reference to a source document (clarification case
categories 01 and 02) are taken into account: in this case, the system does not
check the source document again during the invoicing process.

(C) SAP AG

231

Features
Plausibility Checks for Source Documents
You can activate the plausibility checks for the source document using the invoicing function of
the same name (see Plausibility Checks for Source Documents [Seite 228]).
In this case, the system checks all the source documents in the invoicing unit. If the system
determines that the source document is implausible, processing of the invoicing unit and, if
applicable, the contract account, is terminated in mass processing [Seite 245] (see Plausibility
Checks for Invoicing Documents [Seite 229]). The system creates a clarification case that
belongs to the category 01 for each implausible source document.
The user decides in dialog processing [Seite 242] whether the invoicing unit is to be processed
and if so, how, and whether the system is to create a clarification case that belongs to category
01.
Plausibility Checks for Invoicing Documents
You can activate the plausibility checks for the invoicing document using the invoicing function of
the same name (see Plausibility Checks for Invoicing Documents [Seite 229]).
In this case, the system checks the invoicing document for an invoicing unit. If the system
determines that the invoicing document is implausible, processing of the invoicing unit and, if
applicable, the contract account, is terminated in mass processing (see Plausibility Checks for
Invoicing Documents [Seite 229]). The system creates a clarification case that belongs to the
category 03 for each implausible invoicing document.
The user decides in dialog processing whether the invoicing unit is to be processed and if so,
how, and whether the system is to create a clarification case that belongs to category 03.
If the With Control Document indicator is selected in the settings for the plausibility check on the
invoicing document, the system saves a simulated invoicing document for use in verifying the
clarification case.
Plausibility checks on the invoicing document are run exclusively in the invoicing process [Seite
108].
Contract Account Check
When invoicing takes place for a contract account, the system checks the contract account for an
invoicing lock after data collection has taken place. If the contract account is locked in the validity
period on the document date for invoicing, category 04 clarification cases can also be created.
These clarification cases are created automatically in mass processing. In single invoicing, the
user can decide in dialog processing whether or not a category 04 clarification case is to be
created.
The system checks the invoicing lock in the contract account exclusively in the invoicing process.
Error Messages
During invoicing, the system checks messages that are displayed when processing an invoicing
unit and written to the application log. If these messages are included in the exception list for
messages in the settings for clarification processing, the system creates a category 06
clarification case in mass processing in addition to the corresponding message in the log.
The user decides in dialog processing whether the system is to create a category 03 clarification
case as well as logging the message.
The system only checks messages that are displayed during invoicing of an invoicing unit.

(C) SAP AG

232

Validation in the Billing Process

Use
Unlike validation in the invoicing process, validation in the billing process validates billing
documents. These documents are created in Billing in Contract Accounts Receivable and
Payable [Seite 15]. From an invoicing point of view, they represent source documents.

Features
There are two types of billing process. These are simulated billing and actual billing.
For simulated billing, the system does not create any clarification cases, even if a billing
document does not pass a check. To enable you to understand why checks have failed
without the use of a clarification case, the system writes messages to the application log
during billing simulation.
For actual billing, the system creates a clarification case. It does not write messages to
the application log. However, the application log informs you that a clarification case was
created.
You can decide whether to close a clarification case immediately. You can check and accept the
billing document in the dialog. If you accept a billing document, the system creates a clarification
case with the status Clarified for documentation purposes.
If you reverse a billing document, the system automatically closes any existing clarification
cases. The system can then only create new clarification cases for the billing document during a
new billing run.

Validation in Invoice Order Analysis

Use
This function allows you to run plausibility checks on source documents when analyzing invoicing
orders (Analysis of Invoicing Orders transaction, FKKINV_MON).

Activities
Select a line in the list of source documents for invoicing and choose Check Document.
If the document is "implausible" and the source document is not yet being clarified, you can
create a clarification case that belongs to category 01 when displaying the messages for the
source document. The source document now has the status Being Clarified in the list.
If the source document is already being clarified when the check is run, the system can display
the existing clarification case when displaying the messages for the source document.

If you want to create a clarification case for the source document without running
plausibility checks on source documents, select a line in the list of source
documents for invoicing and choose Create Clarification Case for Source
Document. The system creates a clarification case that belongs to clarification case
category 02.

(C) SAP AG

233

If you want to create a clarification case for the contract account without validation,
select a line in the list of source documents for invoicing and choose Create
Clarification Case for Contract Account. The system creates a clarification case that
belongs to clarification case category 05.

Validation in Billing Document Display

Use
You can use this function to run plausibility checks on the billing document (source document that
belongs to the category INVBI) when displaying the billing document [Seite 294] (Display Billing
Document transaction, FKKINVBILL_DISP).

There is no function to support the creation of clarification cases when displaying

billing documents. To do this, use the function for analyzing invoicing orders [Seite
233]. This ensures that invoicing has not yet taken place for the billing document for
which you want to create a clarification case.

Activities
Choose Check Document.
If the document is "implausible", the system displays messages indicating this for the source
document. If the source document is already being clarified when the check is run, the system
can display the existing clarification case when displaying the messages for the source
document.

Validation in Billing Document Transfer

Use
A range of Business Application Programming Interfaces (BAPIs) is available for transferring
billing documents [Seite 253] from billing systems (see Billing in Contract Accounts Receivable
and Payable [Seite 15]) to Contract Accounts Receivable and Payable.
In telecommunications companies, these BAPIs form the following scenarios:
Create one or more billing documents [Seite 278]
(BAPI_ISTBILLDOC_CREATEMULTIPLE [Seite 257])
Reverse a billing document [Extern] (BAPI_ISTBILLDOC_CANCEL)
Adjust a billing document [Seite 287] (BAPI_ISTBILLDOC_ADJUST)
Customers from Public Sector Contract Accounts Receivable and Payable use the following
interfaces:
Create one or more billing documents (BAPI_FMCABILLDOC_CREATE_MULT)
Reverse a billing document (BAPI_FMCABILLDOC_REVERSE)
(C) SAP AG

234

Adjust a billing document (BAPI_FMCABILLDOC_ADJUST)

Plausibility checks for billing documents are executed during the transfer of billing documents if:
Billing documents are created
Billing documents are adjusted

Features
A new import parameter that controls execution of the plausibility checks is available in the BAPI
interfaces.
The validation rules are applied to each individual billing document (in
BAPI_ISTBILLDOC_CREATEMULTIPLE [Seite 257]) and to the adjustment document (in
BAPI_ISTBILLDOC_ADJUST [Seite 287]). The billing document numbers are not known if these
checks are run during runtime.
If you outsort a billing or adjustment document, the system automatically creates a clarification
case that belongs to the category 01.

Clarification Case
Definition
If there is a situation to be clarified then a clarification case is created. Unclarified clarification
cases trigger Clarification Processing [Seite 242]

Usage
Clarification cases can be created either automatically in the Invoicing Process or Transfer of
Billing Documents or manually in the Analyze Invoicing Orders.

Structure
Aside from selection data for the agent, clarification cases also contain information about the
source documents or bills to be clarified as well as Status Information [Seite 238] about the
clarification process.

Data Model
Data Model of Clarification in Contract Accounts Receivable and Payable
The figure provides an overview of the data objects that form the basis for clarification.

(C) SAP AG

235

SAP ERP
Business
Partner

Contract
Account

Invoicing
Document

Clarification
Case

Clarification Case
Category 03 - 06

Clarification
Case

Clarification Case
Category 01

Clarification
Case

Clarification Case
Category 02

Source
Document

Master Data Object

Document Object
Document Customizing

Clarification Case Category

01
02
03
04
05
06

Source Document Clarification

Source Document Clarification, Manual
Invoicing Document Clarification
Contract Account Clarification
Contract Account Clarification, Manual
Error Message Clarification

Special features of the data model:

Every clarification case [Seite 235] is uniquely assigned to one contract account.
A clarification case is classified by a clarification case category [Seite 240].
Clarification cases with clarification case category 01 or 02 relate to a source document.
Clarification cases with clarification case type 03, 04, 05 or 06 do not refer to a source
document.
A source document can have a maximum of one clarification case with clarification case
category 01.

It is not possible to assign a clarification case to an invoicing document. An

invoicing document can be checked at runtime. If it is found to be implausible then a
clarification case can be created with clarification case type 03. The invoicing is
then ended early. The invoicing document is not created.

Data Storage
The following information is provided for clarification cases:
Clarification case number
The system gives a unique number to each clarification case.
Mater data references
Business Partner
Contract Account

(C) SAP AG

236

Reference data from contract

Subapplication in Contract Accounts Receivable and Payable
Clarification Case Type [Seite 240]
Clarification Reason [Seite 241]
Data for check
The checks refer to different objects:
Source document
Type of source document to be invoiced
Number of source document to be invoiced
Source document check
Invoicing document
Invoicing process
Invoicing document check
Number of control document for invoicing in clarification case.
Messages (documents in output form)
Message class, message type, message number, message variables
Amounts and Currencies
The system stores the following data depending on the clarification type:
Posting relevant total amount of source document and currency (clarification case
type 01, 02)
Invoice amount of control document in transaction currency with +/- sign
(clarification case type 03)
Status Information [Seite 238]
Branch-specific and customer-specific data
The system saves the clarification case data in the new Clarification Case Invoicing application
table (DFKKINV_CFC):
Field

Key

Short Description

MANDT

Client

INVCFCNO

Clarification case number

APPLK

Application area

CFCCAT

Clarification case category

CFCREASON

Clarification reason

CFCVAL_INVDOC

Invoicing document check

CFCVAL_SRCDOC

Source document check

GPART

Business partner number

(C) SAP AG

237

VKONT

Contract account number

VTREF

Reference data from contract

SUBAP

Subapplication in contract
accounts receivable and
payable

SRCDOCCAT

Type of source document to

be invoiced

SRCDOCNO

Number of source document

to be invoiced

SRCDOC_CURR

Transaction currency

SRCDOC_AMOUNT

Total amount of source

document that is posting
relevant

INV_PROCESS

Invoicing process

INVDOCNO

Number of control document

for invoicing in clarification
case.

INVDOC_CURR

Transaction currency

INVDOC_AMOUNT

Amount in transaction
currency (+/-)

. INCLUDE

Messages for clarification case

. INCLUDE

CFC: status include for

application tables

. INCLUDE

Industry include T

. INCLUDE

Industry include P

. INCLUDE

Customer include

Statuses and Processing Statuses of Clarification

Cases
Definition
The clarification case contains status information. The clarification case can have the following
statuses during clarification processing:
New
Clarify
In process

(C) SAP AG

238

Completed

When performing clarification during billing and when transferring billing documents,
the system first sets a temporary processing status and an indicator showing that
the case has been clarified. However, the system updates the processing status
and the status of the clarification case during invoicing or in the clarification worklist
before individual clarification.
Possible Statuses
Number

Status

Explanation

00

New

Assigned temporarily when

creating a clarification case
manually, not stored in the
system.

01

Clarify

Set automatically when

creating and saving a
clarification case.

02

In process

Set automatically for various

processing statuses in
clarification processing.

03

Completed

Set automatically for various

processing statuses in
clarification processing.

Number

Status

Explanation

01

Source document can be

invoiced

Set by the user in dialog

during clarification processing.

02

Source document cannot be

invoiced

Set by the user in dialog

during clarification processing.

03

Source document returned to

worklist

Set by the user in dialog

during clarification processing.

04

Source document reversed

Set in automatic clarification

processing when transferring
billing documents.

05

Source document invoiced

Set during invoicing.

06

Partially billed

Set during invoicing.

08

Invoiced in dialog

Set in dialog during invoicing.

09

Clarified without invoicing

Set by the user in dialog

during clarification processing.

10

Invoiced

Set in billing during automatic

clarification.

11

Do not invoice account

Set by the user in dialog

during clarification processing.

Defined Processing Statuses

(C) SAP AG

239

12

Clarification status reset

Set by the user in dialog

during clarification processing.

Clarification Case Category

Definition
The clarification cases category classifies the invoicing clarification cases and helps differentiate
between and schedule clarification cases according to their causes.

Use
The clarification case category is used by the system, whereby validation and validation object
are important for the clarification case category.
The following values are used for creating clarification cases after validation:
01: Clarification Source Document
03: Clarification Invoicing Document
04: Clarification Contract Account
06: Clarification Error Message
The following values are used for the manual creation of clarification cases without
validation:
02: Clarification Source Document, created manually
05: Clarification Contract Account, created manually
The clarification case category controls the processing of the different clarification cases of
invoicing by setting the detail screen to the display and processing of a clarification worklist item.
The agent can be included in the clarification case category for the selection of clarification cases
for the manual postprocessing of the clarification worklist.

Structure
You store the clarification case categories in Customizing of Financial Accounting (new) under
Contract Account Receivable and Payable
Program Enhancements. Here you can, by entering
a program name and a number of a following screen layout, also set the detail screen to display a
clarification list item in the clarification processing.
The following settings are delivered for the clarification cases categories used by the system:
01 Clarification Source Document, Program Name SAPLFKKINV_CFC_SCREEN, Screen
0100
02 Clarification Source Document, manually created. Program Name
SAPLFKKINV_CFC_SCREEN, Screen 0100
03 Clarification Invoicing Document, Program Name SAPLFKKINV_CFC_SCREEN,
Screen 0200
04 Clarification Contract Account, Program Name SAPLFKKINV_CFC_SCREEN, Screen
0200

(C) SAP AG

240

05 Clarification Contract Account, manually created. Program Name

SAPLFKKINV_CFC_SCREEN, Screen 0200
04 Clarification Error Message, Program Name SAPLFKKINV_CFC_SCREEN, Screen
0200

Clarification Reason
Definition
The clarification reason indicates why a clarification case is created.

Use
The clarification reason classifies the clarification cases according to their different causes. The
administrator can use it in selection when manually postediting the clarification worklist. You must
specify a clarification reason in the clarification case.
The clarification reason also allows you to specify whether the clarification case can be
processed automatically or only manually.

Structure
You define clarification reasons that lead to the creation of a clarification case in Customizing for
Financial Accounting (New) under
Contract Accounts Receivable and Payable
Integration
Clarification Processing Maintain Clarification Reasons. You can allocate different
clarification reasons to each clarification case category [Seite 240].

Control Document
Definition
A control document can be created during invoicing when checking the invoicing document and
when creating a clarification case that belongs to clarification case category 03.
It documents the exception situation that led to the creation of the clarification case in Invoicing.
Most importantly, it provides the user processing the clarification case with information on the
composition of the invoicing unit.
A control document is marked as simulated in the invoicing document header. After clarification,
the control document is no longer needed. After the clarification case has been deleted, the
document can be deleted together with other simulated documents.
You can specify how the control document is to be created in the settings for the invoicing
document plausibility checks [Seite 229].

(C) SAP AG

241

Clarification Processing
Use
With clarification processing you can have clarification cases clarified automatically, or clarify
them manually.
Clarification processing includes the following functions:
Clarification Processing in Dialog [Seite 242]
Automatic Clarification Processing [Seite 245]
For an overview of the status and processing status see Status and Processing Status of
Clarification Case [Seite 238].

Clarification Processing in Dialog

Use
The process of clarification processing supports the agent to complete clarification cases in
dialog.
Clarification processing:
delivers the Clarification Worklist
supports the individual Clarification Case Choice
displays the clarification case data in Detail and Data for Invoicing Environment.
supports the agent with individual clarification case processing by making a corresponding
choice of functions on status change available.

Integration
Clarification Framework Controller Transaction FKKINV_CFC
The Clarification Processing in invoicing is an application of the Clarification Framework
Controller (CFC) and can be called with transaction FKKINV_CFC.
Customizing
The Customizing for the processing of clarification worklist is delivered by SAP (Customizing
Contract Account Receivable and Payable
Technical Settings
Prepare Processing of
Clarification Worklist).
Check, overwrite and add to the default values for application object FINV. At this point, you can
choose selection fields for clarification case processing.
You can set out in Customizing when clarification cases are to be created in invoicing (
Contract Account Receivable and Payable
Integration
Invoicing in Contract Account
Receivable and Payable Clarification Processing).

(C) SAP AG

242

Features
Role Definition
With the help of role definition (analog SAP Workflow) in Customizing, you can assign individual
clarification cases of the clarification worklists to agents. This accounting agent then receives only
those clarification items within their worklist for which they are responsible within the
organizational structure linked to the role.
The system evaluates the units of your organizational structure to determine the clarification
cases needing processing. For more information about role definition in SAP Workflow, see Role
Definition [Extern].
This assignment is optional. Clerks can limit the number of clarification items for processing with
selection criteria. It can, for example, specify a company code after the function for clarification
processing has been called. The fields that are displayed for selection are defined in
Customizing.
Parallel Processing
Clarification items can be processed by several accounting agents at once. When viewing the
clarification worklist, items can be reserved for a particular agent, thereby preventing them from
being processed by other agents. An agent may also choose to cancel this reservation.
You can also impose a time limits on locks, using Customizing. After the lock interval has expired,
the clarification cases can be accessed by all agents.
Refreshing the Clarification Worklist
To refresh the clarification worklist you can either:
Refresh the status information: this updates the status of each item in the list only. You
can now see which clarification items were blocked or clarified by other accounting agents
since the previous update.
Reselect the list: in which case the system reselects items in line with the selection
criteria you entered on the selection screen when you first called up the list. If you choose
reselection, those items that have been clarified or blocked by other users no longer
appear.
Reading the Attributes and Definitions of Notes
You can display a detailed overview containing the attributes of each clarification item. If you
have activated the use of Notes in Customizing, then system offers you here the notes for the
clarification case. If the clarification case was blocked by a user, you can add your own notes.
Clarification
You cannot clarify completed clarification cases. The following attributes for the clarification case
are generally displayed during clarification:
Clarification case number, clarification case category, creation date
Master data: business partner, contract account, contract reference, subapplication
Status information
Notes
The clarification case is blocked by the user during clarification so that you can also add your own
notes here. The system enables you to navigate to the display of various master data. In
addition, you can also display the account balance of the business partner or of the contract

(C) SAP AG

243

account as well as the invoicing orders of the contract account. You can start an invoicing in
simulation mode or invoice a contract account.
Processing Unclarified Clarification Cases of Category 01 or 02
If you process an unclarified clarification case of clarification case category 01 or 02, then the
source document data is displayed. You can navigate to the source document display. If a
clarification case of category 01 is available, then additional data is issued for the source data
check.
You can check the source document and process the processing status of the clarification
case.
The following possibilities exist:
Source document can be invoiced (status 01): the system automatically sets the
technical status to complete. The source document be processed unchecked in next
invoicing.
Source document cannot be invoiced (status 02): the system automatically sets the
technical status to in process. The source document cannot be invoiced and ends the
invoicing of the corresponding invoicing unit.
Source document rescheduled (status 03): the system automatically sets the technical
status to in process. The source document cannot be invoiced. It is excluded from the
creation of invoicing units in invoicing.
Processing Unclarified Clarification Cases of Categories 03 to 06
If you are processing a clarification case of category 03 to 06, the system displays invoicing data
such as invoicing process, control document, amount and data for clarification reason to you.
If a Control Document [Seite 241] exists, you can navigate to its display.
The following possibilities exist:
Clarification case is clarified without invoicing (status 09): the system automatically
sets the technical status to complete.
Contract account cannot be invoiced (status 11): the system automatically sets the
technical status to in process. The contract account cannot be invoiced and ends the
invoicing of the corresponding invoicing unit.
Integration in Invoicing in the Contract Account Receivable and Payable
To create invoicing in dialog and to clarify available clarification cases, you can use the Invoice
Contract Account function in clarification processing, or use the individual creation Invoicing in
Contract Account Receivable and Payable (transaction FKKINV_S).
You can assign the following processing statuses:
Source document can be invoiced (status 05): the system automatically sets the
technical status to complete.
Contract account is invoiced in dialog (status 08): the system sets the technical status to
complete, if all source documents of the invoicing unit are to be invoiced, the processing of
which originally lead to clarification case creation.
Contract account is part-invoiced (status 06): the technical status is in process when at
least one source document, but not all source documents, of the invoicing unit are
invoiced, the processing of which originally lead to clarification case creation.

(C) SAP AG

244

Automatic Clarification Processing

Use
You can use this function to have the system clarify clarification cases automatically when
transferring billing documents and during the invoicing process.

Prerequisites
The clarification case has been automated. Clarification cases that of categories 02 or 05
must be dealt with manually.
The clarification case is classified by a clarification reason other than Clarify Manually
Only.

Features
Even if there is an unclarified clarification case, validation [Seite 227] still takes place during the
invoicing process [Seite 108]. If the result of these checks is that clarification is not currently
necessary, the system processes the clarification case. It sets its status to Completed and the
processing status changes to Invoiced.

Unclarified clarification cases with the status In Process and the processing status
Source Document Returned to Worklist are an exception: the corresponding source
document is not checked again during invoicing. It is excluded when the invoicing
unit is created.
Incomplete clarification cases in a billing document can be clarified automatically during billing
document transfer if the billing document is reversed or adjusted. The clarification case is then
assigned the status Completed and the processing status changes to Source Document
Reversed.
There cannot be incomplete clarification cases for an invoiced billing document.

Enhancement Options in Invoicing

Invoicing in Contract Accounts Receivable and Payable provides the following enhancement
options for customers and industry business solutions:
Events based on the event concept of Contract Accounts Receivable and Payable
You can find the available events in Customizing for Contract Accounts Receivable and
Payable under Program Enhancements Define Customer-Specific Function Modules
using the search term Billing in FI-CA.
Invoicing functions (see Program Enhancements and Customer-Defined Invoicing
Functions)
SI includes and CI includes in runtime structures

(C) SAP AG

245

SI includes and CI includes in document structures

If you use billing within the framework of SAP Convergent Invoicing, there are additional
enhancement options available in the billing document and the invoicing document. For more
information, see Enhancement Options in Billing.

Program Enhancements
Using the event concept [Extern], you can integrate industry-specific and customer-specific
processes and data not specified explicitly in the previous sections in the existing system
architecture for Invoicing in Contract Accounts Receivable and Payable for new
implementations and for implementations already running.
For the documentation and implementations for the individual events for Invoicing, see the
Implementation Guide for Contract Accounts Receivable and Payable under Program
Enhancements
Define Customer-Specific Function Modules, using the search term
Invoicing.

Archiving in Invoicing in Contract Accounts

Receivable and Payable
Invoicing in Contract Accounts Receivable and Payable supports the archiving of billing
documents and invoicing documents.
For more information, see the documentation for archiving in the sections Archiving Billing
Documents (FKKINVBILL) and Archiving Invoicing Documents (FKKINVDOC).

Activities
To archive billing documents and invoicing documents, on the SAP Easy Access screen, choose
Periodic Processing Archive Data .

Integration of Invoicing in Other Applications

You can integrate invoicing with Sales and Distribution (SD), with SAP Customer Relationship
Management (SAP CRM), and with billing systems.

Integration of Invoicing with Sales and Distribution

(SD)
The communication between Sales and Distribution and Contract Accounts Receivable and
Payable takes place using the accounting interface (RWIN).

(C) SAP AG

246

SD billing offers the option of posting billing documents in Contract Accounts Receivable and
Payable (FI-CA), rather than in Accounts Receivable (FI-AR).
If, in addition,you want to process, post and print SD billing documents in invoices together with
other billing documents, you have to integrate invoicing with Sales and Distribution.

Prerequisites
In order for an SD billing document to be processed in Invoicing in Contract Accounts Receivable
and Payable, the transfer to FI-CA has to be active for each customer group of the SD customer.
For such SD billing documents, in FI-CA you enter the rules for deriving the document type for FICA documents and also for deriving the main transaction and subtransaction.
To ensure the further processing of SD billing documents in Invoicing in Contract Accounts
Receivable and Payable, choose one of the following options:
Transfer the SD billing documents to invoicing using sample documents.
You activate the integration using FI-CA sample documents by using a billing type with
billing category Billing Request (fixed value U) in SD billing. In this scenario, the
accounting interface identifies Contract Accounts Receivable and Payable as the
accounting component, and creates a sample document in FI-CA when the SD billing
request is posted. Event 4050 generates an invoicing order for Invoicing in Contract
Accounts Receivable and Payable with the source document category SD Document (FICA sample document) with the fixed value SD. The invoicing function Invoicing of SD
Documents (INV_SD_DOC) processes this invoicing order.
Transfer the SD billing documents to invoicing without using sample documents.
You activate the direct integration without FI-CA sample documents in Customizing for
Contract Accounts Receivable and Payable. You do so by specifying for each SD billing
type and customer group if further processing should take place in Invoicing in Contract
Accounts Receivable and Payable. During the transfer of SD billing documents to
accounting, the accounting interface identifies FI-CA as the accounting component, but
does not create a posting document. Instead of an FI-CA posting document, the system
creates an invoicing order for Invoicing in Contract Accounts Receivable and Payable
with the source document category SD Billing Document (fixed value VBRK). The
invoicing function Invoicing SD Billing Documents VBRK (INV_VBRK_DOC) processes
this invoicing order.

Activities
Make the settings for the transfer to Contract Accounts Receivable and Payable, dependent of
the customer group, in Customizing for Contract Accounts Receivable and Payable under
Integration Sales and Distribution Define Posting to FI-CA for Customer Account Groups
.
As an alternative, you can make these settings in Customizing for Sales and Distribution under
Billing Billing Documents Integration with Contract Accounts Receivable and Payable (FICA) Define Posting to FI-CA for Customer Account Groups .
You make the specification for direct transfer to invoicing without sample documents in
Customizing for Contract Accounts Receivable and Payable under Integration Sales and
Distribution Define Settings for Transfer to Invoicing .

(C) SAP AG

247

As an alternative, you can make these settings in Customizing for Sales and Distribution under
Billing Billing Documents Integration with Contract Accounts Receivable and Payable (FICA) .
You make specifications for the derivation of controlling values from SD billing documents in
Customizing for Contract Accounts Receivable and Payable under Integration Invoicing in
Contract Accounts Receivable and Payable Transfer of SD Billing Documents Derive
Main/Sub-Transaction from SD Information and Derive Document Type from SD Billing Doc
Data.

More Information
Invoicing of SD Documents
Invoicing of SD Documents with Sample Documents.

Integration of SAP Customer Relationship

Management
Purpose
You can transfer billing documents that result from sales transactions in Customer Relationship
Management (CRM) to Contract Accounts Receivable and Payable (FI-CA) in the ERP system.

Prerequisites
You have installed SAP CRM with Release 5.0 or a higher Release and an ERP system with
Release 2005 or higher.

Process Flow
You can process different business transactions simultaneously with one and the same business
partner that you reflect in different systems.
You process the product order of a business partner in SAP CRM or in SAP
CD. You process the services that this business receives from your company (for
example, telephone charges, power consumption, newspaper subscriptions, and
insurance policies) in a further SAP system or a system of a different provider.
Further open receivables (for example, from earlier billing and dunning notices) or
credits (for example, interest credits or overpayments) can exist for this business
partner in an SAP ERP system.
This makes it necessary to treat data that arises for a business partner in different source
systems separately in subsequent processes (for example, issue of invoices, correspondence,
and entry and monitoring of incoming and outgoing payments).
Invoicing in Contract Accounts Receivable and Payable achieves this separation by means of
standard interfaces that you can use to transfer documents from different source systems to
Contract Accounts Receivable and Payable to invoice them together there. In Invoicing in
Contract Accounts Receivable and Payable, invoicing, correspondence, and entry and monitoring
of incoming and outgoing payments are integrated. You can process billing documents from
different SAP source systems and source systems from other solution providers. The integration
of SAP CRM is a special case of the general integration scenario implemented in Invoicing in
Contract Accounts Receivable and Payable, and here an SAP CRM system is the source system
for billing documents.

(C) SAP AG

248

Making System Settings in the CRM System

Use
Communication between SAP CRM and the SAP ERP system where FI-CA runs takes place via
CRM Middleware [Extern]. To enable this, you have to make the settings required for the data
exchange described below. The settings described refer only to the system settings that you
require for the transfer of CRM billing documents to FI-CA, but not to how you configure the CRM
Middleware.

Prerequisites
To enable determination of an account assignment in the ERP system, the business partner for
the BDoc must be replicated in the neutral document. There must also be a business agreement
for the business partner, since the module BEM_UPLOAD_INV_SRV maps the business
agreement to a contract account reference. This contract account reference determines a
contract account in the ERP system.

Procedure
The data that is exchanged between SAP CRM and the SAP ERP system is of the category
[Extern] BEABILLDOCCRMB of the business object BDoc. The data is mapped from a BDoc of
the category BEABILLDOCCRMB to the format of the inbound interface of Invoicing in Contract
Accounts Receivable and Payable using the CRM adapter BEM_UPLOAD_INV_SRV. You
should configure this adapter as adapter module. It ensures that invoicing documents from SAP
CRM (or BDocs of the type BEABILLDOCCRMB) are mapped as ERP billing documents. You
can process the billing documents that are created in the SAP ERP system further in Invoicing in
Contract Accounts Receivable and Payable.
To define the module, in the SAP menu choose Architecture and Technology
Middleware
Data Exchange
Object Management Business Objects (transaction R3AC1).
Then assign a (data) flow with service function SMW3_OUTBOUNDADP_CALLADAPTERS to
BDoc type BEABILLDOCCRMB. To do this, in the SAP menu choose Architecture and
Technology
Middleware
Development Message Flow Define BDoc Type-Specific Flow
(transaction SMW3FDBDOC).

Making Settings for the Account Determination in

the ERP System
Use
The logic and the system settings for the account determination do not have to agree in the
sender and the target system, that is, in SAP CRM and in Invoicing in Contract Accounts
Receivable and Payable. To ensure the processing of billing information from SAP CRM,
therefore, the logic of the sending system has to be mapped to the logic of the receiving ERP
system. The initial data from the SAP CRM system required for the account determination
(company code, division, and symbolic account key) is mapped to the character fields
PA262640_POS1 to PA262640_POS3 of the inbound interface for Invoicing in Contract Accounts

(C) SAP AG

249

Receivable and Payable in the ERP system. This assignment is automatic, program-internal, and
you cannot change it without modifying it. The table below reflects this assignment.
Assignment of account assignment-relevant fields to fields of the ERP inbound interface
ERP

SAP CRM

COMP_CODE: Buchungskreis

PA262640_POS1: Key 1

DIVISION: Division

PA262640_POS2: Key 2

ACCTKEY_SYMB: Symbolic Account Key

PA262640_POS3: Key 3

The following section describes which system settings are necessary for communication using
CRM Middleware.

Procedure
...

1. To enable the ERP system to communicate with an SAP CRM system using CRM
Middleware, you have to define an RFC connection to the CRM system. Using this RFC
connection, the ERP system sends a receipt confirmation or error message to the CRM
system.
2. Using transaction SM30, enter the receipt module (inbound adapter)
INV_BILL_DOC_INBOUND in table CRMSUBTAB. This module receives the billing data of
the invoicing from SAP CRM and triggers the inbound processing that creates the billing
documents and invoicing orders in the ERP system. Invoicing in Contract Accounts
Receivable and Payable processes these further later on - together with billing documents
from other source systems if applicable.
3. In the ERP system define the settings for the account determination for the billing
documents transferred from SAP CRM. To do this, in the Implementation Guide for
Contract Accounts Receivable and Payable, choose Integration
Invoicing in Contract
Accounts Receivable and Payable Transfer Billing Documents
Define Determination
of Transactions for Billing Document Items (posting area 2640). By making this setting you
map data that is stored in the character fields PA262640_POS1 to PA262640_POS3 in the
SAP CRM system to structured fields that have a fixed meaning in the SAP ERP system.
The list of target fields for this mapping consists of Main Transaction, Debit Subtransaction,
Credit Subtransaction, Company Code, and Division.
Considering the account assignment-relevant fields from the SAP CRM system and their
assignment to character fields of the inbound interface for Invoicing in Contract Accounts
Receivable and Payable, posting area 2640 corresponds to the following table.
Posting area 2640 from the view of integration of SAP CRM to SAP ERP

SAP C RM sys tem

Transport Field

SAP ERP System

COMP_CODE: Buchungskreis

PA262640_POS1: Key 1

CRM Company Code

DIVISION: Division

PA262640_POS2: Key 2

CRM Division

ACCTKEY_SYMB: Symbolic
Account Key

PA262640_POS3: Key 3

CRM Symbolic Account Key

Logical (CRM source) system
ERP company code
ERP division
ERP main transaction

(C) SAP AG

250

ERP debit subtransaction

ERP credit subtransaction

Determination of Contract Account in ERP System

Use
In the ERP system, the determination of the contract account from a generic contract account key
(from any external system) takes place in the BAdI FKKINV_BAPIBILL. This program model also
applies for CRM invoicing as source system. A customer implementation of the method
CONTRACT_ACCOUNT_DETERMINE for BAdI FKKINV_BAPIBILL is required.

Procedure
If the master data was actually replicated, add the following program lines:

METHOD IF_EX_FKKINV_BAPIBILL~CONTRACT_ACCOUNT_DETERMINE.
DATA: wa_fkkvkp TYPE fkkvkp.
CLEAR wa_fkkvkp.
SELECT * FROM

fkkvkp
INTO

wa_fkkvkp

WHERE guid EQ x_cont_acct_id.

EXIT.
ENDSELECT.
IF NOT wa_fkkvkp IS INITIAL.
MOVE: wa_fkkvkp-vkont TO xy_cont_acct,
wa_fkkvkp-gpart TO xy_buspartner.
ENDIF.
ENDMETHOD.
You have to differentiate between the source systems since there is no master data replication
between a non-SAP system and the ERP system. You may have to evaluate a customer table
that contains the information.

Notes for Mapping CRM Billing Documents in the

ERP System
The CRM billing documents are mapped to the ERP inbound interface of Invoicing in Contract
Accounts Receivable and Payable in the mapping adapter BEM_UPLOAD_INV_SRV. The CRM
Middleware calls this module automatically internally every time a BDoc of the category
BEABILLDOCCRMB is created. BDocs of the category BEABILLDOCCRMB are created

(C) SAP AG

251

exclusively by invoicing in CRM. Internally, the module creates the neutral document and derives
the data to be sent.
Tax information is not transferred from the CRM system to the ERP system; the tax is determined
in the ERP system.
As standard, the standard program does not fill the table for additional data. If there are transferrelevant fields that are not supported on the standard interface, you have to add your customer
fields to the table. You can fill the customer fields in the table of additional data in the BAdI
CRM_ICA_BADI (in the SAP CRM system).
The inbound adapter INV_BILL_DOC_INBOUND converts the data that the CRM system
provides in a character-form transport structure in categorized structures of the interface of the
BAPI for inbound processing for Invoicing in Contract Accounts Receivable and Payable. The
BAPIs are industry-dependent. The form of the BAPI is therefore dependent on the industry
solution that you use.
In the industry-specific component Telecommunications, you use the BAPI
BAPI_ISTBILLDOC_CREATEMULTIPLE.
In this BAPI, the contract account is derived from the external contract account key. There are
also inbound checks that determine whether the documents are consistent from the view of the
ERP system. The status of the inbound processing is sent to the sender system.
The distribution of the BDocs in the SAP CRM system should be configured
such that it takes place automatically. You can display the status of the distributed
BDocs with transaction SMW01. Here you can select the BDocs to be analyzed
dependent on the BDoc type, BDoc status, send time, and further parameters. You
can repeat the transfer of the BDoc documents using the button Process BDoc
Message Again.
You can suppress the automatic distribution for a test. At a technical level, you can
do this by locking (deregistering) one or more queues. In transaction SMQ1, you
can display all or a selection of the outbound queues. Using the corresponding
function in the menu of this transaction, you can set locks. By setting a generic lock,
you can also lock several queues simultaneously. The generic lock has a prefix in
its name, and this is the same for all queues affected.
You can also lock the automatic distribution at application level and for each billing
document. You can manually release the billing documents locked for the transfer
later in transaction BEA/CRMB12.
Note that you transfer the data to FI-CA using the transaction Transfer Billing
Documents to Accounting. You perform the actual transfer to General Ledger
Accounting (FI-GL), and therefore Accounting, subsequently (as for all other
postings in FI-CA) in a second step using the transactions for the transfer to the
General ledger (FI-GL) and Profitability Analysis (CO-PA) (see FI-CA menu,
Periodic Processing
Forward Postings).
In the ERP system, you can display the BDocs that are still in inbound queues in
transaction SMQ2. However, the prerequisite for this is that the inbound queues
have been locked, since otherwise the BDoc documents could be sent to the
receiving application too quickly.

(C) SAP AG

252

Integration of Billing Systems

Transferring Billing Documents
Use
Using a BAPI or IDoc interface you can transfer billing documents from external billing systems.

Prerequisites
You have activated Invoicing in Contract Accounts Receivable and Payable in Customizing for
Contract Accounts Receivable and Payable under Basic Functions
Postings and Documents
Basic Settings
Maintain Central Posting Settings.

Cross-application billing document transfer has been set up. However, the individual
processes contain steps and functions designed specifically for telecommunications
companies. Please note this when using the following sections.

Features
When you transfer the billing documents, the SAP system maps the external billing information to
the SAP-internal billing information. The result of this mapping is stored as a billing document in
the SAP system. When you save this billing document, the SAP system creates an invoicing
order.
Transfer of Billing Documents to SAP System

Life

Contract
account

External
Positionen
billing
document

Inbound
process

Billing
document

Invoicing
order

Design time

Inbound
mapping

In Invoicing in Contract Accounts Receivable and Payable, the inbound interface for billing
documents has the following functions:

(C) SAP AG

253

Transfer data from one or more billing documents from external systems
The inbound interface can be used synchronously by calling a BAPI using RFC.
Alternatively, you can use asynchronous processing with IDocs by means of an ALE
interface.
Transfer external document data to the corresponding structures and fields of the billing
document in FI-CA (referred to in the following as "mapping")
Save the billing documents to the database if the consistency checks do not return any
errors
An invoicing order is also created for each billing document. If necessary, you can use
customer enhancements (BAdIs) to store additional data in customer-specific tables.
From the invoicing orders, Invoicing in Contract Accounts Receivable and Payable recognizes the
billing documents that are new and have not yet been processed. Invoicing creates new invoicing
documents based on the billing documents and posts the revenues to FI-CA.

Billing Document from Data Transfer

Definition
A billing document created by the data transfer process contains the information that Invoicing in
Contract Accounts Receivable and Payable needs in order to bill services performed for a
customer. Contract Accounts Receivable and Payable (FI-CA) saves this external document data
in the form of billing documents.

Use
As a result of saving the external document data in billing documents:
From a time point of view, invoicing is separate from the transfer of the external document
data
If there are several billing documents for a contract account, Invoicing in Contract
Accounts Receivable and Payable can group these into one invoicing document and
therefore one invoice.
The source of the billing documents is not important that is, they can also originate from
different external systems.
A connection to the documents of the external system is created
The billing documents contain a unique reference to the external document from which
they arose.

Structure
When a billing document is created, the system simultaneously creates an invoicing order [Seite
125].
Invoicing orders enable the invoicing program to quickly select specific billing documents that
have not been processed yet. If the invoicing of a billing document is successful, the related
invoicing order is deleted.
Billing documents cannot be deleted. If the content of a billing document is not correct, it can only
be reversed. For a reversal, the system creates a reversal billing document. The reversal
document suppresses the invoicing of the billing document to be reversed. If the billing document

(C) SAP AG

254

has already been invoiced, the reversal document ensures that the amounts and quantities are
posted again but with the opposite +/- sign.
You can designate billing documents as simulation documents, which you can then use for
checking and testing. The system does not create invoicing orders and postings for simulation
documents.
The system saves the key of the external document from which the billing document arose with
the billing document. This means that, from the invoicing document, you can navigate to the
external document(s) via the billing document(s). When billing documents are created, the system
checks whether the key of the external system and the key of the logical system from which the
external document is transferred are unique or already assigned. This also applies for simulation
documents and reversal documents.
Billling documents consist of:
Billing document header [Seite 264]
Billing document items [Seite 267]
Billing document tax item [Seite 274] (optional)
Billing document additional items [Seite 277] (optional)
The header of a billing document contains:
The reference to the external document from which it arose
The key of the relevant contract account and the business partner
Each billing document contains one or more billing document items. They contain:
Amounts and quantities
Information that influences the account determination and the tax determination in
Invoicing in Contract Accounts Receivable and Payable
Information for invoice printing and the statistical treatment of the amounts and quantities
The billing document tax items are optional. They are filled if the tax calculation took place in the
external system. If Invoicing in Contract Accounts Receivable and Payable calculates the taxes,
the system does not create billing document tax items.
The billing document additional items are also optional. The SAP standard delivery contains only
a few fields. Billing document additional items are suitable for printing additional information on an
invoice, for example, call itemization on a telephone bill. If you want to use billing document
additional items, you have to add the fields that you require to the structure. You can also use the
billing document additional items as a pure link table. To do this, save additional document data
in one or more separate tables, for example. The table of billing document additional items is only
used to link the entries from these customer-defined tables with billing document headers or
billing document items.
Invoicing in Contract Accounts Receivable and Payable does not use the billing document
additional items in operations.
For billing documents, the following layers are differentiated with reference to the ABAP
Dictionary (DDIC):
Database Layer
Logical Layer
Display Layer
In the database layer, the system stores the billing documents in four different transparent tables.
The database tables are only used for the update or in access modules. In the application

(C) SAP AG

255

programs (inbound interface, BAdIs), the billing documents are managed in logical tables. There
are additional display structures for the display.
The following table gives an overview of the DDIC structures of the individual layers for the
individual components of the billing document:
Part

Database Layer

Logical Layer

Display Layer

Header

DFKKINVBILL_H

FKKINVBILL_H

FKKINVBILL_H_DISP

Items

DFKKINVBILL_I

FKKINVBILL_I

FKKINVBILL_I_DISP

Tax Items

DFKKINVBILL_T

FKKINVBILL_T

FKKINVBILL_T_DISP

Additional Items

DFKKINVBILL_A

FKKINVBILL_A

FKKINVBILL_A_DISP

You can use the method SELECT of class CL_FKKINV_BILL_DOC to read billing documents
from the database. The method reads the billing documents from the database and converts
them into the structures of the logical layer.
The structures of the display layer are almost identical to the logical layer. They contain an
additional customer include that you can use to add additional fields for the display.

You can add additional display fields to the display structure of the billing document
items FKKINVBILL_I_DIPS using the include CI_FKKINVBILL_I_DISP. This
enhancement has no influence on the database layer or the logical layer. You have
to fill the fields of the customer include in an implementation of event 2678.

Inbound Interface for Billing Documents

Definition
Interface for transferring billing information from external systems to Contract Accounts
Receivable and Payable (FI-CA)

Structure
The inbound interface for billing documents is realized with the following objects:
BAPI BAPI_ISTBILLDOC_CREATEMULTIPLE [Seite 257]
Methods of the BAdI ISTINV_BAPIBILL [Seite 260]
Methods of the BAdI FKKINV_BAPIBILL [Seite 260]
Transfer billing documents from external systems.

(C) SAP AG

256

SAP ERP
External
External
system
system
Inbound
interface
Invoicing
order

Invoicing

Mapping

ALE

External document
data

BAPI

Billing
document

Z table
External
External
system
system

BAPI BAPI_ISTBILLDOC_CREATEMULTIPLE
Definition
Business Application Programming Interface [Extern] for creating billing documents

Use
With the BAPI BAPI_ISTBILLDOC_CREATEMULTIPLE, you can create one or more billing
documents.

Structure
The parameters of the function module can be filled with external document data. The following
parameters are available:
Parameter

Function

Import table HEADERS

Must be filled with the header data of the

external documents

Import table ITEMS

Must be filled with the external document items

Import table TAXITEMS

Filled with tax data if the tax is calculated in an

external system

Import table ADDITEMS

Can be filled with document additional items

Import table EXTENSIONIN

Can be filled with information from customers

own fields

(C) SAP AG

257

Export table EXTENSIONOUT

Can be filled using a customer own BAdI

during execution to return information to the
caller

Export table BAPI_BILLDOCNUMBER

Filled with the document numbers of the new

billing documents created

Export table RETURN

Contains log messages

Import parameter TESTRUN

Is an indicator
If you select this indicator, the BAPI does not
make any changes to the database. However,
the BAPI runs through all checks and writes
any errors that occur to the export table
RETURN.

Import parameter CFCVALIDATION

Is an indicator
If you select this field, the system runs the
checks that can lead to the creation of a
dispute case for the billing documents.

When BAPI_ISTBILLDOC_CREATEMULTIPLE is called, you can specify data from several

billing documents. However, you must have defined which external items (entries in import table
ITEMS) belong to which external document headers (entries in table HEADERS), for example.
You make the specification using the fields REFDOCNO and LOG_SYSTEM in the import tables
HEADERS, ITEMS, TAXITEMS, and ADDITEMS. Fill REFDOCNO with an external document
number and LOG_SYSTEM with the key of the logical system from which you transfer the
external document data.
The BAPI runs through the following process steps:
..

Mapping
The document data transferred in the import parameters is transferred to the fields in the
billing document. An invoicing order is created for each (non-simulated) billing document.
Check
The system checks whether each billing document is formally correct and free from errors.
If the import parameter CFCVALIDATION is selected, the system checks each billing
document to determine whether a dispute case [Seite 226] needs to be created.
Update
If there are no errors, the system saves all the billing documents together with the invoicing
orders.
Completion of processing by means of writing data to the database using COMMIT
WORK.
Mapping uses the following procedures:
For many fields of the import tables, there is a corresponding field in the billing document.
The values of these fields can be copied directly into the billing document.
Amount and quantity of line items
For some fields of the billing document, there are two alternatives for the import
parameters.

(C) SAP AG

258

There may be two values for the key of the contract account. The key is required for
the billing document header. You can transfer the contract account key in the import table
HEADERS or use an external identification of the contract account. If you transfer an
external identification, a BAdI is called to determine the contract account key.
The currency of the billing document item can be defined using an SAP currency key or an
ISO currency key (see the import table ITEMS).
For some fields of the billing document, we assume that there is an exact corresponding
field in the external document. In this case, mapping is controlled by tables. Here, generic
fields are used to access a table from the import table ITEMS.
The main transaction and subtransaction do not exist in the billing document item. In
this case, the transactions of the billing document items are taken from the table.
For each structure of the billing document (header, items, and so on), a BAdI is called at the end
of the mapping. There you can intervene using customer-defined coding. For example, there you
can fill fields in the billing document where the table-controlled mapping has failed. Therefore, an
unsuccessful access to the mapping tables is not valuated and logged as an error.
Once the mapping has finished, a check is performed. As far as possible, the billing documents
are checked for formal consistency. The check does not terminate at the first error. Instead, it
collects all error messages in the export table RETURN. In the different BAdIs described below,
you can carry out further checks and log errors in the RETURN table.
Note that the system does not interpret entries in the RETURN table with
message type I (information), W (warning), or S (success) as errors. They do not
prevent the update of the billing documents.
The update is divided into two parts:
...

Determination of the document numbers for all billing documents using the internal number
assignment
Writing of the data in the various billing document tables
An invoicing order is saved for each (non-simulated) billing document. Using a BAdI, you can
write additional data in a customer-defined table.
The update is then only performed if there are no billing documents with errors.
If, when you call a BAPI, you transfer data from ten documents, and the data
contains no errors, all ten billing documents are created. If one of the ten documents
contains errors, no billing document is created.
At the end of processing, the data is updated on the database by means of COMMIT WORK.
For performance reasons, whenever you call BAPI_ISTBILLDOC_CREATEMULTIPLE, you
should create several billing documents if possible. This bundling reduces the effort for the RFC
call and optimizes the database accesses.

(C) SAP AG

259

BAdI Methods for Inbound Interface

Definition
Methods of the BAdIs ISTINV_BAPIBILL and FKKINV_BAPIBILL that run the BAPI
BAPI_ISTBILLDOC_CREATEMULTIPLE

Structure
See the documentation of the methods. The figure below shows where the individual methods are
carried out and in which order:

BAdI FKKINV_BAPIBILL

BAPI_ISTBILLDOC_CREATEMULTIPLE

BAdI ISTINV_BAPIBILL

CL_ISTINV_BAPIBILL
CREATE

INITIALIZE

MAP_BILLDOCS
CONTRACT_ACCOUNT_DETERMINE

COLL_BILL_PARTNER

USER_CHECK_INPUT

CHECK_INPUT_PARAMETERS

MAP_HEADERS

MAP_HEADER

MAP_ITEMS

MAP_ITEM

MAP_TAXITEMS

MAP_TAXITEM

MAP_ADDITEMS

MAP_ADDITEM

TRIGGER_CREATE
FILL_TRIG_CUSTOMER_FIELDS
CHECK
SAVE
UPDATE_PREPARE
GET_NUMBERS

UPDATE_PREPARE

UPDATE

UPDATE

Database
Billing
document

Invoicing
order

Z table

BAdI ISTINV_BAPIBILL
The method INITIALIZE is called for every call of the BAPI. The system runs this method before
all other methods of the BAdI. You can use it to initialize the global memory of your implementing
class.
You can use method CHECK_INPUT_PARAMETERS to check the input parameters of the BAPI.
In particular, you should implement the method if you use the EXTENSIONIN parameter to
process customer own data.
The BAPI starts the mapping with the billing document headers. For every entry of the import
table HEADERS, a preliminary billing document header is created according to different rules, as
described above. Each preliminary billing document header is transferred to the method
MAP_HEADER. There you can fill empty fields where necessary or change the content of filled
fields. You can also subject the result of the mapping to a check or save results in the global
memory of your implementation.

(C) SAP AG

260

In the same way, you can influence the remaining billing document structures with the methods
MAP_ITEM and MAP_TAXITEM.
After a successful check of the billing documents, the update is prepared. The document
numbers are determined for the billing documents. The new document numbers are provided in
the method UPDATE_PRPARE. There, if necessary, you can save data for the update of a
customer own table in the global memory of their implementation.
Then the tables are updated. Firstly, the system writes the document data to the tables of the
SAP standard system. Then the method UPDATE is called; you can use this to write data from
the global memory to your own tables.
If you implement the method UPDATE, you have to consider the following
rules:
No error messages can be generated in this method. All re-formulations,
conversions, and checks of data must have taken place previously.
No COMMIT WORK can take place in this method.
Perform a direct update and do not use any update modules (IN UPDATE
TASK).
BAdI FKKINV_BAPIBILL
The method CONTRACT_ACCOUNT_DETERMINE is called if you use the external ID of the
contract account in a billing document header. Then you have to determine the contract account
and business partner in your implementation.
The method COLL_BILL_PARTNER is called if the contract account has a collective bill account
with several business partners. Read the online documentation.
You can add your own fields to the table of billing orders. You can fill these fields using the
method FILL_TRIG_CUSTOMER_FIELDS.
For performance reasons, you should avoid database accesses as far as possible in your BAdI
implementations.

Enhancement of Tables of Billing Document

Use
For all components of the billing document there are customer includes that you can use to add
your own fields without the need for modifications.

Features
All layers use the same customer includes. This means that, for example, when you include a
field in the customer include of the document header, this field exists in the database layer, the
logical layer, and the display layer. You cannot enhance the structures of the inbound interface of
BAPI_ISTBILLDOC_CREATEMULTIPLE using customer includes. In accordance with the
guidelines for programming BAPIs, you have to use the import table EXTENSIONIN to fill the
fields in the customer include of the billing document.
For technical reasons, there are two customer includes in the components of the billing
document. One customer include is designed for fields of a character nature that can be

(C) SAP AG

261

transferred automatically. The transfer is supported by predefined BAPI table enhancements. If

you use this predefined BAPI table enhancement when you fill table EXTENSIONIN, the fields in
the customer include are provided with data automatically. You do not need a BAdI
implementation. For more information, see Customer Enhancement and Modification of BAPIs
(CA-BFA) [Extern] in the documentation for SAP NetWeaver under Cross-Services
Further
Development, Modifications, (CA-BFA).
The predefined BAPI table enhancements also include the above-mentioned customer includes.
The following table shows the names of the BAPI table enhancements and customer includes:
Part

BAPI Table Enhancement

Customer Include

Header

BAPI_TE_FKKINVBILL_H

CI_FKKINVBILL_H

Items

BAPI_TE_FKKINVBILL_I

CI_FKKINVBILL_I

Tax Items

BAPI_TE_FKKINVBILL_T

CI_FKKINVBILL_T

Additional Items

BAPI_TE_FKKINVBILL_A

CI_FKKINVBILL_A

A further customer include is designed for customer-defined fields that are not of a character
nature or required for mapping. An example is additional currency fields. For these fields you
have to implement a method of the BAdI ISTINV_BAPIBILL. The following table shows the names
of the customer includes and the related methods that you have to implement for the transfer of
the data:
Part

BAdI Method

Customer Include

Header

MAP_HEADER

CI_M_FKKINVBILL_H

Items

MAP_ITEM

CI_M_FKKINVBILL_I

Tax Items

MAP_TAXITEM

CI_M_FKKINVBILL_T

Additional Items

MAP_ADDITEM

CI_M_FKKINVBILL_A

The following figure shows how you can use the EXTENSION table to fill customer-defined fields:

(C) SAP AG

262

BAPI interface

Billing document

HEADERS

ITEMS

FKKINVBILL_H

TAXITEMS

CI_FKKINVBILL_H
CI_M_FKKINVBILL_H

ADDITEMS

FKKINVBILL_I
CI_FKKINVBILL_I
CI_M_FKKINVBILL_I

BAPI_TE_FKKINVBILL_H
BAPI_TE_FKKINVBILL_I

FKKINVBILL_T

CI_FKKINVBILL_T
CI_M_FKKINVBILL_T

BAPI_TE_FKKINVBILL_T
EXTENSIONIN

BAPI_TE_FKKINVBILL_A

FKKINVBILL_A

YBAPI_MY_MAP_H

CI_FKKINVBILL_A
CI_M_FKKINVBILL_A

YBAPI_MY_MAP_I
3

YBAPI_MY_MAP_T
YBAPI_MY_MAP_A
4

YBAPI_MY_TABLE

MY_TABLE
(customer table)

1. The standard SAP fields are provided with data automatically. This means, for example,
that the values of the structure HEADERS are transferred to the standard fields of the
structure FKKINVBILL_H. Usually no BAdI implementation is required.
2. Use the customer include CI_FKKINVBILL_H for customer-defined character fields whose
value is to be transferred from the interface to the billing document header unchanged.
This include is also included in the BAPI table enhancement BAPI_TE_FKKINVBILL_H.
Entries in table EXTENSIONIN that refer to this structure are processed automatically. A
BAdI implementation is not required. However, we recommend BAdI implementation for
checking. In the same way, you can add character fields to other parts of the billing
document and provide them with data.
3. If you want to add a numerical field to the billing document header, you have to use the
customer include CI_M_FKKINVBILL_H. Also define a BAPI table enhancement. We
recommend that you only use character fields in the BAPI table enhancement. Implement
method MAP_HEADER of the BAdI ISTINV_BILL. Use your BAPI table enhancement to
identify the corresponding entries in table EXTENSIONIN in the method. Convert the
character field from your BAPI table enhancement into the numerical field from the
customer include CI_M_FKKINVBILL_H. In the same way, you can add numerical fields to
other parts of the billing document and provide them with data.
4. You can also use the EXTENSIONIN table to provide a customer-defined table with values.

Enhancement of Tables of Billing Document

The following example shows how you can fill the EXTENSION table using the BAPI table
enhancement. The example is based on an enhancement of the billing document header with two
character fields. The fields can be included in the customer include CI_FKKINVBILL_H and
provided with data without a BAdI implementation.
...

(C) SAP AG

263

1. Create the customer include CI_FKKINVBILL_H and insert both fields MY_FIELD1 and
MY_FIELD2.
2. Create a billing document where, in the document header, the field MY_FIELD1 has the
value ABC , and MY_FIELD2 the value XYZ. Before you call the BAPI
BAPI_ISTBILLDOC_CREATEMULTIPLE, fill table EXTENSIONIN as follows (coding
extract):
DATA w_header TYPE bapi_ist_extdoc_h.
DATA w_bapi_te_fkkinvbill_h TYPE bapi_te_fkkinvbill_h.
DATA w_extensionin TYPE bapiparex.
DATA extensionin TYPE bapiparex_tab_kk.
[...]
w_bapi_te_fkkinvbill_h-refdocno

= w_header-refdocno.

w_bapi_te_fkkinvbill_h-log_system = w_header-log_system.
w_bapi_te_fkkinvbill_h-my_field1

= 'ABC'.

w_bapi_te_fkkinvbill_h-my_field2

= 'XYZ'.

w_extensionin-structure = 'BAPI_TE_FKKINVBILL_H'.
w_extensionin+30

= w_bapi_te_fkkinvbill_h.

APPEND w_extensionin TO extensionin.

[...]
As stated, no BAdI implementation is necessary for this procedure. We recommend, however,
that you implement the method CHECK_INPUT_PARAMETERS of the BAdI ISTINV_BAPIBILL
to check the data for the customer-defined fields.
To fill a customer-defined table, proceed as follows:
...

1. Create a corresponding BAPI table enhancement for your customer-defined table.

2. When you call the BAPI BAPI_ISTBILLDOC_CREATEMULTIPLE, fill table EXTENSIONIN
and specify the structure name of your BAPI table enhancement.
3. Implement the method CHECK_INPUT_PARAMETERS of the BAdI ISTINV_BAPIBILL to
check the values and run mapping if necessary. Save the values in the global memory of
your implementation.
4. If you want to use the document number of the billing document in your own table, you
have to implement the method UPDATE_PREPARE of the BAdI ISTINV_BAPIBILL.
5. Use the method UPDATE of the BAdI ISTINV_BAPIBILL to write the data to the database
from the global memory.

Billing Document Headers

Definition
Header of the billing document

(C) SAP AG

264

Structure
You define the properties of the billing document headers using the import table HEADERS. A
billing document (structure FKKINVBILL_H) is created for each entry in this table (structure
BAPI_IST_EXTDOC_H). The following overview shows the fields of the billing document header
to which the fields of table HEADERS are transferred:
Note

Source Field in Table

HEADERS

Target Field in Billing

Document Header

REFDOCNO

REFDOCNO

LOG_SYSTEM

LOG_SYSTEM

APPL_AREA

APPLK

SRCPROCESS

SRCPROCESS

DOCTYPE_BILL_EXT

DOCTYPE

Mapping via posting area 2645

CONT_ACCT_ID

VKONT

Mapping via BAdI

FKKINV_BAPIBILL

CONT_ACCT

VKONT

BUSPARTNER

GPART

DATE_FROM

DATE_FROM

DATE_TO

DATE_TO

SIMULATED

SIMULATED

CURRENCY

BILL_CURR

ISO_CODE

BILL_CURR

INV_CURR

INV_CURR

INV_CURR_ISO_CODE

INV_CURR

TAX_DET_TYPE

TAX_DET_TYPE

TAX_DATE_TYPE

TAX_DATE_TYPE

SEPARATE_INV

SEPARATE_INV

INVOICE_FIRST

INVOICE_FIRST

ADD_GROUP

ADD_GROUP

Only used if CURRENCY is

not filled

Only used if INV_CURR is not

filled

The individual fields and their meaning are explained below. See also the documentation of the
fields of structures BAPI_IST_EXTDOC_H and FKKINVBILL_H.
In the mandatory field LOG_SYSTEM you specify the key of the logical system from which the
external document is transferred. Enter the document number of the external document in the
mandatory field REFDOCNO. The external document number must be unique with the key of the
logical system. (That is, it must not exist already.) This also applies for simulation documents and
reversal documents. The system checks whether a billing document with this combination already
exists.
In the mandatory field APPL_AREA, specify the application area.

(C) SAP AG

265

Describe the origin process that created the external billing document in the field SRCPROCESS.
You must maintain the values in the system table TFK2641. Use the customer name range 9* in
this table. If you do not make an entry in the field, the BAPI writes the default value 0003 External
Billing Program to the billing document header.
Together with the logical system, you use the mandatory field DOCTYPE_BILL_EXT to access
posting area 2645. Posting area 2645 defines the document type of the billing document. The
system takes into account whether the document is a simulation document (field SIMULATED is
filled).
You can fill the field CONT_ACCT with the key of the contract account. The field is optional. If
you do not make an entry, you have to enter the external ID of the contract account in the field
CONT_ACCT_ID. The method CONTRACT_ACCOUNT_DETERMINE of the BAdI
FKKINV_BAPIBILL is called to fill the key of the contract account and the key of the business
partner in the billing document header. For more information, see the documentation of the
method.
You can fill the field BUSPARTNER with the key of the business partner. If you do not make an
entry, you should fill CONT_ACCT_ID and determine the key of the business partner in the BAdI
specified. If neither BUSPARTNER nor CONT_ACCT_ID contain entries, the system tries to
determine the key of the business partner using the contract account. However, this is only
possible if there is exactly one business partner for the contract account.
The mandatory fields DATE_FROM and DATE_TO define the start and end of the billing period
to which the billing document relates. DATE_FROM and DATE_TO can be the same, but
DATE_TO cannot be before DATE_FROM.
If you enter value X in the field SIMULATED, the billing document is deemed to be a simulation
document. It is not posted in Contract Accounts Receivable and Payable (FI-CA). No invoicing
order is created. You can invoice the simulated billing document for test purposes as follows:
...

1. Use the transaction Create Invoicing Document in the SAP menu under Invoicing
Processing.

Dialog

2. Set the indicator Simulation Run and select the option Without Invoicing Order.
3. Enter the document number of the simulation document and the source document category
INVBI.
Invoicing in Contract Accounts Receivable and Payable creates a simulated invoicing document.
With the field CURRENCY you define the currency of the billing document. If you do not make an
entry in the field CURRENCY, you have to enter the currency key in ISO code in the field
ISO_CODE.
With INV_CURR you define the target currency for invoicing. Alternatively, you can enter the
relevant ISO code in the field INV_CURR_ISO_CODE. Both fields are optional. If you do not
make an entry in either field, the currency of the billing document is used as the target currency
for invoicing. Usually, you do not have to specify an explicit target currency for invoicing. For an
application example, see the documentation of the field INV_CURR in the structure
FKKINVBILL_H.
In the mandatory field TAX_DET_TYPE, you define how the taxes are determined. You can
choose between the following fixed values:
00 No Tax Calculation
There is no tax calculation in Invoicing in Contract Accounts Receivable and Payable
01 Internal Tax Calculation
Invoicing in Contract Accounts Receivable and Payable calculates the taxes for each
posting-relevant line item.

(C) SAP AG

266

02 External Tax Calculation

The tax amounts must be specified externally as billing document tax items.
The field TAX_DATE_TYPE is mandatory if you have selected internal tax calculation in field
TAX_DET_TYPE. In both other cases (No Tax Calculation or External Tax Calculation), there
must not be an entry in TAX_DATE_TYPE). TAX_DATE_TYPE defines which date is used for the
tax calculation. You can choose between the following fixed values:
01 Tax calculation on document date
02 Tax calculation on posting date
03 Tax calculation on date of creation
04 Tax calculation on external tax date
With the optional field SEPARATE_INV, you define whether a billing document can be invoiced
with other billing documents from the same contract account and grouped in one invoicing
document. However, Invoicing in Contract Accounts Receivable and Payable does not consider
only the value of field SEPARATE_INV; it is also influenced by the grouping variants and by event
2601. See the documentation of the IMG activity Grouping Variants in the Implementation Guide
for Contract Accounts Receivable and Payable under Integration
Invoicing in Contract
Accounts Receivable and Payable
Invoicing
Invoicing Processes.
With the optional field INVOICE_FIRST, you can define the earliest date from which the billing
document can be invoiced. If you make an entry in the field, the billing document is only invoiced
if the document date for invoicing is the same or older than the date in the field INVOICE_FIRST.
If you do not make an entry in INVOICE_FIRST, the billing document can be invoiced at any time.
You can use the optional field ADD_GROUP to assign one or more document additional items to
the billing document header. If you do not use billing document additional items, the field remains
empty.

Billing Document Items

Definition
Items in the billing document.

Structure
You define the properties of the billing document items using the import table ITEMS. A billing
document item (structure FKKINVBILL_I) is created for each entry in this table (structure
BAPI_IST_EXTDOC_I) there is one exception, and this is described below.
Overview
Source Field in Table ITEMS

Target Field in Billing

Document Item

Note

REFDOCNO

Identifies the billing document

header

LOG_SYSTEM

Identifies the billing document

header

REFITEM

REFITEM

AMOUNT

BILL_AMOUNT

(C) SAP AG

267

CURRENCY

BILL_CURR

ISO_CODE

BILL_CURR

ITEM_SIMULATED

ITEM_SIMULATED

POSTREL

POSTREL

PRINTREL

PRINTREL

PRINT_SUBSTITUTE

PRINT_SUBSTITUTE

DATE_FROM

DATE_FROM

DATE_TO

DATE_TO

DUEDATE

FAEDN

QUANTITY

QUANTITY

BASE_UOM

QTY_UNIT

ISOCODE_UNIT

QTY_UNIT

QTY_BW_REL

QTY_BW_REL

QTY_FI_CO_REL

QTY_FI_CO_REL

TAX_DATE

EXT_TAX_DATE

TAX_GROUP

TAX_GROUP

TAX_ID

MWSKZ or STRKZ

TAXJURCODE

TXJCD

CONTRACT

VTREF

PA2640_POS_ID1

For example, HVORG,

BUKRS

Mapping via posting area 2640

PA2640_POS_ID2

For example, HVORG,

BUKRS

Mapping via posting area 2640

PA2640_POS_ID3

For example, HVORG,

BUKRS

Mapping via posting area 2640

PA2640_POS_ID4

For example, HVORG,

BUKRS

Mapping via posting area 2640

PA2640 _POS_ID5

For example, HVORG,

BUKRS

Mapping via posting area 2640

PA2640_POS_ID6

For example, HVORG,

BUKRS

Mapping via posting area 2640

PA2640_POS_ID7

For example, HVORG,

BUKRS

Mapping via posting area 2640

ADD_GROUP

ADD_GROUP

Only used if CURRENCY is

not filled

Only used if BASE_UOM is

not filled

Mapping via posting area 2641

The individual fields and their meaning are explained below. See also the documentation of the
fields of structures BAPI_IST_EXTDOC_I and FKKINVBILL_I.

(C) SAP AG

268

The mandatory fields REFDOCNO and LOG_SYSTEM are not transferred to the billing document
items. Instead, for each external document item, in table ITEMS you define the external
document header in table HEADERS to which the item refers. The individual parts of the billing
document are linked by the common document number (field BILLDOCNO in the structures
FKKINBILL_H, FKKINBILL_I, FKKINBILL_T, and FKKINBILL_A).
The mandatory field REFITEM must contain the external item number. Together with the external
document number and the logical system, the external item number uniquely identifies the line
item from which the item of the billing document arose. The external item number must be unique
within a billing document.
In the billing document, the individual items also receive a sequential number
(field BILLDOCITEM in the structure FKKINVBIL_I). This sequential number is
assigned in the order of the items in table ITEMS.
In the field AMOUNT, enter the amount of the line item. The field is optional. This means that
zero amounts are permitted as well as positive or negative amounts.
With the field CURRENCY you define the currency of the billing document item. If you do not
make an entry in the field CURRENCY, you have to enter the currency key in ISO code in the
field ISO_CODE. Use the same currency as for the billing document header. You do not have to
specify a currency if the following conditions are fulfilled:
The amount has value zero (field AMOUNT is initial).
The item is not relevant for posting (field POSTREL is initial).
The item does not belong to a Substitute Group for Invoice Printing (field
PRINT_SUBSTITUTE is initial).
The currency of the document item can only be different to the currency of the billing document
header if the following conditions are fulfilled:
The item is not relevant for posting (field POSTREL is initial).
The item does not belong to a Substitute Group for Invoice Printing (field
PRINT_SUBSTITUTE is initial).
With the field ITEM_SIMULATED you can select simulated line items. Invoicing in Contract
Accounts Receivable and Payable treats these items as non-simulated items for invoice display.
However, there are no postings to FI-CA. The items are not considered in the final invoice
amount.
With the field POSTREL you indicate posting-relevant items. Items that are not relevant for
posting can, for example, contain information for invoice printing. However, their amounts and
quantities are not posted in Contract Accounts Receivable and Payable. There is no account
determination or tax calculation.
With the field PRINTREL you indicate the items that are relevant for invoice printing. Invoicing in
Contract Accounts Receivable and Payable treats billing document items where the field
PRINTREL is not selected as follows dependent on the field POSTREL:
If the field POSTREL is selected, the item is relevant for posting but not for printing. The
amount and quantity are posted in FI-CA (exception: Simulation documents). An item is
created in the invoicing document and made available for invoice printing. In the
application form, using a query for field PRINTREL you can prevent the invoicing
document item from being printed.
If the field POSTREL is not selected, the billing document item is not relevant for posting
or for printing. There is no posting in FI-CA. No invoicing document item is created for this
billing document item.

(C) SAP AG

269

The optional field PRINT_SUBSTITUTE enables you to enter a Substitute Group for Invoice
Printing. It links billing document items that are only relevant for posting with billing document
items that are only relevant for printing. For an application example, see the documentation of the
field.
The mandatory fields DATE_FROM and DATE_TO define the start and end of the period to
which the billing document item relates. DATE_FROM and DATE_TO can be the same, but
DATE_TO cannot be before DATE_FROM.
You can define the due date of an item in the optional field DUEDATE. For more information, see
the field documentation.
In the optional field QUANTITY, you can enter a billing quantity.
In the field BASE_UOM, you enter the unit of measure of the billing quantity. Alternatively, you
can enter the relevant ISO code of the unit of measure in the field ISOCODE_UNIT. Specifying a
unit of measure is mandatory if the billing quantity (field QUANTITY) does not have the value
zero.
If you select the field QTY_BW_REL, the billing quantity (field QUANTITY) is transferred to
Business Intelligence (BI). For line items that are not relevant for posting, the quantity is not
transferred to BI, irrespective of this indicator. You can also influence the update of the line items
in BI at event 2710.
You valuate a quantity with price 1 and price 2. For both line items, you write
the value of the quantity to the field QUANTITY. You only select the field
QTY_BW_REL for one billing document item so that the billing quantity is not
transferred to BI twice. If you select the field QTY_BW_REL, you have to specify a
billing unit of measure (field BASE_UOM or ISOCODE_UNIT).
If you select the field QTY_FI_CO_REL, the billing quantity (field QUANTITY) is transferred to the
General Ledger (FI-GL) and Profitability Analysis (CO). If you select the field QTY_FI_CO_REL,
you have to specify a billing unit of measure (field BASE_UOM or ISOCODE_UNIT).
The field TAX_DATE is used to determine the tax on sales and purchases code. The external tax
date must be filled in a billing line item under the following conditions:
The billing document item is either relevant for posting or has a Substitute Group for
Invoice Printing.
In the related billing document header, the type of tax date has the value 04 Tax
Calculation for External Tax Date. The type of tax calculation has the value 01 Internal Tax
Calculation.
In all other cases, it does not have to be set.
In the field TAX_GROUP, you can specify a tax grouping. In a billing document, this connects
items to tax items. You can only use the tax grouping for billing documents with type of tax
calculation 02 External Tax Calculation. For external tax calculation, it is mandatory for all items
that are relevant for posting or where a Substitute Group for Invoice Printing is specified. In all
other cases, specifying a tax grouping is not allowed. You can use the same tax grouping for
several billing document items. All billing document items that belong to the same grouping must
use the same company code and the same external tax ID (TAX_ID).
The field TAX_ID is used for access to posting area 2641. It should only be filled if:
In the document header, the type of tax calculation has the value 01 Internal Tax
Calculation or 02 External Tax Calculation.
In the line item, the field POSTREL or PRINT_SUBSTITUTE is filled

(C) SAP AG

270

For internal tax calculation, TAX_ID is optional. If there is an entry for TAX_ID, the tax on sales
and purchases code in the billing document item is filled using posting area 2641 (field
FKKINVBILL_I-MWSKZ). For external tax calculation, TAX_ID is mandatory for all items where
POSTREL or PRINT_SUBSTITUTE is filled. For external tax calculation, TAX_ID defines the tax
code (FKKINVBILL_I-STRKZ).
The field TAXJURCODE can be used in certain countries to define the tax jurisdiction. The field
can only be used for internal tax calculation.
The optional field CONTRACT can contain a reference number that, for example, identifies a
contract item. The value is copied to the field VTREF of the billing document items. This
reference is then forwarded in FI-CA up to the business partner items and can be used for
selection.
The fields PA2640_POS_ID1 to PA2640_POS_ID7 are used, together with the logical system, for
access to posting area 2640. The fields are not mandatory and are not subject to any specific
check. Some important fields in the billing document are filled with posting area 2640:
Division (FKKINVBILL_I-SPART)
Company Code (FKKINVBILL_I-BUKRS)
Main Transaction (FKKINVBILL_I-HVORG)
Subtransaction (FKKINVBILL_I-TVORG)
For billing document items where the fields POSTREL or PRINT_SUBSTITUTE contain entries,
the fields for the company code, main transaction, and subtransaction are mandatory; otherwise
they are optional. The division is always optional.
The main and subtransactions are used for access to posting area 2610 for posting-relevant
items. Posting area 2610 provides the G/L account to which the item is posted. For internal tax
calculation, the tax determination code can also be determined using posting area 2610. For
more information, see Internal Tax Determination [Seite 272]. The texts belonging to the
transactions can be used in invoice printing. This property is also useful for items that are not
relevant for posting.
You can use the optional field ADD_GROUP to assign a document additional item to the billing
document item. If you do not use billing document additional items, the field remains empty.

Items Relevant for Posting and Printing

Invoicing in Contract Accounts Receivable and Payable posts the data from billing documents in
Contract Accounts Receivable and Payable (FI-CA) and prepares the data for invoice printing.
The display of the data in the invoice printout can vary from the creation of the posting records for
FI-CA to a greater or lesser extent. You can influence the different processing with the following
fields:
Line Item Is Simulated (ITEM_SIMULATED)
Line Item Relevant for Posting (POSTREL)
Line Item Relevant for Printing (PRINTREL)
Substitute Group for Invoice Printing (PRINT_SUBSTITUTE)
The items of the billing document shown below contain all permitted combinations. Other
combinations are not allowed.
Items

(C) SAP AG

271

REFITEM

001

002

003

004

005

006

ITEM_SIMULATED
POSTREL

PRINTREL

PRINT_SUBSTITUTE
AMOUNT

1.00

X
X

AA

AA

AA

2.25

3.10

5.35

1.00

007

008

009

010

011

012

X
X

1.00

1.10

BB

BB

BB

2.45

3.20

5.65

1.10

Item 001 is the standard case; the item is relevant for posting and should be printed.
Items 002 to 004 are connected by a Substitute Group for Invoice Printing. This is because for the
billing of a service internally, two partial amounts (2.25 and 3.10) are to be posted to different
accounts. For the customer howerver, only the total amount (5.35) is to be visible. Therefore, only
items 002 and 003 are relevant for posting and only item 004 is relevant for printing.
Item 005 is only printed and not posted. It contains information not relevant for posting. You can
enter an amount.
Item 006 is relevant for neither posting nor printing. Such a billing document item may be useful
for technical reasons. No item is created in the invoicing document for this item in the billing
document.
Items 007 to 012 repeat the setting of items 001 to 006 with regard to the fields POSTREL,
PRINTREL, and PRINT_SUBSTITUTE. (A new Substitute Group for Invoice Printing must be
used.) However, the field ITEM_SIMULATED is selected for these items. Simulated items enable
you to print a comparison rate, for example. This shows the customer what he/she would have
had to pay with a different rate. Items where ITEM_SIMULATED is selected are not posted in FICA regardless of the value of the field POSTREL.
For items where ITEM_SIMULATED is selected, Invoicing in Contract Accounts Receivable and
Payable determines the taxes according to the same rules as for non-simulated items. This
enables you to also print the simulated items with the taxes. The taxes are not posted.
For items connected by a Substitute Group for Invoice Printing, there is a
balance check. The amount total of the items relevant for posting must agree with
the amount total of the items relevant for printing. If the substitute group for the
invoice printing contains different tax codes, there is a balance check for each tax
code. Therefore, make sure that the tax determination is also correct for the items
not relevant for posting with an entry for the Substitute Group for Invoice Printing.

Internal Tax Determination

Use
Internal tax determination determines the tax rate.

Prerequisites
Internal tax determination takes place if you have selected the value 01 Internal tax determination
in the table HEADERS (field TAX_DET_TYPE in the structure BAPI_IST_EXTDOC_H).

(C) SAP AG

272

1.10

Features
The following figure shows the rules used to determine the tax rate for internal tax determination.
Inbound interface
TAX_DATE_TYPE

TAX_DATE

Keys 1 to 7

CONT_ACC

TAX_ID

Posting area
2640

Event
2100

Posting area
2641

HVORG, TVORG,
BUKRS, SPART

KOFIZ

TAXJURCODE

Mapping

Posting area
2610

Billing document
TAX_DATE_TYPE

EXT_TAX_DATE

ERMWSKZ

MWSKZ

Determine
tax date

Determine
tax code

MWSKZ

TXJCD

Invoicing

Posting date etc.

Tax rate

Example
Firstly, the processing of an item where the field TAX_ID is not filled in table ITEMS (structure
BAPI_IST_EXTDOC_I) is considered. In this case, the tax is determined indirectly by the generic
fields PA2640_POS_ID1 to PA2640_POS_ID7 of table ITEMS. Firstly, the system accesses
posting area 2640 with these fields. Using posting area 2640, the following fields of the billing
document item are filled:
HVORG Main Transaction
TVORG Subtransaction
BUKRS Company Code
SPART Division
In a further step, these fields are used for the access to posting area 2610. A key field of posting
area 2610 is the Account Determination ID (field KOFIZ). The account determination ID is
determined by event 2100. Usually, event 2100 uses the account determination ID defined in the
contract account. Posting area 2610 defines the tax determination code stored in the billing
document item (field ERMSKZ).
To determine the tax code (field MWSKZ) from the tax determination code (field ERMWSKZ), you
need a further date. There are various alternatives. With the field TAX_DATE_TYPE, in table
HEADERS you define which tax date is to be used. The system transfers your selection to the
field in the billing document header with the same name (FKKINVBILL_H-TAX_DATE_TYPE).
Depending on your selection, Invoicing in Contract Accounts Receivable and Payable uses the
document date, the posting date, or the date of creation. You can also define the value 04 Tax
calculation on external tax date for TAX_DATE_TYPE. In this case, you have to enter an explicit
tax date in the field TAX_DATE for all tax-relevant items in table ITEMS. The tax date is copied to

(C) SAP AG

273

the field EXT_TAX_DATE of the billing document item and used by Invoicing in Contract
Accounts Receivable and Payable.
In Invoicing in Contract Accounts Receivable and Payable, tax determination code (ERMWSKZ)
and tax date determine the tax code (field MWSKZ) and thus the tax rate.
Determination using the tax determination code has the advantage that you do not have to know
the tax rate at the time when the billing document is created. You can create a billing document
and still use the tax rate valid at the time of invoicing.
However, if you know the final valid tax rate when you create the billing document, you can save
this explicitly in the billing document. To do this, in table ITEMS fill the field TAX_ID. With this
external tax code the system accesses posting area 2641. The company code of the item defines
the country key also required for the access. Posting area 2641 provides the tax code (field
MWSKZ). The tax determination code of the billing document item (field ERMWSKZ) is not filled.
Invoicing in Contract Accounts Receivable and Payable transfers the value of the field MWSKZ.
In some countries, the calculation of the tax is also dependent on the tax jurisdiction (jurisdiction
code [Extern]). In the inbound interface, you can use the field TAXJURCODE in table ITEMS for
the tax jurisdiction. The field is copied to the field TXJCD of the billing document item that
Invoicing in Contract Accounts Receivable and Payable uses for the tax calculation.

Billing Document Tax Items

Definition
Tax item in billing document

Use
You can only use billing document tax items for billing documents with type of tax calculation 06
External Tax Calculation.

Structure
You define the properties of the billing document tax items using the import table TAXITEMS. The
system creates a billing document tax item (structure FKKINVBILL_T) for each entry in this table
(structure BAPI_IST_EXTDOC_T).
Overview
Source Field in Table
TAXITEMSS

Target Field in Billing

Document Tax Item

Comment

REFDOCNO

Identifies the billing document

header

LOG_SYSTEM

Identifies the billing document

header

REFTAXITEM

REFTAXITEM

TAX_GROUP

TAX_GROUP

TAX_DATE

TAX_DATE

(C) SAP AG

274

TAX_BASE

TAX_BASE

TAX_PERC

TAX_PERC

TAX_AMOUNT

TAX_AMOUNT

CURRENCY

BILL_CURR

ISO_CODE

BILL_CURR

Only used if CURRENCY is

not filled

SUB_TAX_ID

KSCHL

Mapping via posting area 2642

The individual fields and their meaning are explained below. See also the documentation of the
fields of structures BAPI_IST_EXTDOC_T and FKKINVBILL_T.
The mandatory fields REFDOCNO and LOG_SYSTEM are used to identify the relevant
document header, as for the billing document items.
The mandatory field REFTAXITEM must contain the external tax item number. Together with the
external document number and the logical system, the external tax item number uniquely
identifies the external tax item from which the tax item of the billing document arose. The external
tax item number must be unique within a billing document.
In the billing document, the individual tax items also receive a sequential
number (field BILLDOCTAXITEM in the structure FKKINVBIL_T). This sequential
number is assigned in the order of the tax items in table TAXITEMS.
The mandatory grouping field TAX_GROUP links the billing document tax items with billing
document items. The grouping enables an N:M linking: One or more tax items can be linked with
one or more items.
In the mandatory field TAX_DATE, you enter the tax date.
In the field TAX_BASE, enter the base amount to which the tax refers.
In the optional field TAX_PERC, you can enter a tax percentage rate. The tax percentage rate is
for information purposes only.
In the field TAX_AMOUNT, enter the tax amount. This tax amount is posted to special G/L
accounts unchanged.
With the field CURRENCY you define the currency of the billing document tax item. If you do not
make an entry in the field CURRENCY, you have to enter the currency key in ISO code in the
field ISO_CODE.
The mandatory field SUB_TAX_ID is used for access to posting area 2642. Further key fields of
the posting area are the external tax ID and the country key. The external tax code (field TAX_ID)
is transferred from the billing document items that are connected to the billing document tax items
using the tax grouping. The country key is determined by means of the company code of the
billing document item. Posting area 2642 fills the Category of Tax Item (field KSCHL in structure
FKKINVBILL_T).

(C) SAP AG

275

Account Determination with External Tax Calculation

Definition
Link of the posting-relevant items (table ITEMS) and tax items (table TAXITEMS) with the help of
the tax grouping (field TAX_GROUP) in the inbound interface.

Structure
The following figure shows the interaction of the billing document items and the billing document
tax items for external tax calculation.
Inbound interface
TAX_DATE_TYPE

TAX_DATE

Keys 1 to 7

CONT_ACC

TAX_ID

Posting area
2640

Event
2100

Posting area
2641

HVORG, TVORG,
BUKRS, SPART

KOFIZ

TAXJURCODE

Mapping

Posting area
2610

Billing document
TAX_DATE_TYPE

EXT_TAX_DATE

ERMWSKZ

MWSKZ

Determine tax
date

Determine tax
code

MWSKZ

TXJCD

Invoicing

Posting date etc.

Tax rate

In external tax calculation, the external tax code (field TAX_ID in the structure
BAPI_IST_EXTDOC_I) is used to derive the tax code for other taxes (field STRKZ in the structure
FKKINVBILL_I) using posting area 2641. A country key is also required for access to posting area
2641. The country key is determined by means of the company code (field BUKRS) of the billing
document item. The system checks whether the tax code (STRKZ) is maintained in table
TFK007F. In table TFK007F, the indicator Use Item Category (field XKSCHL) must be set.
In the inbound interface, you have to specify an external tax code (field SUB_TAX_ID) for all tax
items (table TAXITEMS). It is used to access posting area 2642. For the access, the country key
and the external tax code (field TAX_ID) are transferred from the billing document item. Posting
area 2642 defines the category of the tax item (field KSCHL) in the billing document tax item. The
system checks whether the combination of the Category of Tax Item (field KSCHL from structure
FKKINVBILL_T) and the external tax code (field STRKZ from structure FKKINVBILL_I) is
maintained in table TFK007FK. In table TFK007FK, the indicator External Tax Percentage Rate
(field PERTAX_EXT) must be set.
To access posting area 0015, Invoicing in Contract Accounts Receivable and Payable uses the
company code and the tax code for other taxes (fields BUKRS and STRKZ from structure
FKKINVBILL_I) from the billing item together with the category of tax item (field KSCHL from

(C) SAP AG

276

structure FKKINVBILL_T). Posting area 0015 provides the G/L account to which the external
taxes are posted.

Account Determination with External Tax Calculation

The following example shows how the billing document items are linked with the billing document
tax items.
In the inbound interface, you fill table ITEMS with the following item data:
REFITEM

004

005

POSTREL

TAX_GROUP

0008

0008

TAX_ID

AMOUNT

100.00

50.00

In table TAXITEMS, the tax item data you enter includes:

REFTAXITEM

0016

0017

0018

TAX_GROUP

0008

0008

0008

TAX_BASE

150.00

150.00

159.01

TAX_AMOUNT

5.23

3.78

2.31

SUB_TAX_ID

1020

1025

1045

In tax grouping 0008, two billing document items are linked with three billing document tax items.
Therefore, the taxes refer to both net amounts.
The different external tax subcodes (field SUB_TAX_ID) enable you to post the tax amounts to
different accounts.

Billing Document Additional Items

Definition
Additional item in the billing document

Structure
You define the properties of the billing document additional items using the import table
ADDITEMS. The system creates a billing document additional item (structure FKKINVBILL_A) for
each entry in this table (structure BAPI_IST_EXTDOC_A).
Source Field in Table
ADDITEMS

(C) SAP AG

Target Field in Billing

Document Additional Item

Note

277

REFDOCNO

Identifies the billing document

header

LOG_SYSTEM

Identifies the billing document

header

REFADDITEM

REFADDITEM

ADD_GROUP

ADD_GROUP

The mandatory fields REFDOCNO and LOG_SYSTEM are used to identify the relevant
document header, as for the billing document items.
The mandatory field REFADDITEM must contain the external additional item number. Together
with the external document number and the logical system, the external additional item number
uniquely identifies the external additional item from which the additional item of the billing
document arose. The external additional item number must be unique within a billing document.
In the billing document, the individual additional items also receive a sequential
number (field BILLDOCADDITEM in the structure FKKINVBIL_A). This sequential
number is assigned in the order of the additional items in table ADDITEMS.
The mandatory grouping field ADD_GROUP links the billing document additional item with the
billing document header and/or the billing document items. The grouping permits you to link one
or more additional items with one or more items. One or more additional items can be linked with
the document header. The grouping can be used in invoice printing to print the additional items in
the correct place.

Creating Billing Documents

Use
In the following cases, it may be useful to create billing documents "artificially":
You want to test Invoicing in Contract Accounts Receivable and Payable in a test system.
The transfer of external data with the BAPI BAPI_ISTBILLDOC_CREATEMULTIPLE is not
realized for the test system.

Activities
Program a customer-specific report for the generation of billing documents. SAP provides the
report IST_SAMPLE_CREATE_BILLDOC as a template for an own solution. Please proceed as
follows:
...

1. Copy the report IST_SAMPLE_CREATE_BILLDOC.

2. Remove the part of coding that causes the termination of processing.
3. Adjust the report so that it meets your requirements.
The report uses the function module IST_INV_SAMPLE_EXTERN_BILLDOCS to simulate
external data and creates test billing documents from this using the
BAPI_ISTBILLDOC_CREATEMULTIPLE function module. You can add the external data in the
IST_INV_SAMPLE_EXTERN_BILLDOCS function module if necessary. Instead of the module
IST_INV_SAMPLE_EXTERN_BILLDOCS, you can also use an own function module.

(C) SAP AG

278

You should not run a report that creates billing documents for test purposes in
a production system under any circumstances, since it creates posting-relevant
documents for FI-CA.

Reversing Billing Documents with

BAPI_ISTBILLDOC_CANCEL
Use
You cannot delete or deactivate billing documents processed in Invoicing in Contract Accounts
Receivable and Payable and posted in Contract Accounts Receivable and Payable (FI-CA).
However, with the Business Application Programming Interface (BAPI)
BAPI_ISTBILLDOC_CANCEL, you can reverse a billing document.
Reversing a billing document that has not been invoiced means that its invoicing order is deleted.
It is not possible to repeat invoicing for the reversed billing document. The system usually creates
a reversal billing document that does not contain any items and that is also not invoiced.
When you reverse a billing document that has already been invoiced, the system creates a
reversal billing document that contains copies of the items from the reversed billing document.
The plus/minus signs are reversed for these copied items. The system invoices the reversal
billing document, which compensates the postings for the reversed billing document.
You can also reverse adjustment billing documents [Seite 292].
During reversal, the system checks whether there is a dispute case for the billing document that
does not yet have the status Completed. If this is the case, the system changes the status to
Completed. The last processing status is assigned the value Source Document Reversed. The
system does not create dispute cases for reversal billing documents.

Features
The following parameters are available:
The import parameter REVERSED_DOC identifies the billing document that is to be
reversed.
The components LOG_SYSTEM and REFDOCNO must be filled. They identify the
billing document to be reversed from the view of the legacy system.
The component CONT_ACCT must contain the contract account of the document
to be reversed. Alternatively, you can leave CONT_ACCT empty and fill
CONT_ACCT_ID.
The import parameter REVERSAL_DOC defines the properties of the reversal document:
The component REFDOCNO must contain the document number of the reversal
document in the external system.
The component DOCTYPE_EXT is used to determine the document type of the
reversal document using posting area 2645. If you leave this component empty, the
document type of the document to be reversed is copied.

(C) SAP AG

279

The import parameter READ_ARCHIVE defines whether or not the system also searches
for the billing document in the archive. The system always searches first on the database.
If it does not find the document there and the parameter READ_ARCHIVE is selected, it
then searches in the archive.
If you select the import parameter TESTRUN, the BAPI does not perform any database
changes. However, all checks are carried out. Any errors that occurred are written to the
export table RETURN.
In the component BILLDOCNO, the export parameter NEW_REVERSALDOC contains the
document number of the reversal document.
With the import table EXTENSIONIN, you can provide the BAPI with additional data. The
SAP standard delivery ignores the table; it is merely forwarded to the methods of the BAdI
ISTINV_BILL_CANCEL.
With the export table EXTENSIONOUT, the BAPI can return additional data to the caller.
The standard system delivered by SAP does not use the export table. If you want to fill the
table, you have to implement the methods of the BAdI ISTINV_BILL_CANCEL.
The export table RETURN contains all log messages. If the table contains one or more
messages of message type E or A, an error has occurred that led to termination of
processing.
Note:
The BAPI BAPI_ISTBILLDOC_CANCEL:
Performs direct updates in a successful case and does not use the update
task
Performs a COMMIT WORK for each call
Does not perform any separate authorization checks
You cannot use the BAPI BAPI_ISTBILLDOC_CANCEL to do the following:
Reverse simulated billing documents
Repeat reversal of billing documents that have already been reversed
Reverse reversal documents
Reverse adjusted billing documents
Reversal billing documents require a unique reference to a document in the legacy
system.

Reversing Uninvoiced Billing Documents

This example is based on the following billing document with document number 4201.

(C) SAP AG

280

Billing
documents

BILLDOCNO
BILLDOCNO
REVERSALDOC
REVERSALDOC
REVERSEDDOC
REVERSEDDOC

4201
4201

+100.00
+100.00 USD
USD
+20.00
+20.00 USD
USD

Invoicing
orders

Invoicing
documents

FI-CA

It has not been invoiced, which means the following invoicing order still exists:

Billing
documents

BILLDOCNO
BILLDOCNO
REVERSALDOC
REVERSALDOC
REVERSEDDOC
REVERSEDDOC

4201
4201
5801
5801

BILLDOCNO
BILLDOCNO
REVERSALDOC
REVERSALDOC
REVERSEDDOC
REVERSEDDOC

5801
5801
4201
4201

+100.00
+100.00 USD
USD
+20.00
+20.00 USD
USD

Invoicing
orders

Invoicing
documents

FI-CA

...

1. The BAPI BAPI_ISTBILLDOC_CANCEL creates a reversal document with document

number 5801.
2. In billing document 4201, the system enters the document number 5801 of the reversal
document in the field REVERSALDOC. It is therefore designated as a reversed document.
In reversal document 5801, the system enters the document number 4201 of the reversed

(C) SAP AG

281

document in the field REVERSEDDOC. Document 5801 is therefore designated as a

reversal document.
Reversal document 5801 consists only of a document header. It does not contain any
billing document items.
3. The system does not create an invoicing order for reversal document 5801 and deletes the
invoicing order for the reversed billing document 4201. This prevents the amounts of the
reversed billing documents being posted in FI-CA.

Reversing Invoiced Billing Documents

This example is based on the following invoiced billing document with document number 4202.

Billing
documents

BILLDOCNO
BILLDOCNO
REVERSALDOC
REVERSALDOC
REVERSEDDOC
REVERSEDDOC

4202
4202

+100.00
+100.00 USD
USD
+20.00
+20.00 USD
USD

Invoicing
orders

Invoicing
documents

FI-CA

INVDOCNO
INVDOCNO

7062
7062

+100.00
+100.00 USD
USD
+20.00
+20.00 USD
USD

+100.00 USD
+ 20.00 USD

...

1. Billing document 4202 has already been invoiced. Invoicing in Contract Accounts
Receivable and Payable has deleted the invoicing order and created invoicing document
7062.
The amounts from billing document 4202 have been transferred to the following invoicing
document and posted in FI-CA.

(C) SAP AG

282

Billing
documents

BILLDOCNO
BILLDOCNO
REVERSALDOC
REVERSALDOC
REVERSEDDOC
REVERSEDDOC

4202
4202
5802
5802

+100.00
+100.00 USD
USD
+20.00
+20.00 USD
USD

BILLDOCNO
BILLDOCNO
REVERSALDOC
REVERSALDOC
REVERSEDDOC
REVERSEDDOC

5802
5802
4202
4202

-100.00
-100.00 USD
USD
-20.00
-20.00 USD
USD

Invoicing
orders

Invoicing
documents

FI-CA

INVDOCNO
INVDOCNO

7062
7062

+100.00
+100.00 USD
USD
+20.00
+20.00 USD
USD

+100.00 USD
+ 20.00 USD

2. The BAPI BAPI_ISTBILLDOC_CANCEL creates a reversal document with document

number 5802.
The reversed billing document 4202 and the reversal document 5802 are linked by means
of the fields REVERSALDOC and REVERSEDDOC.
Reversal document 5802 contains copies of the items of the reversed document 4202.
However, the +/- signs of the amounts and quantities have been inverted.
The following invoicing order is created for reversal document 5802.

(C) SAP AG

283

Billing
documents

BILLDOCNO
BILLDOCNO
REVERSALDOC
REVERSALDOC
REVERSEDDOC
REVERSEDDOC

4202
4202
5802
5802

+100.00
+100.00 USD
USD
+20.00
+20.00 USD
USD

BILLDOCNO
BILLDOCNO
REVERSALDOC
REVERSALDOC
REVERSEDDOC
REVERSEDDOC

5802
5802
4202
4202

-100.00
-100.00 USD
USD
-20.00
-20.00 USD
USD

Invoicing
orders

Invoicing
documents

FI-CA

INVDOCNO
INVDOCNO
+100.00
+100.00 USD
USD
+20.00
+20.00 USD
USD

+100.00 USD
+ 20.00 USD

7062
7062

INVDOCNO
INVDOCNO

8402
8402

-100.00
-100.00 USD
USD
-20.00
-20.00 USD
USD

-100.00 USD
- 20.00 USD

3. The system invoices reversal document 5802. The amounts of the reversal document are
posted in the same amount as those of billing document 4202 but with inverse +/- sign in
Contract Accounts Receivable and Payable.

Calling BAdI Methods in the BAPI

BAPI_ISTBILLDOC_CANCEL
Use
When you run the BAPI BAPI_ISTBILLDOC_CANCEL, it runs methods of the BAdIs
ISTINV_BILL_CANCEL and FKKINV_BAPIBILL. See also the documentation for the methods.

Features
The figure below shows where the individual methods are carried out and in which order:

(C) SAP AG

284

BAdI FKKINV_BAPIBILL

BAPI_ISTBILLDOC_CANCEL

BAdI ISTINV_BAPIBILL_CANCEL

CL_ISTINV_BAPIBILL
CREATE
CHECK
USER_CHECK_INPUT
CONTRACT_ACCOUNT_DETERMIN
E

CHECK_INPUT_PARAMETERS

USER_CONTR_ACCT_KEY_DETERMINE

USER_CHECK_REVERSAL_ORDER

CHECK_REVERSAL_ORDER

REVERSALDOC_CREATE
REVERSALDOC_HEADER_CREATE

REVERSALDOC_ITEMS_CREATE
REVERSALDOC_TAXITEMS_CREATE

COLL_BILL_PARTNER

REVERSALDOC_ADDITEMS_CREATE

FILL_CUSTOMER_FIELDS_HEADER
REVERSAL_ITEM_ANALYZE
FILL_CUSTOMER_FIELDS_ITEM
FILL_CUSTOMER_FIELDS_TAXITEM
FILL_CUSTOMER_FIELDS_ADDITEM

REVERSALDOC_TRIGGER_CREATE

FILL_TRIG_CUSTOMER_FIELDS
SAVE
UPDATE_PREPARE
UPDATE_PREPARE

GET_NUMBER
UPDATE

UPDATE

Database
Billing
document

Invoicing
order

Z table

With the method CHECK_INPUT_PARAMETERS, you can check the input parameters of the
BAPI. In particular, you should implement the method if you use the EXTENSIONIN parameter to
process customer own data.
The method CHECK_REVERSAL_ORDER checks whether a billing document can be reversed
for specific customers. You can ususlly reverse all billing documents in the standard SAP system.
An exception to this are simulated documents that have already been reversed and their
associated reversal documents. However, in certain cases, it may be useful to prevent the
reversal of a billing docment if, for example, you only want to permit the reversal of the most
recent unreversed billing document of a contract account.
Billing documents are in chronological order. There are documents for the
months January, February, and March. You can only reverse the February
document if you have already reversed the March document.
You can use method FILL_CUSTOMER_FIELDS_HEADER to make entries in customer fields in
the document header of the reversal document. You only require this method if you are using
customer own fields (include CI_FKKINVBILL_H) in the billing document header (structure
FKKINVBILL_H). Customer fields in the document header of the billing document to be reversed
are copied into the reversal document in the standard SAP system. if you require different values
in these fields, you must implement this method.
With the methods FILL_CUSTOMER_FIELDS_ITEM, FILL_CUSTOMER_FIELDS_TAXITEM,
and FILL_CUSTOMER_FIELDS_ADDITEM, you can change the customer own fields of the
other parts of the billing document.
The method REVERSAL_ITEM_ANALYZE is called for all line items that are not posting-relevant
or do not belong to a substitute group for invoice printing (fields POSTREL and
PRINT_SUBSTITUTE are empty). The system copies the line items of the billing document to be
reversed if this document has already been invoiced. The system reverses the +/- sign for
amount and quantity in document items that are relevant for posting. You can use this method to
decide whether the document items are to be copied and whether the +/- sign is to be reversed. If

(C) SAP AG

285

the billing document to be reversed has not been invoiced yet, the system creates a reversal
document that contains only a document header. In this case, this method is not called.
After a successful check the update is prepared. The system determines the document number
for the reversal document and provides it for the method UPDATE_PRPARE. There, if necessary,
you can save data for the update of a customer own table in the global memory of their
implementation.
Then the tables are updated. Firstly, the document data is written to the tables of the SAP
standard system. Then the method UPDATE is called; you can use this to write data from the
global memory to your own tables.
If you implement the method UPDATE, you have to consider the following
rules:
Do not create any error messages in this method. All re-formulations,
conversions, and checks of data must have taken place previously.
No COMMIT WORK can take place in this method.
Perform a direct update and do not use any update modules (IN UPDATE
TASK).
The methods CONTRACT_ACCOUNT_DETERMINE, COLL_BILL_PARTNER, and
FILL_TRIG_CUSTOMER_FIELDS of the BAdI FKKINV_BAPIBILL are called if an
invoicing order is created for the reversal document. Their meaning corresponds to
that in the BAPI BAPI_ISTBILLDOC_CREATEMULTIPLE.
You should avoid database accesses as far as possible in your implementations in
order to improve performance.

Testing Reversals of Billing Documents

Use
With a report that you create using sample report IST_SAMPLE_CANCEL_BILLDOC as a
template, you can test the reversal of billing documents in a test system.

Features
The sample report calls the BAPI BAPI_ISTBILLDOC_CANCEL and reverses a billing document
without reference to a reversal document from an external system. Such a reversal would be an
error in a productive system and would destroy the consistency of the external documents and
the documents in the SAP system. Therefore, report IST_SAMPLE_CANCEL_BILLDOC
terminates the run immediately.

Activities
...

1. If required, copy the report IST_SAMPLE_CANCEL_BILLDOC.

2. Remove the coding lines that call the termination.
3. Make sure that the report is only run in a test system.
Report IST_SAMPLE_CANCEL_BILLDOC uses a GUID for the reference document number of
the reversal document (field REFDOCNO in structure FKKINVBILL_H).

(C) SAP AG

286

Adjusting Billing Documents with

BAPI_ISTBILLDOC_ADJUST
Use
You can use the Business Application Programming Interface BAPI_ISTBILLDOC_CANCEL to
adjust a billing document. This is particularly useful because you cannot delete or deactivate
billing documents processed in Invoicing in Contract Accounts Receivable and Payable and
posted to Contract Accounts Receivable and Payable.
The process of adjusting a billing document is similar to reversing and creating a new one. If you
reverse a document using BAPI_ISTBILLDOC_CANCEL, the system either suppresses invoicing
for the reversed billing document, or generates and invoices a reversal document with the same
items but a reversed plus/minus sign. This means that once the reversal process is completed,
either no postings have been made or the postings have been compensated by offsetting entries
(the balance is zero). While you can use Mit BAPI_ISTBILLDOC_CREATEMULTIPLE to generate
a new billing document, it has no relationship to the reversal document.
By contrast, when you adjust a billing document, you do not simply compensate for postings of
the adjusted billing document, you actually prevent them. You can also post additional new items.
This means an adjustment billing document can contain copied items with a reversed plus/minus
sign (like a reversal billing document) on the one hand, and on the other hand, additional items
with the correct amounts. In the same way as a reversal, this depends on whether or not the
adjusted billing document had already been invoiced.

Features
The following parameters are available:
The import parameter ADJUSTED_DOC identifies the billing document that is to be
adjusted.
The reference document number of the billing document that is to be adjusted must
be entered in the component ADJREFDOCNO. It identifies the billing document for
adjustment in the legacy system together with the logical system (component
LOG_SYSTEM in the import parameter HEADER).
The import parameter HEADER defines the properties of the adjustment billing document
header. Please note that the following properties of the adjustment billing document and
the adjusted billing document must match:
Contract account
Business partner
Currency key
Type of tax calculation
Type of tax date
If you select the import parameter TESTRUN, the BAPI does not make any changes to the
database. However, all checks are carried out. Any errors that occurred are written to the
export table RETURN.
The import parameter READ_ARCHIVE defines whether or not the system also searches
for the billing document in the archive. The system always searches first on the database.

(C) SAP AG

287

If it does not find the document there and the parameter REASD_ARCHIVE is selected, it
then searches in the archive.
If you select the import parameter CFCVALIDATION, the system runs the checks in
clarification processing for the adjustment document. If it does not pass these checks, the
system creates a dispute case for the adjustment billing document. Irrespective of the
import parameter CFCVALIDATION, the system always checks whether there is a dispute
case that has not yet been resolved for the billing document to be adjusted. If this is the
case, the dispute case for the billing document is set to Complete.
In the component ADJUSTMENTDOC, the export parameter NEW_ ADJUSTMENTDOC
contains the document number of the adjustment billing document.
The import table ITEMS must be filled with the external document items.
The import table TAXITEMS can be filled with tax data if the tax is calculated in an external
system.
You can fill the import table ADDITEMS with document additional items.
With the import table EXTENSIONIN, you can provide the BAPI with additional data. The
standard SAP system ignores this table. It is only passed on to the BAdI methods for
ISTINV_BAPIBILL, FKKINV_BAPI, and BILL ISTINV_BILL_CANCEL.
With the export table EXTENSIONOUT, the BAPI can return additional data to the caller.
The standard system delivered by SAP does not use the export table. If you want to fill the
table, you have to implement the methods of the BAdIs ISTINV_BAPIBILL, FKKINV_BAPI,
or ISTINV_BILL_CANCEL.
The export table RETURN contains all log messages. If the table contains one or more
messages of message type E or A, an error has occurred that led to termination of
processing.

Please note:
The BAPI BAPI_ISTBILLDOC_ADJUST:
Performs direct updates when processing is successful and does not use the
update task
Performs a COMMIT WORK for each call
Does not perform any separate authorization checks
The BAPI BAPI_ISTBILLDOC_CANCEL does not allow you to:
Adjust simulated billing documents
Adjust reversed billing documents
Adjust reversal documents
Repeat adjustment of adjusted billing documents. However, you can adjust
adjustment billing documents yourself.
Adjustment billing documents require a unique reference to a document in the
legacy system.
You may need to adjust a billing document if an amount is incorrect in one item, even if the other
items are correct. However, when you adjust a billing document, the system suppresses or
compensates postings for all items. This means you must always enter all the items in the import
tables ITEMS, TAXITEMS, and ADDITEMS.

(C) SAP AG

288

Suppose a billing document contains the following items:

Item 0001 with the amount 50.00
Item 0002 with the amount 60.00
Item 0003 with the amount 70.00
The amount for the third item (70.00) is not correct. 75.00 is the correct
amount. You therefore perform an adjustment.
You enter the following external item data in the import table ITEMS:
Item 0001 with the amount 50.00
Item 0002 with the amount 60.00
Item 0003 with the amount 75.00
The BAPI BAPI_ISTBILLDOC_ADJUST primarily uses the same source text as the BAPIs
BAPI_ISTBILLDOC_CREATEMULTIPLE and BAPI_ISTBILLDOC_CANCEL. This means the
system also processes the methods of BAdIs ISTINV_BAPIBILL, FKKINV_BAPI, and
ISTINV_BILL_CANCEL.

Adjusting Uninvoiced Billing Documents

This example is based on the following billing document with document number 4202.

Billing documents

Billing document not

invoiced

Create and invoice

adjustment document

BILLDOCNO
4202
BILLDOCNO
4202
ADJUSTMENTDOC
ADJUSTMENTDOC 4203
4203
ADJUSTEDDOC
ADJUSTEDDOC

BILLDOCNO
4203
BILLDOCNO
4203
ADJUSTMENTDOC
ADJUSTMENTDOC
ADJUSTEDDOC
4202
ADJUSTEDDOC
4202

010
010
020
020

010
010
020
020

+100.00
+100.00 USD
USD
+20.00
+20.00 USD
USD

+100.00
+100.00 USD
USD
+21.00
+21.00 USD
USD

Invoicing documents

INVDOCNO
INVDOCNO

7063
7063

+100.00
+100.00 USD
USD
+21.00
+21.00 USD
USD

FI-CA

+100.00
+100.00 USD
USD
+21.00
+21.00 USD
USD
------------------------+121.00
+121.00 USD
USD

The postings in Contract Accounts Receivable and Payable are shown in abbreviated form here
and in the following examples.

(C) SAP AG

289

Process Flow
4. The BAPI BAPI_ISTBILLDOC_ADJUST creates an adjustment billing document with
document number 4203.
5. In billing document 4202, the system enters the document number 4203 of the adjustment
billing document in the field ADJUSTMENTDOC. This designates it as an adjusted
document. In adjustment billing document 4203, the system enters the document number
4202 of the adjusted document in the field ADJUSTEDDOC. This means document 4203 is
therefore marked as an adjustment document.
6. Adjustment billing document 4203 only contains items that replace the adjusted billing
document 4202. There are no copied items from billing document 4202 with a reversed
plus/minus sign.
7. The system creates an invoicing order for adjustment billing document 4203 and deletes
the invoicing order for the adjusted billing document 4202. This prevents the amounts from
the adjusted billing documents being posted in Contract Accounts Receivable and Payable.

Adjusting Invoiced Billing Documents

This example is based on the following billing document with document number 4202.

Billing documents

Billing document
invoiced

Create and invoice

adjustment document

BILLDOCNO
4202
BILLDOCNO
4202
ADJUSTMENTDOC
ADJUSTMENTDOC 4203
4203
ADJUSTEDDOC
ADJUSTEDDOC

BILLDOCNO
4203
BILLDOCNO
4203
ADJUSTMENTDOC
ADJUSTMENTDOC
ADJUSTEDDOC
4202
ADJUSTEDDOC
4202

010
010
020
020

010
010
020
020
030
030
040
040

+100.00
+100.00 USD
USD
+20.00
+20.00 USD
USD

Invoicing documents

INVDOCNO
INVDOCNO

7062
7062

+100.00
+100.00
+21.00
+21.00
-100.00
-100.00
-20.00
-20.00

USD
USD
USD
USD
USD
USD XX
USD
USD XX

INVDOCNO
INVDOCNO

FI-CA

+100.00
+100.00 USD
USD
+20.00
+20.00 USD
USD

+100.00
+100.00
+21.00
+21.00
-100.00
-100.00
-20.00
-20.00

+100.00
+100.00 USD
USD
+20.00
+20.00 USD
USD
------------------------+120.00
USD
+120.00 USD

+100.00
+100.00 USD
USD
+20.00
+20.00 USD
USD
+1.00
+1.00 USD
USD
------------------------+121.00
+121.00 USD
USD

7063
7063

USD
USD
USD
USD
USD
USD XX
USD
USD XX

Process Flow
8. Billing document 4202 has already been invoiced. Invoicing in Contract Accounts
Receivable and Payable has deleted the invoicing order and created invoicing document
7062.
The amounts from billing document 4202 have been transferred to the invoicing document
and posted in FI-CA.

(C) SAP AG

290

9. The BAPI BAPI_ISTBILLDOC_ADJUST creates an adjustment billing document with

document number 4203.
The adjusted billing document 4202 and the adjustment billing document 4203 are linked
by means of the fields ADJUSTMENTDOC and ADJUSTEDDOC.
The adjustment billing document 4203 contains items with partially changed amounts that
replace the items in the adjusted billing document (items 010, 020). It also receives copied
items from billing document 4202 with a reversed plus or minus sign (items 030, 040).
These items are generated automatically by BAPI_ISTBILLDOC_ADJUST. The indicator
REVERSALITEM is selected ('X') for these items.
An invoicing order is created for adjustment billing document 4203.
The clarification processing checks can be run for adjustment billing document 4203. The
interface only passes on items where the REVERSALITEM indicator is not selected to the
check functions. In this example, the interface would transfer items 010 and 020 but not
030 or 040 to the check functions.
10. The system invoices adjustment billing document 4203. The balance in Contract Accounts
Receivable and Payable corresponds to the amount for items 010 and 020.

Repeating Adjustment of Invoiced Billing

Documents
In this example, billing document 4202 is adjusted three times.
Process Flow: Repeated Adjustment

Billing documents

Billing document
invoiced

Create adjustment
document, do not invoice

Create adjustment
document and invoice

Create adjustment
document and invoice

BILLDOCNO
4202
BILLDOCNO
4202
ADJUSTMENTDOC
ADJUSTMENTDOC 4203
4203
ADJUSTEDDOC
ADJUSTEDDOC

BILLDOCNO
4203
BILLDOCNO
4203
ADJUSTMENTDOC
ADJUSTMENTDOC 4204
4204
ADJUSTEDDOC
4202
ADJUSTEDDOC
4202

BILLDOCNO
4204
BILLDOCNO
4204
ADJUSTMENTDOC
ADJUSTMENTDOC 4205
4205
ADJUSTEDDOC
4203
ADJUSTEDDOC
4203

BILLDOCNO
4205
BILLDOCNO
4205
ADJUSTMENTDOC
ADJUSTMENTDOC
ADJUSTEDDOC
4204
ADJUSTEDDOC
4204

010
010
020
020

010
010
020
020
030
030
040
040

010
010
020
020
030
030
040
040

010
010
020
020
030
030
040
040

+100.00
+100.00 USD
USD
+20.00
+20.00 USD
USD

Invoicing documents

INVDOCNO
INVDOCNO

7062
7062

+100.00
+100.00
+21.00
+21.00
-100.00
-100.00
-20.00
-20.00

USD
USD
USD
USD
USD
USD XX
USD
USD XX

+100.00
+100.00
+23.00
+23.00
-100.00
-100.00
-20.00
-20.00

USD
USD
USD
USD
USD
USD XX
USD
USD XX

INVDOCNO
INVDOCNO

FI-CA

+100.00
+100.00 USD
USD
+20.00
+20.00 USD
USD

+100.00
+100.00
+23.00
+23.00
-100.00
-100.00
-20.00
-20.00

USD
USD
USD
USD
USD
USD XX
USD
USD XX

+100.00
+100.00 USD
USD
+20.00
+20.00 USD
USD
------------------------+120.00
+120.00 USD
USD

+100.00
+100.00 USD
USD
+20.00
+20.00 USD
USD
+3.00
+3.00 USD
USD
------------------------+123.00
+123.00 USD
USD

7064
7064

+100.00
+100.00
+15.00
+15.00
-100.00
-100.00
-23.00
-23.00

USD
USD
USD
USD
USD
USD XX
USD
USD XX

INVDOCNO
INVDOCNO
+100.00
+100.00
+15.00
+15.00
-100.00
-100.00
-23.00
-23.00

7065
7065

USD
USD
USD
USD
USD
USD XX
USD
USD XX

+100.00
+100.00 USD
USD
+20.00
+20.00 USD
USD
+3.00
+3.00 USD
USD
-8.00
-8.00 USD
USD
------------------------+115.00
+115.00 USD
USD

Please note that the procedures for adjusting invoiced adjustment documents
and documents that have not been invoiced are different. When adjusting billing

(C) SAP AG

291

document 4203 (not invoiced), the system only copies items for which the indicator
REVERSALITEM is selected. When adjusting billing document 4204 (invoiced), the
system only copies items and changes their plus/minus sign if the indicator
REVERSALITEM is not selected.
Please note the following with regard to displaying billing documents [Seite
294]:
The Corrected Document field (CORRBILLDOCNO) is displayed in the document
header for adjustment billing documents. This field contains the document number
of the original billing document from which the items were copied and marked with
the indicator REVERSALITEM.
In billing document 4203, the Corrected Document field contains the value
4202. This is because items 030 and 040 in document 4203 are copies of
items 010 and 020 from document 4202.
In billing document 4204, the Corrected Document field also contains the
value 4202. This is because items 030 and 040 in document 4204 are also
copies of items 010 and 020 from document 4202.
In billing document 4205, the Corrected Document field contains the value
4204. This is because items 030 and 040 in document 4205 are copies of
items 010 and 020 from document 4204.

Reversing Adjustment Billing Documents

In this example, billing document 4202 is invoiced and then adjusted using billing document 4203.
Billing document 4203 is not invoiced and is reversed using billing document 4204. Although
billing document 4204 reverses a billing document that has not been invoiced, it still contains
billing document items and can itself be invoiced.

(C) SAP AG

292

Process Flow: Generate and Invoice Reversal Document

Source document invoiced

Create adjustment document

and do not invoice

Billing documents

BILLDOCNO
4202
BILLDOCNO
4202
ADJUSTMENTDOC
ADJUSTMENTDOC 4203
4203
ADJUSTEDDOC
ADJUSTEDDOC
REVERSALDOC
REVERSALDOC
REVERSEDDOC
REVERSEDDOC

BILLDOCNO
BILLDOCNO
ADJUSTMENTDOC
ADJUSTMENTDOC
ADJUSTEDDOC
ADJUSTEDDOC
REVERSALDOC
REVERSALDOC
REVERSEDDOC
REVERSEDDOC

010
010
020
020

010
010
020
020
030
030
040
040

+100.00
+100.00 USD
USD
+20.00
+20.00 USD
USD

Invoicing documents

INVDOCNO
INVDOCNO

7062
7062

+100.00
+100.00
+21.00
+21.00
-100.00
-100.00
-20.00
-20.00

4203
4203
4202
4202
4204
4204

USD
USD
USD
USD
USD
USD XX
USD
USD XX

Create reversal document

and invoice

BILLDOCNO
BILLDOCNO
ADJUSTMENTDOC
ADJUSTMENTDOC
ADJUSTEDDOC
ADJUSTEDDOC
REVERSALDOC
REVERSALDOC
REVERSEDDOC
REVERSEDDOC
010
010
020
020

4204
4204

4203
4203

-100.00
-100.00 USD
USD
-20.00
-20.00 USD
USD

INVDOCNO
INVDOCNO

FI-CA

+100.00
+100.00 USD
USD
+20.00
+20.00 USD
USD

-100.00
-100.00 USD
USD
-20.00
-20.00 USD
USD

+100.00
+100.00 USD
USD
+20.00
+20.00 USD
USD
------------------------+120.00
+120.00 USD
USD

+100.00
+100.00 USD
USD
+20.00
+20.00 USD
USD
-120.00
-120.00 USD
USD
------------------------0.00
0.00 USD
USD

7064
7064

Testing Adjustments of Billing Documents

Use
You can use a custom report created using sample report IST_SAMPLE_CANCEL_BILLDOC as
a template to test the adjustment of billing documents in a test system.

Features
The sample report calls the BAPI BAPI_ISTBILLDOC_ADJUST and adjusts a billing document
without reference to an adjustment document from an external system. An adjustment of this
nature would constitute an error in a productive system and would render the external documents
and the documents in the SAP system inconsistent. For this reason, report
IST_SAMPLE_ADJUST_BILLDOC terminates processing immediately in this case.

Activities
11. If required, copy report IST_SAMPLE_ADJUST_BILLDOC.
12. Remove the coding lines that cause the termination.
13. Make sure that the report is only run in a test system.

Report IST_SAMPLE_ADJUST_BILLDOC uses a global unique identifier (GUID) for

the reference document number of the adjustment billing document (field
REFDOCNO in structure FKKINVBILL_H).

(C) SAP AG

293

ALE Interfaces
Definition
Interfaces for data exchange in Application Link Enabling (BC-MID-ALE) [Extern].

Use
You can use the following ALE interfaces for billing documents:
You can create billing documents using the method CREATEMULTIPLE of the object type
ISTBILLDOC. The relevant IDoc type is TELCOBILLDOC_CREATEMULTIPLE01.
You can reverse billing documents using the method CANCEL of the object type
ISTBILLDOC. The relevant IDoc type is TELCOBILLDOC_CANCEL01.
You can adjust billing documents using the method ADJUST of the object type
ISTBILLDOC. The relevant IDoc type is TELCOBILLDOC_ADJUST01.

Displaying Billing Documents

Use
You use this transaction to display billing documents in Contract Acounts Receivable and
Payable.

Features
Using the selection criteria entered, the system determines one or more billing documents. The
upper part of the screen shows the header data of the billing document. All item data is displayed
in list form below this. Items, tax items, and additional items are displayed on separate tab pages.
By means of the icons on the tab pages, you can recognize which data is available.
If the system selects several billing documents, by double-clicking on a billing document you can
navigate to the detail display.
The tab page Invoicing History shows the invoicing document in which the billing document
displayed has been included. You can also display the history of this invoicing document here.
From the billing document, you can navigate to the invoicing document and - if one exists - the
reversal document of the invoicing document.
With the exception of the date of creation, the tab page Invoicing History shows the same
information as the tab page Source Documents in the display of the invoicing document.
If the billing document displayed has not been invoiced, using the pushbutton Invoicing Order on
the tab page Invoicing History, you can navigate to the invoicing orders for analysis.

Activities
14. From the SAP menu, choose Invoicing

Document Display

Billing Document.

15. On the initial screen, enter selection criteria as required.

16. Choose Execute.

(C) SAP AG

294

Update to SAP NetWeaver BW

Use
Invoicing in Contract Accounts Receivable and Payable provides the technical infrastructure for
the extraction of the invoicing data to SAP NetWeaver BW and for monitoring the extraction.

Prerequisites
For the invoicing process whose invoicing documents are to be extracted to SAP NetWeaver BW,
you have activated the invoicing function Integration in BW Sales Statistics, and have assigned
the DataSource to be used for the extraction to this process. You make both settings in
Customizing for Contract Accounts Receivable and Payable under Integration
Invoicing in
Contract Accounts Receivable and Payable
Invoicing Processes Define Invoicing
Processes. For details about activating the invoicing functions, see Activating and Deactivating
Invoicing Functions [Seite 121]. These settings ensure that extraction orders
(DFKKINV_BWTRIG) are created during invoicing for the extraction of invoicing data to SAP
NetWeaver BW.
For extraction orders to be written, a BW system has to be connected to the invoicing system and
the DataSource has to be initialized.
When you start the SAP NetWeaver BW extraction, note that only extraction orders whose
reconciliation keys have been closed (that is, no further posting documents can be created for
these keys) are processed. Therefore, close the reconciliation keys used for posting the
extraction orders to be transferred.

Features
The following functions are available:
...

1. Creation of Extraction Orders

When creating the invoicing documents, Invoicing in Contract Accounts Receivable and
Payable creates extraction orders for updating the invoicing document data in SAP
NetWeaver BW.
The extraction orders are created per reconciliation key; this means that the invoicing and
billing data is updated in SAP NetWeaver BW together for each reconciliation key.
2. Processing of Extraction Orders
The data is extracted to SAP NetWeaver BW by means of a parallel mass run after
invoicing. This run is based on the functions of the mass activities in Contract Accounts
Receivable and Payable (see the SAP Easy Access screen under Invoicing
Extraction
for Business Intelligence
BI Extraction of Invoicing Documents). The program selects
the extraction orders and writes the extraction-relevant data of the related invoicing
documents to the delta queue of SAP NetWeaver BW. A delta extraction to SAP
NetWeaver BW is therefore supported based on the extraction orders.
The preparation of the invoicing document data in the extraction DataSource is
not part of the standard functions; it has to take place in either customer-specific or
industry-specific form in the function module for event 2710. At the interface, this
module receives an invoicing document and has to return the prepared SAP
NetWeaver BW-relevant data of this document in an extraction structure.

(C) SAP AG

295

3. Monitoring
You can use monitoring transactions to analyze the extraction orders and to clarify the
cause of the invoicing documents not extracted. These transactions enable you to simulate
the extraction and to analyze the extraction results (see the SAP Easy Access screen:
Invoicing
Extraction for Business Intelligence
Analysis of BI Extraction
Orders/Analysis of BI Extraction Invoicing Documents).
The figure below shows the process flow of the transfer of invoicing and billing data to SAP
NetWeaver BW.

Runtime

Master Data

BW Extraction
Order

BW Extraction

BW Output

Billing
Document

FakturierungsInvoicing
beleg
Document

Design Time
DataSource

DataSource 0FC_INVDOC_00
Definition
Object that provides the data from Invoicing in Contract Accounts Receivable and Payable for
SAP NetWeaver BW.

Use
Extraction orders form the basis for the extraction of invoicing document data. The DataSource is
a key part of an extraction order.
If a DataSource is assigned to an invoicing process, one extraction order (DFKKINV_BWTRIG)
for extracting the invoicing document data to BW (using the delta procedure) is created in
invoicing for each reconciliation key.
You can use DataSource 0FC_INVDOC_00, which is provided by SAP. It uses the extraction
structure FKKINV_BW_EXTRACT00. SAP provides BI Content for this DataSource.

(C) SAP AG

296

In addition to DataSource 0FC_INVDOC_00, SAP provides DataSources 0FC_INVDOC_01 to

0FC_INVDOC_20.
These DataSources correspond to DataSource 0FC_INVDOC_00. You can use them to assign a
separate DataSource to each invoicing process.
Your extraction structure must only contain fields of the SAP structure
FKKINV_BW_EXTRACT00. If necessary, you may have to add your own additional
fields to the SAP structure in the relevant includes.
SAP does not provide any BI Content for these additional DataSources. To be
able to use these DataSources, you have to define the necessary data targets and
transfer rules in BW.
To reduce the data volume of the delta queue and to improve the performance in the extraction
run, you can use your own customer-specific or industry-specific DataSources instead of these
DataSources. You can tailor your DataSources to your own application, only adding those fields
in the extract structure that you really need in BW.
Your extraction structure must only contain fields of the SAP structure
FKKINV_BW_EXTRACT00. If necessary, you may have to add your own additional
fields to the SAP structure in the relevant includes.

BW Extraction Orders
Definition
Used to select invoicing documents during extraction using the delta procedure for SAP
NetWeaver BW.

Structure
There is a differentiation between the group extraction order (database table DFKKINV_BWTRIG)
and the individual extraction order (database table DFKKINV_BWTRIGS). A group extraction
order is created per reconciliation key, an individual extraction order per invoicing document.
Invoicing in Contract Accounts Receivable and Payable creates group extraction orders. After the
extraction to SAP NetWeaver BW, the extraction program deletes the order automatically.
For invoicing documents that could not be extracted in such an extraction due to an error, the
extraction program creates an individual extraction order that is considered again in a later
extraction. An individual extraction order remains in the system until the related invoicing
document has been successfully extracted to SAP NetWeaver BW.
An invoicing document for one DataSource cannot simultaneously be in an
individual extraction order DFKKINV_BWTRIGS and a group extraction order
DFKKINV_BWTRIG.
When invoicing documents are extracted, the extraction program writes one or more extraction
history records for each extraction order (database table DFKKINV_BWTRIGH). These history
records serve as a record of the extraction. They contain certain statistical information on the
extraction. You can analyze this information in the Data Browser. Provided the data is no longer
needed, you can delete these records using the report
RFKKINV_DFKKINV_BWTRIGH_DELETE.

(C) SAP AG

297

Event 2710
Use
Provides the DataSource with invoicing/source document data

Features
The preparation of the invoicing document data in the extraction DataSource takes place in the
industry-specific/customer-specific module for event 2710. At the interface, this receives an
invoicing document and must return the prepared BI-relevant data of this document in an extract
structure.
To add to the data, in this module you can select any information from the environment of the
invoicing document (for example, the master data attributes, billing document data).
If an invoicing document is initially not to be transferred to BI (for example, due to an error), you
can issue an error message (message type E) for this document in the module. In this case, the
invoicing document is not considered in the current extraction, but it is preselected for a later
extraction run.

Activities
Implement a customer-specific/industry-specific function module for event 2710 and define it in
the Implementation Guide for Contract Accounts Receivable and Payable under Program
Enhancements
Define Customer-Specific Function Modules.

Extracting Documents
Purpose
Evaluation of invoicing document data in SAP NetWeaver BW

Process Flow
The extraction takes place in the two following steps:
...

1. Initialization of the DataSource

Before the first extraction of the invoicing document data, you have to initialize the
DataSource. You do this in the BW system. If you use the DataSource 0FC_INVDOC_00
delivered by SAP (or your own DataSource with the extractor program
FKK_INV_BW_EXTRACT_INVDOC_INIT), no data is loaded for this DataSource during
the initialization. Instead, the group extraction orders and individual extraction orders that
already exist in the initialization interval are deleted and new group extraction orders are
created for all reconciliation keys in the initialization interval.
The regular extraction run can then extract the data in the initialized interval.
2. Processing of extraction orders (delta extraction)
You start the extraction order from the SAP Easy Access screen by choosing Invoicing
Extraction for Business Intelligence
BI Extraction Invoicing Documents.

(C) SAP AG

298

The figure below illustrates the processing logic of the extraction.

DFKKINV_BWTRIGS

BI Extr.Order
Inv.Document

Invoicing

BI Extraction
FakturierungsFakturierungsInvoicing
beleg
beleg
Document

Zeitpunkt
Zeitpunkt
Eventt
2710
2710
2710

Billing
Document

AbrechnungsBilling
beleg
Document

Selection
Individual
Extr. Order

Invoicing
Document

Master Data

DFKKINV_BWTRIG

AbrechnungsBilling
beleg
Document

Invoicing
Document

BI Extr.Order
Reconciliation
Key

Selection
Group Extr.
Order

FKKINV_BW _EXTRACT00

Billing
Document

Invoicing
Document

Extract Structure
<Defined for Project>

Design Timet
DataSource
<Defined for
Project>

Delta
Queue

The extraction is based on the group extraction orders DFKKINV_BWTRIG (see 1 in the
figure) that are created in invoicing or during the initialization of the DataSource.
The extraction program selects the invoicing documents for the extraction orders and runs
event 2710 with each invoicing document. This event provides the data to be transferred to
SAP NetWeaver BW in the extract structure FKKINV_BW_EXTRACT00. This data is then
transferred to the customer-defined DataSource and updated in the SAP NetWeaver BW
delta queue.
As soon as event 2710 has been processed for all invoicing documents of the group
extraction order, the extraction program deletes this group extraction order automatically.
Whether or not all documents were successfully extracted or whether an error was
reported for all or some of them in event 2710 is irrelevant. In the case of errors, an
individual extraction order is created for follow-on processing for the documents affected
(see 2 in the figure).
If a group extraction order was not completely processed in an extraction run - for example,
because of a program termination the order contains information about the degree of
processing. This means that if you restart the extraction, the invoicing documents already
processed by means of this group extraction order are not selected again.
If an error occurs during the preparation of the data in event 2710, the invoicing document
affected is not transferred to SAP NetWeaver BW. Instead, for the invoicing documents
affected, the system creates an individual extraction order DFKKINV_BWTRIGS for a
subsequent extraction run.
The individual extraction orders are processed in a later extraction run (see 3 in the figure).
The procedure corresponds to that described for 1 and 2. An individual extraction order
remains in the system until the related invoicing document has been successfully
transferred to SAP NetWeaver BW.
When invoicing documents are extracted, the extraction program writes one or more
extraction history records for each extraction order (database table DFKKINV_BWTRIGH).

(C) SAP AG

299

These history records serve as a record of the extraction. They contain certain statistical
information on the extraction. You can analyze this information in the Data Browser.
Provided the data is no longer needed, you can delete these records using the report
RFKKINV_DFKKINV_BWTRIGH_DELETE.
When you start an extraction run, you can decide whether the run should
process only individual extraction orders, or only group extraction orders, or both
simultaneously.

Extraction of Invoiced Billable Items

When extracting invoicing documents, you can also extract the billable items processed in the
invoicing document. When you do so, the system distributes the information of the individual
invoicing items to the billable items that belong to them.

Prerequisites
For you to be able to extract invoiced billable items to SAP NetWeaver BW, the following
prerequisites have to be met:
You are using Billing in Contract Accounts Receivable and Payable (origin process
0007).
You are using the standard implementation of event 2710 (FKK_SAMPLE_2710).
If you are using your own implementation, then you modified it as necessary.
For the billable item class, you specified in Customizing that this class is extracted to
SAP NetWeaver BW. (See Customizing for Contract Accounts Receivable and Payable
under Integration Billing in Contract Accounts Receivable and Payable Billable
Item Management Define Processing Rules and Program Enhancements .)
You added the fields of the billable item needed for the extraction to the extraction
structure FKKINV_BW_EXTRACT00 and activated them in the DataSource.

Features
The extraction uses the DataSources for the extraction of invoicing documents. It is implemented
in the standard delivery of event 2710 in function module FKK_SAMPLE_2710.

Extraction Method for SAP NetWeaver BW (BW)

In addition to the delta method, under the circumstances described below, you can also use a full
upload method to extract invoicing documents.

(C) SAP AG

300

Features
Using a full upload, you can, for example, extract invoicing documents of an invoicing process for
a certain posting date, without having to first delete the delta initialization. The prerequisite for this
solution, however, is that you use separate DataSources for the delta upload and full upload
methods for extracting invoicing documents to SAP NetWeaver BW. Using separate DataSources
serves two purposes. On the one hand, it ensures that each of the methods have their own
separate extraction orders on the extraction side. On the other hand, it should make it easier to
establish the source of the data received in SAP NetWeaver BW. The following extraction logic is
supported:
Delta Method
To extract invoicing documents using the delta method, you have to initialize the delta.
The delta method is only supported for DataSources that are assigned to an invoicing
process in Customizing (in Customizing for Contract Accounts Receivable and Payable
under Integration Invoicing in Contract Accounts Receivable and Payable Invoicing
Invoicing Processes Define Invoicing Processes ). The extraction considers only
those invoicing documents that were created in these invoicing processes. Full upload
mode is not supported for DataSources that are assigned to an invoicing process.
Full Upload Method
For the full-upload extraction of invoicing documents, you can use one of the
DataSources listed in DataSource 0FC_INVDOC_00 that is not assigned to an invoicing
process. The extraction takes place only for the initialized selection intervals. It is useful
to start an initialization request without data transfer for the intervals to be extracted.
Along with the mandatory selection by posting date, other selection options are available,
such as selection by invoicing process. You can activate selection by invoicing process
for the DataSource you use in SAP NetWeaver BW.
Note
We recommend that you use only the delta method. This is the only method that ensures the
consistency of the extracted data in SAP NetWeaver BW. Use of the full upload method
increases the risk that the same document data is analyzed multiple times during BW analysis
due to data being extracted more than once to SAP NetWeaver BW.
End of the note.

Master Data in SAP Convergent Invoicing

In an integrated scenario with SAP Customer Relationship Management (SAP CRM) and SAP
Convergent Charging (SAP CC), you use the following master data objects in SAP Convergent
Invoicing: business partner, contract account, prepaid account, provider contract, and product. In
the individual components, these master data objects are used as follows:
SAP Customer Relationship Management
In the CRM system, you configure and manage your products, and you enter and
manage customer data and contract data. You transfer the parts of this data that are
needed in SAP Convergent Invoicing to the ERP system.

(C) SAP AG

301

SAP Convergent Charging (SAP CC)

SAP Convergent Charging creates billable items for services that are used and transfers
these items for further processing to Billing in Contract Accounts Receivable and Payable
in the ERP system. The basis for the creation of billable items are sets of rules stored in
SAP CC that specify pricing and account assignment, in combination with customer data
and product data that SAP CC replicates from the CRM system. The billable items
contain the price to be paid for the usage of a service, along with information on the
account to which receivables or payables are to be posted.
SAP Convergent Invoicing
SAP Convergent Invoicing receives billable items from SAP Convergent Charging,
creates invoices and credit memos from them, posts the receivables or payables in
Contract Accounts Receivable and Payable, and manages these receivables and
payables until they are cleared.
Billable items contain information on the business partner and the account contract
account in postpaid scenarios or prepaid account in prepaid scenarios to which
Contract Accounts Receivable and Payable posts the receivables or payables, and with
which you can track the prepaid usages of your customers.

C ontrac t A c c ounts
R ec eivable and P ayable
(F I-C A)

S ubs criber Acc ount

B us ines s Agreement

C ontract Ac count

E xternal A ccount

P repaid Account

P repaid Ac count

P repaid D ata

F ramework for E rror

H andling

P roduc t

Web S ervic es

B us ines s P artner

Midd leware

B us ines s P artner

P roduc t

P rovider C ontract

ODI*

P rovider C ontract

C ommon O bject L ayer

P rovider C ontrac t

*O rder D is tribution Infras tructure

Master Data in SAP Convergent Invoicing

Process
The following describes the process flows in SAP Convergent Invoicing and in particular in Billing
in Contract Accounts Receivable and Payable. References are made to SAP CRM and SAP CC
only where this is required for a better understanding of the process flows.

(C) SAP AG

302

In the case of integrated use of SAP Convergent Invoicing, SAP CC and SAP CRM, the SAP
CRM system is the leading system with regard to master data. That means that you create and
change business partners, account information, provider contracts and products in SAP CRM and
then replicate these to SAP Convergent Invoicing in the ERP system and to SAP CC. With regard
to the provider contract and product, SAP Convergent Invoicing stores only the information
directly needed for business transactions that take place in SAP Convergent Invoicing.
In the ERP system, you normally just display the provider contracts and products. However, for
exceptional cases, there are transactions available for changing products and contracts. These
changes are local only, and are not distributed to the connected systems. When there is a new
replication of master data from SAP CRM, the system overwrites any manual changes.

Product
SAP Convergent Invoicing relates to products of SAP Customer Relationship Management (SAP
CRM).

Prerequisites
To make it possible in the ERP system to access the product data from the CRM system, you
have prepared both systems by making the system settings described below.
You have made the following Customizing settings in the ERP system:
You have specified the output format and the form of saving the product ID in
Customizing for Cross-Application Components
under SAP Product
Product IDs .

Basic Settings

Define Output Format and Storage Format of

You defined the specifications for sales organizations in Customizing under Enterprise
Structure Definition Sales and Distribution Define, copy, delete, check sales
organization .
You defined the specifications for the distribution channel in Customizing under
Enterprise Structure Definition Sales and Distribution Define, copy, delete, check
distribution channel .
You assigned a distribution channel to the sales organizations in Customizing under
Enterprise Structure Assignment Sales and Distribution Assign Distribution
Channel to Sales Organization .
You defined account assignment groups in Customizing for Sales and Distribution under
Basic Functions Account Assignment/Costing Revenue Account Determination
Check Master Data Relevant For Account Assignment Materials: Account
Assignment Groups
.
You have made the following Customizing settings in the CRM system:

(C) SAP AG

303

You have specified the output format and the form of saving the product ID in
Customizing for Cross-Application Components under SAP Product Basic Settings
Define Output Format and Storage Format of Product IDs .
You have defined the number ranges for products in Customizing for Cross-Application
Components under SAP Product Settings for Product Type Number Assignment
.
The number ranges for the product types Material and Service are not allowed to overlap.
Do not create any products with the same name for different product types.
You have assigned the sales organization from the CRM system and the ERP system to
one another in Customizing for Customer Relationship Management under Master
Data Organizational Management Assignment of Organizational Units from SAP ECC
Assign SAP CRM Sales Organizations to SAP ECC Sales Organizations .
You have defined distribution channels in Customizing for Customer Relationship
Management under Master Data Organizational Management Organizational Data
for Sales Scenario Define Distribution Channels
To make it possible to distribute product data, you have added the subscriptions Product
Services (MESG) and Product Materials (MESG) in the middleware in the administration
console (transaction SMOEAC) for the site of the ERP system.
You have categorized the products as rate plan or combined rate plan in Customizing for
Customer Relationship Management under Master Data Products Settings for
Packages Assign Product Roles to Categories .
Caution
The Customizing for the sales organization, the distribution channel and the product ID has to be
the same in the ERP system and in the CRM system.
End of the caution.

Structure
The product information in the ERP system consists of the following elements:
Language-dependent texts
Data dependent on the sales area
The product header contains an entry identifying the source system (logical system ID of the
sending system) and the product type. The system evaluates this information during the
replication of products. This is to prevent products with the same name from different systems or
with a different product type from being replicated in the ERP system.

Integration
If you have made the appropriate system settings, then product data is automatically replicated
from the CRM system to the ERP system.
During the replication of product data from SAP CRM to SAP ERP, only those products (materials
and service products) are considered that are designated as Rate Plan or Combined Rate Plan.

(C) SAP AG

304

The ERP system allows 100 characters for the long text of a product. If a longer text was entered
for a product in SAP CRM, the ERP system copies the first 100 characters to the long text; the
remaining characters are cut off.
During the replication, Contract Accounts Receivable and Payable records the sending system
and the product type as part of the product. The information is used to ensure that when products
are received in Contract Accounts Receivable and Payable, an existing product is not overwritten
by a product with the same name or a different product type. If you create a new product in
Contract Accounts Receivable and Payable, or reset the technical settings (logical system and
product type) to the initial values, the system overwrites the changed data with the currently valid
data at the next replication from the CRM system.

Features
Since only replicated product data exists in the ERP system, you should only display products
there. If system inconsistencies arise (which is not to be expected), you can manually create or
change products in the ERP system, if you need the current data immediately.
Caution
The ERP system only stores manual changes locally, and does not distribute them to connected
systems. When there is a new replication of product data from SAP CRM, the system overwrites
manual changes that you made in the ERP system.
End of the caution.
You can use CI includes to enhance the sales area data of products replicated in the ERP
system.

Activities
You can display, create, and change products in Contract Accounts Receivable and Payable from
the SAP Easy Access screen under Master Data For Integration with Rating and Charging
Product .
To enhance the sales area data:
1. Add the required fields to the CI include CI_FKK_VT_PRDS.
2. To supply the added fields with values during the replication of products from SAP CRM,
transfer the values from SAP CRM in fields with the same names. To do so, add an
append to the structure CRMT_ISX_ERP_PRODUCT_SALESG in the CRM system; and
in the ERP system add an append to the structure FKK_VT_CRM_PRODUCT_SALESG.
3. Fill the fields in the CRM system in an implementation of the BAdI
CRM_FICA_PRODUCT_MAT_MAP for materials and the BAdI
CRM_FICA_PRODUCT_SRV_MAP for service products.

Provider Contract
A provider contract comprises all legally binding agreements regarding the provision and billing of
services that are entered into by a customer and a company for a specified period of time.

(C) SAP AG

305

Caution
The industry component Media does not use the provider contract.
End of the caution.

SAP Convergent Invoicing relates to provider contracts of SAP Customer Relationship

Management (SAP CRM).

Structure
A provider contract relates to exactly one business partner. It consists of a contract header and
contract items.
The header of the provider contract stores the following data:
Number of the business partner who entered into the provider contract
Contract start date
Contract end date
Authorization group and company code for authorization checks
The header of each provider contract references the contract items, which contain the following
data:
Contract account or prepaid account or both
ID of the product, to which the provider contract relates
Standard account assignment that the system uses for billable items, such as company
code, business area, standard division, profit center, and segment
Each contract item contains a reference to a contract account and/or to a prepaid account. The
contract items can be shown below each other in a hierarchy with a main item as the root node
of the hierarchy. There must be a main item at every point in time from the contract start to the
end of the contract.
Contract items are valid for a limited time. All contract items with the same external GUID
represent the same contract item from a logical perspective, however at different points in time.
Note
SAP Convergent Charging and SAP ERP relate to the same provider contract object, but they
each see it from a different perspective. The process flows in the components each relate to
different parameters of the provider contract. Since both SAP Convergent Charging and SAP
ERP store different data for the same provider contract object, this results in different
requirements as to the point in time at which a provider contract item needs to be distinguished
from its predecessor item in the case of changes. When a change is made, the system generates
separate data records (from a technical perspective) with the changed data. However, seen
logically, these data records represent the same provider contract item. In order to be able to
distinguish in a distributed landscape at what point in time which provider contract item is

(C) SAP AG

306

relevant, the system groups the information under an external GUID using the logical view of the
provider contract item.
When you change the data of a provider contract item, the system creates a new provider
contract item with the changed information. This new item follows chronologically immediately
after the existing provider contract item. Since both provider contract items represent the same
item from a logical perspective, the external GUID of the provider contract item contains the same
value for both items, and therefore forms a kind of set of brackets around the items belonging to it
in a chronological sequence.
End of the note.

Integration
If you have made the appropriate system settings, the master data of provider contracts is
automatically replicated from the CRM system to the ERP system.
For the integration and data distribution of the provider contract in SAP ERP and SAP CC, you
can use the Common Object Layer Framework (COL Framework). You can protect access to the
COL Framework using authorization object X_COL_OBJ.
For the provider contract, you can also use the Business Object Layer (BOL) model (BOL
component ISXCTR), which is integrated with the COL Framework. Using it, you can generate
special Web services for the provider contract on the basis of the BOL Web Service Framework.
When you distribute provider contracts to SAP CC, SAP CC automatically determines, when
generating the billable item, to which contract account, to which business partner and to which
provider account (more precisely, to which contract item) these relate. SAP CC transfers this
information to the ERP system in the billable item.

System Settings for Accessing Provider Contracts

Activities
To make it possible for the ERP system to access the contract data from the CRM system, you
have prepared both systems by making the system settings described below.

Settings in the ERP System

Activate the use of the provider contract in Customizing for Contract Accounts Receivable
and Payable under Basic Functions Provider Contract Activate Provider Contract
.
Note
If you are already using another contract object and are therefore activating the provider
contract as a second contract, the system uses the subapplication P for the provider
contract. In that case, activate the subapplication P under Basic Functions Activate
Subapplication .
End of the note.
Define the number ranges in Customizing for Contract Accounts Receivable and Payable
under Basic Functions Provider Contract Define Number Range .

(C) SAP AG

307

Note
To ensure successful replication of provider contracts, make sure that Customizing is
synchronized for the number ranges used in the ERP and CRM systems.
End of the note.
Define your sales organizations in Customizing under Enterprise Structure
Sales and Distribution Define, copy, delete, check sales organization .

Definition

Define your distribution channels in Customizing under Enterprise Structure

Definition Sales and Distribution Define, copy, delete, check distribution channel
Define your divisions in Customizing under Enterprise Structure
- General Define, copy, delete, check division .

Definition

Logistics

Assign the distribution channels to sales organizations in Customizing under

Enterprise Structure Assignment Sales and Distribution Assign distribution
channel to sales organization .
Assign the sales organizations to company codes in Customizing under Enterprise
Structure Assignment Sales and Distribution Assign sales organization to company
code .
Define the account assignment derivation in Customizing for Contract Accounts
Receivable and Payable under Basic Functions Provider Contract Define
Specifications for Derivation of Standard Account Assignment .
Make settings for the Common Object Layer Framework in Customizing for Contract
Accounts Receivable and Payable under Integration Convergent Charging in the
activity Set Up Replication of Provider Contracts.
In addition, you can make the following optional settings in the Business Data Toolset (BDT) in
the area menu CAVT under Customizing or in Customizing for Contract Accounts Receivable and
Payable using the following paths:
Basic Functions

Provider Contract

Enter Field Attributes per Activity

Basic Functions

Provider Contract

Specify Authorization Types

Basic Functions

Provider Contract

Define Field Groups for Authorization Check

Settings in the CRM System

In Customizing for Customer Relationship Management, configure the settings for
determining the schema for the provider contract. To do so, choose Industry-Specific
Solutions Telecommunications Settings for Telecommunications Transactions
Define Settings for Document Distribution .
Make settings for organizational management in Customizing for Customer Relationship
Management such that they are in accord with the settings for the enterprise structure in
the ERP system.

(C) SAP AG

308

Displaying and Changing Provider Contracts

To view the contract data, you can display provider contracts in the ERP system. If system
inconsistencies arise (which is not to be expected), you can manually adjust provider contracts in
the ERP system, if you need the current data immediately.
Note
Since only replicated data exists in the ERP system, you should only display provider contracts
there.
End of the note.

Features
Changes to contract items are only possible for contract items without follow-on items, that is, the
contract items that are valid the farthest into the future.
Caution
Note the following regarding changes:
Changes are only possible for the future.
The system only stores changes locally. The system does not distribute changes to
connected systems.
When there is a new replication of contract data from SAP CRM, the system overwrites
manual changes that you made in the ERP system.
When you set the deletion flag, the system ends the provider contract at the specified
time. That means that you thereby change the contract end date. The system reverses
any contract items that have a validity start date after the new contract end date.
A change of the contract start date or contract end date affects the validity of the contract
items.
If you change the contract end date, from the new contract end date, the system ends all
contract items that are valid after the new contract end date. If the validity start date of a
contract item lies after the contract end date due to a change of the contract end date,
the system reverses the item.
End of the caution.

Activities
Display
To display provider contracts, on the SAP Easy Access screen, choose
Integration with Rating and Charging Provider Contract Display .

Master Data

For

Change

(C) SAP AG

309

1. To change provider contracts, on the SAP Easy Access screen, choose Master Data
For Integration with Rating and Charging Provider Contract Change .
Note
The transaction is implemented using the Business Data Toolset (BDT). That means that
you can also call the area menu for the provider contract in transaction CAVT.
The system displays the contract items in the ABAP List Viewer (ALV).
End of the note.
2. Select the provider contract you want.
Either enter the provider contract directly or enter the business partner. If you enter only
the business partner, the system automatically selects the provider contract, as long as
the business partner has only one provider contract. If the business partner has more
than one provider contract, select the one you want.
3. Choose Continue.
The system displays information about the contract on the General Data tab. The system
displays the contract items on the Contract Item: Overview tab.
Note
The Customizing of the field groups does not affect the display in the ABAP List Viewer.
To change the display, use the layout functions of the ABAP List Viewer.
End of the note.
4. Click on the item you want to change on the Contract Item: Overview tab. Then you can
access the following processing options using pushbuttons:
Activity

Pushbutton

Create
(Create
follow-on
Follow-On
item for
Item)
contract item

Effects and Notes

The system ends the selected item one second before the change
time, and creates a follow-on item with the change time as the start
of its validity. The field values are adopted from the predecessor
item; however, you can change them.
The item is only valid until the time of the change. If the contract
item has subitems, these are also valid only until the time of the
change.

End contract
item

(End Item) The system ends the contract item at the date and time that you
entered on the initial screen.
You cannot end main items that are the root of a hierarchy.

Reverse
(Reverse
contract item Item)

(C) SAP AG

You can only reverse contract items that were not yet valid up to the
current date. That means the start of validity has to lie in the future
in relation to the current date. If there is a predecessor item for the
reversed item, the system extends its validity, so that the item also
covers the time period of the reversed item. If there is no
predecessor item, then you are only allowed to reverse the contract

310

item if it does not have any subitems. You can reverse a main item
only if a predecessor item exists for it. This is because at all times
between the contract start date and end date, there must be a main
item that is the root of the hierarchy.

Extend
(Extend
contract item Item)

You can re-extend the validity of contract items that you ended
manually. The system resets the end of their validity to the original
end of validity, which the system stored when the item was ended
manually.
Items that you ended manually are not displayed in the Active Items
view. You can extend them in the All Items view.

5. Save your changes.

Authorization Objects for Provider Contracts

Features
Provider contracts in the ERP system are protected by the following authorization objects:
Authorization
Object

Function

With this authorization object, you specify at the level of the company code, which
contracts of Contract Accounts Receivable and Payable a user can process. A
F_KKVT_BUK
user can process a contract, if he or she receives the authorization for the
company code entered in the contract header.
F_KKVT_BEG

With this authorization object, you specify which contracts a user can process and
display.

This authorization object specifies authorizations for the input fields of the contract
dialog. Dependent on the field values, you specify in Customizing for Contract
F_KKVT_AUT
Accounts Receivable and Payable which contracts a user is allowed to process
under Basic Functions Provider Contract Specify Authorization Types .
With this authorization object, you can define authorizations for individual field
groups in the contract. You thereby specify which fields of the contract users are
F_KKVT_FDG allowed to change and display. You make these settings in Customizing for
Contract Accounts Receivable and Payable under Basic Functions Provider
Contract Define Field Groups for Authorization Check .

Referencing of Provider Contracts

Each billable item contains a reference to a contract item. If a billable item changes from status
Raw to the status Billable:

(C) SAP AG

311

The system transfers the reference of the contract item to the internal number of the
contract item and the number of the provider contract.
The billable item receives the standard account assignment of the contract item.
The system enriches the main and subtransaction, taking into account the available
product information.

Replication of Business Partners and Accounts

Prerequisites
You have activated master data distribution from Contract Accounts Receivable and Payable to
SAP Convergent Charging in Customizing for Contract Accounts Receivable and Payable under
Integration Convergent Charging Activate Replication of Business Partners and Accounts
to SAP CC .
You have entered a connection to the SAP Convergent Charging System for the service
consumer SUACProvisioningServices (for example in transaction SOAMANAGER).

Features
Through the integration of SAP Convergent Invoicing, Contract Accounts Receivable and
Payable, SAP Convergent Charging, and SAP Customer Relationship Management, SAP
ensures the distribution and synchronization of master data across all involved systems.

D ialog

C ontrac t Ac c ounts R ec eivable

and P ayable (F I-C A)

P repaid D ata

C ontract Account

S ubs criber Account

Web S ervices

B us ines s A greement

B us ines s P artner
Middleware

B us ines s P artner

Other S ys tems

B AP I/R F C

P repaid Ac count

E xternal A ccount

P repaid Ac count

F ramework for E rror

Handling

Distribution of Business Partners and Accounts Between Systems

(C) SAP AG

312

SAP Convergent Charging makes Web services available as interfaces. Contract Accounts
Receivable and Payable and SAP Convergent Invoicing use these interfaces to transfer master
data to SAP Convergent Charging. The data is transferred using the service consumer
SUACProvisioningServices.
You can enhance the mapping for the calls of the interfaces. You make these settings in
Customizing for Contract Accounts Receivable and Payable under Integration Convergent
Charging Manage Interfaces to SAP CC Enhance Mapping of Individual Interfaces .
If you activate master data distribution, Contract Accounts Receivable and Payable automatically
distributes all new and changed master data to SAP Convergent Charging - regardless of
whether the master data:
Was created or changed in Contract Accounts Receivable and Payable
Was received in Contract Accounts Receivable and Payable by means of a BAPI or RFC
transfer from another SAP system (such as SAP CRM) or from an external system
SAP Convergent Charging handles the master data of Contract Accounts Receivable and
Payable as follows when you create or change master data:
Contract Accounts Receivable and Payable distributes business partners to SAP
Convergent Charging as subscriber accounts.
Contract Accounts Receivable and Payable distributes contract accounts to SAP
Convergent Charging as external accounts.
Contract Accounts Receivable and Payable distributes prepaid accounts to SAP
Convergent Charging as prepaid accounts.
If you are using SAP Customer Relationship Management, enter the master data there and then
distribute it to the ERP system. Following that, the ERP system ensures that the master data is
successfully forwarded to SAP Convergent Charging.

Monitoring and Error Handling

On the SAP Easy Access screen under Master Data For Integration with Rating and
Charging Replication , the following programs are available for tracking data replication and
error handling:
Menu Entry

Function

Monitor
Replication

Using this program, you can monitor the master data distribution from
Contract Accounts Receivable and Payable to SAP Convergent Charging. In
the case of errors, you can view the error messages and trigger the
distribution to SAP Convergent Charging again.

Manual
Replication

Using this program, you can, if necessary, distribute master data (again) to
SAP Convergent Charging.

Contract Accounts Receivable and Payable updates the status of the

distribution to SAP Convergent Charging using distribution records. If the
Delete Distribution
distribution was successful, you no longer need to keep these records in the
Records
system. You can delete the distribution records that are no longer needed
using this program.

(C) SAP AG

313

Compare Master The program compares the master data in order to determine if there are
Data in FI-CA and discrepancies between Contract Accounts Receivable and Payable and SAP
SAP CC
Convergent Charging.
Resend Failed
Replication

You can use this program to automatically process distribution records with
errors and trigger the distribution to SAP Convergent Charging again.

For more information, see the documentation of the individual programs.

Customer Enhancements
You can create your own installation-specific enhancements in the following events:
Event

In this event, you can:

5701

Exclude business partners from the distribution

5702

Exclude contract accounts from the distribution

5703

Add additional data for the business partner

5704

Add additional data for the contract account

5705

Add additional data for the prepaid account

(C) SAP AG

314