Note 591208 - Liquidity calculation: Technical documentation

Version / Date 1 / 2004-08-24
Priority Recommendations/additional info
Category Consulting
Primary Component FIN-FSCM-LP Liquidity Planer
Secondary Components


You require technical background information for the actual calculation of the Liquidity Planner component.

History: Date and release of this documentation:
August 20, 2004 for PI2003 and those following.

To control the overall liquidity in the company, it is advisable to monitor the plan/forecast/actual cycle for the inflows and outflows of funds. That was already attempted in the old R/3 product TR-CB Cash Budget Management. Since the response was somewhat cool, TR-CB is discontinued after Release 470. The alternatives provided by SAP are:

  • The liquidity planning in SEM-BPS (Strategic Enterprise Management - Business Planning and Simulation). SEM-BPS starts with the SAP Business Warehouse; it is the universal instrument for the entire Business Planning and Simulation. In this case, planning areas and layouts can be defined freely, there are several options for the data entry and for the automatic plan/plan and plan/actual integration. In addition, there are utilities for coordinating offline planning. The planning area delivered in SEM -BPS Content as an example for liquidity planning with monthly period split and liquidity items for the description of the technical origin and usage of the cash flows only shows the manual data entry and subsequent consolidation; in no way does it exhaust all the possibilities of SEM-BPS. On the contrary, SEM-BPS is a fully featured and relatively open tool whose use and implementation in a project must be worked out first for the customer.
  • Liquidity forecast in R/3 Cash Management (TR-CM). This component analyzes all flows entered in the R/3 system with regard to their payment relevancy and delivers the day and amount of the payment expected or already made. In addition, the manual entry of additional payment noted items is possible. Depending on lead time (such as between calculation and payment), this component provides a complete, and to a large extent, self-updating overview of the payments to be expected in the next days or weeks.
  • In the liquidity calculation (or analysis), the actual payments updated in the R/3 system are updated completely and classified according to origin and use. For that, liquidity items are used like in planning.

The combination of planning and actual calculation is also marketed as SAP Liquidity Planner.
The plan/forecast/actual liquidity cycle mapped by the three components specified is incomplete; specifically, the information on the technical origin and usage is missing in the forecast. Therefore, programs that can supplement a part of the forecast information with liquidity items are also delivered with the liquidity calculation as of PI2003.1. There is no procedure model yet for usefully combining these and the TR-CM data in BW to an entire forecast.
Therefore, this SAP note only addresses the core process of the liquidity calculation, the online update of the actual payments and the most important mechanisms for the assignment of liquidity items.

Other terms


Reason and Prerequisites

The liquidity calculation function is delivered with the R3 Plug-In (which was first delivery with PI2001.1); it is available for R/3 as of Release 4.5B as well as in ECC (SAP ERP).


The objects of the liquidity calculation are in two development classes: FFLQ and FFLQV. FFLQ contains the objects; that were developed for Basis Release 4.5B and then transported to the higher releases. The objects which were created separately for each basis release are in FFLQV.
This differentiation is purely technical in that: All objects exist in all basis releases and provide exactly the same function.

Naming conventions for the objects of the liquidity calculation:
All ABAP dictionary objects, function modules, and function groups start with FLQ*, all executable programs start with RFLQ*, the module pools start with SAPMFLQ*.

Functions and objects in detail:
The actual data of the liquidity calculation is gathered in two steps:

  • Online update of the payments posted in the R/3 system in separate tables for provisional liquidity items.
  • Subsequent analysis and classification of these payments with assignment of the technically valid liquidity items. That occurs in a rule-based manner; in this case, as many individual steps and duplications are possible as required.

Step I: The online update of the payments

  • The prerequisites for that are:

  • Modules FLQ_DOCUMENT_PROJECT (generating LQ line items) and FLQ_DOCUMENT_POST (update) were appended to the AC interface (table TRWPR), as specified in SAP Note 412605.
  • With FLQC1 liquidity items were created in Customizing. (Table FLQLPOS with texts FLQLPOST).
  • With FLQC2 dummy liquidity items for incoming and outgoing payments were defined in the global data (table FLQCLNT).
  • With FLQC3 the company code was registered and set to active for the liquidity calculation.

