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.
PUBLIC Page 60 of 75
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
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:
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.
PUBLIC Page 61 of 75
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.
1.2.2.1.4.2 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 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.
1.2.2.1.5 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.
PUBLIC Page 62 of 75
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:
SELNR SELFN SELCU SELCO
0001 VTREF 4711
0002 VTREF 4712
0003 VTREF
You want to select items as above, but only those that are due within the next 14 days, based on the invoicing document date. If the document date is June 5, 2005, return the following values in C_SELTAB:
SELNR SELFN SELCU SELCO
Note that different numbers in SELFNR represent an OR link between the selection criteria; the same number indicates an AND link.
1.2.2.2 Documents
Definition
The following sections contain information about the documents created in the invoicing process.
1.2.2.2.1 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)
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.
1.2.2.2.1.1 DDIC Structures and Layer Model
PUBLIC Page 63 of 75
For invoicing documents, the following layers are differentiated with reference to the ABAP Dictionary (DDIC):
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 the update or in access modules. In the invoicing program, the invoicing documents are managed in logical tables. There are additional display structures 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:
Database Layer Logical Layer Display Layer
Header DFKKINVDOC_H FKKINVDOC_H FKKINVDOC_H_DISP
Items DFKKINVDOC_I FKKINVDOC_I FKKINVDOC_I_DISP
Posting document reference DFKKINVDOC_P FKKINVDOC_P FKKINVDOC_P_DISP
Source document history DFKKINVDOC_S FKKINVDOC_S FKKINVDOC_S_DISP
Offsetting items DFKKINVDOC_O FKKINVDOC_O
Reversal data DFKKINVDOC_R
Charges and discounts DFKKINVDOC_C FKKINVDOC_C
Charges and discounts 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 the logical layer. They contain an additional customer include that you can use to add additional fields for the display.
Example
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 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 2676.
Structure of Invoicing Documents