sap ci ehp 6

SAP Convergent Invoicing

PUBLIC

Document Version: 26.04.2012

(C) SAP AG 2

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 3

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 4

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 5

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 6

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 7

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 für 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 für 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 8

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 9

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 10

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 11

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 12

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 13

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 14

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 15


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 ERP


Consumption Mediation RatingCharging 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 16

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 17

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 18

Contract Account

Billing Document

Billable Items

Billing

Billed Items

Billable Items Transfer

ItemsItems

Runtime

1 2

Archiving

3

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 19

Design Time

Contract Account

Billing Process

Billing Document

Runtime

Billing Process

Invoicing Category Billing Type

unitBilling Unit

Selection Variant

Billable Item

Subprocess Grouping Variant

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 20

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 21

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 22

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 23

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 24

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 25

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 26

Main Items

SubitemsLinked via BITPACKCNO_IT

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 27

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 28

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 29

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 30

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 31

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 32

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 33


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 34

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 35

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)



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 36

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 37

Billable

Raw

Billable Excepted

Raw Excepted

BilledBilled

…

Billed

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 38

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

Payment DataItems

Tax Items

Linked via PY_GROUP

Linked via TAX_GROUP

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 39

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 40

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 41

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 42

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 43

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 44

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 45

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 für Verbrauchspositionen

Um Verbrauchspositionen manuell erfassen zu können, müssen Sie im Customizing aus aktivierten Klassen von Verbrauchspositionen Pflegedialoge generieren.

Voraussetzungen Sie haben im Customizing Klassen für Verbrauchspositionen konfiguriert und die Konfiguration aktiviert.

Aktivitäten Pflegedialoge für Verbrauchspositionen generieren Sie im Customizing des Vertragskontokorrents unter Integration Abrechnung im Vertragskontokorrent Klassen für Verbrauchspositionen Pflegedialoge für Klassen von Verbrauchspositionen generieren .

Um einen Pflegedialog zu generieren, markieren Sie die gewünschte Klasse in der Liste und

wählen Sie Generieren (Generierung

(C) SAP AG 46

durchführen) . Die Generierung erfolgt aufgrund der generierten Version der Schnittstelle und der Datenablage der Klasse.

Hinweis

Bei der Generierung löscht das System bereits vorhandene generierte Objekte der Pflegedialoge.

Ende des Hinweises.

Ferner stehen Ihnen in der Drucktastenleiste die folgenden Funktionen zur Verfügung:

Mit der Drucktaste

(Generierung prüfen) prüfen Sie die generierten Pflegedialoge der ausgewählten Klasse. Beim Aufruf der Transaktion vergleicht das System die Felder der generierten Datenablage mit den generierten Pflegedialogen. Das System prüft, ob Schnittstellenkomponenten und Kundenfelder ergänzt oder geändert wurden.

(C) SAP AG 47

Mit der Drucktaste Löschen (Generierte Objekte löschen) können Sie vorhandene Objekte löschen.

Mit der Drucktaste

Objekte (Generierte Objekte anzeigen) können Sie die generierten Objekte anzeigen. In der Objektliste können 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 48

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 Selecting additional interface components not yet active

(C) SAP AG 49

o Selecting additional customer fields not yet active

o Adding table sets

o 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 50

Customizing System

TestSystem

Production System

Transport Transport

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 51

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 52

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 53

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 54

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 __ Not released for use

o Released for Productive Use

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

o 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 für abrechenbare Positionen

Um abrechenbare Positionen manuell erfassen zu können, müssen Sie im Customizing aus aktivierten Klassen abrechenbarer Positionen Pflegedialoge generieren.

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

Aktivitäten Pflegedialoge für abrechenbare Positionen generieren Sie im Customizing des Vertragskontokorrents unter Integration Abrechnung im Vertragskontokorrent Klassen abrechenbarer Positionen Pflegedialoge für Klassen abrechenbarer Positionen generieren .

(C) SAP AG 55

Um einen Pflegedialog zu generieren, markieren Sie die gewünschte Klasse in der Liste und

wählen Sie Generieren (Generierung durchführen) . Die Generierung erfolgt aufgrund der generierten Version der Schnittstelle und der Datenablage der Klasse.

Hinweis

Bei der Generierung löscht das System bereits vorhandene generierte Objekte der Pflegedialoge.

Ende des Hinweises.

Ferner stehen Ihnen in der Drucktastenleiste die folgenden Funktionen zur Verfügung:

Mit der Drucktaste

(Generierung prüfen) prüfen Sie die generierten Pflegedialoge der ausgewählten Klasse. Beim Aufruf der Transaktion vergleicht das System die Felder der generierten Datenablage mit den generierten Pflegedialogen. Das System prüft, ob Schnittstellenkomponenten und Kundenfelder ergänzt oder geändert wurden.

(C) SAP AG 56

Mit der Drucktaste

Löschen (Generierte Objekte löschen) können Sie vorhandene Objekte löschen.

(C) SAP AG 57

Mit der Drucktaste Objekte (Generierte Objekte anzeigen) können Sie die generierten Objekte anzeigen. In der Objektliste können 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 58

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 59

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 60

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 Billing Monitoring Raw Data in the SAP menu.

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 61

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 62

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 Billing Monitoring Reversal Requests for Billable Items .

For more information, see the documentation of the programs.

(C) SAP AG 63

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 – ) and billable excepted (3 – ) keep their status.

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 64

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 65

Billing in Contract Accounts Receivable and Payable

Billing Document

CRM

ERP

Inbound Interface

BAPI

ALE

External D

ocumentD

ata

Mapping

Billable Item

InvoicingProcesses

Selection

Grouping

…

Master Data Administration

Contract Account

Business Partner

External Billing System

Invoicing Order

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 66

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.

Billable Items

Data Selection

Creation of Billing Units

Aggregation of Billable Items

Billing DocumentUpdate

Invoicing Order

Billed Items

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 67

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 68

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 69

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 70

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 Dialog Create Billing Document . To switch to expert mode, choose the pushbutton Expert 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 71

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 72

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 0 Use original field value

SRCTATYPE 0 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 73

BITREF BIT_CURR SRCTATYPE

1 USD WEB1

2 USD WEB1

3 USD WEB2

4 EUR TOLL

5 EUR TOLL

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

Billing unit number BITREF BIT_CURR SRCTATYPE