If a document is entered in AC, function module FLQ_DOCUMENT_PROJECT is called via the AC interface (RWIN) for event DOCUMENT/PROJECT. In the module, the internal accounting document (ACCIT) is processed line by line. There are two checks:

    1. Is the liquidity calculation active in the company code?
    2. Is the account of the line an actual account?

Only if both checks are affirmative is the document line item marked for the generation of a line item.

About the term 'actual account':
The actual accounts are the FI G/L accounts in the company code, which are considered as accounts for liquid funds (such as bank, cash desk). The liquidity calculation uses existing Customizing from the FI bank accounting and regards all G/L accounts as actual accounts, which are defined in table T012K of the house bank accounts. Using Transaction FLQC4 (table FLQACC_ACT) in Customizing of the liquidity calculation, additional G/L accounts can be declared as actual accounts. You also have the option there to classify G/L accounts, which are defined in T012K, explicitly as non-actual. In this transaction, you can work per chart of accounts; then the setting applies to all company codes with this chart of accounts. Specifications only per company code are also possible and stronger, given a conflict.
Function module FLQ_CHECK_ACCOUNT is used to check the accounts for 'actual'. Using report RFLQ_LISTACC (Transaction FLQLACC), you can access an overview of all actual accounts.

In the liquidity calculation there are two line item tables for FI documents:
           FLQITEMBS - Line Items for Bank Statement Docs
FLQITEMFI - Line Items for Other FI Documents.

The first table contains two additional fields, specifically the reference (KUKEY and ESNUM) to a bank statement item stored in SAP (tables FEBKO, FEBEP, FEBRE). As a default, every actual line item of an accounting document generates a line item in FLQITEMFI. So that it creates a line item in FLQITEMBS instead, the following conditions must be met (SAP Note 552009):

  • The actual account has to belong to a house bank account (table T012K).
  • The reference document number in the document header starts with the ID of the bank and the account:

           BKPF-XBLNR(5) = T012K-HBKID

If these conditions are met, then the bank statement reference is used from the header text and entered in FLQITEMBS:
           KUKEY = BKPF-BKTXT(8).

The values for most other fields in tables FLQITEM* come directly from the corresponding fields in the accounting documents - exceptions are reviewed below. A special feature is still that there are two company code fields in FLQITEM*, specifically ZBUKR and BUKRS. These are filled identically at the beginning, however, are different in their importance:

    • The paying company code ZBUKR is the company code of the actual line. This field therefore belongs to the reference of the LQ line item for the FI document line item and cannot be changed.
    • BUKRS is the company code for which payments are made. This can still be changed later (like the liquidity item, see below).

The payment date LQDAY specification depends on Customizing (global data, FLQC2):

  • As default, it is the value date BSEG-VALUT of the actual line. (If this is not provided, then the payment date is determined according to SAP Note 24883).
  • However, the posting date can also be selected.

The liquidity item of the new line item is the default item for incoming payments or outgoing payments from Customizing (global data, FLQC2), depending on the signs of the amount.
At the end of the line by line processing, there is a user exit (entered in FLQC2) with sample module FLQ_CUSTOM_FIELDS. In this case, fields in customer appends or standard fields may be supplied with data differently.
After the processing of the individual lines is completed, there is still one more special treatment: If the accounting document consists only of actual lines in the spirit of the liquidity calculation, then the default item for the incoming payment or outgoing payment is replaced by the corresponding Customizing item for the bank transfer (also in FLQC2).
As a result of module FLQ_DOCUMENT_PROJEKT, the LQ line items for the current FI document are in the global internal table G_T_ITEM - for each actual line there is one line item.
The update of these line items on the database occurs for the AC interface event DOCUMENT/POST via module FLQ_DOCUMENT_POST. There the line item receives the complete FI reference and is set afterwards with FLQ_UPDATE for the database. The system simultaneously generates or updates totals record FLQSUM there with line items FLQITEMBS or FLQITEMFI. The totals table fields result from the line item; FLQSUM-LQTYPE displays whether or not the totals record comes from a FLQITEMBS line item ('B') or from a FLQITEMFI line item ('F').

