SAP Program RFLQ_ASSIGN_REX - Liquidity Calculation: Delta Assignment Based on Invoices (Outg./Inc.)

Purpose
This program goes 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).
The second step is applied if the result of the first step belongs toone of the buffer liquidity items defined using the Select option. Inthis case, the program looks more closely at the accounting recordsuntil it finds line items on P/L accounts or on accounts defined asinformation carriers. 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
You specify the range of actual documents to be processed on theselection screen.

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 query sequence and the first user exit. If theprogram 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 invoice document:
Line item: Vendor
Line item: Expenses (Information for 2nd step)
Line item: Value-added tax
The expense account often contains information about the reason for thepayment. If the expense account has been defined as an informationcarrier (FLQC7), or is managed as a P/L account in the chart ofaccounts (SKA1-XBILK is initial), the program looks for informationrelating to the liquidity item in the expense line item of the invoice.You can also evaluate the header data of an invoice. As for the othermechanism, you can either take the default liquidity item from theaccount, or derive the liquidity item using a query sequence or userexit function (interface as for 'FLQ_SAMPLE_ASSIGN_REX'). The line itemfor value-added tax is not evaluated. Instead, this amount is added tothe expense line item in a "virtual" calculation (gross tax principlefor liquidity calculation).
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_REXCHAIN to display the information and other line itemsfound for an actual line item. If necessary, you can then revise thequery sequences and user exits.

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-
Line item: Expenses
Line item: Vendor,,Amount 60-
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 the liquidity item MATERIAL is a buffer liquidity item, the programcontinues with the second step and the program works its way down tothe two offsetting line items in the invoices.
Line item: Expenses,,Amount 40-
Line item: Investment,,Amount 60-
If, for example, the investment line item has been declared as aninformation carrier with the default liquidity item INVESTMENT, andnothing has been declared for the other line item (or just MATERIAL asin the buffer), we get the following assignment result:
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)

980933Document chains with down payments in the forecast
974581Evaluation of document chains with down payments
944529Scaling of the contribution of partial payments
878970Behavior at: Evaluate intermediate status (FLQC13)
823956Document volume for the FLQAD assignment
802113Performance in the second step of FLQAD
786690Reduction exit for clearing when not balanced
753428Incorrect assignment w/ N:M treatment
666327Extended reduction exit for invoices
721326FLQAD: Too many items involved in the second step
519465Liquidity calculation: enhancements in plug-in 2002.1
694168Evaluation mechanism does not go into detail
685341Intermediate statuses for assignment of liquidity item
626163N:M clusters are not balanced
614240FLQAD: Rules for the second step
571225FLQAD:Too many documents are read in the second step
576539Assignment error for cash discount net procedure
558167Liquidity calculation: Enhancements in plug-in 2002.2
554679Recursion surplus in assignment mechanisms
531018Display of down payments and final settlement