Tag: Data archiving

Archiving MM- Accounting interface posting data

This blog will explain how to archive MM accounting interface posting data via object MM_ACCTIT. Generic technical setup must have been executed already, and is explained in this blog.

The MM_ACCTIT is strange object. Since it is about intermediate data which is normally not viewed by users, there is no read program. In worst case there is a reload program. Do also read about the option to stop using these intermediate tables if the business does not require them.

Avoiding data in MM-accounting interface tables

Please check OSS note 48009 – Tables ACCTHD, ACCTIT, ACCTCR: Questions and answers to see if you can fully avoid data being written to the tables.

Object MM_ACCTIT

Go to transaction SARA and select object MM_ACCTIT.

Dependency schedule (no dependency):

Tables that are archived:

Technical programs and OSS notes

Write program: MM_ACCTIT_WRI

Delete program: MM_ACCTIT_DEL

Read program: none. Only write and delete.

Relevant OSS notes:

Application specific customizing

MM_ACCTIT has no application specific customizing.

Executing the write run and delete run

In transaction SARA, MM_ACCTIT select the write run:

Select your data, save the variant and start the archiving write run.

After the write run is done, check the logs. MM_ACCTIT archiving has high speed and high percentage of archiving (up to 100%).

Deletion run is standard by selecting the archive file and starting the deletion run.

Data archiving: CO line items

This blog will explain how to archive CO line items via object CO_ITEM. Generic technical setup must have been executed already, and is explained in this blog.

Object CO_ITEM

Go to transaction SARA and select object CO_ITEM.

Dependency schedule (no dependency):

Tables that are archived:

Most important:

  • COEP: CO line items
  • COBK: CO object document header

Technical programs and OSS notes

Write program: CO_ITEM_WRI

Delete program: CO_ITEM_DEL

Read program: RKCOITS4

Relevant OSS notes:

Application specific customizing

In the application specific customizing for CO_ITEM you have to set the residence time in months per CO type:

Executing the write run and delete run

In transaction SARA, CO_ITEM select the write run:

Select your data, save the variant and start the archiving write run.

Give the archive session a good name that describes date range. This is needed for data retrieval later on.

After the write run is done, check the logs. CO_ITEM archiving has average speed, but high percentage of archiving (up to 100%).

Deletion run is standard by selecting the archive file and starting the deletion run.

Data retrieval

Start the data retrieval program and fill selection criteria:

Data archiving: purchase documents

This blog will explain how to archive purchase orders and purchase documents via object MM_EKKO. Generic technical setup must have been executed already, and is explained in this blog.

Object MM_EBAN

Go to transaction SARA and select object MM_EKKO.

Dependency schedule:

No dependencies.

Main tables that are archived:

  • EKKO: purchase document header
  • EKPO: purchase document item

Technical programs and OSS notes

Pre-processing program: RM06EV70

Write program: RM06EW70

Delete program: RM06ED70

Read program: RM06ER30

Relevant OSS notes:

Application specific customizing

In the application specific customizing for MM_EKKO you can maintain the document retention time settings:

You have to set the residence time per purchase order type:

Preprocessing

In transaction SARA, MM_EKKO select preprocessing:

There are quite some reasons why a purchase order cannot be archived.

Executing the write run and delete run

In transaction SARA, MM_EKKO select the write run:

Select your data, save the variant and start the archiving write run.

Give the archive session a good name that describes the purchasing group and year. This is needed for data retrieval later on.

After the write run is done, check the logs. MM_EKKO archiving has average speed, and medium percentage of archiving (50 to 90%).

Deletion run is standard by selecting the archive file and starting the deletion run.

Data retrieval

For MM_EKKO start the read via SARA:

Then select the archive file(s).

Result is in a simple list.

Data archiving: change documents

This blog will explain how to archive change documents via object CHANGEDOCU. Generic technical setup must have been executed already, and is explained in this blog.

Object CHANGEDOCU

Go to transaction SARA and select object CHANGEDOCU.

Dependency schedule: (none):

Change documents are archived as part of other archiving objects. For specific changes you might want to archive the changes sooner to get a grip on CDHDR and CDCLS/CDPOS table sizes and amount of entries.

Main tables that are archived:

  • CDHDR (change header)
  • CDCLS (change details)

Technical programs and OSS notes

Write program: CHANGEDOCU_WRI

Delete program: CHANGEDOCU_DEL

Read program: CHANGEDOCU_READ

Reload program: CHANGEDOCU_REL

Relevant OSS notes:

Application specific customizing

No application specific customizing is required for CHANGEDOCU archiving.

Executing the write run and delete run

In transaction SARA, CHANGEDOCU select the write run:

Select your data, save the variant and start the archiving write run.

Give the archive session a good name that describes change document object(s) and year. This is needed for data retrieval later on.

After the write run is done, check the logs. CHANGEDOCU archiving has average speed and very high percentage of archiving (up to 100%).

Deletion run is standard by selecting the archive file and starting the deletion run.

Data retrieval

Don’t start the data retrieval program from SARA. Start program CHANGEDOCU_READ from SA38:

