SAP Convergent Invoicing
PDF download from SAP Help Portal:
http://help.sap.com/erp2005_ehp_05/helpdata/en/f2/1ec04c9c704aefaab0e46888988e86/frameset.htm
Created on October 30, 2015
The documentation may have changed since you downloaded the PDF. You can always find the latest information on SAP Help
Portal.
Note
This PDF document contains the selected topic and its subtopics (max. 150) in the selected structure. Subtopics from other structures are not included. The selected structure has more than 150 subtopics. This download contains only the first 150 subtopics. You can manually download the missing subtopics.
© 2015 SAP SE or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE. The information contained herein may be changed without prior notice. Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by SAP SE 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. SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE in Germany and other countries. Please see www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices.
Table of content
Table of content
1 SAP Convergent Invoicing
1.1 Billing in Contract Accounts Receivable and Payable
1.1.1 Basic Concepts of Billing in Contract Accounts Receivable and Pa
1.1.1.1 Billable Item
1.1.1.2 Billable Item Class
1.1.1.3 Billable Item Types
1.1.1.4 Source Transaction
1.1.1.5 Source Transaction Type
1.1.1.6 Billable Item Packages
1.1.1.7 Interface Component
1.1.1.7.1 Basic Data for Billing
1.1.1.7.2 Receivables/Payables (Reduced Interface)
1.1.1.7.3 Receivables/Payables (Extended Interface)
1.1.1.7.4 Subitems
1.1.1.7.5 External Reference of the Billable Item
1.1.1.7.6 External Master Data Reference
1.1.1.7.7 Contract Reference
1.1.1.7.8 Billing Quantity
1.1.1.7.9 Tax Jurisdiction Code
1.1.1.7.10 External/Internal Account Assignment
1.1.1.7.11 Deferred Revenues - Time-Based
1.1.1.7.12 Deferred Revenues - Event-Based
1.1.1.7.13 Offsetting in Invoicing
1.1.1.7.14 Basic Data for Payment Processing
1.1.1.7.15 Payment Reference
1.1.1.7.16 Card Payment
1.1.1.7.17 Payment Card Data
1.1.1.7.18 Externally-Determined Tax Data
1.1.1.7.19 Assigning External/Internal Tax Codes
1.1.1.7.20 External/Internal Tax Type for Other Taxes
1.1.1.7.21 Tax Codes for Externally Determined Tax
1.1.1.7.22 SAP Convergent Charging
1.1.1.7.23 CRM Order
1.1.1.7.24 Basic Data for Telecommunications Taxes (US)
1.1.1.8 Billable Item Status
1.1.1.9 Record Type
1.1.1.10 Billing Process
1.1.1.11 Subprocess
1.1.1.12 Billing Type
1.1.1.13 Billing Target Date
1.1.1.14 Billing Cycle
1.1.1.15 Scheduling in Billing
1.1.2 Configuration of Billable Item Classes
1.1.2.1 System Landscape
1.1.2.2 Interfaces for Billable Item Classes
1.1.2.3 Customer Fields in Billable Item Classes
1.1.2.4 Interface Generation
1.1.3 Billable Item Management
1.1.3.1 Processing Rules and Program Enhancements
1.1.3.2 Transferring Raw Data into Billable Status
1.1.3.3 Changing of Raw Data and Error Handling
1.1.3.4 Data Storage
1.1.3.5 Displaying Raw Data and Billable Items
1.1.3.6 Deleting Billed Items
1.1.4 Billing Processes in Contract Accounts Receivable and Payable
1.1.4.1 Flow of Billing Processes
1.1.4.1.1 Flow Control for Billing
1.1.4.1.2 Data Selection
1.1.4.1.2.1 Selection of Billable Items
1.1.4.1.2.2 Controlling the Selection
1.1.4.1.3 Creation of Billing Units
1.1.4.1.4 Aggregation of Billable Items
1.1.4.1.4.1 Example 1
1.1.4.1.4.2 Example 2
1.1.4.1.4.3 Example 3
1.1.4.1.4.4 Example 4
1.1.4.1.4.5 Example 5
1.1.4.1.4.6 Example 6
1.1.4.2 Billing Document
1.1.4.2.1 DDIC Structures and Layer Model
1.1.4.2.1.1 Billing Document Header
1.1.4.2.1.2 Billing Document Items
1.1.4.2.1.3 Reversal Data
1.1.4.2.1.4 Tax Items
1.1.4.2.1.5 Payment Data Items
1.1.4.2.1.6 Source Items
1.1.4.2.1.7 Additional Items
1.1.4.2.2 Entering the Document Number and Assigning the Document Type
1.1.4.2.3 Enhancements of the Billing Document
1.1.5 Automatic Billing: Creating Billing Documents
1.1.6 Creating Billing Documents in Dialog
1.1.7 Reversing a Billing Document in Dialog
1.1.8 Displaying Billing Documents
1.1.9 Archiving Billing Documents
1.1.10 Enhancement Options in Billing
1.1.11 Integration of Billing in Other Applications
1.1.11.1 Transferring Billable Items from SAP Convergent Charging
1.1.11.1.1 Account Assignments
1.1.11.1.2 Transactions
1.1.11.1.3 Tax Codes for Internal Tax Determination
1.1.11.1.4 Tax Codes for Externally Determined Tax
1.1.11.1.5 Tax Type for Externally Determined Other Taxes
1.1.11.2 Integration with SAP Customer Relationship Management
1.1.11.3 Integration with SAP Convergent Charging
1.1.11.4 Updating Billable Items to SAP NetWeaver BW
1.2 Invoicing in Contract Accounts Receivable and Payable
1.2.1 Basic Terms of Invoicing in Contract Accounts Receivable and Pay
1.2.1.1 Invoicing Processes
1.2.1.2 Invoicing Functions
1.2.1.3 Source Document Categories
1.2.1.4 Source Document Types
1.2.1.5 Invoicing Types
1.2.1.6 Invoicing Categories
1.2.1.7 Target Date for Invoicing
1.2.1.8 Billing Cycle
1.2.1.9 Scheduling for Invoicing
1.2.1.10 The Term Invoice in Invoicing
1.2.2 Invoicing Processes in Contract Accounts Receivable and Payable
1.2.2.1 Process Flow of Invoicing Processes
1.2.2.1.1 Processing Options
1.2.2.1.2 Activating/Deactivating Invoicing Functions
1.2.2.1.2.1 Examples: Activating/Deactivating Invoicing Functions
1.2.2.1.2.2 Mandatory Invoicing Functions
1.2.2.1.2.3 Activation/Deactivation of Invoicing Functions
1.2.2.1.2.4 Customer-Defined Invoicing Functions
1.2.2.1.3 Data Selection
1.2.2.1.3.1 Invoicing Orders
1.2.2.1.3.2 Selection Control
1.2.2.1.4 Creating Invoicing Units
1.2.2.1.4.1 Notes and Examples for Configuring Grouping Variants
1.2.2.1.4.2 Event 2601
1.2.2.1.5 Selection of Open Items
1.2.2.2 Documents
1.2.2.2.1 Invoicing Documents
1.2.2.2.1.1 DDIC Structures and Layer Model
1.2.2.2.1.1.1 Invoicing Document Headers
1.2.2.2.1.1.2 Invoicing Document Items
1.2.2.2.1.1.3 Reference Table of Posting Documents
1.2.2.2.1.1.4 Invoicing and Reversal History Source Documents
1.2.2.2.1.1.5 Reversal Data for Invoicing Document
1.2.2.2.1.1.6 Charges and Discounts for Invoicing Documents
1.2.2.2.1.1.7 History Records for Charges and Discounts in Invoicing Document
1.2.2.2.1.1.8 Offsetting Items of Invoicing Document
1.2.2.2.1.2 Enhancements to the Invoicing Document
1.2.2.2.1.3 Document Number Assignment and Document Type
1.2.2.2.2 Posting Documents
1.2.2.2.2.1 Document Number Assignment and Document Type
1.2.2.3 Functions of Invoicing in Contract Accounts Receivable and Payab
1.2.2.3.1 Invoicing of Billing Documents
1.2.2.3.1.1 Linking the Documents
1.2.2.3.1.2 Transactions
1.2.2.3.1.3 Invoicing Items
1.2.2.3.1.4 Business Partner Items
1.2.2.3.1.4.1 Summarization Transaction
1.2.2.3.1.4.2 Account Determination
1.2.2.3.1.5 General Ledger Items
1.2.2.3.1.5.1 Account Determination
1.2.2.3.1.5.2 CO Account Assignment
1.2.2.3.1.5.2.1 Making System Settings for the CO-PA Account Assignment
1.2.2.3.1.6 Linking the Line Items
1 SAP Convergent Invoicing
Together the Billing in Contract Accounts Receivable and Payable and Invoicing in Contract Accounts Receivable and Payable components form SAP Convergent Invoicing.
Integration
SAP Convergent Invoicing offers you the possibility of integrating the following applications:
SAP Convergent Charging
SAP Customer Relationship Management Contract Accounts Receivable and Payable
This comprehensive integration enables you to implement the business process from the consumption of a service through pricing and billing right up to dispatch of the invoice to the customer.
Consume to Cash Scenario
1.1 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.
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.
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).
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.
Document Flow of Billing
1.1.1 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.
Billing Process
1.1.1.1 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.
The main items and the dependent record types use separate database tables.
1.1.1.2 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
1.1.1.3 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 .
Example
In one of the divisions of your company, you create billable items from various types of business transactions, such as basic charges, one-off charges, credit memos, fees and other receivables. During further processing of billable items in billing and invoicing, you want to ensure that basic charges are always displayed separately from the other business transactions. You want track all other business transactions together. To carry this out, you define one billable item type for basic charges and another billable item type for all other business transactions.
The following options are then available for controlling how items are processed further:
You can use the billable item type in the selection for the billing process, so that your selection is more precise. In that case, for example, billing selects only items that have “Basic Charge” as their billable item type.
In Customizing, you can assign the billable item type “Basic Charge” to a separate grouping variant for aggregation. If multiple basic charges of a customer are processed in billing, you show these in a separate billing document item.
1.1.1.4 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
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.
1.1.1.5 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 billing cycle 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). 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.
1.1.1.6 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.
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.
1.1.1.7 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.
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.
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.
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.
1.1.1.7.1 Basic Data for Billing
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).
1.1.1.7.2 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 derivation of the account assignments is done using posting areas 8120 and 8121 (see 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 / Define Main Transactions and Subtransactions ).
Additionally, in posting area 8123 you can derive the tax code from an external tax code (activity Define Tax Code for Internal Tax Determination ). 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.
1.1.1.7.3 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.
1.1.1.7.4 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.
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.
1.1.1.7.5 External Reference of the Billable Item
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 .
1.1.1.7.6 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.
1.1.1.7.7 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.
1.1.1.7.8 Billing Quantity
The interface component Billing Quantity makes it possible to store the billing quantity in the billable item.
1.1.1.7.9 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 .
1.1.1.7.10 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 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 and Define Main Transactions and Subtransactions . 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).
1.1.1.7.11 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 Deferred Revenues invoicing function (see Deferred Revenue Postings).
1.1.1.7.12 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 Event-Based Deferred Revenues invoicing function (see Deferred Revenue Postings).
1.1.1.7.13 Offsetting in Invoicing
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 .
1.1.1.7.14 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.
1.1.1.7.15 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.
1.1.1.7.16 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.
1.1.1.7.17 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.
1.1.1.7.18 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.
1.1.1.7.19 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 .
1.1.1.7.20 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.
1.1.11.1.4 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.
1.1.1.7.22 SAP Convergent Charging
The interface component SAP Convergent Charging is used for the transfer of billable items from SAP Convergent Charging.
Note
If you activate the SAP Convergent Charging interface component, the system automatically activates the interface component Receivables/Payables (Reduced Interface).
1.1.1.7.23 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 component Receivables/Payables (Reduced Interface). This interface component also requires interface component
External Reference of the Billable Item.
1.1.1.7.24 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.
1.1.1.8 Billable Item Status
A billable item has one of the following statuses: 0 ( Raw )
1 ( Raw excepted ) 2 ( Billable ) 3 ( Billable excepted ) 4 ( 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.
1.1.1.9 Record Type
1.1.1.9 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)
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.
Linking of Main Items with Dependent Record Types
1.1.1.10 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.
SAP provides billing processes. In addition to these billing processes, you can define your own billing processes. In defining billing processes, you can specify for each process, 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. They define number ranges for billing documents that are dependent on the billing processes.
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.
1.1.1.11 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
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.
1.1.1.12 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.
1.1.1.13 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 export mode for billing can you bill billable items before reaching the target date.
The scheduling function determines the billing target date. In scheduling you can select the date that you want to serve as the baseline date for the determination. Determination rules determine the billing target date based on the baseline date.
1.2.1.8 Billing Cycle
The billing cycles specifies the regular billing periods of your business partners. The billing cycle specifies the period end and the length of a billing period.
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 . Then you enter the technical key of the billing cycle in the contract account of your business partner.
Depending on the configuration of the billing cycle, you can overwrite the regular period end date at the level of the contract account. Optionally, you can use the billing cycle in scheduling for determining the target date for billing.
The end of the billing period that is defined by the billing cycle serves as the base date for determining the target date for billing and invoicing. In this way, you can specify periods from a business perspective (for instance, a calendar month) for your invoicing documents, without having to take into consideration the time of invoice creation or the necessity for balancing the load on the system.
1.1.1.15 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 enter the key for scheduling in the contract accounts of your business partners.
Customizing uses this key to find the calculation rules for determining the billing date.
The system determines the target date for billing from the base date for period assignment. You define the type of determination of the base date for billing in the calculation rule for determining the billing date. If the base date is provided by an external system, then leave this setting empty. In all other cases, the system corrects the base date according to the type of determination.
You can synchronize the execution dates of billing and invoicing with the billing cycles of your contract accounts (based on your specific requirements). You make this setting at the level of the scheduling rules.
If you determine the billing date based on the billing cycle, the system synchronizes the base date with the billing period specified by the billing cycle. In doing so, using the base date specified by the type of determination of the base date, the system determines the billing period in which the base date falls. Then the system corrects the base date to the end of the billing period.
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 Scheduling you define the key for scheduling. You make all further specifications under this key.
2. If you want to synchronize scheduling with the billing cycle, in the activity Define Billing Cycle , define a billing cycle and define 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 a billing cycle.
4. In the activity Assign Rules for Determining the Billing Date , you define the derivation of the rule for determining the billing date. The system derives the rule at the minimum dependent on the key of scheduling.
Scheduling
Example
You have defined scheduling with the key 1000.
The rule for scheduling 1000 is cycle-based and has as its base date the date the billable item was created. The calculation rule specifies, that with a date limit up to 31, two additional days should be calculated.
In a contract account that takes scheduling 1000 into account, the billing cycle 1000 is also entered. This billing cycle determines the period end monthly as the last day of the month.
For a billable item that was created on December 17, 2009, the scheduling is as follows: Base date = date of creation of billable item = 12/ 17/ 2009
Cycle-based: The system determines the end of the period in which 12/17/2009 falls. The period determined extends from 12/ 01/ to 12/ 31/ 2009. Base date is 12/ 31/ 2009.
The calculation rule adds two additional days; the resulting date is 01/ 02/ 2010 The target date for billing is 01/ 02/ 2010.
1.1.2 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.
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.
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: Selecting additional interface components not yet active
Selecting additional customer fields not yet active Adding table sets
Creating, displaying, and changing indexes
Note
Please remember that this can result in conversions of table content already present. 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. Alternatively, you can return from the working version to the last active version of the configuration.
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. You can also decide if the class is automatically generated in the target system. When it is imported to the target system, the billable item class is then automatically generated by the after-import method
FKK_BIX_BITCAT_GEN_AFTER_IMP. To generate the class automatically in the target system, choose Generate Dialog Autom. in Target System .
1.1.2.1 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.
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.
1.1.2.2 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.
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.
1.1.2.3 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 take up 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)
1.1.2.4 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.
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.
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
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:
__ Not released for use Released for Productive Use
A class can only contain this status if its configuration has also been released for productive use. Released for Test Use
A class can contain this status in the development or test system only if the status of the configuration is In Processing or Transportable . This gives you the option of testing a class in advance.
If you execute generation for a class of billable items, the interface is released for the transfer of billable items by default. If you would like to temporarily lock the transfer of billable items for a class on a technical basis, choose the pushbutton ( Lock Class for Usage ). If you want the class to be available again for data transfer, select the pushbutton ( Release Class for Usage ).
1.1.3 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.
1.1.3.1 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
