Purpose

The purpose of this page is to provide general information about actual settlement.

Overview

This document contains general information about transaction codes and reports of actual settlement and the general procedure of actual settlement on business transaction point of view (actual costs, WIP, variances).

1. Transactions for Actual Settlement

These are the most relevant transactions for the actual settlement of different CO objects:

2. Reports for Actual Settlement

You can also call up each collective processing in the background, while in the transaction. This triggers off a background report, which you start with the SE38 transaction.

From 4.0 there is a background report for each collective settlement: RKO7XXXX (XXXX= transaction name), e.g. RKO7CO88 for settlement of production orders, process orders, product cost collectors. SAP provides complete support for the use of these reports. They provide the same user interface as the online transactions.

3. Business Transactions for Actual Settlement

Settlement has many uses in business that are reflected by the settlement transactions. For actual settlement transactions, the following business transactions may be relevant:

• Settlement of actual costs
• Settlement of work in progress
• Settlement of variances
• Settlement of cost of sales/sales revenues 

Settlement transactions are determined in routine VRGNG_GET.

3.1 Settlement of Actual Costs

The first type of settlement is the classical settlement of actual costs. This is the settlement of actual costs that were incurred on the sender. These are settled to the receiver specified in the settlement rule.

KOAO is the business transaction for actual settlement. If it is selected, then the actual costs of the sender are settled to the receiver specified by the settlement rule. This means that the debits from the COSS and COSP tables with value type "04" are read.

3.2 Settlement of Work in Progress

Senders that have a results analysis key and that cannot carry revenues can build up work in process. For example a production order with 100% FUL rules for settlement to material, or a WIP element.

The business significance of the WIP calculation and the following settlement is to post WIP to Financial Accounting and to Profit Center Accounting. Material consumption is posted during the period to the objects, which means that costs from balance sheet accounts are posted to P&L accounts. In the SAP System, WIP must be calculated at the end of the period and is posted with the settlement. If an order has been completed, that is, finally delivered or technically completed, then the WIP is broken down again, and the actual costs of the object are settled to the receiver specified by the settlement rule.

To settle WIP, the following is required:

• The sender has a results analysis key, and WIP has already been calculated
• In Customizing for the results analysis version (transaction OKG3), the "Transfer to Financial Accounting" indicator must be set.
• In Customizing for results analysis, the posting rules for all results analysis categories that are relevant to settlement must be stored (transaction OKG8)

Caution: You can only calculate and settle WIP for orders that do not have a revenue indicator or settlement rule to material if the "WIP on dependent orders" indicator has been set in the results analysis version (transaction OKG3).

KOAW is the business transaction for settling data of WIP calculation or results analysis. If this is selected it is read from the COSB table with value type “32”. If the sender carries revenues, then only this data is interpreted during the actual settlement, and the COSS and COSP tables are not read. 

3.3 Settlement of Variances

Production orders, process orders, product cost collectors and cost objects can calculate variances and scrap using variance calculation.

The business significance of this is to explain the variances between target and actual costs on the objects in terms of categories (input quantity variances, input price variances and so on). The settlement posts these variance categories to different value fields in CO-PA. When a product is sold, the revenues and the standard costs for the material are transferred to CO-PA. The variances can now be periodically transferred to CO-PA using settlement.

The variances for objects that have FUL settlement are only calculated once the object has been finally delivered or is technically completed. The variances for objects that have PER settlement are calculated periodically.

When variances are settled, they are settled to costing-based profitability analysis as variance categories. This type of settlement is not to be confused with settlement of price differences to FI, which takes place at the same time, but independently of the variance settlement. There is often confusion with this, as the total of the price differences is of course the same as that of the variance total. The settlement to FI is a pure actual cost settlement to material. The settlement to CO-PA is a settlement of the variance categories (determined in the variance calculation) to the different value fields in CO-PA.

SAP note 35507 contains the prerequisites for variance settlement.