In the second screen select the archive files. Now wait long time before data is shown.

For faster retrieval, setup data archiving infostructures SAP_CHANGEDOCU1 and SAP_CHANGEDOCU2. These are not active by default. So you have to use transaction SARJ to set them up and later fill the structures (see blog).

Now transaction RSSCD100 can be use for data retrieval:

Don’t forget to select the tick box “Read from archive info system”.

Data archiving: purchase requisitions

This blog will explain how to archive purchase requisitions via object MM_EBAN. Generic technical setup must have been executed already, and is explained in this blog.

Object MM_EBAN

Go to transaction SARA and select object MM_EBAN.

Dependency schedule:

No dependencies.

Main table that is archived:

  • EBAN (Purchase requisitions)

Technical programs and OSS notes

Pre-processing program: RM06BV70

Write program: RM06BW70

Delete program: RM06ID70

Read program: RM06BR30

Relevant OSS notes:

Application specific customizing

In the application specific customizing for MM_EBAN you can maintain the document retention time settings:

You have to set the residence time per requisition type:

Preprocessing

In transaction SARA, MM_EBAN select preprocessing:

There are quite some reasons why a purchase requisition cannot be archived.

Executing the write run and delete run

In transaction SARA, MM_EBAN select the write run:

Select your data, save the variant and start the archiving write run.

Give the archive session a good name that describes the purchasing group and year. This is needed for data retrieval later on.

After the write run is done, check the logs. MM_EBAN archiving has average speed, and medium percentage of archiving (50 to 90%).

Deletion run is standard by selecting the archive file and starting the deletion run.

Data retrieval

For MM_EBAN start the read via SARA:

Then select the archive file(s).

Result is in a simple list:

Data archiving: WM transfer requirements and orders

This blog will explain how to archive WM transfer orders and requirements via objects RL_TA and RL_TB. Generic technical setup must have been executed already, and is explained in this blog.

Objects RL_TA and RL_TB

Go to transaction SARA and select object RL_TA and RL_TB.

Dependency schedule (no dependencies for both):

Main tables that are archived:

  • LTAK (transfer order header)
  • LTAP (transfer order item)
  • LTBK (transfer requirement header)
  • LTBP (transfer requirement item)

Technical programs and OSS notes

RL_TA:

Write program: RLREOT00S

Delete program: RLREOT10

Read program:RLRT0001

RL_TB:

Write program: RLREOB00S

Delete program: RLREOB10

Read program: RLRB0001

Relevant OSS notes:

Application specific customizing

RL_TA and RL_TB don’t have application specific customizing.

Typically RL_TA and RL_TB will yield 90 to 100% documents that can be archived.

Executing the write run and delete run

In transaction SARA, RL_TA or RL_TB select the write run:

Select your data, save the variant and start the archiving write run.

Give the archive session a good name that describes sales warehouse and year. This is needed for data retrieval later on.

After the write run is done, check the logs. RL_TA and RL_TB archiving has average speed, and a high percentage of archiving (up to 90 to 100%).

Deletion run is standard by selecting the archive file and starting the deletion run.

Data retrieval

Start the data retrieval program and fill selection criteria for transfer orders:

Start the data retrieval program and fill selection criteria for transfer requirements:

In the popup screen select the wanted archive files.

Data archiving: CO Order data

This blog will explain how to archive CO Order data via object CO_ORDER. Generic technical setup must have been executed already, and is explained in this blog.

Object CO_ORDER

Go to transaction SARA and select object CO_ORDER.

Dependency schedule:

This means you must first archive relevant purchase requisitions, purchaser orders and financial documents relating to the CO order..

Tables that are archived:

Most important:

  • COEP: CO line items

Technical programs and OSS notes

Pre-processing program: RKOREO01

Write program: RKAARCWR

Delete program: RKAARCD1

Read program: RKAARCS1

Relevant OSS notes:

Application specific customizing

In the application specific customizing for CO_ORDER you have to set two retention periods per CO order type:

Residence time 1 determines the time interval (in calendar months) that must elapse between setting the delete flag (step 1) and setting the deletion indicator (step 2).

Residence time 2 determines the time (in calendar months) that must elapse between setting the deletion indicator (step 2) and reorganizing the object (step 3).

Executing the pre-processing run

The pre-processing run will set the deletion indicator for the CO Orders:

The output is a list of orders that are processed, and if not processed, the reason of blocking is written down.

Executing the write run and delete run

In transaction SARA, CO_ORDER select the write run:

Select your data, save the variant and start the archiving write run.

Give the archive session a good name that describes date range. This is needed for data retrieval later on.

After the write run is done, check the logs. CO_ORDER archiving has average speed, but high percentage of archiving (up to 100%). Reason is that all filtering and checking is already done by the pre-processing program.

Deletion run is standard by selecting the archive file and starting the deletion run.

Data retrieval

Start the data retrieval program and fill selection criteria:

Result is a list. From the list double click on the order. You can see the order now in normal GUI layout.

Data archiving: CATS time writing data

This blog will explain how to archive CATS time writing data via object CATS_DATA. Generic technical setup must have been executed already, and is explained in this blog.