This online update ensures that all actual document line items in accounting immediately generate line items in liquidity calculation and thus ensures all actual line items are in complete agreement for both components (program RFLQ_S001). The liquidity item assigned in this case is one of the four dummy items from Customizing (if it was not already changed in the online exit) and is thus not especially expressive. Downstream processes, which are described below in more detail, find the correct, appropriate liquidity item.
As alternative and addition to the online document generation, you have the option via RFLQ_REBUILD (Transaction FLQC10: Reconstruct flow data) to generate LQ line items for FI documents subsequently. In this case, the same modules will run as online.
There is also a deletion program: RFLQ_DELETE (Transaction FLQC9: Delete flow data)

Analysis and classification of the payments entered
The actual payment of the product is in this step; the payments updated online are moved to a large extent automatically from the initial dummy items to the appropriate liquidity items via defined rules. That happens in the assignment programs (naming convention RFLQ_ASSIGN_*). There is a large number of them; by using various sources of information. Typically, you will not use all of them during the production mode, but you will select some pragmatically:

RFLQ_ASSIGN_BS - Bank statement (Transaction FLQAB)
RFLQ_ASSIGN_FI - FI payment document (Transaction FLQAC)

RFLQ_ASSIGN_REX - Expense/revenue in invoices (Transaction FLQAD)
RFLQ_ASSIGN_INV - Vendor/customer lines in invoices

RFLQ_ASSIGN_DIR - Actual line in FI document (one item)
RFLQ_ASSIGN_EXIT - Actual line in FI document (with splitting)

The first two programs listed are also the first chronologically; the next two are an enhancement of RFLQ_ASSIGN_FI and the last two are exotic. Basically, they are different in that RFLQ_ASSIGN_DIR can assign exactly one liquidity item to an actual line - on the other hand, you can use RFLQ_ASSIGN_EXIT to distribute the amount of the actual line to several items. All six programs are documented in the system; the most important three (with Transaction code FLQA*) are discussed in more detail below.
From discussions with customers, SAP has gathered that previous publications on the Liquidity Planner gave the impression that you always had to use the assignment report from the bank statement (FLQAB) and also the electronic bank statement. That is incorrect: The Liquidity Planner is not dependent on the electronic bank statement and a lot of our customers (virtually all in countries with less detailed bank statements) do not use FLQAB. Currently, the most widely used mechanism is the one that goes from the actual line up to the expense and revenue lines of the paid invoices and determines the liquidity items there (FLQAD).
The assignment programs operate on the line item tables FLQITEMBS and FLQITEMFI. On the selection screen, you can restrict the area of the line items to be examined (such as company code, payment date, current liquidity item). Internally, the program runs through two loops: an external one for the paying company code on the authorization check (there is no separate authorization object at this time, instead F_FDSB_BUK from cash management and forecast is used) and for locking (lock object EFLQ_COMPANY for table FLQCOMPANY). There is also an internal loop where the actual line items in the company code are processed one after the other and each one receives new liquidity items.

We will start with the assignment RFLQ_ASSIGN_BS (FLQAB), which uses the information in the bank statement. In the process, we will also describe the constructs of the queries and query sequences used in the other mechanisms.

The basic concept behind program RFLQ_ASSIGN_BS is quite simple: It is intended to do the work of the employee who, up to now, was busy sifting through the items of the bank statements and deriving the origin/usage of the payment (in other words, the liquidity item) from the usage texts and other information. To do that, the program uses a rule set defined by the customer.
The program operates exclusively on line item table FLQITEMBS (with reference to the bank statement). For every line item, the following SAP bank statement tables are accessed via the existing bank statement reference:
           FEBKO - Header of the bank statement
FEBEP - Line items (item) of the bank statement
FEBRE - Reference records for an item

