CO: Primary Cost Element Categories

01: Primary costs / cost reducing revenues
This Primary Cost Element category can be debited for all primary postings, for example, in Financial Accounting (FI) or in Materials Management (MM).

Cost-reducing revenues are revenues that are to be handled in CO similarly to overhead costs, and which reduce the prices of an activity type or the costs to be assessed. This is the case, for example, with rent revenues, which reduce the room costs to be assessed. Cash discount amounts and exchange rate amounts are also cost-reducing revenues.

Note:
In contrast to revenues of cost element category 11, cost-reducing revenues in the CO module are typically assigned to cost centers. Note that when you use Profitability Analysis (CO-PA, costing-based) these cost-reducing revenues can only be transferred to Profitability Analysis during secondary allocations and not during invoicing.

03: Accrual Calculation Using the Percentage Method

You can only use this cost element category during accrual calculation in Cost Center Accounting (component CO-OM-CCA) when you are using the percentage method. You can post directly from FI to take account of the actual costs incurred. The system also uses cost elements of this category to post the accrual amounts within Cost Center Accounting CO-OM-CCA.

If you do take actual costs into account (say, for additional costs), create cost elements of this category in Controlling (CO) only. The account must be defined in the chart of accounts, but you do not need to create the general ledger account in FI.
04: Accrual Calculation Using the Target=Actual Method

Used in Cost Center Accounting (CO-OM-CCA) only for accrual calculation when you are using the target=actual method. You can post costs directly from FI to register actual costs incurred. At the same time, the R/3 System uses this category of cost element to post accrual cost amounts within Cost Center Accounting CO-OM-CCA.
If you do take actual costs into account (say, for additional costs), create cost elements of this category in Controlling (CO) only. The account must be defined in the chart of accounts, but you do not need to create the general ledger account in FI.
11: Revenues
Used to post revenues. These revenues are generally posted during make-to-stock-production directly into the operating profit, or with make-to-order-production to the sales order.
In Controlling (CO) revenues are displayed with negative +/- sign. An exception to this is Profitability Accounting  (CO-PA, costing-based), in which all values, including revenues, are displayed with a positive +/- sign.
 
Caution: If you post revenues to cost centers, the values are displayed as statistics only (for information purposes).
This means: You can repost revenues to other cost centers to correct postings, but other allocation is not possible.
Revenues are not taken into account during activity price iteration and are therefore not included in activity allocation prices.
Note: Revenues are generally defined as cost element category 11. This enables the integrated transfer of billing documents to CO-PA. An exception to this rule is cost-effecting revenue. See the section "Primary Costs / Cost Reducing Revenues".

12: Sales Deductions
Used to post deductable items (sales adjustments, sales corrections) such as discounts and rebates. Certain deductable items (freight charged separately in the invoice, surcharges for small quantities, special orders) are not classified as sales deductions, but as revenue elements.

You can use this category in the same manner as revenue elements (category 11). Values on cost centers are displayed as statistical only.

22: External Settlement 

Used to settle order costs, project costs, or cost object costs to objects outside of CO. These objects could be assets (Asset Management), materials (Materials Management), or general ledger accounts (Financial Accounting). The R/3 System creates an accounting document when the costs are settled.

Cost elements of this category cannot be used for settlement within CO (cost centers, orders, projects, and so on). Use secondary cost element category 21 for this purpose. The R/3 System does not create an accounting document when costs are settled within CO.

90: Cost Elements for Balance Sheet Accounts in FI 

Automatically assigned when you create cost elements in CO whose general ledger accounts in FI are asset reconciliation accounts (special balance sheet accounts), not income statement accounts. You cannot change this category in CO master data maintenance.

FI does not require CO account assignments to cost elements of category 90. However, if you enter an account assignment, it is only recorded statistically for true objects.

Category 90 cost elements enable you to check the budget of an order or project when you acquire fixed assets that can be directly capitalized. To do this, enter the capital investment order or the WBS element in the corresponding field of the asset master data. Asset Management (AM) ensures that the specified order or WBS element is automatically entered in the document during the asset acquisition.

In CO the order or WBS element is debited statistically. This statistical debiting is checked by the system using the budget during availability control.

Deletion of SAP Data - TCODE : OBR1, Program : SAPF020

