Online Tutorials & Training Materials | STechies.com
Register Login

Tables ACCTHD, ACCTIT, ACCTCR Questions and Answers

|| 0

Tables ACCTHD, ACCTIT, ACCTCR Questions and Answers
Stechies

The tables ACCTHD, ACCTIT and ACCTCR are increasing in size and use a lot of space in the database. You have the following questions:

1. Which data is updated in the ACCT* tables?

The documents of MM Inventory Management and MM Invoice Verification do not contain all the information required for an update in Accounting. Certain additional information is known only during the life of the original posting. These documents are unsuitable for subsequent postings. For this reason, when you post goods movements and invoice receipts (reference types MKPF and RMRP), the call of the accounting interface is documented in the form of documents in the tables ACCTHD, ACCTIT and ACCTCR.

With Note 1228011, PRCHG, MLHD and MLCU was added to the list of AWTYP's.Note 316468 describes how you can determine the organizational units and periods to which the data of the ACCT tables is assigned.

2. For what are these tables required?

This information is stored for applications which are to be supplied with the posting data of MM Inventory Management and MM Invoice Verification at a later date. This concerns the following applications:

Special Purpose Ledger (FI-SL)
Profit Center Accounting (EC-PCA)
Controlling (CO)
Public Sector Funds Management (PSM-FM)

The reason for subsequent posting may be:

You plan to use an application in production at a later point and to use data of past periods in this application.

You use an application in production but you do not provide the data online. You can check whether this is the case using the following Customizing transactions:

Special Purpose Ledger (FI-SL): Call transaction GCD1 and select FI-SL as origin of original document. Enter the posting status and choose Goto -> Posting test. Enter a transaction and select other parameters, if necessary. Execute the transaction.

The diagnosis outputs a list of FI-SL ledgers which are directly supplied, or supplied by means of subsequent posting (depending on the selected posting status), with data of the selected transaction.

Controlling (CO): for active CO components (cost centers, orders, and so on), the data is always transferred online. You can use transaction OKKP to check whether a component is active. Select a controlling area, choose Activate components/control indicators and double-click the relevant fiscal year. (The settings specified below are relevant for the profit center).

Profit Center Accounting (EC-PCA): Call transaction 1KEF and enter a controlling area. If the 'Online transfer' checkbox is selected, the system transfers the data of the corresponding years online.

Funds Management Public Sector (IS-PS-FM): If this component is active, the system transfers the MM Inventory Management data and MM Invoice Verification online.

Two options for subsequent postings:

Transaction GCU4 or OKBB (program RGUREC30): subsequently posting from the datasets of the ACCT* tables of MM data into the above-mentioned applications. As far as completeness of subsequently posted data is concerned, this is the method to be recommended. However, it entails a considerable data volume in the ACCT* tables.

Transaction GCU1 or OKBA (program RGUREC10): subsequently posting from the datasets of the FI documents into the above-mentioned applications. The ACCT* tables are NOT used in this case. You could do without the tables being updated and reduce the amount of work for the database.

Note:When you subsequently post FI data that originates from MM Inventory Management or MM Invoice Verification, the system first checks as to whether data is also contained in the ACCT* tables. If data is found, no subsequent posting is made. As of Release 3.1H, you have the option of deactivating the above procedure ('Transfer MM, SD, and HR docs' indicator) so that FI documents that originate from MM Inventory Management or MM Invoice Verification types are subsequently posted in this case also.

The disadvantage associated with this variant is that information may be lost, since an FI document might not contain all the data or certain data is summarized at your wish. Therefore, compare the fields of the tables BSEG and ACCT*. Consider possible summarizations set for table BSEG (see Note 36353). If the additional fields of the ACCT* tables are not important for you, subsequently posting from the dataset of the FI documents does not entail any disadvantages for you.

Joint Venture Accounting (CA-JVA) also uses the tables.

Apart from the reasons mentioned above, you require the ACCT* tables if errors occurred during the through posting of MM Inventory Management documents or MM Invoice Verification documents. You can correct errors of this type by using the information from the ACCT* tables.

For audit purposes, the ACCT* tables are not used by AIS and DART in the standard. However, the user exit technology in DART enables you to tailor the increase the data volume, that is, ACCT* tables also.

In the material ledger (actual costing, CO-PC-ACT), the value flow monitor (transaction CKMVFM) can be used to analyze differences in price difference accounts.

It is also possible to compare the posted values in FI with the material ledger. For special stocks, this option is useful only if the update of the table ACCTIT is activated.

For analyzing special stocks, the value flow monitor cannot determine all the required information from the FI documents. All missing information is read from the table ACCTIT. If the update of the table ACCTIT is not activated, the special stock differences are assigned to the stock materials in the value flow monitor. The total of the differences for a material is then correct. However, it is not apparent whether the differences are relevant for the warehouse stocks or the special stock.