The reference to an item generally consists of several table entries. These note to payee lines are bundled into a string after the import. Processing continues only with this string.
Selected fields in structures FEBKO, FEBEP and the note to payee string are subjected to queries:
A query is a collection of conditions to field values together with a liquidity item that is assigned if all conditions are met. A plaintext example for this kind of query is: If the business transaction code is 010 and the 'Rechnung' character string is in the note to payee parameter, then the liquidity item assigns AAAA.
The queries are not created in Customizing but in the application (Transaction FLQQB1). On the initial screen, specify a description and the liquidity item in addition to the key. If you enter a company code here, the query can only operate for actual documents in this company code. The background of this option is that the authorization for maintaining queries can be restricted to one company code via authorization object F_FDSB_BUK. In this case, the employee is not to edit any 'global' queries (without company code) but only 'local' queries for his/her company code.
The conditions for the query are entered on a separate screen as selection options (like on the selection screen of a DDIC dictionary report). The rule specified above: If the business transaction code is 010 and the 'Rechnung' character string is in the note to payee parameter, then the liquidity item assigns AAAA, this would then be created as a query as follows:
Call Transaction FLQQB1 to maintain a query. Enter a new query ID and choose "Enter". Then enter the short and long text as well as liquidity item AAAA, if necessary restrict to one company code. Branch to the conditions (F5) after that. In the selection options for the note to payee parameter, enter the masked string *RECHNUNG* and enter 010 in the selection options for the business transaction code. Choose "Execute" (F8) to return to the basic screen and save there.
To ensure a clear overview, not every field in the structures involved has a selection option; instead, SAP has preselected fields. If you want to use information from additional fields, you can create more selection options for that via a modification. You can find out how to do this in SAP Note 497118.
The module pool for the queries is SAPMFLQQRMAINT, the tables are FLQQR for the basic data and FLQQRRG for the conditions (see below). There are queries not only for gathering liquidity item from the bank statement, but also for other mechanisms. The origin field (LQORIG) contains the specifications regarding the query's relevance.
So that the conditions entered in the selection options can be transferred as ranges to database table FLQQRRG, the program requires entries for the names of the structures (tables) and fields used in system tables FLQQR_TABLE and FLQQR_FIELD.
These system tables are delivered empty; you have to fill them by executing program RFLQ_INITTBL once while setting up the liquidity calculation.
For a liquidity item, you can create as many queries as you require. The program does not use the queries directly, instead it uses query sequences, these are groups of queries with a determined sequence. In Customizing (FLQC5), you can create the keys and texts for the query sequences (table FLQGRP). There are again 'global' sequences and others which can be used only in one company code. In the application, the sequences are filled with queries (Transaction FLQQB5; table FLQGRP_QR).
In turn, a queried sequence is specified for every bank account in Customizing (FLQC6). The reason for this mix of Customizing and application is that only the more lasting settings are in Customizing while the queries and their combination into sequences are in the application as a current setting and thus can be changed easily.
The derivation of the liquidity item for an actual line occurs as follows: The fields in structures FEBKO and FEBEP, which are linked with the actual line, and the usage string are checked against the first, second, ... query of the sequence that was assigned to the bank account of this line. The rule in this case is: The first hit wins. In other words, the first query whose conditions apply determines the liquidity item of the actual line. The queries that are toward the end of the sequence will not run for this actual line anymore. This is why when you combine the query sequence you should specify that the special queries come before the general ones.
Alternative to or in addition to the query sequences, you have the option of deriving liquidity items via user exits. For this purpose, copy function FLQ_SAMPLE_ASSIGN_BS into a customer function (because of the interface) and enter the program logic for deriving a liquidity item there (and for deriving the secondary dimensions company code, business area). Unlike the queries, where an advance selection of fields from FEBKO and FEBEP was made, the complete structures are available in the module. In addition, you can see there whether or not the query sequence might already be able to determine a liquidity item for the document. That way it is possible to concentrate on exceptions and special cases in the exit, for example.
You can activate the exit simply by entering the corresponding function name on the selection screen of FLQAB. In each case, it is processed after the query sequence; regardless of whether or not one of the queries was successful.
If the program can allocate a new liquidity item to the actual document, then the program generates new entries in table FLQITEMBS (with LQORIG = B), the old entries are selected as historical entries (XDELETE = X). Totals table FLQSUM is adjusted correspondingly.

Next we will discuss assignment program RFLQ_ASSIGN_FI, which typically estimates the liquidity item assignment by reading the FI documents that are directly under the bank statement. In this case, the relationship between actual line and information line(s) is no longer as immediate as for the derivation from the bank statement information:
The report does not search for the information via the technical origin/usage of incoming/outgoing payments in the actual line of the FI document nor in the offsetting line for the bank clearing account, instead it searches in the vendor and customer lines of the additional accounting documents cleared using the actual document.