1 1 USD WEB 1

1 2 USD WEB 1

2 3 USD WEB 2

3 4 EUR TOLL

3 5 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 74

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

1 1 USD WEB1

1 2 USD WEB1

1 3 USD WEB2

2 4 EUR TOLL

2 5 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


SRCTATYPE 0 Use initial value (SPACE)

(C) SAP AG 75

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

1 1 USD WEB1

1 2 USD WEB1

1 3 USD WEB2

2 4 EUR TOLL

2 5 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 76

SRCTATYPE Source transaction type -

PRODUCT Product Z_CUSTOMER_MODULE

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




PRODUCT 0 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


BITREF BIT_CURR SRCTATYPE PRODUCT

1 USD WEB1 997

2 USD WEB1 997

3 USD WEB2 997

4 EUR TOLL 100

5 EUR TOLL 200

The system forms the following billing units:

Billing unit number BITREF BIT_CURR SRCTATYPE PRODUCT

1 1 USD WEB1 997

1 2 USD WEB1 997

1 3 USD WEB2 997

1 4 EUR TOLL 100

1 5 EUR TOLL 200

Reason

(C) SAP AG 77

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:




PRODUCT 1 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

1 1 USD WEB1 997

(C) SAP AG 78

1 2 USD WEB1 997

1 3 USD WEB2 997

2 4 EUR TOLL 100

3 5 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:




BILLDOCNO_OLD 0 Use original field value

In the subdialog Assign Alternative Grouping Values, you do not store any entries.

Billing


(C) SAP AG 79

BITREF BIT_CURR SRCTATYPE BILLDOCNO_OLD

1 USD WEB1 4711

2 USD WEB1 4711

3 USD WEB1

4 EUR TOLL

5 EUR TOLL

The system forms the following billing units:

Billing unit number BITREF BIT_CURR SRCTATYPE BILLDOCNO_OLD

1 1 USD WEB1 4711

1 2 USD WEB1 4711

2 3 USD WEB1

3 4 EUR TOLL

3 5 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 80

Payment data items

Source items

Additional items

C_Include

S_Include Industry

Tax Item

C_Include

S_Include Industry

Payment Data Item

*

*

C_Include

S_Include Industry

Source Item

*

1

C_Include

S_Include Industry

Billing Document Item

C_Include

S_Include Industry

Billing Document Header* 0..11

1..* 1

1..*1..*

*

Reversal Data

C_Include

S_Include Industry

Additional Item

*

*

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 81

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 82

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

DFKKINVDOC_TMANDT

BILLDOCNOBILLDOCTAXITEM

Tax Item

DFKKINVDOC_PYMANDT

BILLDOCNOBILLDOCPAYITEM

Payment Data Item

*

*

DFKKINVBILL_SMANDT

BILLDOCNOBILLDOCSRCITEM

Source Item

*

1

DFKKINVBILL_IMANDT

BILLDOCNOBILLDOCITEM


DFKKINVBILL_HMANDT

BILLDOCNO


1..* 1

1..*1..*

*

DFKKINVDOC_RMANDT

BILLDOCNO

Reversal Data

DFKKINVBILL_AMANDT

BILLDOCNOBILLDOCADDITEM

Additional Item

*

*

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 83

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

o Grouping of tax items (TAX_GROUP)

o Grouping of payment data (PY_GROUP)

o Grouping of additional items (ADD_GROUP)

o 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 84

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 85

Billing Document

Billable Items

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

471147114711

47114711

4711

BIT_GRPNO

111

22

3

SRCTAID

123451234512345

1234612346

12347

BIT_AMOUNT

3.-5.-2.-

10.-7.-

2.-

SUBPROCESS

100010001000

10001000

1000

BITTYPE

100010001000

10001000

2000

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

Billing Item DFKKINVBILL_IBILLDOCNO

4711

47114711

BILLDOCITEM

00001

0000200003

HVORG AMOUNT0300 10.-

0010 17.-0650 3.-

QTY

500.00

…SRC_GROUP

0815

08160817

BITDATE01/14/2010

01/15/2010

01/15/2010

01/13/2010

01/18/2010

01/11/2010

BITTIME

10:52:0711:15:5919:54:22

13:11:3416:37:45

07:24:48

BILLDOCNO

4711BIT_GRPNO

1SRCTAID

12347

BIT_AMOUNT

1.-

SUBPROCESS

1000BITTYPE

2000BITDATE01/17/2010

BITTIME21:42:07

Source Item DFKKINVBILL_SBILLDOCNO

4711

4711

SRC_GROUP

0815

0816

… BIT_GRPNO1

2

BITCATSCC1

SCC1

12345

12346

4711 0817 3 SCC1 12347

4711 0817 1 SCC2 12347

SRCREF SUBPROCESS

1000

1000

10001000

/1FE/0SCC14IT00

BIT_DBTAB

/1FE/0SCC14IT00

/1FE/0SCC14IT00

/1FE/0SCC24IT00

BITRECTYPE

IT

IT

ITIT

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 customer-specific 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 86

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 87

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.

8125

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.

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.

8135

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.

In the function module processed at event 8135, you can fill or change the customer-defined fields of the billing document. In addition, you can also change some standard fields.

8137

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 addition, you can check the billing document, including the environment, for a last time before posting.

8139

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.

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 88

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 .


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 Schedule Program Run (F8) pushbutton in the toolbar.

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 89

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 Billing Billing

in Dialog Create Billing Document .

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 Log (Display Log) pushbutton to display a detailed 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 90

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 91

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

Billing in Dialog Reverse Billing Document .

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.


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

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

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 Invoicing Archive Data Billing Documents .

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 92

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.

DFKKINVDOC_TMANDT

BILLDOCNOBILLDOCTAXITEM

Tax Item

DFKKINVDOC_PYMANDT

BILLDOCNOBILLDOCPAYITEM

Payment Data Item

*

*

DFKKINVBILL_SMANDT

BILLDOCNOBILLDOCSRCITEM

Source Item

*

1

DFKKINVBILL_IMANDT

BILLDOCNOBILLDOCITEM


DFKKINVBILL_HMANDT

BILLDOCNO


1..* 1

1..*1..*

*

DFKKINVDOC_RMANDT

BILLDOCNO

Reversal Data

DFKKINVBILL_AMANDT

BILLDOCNOBILLDOCADDITEM

Additional Item

*

*

