Purpose
This program runs through the actual documents in the liquiditycalculation, with the exception of manual transfer postings. Itattempts to determine the liquidity item of the document on the basisof information in the line items of accounting documents. This is donein two steps:
The first step is identical to the "simple" derivation mechanism FLQAC.The program evaluates the customer and vendor line items in paymentdocuments, as well as payment-related G/L account line items that havebeen declared as information carriers (FLQC7).
If the first step derives a buffer liquidity item defined using theSelect option, the second step is applied. In this case, the programworks its way down the accounting system until it finds customer orvendor line items in documents with the specified document type(typically invoices). These are then evaluated. If the result ispositive, the buffer liquidity item derived in the first step isreplaced. If not, the buffer liquidity item remains unchanged.

Integration
On the selection screen you specify the actual documents to beprocessed.

Features
The procedure for deriving the liquidity items to be assigned to theactual line item begins as in FLQAC:
First, the program reads the complete actual document. Typically, thiscomprises:
Line item: Bank account (actual)
Line item: Bank clearing account
If this line item has already been cleared in accounting, the programcontinues to search for other FI documents involved in the clearingtransaction. These are then imported. In the simplest scenario, itfinds an additional payment document:
Line item: Bank clearing account
Line item: Vendor (Information for 1st step)
At this point, the first derivation step is executed. This line item isevaluated using the first query sequence and the first user exit. Ifthe program finds a liquidity item, and this item is a buffer item, theprocess continues as follows:
If the vendor line item has also been cleared, the program againsearches for and imports all the documents involved in the clearingtransaction. In the simplest scenario, it finds an additional invoicedocument with one of the defined document types:
Line item: Vendor (Information 2nd step)
Line item: Expenses
Line item: Value-added tax
In this case, the line item containing the information for theliquidity item is the vendor line item in the invoice. Invoices areusually entered manually, and potentially contain more information thanthe corresponding vendor line item in the cleared payment document.
Exact procedure: The program checks the line item (field values ofstructures BKPF and BSEG) against the first query of the sequencedefined in the report for the second step. If all the conditions ofthis query apply, it makes a note of the assigned liquidity item. Ifnot, it checks the line item against the next query, and so on. Youalso have the option of programming your own derivation logic in a userexit function (interface according to 'FLQ_SAMPLE_ASSIGN_INV'). Thismay take priority over the derivation result from the queries.
The liquidity items derived from the "successful" information lineitems then replace the buffer liquidity items from the first step.

Activities
You should only set up this program if the simple FLQAC mechanism is inplace.
If the resulting assignments are unsatisfactory, you should first useprogram RFLQ_INVCHAIN to display the information line items and otherline items found for an actual line item. You can use this as astarting point for revising the query sequences and, where applicable,user exits applied to these line items.

Example
This example assumes that we have the simple document chain describedabove:
Line item: Bank account (actual),,Amount 100-
Line item: Bank clearing account
A document is cleared on the bank clearing account:
Line item: Bank clearing account,,Amount 100-
Line item: Vendor
We have two invoices:
Line item: Vendor,,Amount 40-,,Document type V1
Line item: Expense
Line item: Vendor,,Amount 60-,,Document type V2
Line item: Investment
We assume that in the first step the program derives the liquidity itemMATERIAL on the basis of the vendor line item of the payment document.This is exactly the same result as the simple mechanism FLQAC wouldhave produced (using the same parameters).
If MATERIAL is not a buffer liquidity item, the assignment is complete.If MATERIAL is a buffer liquidity item, the system continues with thesecond step, and the mechanism works its way down to the vendor lineitems in the invoices.
Line item: Vendor,,Amount 40-,,Document type V1
Line item: Vendor,,Amount 60-,,Document type V2
If neither of the document types V1 and V2 have been declared asrelevant, no further evaluations are carried out; the mechanism isunable to derive a new liquidity item.
If, for example, V2 has been declared as relevant, the mechanismevaluates the second line item and the corresponding document header.It may be possible to derive the liquidity item INVESTMENT solely onthe basis of the document type V2. If we assume that we were unable toderive a liquidity item from the other invoice (V1), or that theliquidity item derived on the basis of this invoice is the same as thebuffer liquidity item (MATERIAL), the assignment result is as follows:
The payment amount 100- from the actual document is split into:
60- assigned to INVESTMENT (new in the 2nd step)
40- assigned to MATERIAL (from the 1st step, buffer)