The value flow monitor can also be executed without the "Reconciliation FI with ML" option. Then the update of the table ACCTIT does not play any role.

3. Is the data relevant to euro?

The tables ACCTHD, ACCTIT and ACCTCR are not converted during the local currency changeover. Therefore, the data from these tables can no longer be used for subsequent postings after a local currency changeover.

Prior to the local currency changeover or immediately after it at the latest, you should either delete this data in all (converted) clients to be converted or archive it (only then for audit purposes).

If the tables are not very large, you can keep them in the database and delete or archive them after the local currency changeover. If errors occur during the local currency changeover, the ACCT* tables could help you to localize and eliminate the error (only for documents with the reference types MKPF and RMRP).

4. Is it possible to do without an update of the tables?

A functional disadvantage in the case of missing ACCT* table entries relates to the subsequent postings in the above cases.

There are the following scenarios:

You transfer data online to active R/3 components. You do not have any future plans to supply new components with older posting data from MM Inventory Management or MM Invoice Verification. In this case, you can deactivate the update of the tables and delete their contents.

You do not transfer online the data from MM Inventory Management or MM Invoice Verification to the above-mentioned active R/3 components but post it subsequently from the FI documents (transaction GCU1 or OKBA). You have future plans to supply new components with older posting data from MM Inventory Management or MM Invoice Verification using the FI documents. In this case, you can deactivate the update of the tables and delete their contents.

You do not transfer online the data from MM Inventory Management or MM Invoice Verification to the above-mentioned active R/3 components but post it subsequently from the ACCT* tables (transaction GCU4 or OKBB).

As soon as you have subsequently posted a part of the data, you should delete it from the ACCT* tables. If the subsequent posting is made much later, you can alternatively archive the data to then reload it for subsequent posting into the database. However, you must not reset the MM number ranges in this case (see Note 83076)!

Check whether you can subsequently post data using the FI document (transaction GCU1 or OKBA). If so, you can deactivate the update of the ACCT* tables and delete their contents.

You have future plans to supply new components with older posting data from MM Inventory Management or MM Invoice Verification using the ACCT* tables .

You can archive the data to then reload it for subsequent posting to the database. However, you must not reset the MM number ranges in this case (see Note 83076)!

Check whether you can subsequently post data using the FI document (transaction GCU1 or OKBA). If so, you can deactivate the update of the ACCT* tables and delete their contents.

For missing ACCT* table entries, errors that occurred during the through posting of MM Inventory Management documents or MM Invoice Verification documents cannot be corrected or can only be corrected with difficulty. If this aspect is important to you, SAP recommends that you do not deactivate the updating of the ACCT* tables and delete its contents. SAP recommends you to continue updating the tables and to reduce the work of the database through regular archiving.

5. How can a table update be deactivated or activated?

For this purpose, implement the corrections for the function module AC_DOCUMENT_CREATE (program LRWCLU01). After you do so, no new records are written in the ACCT* tables. You should also implement the source code modifications that are contained in Note 821161 in your system.

If you wish the tables to be updated in the future, undo this correction. Afterwards, the ACCT* tables are updated again as before the deactivation.

6. How can the tables be archived?

You can archive the data for the purpose of

- a later subsequent posting
- correcting through-posting errors

Bear in mind the restrictions concerning the local currency changeover and the resetting of MM number ranges (Note 83076).

Note 83076 describes archiving, reading and reloading the ACCT* tables.

7. How can the tables be deleted?

First deactivate the update of the tables as described under point 5.

Delete the tables ACCTHD, ACCTIT and ACCTCR.

Delete the contents of the table for all clients using database tools. This is the fastest and safest method. The advantage of this method lies in the reorganization, which is automatically made by the database.

For this purpose, call transaction SE14 for the tables ACCTHD, ACCTIT, ACCTCR and carry out the steps 'Delete database table' and then 'Create database table'.

If you want to delete data in particular clients only, use the program (ZZTTAMAC) described in the attachment "ZZTTAMAC.TXT". It deletes the tables ACCTHD, ACCTIT and ACCTCR completely in the current client. Depending on the data volume, runtimes may be long.

Create the program (transaction SE38) and execute it.

8. Is the data relevant for the new G/L migration?

In the case of a migration without document splitting, the ACCT* tables have no significance.

When you use the document splitting, the tables are required only in a very specific exceptional case, namely if a splitting is performed for each logical transatcion (LOGVO). However, for this to happen, the FI summarization must not be active. In all other cases, the ACCT* tables are not relevant for the migration and can be archived, deleted or deactivated, or must not be activated if they are already deactivated.