Archiving CO Line Items (CO) (SAP Library - Cost Element Accounting (CO-OM-CEL))

Archiving CO Line Items (CO)

Definition

Archiving object CO_ITEM for archiving cost accounting line items. Totals records cannot be archived.

Use

The SAP System automatically creates a CO line item for each business transaction involving an object in the CO application (such as an order or cost center). These line items are in addition to the documents for the Payroll or Financial Accounting components.

When you archive CO objects, the system also automatically archives the CO line items that belong to those objects. Consequently, it is normally not necessary to archive CO line items explicitly. However, you may have space problems (during long running orders) with the COEP or COBK tables. If so, you can use the CO_ITEM archiving object to also explicitly archive CO line items.

The table analysis of table COEP helps you choose a suitable archiving object to use. For more information, see table COEP.

Constraints

The system does not archive any CO line items that meet the following criteria:

CO line items that are down payments (value type 12, 58, 59, 61, 63)
CO line items for parked documents (value type 60)
Investment measures that are stored as CO line items
Actual CO line items in current or future period
Plan CO line items in current or future fiscal year
CO line items that were distributed using ALE

Line items distributed by ALE are not archived in the system in which you entered the document. You can delete these line items with the RKADELIT report. Choose Accounting ® Controlling ® Cost Element Accounting ® Environment ® ALE ® Delete ALE line items.

The system archives the copies in each receiving system

Local Currency Changeover

We recommend not archiving line items from the current fiscal year before the local currency changeover.

We recommend selecting CO objects whose line items should be archived instead of selecting CO_ITEM. CO_ITEM archives all CO line items in all CO applications. You can reduce the runtime of the local currency changeover to a minimum by selecting specific CO objects.

If you only wish to archive cost centers and order line items, you can also use the CO_COSTCTR (all data for cost centers), CO_ORDER (overhead cost orders), PP_ORDER (production orders) and SD_VBAK (sales documents) instead of CO_ITEM. You can also use these objects to archive each line item.

Structure

You can use the following functions for CO_ITEM:

Function/report assignment

Function

Report

Archive

RKCOITWR

Delete

RKCOITDL

Report

You can use all the actual CO line item reports to analyze the archive files for CO_ITEM.

When creating the archive, the system locks all the periods for which CO line items are to be archived. This prevents any more postings from being made in those periods.

To archive CO line items, choose Accounting ® Controlling ® Cost Element Accounting ® Environment ® Archiving ® CO line items.

Displaying Individual Objects Using SAP AS

A business view for the archiving object CO_ITEM is delivered as standard. The line item report KSB5 is called. To display individual objects for the archiving object CO_ITEM using SAP AS you require an information structure that has been created based on the standard field catalogs SAP_CO_ITEM_001 or SAP_CO_ITEM_002 delivered by SAP. The information structure must be activated and set up.

Recommendation

Use the information structure SAP_CO_ITEM_001 delivered as standard.

For more information about information structures, see also using the archive information system.

You can find more information on the Archiving Information System (SAP AS) under archiving information system (SAP AS).

Integration

To see which archiving objects can also archive CO line items, choose Tools ® CCMS ® DB Administration ® Data archiving and enter COEP in Objects for Table.

The Object Types

When archiving data from cost accounting tables (e.g. COEP), it is advisable to run an analysis of the object types used. You will find the object type coded in the first two characters of the object number. You will find the object number in the OBJNR field, the object type, for example, in COEP-OBJNR(2). You will find the translation of these two characters to a short text in table TBO01. Analysis programs, such as RARCCOA1 or RARCCOA2, compare the different object numbers with the number of corresponding entries.

In addition to the usual cost accounting object types, such as cost centers (CTR, CC) or orders (ORD, OR), the "reconciliation object" (REC, RO) often appears here. Often a considerable number of the table entries consist of such reconciliation objects. You can use the archiving object CO_ITEM to archive reconciliation object line items. To be able to decide whether these line items are to be archived you must first know how these reconciliation objects and their line items arise and what they are needed for.

The creation and use of reconciliation objects is different to that of reconciliation object types. You will find the latter in table ONRAO in the AOTYP field. There are four different reconciliation object types:

01: profitability analysis
02: operations planning
03: long-term planning
04: financial data (CO)

It is mostly the reconciliation objects of type 01 (profitability analysis) that contribute to the volumes of data (in table COEP). Types 02 (operations planning) and 03 (long-term planning) only contain plan data and thus do not contribute to the data volume in table COEP. Type 04 (financial data CO) is only of historical significance and does not carry data to any cost accounting tables.

Profitability Analysis (AOTYP 01)