A simple example: The payment program pays a vendor invoice and in the process generates a payment file for the bank and a payment document:

25  Vendor            1000
50  Bank clearing    -1000
The bank transfers the amount and sends the bank statement to us as a confirmation. This is imported into the SAP System and generates a document here:

40  Bank clearing    1000
50  Bank             -1000
This clears the document on the bank clearing account from the payment program. The basic concept behind the assignment program is that in line:

25  Vendor            1000

there is information on the liquidity item of the actual line (50 Bank). In this sense, the vendor line is an information line for the actual line.

From this information line, a liquidity item can be derived as follows.

  • Default item, that was assigned to the G/L account (BSEG-HKONT) of the information line (Transaction FLQC7 or FLQINFACC, see below).
  • Item which was determined by a query (with LQORIG = C). Structures BSEG and BKPF for the information line belong to these queries, as well as LFA1 or KNA1 for the master record of the vendor or customer in this line. This master is most interesting because of the industry key. As described above, the query must be included in the query sequence. This is assigned to the program as parameters.
  • User exit function with model FLQ_SAMPLE_ASSIGN_FI, also to be assigned as a parameter.

The sequence of the derivation is as follows: If there is a liquidity item for the general ledger account of the information line, this is noted. If the query sequence returns a positive result (the rule is again: the first query wins), then the account item is rejected and replaced by the item of the query. The default item at the account therefore acts as a last query. The user exit function has the last word again.

Whether or not the program analyzes a document line item as an information line depends mostly on the G/L account in the line. More specifically, the following is valid.

  • Lines with account type vendor or customer are always information lines.
  • Lines on P+L accounts always are information lines.
  • All lines with G/L accounts, which were declared explicitly as information accounts, are information lines. In Customizing FLQC13 (FLQASSET-XINFO_APPL), it is defined whether or not this declaration occurs in Customizing (FLQC7, table FLQACC_INFO) or in the application (FLQINFACC with table FLQACC_INFO_APP). In Customizing Transaction FLQC7, every account must be entered separately; in the application Transaction FLQINFACC, intervals are possible. As for the additional actual-accounts (FLQC4), the entries are per chart of accounts with the option of specialization for a company code. Furthermore, the default liquidity item for the account can be specified here, therefore it may be useful to enter also those kinds of accounts here that are already information accounts implicitly, such as P+L accounts. For instance, material and creation accounts are typically the kind of accounts that are not automatically information-accounts and therefore are to be entered here.

The program again uses two loops: An external one on the paying company code with authorization and locking. For each paying company code, the line item tables FLQITEMBS and FLQITEMFI are read there according to the additional conditions and the affected actual lines are collected. The inner loop is on these actual lines; for each one, the following steps are carried out:

First the complete actual document is imported; its lines are classified in:

    • Actual lines (at least one is there).
    • Information lines (see above) with liquidity item
    • Other cleared lines (such as on bank clearing account)
    • Other open lines and potential information lines without liquidity item.

If no other cleared lines are found, then the evaluation explained below starts for this document. However, there are typically still cleared lines in the document (bank clearing) that are neither actual lines nor information lines. In this case, the program starts a recursion that only stops when there are no more cleared lines found in a step or if the program terminates the information search for this actual line item due to a hard-coded recursion limit (SAP Note 585540).
A recursion step proceeds as follows: All the documents included in the clearing are imported; those documents already known from the previous step are rejected. For newly found documents, proceed as follows:
The offsetting lines of the lines included in the current clearing are taken and classified into:

    • New, cleared lines. If no more are found, then the recursion is ended.
    • Actual lines.
    • Information lines with a liquidity item.
    • Other open lines and potential information lines without any liquidity items.

The actual lines, information lines, and additional lines of every step are gathered.

When the recursion is complete, then the program generates three pools with affiliated lines for the initial actual line:

    • Actual lines
    • Information lines with a liquidity item
    • Other open lines and potential information lines without any liquidity items.

An example with two documents
50  Bank            -1000
40  Bank clearing    1000        and

