Performing Billable Item Management

For billable item management, you need to define a database structure. The database structure needs to reflect the following billing processes, as well as industry or customer-specific requirements. Convergent Invoicing supports database design with predefined interfaces.

1. Importing and Managing Billable Items

The following functions are available for importing and managing billable items: Configure billable item classes

When configuring the interface for data import, a billable item class describes the technical attributes of the billable items.

Generate interfaces for billable item classes

In customizing for contract accounts receivable and payable, you generate the objects that are necessary to transfer and store the data for a billable item class.

Save billable items

You can configure the billable item class in such a way that the system stores billed items and simulated billed items separately on the database.

Monitor billable items

There are functions for monitoring billable items based on their status group. On the SAP Easy Access screen, choose Billing → Monitoring. You can also change the status of individual billing transactions by excluding billable items from processing, or by restoring them so they can be processed.

2. Processing Billable Items

In billing, you bill the billable items of contract accounts. The billing process controls billing by specifying the rules used for selecting billable items, and for automatically grouping them into billing units. For each billing unit, the system creates a billing document.

In addition to the main structure for billable items, tax and payment data is stored in a tax item structure and a payment item structure.

A billable item has one of the following statuses:

• 0 (raw)

• 1 (raw - excepted)

• 2 (billable)

• 3 (billable - excepted)

• 4 (billed)

Raw data does not have to be complete, nor does it have to be consistent. The data in the individual fields can be changed.

For example, the business partner is know in the charging system, but the contract account is missing in the raw data.

Billable items must be both complete and consistent before they can be billed.

Items that have the status raw-excepted and billable-excepted, are excluded from further processing. This means that they are not considered during the transfer or during billing.

The system stores all the billable items of a billable item class according to their status in separate database tables. When you analyze billable items, you first have to select which status you want to evaluate (for example, monitoring reports in billing).

You can define data storage for billed items and for simulated billed items separately. Data storage for billed items can be defined as time-dependent.

The record type groups characteristics of billable items that are related in a business sense.

The system manages data for the following record types separately in the database and the main memory:

• IT (main items)

• PY (payment data items)

• TX (tax items)

• TT (text items)

Billable items belonging to record type IT are necessary to 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.

Requirements for BIT classes are derived from business needs. Here are 3 business examples:

Business example 1

The preceding Webshop Sales process delivers the payment card information for each billable item for the Internet download. Therefore, you need an extra billable item for the payment card information with direct reference to the billable item. The billable item class TDAT needs an additional database structure for payment card information.

Business example 2

The rating and charging system for Telco billable items has already calculated the tax per billable item. Therefore, you need an extra tax BIT for each billable item. The billable item class TC01 needs a database structure for extra tax BITs.

Business example 3

The rating and charging system is SAP Convergent Charging. You need to activate predefined database structures and function modules that are suitable for integration with convergent charging. The billable item class HRAT has activated the convergent charging interface.

The billable item class has not yet been activated.

All business examples have different requirements with regard to the database structure. This is because additional database tables for payment card information are required in example 1, tax information is required in example 2, and process integration is required as well as the database structure in example 3. In this course, we will concentrate on business example 1.

Customizing:

You can create new classes or change existing ones in customizing for contract accounts receivable and payable under Financial Accounting → Contract Accounts Receivable and Payable → Convergent Invoicing → Basic Functions → Billable Items → Billable Item Classes → Maintain Billable Item Classes → Item Classes.

Billable item classes are cross-client.

SAP does not supply any classes. The process configuration of billable item classes in customizing is well supported by the interface components menu. The settings you make here influence the appearance of the database tables, as well as the interfaces for the data transfer.

You make settings for billable item classes by following these steps:

1. Select interface components

2. Select customer fields (optional)

3. Manage tables of billed items

4. Manage tables of billed items for simulation

5. Activate configuration

6. Generate interfaces for billable items classes

The interface component represents a business process from a billing perspective. It defines which business transactions are supported in a billable item class (such as deferred revenues and down payment clearings). Therefore, interface components are the interface of a billable item class.

From a technical perspective, an interface component consists of the documentation of the component, the selection of required fields, the specification of dependent/prerequisite interface components, along with checks, derivations, and assignments of field values.

When you maintain a billable item class, you can assign interface components to the class. Based on this assignment, the system generates interfaces in which the fields of the interface component are automatically integrated. An interface includes both the function modules that transfer the data and the tables where the system stores the data. SAP provides pre-configured interface components.

Some interface components correspond to or add to certain invoicing functions that are part of invoicing in contract accounts receivable and payable. Fields that are defined in the interface components must also be included in the work structures, otherwise data may be lost.

You can use report RFKKBIXBITSTRUCCHECK to compare the fields of the work structures with those of the interface components and display any inconsistencies.

The Webshop sales process delivers the payment card information for each billable item for the internet download. Therefore, you need an extra BIT for the payment card information. The billable item class PBLW needs a database structure for payment card information.