Reconciliation objects of type 01 are always created when actually a profitability segment should be created but the account-based profitability analysis is not active. Thus there is either no profitability analysis active or only the costing-based profitability analysis is active.

An equivalent must exist in the Cost Accounting application component for every posting relevant to cost accounting; otherwise Cost Accounting would not be closed off. Postings relevant to cost accounting are all those made to G/L accounts that are revenue or cost elements, as well as postings to profitability analysis and to the profit center. An "equivalent in cost accounting" implies that an update must be made to a totals record (this is enough for plan postings) or a line item (for an actual posting) at least. This data is, however, always attached to a cost accounting object (CO object). This object exists anyway for "normal" cost accounting postings. Such an object would be, for example, a cost center or an order. Some postings do not have such an object; these then require a reconciliation object.

The following cases can occur:

Revenue postings to cost center
Cost centers can only be updated statistically with revenues. To post to a revenue account a CO object is required that may carry revenues. Such objects are, for example, orders with revenue or a profitability segment for account-based profitability analysis. Such an object cannot, however, be derived by the system. If the account-based profitability analysis is active, the revenue posting is generally made to a profitability segment (object type PSG, PS). If this is not the case there are no profitability segments (as CO object) and the posting is made to a reconciliation object (object type REC, RO).

Revenue postings to profit center
It is not sufficient to enter a profit center when posting, as this is not a real cost accounting posting. A real posting to a CO object must be generated here also. If you do not enter such an object explicitly and the account-based profitability analysis is not active, reconciliation objects are also updated here.

Postings to profitability analysis
If the costing-based, but not the account-based profitability analysis is active, an additional, reconciliation object is also posted to profitability analysis. This occurs particularly often through invoicing or settlements to profitability analysis (calculation of profits). Posting to a reconciliation object (instead of activating account-based profitability analysis) generates, as a rule, totals records with a greater degree of summarization. If this is not the case (the account-based profitability analysis is active) a profitability segment (object type PSG, PS) and not a reconciliation object is generated.
It is therefore not advisable to activate the account-based profitability analysis just to avoid generating reconciliation objects.

The Relationship between Reconciliation Ledger and Reconciliation Object

You can use the reconciliation ledger to check the reconciliation between the FI and CO application components. The reconciliation ledger stores its own data for this purpose. The reconciliation ledger data is not the reconciliation objects. Rather it is stored in tables similar to those of the Special Purpose Ledger (FI-SL) application component.

The reconciliation ledger can only be updated if there is also a posting to a CO object. This ledger also lists for which object type each posting has been made. This can then also be a "reconciliation object" (object type REC, RO).
In the reconciliation ledger reports you can (e.g. in the case of variances), double-click to branch to the corresponding cost accounting documents (line item report). From here you can navigate further to display, for example, the respective invoice. In this way you can analyze the origins of each of the variances determined. Without the reconciliation objects this would not be possible, as no CO line items would exist in this case for the postings described above (revenue postings to cost center, etc.).
You can carry out follow-up postings to the reconciliation ledger as long as a document exists for every posting relevant to cost accounting. You therefore also require reconciliation objects for the cases described above

The reconciliation ledger itself does not generate reconciliation objects it merely reads these. Reconciliation postings for cross-company code postings in cost accounting. Cost accounting itself is not affected. Cost accounting is already reconciled, as these postings always remain within one controlling area.

Operations Planning, Long-Term Planning (AOTYP 02, 03)

The transfer of plan data from SOP planning (logistics) to cost (center) accounting results in activity allocations in planning. Thus only plan data is generated. The postings of AOTYP 01 on the other hand are, as a rule, actual data.

The planning transferred is actually the cost center activity output (scheduling) planning to production orders. The production orders (actual data: the recipients that take on the activity) do not exist in this phase. Cost accounting therefore requires other objects that will take on the activity. The activity input is therefore posted to reconciliation objects on a plant and profit center level. ("100 machine hours for plant 0001, profit center 42).

Line items are only generated if the writing of plan line items has been activated. You will find the appropriate setting in the plan version.

Sales Document Item Object Type (SDI)

For sales orders (object type SDI) you can use the report VBELN_SET_GENERATE to generate sets for the respective sales order number.

When archiving using the archiving object CO_ITEM you can enter a set to limit the amount of data to be archived. The report VBELN_SET_GENERATE generates a set for sales orders automatically. Once you have executed the program, you can use the new set in the Group or set field in the archiving CO line items function.

See also:

Function	Report
Archive	RKCOITWR
Delete	RKCOITDL
Report	You can use all the actual CO line item reports to analyze the archive files for CO_ITEM.