Methodical Recommendations 

Use

The tax transfer-posting program processes only the accounts posted in line with the tax scheme set-up.

Conclusion: For document posting, it is recommended to set up so called validations in order to avoid posting with incorrect combination “account/tax code“ by the user.

Tax transfer-posting program is always based on the tax accounts, where it tracks open debit items before and up to the date indicated in the selection screen parameters – key-dated open items. From these tax items, the program passes to respective documents, looks for vendor specific credit items and tracks them being cleared or not, or, if need be, their links to other documents.

Conclusion:

·        Credit items are not tracked on the tax accounts which means that tax credit memos must be posted as indicated in the example (business transaction description).

·        Tax can be transfer-posted only for documents including vendor credit items. It follows that vendor invoices with tax items must be posted in a subsidiary ledger.

·        Credit vendor items must either be cleared or there must be another vendor item referring to them through BSEG-REBZG field. Counterpart account posting means neither clearing nor document inter-linking, therefore does not have any affect on transfer-posting.

·        For all vendor check accounts it is recommended to set up a field status displaying BSEG-REBZG field (Reference to invoice).

Once the vendor item has been cleared, the program tracks the clearing document to find out whether it includes a bank interim account according to IDSL_GUC table. If this is the case, it passes to the bank interim account and checks whether the item has been cleared. Only if the item has also been cleared here and the cleared document posting date is smaller than the upper limit specified in the selection screen parameters, the tax will be transfer-posted.

Conclusion:

·        Clearing of subsidiary ledger accounts as well as that of interim accounts must be tracked continuously. Whenever possible, clearing must be carried out simultaneously with posting or subsequently, using the automatic clearing program. Only items constituting a single transaction can be marked at a time, i.e. 1:1 clearing. If this rule is not observed it cannot be guaranteed for the program to reach the correct bank account or document, which in turn might result in transfer-posting errors.

·        While tracking the clearing documents at a time, the date of their clearing is not substantial. It is rather important to have the documents cleared before starting the program.

The program tracks the reimbursement amounts for a given invoice and compares them with the total invoice tax. The tax will be transfer-posted only if payments the reach the sum of taxes in the invoice for all tax codes.

Conclusion:

·        Several tax codes can be specified in one accounting document, however, the total sum is always tracked.

·        On the vendor side, either “**“ or any of the tax codes used and belonging to the group can be used.

Transfer-posting will also take place in case the invoice is found not to have been cleared, but only linked to debit items – for example, a transfer-posted down payment or an incomplete reimbursement effected in the form of a partial payment (reference to invoice in the field BSEG-REBZG).

Conclusion:

·        As the linkage of the invoice to the payment via BSEG-REBZG has been used often in practice, the algorithm of the program treats this method as equivalent to clearing. It means, if the payment has the field BSEG-REBZG filled in, it must not be used towards different invoice as it is filled in the field BSEG-REBZG.

It means that if a payment was allocated to the invoice 1 via BSEG-REBZG and this payment was subsequently cleared with the invoice 2, the program RFIDSL00 does not accept the payment towards the invoice 2, as it was already allocated to the invoice 1. The program RFIDSL00 in mode "Account Analysis" returns an error. In such a case, it is necessary to cancel settlement of the invoice 2 and to settle the payment with the invoice 1 or, in case the payment should really belong to the invoice 2, it is necessary to correct the value of BSEG-REBZG.

Similarly, if e.g. an down payment was already made at a high amount and subsequently its part should be used for the invoice 1, whereas by mistake the entire amount of the down payment is allocated to the invoice 1, the down payment transfer-posted this way shall not have to be used for the invoice 2. It is necessary to cancel the posting and to carry out a partial posting, so that the remaining part of the down payment could be repeatedly used to be posted to the invoice 2.

·        To provide for a simple checking of the purchase ledger it is necessary to adjust the statuses of control accounts and accounting keys, so that the box BSEG-REBZG was visible on the screen and modifiable in case of necessity, it is recommended to prepare display forms upon displaying individual items and open items on the account, in order this box was shown in some column of the listing.

Unambiguous and faultless allocation of payments can be assured only in case any payment is unambiguously allocated to a single invoice, either using the field BSEG-REBZG or by clearing, where only a single invoice enters the clearing at a time (and one or several payments).

Conclusion:

·        Due to this, it is inevitable to assure in terms of organization, so that the documents unrelated to each other were not settled together at a time. In case of failing to adhere to this rule, the program for tax transfer-posting runs based on built-in algorithm of payment allocation, which can result in „erroneous“ payment allocation and due to this to a wrong allocation into the period (i.e. the program will return another payment to the invoice as it is the case in the original document, or it returns a single payment to several invoices).

In the system, from the technical point of view it is not possible to assure that the user could not clear the cases being not related to each other at a time, there is only an option to load the so-called validation that can operate e.g. in the way it was not possible to clear the items with unequal values in the field  „allocation“. Introduction of such validations depends on the way of defining of the accounting procedure, i.e. with what values the individual boxes are filled in.

·        In case of the clearing of several unidentified payments, program algorithm will not accept any of them. The program RFIDSL00 in mode "Account Analysis" returns an error. It will occur only in case the program identifies the „payment“, i.e. if the counter-account is in the table IDSL_GUC (i.e. if it is only a residual item after the payment, identification of the payment does not occur).

An Example of Incorrect Posting

On the vendor, it is necessary to settle the documents 1 and 3 separately, 2 and 4 separately; in the bank interim account - the documents 3 and 5 separately, 4 and 6 separately (in the example, all items are cleared together in the bank interim account). On the other hand, there could happen that an incorrect allocation of a payment occurs , e.g. the payment 6 will be used for the document 1 as well as for the document 2, as it is the latest one, while its amount is sufficient to cover VAT of both the invoices.

In the program RFIDSL00 this case does not result in transfer-posting of VAT of both invoices. The program RFIDSL00 in mode "Account Analysis" returns an error. It is possible to jointly perform only a vendor clearing, provided there is a linkage to the invoice through the field BSEG-REBZG in appropriate items of payment documents.

In case of documents posted in foreign currencies, recalculation of correlated documents occurs, using the exchange rate from the exchange-rate table for the date of exchange-rate recalculation of the initial invoice.

Conclusion:

·        When posting invoices (tax credit memos, tax debit memos, ...), it is inevitable to use the correct date of exchange-rate recalculation as well as the exchange rates from the exchange-rate table. The program checks these data. In the case the data of the heading are not matching the exchange-rate table or recalculations of a supplier item are not matching, any tax transfer-posting will not occur.

·        In case the correlated documents are posted in various currencies, a currency triple recalculation will occur upon which even the smallest exchange-rate deviation may affect the course of processing - it is recommended to verify these cases upon posting incomplete payments.

In case the document header currency is SKK  the program checks whether the values of the fields DMBTR and WRBTR are equal (the amounts in the company code currency and in the transaction currency). In case the above-mentioned amounts are not equal, any VAT transfer-posting will not occur.

Conclusion: Documents with a different amount of company code and transaction currency for SKK occur e.g. upon automatic generation of exchange-rate differences, in case e.g. the invoice is settled in a foreign currency with a payment in the domestic currency, while clearing is made in SKK and the values in SKK are equal. This procedure is not in accord with Slovak legislation, being caused by incorrectly setting the company code or separate accounts in the chart of accounts (within global parameters for company code it should be set, so as not to calculate exchange-rate differences in the corporate currency - the field XSLTA).

If all conditions are met, the tax will be transfer-posted from the original tax account to the target account and the original account will be cleared. Consequently, it is guaranteed that any multiple inclusion of the tax into a tax declaration is eliminated.