Structure of the Billing Document

Enhancement of the Invoicing Document

(C) SAP AG 93

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 94

Billing Document

Invoicing Item

Posting Document

Billable Items

Invoicing Item DFKKINVDOC_IINVDOCNO

081500081500081500

… HVORG030000100650

AMOUNT QTY10.-17.- 500.003.-

SRCDOCCAT

INVBIINVBIINVBI

SRCDOCNO

471147114711

SRCITEMCAT

BILLIBILLIBILLI

SRCDOCITEM

000010000200003

OPBEL370001370001370001

INVGRINV1INV1INV2

PSGRPGR1GR1GR1

Invoicing item posting document

Business Partner Item DFKKOPHKONT AMOUNTOPBEL

370001 140000 30.-PSGRP

GR1…

G/L Item DFKKOPKHKONT AMOUNTOPBEL

370001 175000 27.-…

370001 175001 3.-

QTY500.00

PSGRPGR1GR1

INVGRINV1INV2

Invoicing item G/L item

Invoicing item G/L item business partner item

Billable item (Billed status) source item

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

471147114711471147114711

BIT_GRPNO111223

SRCTAID123451234512345123461234612347

BIT_AMOUNT

3.-5.-2.-10.-7.-2.-

SUBPROCESS

100010001000100010001000

BITTYPE100010001000100010002000

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

Billing item invoicing item


471147114711

BILLDOCITEM

000010000200003

HVORG AMOUNT0300 10.-0010 17.-0650 3.-

QTY

500.00

…SRC_GROUP

081508160817

Source item billing item

Source Item DFKKINVBILL_SBILLDOCNO

47114711

SRC_GROUP

08150816

… BIT_GRPNO1

2

BITCATSCC1

SCC1

12345

12346

4711 0817 3 SCC1 12347

4711 0817/1FE/0SCC14IT00

BIT_DBTAB/1FE/0SCC14IT00

/1FE/0SCC14IT00

/1FE/0SCC24IT001 SCC2 12347

SRCREF SUBPROCESS

1000100010001000

BITDATE01/14/2010

01/15/2010

01/15/2010

01/13/2010

01/13/2010

01/11/2010

BITTIME10:52:0711:15:5919:54:2213:11:3416:37:4507:24:48

BILLDOCNO

4711BIT_GRPNO

1SRCTAID

12347

BIT_AMOUNT

1.-

SUBPROCESS

1000BITTYPE

2000BITDATE01/17/2010

BITTIME21:42:07

Invoicing Document: Link of Document Items

(C) SAP AG 95

Invoicing ItemInvoicing Item DFKKINVDOC_IINVDOCNO

081500081500081500

INVDOCITEM

000010000200003

HVORG

030000100650

AMOUNT

10.-17.-3.-

QTY

500.00

SRCDOCCAT

INVBIINVBIINVBI

SRCDOCNO

471147114711

SRCITEMCAT

BILLIBILLIBILLI

SRCDOCITEM

000010000200003

ITEMTYPE

ZUSAGEZUSAGEZBASE

Billable ItemsBillable Item /1FE/0SCC14IT00BILLDOCNO

471147114711471147114711

BIT_GRPNO

111223

SRCTAID

123451234512345123461234612347

BIT_AMOUNT

3.-5.-2.-10.-7.-3.-

SUBPROCESS

100010001000100010001000

BITTYPE

100010001000100010002000

BITDATE

01/14/201001/15/201001/15/201001/13/201001/18/201001/11/2010

BITTIME

10:52:0711:15:5919:54:2213:11:3416:37:4507:24:48

Billing DocumentBilling Item DFKKINVBILL_I

BILLDOCNO

471147114711

BILLDOCITEM

000010000200003

HVORG AMOUNT

0300 10.-0010 17.-0650 3.-

QTY

500.00

…SRC_GROUP

081508160817

ITEMTYPE

ZUSAGEZUSAGEZBASE

Invoice 081500 Date 10/22/2010

Basic charge [ZBASE] 3 EURConsumption [ZUSAGE] 27 EUR

-------------

Invoice amount 30 EUR

CustomizingBillable Item Type TFK8102B

SUBPROCESS

10001000

BITTYPE

10002000

ITEMTYPE

ZUSAGEZBASE

ITEMTYPE Text

ConsumptionBasic Charge

Invoicing Document: Link Using Item Type

(C) SAP AG 96

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.

Contract Account

Billing Document

Billable Items

Billing

Billed Items

Billable Items Transfer

Items Status Raw

Transfer RawData into Billable

Exception Handling

ItemsItems

Raw Excepted

Billable Excepted


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 97

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 98

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 99

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 100

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 one-off 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 Industry-Specific 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 101

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 One-Off Charges .

In event 8170 you can enhance the derivation of selected standard fields and customer-defined 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 102

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 103

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.


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.


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 104

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 105

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 106

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 107

ContractAccount

BillingDocument

Invoicing

InvoicingDocument

BW ExtractionArchiving

InboundProcess

PositionenExternalBilling

BW Output

Runtime

1 2

45

Design Time

InboundMapping Invoicing

DataSource

FI-CA Document

Printing Process

3

Invoice

Print Form

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 108

Design Time

Fakturierungs-funktionen

ContractAccount

BillingDocument

BillingDocument

Invoicing Process

InvoicingDocument

Runtime

Invoicing Process

InvoicingCategory Invoicing Type

FI-CA Document

Fakturierungs-einheitInvoicing Unit

DocumentSelection

InvoicingOrder

Open Item Selection

InvoicingFunctions

GroupingVariant

Event 2603

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 109

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 110

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 111

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 112

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 113

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 114

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 115

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 116

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 117

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 118

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)

Invoicing in FI-CA

BillingDocument

InvoicingDocument

BI Extraction

SD

SD BillingRequest

ERP

FICOFM…

InvoicePrinting

FI-CA

InboundInterface

BA

PIALE

ExternalD

ocument_D

ata

Mapping

InvoicingOrder

InvoicingProcesses

Selection

Grouping

Functions

…

Master Data Maintenance

ContractAccount

Business Partner

ExtractionOrder

CorrespondenceContainer

ExternalBilling System

RW-IN

(C) SAP AG 119

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 120

SD BillingDocument

BillingDocument

FI-CA Document

InvoicingOrder

Data Selection

Creation of Invoicing Units

Processing of Source Documents