KOAV is the business transaction for settlement of variances to profitability analysis for production orders. If this business transaction is selected, then the variance data is selected from table COSB with value type "31", scrap is "30". The settlement rule for variances is generated by the system during the first variance settlement.

3.4 Settlement of Cost of Sales/Sales Revenue

Senders that have results analysis keys and revenues (sales orders, billing elements and orders with revenue indicators) are part of the results analysis, and settle the resulting data.

The business significance of the results analysis is to smooth costs and revenues during the periods and to provide correct period results for profitability analysis. Example: In a customer project, only costs are incurred during the first few periods, and in the last period, revenue is posted. If you would post the costs and revenues to CO-PA like they occured, then the initial period result would look very poor, and at the end very good. The period result does not provide any clues to the success of the period. Therefore, you use results analysis to try to distribute the costs and revenues over the runtime of the project, and to post them accordingly, providing a different view of the costs. It calls the calculated costs "cost of sales", and the calculated revenues "sales revenue". The costs incurred that are not yet cost of sales are displayed as WIP and posted to FI.

In this case (even after changing the status to technically completed), settlement does not post the actual costs, but always the cost of sales, the sales revenue and the reserves for imminent loss. The corresponding categories cannot be changed by the user, which makes sure that FI and CO-PA are reconciled (see SAP note 441994).

Results analysis has another special feature: Summarization of costs in hierarchies. For example, if you have a project in which the top WBS element is a billing element with a results analysis key, then results analysis summarizes the costs for the whole project on the top WBS element. This means that the dependent objects do not need to be settled at all. The settlement of the top WBS element is sufficient to settle the costs of the entire project (see SAP note 76354).

4. Tables updated during Actual Settlement

We recommend to analse the CO objects with report RKACSHOW. See documentation in SAP note 28145.

• AUAK     Document Header for Settlement Document*
• COSPD  Settled values from COSP (Cost Totals for External Postings)
• COSSD  Settled values from COSS (Cost Totals for Internal Postings)
• COSBD  Settled values from COSB (Total Variances/Results Analyses)

The system updates all tables during actual settlement if debits exist in the corresponding tables. A credit line in COSSA/COSPA with BEKNZ (Debit/credit indicator) =  “A” (Special: Sender credit from settlement) is made. COSBA is filled with WIP data (value type 32) during WIP calculation and filled with variances (value type 32) during variance calculation. To get the WIP values and variances updated in COSBD one has to execute settlement.

The settlement document consists of more than one table:

• AUAK    Document header, which contains global information, such as document number, sender, settlement period etc.
• AUAA    Receiver segment. The AUAA contains the sender and receiver for the settlement in routine SENDTAB_CHECK  and RECEIVER_CHECK
• AUAV    settlement transactions used (determined in routine VRGNG_GET)
• AUAS    Totals Segment. The AUAS contains the settled values from this settlement run. The system updates a row for each receiver and original debit totals record. The KEY01 field contains the database key for this record. The PLFNR field displays the receiver (= the record from AUAA, whose sequential number is the same as the PLFNR). If the AUAS-PLFNR field is blank, then the system does not settle to a receiver (currently only for the WIP transfer to FI).
• AUAW   Accounts for the WIP settlement. The AUAW contains the accounts to which the WIP was settled. One row is updated for each original debit total record in the COSB table and each account pair. The AUAW table is filled in the K_SETTLEMENT_CHECK function module according to the posting rules in results analysis Customizing. When a WIP settlement is reversed, the accounts in the AUAW table are used, and the account determination is not called up again. This ensures that the accounts in the reversal are the same as those in the original settlement, should the posting rules be changed.

*Regarding table AUAK it contains some interesting fields regarding dates:

• BUDAT: Posting date. The settlement document has the last day of the posting period as posting date.
• CPUDT: Date Document Was Created. This is the date when the actual settlement was executed.
• WSDAT: Value Date for Currency Translation. This date is the one relevant for the currency translation, which matches the Posting date.