Ansicht
Dokumentation

REA_EVER_ARCHIVE - Archive Utility Contracts

REA_EVER_ARCHIVE - Archive Utility Contracts

SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up   BAL_S_LOG - Application Log: Log header data  
This documentation is copyright by SAP AG.
SAP E-Book

Title

Archive Contracts

Purpose

Archiving consists of the following two steps:

  1. Analysis and test of archivability of contracts
  2. Writing of contracts to an archive file, based on the analysis executed in the first step

The Archive contracts report is the first step.

The archiving object comprises the following contract data:

  • EVER: IS-U Contract
  • EVERH: IS-U Contract History (reference values) - currently not supported because replicated IS-U contracts are not archived

The archiving object for contracts is ISU_EVER.

Use transaction AOBJ to find the definition of the archiving object and the corresponding Customizing settings.

Use transaction SARA to find the archive administration and the corresponding Customizing settings.

Use transaction SARI to find the technical view for the archived contracts.

Integration

The archiving of contracts incorporates the following reports:

  1. Archiving Report

    The system analyzes contracts. Those documents that can be archived are written to the archive file.
  2. Deletion Reports

    Contracts in the archive file are deleted from the corresponding database tables.

Prerequisites

Features

The archiving report selects only contracts whose retention period has expired.

You can define the retention period in Customizing, under Define Retention Period for Archiving Objects (SAP Utilities → Tools → Archiving → Define Retention Period for Archiving Objects).

You can use the ISU_EVER_ARCHIVE BAdI in a subsequent analysis process to define additional checks for the archivability of contracts.

Please note that if IS-U-CRM Sales Integration is active (that is, IS-U contracts are replicated to CRM), the replicated IS-U contracts cannot be archived!

Archivability Checks:

Different kind of checks are performed before archiving a contract. These checks can be grouped by areas.

  • Retention period check.A contract is archived if:
  • The retention date set in Customizing is greater than the move-out date and the customer was billed. For example, if the Retn. Per. field for terminated contracts contains 30 days, then a contract can only be archived if at least 30 days have passed since the move-out date and if the customer was billed.

  • The reversed retention date is greater than the creation date of the contract and the move-out date is set to initial date (that is, to 0000).

    Note: The retention period for contracts set in Customizing should be large enough so that productive settlement runs and supply scenario analyses are not affected by archiving.

  • Device management area checks. A contract is archived if:
  • There are no meter reading results for that contract

  • There are no billing orders for the installation linked to that contract

  • Billing area checks. A contract is archived if:
  • There are no billing documents for that contract.

  • The contract itself is not a master agreement.

  • The contract is not used as a contract pattern for simulation purposes
    (view cluster VC_EASIM).

  • There is no entry in index table ERCHARC with document's archiving status <> 5 (Document header has been archived).

  • Invoicing area checks. A contract is archived if:
  • There are no budget billing plans (of any kind) in the system that depend on this contract.

  • There are no print documents in the system that refer to this contract.

  • There is no tax relevant data in the system that refers to the contract and that have not been extracted yet.

  • FI-CA specific checks.A contract is archived if:
  • There are no FI-CA documents for that contract.

  • There are no security deposits for that contract.

  • There are no orders for that contract.

  • There are no sample documents for that contract.

For a contract to be archived, all the checks listed above should be satisfied.

Selection

You can make the following settings when you start the report:

  • Contract: Restrict the selection to specific contracts, or to a range of documents.
  • Test mode: No changes are made in the database if you start the report in test mode.
  • Detail log: Write detailed information to the log for each analyzed data record. On the report selection screen, the user can choose to hide this information in the report by selecting No Detail Log, or see only error messages by selecting Without Success Message, if desired.
  • Log output: Controls the way information appears on the screen.

In variant maintenance for the write program the following actions from SAP NetWeaver Information Lifecycle Management are available:

  • Archiving
With this action, you can archive the data of closed business objects. The system performs archivability checks to check if the data can be archived. In this respect, this function corresponds to the function of standard data archiving that you are used to. By means of the ILM enhancements, the system evaluates the rules maintained in the Information Retention Manager (IRM) for each object instance during the write phase, and thereby determines the retention period and the storage location for the object. This information is persisted on the database as part of the management data and is later interpreted when the data is stored.
  • Snapshot
Snapshots represent archiving runs that extract data from the database, but do not delete this data from the database. Except for considering the restrictions in the selection variant, the system does not perform any additional checks. Using this option, therefore, you can also write data from current, not yet completed business transactions to the archive. To exclude the possibility of losing data, runs of this type are not offered for deletion. With snapshots therefore, you always create redundant copies of data from the database. This function is especially useful for system decommissioning in conjunction with the ILM component Retention Warehouse.
  • Destruction of Data
The destruction of data from the database takes place using an archiving write run followed by a deletion run. During this process, temporary archive files are created that are then deleted again after the deletion phase is completed. The system automatically deletes these files along with the file-related management data. The technical classification of a run as a destruction run is made using the parameter DESTROY. If an archiving object is not registered in IRM, the parameter DESTROY is completely ignored, and a normal archiving run takes place.

Standard Variants

Output

Activities

Example






BAL Application Log Documentation   Fill RESBD Structure from EBP Component Structure  
This documentation is copyright by SAP AG.

Length: 9491 Date: 20240520 Time: 134211     sap01-206 ( 123 ms )