You define interface components in customizing for financial accounting under Financial Accounting → Contract Accounts Receivable and Payable → Convergent Invoicing → Basic Functions → Billable Items → Billable Item Classes → Define Interface Components.

SAP delivers the data structure and program enhancement for the invoicing function PCCARD_PAYM.

SAP provides pre-configured interface components that you can use immediately. These include basic components, which are mandatory for each record type, as well as other optional components that you can add to a class. You cannot create customer-specific interface components.

Business example:

Payment processing and tax processing is selected for the billable item class. Database tables are generated for main items, payment items, and tax items.

In customizing under Financial Accounting → Contract Accounts Receivable and Payable → Convergent Invoicing → Basic Functions → Billable Items → Billable Item Classes → Maintain Billable Item Classes, you can choose the DB Table Set push button to access the following function:

Following a successful billing run, you can store billed items in various database tables. For example, you can use a new table every month for storing billed items. You can add tables for billed items by generating them with the Add Tables push button. Depending on the number of record types used, the system generates the appropriate number of tables for each new entry you make. The system manages these tables as table sets. Following this, you can specify how you want to use these table sets in customizing under Billable Item Management → Make Settings for Data Storage. As billing generates large amounts of data, this approach could help you simplify the management and archiving of items.

The system proposes the names of the tables. The individual tables of a class are distinguished from one another by a sequential number at the end of the table name, called a table set. The system also makes a distinction between tables for simulation and tables for update runs.

In the customizing activity Make Settings for Data Storage, you can enter storage tables that the system uses after the date you define in this activity. (See customizing for contract accounts receivable and payable under Financial Accounting → Contract Accounts Receivable and Payable → Convergent Invoicing → Basic Functions → Billable Items → Billable Item Management → Make settings for Data Storage.

The system makes a distinction between table sets for billed items and table sets for simulated billed items. A table set must be specified for both actual and simulated settlement. Only one table set at a time can be used for each actual and simulated settlement.

The table set is used as an optional selection criterion for deleting billed items (report RFKKBIXBIT4DELETE).

Before you can transport a configuration, you have to activate the related class in the customizing activity Maintain Billable Item Classes. Select the class you want to activate and choose Activate Configuration.

Configuration Status-In Processing:

The system sets this as the initial configuration status for a billable item class. All changes are allowed for a billable item class that has this status. However, you cannot transport the configuration of this class into another system.

Configuration Status-Transportable:

You cannot transport the configuration to another system until it has this status. All changes are allowed for a billable item class that has this status.

Configuration Status-Released as Productive:

Configurations that have this status can be transported to other systems and generated. Only compatible enhancements to this configuration are supported. You can:

• Add new interface components

• Add new fields

• Add new storage tables for billed items

• Create new indexes

The following statuses are possible:

New:

Designates a new class for which an active configuration version does not yet exist.

Modified:

Designates a modified configuration version of the class. An older, active version exists for the class.

Active:

Designates an active configuration version that can be used for generation.

You can only activate a class when it is consistent within itself. This means primarily that the class has to be without errors. At a given time, there can be only one active version of a billable item class. If you make changes to the active version of a class, but do not activate it again, the system creates a working version in addition to the active version. The working version can become the active version if you activate the configuration. Otherwise, you can go from the working version back to the last active version of the configuration by choosing the Return to Active Version push button.

As soon as a class has the configuration status Released as Productive, the system writes a history of the active versions. You can use this history to see when changes were made to the configuration. You can view the history by choosing Display Configuration Versions.

In transaction FKKBIXBIT_GEN you generate the interfaces for transferring billable items and also for storing data for billable items.

You can find this transaction in customizing under Financial Accounting → Contract Accounts Receivable and Payable → Convergent Invoicing → Basic Functions → Billable Items → Billable Item Classes → Generate Interfaces for Billable Item Classes.

During the generation process, the system deletes previously generated objects depending on the status of the interfaces. This means that loss of data can occur. The behavior of the system in this situation is dependent on the productive status of the interface. An interface can have one of the following statuses:

• Non-productive interfaces

  The system deletes existing objects and regenerates them. In this case, data is lost.

• Productive interfaces (test)

  The system deletes existing objects and regenerates them. In this case, data is lost.

• Productive interfaces

  The system regenerates only those objects that did not exist before, or that need to be modified. All data that already existed remains unaffected.

It is important to have a customer-specific field with content Speed for each billable item. The field is a criterion for aggregation, and different charge positions should be shown on the printed invoice. An additional field with content Speed is necessary in Main_item in the billable item class.

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)

To ensure that customer fields are included in 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.

SAP does not deliver customer includes. You have to generate them, before you can use them.

You configure the billable item classes in customizing. 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 configuring billable item classes. The system ensures that only complete and consistent configurations are transported.

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.