Processing of Billing

Documents

Processing of Collective Bills

Processing of SD Billing

Documents…

FI-CA Document

InvoicingDocument

Update

Additional Functions

InterestCalculation Dunning Charges/

DiscountsAccount

Maintenance …

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 121

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 122

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 X

HIST_ITEMS X

CHARGE_DISC X

INTEREST_SEC X

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 123

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 124

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 125

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 126

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 127

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 128

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:

Selection ControlInvoicing Orders

Process Source Doc. Category

Main SelectionIndicator

01 INVBI X01 SD02 SD X03 COLBI X

ContractAccount V1

ContractAccount V2

Invoicing Process 01General Selections: Contract Account V1 – V2

Contract account V1 is processed


Contract account V1 is processed


Contract accounts V1 and V2 are processed


Neither contract account V1 nor V2 is processed

Source DocumentCategory INVBI

Source DocumentCategory SD

Source DocumentCategory SD

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 129

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 130

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 Function Module

BUKRS Company code

SPART Division

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

Grouping Characteristic Rank Use

BUKRS 0 Use Original Field Value if No Alternative Value Defined

SPART 0 Use Original Field Value if No Alternative Value Defined

(C) SAP AG 131

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:

Grouping Characteristics:

Company Code

Division

Src. Doc.

Company Code

Div-ision

10001 0001 A

10002 0001 B

10003 0002 A

10004 0003 B

10005 0003 B

Char. 1 Char. 2

0001 A

0001 B

0002 A

0003 B

0003 B

Src. Doc.

InvoicingUnit

10001 1

10002 2

10003 3

10004 4

10005 4

Creation of InvoicingUnits

Fields of Invoicing Order(FKKINV_TRIG)

Configuration of Grouping Variant

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 132

Grouping Characteristics:

Company Code

Division

Src. Doc.

Company Code

Div-ision

10001 0001 A

10002 0001 B

10003 0002 A

10004 0003 B

10005 0003 B

Char. 1 Char. 2

0001 A

0001 B

0001 A

0003 B

0003 B

Src. Doc.

InvoicingUnit

10001 1

10002 2

10003 1

10004 4

10005 4

Creation of InvoicingUnits

Fields of Invoicing Order(FKKINV_TRIG)

Configuration of Grouping Variant

Val. Alternative Value

0002 0001

Alternative Grouping Values for GroupingCharacteristic Company Code

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 133

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 SELCO

0001 VTREF 4711

0002 VTREF 4712

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


0001 VTREF 4711

0002 VTREF 4712

(C) SAP AG 134

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:


0001 VTREF 4711

0001 FAEDN 20050619

0002 VTREF 4712

0002 FAEDN 20050619

0003 VTREF

0003 FAEDN 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 135

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 136

Offsetting Items DFKKINVDOC_O FKKINVDOC_O

Reversal Data DFKKINVDOC_R

Charges/Discounts DFKKINVDOC_C FKKINVDOC_C

Charge/Discount History DFKKINVDOC_CH FKKINVDOC_CH

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.

1

Reversal Data

1 Invoicing/Reversal History

C_Include

S_Include Industry

S_Include Telco

Invoicing Document Item

C_Include

S_Include Industry

S_Include Telco

Invoicing Document Header

Reference Table of Posting Document

Charges /Discounts History

1..* 1..*1

0..1* 1

1

**

1..*

1

0..1

OffsettingItem

1

*

C_Include

S_Include Industry

S_Include Telco

Charges and Discounts

*1

Structure of Invoicing Documents

(C) SAP AG 137

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 138

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 139

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 140

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 141

InvoicingReversal History

DFKKINVDOC_SMANDT

SRCDOCCATSRCDOCNOINVDOCNO

…

Invoicing DocumentItem

DFKKINVDOC_IMANDT

INVDOCNOINVDOCITEM

…

Reference Table for Posting Document

DFKKINVDOC_PMANDT

INVDOCNOCONSNO

…

Invoicing DocumentHeader

DFKKINVDOC_HMANDT

INVDOCNO…

CHGDOC_EX = ‘2 ‘ 1

Charges/Discounts-History

DFKKINVDOC_CHMANDT

INVDOCNOOPBELOPUPK

CONSNO…

Charges/Discounts

DFKKINVDOC_CMANDT

INVDOCNOOPBELOPUPK

…

1..*1

1..* 1

1

*

1

*

*

11..*

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 142

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

DFKKINVDOC_RMANDT

INVDOCNO

DFKKINVDOC_CMANDT

INVDOCNOOPBELOPUPK

DFKKINVDOC_CHMANDT

INVDOCNOOPBELOPUPK

CONSNO

1

DFKKINVDOC_PMANDT

INVDOCNOCONSNO

Reference Table Posting Document

Charges/Discounts

Charges/DiscountsHistory

1

*

*1.

*

DFKKINVDOC_OMANDT

INVDOCNOINVDOCOITEM

Offsetting Item

Reversal Data

*

0..1DFKKINVDOC_S

MANDTSRCDOCCATSRCDOCNOINVDOCNO

DFKKINVDOC_HMANDT

INVDOCNO

CHGDOC_EX = ‘2‘

DFKKINVDOC_IMANDT

INVDOCNOINVDOCITEM

1

1

Invoicing/ReversalHistory

Invoicing DocumentItem

Invoicing DocumentHeader

1..* 1..*1

1

1…*

1

1

*

11

1

Database View of Invoicing Document

(C) SAP AG 143

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 customer-defined 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 144

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 145

DFKKINVDOC_PMANDT

INVDOCNOCONSNO

Reference Table Posting Document

C_Include

S_Include Industry

S_Include Telco

1

C_Include

S_Include Industry

S_Include Telco

C_Include

S_Include Industry

S_Include Telco

BP Item(DFKKOP)

Posting Doc. Header

(DFKKKO)

G/L Item (DFKKOPK)

1..*

1

1..*

1

1

Posting Document Invoicing Document

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 146

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 147

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 (FI-CA).

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 148

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

Derivation of CO-PA Profitability Segment

Posting Area2612

Posting Area2611

Posting Area2610

TFKCOK

TFK2610

Billing Item DFKKINVBILL_I… BUKRS SPART KOFIZ HVORG TVORG

0001 06 01 0300 00100001 06 01 0010 00300001 06 01 0650 0020

…

