Purpose
This program runs through actual documents in the liquidity calculationthat belong to FI documents (that is, all documents except for manualtransfer postings). It attempts to derive the liquidity item for thedocument from the information in FI.

Integration
You specify the range of actual documents to be processed on theselection screen.

Features
The logic for deriving the liquidity item (with the query sequence anduser exit) is the same as for the program that evaluates theinformation in bank statements. However, this program incorporates anadditional step, namely the search for the FI document line items thatare to be evaluated:
An actual line item in the liquidity calculation references a specificline item in FI (in other words, the G/L account for the line item is abank account or another actual account). However, this document lineitem seldom contains information that is useful for evaluationpurposes.
As a result, the mechanism imports the whole document, typically:
Line item: Bank account (actual)
Line item: Bank clearing account
Likewise, the line item on the bank clearing account seldom containsuseful information.
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, it finds anadditional payment document:
Line item: Bank clearing account
Line item: Vendor (Information)
In this case, the line item containing the information for theliquidity item is the vendor line item. The mechanism stops at thisline item, regardless of whether or not it has been cleared.
As a rule, the account type and, in some cases, the G/L accountdetermine whether a line item is an "end point" in which the programsearches for information to derive a liquidity item. These "informationline items" are:

• All customer and vendor line items


• All other line items posted to a G/L account that has been declared as
an "information carrier" in Customizing (for example, reconciliationaccounts for treasury transactions or salary payments).
This search method usually finds one or several potential "informationline items", each of which is evaluated as follows: The line item(field values of structures BKPF, BSEG and possibly KNA1, LFA1) ischecked against the first query in the sequence defined in the report.If all the conditions of this query apply, it makes a note of theassigned liquidity item. If not, it checks the line item against thenext query, and so on. You also have the option of programming your ownderivation logic in a user exit function (interface according to"FLQ_SAMPLE_ASSIGN_FI"). This may take priority over the derivationresult from the queries.
The program collects the liquidity items derived from the "successful"information line items together with the corresponding amounts, andcompares the total amount with the amount of the actual line item.
If the actual line item is not covered (that is, if the total amountfrom the information line items is less than the actual line item), themechanism cannot assign a new liquidity item, and the liquidity itemassignment remains unchanged.
If the actual line item is covered, it is assigned the new liquiditypositions. The amount is divided up in proportion to the amounts of theinformation line items.
The detail log displays the new liquidity item and the correspondingquery. If the program is unable to assign the liquidity item for anactual document, an error message is displayed in the log.
One of the errors that can occur is related to the fundamental programlogic: If the mechanism begins with an actual line item as describedabove, and then reads the related document cluster from the clearingtransaction, this document cluster may sometimes include other actualline items. As a result, the cluster comprises N actual line items andM information line items. In such cases, meaningful information canonly be assigned to the current actual line item in exceptional cases.To reflect this, the program often displays an error message (N:Mrelationship).
This primarily applies to clearing transactions on bank clearingaccounts. We therefore advise that you clear documents on bank clearingaccounts on a strict transaction basis, and only clear a limited numberof documents against each other (you can usually achieve this by usingprogram SAPF124 for automatic clearing). You should not permit massclearing postings with several hundred documents.

Activities
If the resulting assignments are unsatisfactory, you should first useprogram RFLQ_ITCHAIN to display the information/other line items foundfor an actual line item. You can use this as a starting point forrevising the query sequence and, where applicable, the user exitapplied 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
Two documents are cleared on the bank clearing account:
Line item: Bank clearing account,,Amount 60-
Line item: External vendor
Line item: Bank clearing account,,Amount 40-
Line item: Internal vendor
If you have already declared the bank account or bank clearing accountas an information carrier, the mechanism only sees the first documentand evaluates the corresponding line item. However, this will tend tobe the exception.
If the bank account and bank clearing account have not been defined asinformation carriers, the mechanism looks at the two other documentsand evaluates the two line items:
Line item: External vendor,,Amount 60
Line item: Internal vendor,,Amount 40
If the program is unable to derive a liquidity item for both of theseline items, the actual line item is not reassigned. This is because theactual line item is not fully covered.
If the program derives the same liquidity item for both line items,this liquidity item is assigned for the full amount of the actual lineitem. If the program derives a different liquidity item for each lineitem, the actual line item amount is split proportionately between thetwo liquidity items (in this example, the ratio is 60/40).