Ansicht
Dokumentation
RFLQ_ASSIGN_INV - Liquidity Calculation: Delta Assignm. Based on Invoices (Cust./Vendor)
General Material Data TXBHW - Original Tax Base Amount in Local CurrencyThis documentation is copyright by SAP AG.
Purpose
This program runs through the actual documents in the liquidity calculation, with the exception of manual transfer postings. It attempts to determine the liquidity item of the document on the basis of information in the line items of accounting documents. This is done in two steps:
The first step is identical to the "simple" derivation mechanism FLQAC. The program evaluates the customer and vendor line items in payment documents, as well as payment-related G/L account line items that have been declared as information carriers (FLQC7).
If the first step derives a buffer liquidity item defined using the Select option, the second step is applied. In this case, the program works its way down the accounting system until it finds customer or vendor line items in documents with the specified document type (typically invoices). These are then evaluated. If the result is positive, the buffer liquidity item derived in the first step is replaced. If not, the buffer liquidity item remains unchanged.
Integration
On the selection screen you specify the actual documents to be processed.
Features
The procedure for deriving the liquidity items to be assigned to the actual line item begins as in FLQAC:
First, the program reads the complete actual document. Typically, this comprises:
Line item: Bank account (actual)
Line item: Bank clearing account
If this line item has already been cleared in accounting, the program continues to search for other
FI documents involved in the clearing transaction. These are then imported. In the simplest scenario, it finds 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 is evaluated using the first query sequence and the first user exit. If the program finds a liquidity item, and this item is a buffer item, the process continues as follows:
If the vendor line item has also been cleared, the program again searches for and imports all the documents
involved in the clearing transaction. In the simplest scenario, it finds an additional invoice document 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 the liquidity item is the vendor line item in the invoice. Invoices are usually entered manually, and potentially contain more information than the corresponding vendor line item in the cleared payment document.
Exact procedure: The program checks the line item (field values of structures BKPF and BSEG) against the first query of the sequence defined in the report for the second step. If all the conditions of this query apply, it makes a note of the assigned liquidity item. If not, it checks the line item against the next query, and so on. You also have the option of programming your own derivation logic in a user exit function (interface according to 'FLQ_SAMPLE_ASSIGN_INV'). This may take priority over the derivation result from the queries.
The liquidity items derived from the "successful" information line items then replace the buffer liquidity items from the first step.
Activities
You should only set up this program if the simple FLQAC mechanism is in place.
If the resulting assignments are unsatisfactory, you should first use program RFLQ_INVCHAIN to display the information line items and other line items found for an actual line item. You can use this as a starting 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 described above:
| 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 item MATERIAL on the basis of the vendor line item of the payment document. This is exactly the same result as the simple mechanism FLQAC would have 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 the second step, and the mechanism works its way down to the vendor line items 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 as relevant, no further evaluations are carried out; the mechanism is unable to derive a new liquidity item.
If, for example, V2 has been declared as relevant, the mechanism evaluates the second line item and the corresponding document header. It may be possible to derive the liquidity item INVESTMENT solely on the basis of the document type V2. If we assume that we were unable to derive a liquidity item from the other invoice (V1), or that the liquidity item derived on the basis of this invoice is the same as the buffer 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)
General Material Data RFUMSV00 - Advance Return for Tax on Sales/Purchases
This documentation is copyright by SAP AG.
Length: 7077 Date: 20240520 Time: 141501 sap01-206 ( 136 ms )