Invoicing Item DFKKINVDOC_I… BUKRS SPART KOFIZ HVORG TVORG

0001 06 01 0300 00100001 06 01 0010 00300001 06 01 0650 0020

…

G/L Item DFKKOPK… BUKRS HKONT GSBER KOSTL PA OBJNR

0001 175000 0001 KS01 08150001 175001 0001 KS01 0816

…

Business Partner Item DFKKOPBUKRS SPART KOFIZ HVORG TVORG HKONT…

0001 06 01 0100 0010 140000…

HVORG + TVORG

COKEY

COPAK = ‘X‘

CO Account Assignment

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 149

The link is according to the following pattern:

DFKKINVDOC_I Fixed Value DFKKBILLDOC_I

SRCDOCCAT INVBI

SRCDOCNO 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 150

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 151

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 152

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 153

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 154

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


471147114711

BILLDOCITEM

000010000200003

HVORG BETRAG MENGE0300 10.-0010 17.- 500,000650 3.-

…

Business Partner Item DFKKOPHKONT BETRAGOPBEL

370001 140000 30.-PSGRP

GR1…

G/L Item DFKKOPKHKONT BETRAGOPBEL

370001 175000 27.-…

370001 175001 3.-

MENGE500.00

PSGRPGR1GR1

INVGRINV1INV2

Invoicing Item DFKKINVDOC_IINVDOCN

O081500081500081500

… HVORG030000100650

BETRAG MENGE10.-17.- 500.003.-

SRCDOCCAT

INVBIINVBIINVBI

SRCDOCNO

471147114711

SRCITEMCAT

BILLIBILLIBILLI

SRCDOCITEM

000010000200003

OPBEL370001370001370001

INVGRINV1INV1INV2

PSGRPGR1GR1GR1

Billing Item Invoicing Item

Invoicing Item Posting Document

Invoicing Item G/L Item

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 155

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 156

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 157

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 158

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

Invoice 4711 Date: 10/22/2005

Contract 1000 – August 2005Basic PriceEnergy PriceTax on Sales/Purchases (16%)

Subtotal:

Contract 1000 – September 2005Basic PriceEnergy PriceTax 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 €

157.35 €

Posting Document Before Difference Clearing

Posting Document After Difference Clearing

Difference due to different summarization rules in invoicing document and posting document

Correction of tax posting with adjustment of receivablesposting

DFKKOP

Contract:Amount:

10001140.83 €

DFKKOP

Contract:Amount:

10001140,84 €

DFKKOPK

Account:Amount:

10023 (Rev. A)600.00 €

Account:Amount:

10024 (Rev. B)383.48 €

Account:Amount:

100030 (Tax)157.36 €

DFKKOPK

Account:Amount:

10023 (Rev. A)600.00 €

Account:Amount:

10024 (Rev. B)383.48 €

Account:Amount:

100030 (Tax)157.35 €

1

2

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 159

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 DFKKBILLDOC_T

SRCDOCCAT INVBI

SRCDOCNO BILLDOCNO

SRCITEMCAT BILLT

SRCDOCITEM 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 160

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 DFKKBILLDOC_T

SRCDOCCAT INVBI

SRCDOCNO BILLDOCNO

SRCITEMCAT BILLT

SRCDOCITEM 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 161

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 162

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 163

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 (FI-CA), 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 164

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 165

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 166

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 (FI-

CA) 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 167

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

PostingDocument

InvoicingDocument

SD BillingRequest

InvoicingOrder SD

InvoicingProcesses

Selection

Grouping

Invoicing SD Documents

…

SD

Billing Category U

AC InterfaceAC Interface

SD Order

SD Invoice

SD BillingDcoument CO-PA

FICO…

1 2

DFKKINV_TRIG

DFKKMOP…

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 168

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

PostingDocument

InvoicingDocument

InvoicingOrderVBRK

Invoicing Processes

Selection

Grouping

InvoicingVBRK

Documents

…

AC Interface

AC Interface (Project)

SD Order

SD Invoice

SD BillingDocument

CO-PA

FICO…

1

2

DFKKINV_TRIG

AC Interface (Exit)

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 169

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 170

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 171

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

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 172

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 173

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

FI-CA Document

IndividualContractAccount

BillingDocument

IndividualInvoicing

InvoicingDocument

CollectiveInvoicing

DocumentInvoicing Order Invoicing Order

CollectiveInvoicing

Collective Bill Contract Account

(C) SAP AG 174

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 175

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 176

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 15th 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 177

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 178

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 179

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 180

Create Preliminary Invoice

D CFI-CA: Account

Release Preliminary Invoice

Reject Preliminary

Invoice

4711*

4712

Check

4713

Print Invoice(Optional)

+

(Not Posted)

Preliminary

Preliminary

• - Automatically After N Days- Manually by User (CFC)

InvoiceInvoice

ReversalReversal

Create Clarification Case (CFC)(Optional)

Create Preliminary

Invoice

Release Preliminary

Invoice

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 (FI-CA) 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 181

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 182

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 Grace Rel.to Final Amount

01 14

01 0020 0010 9

01 0060 0010 999 X

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 183

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 184

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 185

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 186

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 187

'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 188

Integration Invoicing in Contract Accounts Receivable and Payable Invoicing Invoicing Processes Additional Functions Preselect Items for Activation in 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 189

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 190

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 191

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-business-partner 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 192

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 193

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 194

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 195

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 196

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 197

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 198

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/Industry-Specific) 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 199

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 200

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.



(C) SAP AG 201

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 202

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

o 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 203

o Scratch-off lottery ticket with credit to be activated

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

o 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 204

Accounts Receivable and Payable Invoicing Invoicing Processes Additional Functions Offsetting in Invoicing 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 205

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 206

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 207

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 .


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 208

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 209

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 210

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 211

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 212

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 213

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 Invoicing Dialog Processing Create Invoicing Document .

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 Dialog Processing Create Invoicing Document .

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 214

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 215

InvoicingDocument

ContractAccount

InvoicingDocument

Reversal


Runtime

Design Time

ReversalParameters

FI-CA Document

FI-CA Document

Invoicing Order

BillingDocument

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 216

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 217

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 Dialog Processing Reverse Invoicing Document.

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 218

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 Invoicing

Dialog Processing Reverse Billing Document .

2. To select the document to be reversed, either enter the document number directly, or enter the business partner and contract account.



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 219

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

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

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