Object CATS_DATA

Go to transaction SARA and select object CATS_DATA.

Dependency schedule:

This means no dependencies.

Only table that is archived:

  • CATSDB: time writing data

Technical programs and OSS notes

Write program: RCATS_ARCH_ARCHIVING

Delete program: RCATS_ARCH_DELETING

Read program: RCATS_ARCH_READING

Relevant OSS notes:

Application specific customizing

In the application specific customizing for CATS_DATA is not required.

Executing the write run and delete run

In transaction SARA, CATS_DATA select the write run:

Select your data, save the variant and start the archiving write run.

Give the archive session a good name that describes date range. This is needed for data retrieval later on.

After the write run is done, check the logs. CATS_DB archiving has average speed, but high percentage of archiving (up to 100%). Only status 30 (approved) and status 60 (cancelled) are archived. See SAP Help.

Deletion run is standard by selecting the archive file and starting the deletion run.

Data retrieval

Start the data retrieval program and fill selection criteria:

Result is a simple list:

Data reload program

For emergency cases, there is an undocumented reload program: RCATS_ARCH_RELOADING. Use at own risk.

Data archiving: sales orders

This blog will explain how to archive sales orders via object SD_VBAK. Generic technical setup must have been executed already, and is explained in this blog.

Object SD_VBAK

Go to transaction SARA and select object SD_VBAK.

Dependency schedule:

In case you use production planning backflush, you must archive those first. Then material documents, shipment costs (if in use), SD transport (if in use), deliveries (if in use), purchase orders and purchase requisitions related to the sales order.

Main tables that are archived:

  • NAST (for the specific records)
  • VBAK (sales order header)
  • VBAP (sales order item)
  • VBEP (sales order schedule line data)
  • VBFA (for the specific records)
  • VBOX (SD Document: Billing Document: Rebate Index)
  • VBPA (for the specific records)
  • VBUP (sales order status data)

Technical programs and OSS notes

Preprocessing program: S3VBAKPTS

Write program: S3VBAKWRS

Delete program: S3VBAKDLS

Read program: S3VBAKAU

Relevant OSS notes:

Application specific customizing

In the application specific customizing for SD_VBAK you can maintain the document retention time settings:

Executing the preprocessing run

In transaction SARA, select SD_VBAK. In the preprocessing run the documents to be archived are prepared:

Check the log for the results:

Typically SD_VBAK will yield 30 to 70% documents that can be archived.

Executing the write run and delete run

In transaction SARA, SD_VBAK select the write run:

Select your data, save the variant and start the archiving write run.

Give the archive session a good name that describes sales organization/shipment point and year. This is needed for data retrieval later on.

After the write run is done, check the logs. SD_VBAK archiving has average speed, but not so high percentage of archiving (up to 40 to 90%).

Deletion run is standard by selecting the archive file and starting the deletion run.

Data retrieval

Start the data retrieval program and fill selection criteria:

In the second screen select the archive files. Now wait long time before data is shown.

For faster retrieval, setup data archiving infostructures SAP_SD_VBAK_001 and SAP_SD_VBAK_002. These are not active by default. So you have to use transaction SARJ to set them up and later fill the structures (see blog).

Data archiving: SD invoices

This blog will explain how to archive SD invoices via object SD_VBRK. Generic technical setup must have been executed already, and is explained in this blog.

Object SD_VBRK

Go to transaction SARA and select object SD_VBRK.

Dependency schedule:

In case you use production planning backflush, you must archive those first. Then material documents, shipment costs (if in use), SD transport (if in use) and deliveries (if in use).

Main tables that are archived:

  • NAST (for the specific records)
  • VBFA (for the specific records)
  • VBOX (SD Document: Billing Document: Rebate Index)
  • VBPA (for the specific records)
  • VBRK (invoice headers)
  • VBRP (invoice line items)
  • VBUK (invoice status)

Technical programs and OSS notes

Preprocessing program: S3VBRKPTS

Write program: S3VBRKWRS

Delete program: S3LIKPDLS

Read program: S3VBRKAU

Relevant OSS notes:

Application specific customizing

In the application specific customizing for SD_VBRK you can maintain the document retention time settings:

Executing the preprocessing run

In transaction SARA, select SD_VBRK. In the preprocessing run the documents to be archived are prepared:

Check the log for the results:

Typically SD_VBRK will yield 30 to 70% documents that can be archived.

Executing the write run and delete run

In transaction SARA, SD_VBRK select the write run:

Select your data, save the variant and start the archiving write run.

Give the archive session a good name that describes sales organization/shipment point and year. This is needed for data retrieval later on.

After the write run is done, check the logs. SD_VBRK archiving has average speed, but not so high percentage of archiving (up to 40 to 90%).

Deletion run is standard by selecting the archive file and starting the deletion run.

Data retrieval

Start the data retrieval program and fill selection criteria:

In the second screen select the archive files. Now wait long time before data is shown.

For faster retrieval, setup data archiving infostructures SAP_SD_VBRK_001 and SAP_SD_VBRK_002. These are not active by default. So you have to use transaction SARJ to set them up and later fill the structures (see blog).