50  Bank clearing    -1000
25  Vendor            400
25  Vendor             600
Here the program reads the actual document first:
50  Bank            -1000
40  Bank clearing     1000
With the clearing information in the bank clearing line, it finds the second document:
50  Bank clearing    -1000
25  Vendor            400
25  Vendor             600
The offsetting lines for the bank clearing line are analyzed, and thus the three pools are at the end:
Actual: One document line item (50 Bank -1000)
Information: Vendor lines (400, 600) with liquidity item (if derivation was successful)
Additional: Vendor lines (400, 600) without any liquidity items (if not)

The straightforward example that is absolutely desirable is when, as indicated in the example, the actual lines pool contains exactly one object. This one actual line gets its new liquidity items as follows:
The liquidity items from the information lines are gathered with amounts. If the information total amount is greater than or equal to the actual amount, then a proportional assignment of the liquidity items is made according to amount (in transaction currency). That is the case in the example if the program can derive a liquidity item from both vendor lines.
If the information total amount is smaller than the actual amount (in the example: only one vendor line returns a liquidity item, the other one does not), then the following distinction must be made: If the flag is set in Customizing (FLQC13, settings for FI mechanisms) for using partial information (FLQASSET-XPARTIAL), then the actual amount is split into the information amount (liquidity items from information lines) and the rest. The rest remains on the old liquidity item (such as the default item for outgoing/incoming payments).
If this switch is not set in Customizing, the program issues error 8 (information amount is not enough) and no new assignment can be carried out.
If there is not any information line, no liquidity item can be assigned, the program issues the error 0 (incomplete document chain). That may be the case for a bank to bank clearing document for which the second line is not cleared yet. Or as in the example, if neither vendor line returns any liquidity item and is therefore in the third pool for the additional lines.

If the actual lines pool contains more than one line, then this is the case of N:M. In this case, the program found additional actual lines that are linked via clearing (for bank clearing accounts) with the actual line with which the program is started.
In particular, the difficulty here is that the program is to assign only the current actual line; strictly speaking the information gathered, however, applies only to all linked actual lines together. Thus the following, simple heuristic is implemented: Already during the recursion, the program checks whether or not one unique (amount) information line can be found for the current actual line. If so, the recursion is cancelled prematurely and a 1:1 assignment occurs, in other words, all other actual lines and other lines are ignored.
If no partner can be found, the recursion runs to the end. If the information pool is still empty, then the current actual line goes to the bank/transfer item from Customizing which corresponds to its sign. For instance, that is the case if money is transferred from one bank account to another with these postings:
           40 Bank1  -  50 Bank clearing
50 Bank2  -  40 Bank clearing

In general, information document line items are found, however. In this case, you have to distinguish between: If the switch for the special treatment of the N:M case (FLQASSET-XNM_REL) is not set in Customizing (FLQC13, settings for the FI mechanisms), the program issues error 2 (N:M relationship).
On the other hand, if you activate the switch, the program takes the actual line with the largest amount as representative for N linked actual lines and assigns the entire information to it. The other actual lines and a correction record for the representative go to the dummy items defined in FLQC13. An example for that is outlined in SAP Note 558167.
End users mostly do not like this technical separation into a representative and the rest (for dummy items), however, it is a consequence of the missing information caused by the mass clearing. By using two user exit functions (to be entered in Customizing FLQC13):
           For document reduction with sample: FLQ_SAMPLE_REDUCE_DOC
For the reduction of the clearing activities in the first step with sample: FLQ_SAMPLE_REDUCE_1CL

you can try to break these kinds of large activities heuristically into controllable parts. If successful, this not only improves the quality of the assignment, but it also improves the performance. However, it is better if the clearing occurs for bank clearing accounts in such a way that the document chains defined implicitly remain slim. You can find information on using the reduction modules in a comment within the source code of the sample modules.
If program RFLQ_ASSIGN_FI can convert a document, then it generates new entries in table FLQITEMBS or FLQITEMFI (with LQORIG = C); the totals are adjusted.