o 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 Invoicing Dialog Processing Reverse Billing Document .


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 220

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 if it is already archived

o 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 if the billed items of this document were already deleted

Note

(C) SAP AG 221

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 Billing Billing in Dialog Reverse Billing Document .


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 222

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 223

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

Master Data

InvoicingDocument

Printing Process

Billing Document

Runtime

Design Time

Print Form


Invoice

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 224

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 225

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 226

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 Invoicing Document Display Invoicing

Document .

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 227

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 228

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 229



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.



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.


(C) SAP AG 230


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.



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 231

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 232

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 233

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 234

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 235

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 236

SAP ERP

Business Partner

ContractAccount

InvoicingDocument

SourceDocument

ClarificationCase

ClarificationCase

ClarificationCase

Clarification CaseCategory 03 - 06

Clarification CaseCategory 01

Clarification CaseCategory 02

Master Data Object

Document Object

Document Customizing

Clarification Case Category01 Source Document Clarification02 Source Document Clarification, Manual03 Invoicing Document Clarification04 Contract Account Clarification05 Contract Account Clarification, Manual06 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 237

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 X Client

INVCFCNO X 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 238

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 239

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.

Defined Processing Statuses

Number Status Explanation

01 Source document can be invoiced

Set by the user in dialog during clarification processing.

02 Source document cannot be invoiced


03 Source document returned to worklist


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.

(C) SAP AG 240

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 241

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 242

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 243

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 244

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 245

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 246

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 247

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 FI-CA 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 (FI-CA 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 .


CA) 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 248


CA) .

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 249

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 250

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 CRM 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 251

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 252

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 transfer-relevant 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 253

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

Contractaccount

Billingdocument

Invoicingorder

Inboundprocess

PositionenExternalbilling

document

Life

Design time

Inboundmapping

In Invoicing in Contract Accounts Receivable and Payable, the inbound interface for billing documents has the following functions:

(C) SAP AG 254

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 255

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 256

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 257

SAP ERP

ExternalsystemExternalsystem

ExternalsystemExternalsystem

Inboundinterface

BA

PI

ALE

Externaldocument

data

Mapping

Invoicingorder

Billingdocument

Z table

Invoicing

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 258

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 259

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 260

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:

Database

Billingdocument

Invoicingorder Z table

BAdI FKKINV_BAPIBILL BAdI ISTINV_BAPIBILLBAPI_ISTBILLDOC_CREATEMULTIPLE

CL_ISTINV_BAPIBILL

CREATE

MAP_BILLDOCS

CHECK

SAVE

USER_CHECK_INPUT

MAP_HEADERS

MAP_ITEMS

MAP_TAXITEMS

MAP_ADDITEMS

TRIGGER_CREATE

UPDATE_PREPARE

UPDATE

GET_NUMBERS

CONTRACT_ACCOUNT_DETERMINE

COLL_BILL_PARTNER

FILL_TRIG_CUSTOMER_FIELDS

INITIALIZE

UPDATE

UPDATE_PREPARE

CHECK_INPUT_PARAMETERS

MAP_HEADER

MAP_ITEM

MAP_TAXITEM

MAP_ADDITEM

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 261

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 262

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 263

HEADERS

ITEMS

TAXITEMS

ADDITEMS

BAPI_TE_FKKINVBILL_H

BAPI_TE_FKKINVBILL_I

BAPI_TE_FKKINVBILL_T

BAPI_TE_FKKINVBILL_A

YBAPI_MY_MAP_H

YBAPI_MY_MAP_I

YBAPI_MY_MAP_T

YBAPI_MY_MAP_A

YBAPI_MY_TABLE

EXTENSIO

NIN

MY_TABLE(customer table)

FKKINVBILL_H

FKKINVBILL_I

FKKINVBILL_T

FKKINVBILL_A

CI_FKKINVBILL_HCI_M_FKKINVBILL_H

CI_FKKINVBILL_I

CI_FKKINVBILL_T

CI_FKKINVBILL_A

CI_M_FKKINVBILL_I

CI_M_FKKINVBILL_T

CI_M_FKKINVBILL_A

1

4

2

3

BAPI interface Billing document

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 264

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 265

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:

Source Field in Table HEADERS

Target Field in Billing Document Header

Note

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 Only used if CURRENCY is not filled

INV_CURR INV_CURR

INV_CURR_ISO_CODE INV_CURR Only used if INV_CURR is not filled

TAX_DET_TYPE TAX_DET_TYPE

TAX_DATE_TYPE TAX_DATE_TYPE

SEPARATE_INV SEPARATE_INV

INVOICE_FIRST INVOICE_FIRST

ADD_GROUP ADD_GROUP

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 266

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 Dialog Processing.

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 267

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 268

CURRENCY 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 Only used if BASE_UOM is not filled

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 Mapping via posting area 2641

TAXJURCODE TXJCD

CONTRACT VTREF

PA2640_POS_ID1 For example, HVORG, BUKRS

Mapping via posting area 2640







PA2640 _POS_ID5 For example, HVORG, BUKRS






ADD_GROUP ADD_GROUP

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 269

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 270

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 271

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 272

REFITEM 001 002 003 004 005 006 007 008 009 010 011 012

ITEM_SIMULATED X X X X X X

POSTREL X X X X X X

PRINTREL X X X X X X

PRINT_SUBSTITUTE AA AA AA BB BB BB

AMOUNT 1.00 2.25 3.10 5.35 1.00 1.00 1.10 2.45 3.20 5.65 1.10 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 FI-CA – 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 273

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 TAXJURCODE

Billing document

Invoicing

Mapping

TAX_DATE_TYPE EXT_TAX_DATE ERMWSKZ MWSKZ TXJCD

Posting area2641

Posting area2640

Event 2100

Posting area2610

KOFIZHVORG, TVORG, BUKRS, SPART

Determinetax date

Determinetax code MWSKZ

Tax ratePosting date etc.

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 274

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



REFTAXITEM REFTAXITEM

TAX_GROUP TAX_GROUP

TAX_DATE TAX_DATE

(C) SAP AG 275

TAX_BASE TAX_BASE

TAX_PERC TAX_PERC

TAX_AMOUNT TAX_AMOUNT

CURRENCY BILL_CURR


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 276

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 TAXJURCODE

Billing document

Invoicing

Mapping

