Хорошие таблички, отчеты удобно делать... Вот решил поделиться инфой, т.к. многих они смущают и в некоторых случаях неоправданно используют bseg
The tables ACCTHD, ACCTIT and ACCTCR become larger and larger and use a lot of space in the database. The following questions arise:

1. Which data is updated in the ACCT* tables?
2. What is the data required for?
3. Are the tables affected by the local currency changeover?
4. Is it possible to do without an update of the tables?
5. How can a table update be deactivated and activated again?
6. How can the tables be archived?
7. How can the tables be deleted?

Other terms
FI/CO interface, RWCL, ADK, archiving, local currency changeover
Function modules: AC_DOCUMENT_CREATE, AC_DOCUMENT_POST, DOCUMENT_MM_POST
Archiving object MM_ACCTIT
Tables: ACCTIT, ACCTHD, ACCTCR, EURO
Programs: RGUARCMM, RGUDELMM, RGUREC30
Transaction: GCU4, GCU1, OKBA, OKBB


Reason and Prerequisites
Missing information. Missing archiving.

Solution
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 only known 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 FI/CO interface is documented in the form of documents in the tables ACCTHD, ACCTIT and ACCTCR.



Note 316468 describes how you can ascertain to which organizational units and periods the data of the ACCT tables is assigned.



1. What are these tables required for?
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. The following applications are relevant:

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


The reason for subsequent posting may be:

