This means that you post the balance of the period (actual costs minus deliveries) to stock or the price difference account. The base quantity is always the delivery quantity of the period. If the material price control indicator is set to S, then the actual costs are posted to the price difference account. If the indicator is set to V, then the actual costs are settled to the stock account, providing the stock is covered. If the control indicator is set to V, and the stock is not covered, then the actual costs for the quantities still in the warehouse are settled to stock, and the remainder 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. The variances are settled to stock for these two pieces, 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 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 also deactivate this logic using substitution (see note no. 169688).
If you selected a variance key on the order, and variances have been calculated, then these are transferred to costing-based profitability analysis. Prerequisites are listed in note no. 35507.
If required, you can calculate WIP with target costs for the orders. To do this, you need to select a results analysis key on the order. If you want to post the WIP to FI and Profit Center Accounting also, then you need to store posting rules in customizing (for results analysis) for all results analysis categories relevant to settlement (transaction OKG8), and select the "Transfer to Financial Accounting" indicator in the results analysis version (transaction OKG9). If you decide to calculate and post WIP, then the order balance less the WIP from the period is settled instead of the whole order balance. The balance of the order after settlement corresponds to the WIP.
3.4 PER/FUL-Rule to Material and Sales Order/Project - MTO with valuated sales order/project stock
A variant of the scenario described in 3.2 and 3.3 is the make-to-order production/engineer-to-order with valuated sales order and project stock, which is available from Release 4.0.
In this case, the settlement rule also specifies settlement to Material. In the detail screen of the settlement rule, the sales order item or WBS element is also entered. Period-end closing takes place in the same way as the business transactions described above.
The only differences regarding settlement are as follows:
The make-to-stock warehouse inventory is not debited. Instead, make-to-order production/engineer-to-order are debited.
If the price difference account is a cost element and if the sales order is a CO object, then the price differences are automatically transferred to the sales order item or the WBS element (see note 183250).
3.5 PER/FUL-Rule to Sales Order/Project - MTO with unevaluated sales order/project stock
If a production order has a 100% rule for settlement to sales order/project, then it is unvaluated sales order stock/project stock.
In this case, the order is treated like an internal order, meaning that it is settled periodically to the sales order or project, regardless of the status.
For an unvaluated sales order stock, the sales order always has a CO object, and the goods receipt on the production order is unvaluated. This means that the order is not credited when goods are received. The entire order costs are transferred to the sales order or WBS element.
If you want to calculate WIP on the production order, and settle the order to the sales order or WBS element after it has been finally delivered or technically completed, then you need to make the usual settings (results analysis key, indicator in the results analysis version, posting rules), and also set the "WIP on independent orders" indicator in the results analysis version (transaction OKG9).
Variances are not settled to costing-based profitability analysis.
3.6 PER to Material for Product Cost Collectors - Repetitive manufacturing with controlling by period
From Release 4.5, product cost collectors have a settlement rule for a 100% PER settlement to material. In the detail screen of the settlement rule the 005 strategy is displayed. This means that processing is slightly different to processing for PER to material (see above).
The actual costs and credits are posted on the product cost collector from the goods receipt for different production orders. The deliveries can go to different stock segments if the material has a separate valuation, or if the material is produced in-house or made to order. During settlement, the value of the goods receipts for the period is dynamically calculated for the different stock segments. The actual costs are distributed to the different stocks according to these values. If no goods were received in a period, then the actual costs are posted to a separate price difference account (account modification PRP). For more information, see note no. 388457.
3.7 PER/GES to Order position - Joint production
Co-production is when two products are created simultaneously from the input materials. This often takes place in the chemical industry, where an additional product is created with the main product (e.g. in the manufacture of automobile gas from oil). The SAP System differentiates between by-products and co-products. If you choose the second product as a co-product, then it is represented in the SAP System as normal lot-related make-to-stock production (see above). The only difference is, is that the co-product reduces the order balance. If you choose the second product as a co-product, then both products are relevant to cost accounting, meaning that the variances are distributed to both the co-products.
From a technical point of view, co-production is implemented in such a way that the order items receive their own CO objects. This means that instead of a CO object for the production order, you have N + 1 Co object, so one for the order and N for the N co-products.
The value flow is then as follows: The material consumption and activities are posted to the order header, the goods receipts are posted directly to the order items. In period-end closing, the order costs are initially posted proportionately to the items, using the preliminary settlement for co-products (transaction CO8A, CO8B). The order items then settle to Material.
When you create the production order, you create the following settlement rules for the above:
The order has settlement rules for its order items with equivalence numbers. These numbers are taken from the material master of the main product (view MRP 2, button "co-production") and can be overwritten.
The order items have settlement rules for 100% FUL/PER settlement to Material. Therefore, the order items behave like a normal production order with a material rule (see above).
This means that the order is settled periodically to its items regardless of the status. If the order items have a 100% FUL rule to Material, then the costs are only settled from the order item to Material when the order item and the order have the DLV status (all order items have been finally delivered), or the order header has the TECO status. If required, you can calculate WIP on the order items beforehand.
3.8 FUL to Order - Collective orders without automatic goods movements
If a production order has a settlement rule for FUL settlement to another order, then it is most likely to be a collective order without automatic goods movements.
Collective orders are hierarchies of production orders. The semi-finished products of the lower production orders are used directly for the higher product.
From Release 4.5, you can enter settings in the order type (transaction KOT2) to determine whether collective orders are represented in the system with or without automatic goods movements. Previously, only processing without automatic goods movements was possible.
Processing with automatic goods movements means that when goods are received on the lower orders, a goods receipt of this semi-finished product is automatic on the next order. All orders in the collective order have a settlement rule for 100% FUL settlement to Material, and behave as described above, for CO purposes.
Processing without automatic goods movement means that the goods receipt of the lower orders takes place on the next order, without going via the warehouse. The orders in the collective order have a settlement rule of 100% FUL settlement to the higher-level order. This means that they initially behave like normal internal orders, and periodically settle the actual costs to the higher-level order. The settlement is always made using a consumption account (see note no. 82150). This account is written when you create the collective order in the COBRA-KSTAR field. The settlement structure is not interpreted. If you want to create and settle WIP on the orders, then the "WIP on dependent orders" indicator must be set in the results analysis version (transaction OKP9).
4 Investment Measures
These are orders or WBS elements that have an investment profile assigned to them. The investment profile specifies whether:
The system creates an AuC during release
The settlement is summary or by line itemWhen releasing an investment measure, an AuC is created if required. Then settlement takes place as follows:
As long as the investment measure is not yet technically completed, the system settles it to your AuC. The corresponding ANN rule to the AuC is created automatically when the investment measure is settled for the first time. Costs that are not to go to the AuC can be settled to another CO receiver using a manually created PRE rule. The PRE rules are used before the ANN rules.
If the investment measure is technically completed, then the system settles the costs from the investment measure to the PRE rule receivers, and to the AuC. Then the AuC is settled to the FUL rules receivers of the investment measure. Normally, these are one or more fixed assets.
The system treats the investment measures as if they were technically completed, if capitalization is only partial (= settlement is started with processing type 3).
5 Questions Frequently Asked by Consultants
5.1 FAQ
In general - How do I make a setting to make sure that costs are not settled: Note no. 173909 - How can I analyze previous settlements?: Note no. 373685 - How does reversal work, and why does it not reverse all the values?: Note no. 372630 - What can the customer do to improve settlement performance?: Note no. 38855 - Why are error messages displayed although the balance is zero: Note no. 197561 - How can costs from previous periods be settled or reversed: Note no. 140672 - How can you reverse settlements that are not from the posting period?: Note no. 359814 - Double overhead during settlement: Note no. 185299 - Is the "settled" status given during settlement: Note no. 184919
Settled values/amounts - What is the difference between PER and FUL: Note no. 27922 - When quantities are allocated to the receiver: Note no. 27922 - Which document is created when you settle activity allocations or make settlement after revaluation at actual prices?: Note no. 156563 - How are figures rounded during settlement: Note no. 72429 - How are currencies translated during settlement: Note no. 201445 - Why is nothing settled for existing amount rules if the balance is zero?: Note no. 50249 - How does amount settlement work: Note no. 330001
Production orders/process orders/product cost collectors - Account determination for settlement to Material: Note no. 63339 - Account determination for settlement in the collective order: Note no. 82150 - When variances are settled to the profitability analysis: Note no. 35507 - How do you create the settlement rule for settlement to Profitability Analysis, for variances?: Note no. 189325 - Price differences for account-based results analysis: Note no.169688 - Price differences for valuated sales order/project stock: Note no. 183250 - Disadvantages of V price for semi-finished and finished products: Note no. 81682 - How do you settle a product cost collector from 4.5: Note no. 388457
Sales orders/WBS-elements - Settlement of the billed quantity to CO-PA: Note no. 111309 - Which results analysis categories get settled to CO-PA: Note no. 441994
Settlement to fixed asset - How is the asset value date determined during settlement to fixed assets: Note no. 98496
Reorganization - Why can a project not be closed: Note no. 76354 - How do I make a setting to make sure that costs are not settled: Note no. 173909
Plan settlement - What functions exist for planned settlement and in which release: Note no. 113629 - How do you generate plan settlement rules?: Note no. 207722 - Why do rounding balances arise despite complete planned settlement?: Note no. 356546
5.2 Senders no Longer Need to be Settled
You no longer need to settle senders to reorganize them (= close or set deletion flag). In the settlement profile (see Settlement Customizing), there are radio buttons under the actual cost/cost for sales ("To be settled in full", "Can be settled", and "Not for settlement"). You can use these to control how the sender is to be treated for settlement, closing, or reorganization.
"Not for settlement" means that the objects are not included in the settlement, and are not checked during reorganization to see if the balance is zero.
"To be settled in full" means that the object is to be settled, and an error message is issued during reorganization if the balance still contains an object.
"Can be settled" is similar to "to be settled in full" for the settlement, and similar to "not for settlement" for the reorganization.
The F1 field help provides detailed information on this.
In some situations, the "can be settled" setting must be used even though you may want to use "to be settled in full". This is the case when values from several objects are summarized on one object through the results analysis, and only this object is settled. For more information, see note no. 76354.
In addition, the "not for settlement" setting is always useful if you have old data from previous years on orders, and this data is no longer required for the current year. In this case, it is recommended that you change the settlement profile in the orders to "not for settlement", close the orders and then create new ones with a different settlement profile (see also note 173909).
5.3 Orders with Revenues Can be Settled to a Cost Center
Senders that can have revenues (sales orders, orders with revenues, or billing elements) can also be settled to cost centers/fixed assets, providing no revenues were posted, or settled to other receivers using source groups.
6 Technical Aspects of Actual Settlement
The following list of the routines and tables most important to settlement is based on the flow trace structure.
6.1 Important Routines and Internal Tables in The Settlement Run for Actual Settlement
A standard settlement run for actual settlement with important routines, function modules and tables is displayed in Fig. 8.
Settlement start: SAPLKO71, before 4.5: SAPLKO74
Sender selection (SENDER_SELECT routine, IT_OBJNR table) and sort the senders by hierarchy number (OBJHIE_FILL routine, IT_OBJHIE table (like COBRA[1])): SAPLKO71, before 4.5: SAPLKO74
Individual processing of senders (SINGLE_AUSFUEHREN routine): SAPLKO72, before 4.5: SAPLKO74
Import settlement rule (RULES_READ routine, AT table (like AUFT[2]))
Read settlement parameters (COBRA table)
Determine transactions for settlement (VRGNG_GET routine, AV table)
Read costs/revenues (K_SETTLEMENT_COST_READ function module, BEL table (like BELA[3]))
Distribute costs/revenues to receivers (K_TAB_AUAS_FILL function modules, AS table (like AUAS[4]))
Create documents (K_SETTLEMENT_CHECK function module, AK table (like AUAK[5]))
Error and list output
6.2 Settlement Transactions for Actual Settlement
Settlement transactions are determined in the VRGNG_GET routine as already mentioned above.
The possible business transactions that can be determined are as follows:
KOAO: 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 in the K_SETTLEMENT_COST_READ function module, the debits from the COSS and COSP tables with value type "04" are read. In addition, the down payments that have value type "12" are read during settlement to fixed assets.
KOAV: Business transaction for settlement of variances to profitability analysis for production orders. The prerequisites for settling variances in production orders are listed in note no. 35507. If this business transaction is selected, then the variance data is selected from table COSB in the K_SETTLEMENT_COST_READ function module. Variances are value type "31", scrap is "30". The variances are settled to a profitability segment. The settlement rule for variances is generated by the system during the first variance settlement.
KOAW: Business transaction for settling data in the WIP calculation or results analysis. If this is selected, then the results analysis data (data that is value type "32") is read from the COSB table and processed in the K_SETTLEMENT_COST_READ function module. If the sender carries revenues, then only this data is interpreted during the actual settlement, and the COSS and COSP tables are not read.
KOAA: Business transaction for settling the incoming orders that are project-related. If it is selected, then the incoming order is read from the COSB table and processed in the K_SETTLEMENT_COST_READ function module. Incoming orders are value type "19". Incoming orders are settled to a profitability segment. The settlement rule for the incoming orders is copied from the actual rule during the first settlement of incoming order data, but can also be manually created.
6.3 Tables Updated During Actual Settlement
AUAK: Settlement document
COSPD: Settled values from COSP
COSSD: Settled values from COSS
COSBD: Settled values from COSB
COSLD: Settled values from COSL (before 4.5A, only the billed quantity, from 4.5A the delivery quantity also)
Credit line in COSSA/COSPA with BEKNZ = 'A'
The system updates all tables during actual settlement, insofar as debits exist in the corresponding tables. The system updates the settlement document (1), and the COSBD (4) values only during WIP settlement. The system updates the settlement document (1), and the COSBD (4) values during variance settlement.
6.4 The Settlement Document for Actual Settlement
The system updates the settlement document during settlement (see Fig. 9). This consists of more than one table, the most important of which are explained below. In the DDIC, the settlement document is displayed using the AABLG cluster table.
AUAK: Document header, which contains global information, such as document number, sender, settlement period, and so on.
AUAA: Receiver segment The AUAA contains the sender and receiver for the settlement. The system places the sender in the AUAA table during the sender check (SENDTAB_CHECK routine), and the receivers in the AUAA table during the receiver check (RECEIVER_CHECK routine).
AUAV: Transactions The settlement transactions used are contained in the AUAV. These are determined in the VRGNG_GET routine (for details, see above)
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). The AUAS table is filled in the K_TAB_AUAS_FILL function module.
AUAW: Accounts for the WIP settlement (from 4.5 only) 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.
This data is used to create more CO or AC documents (K_SETTLEMENT_CHECK function module). In the K_SETTLEMENT_DOCUMENT_INSERT function module, the system posts the settlement document, and updates the COSSD, COSPD, and COSBD tables according to the settlement document values.
6.5 Two Examples of How the Settlement Processor Works
6.5.1 Simple Example (FUL Settlement)
6.5.1.1 Starting point
The following debits have been posted in a settlement sender: Table Cost element Period Amount COSP 400000 001 1000 002 50 415000 001 1000 002 50
There are D-records from the settlement in period 001: COSPD 400000 1000 415000 1000
This was a full settlement to two cost centers: COBRB 50% CCTR1 FUL 50% CCTR2 FUL
6.5.1.2 Settlement in the second period
COSPA_READ_MULTI The debits cumulated up to the settlement period are imported to the BTR fields in the BEL table. The debits from the settlement period are imported to the PER fields. BTR PER BEL: 400000 1050 50 415000 1050 50
Now the data records are "merged" with the BTR fields, which means that the amounts that have already been settled are subtracted from the data records. BEL: 400000 50 50 415000 50 50
K_TAB_AUAS_FILL The function module splits the BEL table and distributes it among the receivers. It then writes the amounts to be settled for each receiver to the internal AS table. This internal table is then written to the AUAS table in the database. (The values are initially processed in the internal ASTAB table and then transferred to the AS table as ASTAB_TO_AS). The receivers are linked to the AA table by the PLFNR field. Once the data has been distributed to the receivers, the BEL table is reduced to zero. PLFNR AS: 400000 0002 25 400000 0003 25 415000 0002 25 415000 0003 25
AA: 0002 CCTR1 0003 CCTR2
BEL: 400000 0 0 415000 0 0
6.5.2 A More Complex Example (PER Settlement)
6.5.2.1 Starting point
The following debits have been posted: Table Cost element Period Amount COSP 400000 001 1000 002 1000
The settlement again goes to two cost centers, this time as periodic settlement: COBRB 50% CCTR1 PER 50% CCTR2 PER
The settlement of periods 001 and 002 create a D-record. COSPD 400000 2000
Now another debit of 50.00 is posted in each of these two periods. COSP 400000 001 1050 COSP 400000 002 1050
6.5.2.2 New settlement in the second period
COSPA_READ_MULTI The debits cumulated up to the settlement period are imported to the BTR fields in the BEL table. The debits from the settlement period are imported to the PER fields. BTR PER BEL: 400000 2100 1050
Now the data records are "merged" with the BTR fields, which means that the amounts that have already been settled are subtracted from the data records. BEL: 400000 100 1050
K_TAB_AUAS_FILL Since a PER rule is being used for settlement, the role of the data records is "transferred" from the AUAS records of the settlements that were already made in the period. However, the debits of the period are split afresh, and the settlements that have already been made are only then deducted afterwards. Initially the settlement documents from the settlements made in period 002 are imported (form READ_ACT_SETTLMENT_DOCUMENT). These are transferred to the ASTAB table with a negative plus/minus sign (form AUAS_TO_BEL), but are also added to the BTR fields in the BEL table. PLFNR ASTAB: 400000 0002 -500 400000 0003 -500
BEL: 400000 1100 1050
Now the function module splits the BEL table among the receivers as usual. Since this is a periodic rule, the splitting is applied to the PER fields. The result of the split is added to the values already in the ASTAB (settled values with a negative plus/minus sign). PLFNR ASTAB: 400000 0002 25 (525-500) 400000 0003 25 (525-500)
Next the PER field amount is subtracted from the BETR fields in the BEL table (form CALCULATE_BEL_BTR_FROM_REST). BEL: 400000 50 1050
This means that the BTR fields in the BEL contain the exact values that would be used for any additional FUL rule that may exist, in a second splitting step (form SPLIT_BEL_ONE_GENERAL).
7 Technical Aspects of Planned Settlement
7.1 Important Routines and Internal Tables in The Settlement Run for Actual Settlement
A standard settlement run for planned settlement with important routines, function modules and tables is displayed in Fig. 10.
Settlement start: SAPLKO71, before 4.5: SAPLKO74
Sender selection (SENDER_SELECT routine, IT_OBJNR table) and sort the senders by hierarchy number (OBJHIE_FILL routine, IT_OBJHIE table (like COBRA)): SAPLKO71, before 4.5: SAPLKO74
Individual processing of senders (SINGLE_AUSFUEHREN_PLAN routine): SAPLKO72, before 4.5: SAPLKO74
Import settlement rule (RULES_READ_PLAN routine, AT table (like AUFT)), copy planned settlement rule from actual settlement rule if there is no planned settlement rule
Read settlement parameters (COBRA table)
Determine transactions for settlement (VRGNG_GET_PLAN routine, before 4.5 RULES_READ_PLAN, AV table)
Read planned costs/planned revenues (K_SETTLEMENT_PLAN_READ function module, ALL table (like COSP1_OT_ALL in type group COSP1))
Distribute planned costs/planned revenues to receivers (K_SC_COST_SPLIT_MULTI function modules, ALL_RES table (like COSP1_OT_ALL_RES in type group COSP1)
Merging the distributed planned costs with the costs that have already been settled; from 4.5 this is done based on the planned settlement documents (K_SPLIT_RESULT_COLLECT function module, ALL_RES table (such as COSP1_OT_ALL_RES in the COSP1 type group), and before 4.5 based on the CO documents (K_SPLIT_RESULT_POST function module, IT_COEJA table (like COEJA)).
From 4.5 create settlement document (K_SPLIT_RESULT_COLLECT function module)
Create documents (K_SPLIT_RESULT_POST function module)
Error and list output* *
7.2 Settlement Transactions for Planned Settlement
Before Release 4.5, there was only one settlement transaction for planning data, the KOAP business transaction. This was selected in the RULES_READ_PLAN routine. From 4.5 there is the VRGNG_GET_PLAN routine, in which the settlement transactions are determined.
The business transactions that can be determined there are as follows:
KOAP: Business transaction for planned settlement. If it is selected, then the planned costs of the sender are settled to the receiver specified in the settlement rule. This means that in the K_SETTLEMENT_PLAN_READ function module, the debits with value type "01" from the COSS and COSP tables are read.
KOAB: Business transaction for transferring planning data. If it is selected, then the planned results analysis data with value type "49" is read from the COSB table in the K_SETTLEMENT_PLAN_READ function module. The plan data transfer is only settled to a profitability segment. When planning data is transferred, no credit is posted on the sender.
KOAX: Business transaction for settling data from planned results analysis. If it is selected, then the planned results analysis data with value type "49" is read from the COSB table in the K_SETTLEMENT_PLAN_READ function module. The COSS and COSP tables are not read.
7.3 Tables Updated During Planned Settlement
AUAK: Settlement document
Credit line in COSSA/COSPA with BEKNZ = 'A'
Unlike actual settlement, the COSSD, COSPD and COSBD tables are not updated. The settlement document is written from 4.5. The system does not write a credit record in COSSA with BEKNZ = A during the transfer of planning data.
7.4 The Settlement Document for Planned Settlement
The settlement document is not updated from 4.5 during planned settlement (see also Fig. 11). This consists of several tables, on which the most important are explained below. In the DDIC, the settlement document is displayed using the AABLG cluster table.
AUAK: Document header, which contains global information, such as document number, sender, settlement period from, settlement period to, version, and so on.
AUAA: Receiver segment The AUAA contains the sender and receiver for the settlement. The system places the sender in the AUAA table during the sender check (SENDTAB_CHECK routine), and the receivers in the AUAA table during the receiver check (RECEIVER_CHECK routine).
AUAV: Transactions The settlement transactions used are contained in the AUAV. These are determined in the VRGNG_GET_PLAN routine (for details, see above)
AUAY: Totals keys In the AUAY table, there is a row for each original debit totals record. The KEY01 field contains the database key for this record.
AUAT: Totals segment for each period The AUAT table contains the settled values from this settlement run. The system updates one row per receiver and original debit totals record. The KLFNR field refers to the debit totals record (= the record from the AUAY table, whose current number is the same as KLFNR). The PLFNR field displays the receiver (= the record from AUAA, whose current number is the same as PLFNR). The AUAT table is filled in the K_SPLIT_RESULT_COLLECT function module.
From 4.5, this data is used to create more CO documents (K_SPLIT_RESULT_POST function module). The settlement document is updated in the K_SETTLEMENT_DOCUMENT_INSERT function module.
8 Debugging Basics
8.1 Message Handler
The message handler enables you to collect messages that the system does not display until the transaction flow is complete.
MESSAGES_INITIALIZE This deletes the messages that were already collected, and collects those that are to come. You can see whether the message handler is activated, or accidentally switched on for a second time (this would delete the messages already collected).
MESSAGE_STORE This saves the issued message. You can use the callup hierarchy to see who issued the message.
MESSAGES_SHOW This displays the messages that were collected, as well as their long texts.
Message handling normally works by switching on the message handler using the MESSAGES_INITIALIZE function module, saving each message with the MESSAGE_STORE function module, and displaying the messages collected, using the MESSAGES_SHOW function module. However, using the message handler does have a few risks. You can, for example, delete all previously collected messages by switching on the message handler twice. This can result in repressing error messages that the system normally displays for a posting, leading to a posting with errors.
8.2 SENDER_SELECT Form
Depending on the first transaction used when the system was called up, various modules are called up for determining the object numbers to be processed. These are in the IT_OBJNR table. Caution: Each object number may only appear once in the table, as multiple entries cause the system to cancel with a short dump.
Temporary solution for the problem: Insert SORT IT_OBJNR and DELETE ADJACENT DUPLICATES. However, later on, you need to examine the reasons why the object numbers appeared more than once.
8.3 RULES_READ or RULES_READ_PLAN Form
The system imports the settlement rules for the sender into the IT_COBRB table, and then executes a selection of checks. If required, dynamic rules are also added (see also: 8.4). Finally VRGNG_GET is called up. The system checks the rules and then fills the AT table in the RECEIVER form, where various error messages can occur, which, for example, are a result of the status check of the receiver.
8.4 VRGNG_GET or VRGNG_GET_PLAN Form
The system checks the transactions described in 6.2. It calls up individual subroutines, in which different error messages are issued if the program believes it has found any errors. This is where the entire logic is displayed, for settlement prerequisites, with the final result in the internal AV table.
8.5 K_SETTLEMENT_COST_READ or K_SETTLEMENT_PLAN_READ Function Module
Depending on the determined business processes, the system calculates the debits from the COSP, COSS, and COSB tables, using the standard K_<tabname>READ_MULTI function module. The records provided by these tables are transferred to the BEL table in the FILL_BEL<tabname> callback routines.
If a FUL settlement of actual costs is made, then settled values are imported from the COSPD, COSSD, and COSBD tables to the BEL table.
8.6 K_TAB_AUAS_FILL Function Module for Actual Settlement
If you repeat settlement or a reversal, the settlement documents that the system already created for the period are imported (read_settlement_document FORM), and added to the internal BEL table. Then the system fills the AQTAB, and possibly the BETRTAB tables, which contain the settlement rules (already formatted) for settlement by equivalence numbers or fixed amounts. The system then distributes the BEL one record at a time to the receivers, thus creating an AS record for each receiver.
8.7 K_SC_COST_SPLIT_MULTI Function Module for Planned Settlement
The AQTAB table is filled. This table contains the settlement rules for settlement by percent and equivalence numbers already formatted. Now ALL is distributed one record at a time to the receivers, and an ALL_RES record is created for each receiver.
8.8 K_SPLIT_RESULT_COLLECT Function Module for Planned Settlement
When you repeat settlement or reversal, the settlement documents already created for the period are imported and merged with the internal ALL_RES table. Next, the settlement document is created with the AUAY and AUAT tables. This function module is only available from Release 4.5.
8.9 K_SETTLEMENT_CHECK Function Module for Actual Settlement
The system adds documents to the AS that are created during settlement. Depending on the receiver category, these documents are:
CO documents (co_document_build form), such as settlement to cost center
CO-PA documents (er_document_build form), settlement to profitability segment
MM documents (ma_document_build form), production order to Material
AM documents (an_document_build form), settlement to fixed assets
FI documents (fi_document_build form), settlement to G/L account
You need to have a basic understanding of the documents created, and of the COIN and RWIN to debug in the above routines. Advanced understanding is essential before making changes in KO77, to avoid severe data problems.
8.10 K_SETTLEMENT_POST Function Module
This saves the documents created by K_SETTLEMENT_CHECK, and the settlement document. Then it writes the corresponding records in the COSPD, COSSD, COSBD and COSLD tables. This all takes place in the IN UPDATE TASK, meaning that only update debugging can help (see 8.12)
8.11 K_SPLIT_RESULT_POST Function Module for Planned Settlement
Using the ALL_RES table, the system creates the documents resulting from the planned settlement. Before 4.5 only planned settlement to cost centers or business processes is available. Then in this function module, the CO document is created and merged with the old CO documents from the settlement. After 4.5, either CO or CO-PA documents are created depending on the receiver. The delta handling is no longer included in this module.
8.12 Update debugging
Caution: Only for experienced developers
The K_SETTLEMENT_DOCUMENT_INSERT function module is started in the update task. This means that an error search (such as for updating D-tables) can only be made using the update debugging. Procedure:
Start settlement to the update server from the debugging session (/h)
"Settings" -> "Update debugging"
Continue
The debugger stops in the RSM13000 program, Vbexec module.
Continue one step at a time until you reach LOOP AT VBMOD_TABL
Insert the correct table entry (VBFUNC = K_SETTLEMENT_DOCUMENT_INSERT)
Go to the VB_CALL_FUNC form
At the end of the form, there is a dynamic callup of VBFUNC
Now you can start.
[1] COBRA: Settlement rule, order settlement [2] AUFT: Internal structure, distribution rule for settlement [3] BELA: Internal structure: Amounts to be settled [4] AUAS: see 3.4 [5] AUAK: see 3.4