TAX_DATE_TYPE EXT_TAX_DATE ERMWSKZ MWSKZ TXJCD

Posting area2641

Posting area2640

Event 2100

Posting area2610

KOFIZHVORG, TVORG, BUKRS, SPART

Determine tax date

Determine tax code MWSKZ

Tax ratePosting date etc.

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 277

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 X X

TAX_GROUP 0008 0008

TAX_ID A A

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

Target Field in Billing Document Additional Item

Note

(C) SAP AG 278



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 279

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 280

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 281

Billingdocuments

Invoicingorders

Invoicingdocuments

FI-CA

BILLDOCNO 4201REVERSALDOCREVERSEDDOC


+100.00 USD+20.00 USD

+100.00 USD+20.00 USD

It has not been invoiced, which means the following invoicing order still exists:

Billingdocuments

Invoicingorders

Invoicingdocuments

FI-CA

BILLDOCNO 4201REVERSALDOC 5801REVERSEDDOC


+100.00 USD+20.00 USD

+100.00 USD+20.00 USD

BILLDOCNO 5801REVERSALDOCREVERSEDDOC 4201


...

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 282

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.

Billingdocuments

Invoicingorders

Invoicingdocuments

FI-CA



+100.00 USD+20.00 USD

+100.00 USD+20.00 USD

INVDOCNO 7062INVDOCNO 7062

+100.00 USD+20.00 USD

+100.00 USD+20.00 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 283

Billingdocuments

Invoicingorders

Invoicingdocuments

FI-CA



+100.00 USD+20.00 USD

+100.00 USD+20.00 USD


+100.00 USD+20.00 USD

+100.00 USD+20.00 USD



-100.00 USD-20.00 USD

-100.00 USD-20.00 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 284

Billingdocuments

Invoicingorders

Invoicingdocuments

FI-CA



+100.00 USD+20.00 USD

+100.00 USD+20.00 USD


+100.00 USD+20.00 USD

+100.00 USD+20.00 USD



-100.00 USD-20.00 USD

-100.00 USD-20.00 USD


-100.00 USD-20.00 USD

-100.00 USD-20.00 USD

+100.00 USD+ 20.00 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 285

Database

Billingdocument

Invoicingorder Z table

BAdI FKKINV_BAPIBILL BAdI ISTINV_BAPIBILL_CANCELBAPI_ISTBILLDOC_CANCEL

CL_ISTINV_BAPIBILL

REVERSALDOC_CREATE

REVERSALDOC_HEADER_CREATE

REVERSALDOC_ITEMS_CREATE

REVERSALDOC_TAXITEMS_CREATE

REVERSALDOC_ADDITEMS_CREATE

REVERSALDOC_TRIGGER_CREATECOLL_BILL_PARTNER

FILL_TRIG_CUSTOMER_FIELDS

CREATE

SAVE

UPDATE UPDATE

UPDATE_PREPAREGET_NUMBER UPDATE_PREPARE

CHECK_INPUT_PARAMETERS

CHECK_REVERSAL_ORDER

REVERSAL_ITEM_ANALYZEFILL_CUSTOMER_FIELDS_ITEM

FILL_CUSTOMER_FIELDS_ADDITEM

CHECK

USER_CONTR_ACCT_KEY_DETERMINECONTRACT_ACCOUNT_DETERMINE

USER_CHECK_INPUT

USER_CHECK_REVERSAL_ORDER

FILL_CUSTOMER_FIELDS_TAXITEM

FILL_CUSTOMER_FIELDS_HEADER

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 286

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 287

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 288

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 289

Suppose a billing document contains the following items:

Item 0001 with the amount 50.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:




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

Invoicingdocum

entsFI-C

A

BILLDOCNO 4202ADJUSTMENTDOC 4203ADJUSTEDDOC


010 +100.00 USD020 +20.00 USD010 +100.00 USD020 +20.00 USD

BILLDOCNO 4203ADJUSTMENTDOC ADJUSTEDDOC 4202


010 +100.00 USD020 +21.00 USD010 +100.00 USD020 +21.00 USD

Billing document notinvoiced

Create and invoiceadjustment document


+100.00 USD+21.00 USD

+100.00 USD+21.00 USD

+100.00 USD+21.00 USD-------------+121.00 USD

+100.00 USD+21.00 USD-------------+121.00 USD

The postings in Contract Accounts Receivable and Payable are shown in abbreviated form here and in the following examples.

(C) SAP AG 290

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

Invoicingdocum

entsFI-C

A



010 +100.00 USD020 +20.00 USD010 +100.00 USD020 +20.00 USD



010 +100.00 USD020 +21.00 USD030 -100.00 USD X040 -20.00 USD X

010 +100.00 USD020 +21.00 USD030 -100.00 USD X040 -20.00 USD X

Billing documentinvoiced

Create and invoiceadjustment document


+100.00 USD+20.00 USD

+100.00 USD+20.00 USD

+100.00 USD+20.00 USD

-------------+120.00 USD

+100.00 USD+20.00 USD

-------------+120.00 USD


+100.00 USD+21.00 USD-100.00 USD X-20.00 USD X

+100.00 USD+21.00 USD-100.00 USD X-20.00 USD X

+100.00 USD+20.00 USD+1.00 USD

-------------+121.00 USD

+100.00 USD+20.00 USD+1.00 USD

-------------+121.00 USD

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 291

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

Invoicingdocum

entsFI-C

A



010 +100.00 USD020 +20.00 USD010 +100.00 USD020 +20.00 USD


+100.00 USD+23.00 USD-100.00 USD X-20.00 USD X

+100.00 USD+23.00 USD

-100.00 USD X-20.00 USD X

+100.00 USD+20.00 USD+3.00 USD

-------------+123.00 USD

+100.00 USD+20.00 USD+3.00 USD

-------------+123.00 USD

BILLDOCNO 4203ADJUSTMENTDOC 4204ADJUSTEDDOC 4202


010 +100.00 USD020 +21.00 USD030 -100.00 USD X040 -20.00 USD X

010 +100.00 USD020 +21.00 USD030 -100.00 USD X040 -20.00 USD X

Billing documentinvoiced

Create adjustmentdocument, do not invoice


+100.00 USD+20.00 USD

+100.00 USD+20.00 USD

+100.00 USD+20.00 USD

-------------+120.00 USD

+100.00 USD+20.00 USD

-------------+120.00 USD



