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.