You plan to use an application later in production 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 up 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, or by subsequent posting (depending on the selected posting status), supplied with data of the selected transaction.
Controlling (CO): for active CO components (cost centers, orders, etc.), 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 then double-click the desired fiscal year.(For profit centers, also make the settings specified further below.).
Profit Center Accounting (EC-PCA): Call up 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 Government (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 the data posted subsequently 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 them being updated and reduce the amount of work for the database.
Note:
When you subsequently post FI data which originate from MM Inventory Management or MM Invoice Verification, first a check is made as to whether data is also contained in the ACCT* tables. If they are found, no subsequent posting is made. As of Release 3.1H, you have the option to deactivate the above procedure ('Transfer MM, SD, and HR docs' flag) so that FI documents which originate from MM Inventory Management or MM Invoice Verification types are subsequently posted in this case, too.

The disadvantage associated with this variant is the possibility of a loss of information, since an FI document might not contain all the data or certain data is summarized at your wish. Therefore, compare the fields of table 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 means no disadvantage for you.



Another user of the tables is Joint Venture Accounting (CA-JVA). Please refer to Notes 551618, 540178, and 565448.


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 such errors by using the information from the ACCT* tables.




For audit purposes, the ACCT* tables are not used by AIS and DART in the standard. The user exit technology in DART allows to increase the data volume according to the customer's wishes, however (i.e. also ACCT* tables).


1. Is the data relevant to euro?
The tables ACCTHD, ACCTIT and ACCTCR are not converted during the local currency changeover. The data from these tables can therefore 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 clients to be converted (or converted) or archive it (then only for auditing 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 should occur during the local currency changeover, the ACCT* tables could help you localizing and eliminating the error (only for documents with the reference types 'MKPF' and 'RMRP').



1. Is it possible to do without an update of the tables?
A functional disadvantage in 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 posted subsequently 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 in order to then reload it for subsequently posting it into the database. However, you must not reset the MM number ranges in this case (see Note 83076)!
Check whether subsequently posting data using the FI document (Transaction GCU1 or OKBA) is possible. 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 in order to then reload it for subsequently posting it to the database. However, you must not reset the MM number ranges in this case (see Note 83076)!
Check whether subsequently posting data using the FI document (Transaction GCU1 or OKBA) is possible. If so, you can deactivate the update of the ACCT* tables and delete their contents.



For missing ACCT* table entries, errors that occurred during through posting of MM inventory management documents or MM invoice verification documents cannot be corrected or only be corrected with difficulty. If this aspect is important to you, SAP recommends you not to deactivate the updating of the ACCT* tables and to delete its contents. SAP recommends you to continue updating the tables and to take a load off the database through regular archiving.


1. How can a table update be deactivated and activated again?
For this purpose apply the corrections for function module "AC_DOCUMENT_CREATE" (Program LRWCLU01). Then 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.


2. How can the tables be archived?
You can archive the data for the purpose

of a later subsequent posting
of correcting through-posting errors
Take care that you consider the restrictions concerning the local currency changeover and the resetting of MM number ranges (Note 83076).
Note 83076 describes archiving, reading and reloading of the ACCT* tables.

1. How can the tables be deleted?
First deactivate the update of the tables as described under item 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. Its advantage also lies in the reorganization which is automatically made by the database.
To do this 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 described in the correction instructions (ZZTTAMAC). 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.


Symptom
Prior to archiving or analyzing tables ACCTHD and ACCTIT, you would like to know how data in these tables is distributed to individual organizational units and periods.


Other terms
Archiving, ADK, table analysis, analysis report, analysis program
Archiving object: MM_ACCTIT


Reason and Prerequisites
This has not yet been supported up to now.


Solution
You have two options to ascertain how data in the tables ACCTHD and ACCTIT is distributed to individual organizational units and periods.

1. As of Release 4.6C:Use the tool for table analysis, which allows you to make a user-defined analysis of any table.
Call Transaction TAANA and choose 'Table analysis -> Perform check'. Enter the table name 'ACCTIT' and the analysis variant 'ARCHIVE'.
In the corresponding Customizing Transaction ANA_VAR, you can also define another variant, that is determine the fields to be analyzed. Please note:

the more fields you select, the larger the analysis results which are stored in the database. We recommend you not to select more than 3-4 fields.
the more selective the chosen fields are, the larger the analysis results which are stored in the database. We recommend you not to select fields such as document number or material number.
This solution has the disadvantage that Transaction TAANA is a general tool and therefore does not know the relationships between the tables ACCTHD and ACCTIT and thus is only suitable for the analysis of table ACCTIT (table ACCTHD contains no organizational unit or period fields).

1. Releases 3.0F through 4.6C: This note contains the source code of two programs, which analyze the tables ACCTIT and ACCTHD.
The advantage of this solution is that you can analyze the tables ACCTIT and ACCTHD at the same time (see documentation below).

Check whether the programs RGUANAM1 and RGUANAM2 exist in your system. If not, create them (using Transaction SE38 or SE80).
Program attributes:
Title: Analysis of the tables ACCTHD and ACCTIT
Type: Executable program
Development class: GBAS
Copy the source code from the correction instructions attached to this note
Text elements for RGUANAM1:
001 Entries read from ACCTIT:
002 Analysis is finished.
003 Start program RGUANAM2 for evaluating the analysis.
Text elements for RGUANAM2:
001 Date
002 System
003 Analysis of the tables ACCTHD and ACCTIT from


Documentation on reports RGUANAM1 and RGUANAM2:
-----------------------------------------------

Usage
The programs RGUANAM1 and RGUANAM2 help you to ascertain to which organizational units and to which periods the data of tables ACCTHD and ACCTIT (Compressed Data from FI/CO Document) has been assigned.

You can use this information, for example, to ascertain, prior to archiving, which data volume can be archived by using which selection criteria.


Scope of functions
The analysis is carried out in two steps.

1. Program RGUANAM1 is cross-client and reads the entire table ACCTIT. For each record, it determines the client, the company code, the year and the period as well as the reference procedure.
The program does not access table ACCTHD in order to determine the number of the corresponding document headers. It only counts for how many document headers there are line items in table ACCTIT. This is a more efficient method and brings about the same result, provided that the tables are in an orderly state. If they are inconsistent, you may find there are ACCTIT entries without the corresponding document headers (ACCTHD) or document headers without line items.

For the above-mentioned fields, the program sets up statistics on the corresponding ACCTHD and ACCTIT records and stores them in the database (table INDX). In doing so, the program deletes the data of the last statistics.

Program RGUANAM2 reads stored statistics data and creates a list containing the respective information.

As there are two programs, you can evaluate the data of an analysis several times. A further advantage is the separate setting up of the statistics, which can be time-consuming in the case of a large data volume.


Prerequisites
The program is suitable for the evaluation of table ACCTHD if its size does not exceed 1,1 GB (approx. 13.5 million lines). Otherwise, the program may terminate due to memory space problems.
For the size of table ACCTIT, there are no restrictions.


Selection
Both programs do not have a selection screen. The programs always analyze the entire table and display the entire statistics.
You cannot influence the fields to be analyzed.



Output
The result of the analyis is issued in form of a list where the number of the corresponding ACCTHD and ACCTIT records (columns 'ACCTHD', 'ACCTIT') and the total of these values (column 'ALL') is assigned to each combination of the fields Client, Company code, Fiscal year. The column with the header '%' specifies the percentage rate.


For more information on a report row, you can click the first column (character '*'). You can now see how data is distributed to the periods and the reference procedures.
Depending on the release you are using, these pieces of information are only displayed when you choose 'Expand totals' in the toolbar (a green arrow pointing downwards).


The analysis data is sorted in descending order according to the total number of corresponding records (column 'ALL').


The last row of the list specifies the total number of the ACCTHD and ACCTIT records. As far as table ACCTHD is concerned, this number may exceed the actual number of records of this table. This is because if the line items of a document refer to different company codes, years or months, the document header is contained several times in the statistics.In particular, when you consider archiving with selection restrictions for the company code, fiscal year or month, this is correct since the document header is always written into the archive but is not deleted until the archive run is carried out when all (remaining) line items are archived. These statistics therefore informs you on how many document headers would be archived but not necessarily deleted.
The '%' column should always contain the number 100. However, this value may slightly differ owing to rounding errors in totaling the percentage rates.


Activities
In order to carry out a new analysis proceed as follows:

1. Start program RGUANAM1.It has no selection screen, therefore you need not make any further entries.
We recommend you to start the program as a background job since the analysis may take much time if the data volume is large.
A test in the customer system with 45 million ACCTIT (approx. 36GB) and 1.6 million ACCTHD entries took 1 hour.
2. When the analysis is finished, start program RGUANAM2. You can call it as often as you like - it always shows the last analysis.



Known problems
If program RGUANAM1 abends due to memory problems and you cannot increase the values of the corresponding memory parameters, carry out the analysis for selected years or selected periods only. For this purpose, make the following change to program RGUANAM1:

TABLES: ACCTIT.
SELECT-OPTIONS: s_ryear FOR acctit-GJAHR. "<--- INSERT
SELECT-OPTIONS: s_monat FOR acctit-MONAT. "<--- INSERT
...
OPEN CURSOR WITH HOLD lv_cursor FOR
SELECT MANDT BUKRS GJAHR MONAT AWTYP AWREF AWORG FROM ACCTIT
CLIENT SPECIFIED. "<--- DELETE
CLIENT SPECIFIED "<--- INSERT
WHERE gjahr IN s_ryear "<--- INSERT
AND monat IN s_monat. "<--- INSERT

You now have a 'Fiscal year' and 'Fiscal month' selection field (S_RYEAR; S_MONAT). Carry out the analysis for the year/month that you expect to show the largest data volume. Print the results before carrying out the analysis for the remaining years/months because each new analysis overwrites the results of the previous analysis.

А можно в двух словах что архивируют указанные транзакции?