010 +100.00 USD020 +23.00 USD030 -100.00 USD X040 -20.00 USD X

010 +100.00 USD020 +23.00 USD030 -100.00 USD X040 -20.00 USD X

Create adjustmentdocument and invoice

Create adjustmentdocument and invoice

BILLDOCNO 4205ADJUSTMENTDOCADJUSTEDDOC 4204

BILLDOCNO 4205ADJUSTMENTDOCADJUSTEDDOC 4204

010 +100.00 USD020 +15.00 USD030 -100.00 USD X040 -23.00 USD X

010 +100.00 USD020 +15.00 USD030 -100.00 USD X040 -23.00 USD X


+100.00 USD+15.00 USD-100.00 USD X-23.00 USD X

+100.00 USD+15.00 USD-100.00 USD X-23.00 USD X

+100.00 USD+20.00 USD+3.00 USD-8.00 USD

-------------+115.00 USD

+100.00 USD+20.00 USD+3.00 USD-8.00 USD

-------------+115.00 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 292

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 293

Process Flow: Generate and Invoice Reversal Document

Billing

documents

Invoicingdocum

entsFI-C

A


-100.00 USD-20.00 USD

-100.00 USD-20.00 USD

+100.00 USD+20.00 USD

-120.00 USD-------------

0.00 USD

+100.00 USD+20.00 USD

-120.00 USD-------------

0.00 USD

Source document invoiced Create adjustment documentand do not invoice


+100.00 USD+20.00 USD

+100.00 USD+20.00 USD

+100.00 USD+20.00 USD

-------------+120.00 USD

+100.00 USD+20.00 USD

-------------+120.00 USD

Create reversal documentand invoice

010 +100.00 USD020 +20.00 USD010 +100.00 USD020 +20.00 USD

BILLDOCNO 4202ADJUSTMENTDOC 4203ADJUSTEDDOCREVERSALDOCREVERSEDDOC

BILLDOCNO 4202ADJUSTMENTDOC 4203ADJUSTEDDOCREVERSALDOCREVERSEDDOC

010 +100.00 USD020 +21.00 USD030 -100.00 USD X040 -20.00 USD X

010 +100.00 USD020 +21.00 USD030 -100.00 USD X040 -20.00 USD X

BILLDOCNO 4203ADJUSTMENTDOCADJUSTEDDOC 4202REVERSALDOC 4204REVERSEDDOC

BILLDOCNO 4203ADJUSTMENTDOCADJUSTEDDOC 4202REVERSALDOC 4204REVERSEDDOC

010 -100.00 USD020 -20.00 USD010 -100.00 USD020 -20.00 USD

BILLDOCNO 4204ADJUSTMENTDOCADJUSTEDDOCREVERSALDOCREVERSEDDOC 4203

BILLDOCNO 4204ADJUSTMENTDOCADJUSTEDDOCREVERSALDOCREVERSEDDOC 4203

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 294

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 295

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 296

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.

Fakturierungs-beleg

Master Data

BillingDocument

BW Extraction

InvoicingDocument

BW Output

Runtime

Design Time

DataSource

BW ExtractionOrder

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 297

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 298

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 299

The figure below illustrates the processing logic of the extraction.

Fakturierungs-beleg

Zeitpunkt 2710

Zeitpunkt 2710

Abrechnungs-beleg

Abrechnungs-beleg

Master Data

BillingDocument

Fakturierungs-beleg

InvoicingDocument

BillingDocument

BI Extraction

Design TimetDataSource<Defined for

Project>

Invoicing

BillingDocument

BillingDocument

InvoicingDocument

InvoicingDocument

InvoicingDocument

BI Extr.OrderReconciliation

Key

DFKKINV_BWTRIG

BI Extr.OrderInv.Document

DFKKINV_BWTRIGS

Delta Queue

Extract Structure<Defined for Project>

FKKINV_BW_EXTRACT00

Eventt2710

SelectionIndividual

Extr. Order

SelectionGroup Extr.

Order1

2

3

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 300

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 301

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 302

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 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 Ac c ounts R ec eivable and P ayable (F I-C A)

S ubscriber Account

E xternal Account

B us iness P artner

C ontract Account

P repaid Account

B us iness P artner

B us iness Agreement

P repaid Data

P repaid Account

P roduct

P rovider C ontract

P roduct

Mid

dle

war

e

P rovider C ontract

P rovider C ontract

Web

Ser

vice

s

OD

I*

C ommon O bject L ayer

*O rder D is tribution Infras tructure

F ramework for E rror H andling

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 303

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 Basic Settings Define Output Format and Storage Format of Product IDs .

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 304

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 305

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 306

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 307

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 308

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 Definition Sales and Distribution Define, copy, delete, check sales organization .

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 Definition Logistics - General Define, copy, delete, check division .

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 309

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 Master Data For Integration with Rating and Charging Provider Contract Display .

Change

(C) SAP AG 310

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 Effects and Notes

Create follow-on item for contract item

(Create Follow-On Item)

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.

End contract item (End Item)

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.

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 contract item

(Reverse Item)

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

(C) SAP AG 311

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 contract item

(Extend 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

F_KKVT_BUK 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 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.

F_KKVT_AUT This authorization object specifies authorizations for the input fields of the contract dialog. Dependent on the field values, you specify in Customizing for Contract Accounts Receivable and Payable which contracts a user is allowed to process under Basic Functions Provider Contract Specify Authorization Types .

F_KKVT_FDG

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 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 312

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.

C ontrac t Ac c ounts R ec eivable and P ayable (F I-C A)

B us iness P artner Bus ines s P artner S ubscriber Account

Bus iness Agreement

P repaid Data

C ontract Account E xternal Account

P repaid Account P repaid Account

Mid

dlew

are

Web

Ser

vice

s

D ialog

BA

PI/R

FC

Other S ys temsF ramework for E rror Handling

Distribution of Business Partners and Accounts Between Systems

(C) SAP AG 313

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.

Delete Distribution Records

Contract Accounts Receivable and Payable updates the status of the distribution to SAP Convergent Charging using distribution records. If the distribution was successful, you no longer need to keep these records in the system. You can delete the distribution records that are no longer needed using this program.

(C) SAP AG 314

Compare Master Data in FI-CA and SAP CC

The program compares the master data in order to determine if there are discrepancies between Contract Accounts Receivable and Payable and SAP 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