Understanding the Data that Is Archived 

Data archiving in mySAP CRM is similar to that in SAP R/3. In both, documents that were created within an application and that contain all the data that belongs to a concrete business event, are archived using archiving objects. However, instead of the term document, CRM uses the more general term, business object, or, as in CRM transaction processing, the term business transaction. To be able to understand CRM data archiving it is necessary to have a clear picture of the relationship between an archiving object and the data that will be archived. The following background information will help you better understand CRM data archiving.

Relationship Between Business Transaction Type, Business Transaction Category and Archiving Object

A Business Transaction (CRM) is composed of a number of different data, which is stored in separate database tables. During archiving, the data definitions saved in the archiving object ensure that all data that belongs to a specific business transaction is written to the archive, if necessary. This helps ensure that the archived business transaction is complete and that it can be displayed properly later.

Business Transaction Type and Business Transaction Category

A CRM business transaction (i.e. sales order, visit, or service order) is described by exactly one Transaction Type (see graph). The transaction type defines the structure of the business transaction, including the tables involved, which are also relevant in connection with data archiving. In addition, the transaction type controls the processing of the business transaction and determines the control attributes (i.e. text schema, partner schema, status schema, organizational profile). In other words the transaction type defines the properties and characteristics of a business transaction, as well as the default values and how these are processed. A business transaction is always created in reference to a transaction type.

One or more business transaction categories (i.e. contract, sales, service) are assigned to a transaction type. The business transaction category determines the business context in which the transaction type can be used (i.e. service, sales, activity). Business transaction categories are created in the Business Object Repository (BOR), and are therefore also referred to as BOR objects. A business transaction category is defined either on the transaction head level or on the transaction item level. The head transaction category can be further divided into leading business transaction category and subcategory. A leading head transaction category can have 0 to n subcategories.

The business transaction category is pre-defined by the system, while users can define the transaction type in customizing themselves. Thus, through the concept of the business transaction it is possible to enter items from different business contexts in the same transaction.  For example, in one transaction you can sell products and also enter complaint or return items.

Sets and Extensions

The actual data of a business transaction is stored in tables that belong to “sets” and “extensions”. Business transaction categories do not have tables. They merely serve a logical function in the structure of a business transaction. Sets and extensions are not defined in the Business Object Repository, because they are not BOR objects. From a technical point of view, sets and extensions are implemented as a software package that contains several function groups. Data archiving is included in this package through its own function group.

·        Extension: is an addition to a business transaction; it contains further information about the business transaction and describes the business transaction more closely from a business perspective. An extension can exist either for the transaction itself, on the head level, or for the item that belongs to the transaction. Examples of extensions are CUSTOMER_H (head extension for the enhancement of customer data) and FINPROD_I (items extension for financial data).

·        Set: is also an addition to a business transaction.   It can exist for the transaction (on head level), for the transaction item or for both. A set is used to store data that is relevant for the transaction or also for the items. Examples of sets are shipping information, organizational unit, and partner data. Sets can be reused and therefore help prevent data redundancy.

For more information about this topic see the data model for CRM Business Transactions in the SAP Service Marketplace under /modeling ® Documentation.

Role of the Archiving Object

What does this mean for data archiving? Each archiving object has n leading head transaction categories assigned to it. The head transaction categories are assigned to the archiving object in the transaction DA_CONTROL.  Thus, when you archive a business transaction, all table entries that belong to a leading head transaction category (saved in the category’s sets and extensions), and all table entries that are assigned to head or item transaction categories (also saved in the category’s sets and extensions), are copied to the archive.  The following graph shows the relationships described above:

The graph shows that a business transaction is made up of a leading head transaction category and one or more head transaction subcategories (optional).  The leading head transaction category can have one or more item transaction categories. The head and item transaction categories in turn can have one or more sets or extensions. The number of permitted sets and extensions is determined in Customizing. A transaction type does not have to use all the permitted sets and extensions. The figures in the graph show the relationships between the individual objects.

Example

The business transaction categories CRM Sales Transaction (BUS2000115) and CRM Business Activity (BUS2000126) are assigned to the transaction type Standard Order (see graph below).   CRM Sales Transaction is the leading category. The item categories CRM Sales Item (BUS2000131) and CRM Customer Substitute Delivery Item (BUS2000165) are assigned to this leading business transaction category.

The business transaction categories have the following sets and extensions (extract):

Business Transaction Type	Set or Extension
BUS2000115	BILLING, CUMULAT_H, CUSTOMER_H, PARTNER, TEXTS
BUS2000126	ACTIVITY_H, APPOINTMENT, CUSTOMER_H
BUS2000131	APO_I, TEXTS
BUS2000165	PARNTER, TEXTS

On the head and the item level you always have the superset of the sets and extensions; the sets and extensions are thus copied only once by the write program, even if they occur more than once. Sales orders are archived using archiving object CRM_SALDOC. The following graph shows the above named example:

See also:

Attachments and Linkages in a Document Flow