This program resets transaction data in a company code, initializes the number ranges, deletes data from test payment and dunning runs, and deletes cross-company code transactions and customer credit control data. The program also includes data from Special Purpose Ledger and Controlling if it is generated by transactions in Financial Accounting.
It deletes the following:
  • Document header supplement for recurring entries
  • Document header for Financial Accounting
  • Document segments
    • Financial Accounting document segment
    • one-time data document segment
    • bill of exchange field document segment
    • tax data document segment
  • Change documents
  • Document long texts
  • Financial Accounting: Secondary index for customers
  • Financial Accounting: Secondary index for customers (cleared items)
  • Financial Accounting: Secondary index for vendors
  • Financial Accounting: Secondary index for vendors (cleared items)
  • Financial Accounting: Secondary index for G/L accounts
  • Financial Accounting: Secondary index for G/L accounts (cleared items)
  • Secondary index for material documents
  • Index table for customer bills of exchange used
  • Customer master record transaction figures
  • Customer master record special G/L transaction figures
  • Vendor master record transaction figures
  • Vendor master record special G/L transaction figures
  • G/L account master record transaction figures
  • Cross-company code posting procedures
  • Customer payment history
  • Prenumbered checks
  • Payment medium file
  • Open item account with changed reconciliation account
  • Consistent payment run information
  • Consistent dunning run information
  • Held documents
  • Documents for external systems
  • Parked documents
  • Data for external tax systems
  • Information on business area allocation
  • Reconciliation postings from the company code's reconciliation ledger
  • Cash management data for the company code
Some fields are initialized for dunning control and customer credit control.
  • Customer master record (dunning data)
  • Vendor master record (dunning data)
    • date of the last dunning notice
    • dunning level
    • date of the legal dunning proceedings
  • Credit management: Control area data
    • total of the order values for checking the credit limit
    • total of the receivables for checking the credit limit
    • relevant special G/L transaction commitments for checking the credit limit
    • date on which the credit limit was exceeded
    • the indicator stating that the credit limit has to be reset, is set.
Controlling data which can be allocated to the company code to be deleted (also planning data), is deleted in the program run.

Requirements

Only switch on the "Cluster deletion off" field if you do not want to delete directly in the RFBLG cluster. This only makes sense if you have added your own fields to the BSEG and have defined your own matchcode objects for them, or you have set table logging for tables BSEG, BSET, BSED or BSEC. This is then also necessary to reset your own matchcode information and the log information. Note that the runtime will increase.

Note

You should always run the reset program in background processing since problems can occur during runtime even if you are just deleting or displaying small sets of data. Database changes, however, are made only in production run mode, and when they are made, the system writes a log entry in addition to the documentation.
If the company code you are deleting is found in a payment run and no other company code that is included in this payment run is productive, the program deletes the data of that payment run. The log lists the number of payment runs in which the test company code and a productive company code exist together. To delete these records from the system, you have to run your own programs. The same applies to test dunning runs.
If a primary cost element is in a controlling area that is assigned to a productive company code, the program does not delete any data in Controlling. The log then informs you of this situation, and lists the number of records per table that are not deleted.
In Special Purpose Ledger, the program deletes all standard ledgers in totals table GLT0 and GLT3, including the additional ledger for the respective company code. Furthermore, it deletes all nonstandard additional ledgers and nonadditional ledgers in the other totals tables. The remaining ledgers must be deleted using other, application-specific programs (certain consolidation ledgers).
If an error occurs in the deletion program for Special Purpose Ledger, the log lists the error text. You can display the long text using transaction SE91 by specifying the application area.
The reset program does not delete any documents that are being posted at the time of the program run.

A warning appears for non-productive company codes that are linked by means of the controlling area to the company code you are deleting. You can select "Suppress repetitive warnings" to limit these warnings so that only the first one appears.

SAP COPA : Account Based Vs Costing Based

In Account based CO-PA:

1. You can't get Cost component break down.
2. No break down of variance categories.
3. Create a Characteristic in KEA5 and add to operating conern in KEA0. KEQ3 is to define segment level characteristics. To improve system performance, you can also restrict the characteristics that make up the profitability segment.
4. When you add a characteristic to operating concern, then by default that characteristic is available at the time of document entry. We use characteristic groups to determine what characteristics appear in which order on the screens for assigning profitability segments in different business transactions. If no characteristic groups are defined, the user can enter values for any characteristic in the operating concern.
5. Account based CO-PA uses the same tables (COEP, COEJ, COSP, COSS etc.,) as used by overhead cost management, whereas costing based COPA has it's own tables. The definitions of profitability segments for both CO-PA sub-modules are stored in the same table, the CE4XXXX table (where XXXX = operating concern).
6. Period account approach, unlike costing based which is cost of sales accounting approach.
7. Account-based CO-PA stores all transaction in three currencies: the transaction currency, the local currency, and the controlling area currency.
 

Text field in FI Document automatically from MIRO line item

When a purchase order is created to a cost centre, G/L account and cost centre are entered manually. Often Purchase Order only uses short text field as reference, i.e., Material is not mandatory.

 

MIRO process is then done for PO after GR, and the PO text (short text) is copied into MIRO.

 

G/L account line items can be displayed in FBL3N, detailing the document numbers related to the invoice/PO once posted.

 

The field "Text" is defaulted as blank, even if created with reference to a PO, which contains text. Does anybody know of a way to automate process so that the text field is populated with the text from MIRO?

 

 

You can transfer what ever the data from the MIRO to accounting document-using BTE.

 

Go to SE37 - SAMPLE_PROCESS_00001120 (this is the standard BTE for account document posting). Copy this with ZSAMPLE_PROCESS_00001120.

 

In this you cannot modify the tables t_bkpf and t_bseg. you can use t_bkpfsub and t_bsegsub.

 

For this a little bit config is required.

 

1) Go to t-code FIBF-> settings->Products->... of a customer.

Click new entries -> product name- ZPRODUCT, text - any text, RFC dest - ZSAMPLE_PROCESS_00001120, A - enable check box -> save.

2) Go back -> settings -> P/S Modules -> ... of a customer.

Click new entries -> event - 00001120, Product - ZPRODUCT, Ctr - Country key, Appl - FI-FI, Function module - ZSAMPLE_PROCESS_00001120 -> save.

3) Go back -> settings -> Process Modules -> ... of a customer.

Click new entries ->Process - 00001120, Ctr - Country key, Appl - FI-FI, Function module - ZSAMPLE_PROCESS_00001120, Product - ZPRODUCT -> save.

 

Now go to SE37->ZSAMPLE_PROCESS_00001120 logic.

 

loop at t_bkpf.

loop at t_bkpfsub.

move 'your value' to t_bkpfsub-value.

modify t_bkpfsub index sy-tabix.

endloop.

endloop.

 

loop at t_bseg.

loop at t_bsegsub.

move 'your value' to t_bsegsub-value.

modify t_bsegsub index sy-tabix.

endloop.

endloop.

 

''Your value' is imported value.

 

No need to worry about modified values. After execution of BTE it will go to standard program and copy the values of t_bkpfsub] and t_bsegsub to SAP tables. So please be perfect with code. SAP wouldn't allow change the values in t_bkpf and t_bseg values. you can add your own fields in bkpf_subst and bseg_subst.

 

But make sure that; please write the code in FM with conditions like company code doc type etc. because this BTE is very important. It will execute before acc doc is posted. If you do not specify any conditions it will execute for all co codes in acc doc. it will affect business. You can debug this BTE. Put a break point in FM and see the values while post the MIRO.

 

Once import the values free memory id and clear the variables whatever you used in BTE.

Problem in spool requests from printing jobs in SAP

Recently SAP has detected a problem in the spool area which affects all customers in the world regardless of the SAP release and any support package level. As soon as the retention time of a spool request exceeds 2009/12/31, a wrong date 2100/01/01 is entered during creation of the spool request. As a consequence these spool requests will not be deleted anymore from the spool reorg jobs. Using the default retention period this affects all spool requests on each SAP system in the world created since 2009/12/23.
Please refer the SAP note 1422843 for further details. The SAP note 1422843 is to be implemented immediately in all the SAP systems. There is a ABAP report attached in this note 1422843 for the SAP Basis releases 46C to 7xx releases. This report is to be imported in all the SAP systems in the transaction SE38 schedule a periodic job, with a period analogous to the spool reorg job with the report as step, before the real spool reorg job.