Purpose of this blog

This blog might be hints to answer questions you might come up with when you archive SD documents with attachments.

Those questions might be:
– In which tables those attachments are stored?
– Not all DB table entries are deleted after deletion run. Why?

Please note that archiving attachments is cross-area with Basis and the topic is not covered by Application side only.

1. Overview / Basic Information
As explained on SAP Note 2940339 (Archiving of attachments in SD: Additional parameters), it is possible to archive attachment of SD documents as of S/4HANA 1809.

You can do it by “Archive Attachments” flag.

[ Figure 1: Write program of archiving object SD_VBAK ]

[ Figure 2: Attachment of SD document ]

The attachment function uses GOS (Generic Object Services) framework. It is a classic function and you will find lots of information on several resources.

2. Prerequisite
You need to use user parameter SD_SWU_ACTIVD = X to enable a button to attach documents.

Then you will see the button on SD document.

3. Database table
Related tables are SOOD and SOFM.

You will find entries in those tables when you have attachments on SD documents.

[ Figure 3: DB tables ]
On SOOD, find a related entry by using user ID (your ID) OWNNAM and language (OBJLA) etc.

SOFM entry can be found by using SOOD-OBJYR into SOFM-DOCYR and SOOD-OBJNO into SOFM-DOCNO.

Refer to the following SAP Note, too.

904711 – SAPoffice: Where are documents physically stored?
530792 – Storing documents in the generic object services
2571570 – Where are documents physically stored with Business Communication Services?

4. Archiving Object / Archiving Class
When SD documents with attachments are archived by an archiving object SD_VBAK, an archiving class SGOS is called, and then SBCS.

[ Figure 4: Archiving object definition (T-cd: AOBJ) ]

[ Figure 5: Define Archiving Classes (T-cd: ACLA) ]

5. Post-processing (delete remaining tables)
Archiving SD documents with flag “Archive Attachments” only deletes table SOFM.

You need to run a report RSBCS_REORG to delete SOOD and SOC3.
Basically it is recommended to schedule this report on regular basis in the customer’s system.

This report has Test Mode flag by default.
You can check the result before actually deleting the records.

[ Figure 6: Report RSBCS_REORG ]

You will find that SOOD entry is deleted after this report.