1 General Introduction to Settlement
1.1 The General Purpose of Settlement
Settlement is always used for cost accounting on jobs. Typical jobs include marketing events such as trade fairs or the completion of a product for a special customer. In these situations, the costs and any revenues are saved temporarily on a CO object such as an order or a WBS element before being finally allocated. Settlement is used for this allocation.
1.2 Transactions and Reports
The following transactions are used in settlement:
1.2.1 Actual Settlement
KO88: Individual order settlement (you can process any order category) KO8G: Collective settlement of internal orders CO88: Settlement of production orders, process orders, and production cost collectors CJ88: Individual project settlement CJ8G: Collective project settlement KK88: Individual settlement of cost objects KK89: Collective settlement of cost objects KK87: Individual settlement of production cost collectors VA88: Collective settlement of sales orders FO8C: Individual settlement of real estate (from 4.0) FO3C: Collective settlement of real estate (from 4.0)
1.2.2 Retirement Investment
KO8A: (Not contained in the menu, see note no. 23814): Investment order - retirement CJ8A: (Not contained in the menu, see note no. 23814): WBS investments - retirement
1.2.3 Planned Settlement and Plan Data Transfer
KO9E: Plan individual settlement of internal orders KO9G: Plan collective settlement of internal orders CJ9E: Plan individual settlement of projects CJ9G: Plan collective settlement of projects CJ7E: Plan data transfer of projects (individual processing) CJ7G: Plan data transfer of projects (collective processing
1.2.4 Reports for 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.
In 3.0 this report is called RKOO7400. If you want to use it see note no. 68279. SAP does not provide complete support for the use of this report.
From 4.0 there is a background report for each collective settlement: RKO7 (...= transaction name), e.g. RKO7KO8G for settlement of internal orders. SAP provides complete support for the use of these reports. They provide the same user interface as the online transactions.
1.3 Settlement Rule
In the settlement rule, you specify the receivers to which the costs are to be distributed.
The settlement contains the settlement parameters as well as the distribution rules.
Distribution rules contain the settlement receivers, settlement shares and settlement type. They can contain a source assignment. You always create a distribution rule for a view.
1.3.1 Settlement Receivers
More or less all CO objects are allowed as receivers of a distribution rule, and the external G/L account and fixed asset receivers. In addition, production orders have Material as an external receiver. External means that the settlement not only occurs in CO, but also triggers postings in Financial Accounting.
You specify whether a receiver category can be entered in a distribution rule or not in the settlement profile (see: Settlement Customizing).
During planned settlement, only the following receivers are possible: in 3.0 - cost centers, in 4.0 - cost centers and business processes, from 4.5 cost centers, business processes, plan-integrated orders, WBS elements and profitability segments (see also: note no. 113629).
1.3.2 Distribution Rules Using Percentages, Equivalence Numbers, and Amounts
Settlement is made depending on the settlement rule created. You can create distribution rules with either percentages, equivalence numbers, or amounts.
In planned settlement, you cannot use amounts for settling (see also note no. 113629).
In the settlement profile, you need to specify whether fields (such as for the amount in the rule) are ready for input (see Settlement Customizing).
Note no. 330001 describes how amount settlement works, providing detailed examples. The main theory of amount settlement is that the amount to be settled (from the distribution rule) is proportionately deducted from incurred costs. The rest is distributed to the receivers of the percentage rules.
The amount settlement does not take place if there are no costs that need to be settled. The customer may find the tip in note no. 50249 useful at this stage.
1.3.3 PER/FUL/PRE Rules
You need to assign a settlement type (PER for periodic settlement, and FUL for full settlement) to each distribution rule.
When you manually create a settlement rule, the system defaults the settlement types depending on the receiver category: FUL for G/L accounts and fixed assets and PER for all other receivers. The default value cannot be entered without making modifications.
You can only create FUL and PRE rules for an investment measure (see Investment Measures).
You can create PER and FUL rules at the same time. For the effects of these rules, and the access sequence, see note 27911, and the F1 help for the "Processing type" field, in the initial screen for settlement. The following is important:
The PER rules only include the costs from the settlement period during settlement, whereas the FUL rules also include the values from the previous period that have not yet been settled.
The PER rules mean that during activity inputs, the information is transferred via the activity provider to the settlement receiver, whereas the FUL settlement does not do this.
Therefore it is often useful for an order to have two rules. One with 100% PER to the receiver cost center, and one with 100% FUL to the receiver cost center. This means that all costs from the settlement period are settled using the PER rule, and the activity information for these costs are transferred thus to the receiver cost center. On the other hand, the FUL rule ensures that any subsequent costs that were settled to the past are also settled.
Planned settlement only allows PER rules (see also: note no. 113629)
1.3.4 Settlement View
The settlement rule is always created with reference to a special view. The different views enable you to have different settlement rules for each business transaction. The "actual" view is available for all senders. In addition there is the "plan" view for plan-integrated senders, the "variance" view for production orders, the "incoming order data" view for billing elements that have a results analysis key, and the "plan data transfer" view for billing elements that are not plan-integrated.
1.3.5 Settlement Parameters
These are used to control sender settlement. Listed in the settlement parameters
Description (not used)
Settlement profile The default value for the settlement profile is taken from the order type for orders and networks, from the project profile for WBS elements, from the requirements class for sales orders and from the cost object type for general objects. You create the settlement profile in Customizing (see Settlement Customizing).
Allocation structure/PA transfer structure/Source structure The default values for these structures are taken from the settlement profile. You create the structures in Customizing. (see Settlement Customizing).
Hierarchy number Hierarchical settlement is automatically supported during collective settlement. This means that a sender (that is also a receiver during this settlement) is processed according to the object settled to it. This is controlled by the hierarchy number in the settlement parameters. The higher this number, the sooner the sender is processed. The hierarchy number is automatically issued or adapted by the system, and does not need to be entered manually by the user. If however, there should be any inconsistencies with the hierarchy numbers, then you can repair them using the RKSRULE4 report from note no. 71492
1.3.6 Source Assignments
If a sender has a source structure in the settlement parameters (see Settlement Customizing), then you can create settlement rules for each source assignment. This enables costs and revenues to be settled to various receivers separately, for example.
1.3.7 Simple Settlement
In internal orders, you can store a simple settlement rule in the master data for a cost center or general ledger account, with a settlement cost element. You therefore do not need to customize settlement.
1.3.8 Generated Settlement Rules
There are a lot of object types (including production orders and sales orders) where it is not feasible for the user to create a settlement rule manually. For this reason, the system generates the settlement rules automatically at certain times.
The settlement rule for production orders mainly determines the business behavior of the production order. Therefore, the automatically generated rules for production orders cannot be deleted, you can often only change the percentage. If you enter 0%, you can, however, force a different settlement. The following are examples of automatically created distribution rules:
Production order: Settlement rule to material or sales order. The rule is created at the same time as the order.
Production order: Settlement rule for the variances to the profitability segment. The rule is generated during the first variance settlement.
Sales order: Settlement rule to profitability segment. The rule is created at the same time as the sales order.
WBS elements: PS contains "strategies for determination of settlement rules". This means that you can transfer the settlement rule from higher-level WBS elements for example, for network activities or WBS elements. These settlement rules can be changed as required.
WBS elements: Since Release 4.5, PS has its own transaction for generating settlement rules.
Investment measures: Annual rule for an investment measure. The annual rule is created at the same time as the first settlement to the asset under construction, and cannot be changed.
The application that generates the settlement rule is responsible for creating it correctly.
1.4 Settlement Customizing
The following points for customizing settlement are listed in the IMG in the different application menus. You can also use transaction OKOA to access Customizing.
For more information on the structures, see the IMG documentation. This document is only intended to give a short overview on the structures.
1.4.1 Settlement Profile
The settlement profile is automatically determined when you create a sender: for orders from the order type, for projects from the project profile, for networks from the network type, for cost objects from the cost object profile, and for sales orders from the requirements class.
In the settlement profile, you decide on the following settings:
Is the object to be settled? This indicator is particularly useful if the system contains objects that are to be archived despite their balance, for example, old objects that were overlooked for settlement in the past (see also note no. 173909). The indicator can help improve performance when you settle projects, if results analysis is performed at the top level. In this case, the results analysis of the project costs are transferred to the top WBS element. It is not necessary to settle the lower WBS elements to the top WBS element, and this should also be avoided due to performance reasons.
What are the default values from the allocation structure, PA transfer structure and source structure when you create the object?
Which receivers are allowed or must be entered?
Should a 100% validation be made using PER rules?
What type of settlement is allowed (percentage settlement, equivalence numbers, amounts)?
Should variances in production orders and cost objects be settled to costing-based profitability analysis?
1.4.2 Settlement Structure (= Allocation Structure)
The allocation structure is automatically determined when you create a sender from the settlement profile.
The allocation structure specifies which cost element is to be used for settlement, meaning the cost element that is used to write the CO document from the settlement.
To determine the settlement cost element, you group the original cost elements (under which debits are posted to the orders) into settlement assignments. For each assignment, you specify whether the settlement to a certain receiver category is to be made by cost element or with a cost element type.
The settlement structure is always needed if actual costs or plan costs are to be settled. Exceptions are as follows:
Material as receiver: The receiver Material is not dealt with in the allocation structure as the settlement cost element is found using MM account determination during the settlement to Material (see note no. 63339)
Order item as receiver: The order item receiver is not dealt with in the allocation structure as this object can only be a receiver during settlement of co-products, whereby settlement is always made by cost element.
"Light" settlement with the internal order as sender: You specify the settlement cost element in the master data (see: Simple Settlement).
1.4.3 Source Structure
The source structure is automatically determined from the settlement profile when you create a sender.
This specifies which source assignments are defaulted in settlement rule maintenance.
Original cost elements (under which debits are posted to orders) are grouped into source assignments.
This enables you to assign another receiver (depending on the source assignment) when entering a distribution rule. In this way, you can settle costs incurred on a sender to different receivers, depending on the cost element.
The following is an application example: You have an order that you want to settle to a fixed asset. However, you may not activate certain cost elements. These costs are always to be settled to a particular cost center. In this situation, you need to create a source assignment with all costs that cannot be activated, and a settlement rule for settlement to the cost center , as well as a source assignment with the costs that can be activated and the settlement rule for settlement to the fixed asset.
1.4.4 PA Transfer Structure
The PA transfer structure is automatically determined from the settlement profile when you create a sender.
It specifies the value field (in costing-based profitability analysis) to which the settlement is made.
Original cost elements or original cost elements/variance categories or original cost elements/accounting indicators that are used for posting debits to the orders are grouped into assignment lines. Each assignment has a CO-PA value field assigned to it.
Since revenues in CO-Pa are always displayed with reversed plus/minus signs, you must not mix cost elements with revenue elements in an assignment as this creates incorrect results in CO-PA.
You only need the PA transfer structure when you settle to CO-PA.
Note: You need to make assignments according to cost element/variance categories for variances.
1.4.5 Number range for settlement documents
When you make a settlement, a settlement document is written. This is used as the original document for the created CO or FI documents for example.
1.5 Business Transactions for 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 cost of sales/sales revenues
Settlement of work in progress
Settlement of variances
Settlement of orders received (from 4.5)
For planned settlement transactions, the following business transactions may be relevant:
Settlement of planned costs
Settlement of planned cost of sales/planned sales revenues (from 4.5)
For transferring planning data, only the following business transaction is relevant:
Plan data transfer (from 4.5)
The business transactions are individually explained below, with their business significance:
1.5.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.
1.5.2 Settlement of Work in Progress
Senders that have a results analysis key, and that cannot carry revenues can build up work in process. This is providing it is 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 American systems, material consumption is often posted directly to the WIP account. In the SAP System, WIP must be calculated at the end of the period and 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 OKG9), 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 OKG8).
1.5.3 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 were to post the costs and revenues to CO-PA in the form that they are incurred, 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 iminent loss. The corresponding categories can not be changed by the user, which makes sure that FI and CO-PA are reconciled (see Note no. 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 Note no. 76354).
1.5.4 Settlement of Variances
Production orders, process orders, product cost collectors and cost objects can calculate variance 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.
Note no. 35507 contains the prerequisites for variance settlement.
1.5.5 Settlement of Incoming Orders
WBS elements that have a results analysis key and are billing elements, can determine incoming order data. The settlement posts this incoming order to CO-PA.
The business significance of this is to display in CO-PA the value of the sales orders that were already received for a project.
1.5.6 Settlement of Planned Costs
Typical planned settlement is when the planned costs and planned revenues incurred on the sender are settled to the receiver specified in the settlement rule. This business transaction is relevant for all plan-integrated orders and plan-integrated WBS elements.
1.5.7 Settlement of Planned Cost of Sales/Planned Sales Revenues
Similar to the business transaction "settlement of the cost of sales/sales revenue" in actual settlement, there is also the business transaction "Settlement of planned cost of sales/plan sales revenue"
The aim of planned settlement is to settle the planned costs in the same way as the actual costs to enable a comparison of planned and actual values.
This business transaction is always relevant to planned settlement if the "settlement of cost of sales/sales revenue" is relevant in the actual data. Additionally, the sender must be plan-integrated. This means that the business transaction is relevant for all plan-integrated billing elements with results analysis key or all plan-integrated internal orders with results analysis key.
1.5.8 Plan Data Transfer
Projects also have plan data transfer for billing elements that are non-plan integrated and have results analysis keys.
This business transaction is used to transfer the planning data from the WBS element to profitability analysis. This is to support planning, and avoids double entry of planning data on the WBS elements and then again in profitability analysis. The WBS element is not credited, unlike planned settlement of plan-integrated senders.
1.6 Settlement and WIP/Results analysis - a summary
The following shows you what settlement does in which circumstances:
The object has a results analysis key and cannot carry revenues. One of the following conditions applies: the object is a WBS element or it has a FUL rule to material that is >0%, or the object is an order/order item, and in the results analysis version, "WIP on dependent objects" has been selected. -> WIP at actual prices WIP at actual prices means that the object keeps the balance on the order until the DLV/TECO status. It calculates and settles WIP. Once the DLV/TECO status has been reached, the WIP is broken down and actual costs are settled to the receiver (see FUL-Rule to Material - controlling on a lot).
生产订单这样，平时结算WIP，完工结算差异的情况，这时就以实际成本结算WIP。
The object has a results analysis key and a settlement rule for periodic settlement to material. -> WIP at target costs WIP at target costs means that the object calculates and settles WIP in each period regardless of the status. The object is credited with the actual costs minus the WIP (see PER-Rule to Material - controlling by period).
成本收集器，同时存在WIP和差异的情况，平时以目标成本结算WIP。
The object has a results analysis key and can carry revenues -> results analysis Results analysis means that the object calculates and settles WIP, reserves for unrealized costs, cost of sales, sales revenues, reserves for iminent loss, ... in each period regardless of the status. Only the data calculated by results analysis is settled. A certain category will only get settled to FI and Profit Center Accounting if a posting rule has been defined for it in the customizing of results analysis. This is possible for all categories. On the other hand, only the cost of sales, sales revenue and reserve for iminent loss will get settled to the receiver of the settlement rule (see Settlement of Cost of Sales/Sales Revenue).
施工服务项目，有收入有成本。
The object does not have a results analysis key and has a FUL rule for settlement to material >0%. -> actual settlement only after DLV/TECO
这种可能是物料以移动平均价核算的生产订单。
In all other cases -> pure actual settlement to the receiver of the settlement rule
2 Ways to Analyze Actual Settlement
This section will deal with ways of analyzing settlement, which do not require debugging or programming skills, and provide an extensive explanation of the settlement results.
2.1 Searching for Notes
You can find notes for order settlement by using the component CO-OM-OPA-F and the search term "Settlement", or by using transactions (such as KO88 or CJ8G).
If the customer has received an error message or a program termination, then this should be specified in the search. Normally notes contain a detailed description of the prerequisites. These should be checked.
If you are searching for a consulting note, then enter the key word "info" or the category "consulting" and the transaction.
2.2 Previous Settlements
On the initial screen for settlement, you can display the previous settlements for a sender by choosing "Goto -> Previous settlements". This shows you the exact order in which the sender was settled, which debits were made for each settlement, and how these debits were distributed to the receivers. You can also go to the accounting documents that were created from this screen.
The display is based on the settlement documents. All the settlement documents that are in the system are displayed for the object, regardless of the period. The total of all the documents is also displayed. If settlement documents have already been archived, then these costs are not included. The system issues a warning if this is the case.
This analysis method is always useful if the customer experiences incorrect updates of documents. It is also very useful if you require an overview of whether and when the object has already been settled.
2.3 The Flow Trace
2.3.1 General Introduction to The Flow Trace
From Release 4.0 it is possible to write a flow trace for a single settlement. You can activate this in the initial screen menu by choosing "Extras -> Activate flow trace". Once you have called up the settlement, you can see the basic list of the log. This provides a very good picture of the technical progress of the settlement and of possible errors in settlement Customizing. The log explains comprehensively why the settlement settled which costs and where. It is recommended that you use this function. It often enables you to search for errors successfully without debugging.
For releases older than 3.0/3.1, you can install a flow trace using note no. 105820. This has mainly the same functions as the flow trace in 4.0, but you cannot call it up from the settlement transaction. Instead, you need to use transaction SE38 or SA38, and start report RKOTRACE to call it up.
The following graphics show how the flow trace can be evaluated.
2.3.2 Example 1: Settlement of a Production Order with Status REL
When you settle production order 600007419, the detail list shows that 50 USD WIP was settled.
The flow trace then provides the following analysis (see Fig. 1):
Initially the flow trace shows which sender was processed, in this case order 60007419.
Then the settlement rule is read in three steps: Determination of settlement transactions (see section three), reading the settlement rule and the settlement parameters.
The settlement rule that is valid for this settlement (100% FUL to Material MA-FERT) is listed as well as settlement profile no. 30 that was stored in the settlement rule.
However, especially important is the determination of the settlement transactions:
Initially, the system checks whether costs and revenues are to be settled. The result of this check is "-". This means that the actual costs and revenues are not to be settled. Reason: The sender has settlement profile no. 30, in which "Actual costs are to be settled in full" is selected. Actual costs would therefore be relevant in this respect. However, the sender now has Material as the receiver, which means that the sender is only settled once it has been finally delivered or technically completed. The DLV and the TECO statuses are both inactive. Therefore, actual costs are not settled.
Now checks are made to see whether variances are to be settled to costing-based profitability analysis. The result of this check is "-" which means that variances are not to be settled. Reason: Although the sender has a variance key, the production order does not have either the DLV or TECO status. Reason: Although the sender has a variance key, the production order does not have either the DLV or TECO status.
Finally, the system checks whether there is any WIP to be settled to FI. The result of this check is "+", which means that WIP is to be settled. Reason: The sender is not able to carry revenue and has a results analysis key.
Fig. 1 The relevant costs for these business transactions are now imported (see Fig. 2), in this case just the WIP. In the database, all the results analysis records in the WIPA, WIPN, RFKA, RFKW, RPPA and RFVL categories in version 000 are selected for this, and one record is found.
The categories and versions used for selection depend on the settings made in Customizing for WIP calculation. The system only selects versions in the controlling area where the "Transfer to Financial Accounting" switch is activated. Additionally, only categories are selected for which posting rules have been stored in the controlling area. (transaction OKG8). All other categories and versions are not relevant to settlement. In addition, all categories relevant to profit are selected on senders with revenues. These are the following categories: RDVL (60), RDVA (61), KDUA (63), KDUW (64), KDUN (65), ERER (67), POCV (71), POCR (72).
Now the records found are distributed to the receivers individually.
The cost element of the record found by the system is 672111, and it belongs to the WIPA category. The value in the settlement period is 50 USD after the costs already settled are subtracted. The total value of costs not settled during the year for this record is also 50 USD. This value is settled to FI, but is not relevant to profit, since WIPA does not belong to the categories relevant to profit (see above), so the record is not settled to the receiver specified in the settlement rule.
Fig. 2
2.3.3 Example 2: Settlement of a Production Order with Status DLV
When production order 60007448 is settled, the detail list shows that 3.33 USD is settled to Material. The question arises as to why the calculated variances were not posted to costing-based profitability analysis.
The flow trace provides you with the following analysis on that (see Fig. 3):
Fig. 3
Again, the settlement transactions are particularly important:
The system initially checks whether costs and revenues are to be settled. The result of this check is "+", which means that actual costs and revenues are to be settled. Reason: The sender has settlement profile no. 30, in which the "Actual costs are to be settled completely" indicator is set. Moreover, its status is DLV, which is also active on 30.09.2000. For this reason, actual costs are settled to the receiver specified in the settlement rule.
Now the system checks whether variances are to be settled to costing-based profitability analysis. The result of this check is "-", which means that variances are not to be settled. Reason: The sender has a variance key, and also has the DLV status on 30.09.2000. However, in settlement profile 30, the "Settle variances" indicator has not been set. This is why the variances are not settled.
Finally, the system checks whether WIP is to be settled to FI. The result of this check is "+", which means that WIP is to be settled. Reason: The sender is not able to carry revenue, and has a results analysis key.
Fig. 4
Then the costs are read again, and distributed to the receivers (see Fig. 4)
To provide an example, a debit has been drilled down in the tree, under cost element 400010. The value posted in the period using this cost element is 50 USD once the settled costs have been deducted. The total costs of the year under this cost element that were not yet settled are also 50 USD. The settlement rule 100% to Material is now applied to these costs. The result is that 50 USD are settled from this cost element to Material.
2.3.4 Example 3: Settlement of an Internal Order with Revenues
During the settlement of internal order 502302, which carries revenue, the detail list shows that 2,500 USD are settled to profitability analysis, and 5,000 USD WIP to FI.
The flow trace initially provides the following analysis (see Fig. 5):
Fig. 5
The sender is order no. 502302. The settlement rule valid in this case is 100% FUL to profitability segment. The settlement parameters for this order contain settlement profile no. 10, allocation structure MA, and PA transfer structure MA.
The settlement is determined as follows:
Costs and revenues are not for settlement Reason: The sender has a results analysis key and can carry revenues. Therefore, cost of sales and sales revenue are to be settled for this sender instead of actual costs.
WIP/COS to be settled Reason: The sender has a results analysis key and can carry revenues. Therefore, cost of sales and sales revenues are to be settled for this sender instead of actual costs.
The following continues with reading and distributing the costs (see Fig. 6):
When the costs are read, the results analysis data in version 000 with the following results analysis categories are read: RDVL, RDVA, KDUA, KDUW, KDUN, BWER, POCV, POCR, WIPA, WIPN, RFKA, RFKW, RFKN, RPRA. Four records were selected.
As this is a sender with revenues, version 000 and all categories relevant to revenue are selected. These categories are RDVL, RDVA, KDUA, KDUW, KDUN, BWER, POCV, POCR. In addition, the versions are selected for which the "Transfer to Financial Accounting" indicator was set in Customizing for the results analysis version (transaction OKG9). This is not a new version. Moreover, results analysis categories are selected that have posting rules (transaction OKG8), these are WIPA, WIPN, RFKA, RFKW, RFKN, RPRA.
Then the selected records are distributed to the receivers if they are relevant to profit, or are simply transferred to FI if WIP.
To provide an example, the record for cost element 671110 and category KDUA have been drilled down. The record value in the settlement period is 5,000 USD. The record is relevant to profit, and is thus settled to the receiver specified by the settlement rule. This states that 100% of the record is to go to the
profitability segment, being 5,000 USD.
2.4 The report RKACSHOW
Note no. 28145 provides you with an overview of the use of the technical validation report RKACSHOW. The following explains how the report can be used especially for settlement. For more detailed information on the settlement tables, see Technical Aspects of Actual Settlement.
2.4.1 Settlement rule
The settlement rule is saved in the COBRA and CORB tables. COBRA contains the settlement parameters, and COBRB contains the settlement rule.
2.4.2 Costs/Revenues
The settlement rule reads the costs to be settled for an object from the CO totals tables (COSP and COSS). The line items are generally not important. Depending on the settlement transaction, the COSB table may also be important. In the COSL table, the delivered quantity is for production orders and the billed quantity is for sales orders and WBS elements.
2.4.3 Already settled values
For each of the CO totals tables listed above, there is a settlement table in which values already settled are saved as totals: COSPD, COSSD, COSBD, COSLD. In settlement, the costs are read from the CO totals records and then the values from the D tables are subtracted. This result is then settled (see Tables Updated During Actual Settlement).
2.4.4 Settlement document
A settlement document is created for each settlement. This is used as the original document for the FI and CO documents etc. The settlement document is in the AUAK table (see Tables Updated During Actual Settlement).
2.5 The Report RKA_SETTLE_TABLES_COMPARE
You can analyze the tables that are relevant to settlement using the RKACSHOW report. A typical analysis would include the debits on the sender, the settled values, and the settlement documents.
The RKA_SETTLE_TABLES_COMPARE analysis report has been especially devised for settlement. This report displays tables relevant to settlement as well as additional functions, and can be made available from Release 4.0.
The RKA_SETTLE_TABLES_COMPARE report can be installed using note no. 193586 if not already in the customer system.
You display the results of the RKA_SETTLE_TABLES_COMPARE report using the SAP list viewer. The display variants, and the sort, filter and total functions in the SAP list viewer enable a more flexible analysis of the displayed data. It is recommended that you make extensive use of the SAP list viewer functions.
To analyze an object, you start by entering its number (see Fig. 7). If you do not have the number, then you can find it by starting the RKACSHOW report via the sender. The object number is in the list header of the RKACSHOW.
The report provides the following three options, which can be selected using a radio button:
Analysis of CO totals records
Analysis of CO line items
Analysis of the settlement documents
The following explains the analysis possibilities provided by these three options.
2.5.1 Analysis of CO Totals Records
To start, you can choose the data that is relevant for your purposes, and you can choose more than one data source at the same time:
Actual data from the COSS table
Actual data from COSP table
Results analysis data from the COSB table
Variances from the COSB table
Scrap from the COSB table
You can select one of the following processing functions for this data:
Debits minus data records: The system reads the debits from the data sources selected above, and the settled values that are in the corresponding tables (for example, COSPD for COSP) are deducted. For each totals record key, the system displays a record with a cumulated remaining value. It does not display credits from the settlement. You can use this option to check which totals records still contain costs that have not been settled. This function can, for example, be used when closing a sender, should an error message be issued informing you that there are still costs to be settled. Note: The field for the debit indicator is always empty. This is because, from Release 4.0 onwards, the system only writes one data record with an empty debit indicator. This means therefore, that the totals records are added up and the data records are deducted in the report, regardless of the debit indicator.
Cumulated debits Debits are read from the above selected data sources. For each totals record key, the system displays a record with a cumulated amount. Credits from the settlement are not displayed.
Periodic debits The system reads the debits from the above selected data sources. For each totals record key, a record with all period values is displayed. Credits from the settlement are not displayed.
Data records The system reads the settled values (that are in the corresponding data tables, such as COSPD for COSP) for the above selected data sources. For each totals record key, a record with its cumulated value is displayed.
Cumulated credits from the settlement The system reads the credits from settlements from the selected tables (records with debit indicator = A). The display is cumulated per totals record key.
Periodic credits from the settlement The system reads the credits from settlements from the selected tables (records with debit indicator = A). The display is by period for each totals record key.
2.5.2 Analysis of CO Line Items
If you suspect that postings were made to the last period after settlement was made, then you should always analyze the line items. The entry date field (CPUDT) shows whether this was the case or not, so if necessary, you can sort using this date.
You can make an initial selection of data that is relevant to you. You can also select more than one data source at the same time:
Actual line items (COEP table)
Results analysis line items (COEPB table)
Variance line items (COEPB table)
Scrap line items (COEPB table)
You can select one of the following display functions for this data:
Display without timestamp The line items are selected from the corresponding table and displayed. The timestamp field is not displayed.
Display with timestamp The line items are selected and displayed from the corresponding table The timestamp field is evaluated and made legible. You should only select this option if the display without timestamp displays more than one posting with the same entry date, and you need the entry time for them. This display option can take a significant amount of time.
2.5.3 Analysis of Settlement Documents
The settlement documents show which settlement was made for which amount, from which credit record.
There are two display options for the analysis:
Flat display The settlement documents are selected. For each settlement document/original totals record key/receiver (AUAK, AUAS, AUAA tables), the settled costs are displayed in a row.
Hierarchical display The settlement documents are selected. For each settlement document, the system displays a row (AUAK table). For each original totals record key/receiver (AUAS and AUAA tables), the settled costs are displayed in a row, in order of hierarchy.
3 Production Orders/Process Orders/Product cost collectors
A special feature for production orders is that the distribution rule determines the business process. The settlement rule for production orders is automatically created by the system, and is normally a PER or FUL rule settlement to Material.
3.1 Customizing for Production Orders/Process Orders
The default rule for the settlement rule is specified in Customizing for each plant and order type (transaction OKZ3 or OPL8). If the default rule = PP1, all production orders for this plant and order type receive the FUL rules. If the default rule = PP2, all the production orders for this plant and order type receive PER rules.
3.2 FUL-Rule to Material - controlling on a lot
If an order has a FUL rule for settlement to Material, then this is make-to-stock production that is lot-related.
The actual costs are only settled once the order has been finally delivered or technically completed. This means that the prerequisite for settling actual costs is the DLV status and the delivery date (AFPO-LTRMI) being well in advance of the last day in the settlement period. Alternatively, the TECO status must be given, and the date of the technical closing (AUFK-IDAT2) must be well in advance of the last day of the settlement period.
3.2.1 Settlement before DLV/TECO
For orders that have not yet been finally delivered or technically completed, the actual costs are not settled. The balance remains the same on the order.
If required, you can calculate WIP with actual costs. To do this, you require a results analysis key on the order. If you also want to post the WIP to FI and Profit Center Accounting, then you need to store posting rules in Customizing for results analysis for all results analysis categories relevant to settlement (transaction OKG8), and you need to select the "Transfer to Financial Accounting" indicator in the results analysis version (transaction OKG9). The WIP posting is triggered by settlement. The balance remains the same on the order even when WIP is created and settled.
3.2.2 Settlement after DLV/TECO
If the order has been finally delivered or is technically completed, then the actual costs are settled to stock or a price difference account, depending on the price control of the material. The base quantity is always the total delivery quantity of the order. This also applies to the settlement of subsequent debits. If the material price control indicator is set to S, then the actual costs are posted to the price difference account. If it is set to V, then the actual costs are settled to the stock account, if the stock is covered. If the indicator is set to V, and the stock is not covered, then the actual costs are settled to stock for the quantities that are still in the warehouse, the rest is settled to the price difference account. Example: 10 pieces with variances of 150 USD are settled, and there are only two pieces left in the warehouse. Then variances for these two pieces are settled to stock, being 30 USD. The remaining 120 USD are settled to the price difference account. It is generally strongly recommended that you do not use the V indicator for finished products (for more information, see note no. 81682).
If you are using the account-based profitability analysis and the price difference account is a cost element, then from Release 3.0F the price differences are automatically posted to account-based profitability analysis. You can deactivate this logic using substitution (see note no. 169688).
If a variance key has been selected on the order and variances have been calculated, then these are transferred to costing-based profitability analysis. Prerequisites for this are listed in note no. 35507.
If the order has posted WIP to FI before it reaches the DLV/TECO status, then the WIP is broken down again in FI.
3.3 PER-Rule to Material - controlling by period
If an order has the PER rule for settlement to Material, then it is periodic make-to-stock production.
The actual costs are settled regardless of status.