The third and last assignment program discussed in detail is RFLQ_ASSIGN_REX (Transaction FLQAD). Here two steps run internally for each actual document line item:
In a first step, a liquidity item assignment occurs as in RFLQ_ASSIGN_FI (FLQAC); however, the result is not written on the database but noted in the program. Furthermore, the program also notes the information lines that led to the individual liquidity items.
Two checks are carried out for every liquidity item determined in the first step.

  • Is the liquidity item a buffer item for this assignment?  On the selection screen of FLQAD, the definition is made on which items are to be considered buffer items. If this is not the case, then there is no second step for this item. If this is the case, the next check occurs:
  • Are the information lines, which led to this liquidity item, on continuing information accounts? SAP Note 614240 contains more details on continuing information accounts; the reconciliation accounts for customers and vendors (except for down payment) are implicitly continuing accounts; G/L accounts (clearing accounts) can be selected as continuing accounts in the information account maintenance (FLQC7 or FLQINFACC).

If both checks are successful, the door is open for the second step. Then a recursion mechanism - similar to the one in the first step - continues on from these information lines (in the clearing) via the offsetting lines until the lines for the second evaluation step are found (see SAP Note 614240 for criteria). The original documents may be changed in the process:

  • The elimination of the value-added tax lines is hard coded; their amounts are added to both the expense and revenue lines with the same tax code.
  • In the GR/IR lines of the logistics invoice, the program replaces the GR/IR account with the order account as an option in Customizing (FLQC13). The background is that the GR/IR account is a relatively meaningless clearing account; on the other hand, the account (material or costs) from the purchase order may often return the correct liquidity item.
  • Self-defined changes are possible via exits. (Calculation exit in FLQC13 with sample FLQ_SAMPLE_MODIFY_INV; in PI2003 only via modification: SAP Note 666327).

It is also possible to reduce large clearing activities via exit function (FLQC13); the sample function module is FLQ_SAMPLE_REDUCE_2CL. The evaluation in the second step again uses the default item for the G/L account, a query sequence (type D) and an assignment exit with sample function FLQ_SAMPLE_ASSIGN_REX. This results in two pools:

  • lines for which one liquidity item could be derived.
  • lines for which this was not the case.

The totals are calculated from both pools and are compared with the amount from the first assignment for this buffer item. For the final assignment, the rules are:
The sign of first step is not equal to the sign of the information total: The liquidity item from the first step remains intact; there is no new assignment.
The sign of the first step is equal to the sign of the information total: Proportional replacement; if the non-information total has the same sign, then it is used for the correction.

Example: The buffer item from the first step is AAA with amount 1000.
In the second step, this is found: BBB with amount 200 and also non-information with amount 800.
This deficit is taken into account, and thus the entire amount 1000 does not go to BBB but only 200. The rest remains on item AAA.
The buffer item name for the item (in this case AAA) from the first step was selected because of this behavior: In many cases, it is replaced completely in the second step; sometimes (as in the example), however, also only partially.
If program RFLQ_ASSIGN_FI can convert a document, it generates new entries in table FLQITEMBS or FLQITEMFI (with LQORIG = D); the totals are adjusted.

Manual assignment of liquidity items
Here you have two options - generally speaking, the one is for individual amounts and the other for lump sum amounts:
Using Transaction FLQAM, you can assign new liquidity items to a specific payment document for which there are already line items (FLQITEMBS or FLQITEMFI). The line items generated in this way receive the assignment origin symbol (LQORIG) M. You can also access this transaction via the line item list; there you can use it, for instance, after the automatic assignment runs to assign better items to documents which are still on a dummy item.
Separated from specific actual documents from accounting, you can move lump sum amounts between various liquidity items (balance zero) by using transfer posting transaction (FLQT1). The system generates separate original documents via this transaction (document number range in the company code according to the entry in FLQC4); the table for that is FLQITEMMA . These go into the totals table with FLQSUM-LQTYPE = M. These transfer postings are useful, for example, if the information in your system only allows the automatic assignment programs to make a rough item assignment which you can augment with information from other sources.

Related Notes
819269Amounts on buffer item in spite of clearing
731562Liquidity calculation: Enhancements in plug-in 2004.1
666327Extended reduction exit for invoices
623255Liquidity calculation: Enhancements in plug-in 2003.1
614240FLQAD: Rules for the second step
585540Error code 1 for long payment chains
558167Liquidity calculation: Enhancements in plug-in 2002.2
519465Liquidity calculation: enhancements in plug-in 2002.1
497118Modification to change table fields used in Queries
412605Implementation of the liquidity calculation