160 dvm guide[1]
Upcoming SlideShare
Loading in...5
×
 

160 dvm guide[1]

on

  • 385 views

 

Statistics

Views

Total Views
385
Views on SlideShare
385
Embed Views
0

Actions

Likes
0
Downloads
13
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

160 dvm guide[1] 160 dvm guide[1] Document Transcript

  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0 Dietmar-Hopp-Allee 16 D-69190 Walldorf DATE January.2012 SOLUTION MANAGEMENT PHASE SAP SOLUTION Operations & Continuous Improvement Generic Best-Practice Document TOPIC AREA SOLUTION MANAGER AREA Run SAP like a Factory Application OperationsPage 1 of 114
  • 01.03.2012Table of Contents1 Data Volume Management Guide for Account Management 4 1.1 Abstract 4 1.2 Introduction to SAP Data Volume Management 4 Precondition 5 Integration 6 Features 62 Overview of Archiving and Deletion Objects 83 Residence Times 104 General Recommendations 12 4.1 Configuration 12 4.2 Performance Optimization 13 4.3 SAP Notes 14 4.4 Determination of Archiving and Deletion Potential 16 4.5 Dependencies 175 Archiving Objects in Account Management 18 5.1 AM Accounts 18 5.2 AM Cards 24 5.3 AM Correspondences 28 5.4 AM Counters 30 5.5 AM Posting Control Orders 33 5.6 AM Transaction Figures 35 5.7 AM Individual Conditions 38 5.8 AM Info Items 41 5.9 AM Available Balance Series 44 5.10 AM Account Holder Change 46 5.11 AM Card Product Change 48 5.12 AM Account Product Change 51 5.13 AM Orders for CrExAv Details 54 5.14 AM Order for Notice on Amount 57 5.15 AM Order for Account Closure 60 5.16 AM Payment Forms 63 5.17 AM Payment Items 66 5.19 AM PLM Documents 73 5.20 AM Posting Notifications 75 5.21 AM Posting Notification Rules 77 5.22 AM Business Prenotes 79 5.23 AM Reconciliation Documents for Payment Items 82 5.24 AM Release Logs 85 5.25 AM Settlement Results 87 5.26 AM Standing Orders 91 5.27 AM Withdrawal with Settlement 946 Archiving Engine in Account Management 96 6.1 Archiving Engine: Purpose 96 6.2 Archiving Engine: Features 967 Deletion Reports and Objects for Account Management 98 7.1 AM Deletion Reports 99 7.2 Deletion Objects 102 Page 2 of 114
  • 01.03.20127.3 AM GL Interface Data 104 Page 3 of 114
  • 01.03.20121 Data Volume Management Guide for Account ManagementThis document gives an overview of the archiving and deletion processes in a Banking Services system,which is used for account management.1.1 AbstractBanking Services from SAP 6.0 comprise both operational and analytical banking applications based on abusiness process platform. The various applications can communicate with one another by means ofEnterprise Services.Banking Services from SAP 6.0 consist of the following components:  Account Management (FS-AM)  Master Contract Management (FS-MCM)  Posting Control Office (FS-PCO-AM)  Collateral Management (FS-CMS)  SAP Business Partner for Financial Services (FS-BP)  Foundation (FS-FND)  Bank Analyzer (FS-BA)This document describes how to stabilize the system size of a Banking Services system, which is used forAccount Management.The following sections start with an overview of the archiving and deletion objects that are available inAccount Management, followed by a chapter that describes the dependencies between the different objectsand the commonly used residence times for the objects, which are expected to grow very quickly.Section 5 is based on the business objects created in an Account Management system, such as paymentorders or accounts. It describes the purpose of each object and the business context, the archiving ordeletion object, and the configuration that is necessary before the archiving or deletion process can begin.The SAP data tables that contain the corresponding data are listed so you can identify which object willcontribute to the growth of a single table.The decision about which data should remain in the online database is often based on the age of thecorresponding records. The age of records can be determined by performing a table analysis. The tableanalysis is executed by using SAP transaction TAANA, which is described in the below mentioned SAPdocumentation Introduction to Data Archiving (see section 1.2). The information for creating an ad hocvariant for the table analysis is given for each document type in the corresponding section TAANA Ad HocVariant. This information can also be used to implement a detailed data analysis in the Data VolumeManagement Cockpit.1.2 Introduction to SAP Data Volume ManagementSAP Data Volume Management comprises the methodology that helps you reduce total operating costs bydecreasing the size of the databases and the monthly additions to the data.The available methods discussed in this document are:  Data archiving  Data deletion Page 4 of 114
  • 01.03.2012While data deletion means that the data is completely removed from the database and no longer availablefor any access, data archiving removes mass data that the system no longer needs online, but which muststill be accessible at a later date, if required, from the database. Archiving objects are used to writedocuments to archive files, which can be stored on other media. The archiving object specifies preciselywhich data is archived and how. It describes which database objects must be handled together as a singlebusiness object, and interprets the data irrespective of the technical specifications at the time of archiving(such as release and hardware).The following figure illustrates the archiving process. Data archiving procedure SAP Database File System External Online Online Storage System Offline 1 Analysis run 2 Archive run 3 Archive files are stored in the external storage system Archive directory Archiving object ArchiveLink Customizing 4 Delete run Archive files are deleted (Archive files are read and corresponding data is deleted from DB) from archive directoryPreconditionBefore reading this document, you should familiarize yourself with the general features of data archiving inan SAP system. You may read Introduction to data archiving, available in the SAP Service Marketplace:http://service.sap.com/ilm  SAP NetWeaver  SAP NetWeaver in detail  Solution Life-CycleManagement  Information Lifecycle Management Data Archiving  Media Library  Literature &Brochures Introduction to Data Archiving.The corresponding information is also available in the SAP Library: Account Management  DataArchiving and Deletion in Account Management  Introduction to Data Archiving.A general understanding of the terms and features of SAP Data Archiving is required to understand theremaining content in this document. Page 5 of 114
  • 01.03.2012IntegrationFor the majority of the archiving objects, the SAP Data Archiving concept is based on the archivingtechnology Archive Development Kit (ADK). Banking Services systems offer an additional technologyespecially designed for mass data archiving: the Archiving Engine. The Archiving Engine deals witharchiving scenarios instead of archiving objects. This technology enables the system to archive high datavolumes.In Banking Services systems, the archiving objects designed for Account Management business objectsare also able to handle high data volumes by using the Framework for Parallel Processing, which is alsoused for end-of-day process steps.Archiving procedures for archiving objects are started with the help of Archive Administration (transactionSARA). Archiving procedures based on archiving scenarios are carried out with the Archiving Engine,transaction AR_ENGINE.For most applications, it is possible to start archiving directly from the application menu. In these cases, theapplication-specific parameters, such as the archiving object, appear as default values.Archiving objects for each application component are predefined in the system. Their structures aredescribed in the application-specific sections of this document.FeaturesThe archiving procedure is divided into four main steps: 1. Analyze data In the analysis phase, the data to be archived is analyzed and either marked to be archived or marked to be analyzed again after a certain period of time. 2. Create archive files In the write phase, the data to be archived is written into newly created archive files. This process can be executed in parallel based on your customizing settings. 3. Store archive files The newly created archive files can then be moved to a storage system or copied to a tape. The removal to an external storage system can be triggered manually or automatically. 4. Delete from the database The delete program reads the data from the archive files and then deletes it from the database. It is also possible to delete the data before the store phase.For some archiving objects an additional pre-step can be executed to improve the parallel processing. Thepre-step sub process firstly examines the dataset of the archiving object, and then generatescorresponding profiles that specify the package limits for parallel processing. The profiles are storedpersistently in the database and then used later by the analysis and write sub processes, if set in the globalCustomizing for the archiving object.For general information about archiving in Account Management, visit the SAP Library and choose DataArchiving and Deletion in Account Management. Page 6 of 114
  • 01.03.2012The following documentation describes ADK-based archiving and Archive-Engine-based archiving. It isimportant that you understand the basic archiving concepts described in this documentation before youbegin archiving. The differences between the two technologies and processes are described in theArchiving Engine section. Page 7 of 114
  • 01.03.20122 Overview of Archiving and Deletion ObjectsFor general information about archiving in Account Management, visit the SAP Library and choose DataArchiving in FS-AM.In Account Management, archiving data is executed based on Archive Administration (transaction SARA)and on the Archive Engine (transaction AR_ENGINE). You can execute the archiving step from the SAPmenu or by calling one of the above transactions and choosing the corresponding archiving object. Thearchiving objects for Account Management are listed in the table below.Overview of Archiving Objects Archiving Object Description AM_ACCOUNT *) Accounts AM_CARD *) Cards CORRESPND Correspondence COUNTER Counters DISPORDER *) Posting control orders FIGURES Transaction figures INDCOND Individual conditions INFOITEM **) Info items NOW_ABS *) Available balance series ORDER_CAH **) Account holder change ORDER_COCP Card product change ORDER_COP Account product change ORDER_CXA CrExAv details order ORDER_NOW *) Notice on amount ORDER_TOC *) Account closure ORDER_WWS **) Withdrawal with settlement PAYMFORM **) Payment forms PAYMITEM Payment item PAYMORDER Payment order PLMDOC PLM document PNS_ALT **) Posting notifications PNS_MD **) Posting notification rules PRENOTE_B Business prenotes RECONC_PI **) Reconciliation documents for payment items RELEASELOG Release objects SETTLEMENT Settlements STANDORDER Standing order* These archiving objects are called hybrid objects. For hybrid objects, you can archive data using bothArchive Administration (SARA) and the Archiving Engine.For these archiving objects, you can include customer-specific data in archiving and data deletion. You canalso add customer-specific tables and customer-specific checks using the Archiving Factory. Page 8 of 114
  • 01.03.2012If you use the Archiving Engine for these archiving objects, you can use both the previous IMG activityMaintain Global Archiving Control and the new IMG activity Maintain Global Control for ArchivingEngine in Customizing. You can find more information about the Archiving Engine in section 6.** These archiving objects were developed for SAP Transaction Banking 4.0 and later releases. Use theArchive Engine for these objects. The Archive Engine allows you to access the Archiving Factory. Here,you can add customer-specific tables and customer-specific checks.Overview of Deletion objectsIn Account Management the deletion of data is executed for a number of objects by using so-calleddeletion objects. The following table gives an overview about these deletion objects. The details are givenin section 7. Deletion Object Description 1 GL_BALANCE FI balances 2 GL_BALPREP Balance sheet preparation 3 CORRESPND Correspondence 4 GL_SUMS FI totals records 5 INVENTORY Inventory data 6 PRENOTE_T Technical prenotes 7 RECONC Reconciliation data 8 SNITEM Non-balance-changing postings Page 9 of 114
  • 01.03.20123 Residence TimesNote:The residence time and—even more important—the overall retention time of each object must be definedaccording to the legal requirements of the countries where you are located. The residence times listedbelow are only an initial input that must be approved by your auditor in accordance with the localauthorities.Document type Archiving object Residence timeAccounts AM_ACCOUNT 4 to 10 yearsCards AM_CARD 15 monthsCorrespondence CORRESPND 15 monthsCounters COUNTER Savings accounts: 2 yearsPosting control orders DISPORDER 6 monthsTransaction figures FIGURES 1 monthIndividual conditions INDCOND 2 yearsInfo items INFOITEM 6 monthsAvailable balance series NOW_ABS 2 yearsAccount holder change ORDER_CAH 6 monthsCard product change ORDER_COCP 1 monthAccount product change ORDER_COP 4 monthsCrExAv details order ORDER_CXA 6 monthsNotice on amount ORDER_NOW 2 yearsAccount closure ORDER_TOC 3 monthsPayment forms PAYMFORM 15 months Current accounts: 3-6 monthsPayment item PAYMITEM Savings accounts: 15 monthsPayment order PAYMORDER Savings accounts: 15 monthsPLM document PLMDOC 1 monthPosting notifications PNS_ALT 15 monthsPosting notification rules PNS_MD 15 monthsBusiness prenotes PRENOTE_B 1 monthReconciliation documents for RECONC_PI 4 months Page 10 of 114
  • 01.03.2012payment items Current accounts: 9 monthsSettlements SETTLEMENT Savings accounts: 2 yearsStanding order STANDORDER 6 – 12 monthsDocument type Deletion object Residence timeFI balances GL_BALANCE 1 monthBalance sheet preparation GL_BALPREP 1 monthCorrespondence CORRESPND 15 monthsFI totals records GL_SUMS 1 monthInventory data INVENTORY 1 monthTechnical prenotes PRENOTE_T 1 monthReconciliation data RECONC 1 monthNon-balance-changing postings SNITEM 4 months Page 11 of 114
  • 01.03.20124 General RecommendationsThe following recommendations are valid for all archiving objects in Account Management and aretherefore described in this general section.4.1 ConfigurationGlobal configuration and customizing settingsBefore defining the configuration of the Account Management archiving objects, you should havecompleted the following IMG activities: 1. Cross-Archiving Object Customizing (technical settings) 2. Create Logical File Path 3. Archiving Object-Specific Customizing (technical settings) 4. Maintain Global Archiving Control 5. Maintain Global Control with Archiving EngineInterrupt WRITE phaseDuring regular archiving runs, you might want to interrupt the WRITE phase, for example, to free systemresources for end-of-day processing. The interrupts can be achieved by defining thresholds in the Cross-Archiving Object Customizing. You can define time-based and size-based interruptions. However, theseinterrupted archiving sessions must be completed before starting a new WRITE job. This means thecorresponding deletion job for this written data must be executed before starting a new WRITE job. It is notpossible to continue interrupted FS-AM archiving sessions, because continuing parallel processing is notsupported.Creation/size of archive fileYou can define the maximum size of an archive file and thus enforce the creation of a new file with thesettings in the IMG activity Archiving Object-Specific. The recommended initial setting is Maximum sizein MB: 100 MB.Test this setting with mass data before starting mass data archiving in production.Automatic start of WRITE phaseIn the IMG activity Maintain Global Archiving Control, you can set the Automatic Start indicator for everyAccount Management archiving object. This indicator will then start the WRITE job automatically afterfinishing the ANALYZE (pre-processing) job. Before you set this indicator, you should test this setting withmass data with regard to system resources.Execution modeCurrently, for all Account Management archiving objects that are started with transaction SARA, theanalysis program does not contain any selection parameters and therefore never has any variants.The two global control options are the archiving mode and analysis mode entries; these can be set in theMaintain Global Archiving Control activity.1. The archiving mode has the following characteristic values: Productive mode Page 12 of 114
  • 01.03.2012 The parallel package administrators are started as jobs in the background. The archiving status and the resubmission date are updated in the database. Simulation mode The parallel package administrators are started as jobs in the background. The database is not updated. Test mode The package administrators are started in online processing and therefore run sequentially rather than in parallel. The database is not updated. This mode is useful for testing and tracking the analysis program.2. The analysis mode has the following characteristic values: Standard The business objects are selected according to their archiving status and resubmission date. The selection rules for each business object are described in the subsequent sections Archiving object and configuration and Preconditions. This mode is used in productive operations. Initial All business objects with an initial archiving status and resubmission date are included in the selection. This mode is used if the archiving process is being started for the first time and neither of the fields Archiving Status and Resubmission Date was filled when the business objects were created. All In this mode, all business objects are selected without any restrictions. This mode is useful if the object-specific Customizing is changed and you want this change to apply to all business objects (in other words, to all those that already have an archiving status and resubmission date).Check archiving CustomizingIf you want to check whether the Customizing settings are complete, you can use a report fromCustomizing for Account Management (FS-AM) by choosing Archiving  Check Archiving Customizing.Partitioning of tables and archive information structuresOnly for DB2 z/OS: Follow the instructions in SAP Note 496904 - Performance notes database parametersFS-AM for DB2 z/OS.4.2 Performance OptimizationRSARCHDFor performance reasons, it is recommended to use RSARCHD to start the deletion jobs instead of havingthe archiving write phase automatically start the delete jobs for the closed archive files.Report RSARCHD allows you to limit the amount of parallel deletions.Package Formation pre-step Page 13 of 114
  • 01.03.2012To ensure optimum usage of system resources in parallel processing, the objects that are to be processedmust be distributed equally between individual packages. Advance generation of profiles has two maingoals:  The packages may not exceed a size limit defined in the Customizing settings.  Generate work packages of an equal size.To call this report from the SAP Easy Access screen, choose Account Management  Archiving Creation of Package Profile.The program examines the dataset of the business objects in advance, and generates correspondingprofiles based on the package limits. These profiles are constantly created on the database and are usedlater by the analysis and write programs in the parallel package administrators. For several archivingobjects, package formation procedures are already implemented. You can also implement your ownpackage formation procedure as a function module, which you must enter in the Package FormationProcedure Customizing settings.The pre-step for package formation is available in the SAP standard for:  Settlements  Correspondences  PLM documents  Non-balance-changing postings  Transaction figures  Payment items  Counters4.3 SAP NotesBefore implementing archiving, implement all SAP Notes listed in this document that are relevant for yoursoftware release. Furthermore, search the SAP Support Portal for SAP Notes applicable for the archivingobjects included in your archiving project. Included in SupportNote Number Description SW Comp Release Package BVW_ORDER_TOC: Internal account number 200 SAPKISC3171614763 FS-APPL is displayed 300 SAPK-30010INFSAPPL 200 SAPKISC3171607286 Account with rejection reason 43 is not archived FS-APPL 300 SAPK-30010INFSAPPL 400 SAPK-40001INFSAPPL RBCA_PLMDOC_ENTRY: Data selection using 200 SAPKISC3161586524 FS-APPL field catalog 300 SAPK-30009INFSAPPL 200 SAPKISC3161583981 Missing fields in table BCA_CONTRACT_DEL FS-APPL 300 SAPK-30009INFSAPPL Payment form type not displayed for payment 200 SAPKISC3161582998 FS-APPL order 300 SAPK-30009INFSAPPL Account is not archived due to info item (reason 200 SAPKISC3161581241 FS-APPL 36) 300 SAPK-30009INFSAPPL WWS: Notice on amount is not taken into 200 SAPKISC3161581222 FS-APPL account 300 SAPK-30009INFSAPPL Page 14 of 114
  • 01.03.2012 Included in SupportNote Number Description SW Comp Release Package Include table FICOT_POS_REL during UNDO 200 SAPKISC3151580514 FS-APPL individual condition 300 SAPK-30008INFSAPPL UNDO migration of individual conditions based 200 SAPKISC3151580105 FS-APPL on contract 300 SAPK-30008INFSAPPL 200 SAPKISC3151580049 BCA_CN_LINK: Outsourcing data FS-APPL 300 SAPK-30008INFSAPPL 710 SAPKA710131574758 Business Views: Improved results display SAP_ABA 711 SAPKA71107 730 SAPKA73003 Business View archiving object INDCOND: 200 SAPKISC3141573368 FS-APPL Display detail tables 300 SAPK-30007INFSAPPL 200 SAPKISC3161572291 Payment items are not archived (intraday) FS-APPL 300 SAPK-30009INFSAPPL 200 SAPKISC3151564493 Poor performance when reading payment items FS-APPL 300 SAPK-30008INFSAPPL Report to display balance list of archived 200 SAPKISC3151564099 FS-APPL transac. figures 300 SAPK-30008INFSAPPL Interest penalty calculated incorr. when prenote 200 SAPKISC3151556838 FS-APPL is created 300 SAPK-30008INFSAPPL Missing fields in arch. field catalog 200 SAPKISC3151552107 FS-APPL SAP_BCA_PAYMITM 300 SAPK-30008INFSAPPL 200 SAPKISC3141548800 Displaying archived posting notifications FS-APPL 300 SAPK-30007INFSAPPL 200 SAPKISC3151547415 Deleted forward order is not archived FS-APPL 300 SAPK-30008INFSAPPL Archiving: Reports missing for posting 200 SAPKISC3141542413 FS-APPL notification 300 SAPK-30007INFSAPPL Archiving Object SETTLEMENT: SARA SAPKISC3121541236 FS-APPL 300 Statistics Missing SAPK-30009INFSAPPL The report RBCA_UNDO_MIG_GRP_DEL 200 SAPKISC3151538844 FS-APPL does not delete any data 300 SAPK-30007INFSAPPL Archiving object INDCOND: More stringent 200 SAPKISC3131533731 FS-APPL checks 300 SAPK-30006INFSAPPL Residence time determintn for ORDER_COCP 200 SAPKISC3141531339 FS-APPL + STANDORDER incorr 300 SAPK-30007INFSAPPL 200 SAPKISC3141530444 Migrated account cannot be archived FS-APPL 300 SAPK-30007INFSAPPL 200 SAPKISC3141529681 Corrections for archiving object ORDER_WWS FS-APPL 300 SAPK-30007INFSAPPL Archiving AM_ACCOUNT: Check for inventory 200 SAPKISC3141527498 FS-APPL data is incorrect 300 SAPK-30007INFSAPPL 200 SAPKISC3141527035 Potential access of saved data in PCO FS-APPL 300 SAPK-30007INFSAPPL Dump in business view of archiv. objects 200 SAPKISC3141526945 FS-APPL FIGURES and AM_CARD 300 SAPK-30007INFSAPPL 200 SAPKISC3141526791 Migrated account cannot be archived FS-APPL 300 SAPK-30007INFSAPPL RBCA_AM_CARD_ENTRY: Data selection 200 SAPKISC3131524091 FS-APPL using field catalog 300 SAPK-30006INFSAPPL 200 SAPKISC3131523339 Corrections for Archiving Object ORDER_WWS FS-APPL 300 SAPK-30006INFSAPPL Archiving deletion object GL_SUMS: posting1523164 FSAPPL 200 SAPKISC313 date is initial Archiving object ORDER_CARC: Card 200 SAPKISC3131521784 FS-APPL Cancellation 300 SAPK-30006INFSAPPL RBCA_AM_ACCT_ENTRY: Data selection 200 SAPKISC3131521447 FS-APPL using field catalog 300 SAPK-30006INFSAPPL 200 SAPKISC3131521401 Initializing existing orders for archiving FS-APPL 300 SAPK-30006INFSAPPL 200 SAPKISC3131504593 Archiving Object: Withdrawal With Settlement FS-APPL 300 SAPK-30005INFSAPPL 200 SAPKISC3131497800 Table BCA_PAYMFORM_REF is not archived FS-APPL 300 SAPK-30006INFSAPPL Page 15 of 114
  • 01.03.2012 Included in SupportNote Number Description SW Comp Release Package BCA_AR_FIGURES_BVW displays payment 200 SAPKISC3131497087 FS-APPL items not archived 300 SAPK-30006INFSAPPL Backdated change checks archiving object 200 SAPKISC3121492588 FS-APPL AM_ACCOUNT 300 SAPK-30005INFSAPPL Duplicate display of turnover in display of 200 SAPKISC3111436253 FS-APPL transac. figures 300 SAPK-30004INFSAPPL 200 SAPKISC3111460157 Transaction Figures for WWS Account archived FS-APPL 300 SAPK-30004INFSAPPL Transaction BCA_AR_FIGURES_BVW: 200 SAPKISC3101425169 FS-APPL Selection criteria incorrect 300 SAPK-30003INFSAPPL Archiving objects AM_ACCOUNT and 200 SAPKISC3101402462 FS-APPL AM_CARD: Missing tables 300 SAPK-30003INFSAPPL 200 SAPKISC3101385811 Display of transaction figures in archived period FS-APPL 300 SAPK-30003INFSAPPL Missing prefetch functionality for account1386162 FS-APPL 200 SAPKISC309 balance Performance when reading balances and key 200 SAPKISC3091385267 FS-APPL figures 300 SAPK-30002INFSAPPL1323005 Archiving Engine: Dump when you delete SAP_ABA 711 SAPKA71103 Release Performance notes database parameters FS-496904 independe AM for DB2 z/OS nt4.4 Determination of Archiving and Deletion PotentialBefore you start an archiving project, you may want to determine the archiving or deletion potential for acertain business object. You can either use the DVM Cockpit or the DVM Work Center to display this, oryou can calculate it manually. In each case, you need to define the residence time for the object first, andthen execute an analysis with regard to timely distribution. You can execute the analysis with transactionTAANA. The analysis is either started manually or triggered by the DVM Cockpit or the DVM Work Center.For a detailed description of the transaction, please check the online documentation in the SAP Library:Account Management  Data Archiving and Deletion in Account Management  Introduction to DataArchiving Table Analysis.For the analysis of the timely distribution see the description of ―Creating an Ad hoc variant‖.For each document type the details required for creating an ad hoc variant is given in the correspondingsection TAANA Ad Hoc Variant.The fields used for the TAANA Ad Hoc variant are often based on a date field with the formatDD.MM.YYYY whereas the fields for the TAANA Ad Hoc variant only collect the year or the monthinformation. Therefore so-called virtual fields are used. The naming convention is Z_datefieldname_YEARor Z_datefieldname_MONTH. The virtual fields are created automatically when performing an ST14anaylsis with focus on DVM, if the latest version of the solutions tools plug-in ST-A/PI is available on theBanking system. Page 16 of 114
  • 4.5 DependenciesThe following figure shows the dependencies between the Account Management objects with regard to deletion and archiving: TIME LINE Page 17 of 114
  • 5 Archiving Objects in Account Management5.1 AM AccountsAM Accounts: DescriptionIn Account Management (FS-AM), accounts depict the contractual agreements between the business partnerand the bank in the system, enabling a current account to be managed. The system links together theinformation in the respective contract elements and business partners to form the actual contractualagreement.Relationship: Account Contract - ProductAn account is always related to an account product. A product is comparable to a form or template. When anaccount is created, the account product passes its characteristics to the account contract. Thesecharacteristics can be changed in a limited way, depending on the account product. Archiving of accountscan be defined per product.Relationship: Account Contract - Organizational UnitThe contract-managing organizational unit to which the account contract is assigned is an important elementin an account contract. It is from this that the system derives the bank posting area, bank country, bank key,and contract calendars. In banking services 6.0,1 the contract-managing organizational unit of an accountcontract cannot be changed once the contract has been created. Archiving of accounts can be defined perbank postings area.Relationship: Account Contract - Business PartnerFrom a business perspective, the account contract is related to at least two business partners: the accountholder and the bank itself. In the Account Management system, the account contract only recognizes theaccount holder or another additional business partner. The bank itself is assigned by the contract-managingorganizational unit.AM Accounts: Archiving Object and ConfigurationThe archiving object for AM accounts is AM_ACCOUNT. Archiving object AM_ACCOUNT is a hybrid object;you can carry out data archiving using both data archiving (SARA) and the Archive Engine.I. Definition of residence timesIn the IMG activity Define Residence Time for Accounts (Object AM_ACCOUNT), you specify the period oftime after which accounts are archived.II. ActivitiesEnter at least the residence time for each bank posting area. You can use the product attribute todifferentiate between your residence time settings in detail.1 With banking services 8.0, the organizational unit of an account can be changed.© 2011 SAP AG
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0The system determines the residence time of an account by checking if its attributes match those specified inthe IMG activity. The system checks from the most matches (all attributes match) down to the least matches(only the bank posting area matches) in the following sequence: 1. Bank posting area, product 2. Bank posting areaIII. NotesThis archiving object is a hybrid object: You can carry out data archiving using both data archiving (SARA)and the Archiving Engine.For these archiving objects, you can include customer-specific data in archiving and data deletion. You canadd customer-specific tables and customer-specific checks using the Archiving Factory.If you use the Archiving Engine for this archiving object, you can use both the previous IMG activity, MaintainGlobal Archiving Control, and the new IMG activity, Maintain Global Control for Archiving Engine inCustomizing.Reload program: For archived contracts, no reload program has been implemented. As contracts can onlybe archived if they are terminated and their reactivation period has expired, all archived contracts can nolonger be reactivated. Consequently, the data can only be displayed. As this is also possible using thearchive, no program has been implemented to reload archived contracts.AM Accounts: PreconditionsBusiness checks are performed during the analysis phase of the archiving process. Only accounts that areclosed can be archived. When an account is closed, a new entry is added to table BCA_AR_ACCOUNT. Theanalysis program of the archiving object AM_ACCOUNT reads table BCA_AR_ACCOUNT to determine theaccounts to be archived.As only accounts that are closed can be archived, the archiving potential for the accounts is rather small.Make sure you enter a residence time for each bank posting area.The residence time must be longer than—or the same as—the minimum residence time defined either in IMGactivity Maintain Global Archiving Control or in IMG activity Maintain Global Archiving Control with ArchivingEngine.If you do not make an entry in this IMG activity, the standard residence time applies. This is the residencetime you defined for accounts in the Customizing for Account Management (FS-AM) under Archiving Maintain Global Archiving Control or Maintain Global Archiving Control with Archiving Engine.The residence time is dependent on a product. Therefore, if you have different residence times for differentproducts (and a product change), the following situations may arise:  If you initially use a product to define the residence time, and then enter another product and execute a product change during the current productive operations, the system uses the residence time of the product that is currently valid as a basis for the archiving object data records created in the operational system after the product change.© 2011 SAP AG page 19/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0  If the residence time of the old product was longer than that of the new product, the data records that were created after the product change are archived before the data records created before the product change. This may mean that older data records are still in the operational system even though newer ones are already in the archive.The residence time of the account must be expired. The residence time is based on the end of thereactivation period for the account (stored in BCA_CN_EVENT-TIMESTAMP where BCA_CN_EVENT-EVENT equals 0015). The residence time is checked against the posting date for payment transactions.A wide range of business checks will be executed before an account can actually be archived. Forinformation about the business checks of the archiving object data and dependent archiving object data, seethe documentation in the system: IMG  Financial Services  Technical Documentation for AccountManagement  Concept and Guidelines  Archiving  AM_ACCOUNT:  Archiving Check of Account for Settlement  Archiving Check of Contract for Financial Conditions  Archiving Check of Account for PLM  Archiving Check of Account for Migration Status  Archiving Check of Account for Release  Archiving Check of Account for Reactivation and Participant Cards  Archiving Check of Account for Payment Item Control or Facility Relevance  Archiving Check of Account for Loans  Archiving Check of Account for Counters  Archiving Check of Account for Payment Transactions  Archiving Check of Account for Balance Sheet Preparation Data  Archiving Check of Account for Information Items  Archiving Check of Account for Payment Items  Archiving Check of Account for Payment Forms  Archiving Check of Account for Prenotes  Archiving Check of Account for Non-Balance-Changing Turnovers  Archiving Check of Account for Reconciliation Documents  Archiving Check of Account for Inventory Details  Archiving Check of Account for Reconciliation Data  Archiving Check of Account for Item Splits  Archiving Check of Account for Posting Notifications  Archiving Check of Account for Posting Notification Rules  Archiving Check of Account for Posting Control Orders© 2011 SAP AG page 20/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0The system will then set one of the following corresponding rejection reasons: Reason Description (Cause) 01 Individual conditions not archived 02 Settlements not archived 03 PLM document not archived 10 Dependent card not archived 15 Reactivation period not expired 20 Payment items not archived 21 Counters not archived 22 Transaction figures not archived 23 Prenotes not archived 30 Standing orders not archived 31 Payment orders not archived 32 Posting control orders not archived 33 Non-balance-changing items not deleted 34 GL information about non-balance-changing items not deleted 35 Balance sheet preparation data not deleted 36 Information items not archived 37 Payment forms not archived 38 Product change not archived 39 Account closure not archived 40 Account holder change not archived 41 Notice on amount not archived 42 Available balance series not archived 43 Reconciliation documents not archived RECONC_PI 44 Inventory details not deleted 45 Reconciliation data not deleted RECONC 46 Account has relationships with other contracts 47 Status of account is not ―closed‖ 48 Account is participant in a card 49 Item split not archived 50 Posting notification not archived 51 Posting notification rule not archived 52 Account is participant in a facility 53 Account is loan 95 inconsistent data 96 inconsistent data 97 inconsistent data 98 Contract is in the release process 99 inconsistent data© 2011 SAP AG page 21/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0AM Accounts: Display Archived DataYou can display archived accounts with the report Display Account From Archive. To call report DisplayAccount From Archive from the SAP Easy Access screen, choose Financial Services  AccountManagement  Archiving  Data Display  BVW_AM_ACCOUNT Accounts (Archiving ObjectAM_ACCOUNT).AM Accounts: TablesThe main tables for accounts are:Table name DescriptionBCA_AR_ACCOUNT AccountsBCA_CONTRACT Assignment Table: Contract AnchorBCA_CN_EVENT Contract EventsBCA_CN_LINK Assignment Table: Contract Parts to a ContractBCA_CNSP_ACCT Assignment Table: Account Contract SpecializationCDCLS Cluster structure for change documentsCDHDR Change document headerCDPOS_STR Additional Change Document - Table for STRINGsCDPOS_UID Additional Table for Inclusion of TABKEY>70 CharactersPlease note: The archiving object AM_ACCOUNT might delete entries from 73 additional tables, such asaddress tables, contract element tables, and so on. These tables can be determined with DB15, but are notlisted here for transparency reasons. The tables listed above—except for BCA_AR_ACCOUNT—areexpected among the top 30 tables.AM Accounts: TAANA Ad Hoc VariantWhen an account is created, the system will create an entry in the contract table BCA_CONTRACT. Whenthe account is closed, the system will create an additional entry in table BCA_AR_ACCOUNT. TableBCA_AR_ ACCOUNT was designed for archiving purposes. During the archive phase ANALYZE, the systemreads table BCA_AR_ ACCOUNT instead of reading the table BCA_CONTRACT, which is considerablylarger. The archive status (field ARCHIVE_STATUS) is set 1 (= Not Archivable), when the account is closed.During the analysis run, the status can be changed according to the results of the business and residencetime checks.© 2011 SAP AG page 22/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0Possible statuses are:Blank No Analysis Made1 Not Archivable2 Archivable3 Can be deleted4 ArchivedThe following table and fields can be used to analyze the number of accounts that can be archived:BCA_AR_ACCOUNT CLIENT ARCHIVE_STATUS Z_TIMESTAMP_YEAR Z_TIMESTAMP_MONTH© 2011 SAP AG page 23/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.05.2 AM CardsAM Cards: DescriptionAn AM card represents a contract in Account Management (FS-AM) that has various objects assigned to it,such as business partner, conditions, and account details.You can create a card contract for any type of card:  Credit card (such as Visa, Euro, or Master card)  Debit card (such as EC card or bank card)  Other cards with and without payment functionsAM Cards: Archiving Object and ConfigurationThe archiving object for AM card data is AM_CARD. Archiving object AM_CARD is a hybrid object; you cancarry out data archiving using both data archiving (SARA) and the Archiving Engine.I. Definition of residence timesIn the IMG activity Define Residence Time for Payment Order (Object PAYMORDER), you define the periodof time after which AM cards can be archived in the operational system.II. ActivitiesDefine the residence time for each bank posting area. You can use the product attribute to differentiatebetween your residence time settings in greater detail.The system determines the residence time of a card by checking whether its attributes correspond to thedetails specified in the IMG activity. During this process, the system checks all possible matches from thebest (all attributes match) to the worst (only the bank posting area matches) in the following sequence: 1. Bank posting area, product 2. Bank posting areaIII. NotesThe residence time must be longer than or the same as the minimum residence time defined in IMG activityMaintain Global Archiving Control or in IMG activity Maintain Global Archiving Control with Archiving Engine.If you do not make an entry in this IMG activity, the standard residence time applies. This is the residencetime you defined for cards in Customizing for Account Management (FS-AM) under Archiving  MaintainGlobal Archiving Control or in Maintain Global Archiving Control with Archiving Engine.The residence time depends on a product. Therefore, if you have different residence times for differentproducts (and a product change), the following situations may arise: If you initially use a product to define the residence time, and then enter another product and execute a product change during the current productive operations, the system uses the residence time of the product that is currently valid as a basis for archiving object data records created in the operational system after the product change.© 2011 SAP AG page 24/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0 If the residence time of the old product was longer than that of the new product, the data records that were created after the product change are archived before the data records created before the product change took place. This may mean that older data records are still in the operational system even though newer ones are already in the archive.For these archiving objects, you can include customer-specific data in archiving and data deletion. You canadd customer-specific tables and customer-specific checks using the Archiving Factory.If you use the Archiving Engine for this archiving object, you can use both the previous IMG activity MaintainGlobal Archiving Control and the new IMG activity Maintain Global Control for Archiving Engine inCustomizing.AM Cards: PreconditionsBusiness checks are performed during the analysis phase of the archiving process. The followingrequirements must be met for a card to enable subsequent archiving:  If the card is a main card, all its additional cards must be archived before the main card can be archived.  If the card participates in a card pool, it can only be archived if it only inactively belongs to the card pool.  If there are corresponding orders for card cancellation for a card, this card cannot be archived.  A contract can only be archived if all Posting Lock Management (PLM) documents that contain the contract have been archived already. For the specified contracts, the system determines the PLM documents that contain at least one such contract. The system then sets the archivability status of the contract to Cannot be archived if the contract exists in at least one unarchived PLM document. The system also sets the rejection reason.  If unarchived individual conditions exist, the archiving status of the checked contracts is set to 1 (cannot be archived) and the rejection reason is set to 01 (individual conditions not archived).  This function module checks whether the relevant settlements still exist in the system for a list of contracts. If the settlements for a contract have not yet been archived, you may also not archive this contract.  If the analysis is run in Migration Undo mode, the migration analysis function module enables the system to identify data that has been migrated incorrectly or has not been migrated. Incorrectly migrated or non-migrated data is given the status 3 = Can be deleted.The following rejection reasons may be set during the business checks: WZ Business Object Re-Checked YY Application: Residence Time Not ExpiredAM Cards: Display Archived DataYou can find the Display Card From Archive report from the SAP Easy Access screen by choosingFinancial Services  Account Management  Archiving  Data Display  BVW_AM_CARD Cards(Archiving Object AM_CARD).If you have archived cards with encrypted card numbers and log the accesses to them using transactionDisplay Accesses to Unmasked Card Numbers, you can also access archived cards. To find thetransaction, on the SAP Easy Access screen, choose Account Management  Card  Security Settings forCard Numbers.© 2011 SAP AG page 25/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0AM Cards: TablesThe fastest growing tables for AM cards are:Table name DescriptionBCA_CARD_ADMIN Administrative Card DataBCA_CN_EVENT* Contract EventsBCA_CN_LINK* Assignment Table: Contract Parts to a ContractBCA_CONTRACT* Assignment Table: Contract Anchor* The archiving object AM_CARD will only archive data from the tables that correspond to CARD data.Entries of these tables will also be archived with AM_ACCOUNTS.AM Cards: TAANA Ad Hoc VariantWhen a card is created, the system will create an entry in contract table BCA_CONTRACT and an additionalentry in table BCA_AR_CARD. Table BCA_AR_CARD was designed for archiving purposes. During thearchive phase ANALYZE, the system reads table BCA_AR_CARD instead of table BCA_CONTRACT, whichis considerably larger. The archive status (field ARCHIVE_STATUS) is set 1 (= Not Archivable), when thecard is created. Further possible statuses are:Blank* No Analysis Made1 Not Archivable2 Archivable3 Can be deleted4 Archived* Possible entry for migrated cardsThe following table and fields can be used to analyze the number of cards that can be archived:BCA_AR_CARD CLIENT ARCHIVE_STATUS Z_ARCHIVE_FLUD_YEAR Z_ARCHIVE_FLUD_MONTHAM Cards: Field Catalogs and Archiving Information StructuresFor this archiving object, the following three different field catalogs (and corresponding archiving informationstructures for displaying the archived card data) are available:Note: For other FS-AM archiving objects, only one field catalog and archiving information structure exits; youcan find it in the relevant online application help.Usage Field Catalog Archive information structuresCard (Card) SAP_AM_CARD03 SAP_AM_CARD03Card (Business Partner) SAP_AM_CARD04 SAP_AM_CARD04Card (LOG) SAP_AM_CARD05 SAP_AM_CARD05© 2011 SAP AG page 26/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0AM Cards: ReloadReload program: For archived cards, no reload program has been implemented. As cards can only bearchived if they are terminated and their reactivation period has expired, all archived cards can no longer bereactivated. Consequently, the data can only be displayed. As this is also possible using the archive, noprogram has been implemented to reload archived cards.© 2011 SAP AG page 27/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.05.3 AM CorrespondencesAM Correspondences: DescriptionCorrespondence serves a wide range of communication purposes, including:  Sending information (for example, notification of condition changes)  Documenting business processes based on agreements between customer and bank (for example, notification of creation of a standing order or confirmation of notice)Correspondence created in Account Management focuses on standardized mass correspondence, initializedfrom transactions. Correspondence is generated in single and mass runs. Correspondence can be sent to therecipient using various media (for example, by letter, e-mail, or fax).AM Correspondences: Archiving ObjectThe archiving object for correspondences is CORRSPND. This object is the basis for archiving or deletingcorrespondence requests.I. Definition of residence timesIn the IMG activity Define Residence Time for Correspondence Types (CORRSPND Object), you define thecorrespondence residence time for each correspondence type.II. ActivitiesDefine the residence time for each correspondence type. If you set the Delete indicator, the system deletesthe corresponding data of the correspondence type without archiving it. In doing this, it creates a deletionobject from an archiving object.If you do not make an entry for the correspondence type, you can create a generic entry where you definehow long correspondence is to remain in the system before being archived or deleted.Individual applications have defined their own procedures for archiving correspondence requests. Note theinstructions in these applications and use only the procedures defined in the applications to archive.The residence time is entered in the CorrType column, which stands for ―Correspondence Type Runtime forArchiving‖ measured in days.Notes:The residence time for correspondences is always entered in days. You cannot specify a different unit here.The base date for the residence time is the print date. The residence time must be larger than—or the sameas—the minimal residence time that you defined in the activity Maintain Global Control for Archiving.If you do not make an entry in this IMG activity, the system checks whether you have created a generic entry.If not, the standard residence time defined in Maintain Global Control of Archiving applies.AM Correspondences: PreconditionsNo further business checks are defined.© 2011 SAP AG page 28/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0AM Correspondences: Display Archived DataYou can find the Display Archived Correspondences report from the SAP Easy Access screen by choosingFinancial Services  Account Management  Logs  Correspondence  Display Correspondence History.In the selection screen, choose Display from the Archive also.AM Correspondences: TablesThe tables for AM correspondences are:Table name DescriptionCDCLS Cluster structure for change documentsCDHDR Change document headerCDPOS_STR* Additional Change Document - Table for STRINGsCDPOS_UID Additional Table for Inclusion of TABKEY>70 CharactersDFKKCOD FI-CA Correspondence - Correspondence DataDFKKCODCLUST FI-CA Correspondence - Correspondence Cluster DataDFKKCOH FI-CA Correspondence - Correspondence HeaderDFKKCOH_ARC FI-CA Correspondence - Correspondence HeaderDFKKCOHARC FI-CA Correspondence - Archive IdentificationDFKKCOHI FI-CA Correspondence - Correspondence HistoryDFKKCOHINCORR FI-CA Correspondence - Data on Inbound CorrespondenceAM Correspondences: TAANA Ad Hoc VariantThe following table and fields can be used to analyze the yearly and monthly distribution of correspondences:DFKKCOH Z_LAUFD_YEAR Z_LAUFD_MONTHAM Correspondences: DeletionIf you want to delete correspondences without archiving, you can execute report Delete CorrespondenceRequests Without Archiving report from the SAP Easy Access screen by choosing Financial Services Account Management  Archiving  Data Deletion  BCA_CORR_DELETE - Correspondence. In theselection screen, set Application Component B (for Banking). The report will use parallel processing similar tothe archiving process.© 2011 SAP AG page 29/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.05.4 AM CountersAM Counters: DescriptionIn Account Management, counters record various kind of values such as  the number of posting items for each account  unpaid installments in the context of a savings scheme agreementAM counters are used for the following: - Condition determination in account settlement (for example, number of posted items per calculation period) - Collecting information on an account for posting control purposes (for example, the number of days on which an account is overdrawn) - Statistical evaluations.AM Counters: Archiving Object and ConfigurationThe archiving object for AM counters is COUNTER.I. Definition of residence timesIn the IMG activity Define Deduction Period for Counters (Object COUNTER), you specify the period of timeafter which counters are archived.II. ActivitiesBank Posting AreaBank Posting Area is a required field. There must be an entry for each bank posting area. If, however, thereis no entry for a particular bank posting area, the residence time is taken from the global control of archiving(COUNTER object) and used for the counters for this bank posting area.Product Category and ProductThe product category and external product ID of the product form a unit and must always be enteredtogether.Safety MarginThe safety margin is used in the ways as described in the section ―Preconditions‖ below. It consists of oneunit and one deduction period (number of units) and corresponds to calendar days.The safety margin must be longer than—or the same as—the minimum residence time defined in the checktable for the global control of archiving.Deduction PeriodHere you specify the number of units. Deduction Period is a required field.© 2011 SAP AG page 30/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0UnitUnit is a required field. The following units are possible:  Months  YearsAM Counters: PreconditionsThe following requirements must be met before counters can enable the subsequent archiving.The related counters must exist in the operational system per account for the settlement periods for whichsettlements exist with the status Operational. However, it would be extremely complicated and time-consuming to determine the exact counters required for a settlement period using the standard and individualconditions, and this is therefore not done.Instead, you define a safety margin for the COUNTERS object per bank posting area, product category, andproduct. You must always specify the bank posting area and safety margin, but the product category andproduct are optional.The period for which a counter is used as a calculation base can differ from the period of use.Examples:  The account maintenance charges for April are governed by the number of postings in March.  The item charges for April are governed by the number of postings from January to March.1. The system determines the earliest existing start date of the settlements of an account (MIN [BCA92- START_TMSTP]), for example, 07/11/2001.2. The customizing settings are used as a base to calculate the valid safety margin for the account, for example, 3 months.3. The safety margin is subtracted from the earliest existing start date of an account settlement, for example, 04/11/2001.4. Counters are always archived in complete months. The date determined in point 3 is therefore set to the first day of the month, for this example, 04/01/2001.All counters from before the date determined in point 4 are archived.AM Counters: Display Archived DataYou can find report Select and Display Archived Counters from the SAP Easy Access screen by choosingFinancial Services  Account Management  Archiving  Data Display  BCA_AR_COUNTER_BVW.AM Counters: TablesThe tables for AM counters are:Table name DescriptionBCA_COUNTER CounterCDCLS Cluster structure for change documents© 2011 SAP AG page 31/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0Table name DescriptionCDHDR Change document headerCDPOS_STR Additional Change Document - Table for STRINGsCDPOS_UID Additional Table for Inclusion of TABKEY>70 CharactersAM Counters: TAANA Ad Hoc VariantThe following table and fields can be used to analyze the yearly and monthly distribution of counters:BCA_COUNTER Z_COUNT_TIMESTMP_YEAR Z_COUNT_TIMESTMP_MONTHAM Counters: Residence TimesIn general, it is expected that the runtimes for settlement runs and settlement simulation runs will slow downwith a growing number of entries in table BCA_COUNTER. Consequently, we recommend archiving countersas soon as possible. Although the counters can be read from the archive to display the data (see section 5.5),however, the settlement and settlement simulation runs cannot read from the archive due to performancereasons. If you would like to keep counter data online to calculate settlements for certain account products,we recommend defining longer residence times for those account types and shorter residence times for therest of the data. Configure specific residence times as described in section 5.5 to meet your internal or legalrequirements. The same applies for transaction figures.© 2011 SAP AG page 32/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.05.5 AM Posting Control OrdersAM Posting Control Orders: DescriptionA posting control order is an order automatically generated in the Posting Control Office for checking andprocessing problems that occurred during posting of payment items or creation of prenotes in the AccountManagement system.The data required for creating a posting control order is transferred via an interface from the AccountManagement system to the Posting Control Office.AM Posting Control Orders: Archiving Object and ConfigurationThe archiving object for posting control orders is DISPORDER.I. Definition of residence timesIn the IMG activity Define Residence Time for Posting control orders, you define the period of time after whichposting control orders are archived in the operational system.II. ActivitiesEnsure that you enter at least the residence time for each bank posting area.You have the option to subdivide your settings more precisely via the posting control order category, theposting control order subcategory, and the product.The system determines the residence time of a posting control order by selecting the entry for which theattributes of the posting control order match your specifications in this IMG activity. If there is no entry forwhich all specifications match, the system takes into account the remaining entries in the following sequence: 1. Partially qualified entry without details of the product, but with matching bank posting area and posting control order category and subcategory 2. Partially qualified entry without details of the posting control order category and subcategory, but with matching bank posting area and product 3. Generic entry without details of product or posting control order category and subcategory, but with matching bank posting areaIII. NotesThat the residence time you enter must be longer than–or the same as—the minimum residence time set inIMG activity Maintain Global Archiving Control or in IMG activity Maintain Global Archiving Control withArchiving Engine. If you do not create a generic entry, the standard retention period that you stored forposting control orders in the Customizing settings (under Archiving  Maintain Global Archiving Control orMaintain Global Archiving Control with Archiving Engine) applies.AM Posting Control Orders: PreconditionsBusiness checks are performed during the analysis phase of the archiving process. The followingrequirements must be met for a posting control order to enable the subsequent archiving:  The posting control order must have the status Completed. This means no further changes are possible.© 2011 SAP AG page 33/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0  All payment items modified when processing a posting control order must be archived. On the other hand, payment items that have a posting control order due to the posting control rules may only be archived once the corresponding posting control order has reached the end status.AM Posting Control Orders: Display Archived DataYou can find the Display Archived Payment Items report from the SAP Easy Access screen by choosingFinancial Services  Posting Control Office Archiving  Display Archived Posting Control Orders.AM Posting Control Orders: TablesThe tables for AM posting control orders are:Table name DescriptionBAPC_ACTION_LOG Action LogBAPC_ORDER Posting Control OrderCDCLS Cluster structure for change documentsCDHDR Change document headerCDPOS_STR Additional Change Document - Table for STRINGsCDPOS_UID Additional Table for Inclusion of TABKEY>70 CharactersAM Posting Control Orders: TAANA Ad Hoc VariantThe following table and fields can be used to analyze the yearly and monthly distribution of posting controlorders:BAPC_ORDER Z_BAPC_ORDER-POSTDATE_CREA_YEAR Z_BAPC_ORDER-POSTDATE_CREA_MONTH© 2011 SAP AG page 34/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.05.6 AM Transaction FiguresAM Transaction Figures: DescriptionAM transaction figures are the total of all postings to an account per posting date, value date day, andturnover class, separated according to debit and credit. AM transaction figures are updated during thecalculation of balances.AM Transaction Figures: Archiving Object and ConfigurationThe archiving object for AM transaction figures is FIGURES.I. Definition of residence timesIn the IMG activity Define Deduction Period for Transaction Figures (object FIGURES) you define the periodof time after which transaction figures are archived in the operational system.II. ActivitiesBank Posting AreaBank Posting Area is a required field. There must be an entry for each bank posting area. If, however, thereis no entry for a particular bank posting area, the residence time is taken from the global control ofarchiving and used for the transaction figures for this bank posting area. The turnover class, productcategory, and product are optional.Turnover ClassThere may be several turnover classes per product or account. If you wish to define the deduction period forthe normal transaction figures, enter nothing.Product Category and ProductThe product category and external product ID of the product form a unit and must always be enteredtogether.Safety MarginThe safety margin is used in the ways as described in the section ―Preconditions‖ below. It consists of oneunit and one deduction period (number of units) and corresponds to calendar days.The safety margin must be longer than—or the same as—the minimum residence time defined in the checktable for the global control of archiving.Deduction PeriodHere you specify the number of units. Deduction Period is a required field.UnitThe following units are possible:  Months  Years© 2011 SAP AG page 35/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0Unit is a required field.III. NotesThe period for which a transaction figure can be used as a calculation basis can differ from the period ofuse.Examples: The account maintenance charges for April are governed by the incoming salary (turnover class) in March. The account maintenance charges for April are governed by the incoming salary (turnover class) from January to March.AM Transaction Figures: PreconditionsThe related transaction figures must exist in the operational system per account for the settlement periods forwhich settlements exist with the operational status. However, it would be extremely complicated and time-consuming to calculate the exact transaction figures required for a settlement period using the standard andindividual conditions, and this is therefore not done. Instead, you define a safety margin for the FIGURESobject (transaction figures) per bank posting area, turnover class, product category, and product.The transaction figures must meet the preconditions below to be archived.The transaction figures that can be archived are calculated on the basis of the safety margin as follows: 1. The system calculates the earliest existing start date of the settlements of an account: (MIN [BCA92- START_TMSTP]), for example, 07/11/2001. 2. The Customizing settings are used as a base to calculate the valid safety margin for the account and the respective turnover class, for example, 3 months. 3. The safety margin is subtracted from the earliest existing start date of an account settlement, for example, 04/11/2001. 4. Transaction figures are always archived in complete months. The date determined in point 3 is therefore set to the first day of the month, for this example, 04/01/2001.If the posting date and value date are earlier than the date calculated in point 4 for all transaction figures of aturnover class and month, the corresponding transaction figures may be archived. If the criteria are notfulfilled, none of the transaction figures from the relevant turnover class and month are archived.You must not leave any gaps within a turnover class. Example: o January 2001 can be archived o February 2001 cannot be archived o March 2001 can be archivedOnly January is archived; February and March are not.© 2011 SAP AG page 36/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0AM Transaction Figures: Display Archived DataYou can find the Display Balance List of Archived Transaction Figures report from the SAP Easy Accessscreen by choosing Financial Services  Account Management  Archiving  Data Display BCA_AR_FIGURES_BVW.AM Transaction Figures: TablesThe table for AM transaction figures is:Table name DescriptionBCA_TRANSFIG Value Date Transaction FiguresAM Transaction Figures: TAANA Ad Hoc VariantThe following table and fields can be used to analyze the yearly and monthly distribution of transactionfigures:BCA_TRANSFIG Z_DATE_POST_YEAR Z_DATE_POST_MONTHAM Transaction Figures: Residence TimesIn general, it is expected that the runtimes for settlement runs and settlement simulation runs will slow downwith a growing number of entries in table BCA_TRANSFIG. Consequently, we recommend archivingtransaction figures as soon as possible. Although the transaction figures can be read from the archive todisplay the data (see section 5.3), however, the settlement and settlement simulation runs cannot read fromthe archive due to performance reasons. If you would like to keep transaction figure data online to calculatesettlements for certain account products or turnover classes, we recommend defining longer residence timesfor these account types and turnover classes and shorter residence times for the rest of the data. Configurespecific residence times as described in section 5.3 to meet your internal or legal requirements.The same applies for counters.© 2011 SAP AG page 37/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.05.7 AM Individual ConditionsAM Individual Conditions: DescriptionAn individual condition is a condition which, contrary to a standard condition, only applies for a certaincontract.AM Individual Conditions: Archiving Object and ConfigurationThe archiving object for individual conditions is INDCOND.I. Definition of residence timesIn the IMG activity Define Residency Time for Individual Conditions, you define after which time the individualconditions are to be archived.II. ActivitiesYou must always specify the bank posting area and the residence time. Ensure that you enter at least theresidence time for each bank posting area. The period must be at least one month.You can use the condition group category, product category, and product attributes to differentiatebetween your residence time settings in greater detail.The system determines the residence time of an individual condition by checking whether its attributescorrespond to the details specified in the IMG activity. During this process, the system checks all possiblematches from the best (all attributes match) to the worst (only the bank posting area matches) in the followingsequence: 1. Bank posting area, condition group category, product category and product 2. Bank posting area, condition group category 3. Bank posting area, product category and product 4. Bank posting areaIII. NotesThe residence time you enter must meet the prerequisites below:  It must be later than or the same as the minimum residence time set in IMG activity Maintain Global Archiving Control. If you do not make an entry in this IMG activity, the standard residence time applies.  The residence time for the individual condition must have elapsed. The program uses the valid-to date for the individual condition to calculate the residence time if none of the cases below apply: o If the status is deleted, the program uses the released on date as the base. o If there is no released on date, the program uses the changed on date as the base. o If there is no changed on date, the program uses the created on date as the base.AM Individual Conditions: PreconditionsBusiness checks are performed during the analysis phase of the archiving process. The followingrequirements must be met for individual conditions to enable the subsequent archiving:  The Individual Condition indicator must be set.© 2011 SAP AG page 38/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0  Conditions with the validity category fixed-base contract start or fixed-base payment agreement start are only given the status Can Be Archived if the base account contract has the contract status Deleted and its reactivation period has elapsed.  Individual conditions with the validity category fixed base start of term or variable are only given the Can Be Archived status if the following prerequisites have been met: o Settlement condition group category: The individual conditions in this condition group category are no longer required for the reversal or recalculation of a settlement that has already run. The individual conditions in this condition group category are no longer required for the next settlement. Example: An account is created on January 3, 2003. The product on which it is based is settled annually on December 31. On March 15, 2003, an individual condition is created with the valid-on date January 15, 2003, and the valid-to date May 15, 2003. The residence time for the settlement is one year. The residence time for the individual condition is six months. Since the individual condition is therefore still required for the settlement on December 31, 2003, it must not be archived on November 15, 2003, but as of December 31, 2004. The individual conditions in this condition group category are no longer required for any adjustments to settlements that have run. o Event, transaction, and cards condition group categories: The individual conditions in these condition group categories are no longer used. This is the case if the valid-to date for the individual condition is earlier than the oldest permitted posting date.Standard conditions are not archived with the archiving object INDCOND.AM Individual Conditions: Display Archived DataYou can find the Display Archived Individual Conditions report from the SAP Easy Access screen bychoosing Financial Services  Account Management  Archiving  Data Display  BVW_INDCOND -Individual Conditions (Archiving Object INDCOND).When you decide that your customers will access archived data, for example, via online banking, you shouldtest the display of archived data via Web UI with mass data.AM Individual Conditions: TablesThe tables for AM individual conditions are:Table name DescriptionBCA_REL_LOG_D Detail Data of Log Table for ReleaseBCA_REL_LOG_H Header Data of Log Table for ReleaseCDCLS Cluster structure for change documentsCDHDR Change document headerCDPOS_STR Additional Change Document - Table for STRINGs© 2011 SAP AG page 39/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0Table name DescriptionCDPOS_UID Additional Table for Inclusion of TABKEY>70 CharactersFICOT_COND_T Texts for Conditions (Unbuffered)FICOT_CONDI Conditions (Unbuffered)FICOT_POS Condition Items (Unbuffered)FICOT_POS_REL Relationships Between Condition Items and Condition TypesAM Individual Conditions: TAANA Ad Hoc VariantThe following table and fields can be used to analyze the yearly and monthly distribution of individualconditions:FICOT_CONDI Z_D_VALIDTO_YEAR Z_D_VALIDTO_MONTH© 2011 SAP AG page 40/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.05.8 AM Info ItemsAM Info Items: DescriptionAn info item is a payment item saved purely for information purposes (interest penalty or debit position items,for example).Info items do not originate from payment transactions and are not transferred to the general ledger, nor dothey affect the account balance, balances, or the available amount. Info items may have an effect on flexiblebalances.AM Info Items: Archiving Object and ConfigurationThe archiving object for info items is INFOITEM. Info items can only be archived with Archiving Engine.I. Definition of residence timesIn the IMG activity Define Residence Time and Resubmission Period for Info Items, you define the period oftime after which info items are archived in the operational system and resubmission periods apply for eachbank posting area.II. ActivitiesYou must always specify the bank posting area, the resubmission period, and the residence time. Ensurethat you enter at least the residence time for each bank posting area. The residence time must be at leastone day. The residence time of the info items is based on the posting date or the release date of the infoitem, whichever is most recent.You can enter more detailed settings for the residence time and resubmission period by using the attributesProduct and Transaction Type. The product and transaction type are optional.The residence time and resubmission period consist of a period unit and a number of periods. The residencetime and the resubmission period refer to calendar days, not to posting days or working days. The residencetime must be at least one day. The basis for the residence time for info items is either the posting date or therelease date of the info item, depending on which date is the latest.The system determines the residence time of an info item by checking whether its attributes correspond tothe details specified in the IMG activity. The system checks from the most matches possible (all attributesmatch) down to the least matches possible (only the bank posting area matches) in the following sequence: 1. Bank posting area, product, transaction type 2. Bank posting area, transaction type 3. Bank posting area, product 4. Bank posting areaIII. NotesThe resubmission period and the residence time refer to calendar days, and not to posting days or workdays.The residence time you enter must meet the prerequisites below: It must be later than—or the same as—the minimum residence time set in IMG activity Maintain Global Archiving Control with Archiving Engine.© 2011 SAP AG page 41/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0 An info item can consist of multiple positions. Each of these positions has a different transaction type. Since the residence time can depend on the transaction type, depending on the Customizing settings, there could be different residence times within an info item. The individual positions in an info item can only be archived as a unit. To ensure this happens, the residence time is determined for each of the individual positions in an info item. The latest residence time then applies to all positions in the info item.If you do not make an entry in this IMG activity, the standard residence time applies. This is the residencetime you defined for info items in Customizing for Account Management (FS-AM) under Archiving  MaintainGlobal Archiving Control with Archiving Engine.The residence time depends on a product or a transaction type. This may give rise to the followingsituations:1. Different residence times for different products (and a product change): If you initially use a product to define the residence time, and then enter another product and execute a product change during the current productive operations, the system uses the residence time of the product that is currently valid as a basis for the archiving object data records created in the operational system after the product change. If the residence time of the old product was longer than that of the new product, the data records that were created after the product change are archived before the data records created before the product change. This may mean that older data records are still in the operational system even though newer ones are already in the archive.2. Different residence times for different transaction types: If you set different residence times for different transaction types, transaction type data records that were created at the same time may be archived at different times. This may mean that older data records are still in the operational system although newer data records are already in the archive.AM Info Items: PreconditionsBusiness checks are performed during the analysis phase of the archiving process. The followingrequirements must be met for an info item to enable the subsequent archiving:  If the account was closed and the reactivation period has expired, the info item can be archived.  If the account is still active, or if the reactivation period for the closed account has still not expired, additional checks are run: a. If the account was not yet settled, the info item cannot be archived. b. The posting date of the items for settlement must be before the oldest existing start date of a settlement period for the account in all settlement tracks. c. The highest monitoring level must be expired. This means that the posting date of the debit position item, plus the catch-up period, must be before the oldest allowed posting date. d. The debit position items must be included in the bonus calculation if a bonus is to be calculated for the account. The posting date of the debit position item must, therefore, be before the oldest existing start date of a settlement period for the account. e. The items relevant for settlement (interest penalty) with a reference to the triggering payment items can only be archived if the triggering payment item was already archived. Background: When the bank statement is written, or when the savings book is updated, any incurred interest penalty must be displayed when a withdrawal is made. f. Does the info item belong to the last settlement? If it does, it must not be archived, since the last settlement may have since been reversed. g. The last settlement of active accounts is always available in the operative system. If the reactivation period has expired for a deleted account, however, then the last settlement is© 2011 SAP AG page 42/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0 allowed to be archived. Therefore, all info items are archived once the residence time has expired on deleted accounts whose reactivation period has expired.AM Info Items: Display Archived DataYou can find the Display Archived Info Items report from the SAP Easy Access screen by choosingFinancial Services  Account Management  Archiving  Data Display  BVW_INFOITEM - InformationItems (Archiving Object INFOITEM).AM Info Items: TablesThe tables for AM info Items are:Table name DescriptionBCA_INFOITEM Info ItemsBCA_PAYMITEM_NT Info Notes of a Info ItemAM Info Items: TAANA Ad Hoc VariantThe following table and fields can be used to analyze the yearly and monthly distribution of Info items:BCA_INFOITEM Z_DATE_POST_YEAR Z_DATE_POST_MONTH© 2011 SAP AG page 43/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.05.9 AM Available Balance SeriesAM Available Balance Series: DescriptionIn the Account Management system, the Available Balance Series serve as the basis for determining thefollowing data for savings accounts: 1. Withdrawal not subject to early withdrawal penalty This specifies that on a certain key date a customer can withdraw an amount without having to pay an early withdrawal penalty. 2. Interest penalty amount This specifies the calculated interest penalty amount.The available balance series is only managed for accounts with feature 0017 (notice on amount). On thebasis of the available balance series, the Account Management system checks whether credits to an accountare subject to a notice period and, if not, if they can be withdrawn without incurring an early withdrawalpenalty.The available balance series is built up by the notice amounts and used up by withdrawals.Every entry has a notice amount and an available balance. The notice amount is restricted (in time) by thevalidity of the notice amount.AM Available Balance Series: Archiving Object and ConfigurationThe archiving object for AM available balance series is NOW_ABS.I. Definition of residence timesIn the IMG activity Define Residence Time for Available Balance Series (object NOW_ABS), you specify theperiod in the operational system after which available balance series are archived for each bank postingarea.II. ActivitiesYou must always specify the bank posting area and the residence time. This period must be at least oneday. Ensure that you enter at least the residence time for each bank posting area.You can use the product attribute to further differentiate your settings for the residence time.The system determines the residence time of an available balance series by checking if its attributes matchthose specified in the IMG activity. The system checks from the most matches (all attributes match) down tothe least matches (only the bank posting area matches) in the following sequence: 1. Bank posting area, product 2. Bank posting areaIII. NotesThe residence time you enter must meet the prerequisites below: It must be later than—or the same as—the minimum residence time set in IMG activity Maintain Global Archiving Control or in IMG activity Maintain Global Archiving Control with Archiving Engine.© 2011 SAP AG page 44/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0 If you do not make an entry in this IMG activity, the system uses the standard residence time defined for available balance series in the Customizing for Account Management (FS-AM) under Archiving  Maintain Global Archiving Control or Maintain Global Archiving Control with Archiving Engine. The residence time depends on a product. Therefore, if you have different residence times for different products (and a product change), the following situations may arise: If you initially use a product to define the residence time, and then enter another product and execute a product change during the current productive operations, the system uses the residence time of the product that is currently valid as a basis for the archiving object data records created in the operational system after the product change. If the residence time of the old product was longer than that of the new product, the data records that were created after the product change are archived before the data records created before the product change. This may mean that older data records are still in the operational system even though newer ones are already in the archive.AM Available Balance Series: PreconditionsBusiness checks are performed during the analysis phase of the archiving process. The followingrequirements must be met for an available balance series to enable the subsequent archiving: The valid-to date of the available balance series (BCA_NOW_ABS-DATE_VALID_TO_DB) must be before the earliest existing settlement date for the account in question. Consequently, if there has not yet been a settlement for the account, no available balance series is archivable. In notices on amount, data (such as withdrawn amount) is displayed that is read from the available balance series. This means that an entry from the available balance series may only be archived if the notice on amount in question has already been archived.The following rejection reasons may be set as consequence of the business checks: 01 Value date in the past still possible 02 Predecessor ORDER_NOW not archived.AM Available Balance Series: Display Archived DataYou can find the Display Archived Available Balance Series report from the SAP Easy Access screen bychoosing Financial Services  Account Management  Archiving  Data Display  BVW_NOW_ABS -Available Balance Series (Archiving Object NOW_ABS).AM Available Balance Series: TablesThe table for AM NOW_ABS is:Table name DescriptionBCA_NOW_ABS Notice on Amount: Available Balance SeriesAM Available Balance Series: TAANA Ad Hoc VariantThe following table and fields can be used to analyze the yearly and monthly distribution of available balanceseries:BCA_NOW_ABS Z_DATE_VALID_FR_DB_YEAR Z_DATE_VALID_FR_DB_MONTH© 2011 SAP AG page 45/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.05.10 AM Account Holder ChangeAM Account Holder Change: DescriptionAn account holder change is an order that changes the master data entry for the account holder of anaccount in the Account Management (FS-AM) system. The previous account holder is replaced by a newbusiness partner, which exists in the roles of account holder and correspondence recipient.The account holder change is managed in the Account Management system as an order by OrderManagement and is depicted on the account through the activation of the order. The account holder changeexecutes all the necessary functions, such as deleting existing standing orders.AM Account Holder Change: Archiving Object and ConfigurationThe archiving object for account holder change is ORDER_CAH. It can only be used with the ArchivingEngine.I. Definition of residence timesIn the IMG activity Define Residence Time for Account Holder Change, you define the period of time afterwhich account holder changes are archived in the operational system. This must be at least one day.II. ActivitiesYou must always specify the bank posting area and the residence time. Ensure that you enter at least theresidence time for each bank posting area.You can further differentiate your settings for the residence time with the product and order statusattributes. The product and order status are optional.The residence time and resubmission period consist of a period unit and a number of periods. The residencetime and the resubmission period refer to calendar days, not to posting days or working days. The residencetime must be at least one day.The basis for the residence time depends on the status of the order for account holder change: Status Basis for the Residence Time 0100 Entered Change time (date part) or, if this is not entered, the entry time (date part) 0110 Deleted Change time (date part) 0120 Executed Execution dateThe current product of the contract is used to determine the residence time.The system determines the residence time of an account holder change by checking whether its attributescorrespond to the details specified in the IMG activity. The system checks from the most matches possible(all attributes match) down to the least matches possible (only the bank posting area matches) in thefollowing sequence: 1. Bank posting area, transaction type, product 2. Bank posting area, transaction type 3. Bank posting area, product 4. Bank posting area© 2011 SAP AG page 46/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0III. NotesIf you do not make an entry in this IMG activity, the standard residence time applies. This is the residencetime you defined for account holder change in Customizing for Account Management (FS-AM) underArchiving  Maintain Global Archiving Control with Archiving Engine.The residence time you enter must be longer than—or the same as—the minimum residence time set in IMGactivity Maintain Global Archiving Control with Archiving Engine.AM Account Holder Change: PreconditionsNo business-related checks are made for this archiving object. For this reason, choose a residence time thatensures that all orders created for an account holder change are executed before the residence time expires.AM Account Holder Change: Display Archived DataYou can find the Display Archived Account Holder Change report from the SAP Easy Access screen bychoosing Financial Services  Account Management  Archiving  Data Display BCA_AR_PAYMITEM_BVW – Account Holder Change.When you decide that your customers will access archived data, for example, via online banking, you shouldtest the display of archived data via Web UI with mass data.AM Account Holder Change: TablesThe tables for AM account holder change are:Table name DescriptionBCA_ORDER Order Management BCABCA_OR_CAH Order table for account holder changeBCA_OR_CALLOR Assignment of activities and objects to ordersBCA_OR_LINK Link table: Assignment of order to objectsBCA_REL_LOG_D Detail Data of Log Table for ReleaseBCA_REL_LOG_H Header Data of Log Table for ReleaseCDCLS Cluster structure for change documentsCDHDR Change document headerCDPOS_STR Additional Change Document - Table for STRINGsCDPOS_UID Additional Table for Inclusion of TABKEY>70 CharactersAM Account Holder Change: TAANA Ad Hoc VariantThe following table and fields can be used to analyze the yearly and monthly distribution of account holderchange, with restriction to entries with order category (ORDER_CATG) = CAH:BCA_ORDER ORDER_CATG Z_LAST_UPDATE_TS_YEAR Z_LAST_UPDATE_TS_MONTH© 2011 SAP AG page 47/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.05.11 AM Card Product ChangeAM Card Product Change: DescriptionA card product change is an order that depicts the transition of a contracts source product to a targetproduct. The target product can be a new product version of the source product or a completely differentproduct. The system always chooses the valid product version of the target product.The card product change is managed in the Account Management system as an order by OrderManagement. By activating the order, the card product is flagged for change and the actual change istriggered by executing the order.AM Card Product Change: Archiving Object and ConfigurationThe archiving object for card product change is ORDER_COCP.I. Definition of residence timesIn the IMG activity Define Residence Time for Card Product Change, you define the period of time after whichcard product changes are archived in the operational system.II. ActivitiesYou must always specify the bank posting area and the residence time. Ensure that you enter at least theresidence time for each bank posting area.You can further differentiate your settings for the residence time with the product and order statusattributes. The product and order status are optional.The system determines the residence time of a card product change by checking whether its attributescorrespond to the details specified in the IMG activity. The system checks from the most matches possible(all attributes match) down to the least matches possible (only the bank posting area matches) in thefollowing sequence: 1. Bank posting area, product, order status 2. Bank posting area, product 3. Bank posting area, order status 4. Bank posting areaIII. NotesIf you do not make an entry in this IMG activity, the standard residence time applies. This is the residencetime you defined for card product change in Customizing for Account Management (FS-AM) under Archiving Maintain Global Archiving Control.Note that the residence time you enter must be longer than—or the same as—the minimum residence timeset in IMG activity Maintain Global Archiving Control.The residence time refers to calendar days, and not to posting days or working days.The residence time depends on a product. Therefore, if you have different residence times for differentproducts (and a product change), the following situations may arise:© 2011 SAP AG page 48/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0  If you initially use a product to define the residence time, and then enter another product and execute a product change during the current productive operations, the system uses the residence time of the product that is currently valid as a basis for the archiving object data records created in the operational system after the product change.  If the residence time of the old product was longer than that of the new product, the data records that were created after the product change are archived before the data records created before the product change. This may mean that older data records are still in the operational system even though newer ones are already in the archive.AM Card Product Change: PreconditionsBusiness checks are performed during the analysis phase of the archiving process. The followingprerequisites must be fulfilled before a card product change order can be archived:  The product change must have one of the following order statuses: o 0100 (entered) o 0110 (deleted) o 0130 (deactivated) o 0140 (executed)  The product change has release status Not in Release.AM Card Product Change: Display Archived DataYou can find the Display Archived Card Product Change report from the SAP Easy Access screen bychoosing Financial Services  Account Management  Archiving  Data Display  BVW_ORDER_COP -Card Product Changes (Archiving Object ORDER_COP).AM Card Product Change: TablesThe tables for AM card product change are:Table name DescriptionBCA_OR_COCP Product Change Order for Individual Cards (Mass Data Model)BCA_OR_LINK Link table: Assignment of order to objectsBCA_REL_LOG_D Detail Data of Log Table for ReleaseBCA_REL_LOG_H Header Data of Log Table for ReleaseCDCLS Cluster structure for change documentsCDHDR Change document headerCDPOS_STR Additional Change Document - Table for STRINGsCDPOS_UID Additional Table for Inclusion of TABKEY>70 Characters© 2011 SAP AG page 49/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0AM Card Product Change: TAANA Ad Hoc VariantThe following table and fields can be used to analyze the yearly and monthly distribution of card productchange:BCA_OR_COCP Z_LAST_UPDATE_TS_YEAR Z_LAST_UPDATE_TS_MONTH© 2011 SAP AG page 50/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.05.12 AM Account Product ChangeAM Account Product Change: DescriptionAn account product change is an order that depicts the transition of a contracts source product to a targetproduct. The target product can be a new product version of the source product or a completely differentproduct. The system always chooses the valid product version of the target product.The account product change is managed in the Account Management system as an order by OrderManagement. By activating the order, the account product is flagged for change and the actual change istriggered by executing the order.AM Account Product Change: Archiving Object and ConfigurationThe archiving object for account product change is ORDER_COP.I. Definition of residence timesIn the IMG activity Define Residence Time for Account Product Change, you define the period of time afterwhich account product changes are archived in the operational system. This must be at least one day.II. ActivitiesYou must always specify the bank posting area and the residence time. Ensure that you enter at least theresidence time for each bank posting area.You can further differentiate your settings for the residence time with the product and order statusattributes. The product and order status are optional.The system determines the residence time of an account product change by checking whether its attributescorrespond to the details specified in the IMG activity. The system checks from the most matches possible(all attributes match) down to the least matches possible (only the bank posting area matches) in thefollowing sequence: 1. Bank posting area, product, order status 2. Bank posting area, product 3. Bank posting area, order status 4. Bank posting areaIII. NotesIf you do not make an entry in this IMG activity, the standard residence time applies. This is the residencetime you defined for account product change in Customizing for Account Management (FS-AM) underArchiving  Maintain Global Archiving Control.The residence time you enter must be longer than—or the same as—the minimum residence time set in IMGactivity Maintain Global Archiving Control.The residence time refers to calendar days, and not to posting days or working days.The residence time depends on a product. Therefore, if you have different residence times for differentproducts (and a product change), the following situations may arise:© 2011 SAP AG page 51/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0  If you initially use a product to define the residence time, and then enter another product and execute a product change during the current productive operations, the system uses the residence time of the product that is currently valid as a basis for the archiving object data records created in the operational system after the product change.  If the residence time of the old product was longer than that of the new product, the data records that were created after the product change are archived before the data records created before the product change. This may mean that older data records are still in the operational system even though newer ones are already in the archive.AM Account Product Change: PreconditionsBusiness checks are performed during the analysis phase of the archiving process. The followingprerequisites must be fulfilled before an account product change order can be archived:  The product change must have one of the following order statuses: o 0100 (entered) o 0110 (deleted) o 0130 (deactivated) o 0140 (executed)  The product change has release status Not in Release.AM Account Product Change: Display Archived DataYou can find the Display Archived Account Product Change report from the SAP Easy Access screen bychoosing Financial Services  Account Management  Archiving  Data Display  BVW_ORDER_COP -Account Product Changes (Archiving Object ORDER_COP).AM Account Product Change: TablesThe tables for AM account product change are:Table name DescriptionBCA_OR_COP Product Change Order (Mass Data Model)BCA_OR_LINK Link table: Assignment of order to objectsBCA_REL_LOG_D Detail Data of Log Table for ReleaseBCA_REL_LOG_H Header Data of Log Table for ReleaseCDCLS Cluster structure for change documentsCDHDR Change document headerCDPOS_STR Additional Change Document - Table for STRINGsCDPOS_UID Additional Table for Inclusion of TABKEY>70 Characters© 2011 SAP AG page 52/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0AM Account Product Change: TAANA Ad Hoc VariantThe following table and fields can be used to analyze the yearly and monthly distribution of account productchange:BCA_OR_COP Z_LAST_UPDATE_TS_YEAR Z_LAST_UPDATE_TS_MONTH© 2011 SAP AG page 53/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.05.13 AM Orders for CrExAv2 DetailsAM Order for CrExAv Details: DescriptionAn order for CrExAv details is an order that changes the information that is stored in the system and includesthe following data of a credit with extended availability (CrExAv):  Validity period  GUID of underlying payment item  Remaining amount and currencyThe order for CrExAv details is managed in the Account Management system as an order by OrderManagement. By activating the order, the CrExAv details is flagged for change and the actual change istriggered by executing the order.AM Order for CrExAv Details: Archiving Object and ConfigurationThe archiving object for CrExAv details orders is ORDER_CXA.I. Definition of residence timesIn the IMG activity Define Residence Time for CrExAv details order, you define the period of time after whicha CrExAv details order is archived in the operational system. This must be at least one day.II. ActivitiesYou must always specify the bank posting area and the residence time. Ensure that you enter at least theresidence time for each bank posting area.You can further differentiate your settings for the residence time with the product and order statusattributes. The product and order status are optional.The system determines the residence time of a credit with extended availability details by checking whetherits attributes correspond to the details specified in the IMG activity. The system checks from the mostmatches possible (all attributes match) down to the least matches possible (only the bank posting areamatches) in the following sequence: 1. Bank posting area, product, order status 2. Bank posting area, product 3. Bank posting area, order status 4. Bank posting areaIII. NotesIf you do not make an entry in this IMG activity, the standard residence time applies. This is the residencetime you defined for CrExAv details orders in Customizing for Account Management (FS-AM) under Archiving Maintain Global Archiving Control.The residence time you enter must be longer than—or the same as—the minimum residence time set in IMGactivity Maintain Global Archiving Control.2 Credit with extended availability© 2011 SAP AG page 54/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0The residence time refers to calendar days, and not to posting days or working days.The basis of the residence time depends on the status of the credit with extended availability details. Status Residence Time Basis 0100 Entered Validity end (date part) 0110 Deleted Validity end (date part)The current product for the contract is used to determine the residence time.The residence time depends on a product. Therefore, if you have different residence times for differentproducts (and a product change), the following situations may arise:  If you initially use a product to define the residence time, and then enter another product and execute a product change during the current productive operations, the system uses the residence time of the product that is currently valid as a basis for the archiving object data records created in the operational system after the product change.  If the residence time of the old product was longer than that of the new product, the data records that were created after the product change are archived before the data records created before the product change. This may mean that older data records are still in the operational system even though newer ones are already in the archive.AM Order for CrExAv Details: PreconditionsBusiness checks are performed during the analysis phase of the archiving process. The followingprerequisites must be fulfilled before an order for CrExAv details can be archived:  The order for credit with extended availability details must have one of the following order statuses: o 0100 (entered) o 0110 (deleted)  If the order for credit with extended availability details contains a reference to a payment item, archive the payment item first.  The available balance series of the credit with extended availability details must be archived first.The business checks set the following rejection reasons: o 01 Available balance series not archived o 02 Payment item not archived o 03 (currently not used) o 04 CrExAv details in release process (currently not used) o 05 Internal errorAM Order for CrExAv Details: Display Archived DataYou can find report Display CrExAv Details from Archive in the SAP Easy Access screen by choosingFinancial Services  Account Management  Archiving  Data Display  CrExAv Details (Archiving objectORDER_CXA).© 2011 SAP AG page 55/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0AM Order for CrExAv Details: TablesThe tables for AM orders for CrExAv details are:Table name DescriptionBCA_ORDER Order (General Data)BCA_REL_LOG_D Detail Data of Log Table for ReleaseBCA_REL_LOG_H Header Data of Log Table for ReleaseCDCLS Cluster structure for change documentsCDHDR Change document headerCDPOS_STR Additional Change Document - Table for STRINGsCDPOS_UID Additional Table for Inclusion of TABKEY>70 CharactersAM Order for CrExAv Details: TAANA Ad Hoc VariantThe following table and fields can be used to analyze the yearly and monthly distribution of orders for CrExAvdetails with restriction to entries with order category (ORDER_CATG) = CXA:BCA_ORDER ORDER_CATG Z_LAST_UPDATE_TS_YEAR Z_LAST_UPDATE_TS_MONTH© 2011 SAP AG page 56/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.05.14 AM Order for Notice on AmountAM Order for Notice on Amount: DescriptionAn order for notice on amount is an order that changes the information that is stored in the system andincludes the following data of a credit with extended availability (CrExAv):  Validity period  GUID of underlying payment item  Remaining amount and currencyThe order for notice on amount is managed in the Account Management system as an order by OrderManagement. By activating the order, the notice on amount is flagged for change and the actual change istriggered by executing the order.AM Order for Notice on Amount: Archiving Object and ConfigurationThe archiving object for orders for notice on amount is ORDER_NOW. This archiving object is a hybridobject; you can carry out data archiving using both data archiving (SARA) and the Archiving Engine.I. Definition of residence timesIn the IMG activity Define Residence Time for Notice on Amount, you define the period of time after which anorder for notice on amount is archived in the operational system. This must be at least one day.II. ActivitiesYou must always specify the bank posting area and the residence time. Ensure that you enter at least theresidence time for each bank posting area.You can further differentiate your settings for the residence time with the product and order statusattributes. The product and order status are optional.The system determines the residence time of an order for notice on amount by checking whether its attributescorrespond to the details specified in the IMG activity. The system checks from the most matches possible(all attributes match) down to the least matches possible (only the bank posting area matches) in thefollowing sequence: 1. Bank posting area, product, order status 2. Bank posting area, product 3. Bank posting area, order status 4. Bank posting areaIII. NotesIf you do not make an entry in this IMG activity, the standard residence time applies. This is the residencetime you defined for account product change in Customizing for Account Management (FS-AM) underArchiving  Maintain Global Archiving Control or Maintain Global Archiving Control for Archive Engine.The residence time you enter must be longer than—or the same as—the minimum residence time set in IMGactivity Maintain Global Archiving Control or Maintain Global Archiving Control for Archive Engine.© 2011 SAP AG page 57/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0The residence time depends on a product. Therefore, if you have different residence times for differentproducts (and a product change), the following situations may arise:  If you initially use a product to define the residence time, and then enter another product and execute a product change during the current productive operations, the system uses the residence time of the product that is currently valid as a basis for the archiving object data records created in the operational system after the product change.  If the residence time of the old product was longer than that of the new product, the data records that were created after the product change are archived before the data records created before the product change. This may mean that older data records are still in the operational system even though newer ones are already in the archive.AM Order for Notice on Amount: PreconditionsBusiness checks are performed during the analysis phase of the archiving process. The followingprerequisites must be fulfilled before an order for notice on amount can be archived:  The order for credit with extended availability details must have one of the following order statuses: o 0100 (entered) o 0110 (deleted) o 0120 (activated), while Notices on amount with status 120 (activated) may only be archived once the validity period of the notice on amount has expired. o 0130 (deactivated)  A superordinate order for account closure must be archived.  The release status of the order for notice on amount is "Not in Release." This means that orders can only be archived if they have no versions currently in the release process.  Any Posting Lock Management (PLM) documents generated by the order must be archived.The business checks set the following rejection reasons: o 01 Notice on amount is active (status 120) o 02 Super ordinate order (TOC) active o 03 Order is in the release process o 04 There is an active PLM documentAM Order for Notice on Amount: Display Archived DataYou can find the report Display Archived Notice on Amounts in the SAP Easy Access screen by choosingFinancial Services  Account Management  Archiving  Data Display  CrExAv Details (Archiving objectORDER_CXA).AM Order for Notice on Amount: TablesThe tables for AM orders for notice on amount are:Table name DescriptionADR* Address tablesBCA_OR_LINK Link Table: Assignment Order - ObjectsBCA_OR_NOW Order for Notice on Amount (Mass Data Model)© 2011 SAP AG page 58/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0Table name DescriptionBCA_PAYREF Database Table - Payment DetailsBCA_REL_LOG_D Detail Data of Log Table for ReleaseBCA_REL_LOG_H Header Data of Log Table for ReleaseCDCLS Cluster structure for change documentsCDHDR Change document headerCDPOS_STR Additional Change Document - Table for STRINGsCDPOS_UID Additional Table for Inclusion of TABKEY>70 CharactersAM Order for Notice on Amount: TAANA Ad Hoc VariantThe following table and fields can be used to analyze the yearly and monthly distribution of orders for noticeon amount with restriction to entries with order category (ORDER_CATG) = NOW:BCA_OR_NOW ORDER_CATG Z_LAST_UPDATE_TS_YEAR Z_LAST_UPDATE_TS_MONTH© 2011 SAP AG page 59/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.05.15 AM Order for Account ClosureAM Order for Account Closure: DescriptionAn order for account closure is an order that manages the closure of the account between account holderand the contract-managing organizational unit (such as a bank).The account closure is managed in Account Management as an order from Order Management. By activatingthe order, the account is flagged for closure and the actual closure is triggered by executing the order. Theaccount closure executes all necessary functions, such as the clearing of the remaining balance and theaccount settlement. Once these have been completed, the accounts status is set to ―closed.‖AM Order for Account Closure: Archiving Object and ConfigurationThe archiving object for orders for account closure is ORDER_TOC. This archiving object is a hybrid object;you can carry out data archiving using both data archiving (SARA) and the Archiving Engine.I. Definition of residence timesIn the IMG activity Define Residence Time for Account Closures, you define the period of time after which anorder for account closure is archived in the operational system. This must be at least one day.II. ActivitiesYou must always specify the bank posting area and the residence time. Ensure that you enter at least theresidence time for each bank posting area.You can further differentiate your settings for the residence time with the product and order statusattributes. The product and order status are optional.The system determines the residence time of a payment item by checking whether its attributes correspondto the details specified in the IMG activity. The system checks from the most matches possible (all attributesmatch) down to the least matches possible (only the bank posting area matches) in the following sequence: 1. Bank posting area, product, order status 2. Bank posting area, product 3. Bank posting area, order status 4. Bank posting areaIII. NotesIf you do not make an entry in this IMG activity, the standard residence time applies. This is the residencetime you defined for account product change in Customizing for Account Management (FS-AM) underArchiving  Maintain Global Archiving Control or Maintain Global Archiving Control for Archive Engine.The residence time you enter must be longer than or the same as the minimum residence time set in IMGactivity Maintain Global Archiving Control or Maintain Global Archiving Control for Archive Engine.The residence time depends on a product. Therefore, if you have different residence times for differentproducts (and a product change), the following situations may arise:© 2011 SAP AG page 60/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0  If you initially use a product to define the residence time, and then enter another product and execute a product change during the current productive operations, the system uses the residence time of the product that is currently valid as a basis for the archiving object data records created in the operational system after the product change.  If the residence time of the old product was longer than that of the new product, the data records that were created after the product change are archived before the data records created before the product change. This may mean that older data records are still in the operational system even though newer ones are already in the archive.AM Order for Account Closure: PreconditionsBusiness checks are performed during the analysis phase of the archiving process. The followingprerequisites must be fulfilled before an order for account closure can be archived:  The account closure order must have one of the following order statuses: o 0100 (entered) o 0110 (deleted) o 0130 (deactivated) o 0150 (executed) o 0160 (reversed)  The release status of the order for account closure must be "Not in Release." This means that orders can only be archived if they have no versions currently in the release process.  For closed accounts, the maximum reactivation period must be expired.  If the order for account closure generates a notice on remaining amount, this must already have been archived.  Due to performance reasons, post-processing orders generated by the account closure are not checked with regard to business reasons. Only the existence of the post-processing orders is checked.The business checks set the following rejection reasons: o 01 Account active or can be reactivated o 02 Notice on amount not archived o 03 Post-processing orders not archived o 04 Account closure in the release process o 05 Internal errorAM Order for Account Closure: Display Archived DataYou can find the report Display Account Closures from Archive in the SAP Easy Access screen bychoosing Financial Services  Account Management  Archiving  Data Display  Account Closures(Archiving object ORDER_TOC).AM Order for Account Closure: TablesThe tables for AM orders for account closure are:Table name DescriptionBCA_OR_LINK Link Table: Assignment Order - ObjectsBCA_OR_TOC Order for Account Closure© 2011 SAP AG page 61/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0Table name DescriptionBCA_ORDER Order (General Data)BCA_REL_LOG_D Detail Data of Log Table for ReleaseBCA_REL_LOG_H Header Data of Log Table for ReleaseCDCLS Cluster structure for change documentsCDHDR Change document headerCDPOS_STR Additional Change Document - Table for STRINGsCDPOS_UID Additional Table for Inclusion of TABKEY>70 CharactersAM Order for Account Closure: TAANA Ad Hoc VariantThe following table and fields can be used to analyze the yearly and monthly distribution of orders for noticeon amount with restriction to entries with order category (ORDER_CATG) = TOC:BCA_ORDER ORDER_CATG Z_LAST_UPDATE_TS_YEAR Z_LAST_UPDATE_TS_MONTH© 2011 SAP AG page 62/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.05.16 AM Payment FormsAM Payment Forms: DescriptionPayment forms are:  Forms that have a payment form identification number when they are issued by the bank  Forms created by customers that have an identification number entered by the customer and acknowledged by the bankThe form must show a payment form identification number when it is presented for payment. A particular formcan be locked, for example, to prevent it from being presented for payment.AM Payment Forms: Archiving Object and ConfigurationThe archiving object for payment forms is PAYMFORM. Payment forms can only be archived with theArchiving Engine.I. Definition of residence timesIn the IMG activity Define Residence Time for Payment forms, you define the period of time after whichpayment forms are archived in the operational system.II. ActivitiesYou must always specify the bank posting area and the residence time. Ensure that you enter at least theresidence time for each bank posting area. The residence time must be at least one day.You can enter more detailed settings for the residence time by using the attributes Archiving Reason andPayment Form Type. The archiving reason and the payment form type are optional entries.The system determines the residence time of a payment form item by checking whether its attributescorrespond to the details specified in the IMG activity. The system checks from the most matches possible(all attributes match) down to the least matches possible (only the bank posting area matches) in thefollowing sequence: 1. Bank posting area, archiving reason, payment form type 2. Bank posting area, archiving reason 3. Bank posting area, payment form type 4. Bank posting areaIII. NotesThe resubmission period and the residence time refer to calendar days, and not to posting days or workdays.Note that the residence time you enter must meet the prerequisites below: It must be later than—or the same as—the minimum residence time set in IMG activity Maintain Global Archiving Control with Archiving Engine.If you do not make an entry in this IMG activity, the standard residence time applies. This is the residencetime you defined for payment forms in Customizing for Account Management (FS-AM) under Archiving Maintain Global Archiving Control with Archiving Engine.© 2011 SAP AG page 63/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0The residence time depends on a product or a transaction type. This may give rise to the followingsituations:1. Different residence times for different products (and a product change): If you initially use a product to define the residence time, and then enter another product and execute a product change during the current productive operations, the system uses the residence time of the product that is currently valid as a basis for the archiving object data records created in the operational system after the product change. If the residence time of the old product was longer than that of the new product, the data records that were created after the product change are archived before the data records created before the product change. This may mean that older data records are still in the operational system even though newer ones are already in the archive.2. Different residence times for different transaction types: If you have set different residence times for different transaction types, transaction type data records that were created at the same time may be archived at different times. This may mean that older data records are still in the operational system although newer data records are already in the archive.AM Payment Forms: PreconditionsBusiness checks are performed during the analysis phase of the archiving process. The followingrequirements must be met for a payment form to enable the subsequent archiving:  The account was deleted and the reactivation period has expired.  The Payment Form Was Deleted indicator is set (BCA_PAYMFORM-XDELETE=X).  Payment form was cashed (BCA_PAYMFORM-XCASHED=X)If one of the above conditions is fulfilled, an archiving reason is set accordingly: o 01 Payment form cashed o 02 Indicator Payment Form Deleted is set o 03 Account was deletedOnly payment forms that have a set archiving reason without a business rejection reason are allowed to bearchived after the residence time has expired.AM Payment Forms: Display Archived DataYou can find the Display Archived Payment forms report from the SAP Easy Access screen by choosingFinancial Services  Account Management  Archiving  Data Display  BVW_PAYMFORM – PaymentForms (Archiving Object PAYMFORM).AM Payment forms TablesThe tables for AM payment forms are:Table name DescriptionBCA_PAYMFORM Payment form administration: general dataBCA_PAYMFORM_REF References to Payment Forms (Additional Table)© 2011 SAP AG page 64/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0Table name DescriptionCDCLS Cluster structure for change documentsCDHDR Change document headerCDPOS_STR Additional Change Document - Table for STRINGsCDPOS_UID Additional Table for Inclusion of TABKEY>70 CharactersAM Payment Forms: TAANA Ad Hoc VariantThe following table and fields can be used to analyze the yearly and monthly distribution of payment forms:BCA_PAYMFORM Z_PAY_DATE_YEAR Z_PAY_DATE _MONTH© 2011 SAP AG page 65/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.05.17 AM Payment ItemsAM Payment Items: DescriptionA payment item is a one-sided turnover on a current account that represents either a credit or a debit memo.A payment item can consist of one or more payment item positions with the same item identification (item ID),for example, the return of a debit memo with the corresponding return charges.AM Payment Items: Archiving Object and ConfigurationThe archiving object for payment items is PAYMITEM.I. Definition of residence timesIn the IMG activity Define Residence Time and Resubmission Period for Payment Items, you define theperiod of time after which payment items are archived in the operational system and which resubmissionperiods apply for each bank posting area.II. ActivitiesYou must always specify the bank posting area, the resubmission period, and the residence time. Ensurethat you enter at least the residence time for each bank posting area.You can enter more detailed settings for the residence time and resubmission period by using the attributesTransaction Type and Product. The product and transaction type are optional.The residence time and resubmission period consist of a period unit and a number of periods. The residencetime and the resubmission period refer to calendar days, not to posting days or working days. The residencetime must be at least one day. The basis for the residence time for payment items is either the posting date orthe release date of the payment item, depending on which date is the latest.The system determines the residence time of a payment item by checking whether its attributes correspondto the details specified in the IMG activity. The system checks from the most matches possible (all attributesmatch) down to the least matches possible (only the bank posting area matches) in the following sequence: 1. Bank posting area, transaction type, product 2. Bank posting area, transaction type 3. Bank posting area, product 4. Bank posting areaIII. NotesThe residence time you enter must meet the prerequisites below: It must be later than—or the same as—the minimum residence time set in IMG activity Maintain Global Archiving Control. The residence time for all payment items must last at least the length of time during which the payment items flow to the general ledger or during which a retroactive balance adjustment is made. It must be later than the latest bank statement period. Otherwise, payment items that have already been archived but not yet printed on the bank statement would have to be read from the archive. This would have a negative impact on performance.© 2011 SAP AG page 66/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0 A payment item can consist of multiple positions. Each one of these positions has a different transaction type. Since the residence time can depend on the transaction type, depending on the Customizing settings, there could be different residence times within a payment item. The individual positions in a payment item can only be archived as a unit. To ensure this happens, the residence time is determined for each of the individual positions in a payment item. The latest residence time then applies to all positions in the payment item.If you do not make an entry in this IMG activity, the standard residence time applies. This is the residencetime you defined for payment items in Customizing for Account Management (FS-AM) under Archiving Maintain Global Archiving Control.The residence time depends on a product or a transaction type. This may give rise to the followingsituations:1. Different residence times for different products (and a product change): If you initially use a product to define the residence time, and then enter another product and execute a product change during the current productive operations, the system uses the residence time of the product that is currently valid as a basis for the archiving object data records created in the operational system after the product change. If the residence time of the old product was longer than that of the new product, the data records that were created after the product change are archived before the data records created before the product change. This may mean that older data records are still in the operational system even though newer ones are already in the archive.2. Different residence times for different transaction types: If you set different residence times for different transaction types, transaction type data records that were created at the same time may be archived at different times. This may mean that older data records are still in the operational system although newer data records are already in the archive.AM Payment Items: PreconditionsBusiness checks are performed during the analysis phase of the archiving process. The followingrequirements must be met for a payment item to enable the subsequent archiving:  Only payment items with the following statuses can be archived: 03 Posted 05 Deleted 06 Reversed 07 Returned  The date of the Subject to Final Payment balance must be in the past.  If the payment item is from a suspense (CpD) account, then it must be transfer posted. The payment item must therefore have status 06 (reversed).  If a payment item position has the "Cannot Be Archived" status, then each position for this payment item is set to "Cannot Be Archived."In addition, the following general object requirements must be met for the archiving of a payment item:  Bank statement© 2011 SAP AG page 67/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0 Only the payment items whose posting date and release time stamp are before the start time of the last bank statement (posting date and release time stamp) may be archived. This condition must be met for bank statement agreements of the account. Note: The bank statement may be printed after archiving the corresponding payment items. In this case, the print program will read the payment item information from the archive. To ensure smooth operation, you must ensure that the archive can be accessed fast enough.  Posting control order Payment items that have a posting control order due to the posting control rules may only be archived once the corresponding posting control order has reached the end status. The payment item must be archived with its posting control order if it has one. It is only necessary to check for a posting control order if the customer is using the posting control office.  Settlement The settlement saves the keys of the payment items and payment orders (generated during settlement) in the BKK92_POSTINGS table. Settlements can be reversed. The payment items that would have to be reversed are found using the BKK92_POSTINGS table and reversed using the "Reverse" method. The following attributes are filled in the table for payment items that were created by the settlement: Settlement type (SETTL_TYPE) Internal contract number of the settled contract (SETTL_CN_INT) Settlement period (SETTL_PERIOD) Addition to the settlement period number (SETTL_NRADD) Payment items where the above attributes have been filled can only be archived once the data is no longer kept in the settlements table BKK92_POSTINGS.  Intraday interest calculation The interest calculation for accounts to which intraday interest calculation applies is not based on transaction figures but directly on the payment item. Therefore, for these accounts, you need to ensure that for the settlement periods saved in the operational system, you also save their payment items there. Payment items where the intraday indicator is set can thus only be archived if the posting day and the value date of the payment item are before the earliest start date of the existing settlement periods for the account.  You can use business transaction event 0BCA3070 for further checks.AM Payment Items: Display Archived DataYou can find the Display Archived Payment Items report from the SAP Easy Access screen by choosingFinancial Services  Account Management  Archiving  Data Display  BCA_AR_PAYMITEM_BVW –Payment Items.© 2011 SAP AG page 68/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0When you decide that your customers will access archived data, for example, via online banking, you shouldtest the display of archived data via Web UI with mass data.AM Payment Items: TablesThe tables for AM payment items are:Table name DescriptionBCA_GL_PAYMITEM GL: Additional Payment Item DataBCA_PAYMITEM Payment ItemsBCA_PAYMITEM_NT Payment Notes of a Payment ItemBCA_REL_LOG_D Detail Data of Log Table for ReleaseBCA_REL_LOG_H Header Data of Log Table for ReleaseBCA_SB_2BR_CHNG Savings Book: Changes to Turnovers to be EnteredCDCLS Cluster structure for change documentsCDHDR Change document headerCDPOS_STR Additional Change Document - Table for STRINGsCDPOS_UID Additional Table for Inclusion of TABKEY>70 CharactersAM Payment Items: TAANA Ad Hoc VariantThe following table and fields can be used to analyze the yearly and monthly distribution of payment items:BCA_PAYMITEM Z_DATE_POST_YEAR* Z_DATE_POST_MONTH** The virtual fields Z_DATE_POST_YEAR and Z_DATE_POST_MONTH are available in the SAP transactionTAANA after you implement the latest version of the solutions tools plug-in ST-A/PI.5.18 AM Payment OrdersAM Payment Orders: DescriptionAn AM payment order depicts an order to a bank, for example, to execute a bank transfer or a debit memocollection. A payment order consists of two or more payment items: one ordering party item and one or morerecipient items. There are various types of payment orders:Internal payment orders: Payment orders whose order recipients are also managed in the AccountManagement (FS-AM) system.External payment orders: Payment orders whose order recipients are not managed within the AccountManagement (FS-AM) system.AM Payment Orders: Archiving Object and ConfigurationThe archiving object for AM payment orders is PAYMORDER.© 2011 SAP AG page 69/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0I. Definition of residence timesIn the IMG activity Define Residence Time for Payment Order (Object PAYMORDER), you define the periodof time after which payment orders can be archived in the operational system.II. ActivitiesDefine the residence time for each payment transaction area.You can use the product attribute to differentiate between your residence time settings in greater detail.The system determines the residence time of a payment order by checking whether its attributes correspondto the details specified in the IMG activity. During this process, the system checks all possible matches fromthe best (all attributes match) to the worst (only the payment transaction area matches) in the followingsequence: 1. Payment transaction area, product 2. Payment transaction areaIII. NotesThe residence time you enter must meet the prerequisites below:The residence time must be longer than or the same as the minimum residence time defined in IMG activityMaintain Global Archiving Control.If you do not make an entry in this IMG activity, the standard residence time applies. This is the residencetime you defined for payment orders in the Customizing for Account Management (FS-AM) under Archiving Maintain Global Archiving Control.The residence time depends on a product. Therefore, if you have different residence times for differentproducts (and a product change), the following situations may arise: 1. If you initially use a product to define the residence time, and then enter another product and execute a product change during the current productive operations, the system uses the residence time of the product that is currently valid as a basis for the archiving object data records created in the operational system after the product change. 2. If the residence time of the old product was longer than that of the new product, the data records that were created after the product change are archived before the data records created before the product change. This may mean that older data records are still in the operational system even though newer ones are already in the archive.AM Payment Orders: PreconditionsFunction module BCA_PO_API_ARCHIVE_CHECK checks the business-related prerequisites for archivingpayment orders and sets the archiving status for the data records not to be archived to 2 (cannot bearchived).© 2011 SAP AG page 70/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0The following prerequisites must be met for the archiving of a payment order:1. Archiving object-specific prerequisites: a. The payment order must have one of the following statuses: 03 Posted 05 Forward order deleted 06 Reversed 09 rejected 10 Posted in post-processing 12 Error in post-processing 13 Release rejected 14 Rejected, confirmation of non-execution generated b. The residence time of the payment order must have expired. The basis for calculating the residence time is the posting date.2. Prerequisites for archiving object-dependent objects: a. Reconciliation totals: A payment order may not be archived until its payment items are no longer contained in reconciliation totals on the posting day. b. Payment item: A payment order may not be archived until there are no more ordering party payment items for it in the operational system. Recipient payment items are not affected. c. Settlement The following settlements can only be reversed as long as payment orders resulting from the settlement have not yet been archived: 0090 Settlement account/card 0092 Settlement reference account/reference card 0095 Account closure 0096 Account closure end-of-day processing.The BAdI Archivability of Payment Orders is available to you as customer enhancement for the checkmodule BCA_PO_API_ARCHIVE_CHECK.© 2011 SAP AG page 71/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0AM Payment Orders: Display Archived DataYou can find the Display Archived Payment Orders report from the SAP Easy Access screen by choosingFinancial Services  Account Management  Archiving  Data Display  BVW_PAYMORDER – PaymentOrders.AM Payment Orders: TablesThe tables for AM payment orders are:Table name DescriptionBCA_PO_CORR_FEE Payment Order: Log for Charges and CorrespondenceBCA_PO_HD Payment OrderBCA_PO_IT Items of the Payment OrderBCA_PO_NT Payment Notes for a Payment OrderBCA_REL_LOG_D Detail Data of Log Table for ReleaseBCA_REL_LOG_H Header Data of Log Table for ReleaseCDCLS Cluster structure for change documentsCDHDR Change document headerCDPOS_STR Additional Change Document - Table for STRINGsCDPOS_UID Additional Table for Inclusion of TABKEY>70 CharactersAM Payment Orders: TAANA Ad Hoc VariantThe following table and fields can be used to analyze the yearly and monthly distribution of payment orders:BCA_PO_HD CLIENT Z_DATE_SYSTPOST_YEAR Z_DATE_SYSTPOST_MONTH POSTATUSAM Payment Orders: Additional InformationCollective payment orders are archived with archiving object POPROXY, which is available with bankingservices 7.0 (FS-APPL 300).© 2011 SAP AG page 72/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.05.19 AM PLM DocumentsAM PLM Documents: DescriptionA PLM document depicts business transactions (such as the death of an account holder) and sets anddeletes locks for lockable objects in Account Management.PLM documents are managed by Posting Lock Management (PLM) in Account Management. Each PLMdocument is based on a PLM document category and is set using the event type.AM PLM Documents: Archiving Object and ConfigurationThe archiving object for PLM documents is PLMDOC.I. Definition of residence timesIn the IMG activity Define Residence Time and for PLM Documents, you define the period of time after whichPLM documents are archived in the operational system for each event type.II. ActivitiesEnsure that you enter the residence time for each event type. The basis for the residence time is the enddate of the PLM document, which is stored in BCA_DEH_DOC_HEAD-SCHED_ACTIV_TO.III. NotesThe residence time you enter must meet the prerequisites below: It must be longer than—or the same as—the minimum residence time set in IMG activity Maintain Global Archiving Control.If you do not make an entry in this IMG activity, the standard residence time applies. This is the residencetime you defined for PLM documents in Customizing for Account Management (FS-AM) under Archiving Maintain Global Archiving Control.AM PLM Documents: PreconditionsDuring the analysis phase of the archiving process, no standard business checks are performed.You can use the Business Add-In (BAdI) Archivability of PLM Document for further checks.AM PLM Documents: Display Archived DataYou can find the Display Archived PLM Documents report from the SAP Easy Access screen by choosingFinancial Services  Account Management  Archiving  Data Display  BVW_PLMDOC - PLMDocuments (Archiving Object PLMDOC).AM PLM Documents: TablesThe tables for AM PLM documents are:Table name DescriptionBCA_DEH_DOC_ACCP PLM Account Posting LocksBCA_DEH_DOC_ACFT PLM Feature Locks on AccountBCA_DEH_DOC_ACTT PLM Account - Posting Locks from Event Type (BP only)© 2011 SAP AG page 73/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0Table name DescriptionBCA_DEH_DOC_CARD PLM Card LocksBCA_DEH_DOC_CDFT PLM Cards with Feature LocksBCA_DEH_DOC_CNFT PLM Feature Locks in ContractBCA_DEH_DOC_COID PLM Customer-Specific MessagesBCA_DEH_DOC_CTYP PLM Card TypesBCA_DEH_DOC_FEE PLM Differentiation Values for Condition DeterminationBCA_DEH_DOC_HEAD PLM Document HeaderBCA_DEH_DOC_NOTE PLM NotesBCA_DEH_DOC_PFRM PLM Payment Form Position IntervalsBCA_DEH_DOC_PICA PLM: Payment Items Posted for Card ChargesBCA_DEH_DOC_PITM PLM: Payment Items Posted for PLM Document ChargesBCA_DEH_DOC_PNET PLM Prenote Types from Event Type (BP only)BCA_DEH_DOC_PREN PLM PrenotesBCA_REL_LOG_D Detail Data of Log Table for ReleaseBCA_REL_LOG_H Header Data of Log Table for ReleaseCDCLS Cluster structure for change documentsCDHDR Change document headerCDPOS_STR Additional Change Document - Table for STRINGsCDPOS_UID Additional Table for Inclusion of TABKEY>70 CharactersAM PLM Documents: TAANA Ad Hoc VariantThe following table and fields can be used to analyze the yearly and monthly distribution of PLM documents:BCA_DEH_DOC_HEAD Z_SCHED_ACTIV_TO_YEAR Z_SCHED_ACTIV_TO_MONTH© 2011 SAP AG page 74/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.05.20 AM Posting NotificationsAM Posting Notifications: DescriptionPosting notifications are additional correspondences in the form of an SMS or e-mail or an event-controlledbank statement.Posting notifications are generated when certain postings are made to an account (items or prenotes) orwhen a certain account balance is reached.AM Posting Notifications: Archiving Object and ConfigurationThe archiving object for posting notifications is PNS_ALT. Posting notifications can only be archived with theArchiving Engine.I. Definition of residence timesIn the IMG activity Define Residence Time for Posting Notifications, you define the period of time after whichposting notifications are archived in the operational system.II. ActivitiesYou must always specify the bank posting area and the residence time. Ensure that you enter at least theresidence time for each bank posting area.The residence time must be at least 30 days long. The residence time for posting notifications is based on thechange or creation date of the posting notification.You can use the Product attribute to make even more specific settings for the residence time.The system determines the residence time of a posting notification by checking whether the attributes of thenotification match the entries made in the IMG activity. The system checks from the best possible match (allattributes match) to the worst possible match (only the bank posting areas match) in the following order: 1. Bank posting area, product 2. Bank posting areaIII. NotesThe residence time refers to calendar days, and not to posting days or workdays. The details are convertedinternally into days: o Year → 365 days o Month → 30 days o Week → 7 daysThe residence time you enter must meet the prerequisites below: It must be later than—or the same as—the minimum residence time set in IMG activity Maintain Global Archiving Control with Archiving Engine.If you do not make an entry in this IMG activity, the standard residence time applies. This is the residencetime you defined for posting notifications in Customizing for Account Management (FS-AM) under Archiving Maintain Global Archiving Control with Archiving Engine.© 2011 SAP AG page 75/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0The residence time depends on a product. Therefore, if you have different residence times for differentproducts (and a product change), the following situation may arise.Different residence times for different products (and a product change): If you initially use a product to define the residence time, and then enter another product and execute a product change during the current productive operations, the system uses the residence time of the product that is currently valid as a basis for the archiving object data records created in the operational system after the product change. If the residence time of the old product was longer than that of the new product, the data records that were created after the product change are archived before the data records created before the product change. This may mean that older data records are still in the operational system even though newer ones are already in the archive.AM Posting Notifications: PreconditionsBusiness checks are performed during the analysis phase of the archiving process. The followingrequirements must be met for posting notifications preconditions to enable the subsequent archiving:  The notification must have the status Created or Deactivated.If the above condition is not fulfilled, the rejection reason is set: o 99 Inconsistent dataAM Posting Notifications: Display Archived DataYou can find the Display Archived Posting Notifications report from the SAP Easy Access screen bychoosing Financial Services  Account Management Archiving  Data Display  BVW_PNS_ALT - PostingNotifications (Archiving Object PNS_ALT).AM Posting Notifications: TablesThe tables for AM posting notifications are:Table name DescriptionBCA_NOTIFICAT_AL Posting NotificationAM Posting Notifications: TAANA Ad Hoc VariantThe following table and fields can be used to analyze the yearly and monthly distribution of postingnotifications:BCA_NOTIFICAT_AL Z_TIMESTAMP_CHANGED_YEAR Z_TIMESTAMP_CHANGED_MONTH© 2011 SAP AG page 76/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.05.21 AM Posting Notification RulesAM Posting Notification Rules: DescriptionPosting notification rules are the settings for an account that control the criteria for posting notifications.A posting notification rule contains details about the validity period and amount of the posting in question.AM Posting Notification Rules: Archiving Object and ConfigurationThe archiving object for posting notification rules is PNS_MD. Posting notification rules can only be archivedwith the Archiving Engine.I. Definition of residence timesIn the IMG activity Define Residence Time for Posting Notification Rules, you define the period of time afterwhich posting notification rules are archived in the operational system.II. ActivitiesYou must always specify the bank posting area and the residence time. Ensure that you enter at least theresidence time for each bank posting area.The residence time must be at least 30 days long. The residence time for posting notification rules is basedon the change or creation date of the posting notification rule.You can use the Product attribute to make even more specific settings for the residence time.The system determines the residence time of a posting notification rule by checking whether the attributes ofthe rule match the entries made in the IMG activity. The system checks from the best possible match (allattributes match) to the worst possible match (only the bank posting areas match) in the following order: 1. Bank posting area, product 2. Bank posting areaIII. NotesThe residence time refers to calendar days and not to posting days or workdays. The details are convertedinternally into days: o Year → 365 days o Month → 30 days o Week → 7 daysThe residence time you enter must meet the prerequisites below: It must be later than—or the same as—the minimum residence time set in IMG activity Maintain Global Archiving Control with Archiving Engine.If you do not make an entry in this IMG activity, the standard residence time applies. This is the residencetime you defined for posting notification rules in Customizing for Account Management (FS-AM) underArchiving  Maintain Global Archiving Control with Archiving Engine.The residence time depends on a product. Therefore, if you have different residence times for differentproducts (and a product change), the following situation may arise:© 2011 SAP AG page 77/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0Different residence times for different products (and a product change):If you initially use a product to define the residence time, and then enter another product and execute aproduct change during the current productive operations, the system uses the residence time of the productthat is currently valid as a basis for the archiving object data records created in the operational system afterthe product change.If the residence time of the old product was longer than that of the new product, the data records that werecreated after the product change are archived before the data records created before the product change.This may mean that older data records are still in the operational system even though newer ones arealready in the archive.AM Posting Notification Rules: PreconditionsBusiness checks are performed during the analysis phase of the archiving process. The followingrequirements must be met for posting notification rules to enable the subsequent archiving:  The corresponding posting notifications must have been archived.  The notification rule must have the status Created or Deactivated.If the above condition is not fulfilled, the rejection reason is set: o 01 Corresponding posting notifications not yet archived o 02 Posting notification rule activeAM Posting Notification Rules: Display Archived DataYou can find the Display Archived Posting Notification Rules report from the SAP Easy Access screen bychoosing Financial Services  Account Management  Archiving  Data Display  BVW_PNS_MD -Posting Notification Rules (Archiving Object PNS_MD).AM Posting Notification Rules: TablesThe tables for AM posting notification rules are:Table name DescriptionBCA_NOTIFICAT Posting Notification RulesCDCLS Cluster structure for change documentsCDHDR Change document headerCDPOS_STR Additional Change Document - Table for STRINGsCDPOS_UID Additional Table for Inclusion of TABKEY>70 CharactersAM Posting Notification Rules: TAANA Ad Hoc VariantThe following table and fields can be used to analyze the yearly and monthly distribution of postingnotification rules:BCA_NOTIFICAT Z_TIMESTAMP_CHANGED_YEAR Z_TIMESTAMP_CHANGED_MONTH© 2011 SAP AG page 78/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.05.22 AM Business PrenotesAM Business Prenotes: DescriptionAn FS-AM business prenote represents a cash reservation for a future turnover (for a debit resulting from useof a card, for example).You can create prenotes both for credit and debit postings. Amount, posting date, and payment method areopen. When there is a posting for a prenote, the system finds and cancels the prenote via a reference (knownas ―matching‖). Otherwise, the prenote is deleted after a certain time.Prenotes affect neither the account balance nor the posting-date-based or value-date-based balance.Depending on the transaction type, however, prenotes can be labeled as relevant for posting control and arethen included in the calculation of the available amount.AM Business Prenotes: Archiving Object and ConfigurationThe archiving object for AM business prenotes is PRENOTE_B.I. Definition of residence timesIn the IMG activity Define Residence Time for Prenotes (PRENOTE_B Object), you specify the period of timefor which the business prenotes are to be managed in the operational dataset before being archived(PRENOTE_B - business prenotes) or physically deleted from the database (PRENOTE_T - technicalprenotes).II. ActivitiesDefine the residence time at least for each bank posting area.You can use the prenote type and product attributes to differentiate between your residence time settings ingreater detail.The system determines the residence time for a technical prenote by checking whether its attributescorrespond to the details specified in the IMG activity. During this process, the system checks all possiblematches from the best (all attributes match) to the worst (only the bank posting area matches) in the followingsequence: 1. Bank posting area, prenote type, product 2. Bank posting area, prenote type 3. Bank posting area, product 4. Bank posting areaIII. NotesThe residence time you enter must meet the prerequisites below: The residence time must be longer than—or the same as—the minimum residence time defined in IMG activity Maintain Global Archiving Control. If you do not create a generic entry, the standard residence time applies. This is the residence time you defined for prenotes in the Customizing for Account Management (FS-AM) under Archiving  Maintain Global Archiving Control.© 2011 SAP AG page 79/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0 If you set the Archive indicator in the Customizing for Account Management (FS-AM) under Item Management  Prenotes  Define Prenote Types, the prenotes are archived for the relevant prenote type. If you do not set the indicator, the prenotes are deleted. The residence time is dependent on a product. Therefore, if you have different residence times for different products (and a product change), the following situations may arise: o If you initially use a product to define the residence time, and then enter another product and execute a product change during the current productive operations, the system uses the residence time of the product that is currently valid as a basis for archiving object data records created in the operational system after the product change. o If the residence time of the old product was longer than that of the new product, the data records that were created after the product change are archived before the data records created before the product change took place. This may mean that older data records are still in the operational system even though newer ones are already in the archive.AM Business Prenotes: PreconditionsBusiness checks are performed during the analysis phase of the archiving process. The followingrequirements must be met for a prenote to enable the subsequent archiving:  The status of the prenote must be Created, Assigned, Deleted, or Reversed.  The residence time must have expired. Depending on the status of the prenote, the residence time is based on the following data: Status Residence Time Based On 01 Created Valid-To Date of the Prenote 08 Assigned Valid-To Date of the Prenote 09 Deleted Expiration Date of the Prenote 10 Reversed Expiration Date of the Prenote  There may be no record for the prenote that is in the release process.AM Business Prenotes: Display Archived DataYou can find the Display Archived Prenotes report from the SAP Easy Access screen by choosing FinancialServices  Account Management  Archiving  Data Display 00 BVW_PRENOTE_B - Business-RelatedPrenotes (Archiving Object PRENOTE_B).AM Business Prenotes: TablesThe tables for AM prenotes are:Table name DescriptionBCA_PRENOTE DB Tables - PrenotesBCA_REL_LOG_D Detail Data of Log Table for ReleaseBCA_REL_LOG_H Header Data of Log Table for ReleaseCDCLS Cluster structure for change documentsCDHDR Change document header© 2011 SAP AG page 80/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0Table name DescriptionCDPOS_STR Additional Change Document - Table for STRINGsCDPOS_UID Additional Table for Inclusion of TABKEY>70 CharactersAM Business Prenotes: TAANA Ad Hoc VariantThe following table and fields can be used to analyze the yearly and monthly distribution of prenotes:BCA_PRENOTE Z_DATE_CRT_YEAR Z_DATE_CRT_MONTH© 2011 SAP AG page 81/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.05.23 AM Reconciliation Documents for Payment ItemsAM Reconciliation Documents for Payment Items: DescriptionReconciliation documents for payment items are a standard service for applications that post turnovers, butdo not themselves save any documents. The saved documents are used for reconciliation.Reconciliation documents for payment items are written when direct charges or trivial amounts are posted inthe context of account closure.AM Reconciliation Documents for Payment Items: Archiving Object and ConfigurationThe archiving object for reconciliation documents for payment items is RECONC_PI. Reconciliationdocuments for payment items can only be archived with Archiving Engine.I. Definition of residence timesIn the IMG activity Define Residence Time for Reconciliation documents for payment items, you define theperiod of time after which reconciliation documents for payment items are archived in the operational system.II. ActivitiesYou must always specify the bank posting area and the residence time. Ensure that you enter at least theresidence time for each bank posting area.The residence time must be at least 30 days long. This residence time needs to match the residence time fordeletion of the reconciliation data, which is defined in the IMG activity Maintain Global Archiving Control forthe Deletion Object RECONC.The system determines the residence time of a posting notification by checking whether the attributes of thenotification match the entries made in the IMG activity. The system checks from the best possible match (allattributes match) to the worst possible match (only the bank posting areas match) in the following order: 1. Bank posting area, product 2. Bank posting areaIII. NotesThe residence time refers to calendar days, and not to posting days or workdays. The details are convertedinternally into days: o Year → 365 days o Month → 30 days o Week → 7 daysThe residence time you enter must meet the prerequisites below: It must be later than—or the same as—the minimum residence time set in IMG activity Maintain Global Archiving Control with Archiving Engine.If you do not make an entry in this IMG activity, the standard residence time applies. This is the residencetime you defined for reconciliation documents for payment items in Customizing for Account Management(FS-AM) under Archiving  Maintain Global Archiving Control with Archiving Engine.© 2011 SAP AG page 82/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0The residence time depends on a product. Therefore, if you have different residence times for differentproducts (and a product change), the following situation may arise:Different residence times for different products (and a product change):If you initially use a product to define the residence time, and then enter another product and execute aproduct change during the current productive operations, the system uses the residence time of the productthat is currently valid as a basis for the archiving object data records created in the operational system afterthe product change.If the residence time of the old product was longer than that of the new product, the data records that werecreated after the product change are archived before the data records created before the product change.This may mean that older data records are still in the operational system even though newer ones arealready in the archive.AM Reconciliation Documents for Payment Items: PreconditionsReconciliation documents for payment items may only be archived if the reconciliation was completed withouterror. This must be ensured by organizational measurements and will not be checked by the businesschecks.Business checks are performed during the analysis phase of the archiving process. The followingrequirements must be met for a reconciliation document to enable the subsequent archiving:  There are no reconciliation totals for the posting day in table BCA_RCN_SUMS_OUT.If the above condition is not fulfilled, the rejection reason is set: o 01 Reconciliation totals not deleted (RECONC).If the system detected a status for the reconciliation document that makes further processing in the context ofarchiving impossible, the following rejection reason is set: o 99 Inconsistent dataAM Reconciliation Documents for Payment Items: Display ArchivedDataAs the expected data volume for reconciliation documents for payment items is rather small, no businessview is implemented for the archived data. The archived data can be displayed with the technical view usingtransaction SARI.AM Reconciliation Documents for Payment Items: TablesThe tables for AM reconciliation documents for payment items are:Table name DescriptionBCA_RCN_DOC AM Reconciliation: Documents© 2011 SAP AG page 83/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0AM Reconciliation Documents for Payment Items: TAANA Ad Hoc VariantThe following table and fields can be used to analyze the yearly and monthly distribution of reconciliationdocuments for payment items:BCA_RCN_DOC Z_DATE_POST_YEAR Z_DATE_POST_MONTH© 2011 SAP AG page 84/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.05.24 AM Release LogsAM Release Logs: DescriptionA release log or release object is an object derived from the general release object of the Framework for thePrinciple of Dual Control (CA-GTF-TS-PDC) for an application object that can run through the releaseworkflow.The general release object is the business object of the Framework for the Principle of Dual Control (CA-GTF-TS-PDC) for defining the workflow template. It contains the category and key of the application objectand a generally defined structure via which the release attributes of the application object can be transferredto the release workflow.AM Release Logs: Archiving Object and ConfigurationThe archiving object for release logs is RELEASELOG.I. Definition of residence timesIn the IMG activity Define Residence Time and for Release Logs, you define the period of time after whichrelease logs are archived in the operational system. In the Account Management system, you can define dataentries that are subject to special release rules. The current and historical statuses of the releases are savedin the release log.II. ActivitiesYou can define the residence times for the RELEASELOG object for each release object. Always specify therelease object and residence time.The base for the residence time of the release data is the earliest change date in the release log.The release data is normally archived together with the object that you want to release. This applies to bothmaster data and flow data, but is non-critical for the latter, as it can be archived relatively quickly.In the case of the master data, however, there may be a marked increase in memory space for the releasedata.The RELEASELOG archiving object is used to reduce the memory space required for the release data, evenif the object you want to release cannot be archived. You can use the RELEASELOG archiving object for thispurpose, but it is not strictly necessary.If you use the RELEASELOG archiving object, this may cause the release data for a release object to bestored in the archive files of several different archiving objects. If you use the CONTRACT archiving object(for example, AM_ACCOUNT) as well, for example, the release log for the contract may be partly archived inthe RELEASELOG archiving object and partly in the CONTRACT archiving object.The amount of memory space required for the archive information structure is then large in comparison tothat required for the operational data. You should therefore not archive the RELEASELOG archiving objecttoo frequently.© 2011 SAP AG page 85/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0III. NotesThe residence time you enter must meet the prerequisites below: It must be longer than—or the same as—the minimum residence time set in IMG activity Maintain Global Archiving Control.If you do not make an entry in this IMG activity, the standard residence time applies. This is the residencetime you defined for release logs in Customizing for Account Management (FS-AM) under Archiving Maintain Global Archiving Control.AM Release Logs: PreconditionsNo standard business checks are performed during the analysis phase of the archiving process.AM Release Logs: Display Archived DataNo business view available to display the archived release logs. You can display them via transaction SARI,using the GUID of the object you want to display.AM Release Logs: TablesThe tables for AM release logs are:Table name DescriptionBCA_REL_LOG_H Header Data of Log Table for ReleaseBCA_REL_LOG_D Detail Data of Log Table for ReleaseAM Release Logs: TAANA Ad Hoc VariantThe following table and fields can be used to analyze the yearly and monthly distribution of release logs:BCA_REL_LOG_D Z_CHANGED_AT_YEAR Z_CHANGED_AT_MONTH© 2011 SAP AG page 86/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.05.25 AM Settlement ResultsAM Settlement Results: DescriptionDuring the interest and charge settlement runs, the settlement results (for example, debit or credit interest orcharges) are calculated using diverse factors such as conditions, periods, or balances. These are thendebited or credited to an account of the bank customer.AM Settlement Results: Archiving Object and ConfigurationThe archiving object for settlement results is SETTLEMENT.I. Definition of residence timesIn the IMG activity Define Residence Time for Settlements (object SETTLEMENT), you define the period oftime after which settlements can be archived in the operational system.II. ActivitiesEnsure that you enter at least the residence time for each bank posting area.The end date of the settlement period is used as the basis for determining the residence time. This ischecked against the posting date for end-of-day processing.You can use the settlement type, product category, and product attributes to differentiate between yourresidence time settings in greater detail.The system determines the residence time of a settlement by checking whether its attributes correspond tothe details specified in the IMG activity. During this process, the system checks all possible matches from themost (all attributes match) to the least (only the bank posting area matches) in the following sequence: 1. Bank posting area, settlement type, product category and product 2. Bank posting area, settlement type 3. Bank posting area, product category and product 4. Bank posting areaThe product category and external product ID of the product form a unit and must always be enteredtogether.III. NotesThe residence time you enter must meet the prerequisites below:  It must be later than—or the same as—the earliest residence time set in IMG activity Maintain Global Control of Archiving.  Settlement data is required in the RBCA_RCN_SUMS_OUT report for reconciliation purposes. This must be taken into consideration when defining the residence time.  The residence time for the settlement also affects the turnover classes that are not relevant for settlement. The residence time for the turnover classes that are not relevant for settlement cannot be earlier than the residence time determined for the settlement. This is because a deduction period is set for the settlement residence time, including for the turnover classes that are not relevant for© 2011 SAP AG page 87/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0 settlement. This must be taken into consideration when defining the residence time. (Refer to IMG activity Define Residence Time for Transaction Figures [FIGURES object]).  The settlement period of a product can be shorter than the settlement period of an account belonging to the product. Example: Product ABC is settled every 3 months. The residence time is 6 months. However, individual accounts are settled every 6 or 12 months. For these accounts, only the last settlement is stored in the operational system.  The bank statements are created by the correspondence tool. To this end, correspondence requests are created in AM. These contain the keys for the settlement data that is to be printed on the bank statement. The individual bank statements are then created in the correspondence print run. During the process, the settlement data is accessed using the keys contained in the correspondence request.  For performance reasons during data archiving, the system only checks if the settlement data from all bank statement agreements is contained in the correspondence requests. It does not check if the correspondence request has actually printed.  There may be a gap between the creating of the correspondence request and the correspondence print. This may mean that settlement data, which is required for the correspondence print, has already been archived. If this is the case, the settlement data is read from the archive during the correspondence print, which leads to poor performance.Therefore, the residence time for the settlements must be later than the maximum statement period used innormal cases.The last settlement of each settlement type is not archived for the active accounts because it is required as abasis for the following settlement.If you do not make an entry in this IMG activity, the standard residence time applies. This is the residencetime you defined for settlements in the Customizing for Account Management (FS-AM) under Archiving Maintain Global Control of Archiving.If you want to check whether the Customizing settings are complete, you can use a report from theCustomizing for Account Management (FS-AM) by choosing Archiving  Check Archiving CustomizingWarning.Do not change the residence time for settlement during settlement archiving or during settlement.AM Settlement Results: PreconditionsBusiness checks are performed during the analysis phase of the archiving process. Settlement data mustmeet the following conditions before it can be archived: The residence time for the settlement must have expired. To calculate the residence time, the program refers to the end date and time of the period (time stamp) for the settlement. Account settlement data: o The contract status of the account that forms the basis for the calculation must be one of the following: Active, in use: Settlement data for accounts with this contract status, and the existing settlement type, acquires the archiving status can be archived only if the data is not drawn from the most recently performed© 2011 SAP AG page 88/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0 settlement. This includes any adjustments that may have been made (previous period adjustment, reversal) for the last settlement. Deleted: Settlement data for accounts with this status acquires the archiving status can be archived only if the reactivation period for the contract status has already expired. o A previous period adjustment is not necessary for the subsequent settlement. The function module checks this using the existing transaction figures. If transaction figures exist for the account with a posting date that is later than the latest available end date and time included in the posting (time stamp), and with a value date that is before—or the same as—the end date and time of the period (time stamp) (following period) of the settlement to be checked, you cannot archive the settlement. o There must be no gaps between the archived settlement data. Example: Account with monthly settlement The settlement data for January 2001 has already been archived. The settlement data for February 2001 cannot be archived. The settlement data for March 2001 has the status cannot be archived for as long as the settlement data for February continues to have the status cannot be archived. o With checking accounts, all the settlement data must already have appeared on a bank statement for a bank statement agreement. o With fixed-term deposit accounts, the term of the transaction that triggers the settlement must already have expired. o The system cannot archive settlement data that still requires billing. The system checks if the start dates for the billing dates (start of the current billing period [table BCA_BL_SCHED, field DATE_FROM]) and the billing history (start of the current billing period [table BCA_BL_SCHED_H, field DATE_FROM]) are before the following end dates for the settlement: - End Date and Time of Period (Time Stamp) (table BCA92, field END_TMSTP) - End Date and Time of Interest Calculation (Time Stamp) (table BCA92, field END_TMSTP_I) - Latest posting date for the period (table BCA92, field END_TMSTP_P) If the start date for billing is before the three end dates of the settlement, the system cannot archive the settlement data. The settlement requires the data from the previous settlement to determine which condition was already taken into account. Therefore, the system does not also archive the previous settlement. o Because the combined settlement with the compensation (interest and charges) feature requires the settlement results for the participant accounts, the system cannot archive these. The system checks whether the accounts belong to the combined settlement with the compensation feature. Accounts that have a condition type bundle assigned to them belong to the combined settlement with the compensation feature. Not all master contracts in combined settlement with the compensation feature need the settlement results of the participant accounts. If you set the indicator in the Do Not Request Account Settlement check box in the Customizing activity Assign Condition Types to Condition Type Bundle for the© 2011 SAP AG page 89/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0 corresponding condition type bundle, the system can then archive the settlement results for the participant accounts. If you do not set the indicator, the system cannot archive the settlement results for the participant accounts (see Customizing activity Assign Condition Types to Condition Type Bundles). Card and card pool settlement data: o The card status of the card(s) that form(s) the basis for the calculation must be one of the following : Active: Settlement data for cards with this contract status, and the existing settlement type, acquires the archiving status can be archived only if the data is not drawn from the most recently performed settlement. This includes any adjustment postings that may have been made for the last settlement. Expired: Settlement data for cards with this contract status is always given the archiving status can be archived.  You can use the BTE EV0BCA4300 to perform additional checks.AM Settlement Results: Display of Archived DataYou can find the DISPLAY ARCHIVED SETTLEMENTS report from the SAP Easy Access screen bychoosing Financial Services  Account Management  Archiving  Data Display BCA_AR_SETTLE_BVW.AM Settlement Results: TablesThe tables for AM settlements are:Table name DescriptionBCA_CARRY_FORW Carryforward From Condition Type OffsetBCA_IDAY_BALANCE Table of Intraday BalancesBCA92 Account Settlement (Interest and Charges)BCA92_RESTART Restart InformationBCA96 Account Settlement Detail DataBKK92_POSTINGS Documentation of Settlement PostingsBKK92_SUMS Totaled Amounts of a Settlement (Interest and Charges)AM Settlement Results: TAANA Ad Hoc VariantThe following table and fields can be used to analyze the yearly and monthly distribution of settlements:BCA92 Z_END_TMSTP_YEAR Z_END_TMSTP_MONTH© 2011 SAP AG page 90/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.05.26 AM Standing OrdersAM Standing Orders: DescriptionAM standing orders depict a periodically generated payment order credited to or debited from one or morerecipient accounts. Standing orders with one recipient item are called single or individual standing orders;those with multiple order recipient items are called collective standing orders. We can differentiate betweenfixed standing orders, which have a constant amount, and variable standing orders, which have a variableamount. In Account Management, the standing order is a feature of the account. Standing orders aremanaged for each account on a time-dependent basis. The transaction type forms the basis of a standingorder. You define transaction types in the Customizing for Account Management.AM Standing Orders: Archiving ObjectThe archiving object for AM Standing orders is STANDORDER.I. Definition of residence timesIn the IMG activity Define Residence Time for Standing Order (Object STANDORDER), you define the periodof time after which standing orders can be archived in the operational system.II. ActivitiesDefine the residence time for each bank posting area. You can use the transaction type and productattributes to differentiate between your residence time settings in greater detail.The system determines the residence time of a standing order by checking whether its attributes correspondto the details specified in the IMG activity. During this process, the system checks all possible matches fromthe best (all attributes match) to the worst (only the bank posting area matches) in the following sequence: 1. Bank posting area, transaction type, product 2. Bank posting area, transaction type 3. Bank posting area, product 4. Bank posting areaIII. NotesThe residence time you enter must meet the prerequisites below: The residence time must be longer than—or the same as—the minimum residence time defined in IMG activity Maintain Global Archiving Control. If you do not make an entry in this IMG activity, the standard residence time defined in Maintain Global Archiving Control applies. The residence time depends on a product. Therefore, if you have different residence times for different products (and a product change), the following situations may arise: o If you initially use a product to define the residence time, and then enter another product and execute a product change during the current productive operations, the system uses the residence time of the© 2011 SAP AG page 91/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0 product that is currently valid as a basis for the archiving object data records created in the operational system after the product change. o If the residence time of the old product was longer than that of the new product, the data records that were created after the product change are archived before the data records created before the product change. This may mean that older data records are still in the operational system even though newer ones are already in the archive.AM Standing Orders: PreconditionsBusiness checks are performed during the analysis phase of the archiving process. The followingprerequisites must be fulfilled before a standing order can be archived: One of the standing order versions (depending on the start of the validity period of the standing order) must have one of the following statuses o 02 Deleted o 05 Rejected The residence time for the standing order must be past. The residence time is calculated based on the date on which the last change was made. All the payment orders that belong to the standing order must be archived. The standing order with the highest number in an account can only be archived if the account has been deleted and can no longer be activated, because the standing order with the highest number is required for use in assigning standing order numbers.Note: The BAdI Standing Order Archiving is available as a customer enhancement for this check module.AM Standing Orders: Display Archived DataYou can find the Display Archived Standing orders report from the SAP Easy Access screen by choosingFinancial Services  Account Management  Archiving  Data Display  BVW_STANDORDER - StandingOrders (Archiving Object STANDORDER).AM Standing Orders: TablesThe tables for AM standing orders are:Table name DescriptionADR* 23 Address TablesBCA_REL_LOG_D Detail Data of Log Table for ReleaseBCA_REL_LOG_H Header Data of Log Table for ReleaseBCA_SO_PRC_CHG Logging for No Charges and No Correspondence (One-Off)BKK_SO_PRC_CHG Logging for No Charges and No Correspondence (One-Off)© 2011 SAP AG page 92/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0Table name DescriptionBCASO_PAORN AM: Payment Orders of a Standing OrderBKKSOHD Standing Order Header DataBKKSOIT Recipient Item for Standing OrderBKKSOIT_VAR_AMNT Standing Order: Variable Amounts (Version Incl. Collect.SOs)BKKSOITNT Payment Notes of Standing OrdersCDCLS Cluster structure for change documentsCDHDR Change document headerCDPOS_STR* Additional Change Document - Table for STRINGsCDPOS_UID Additional Table for Inclusion of TABKEY>70 CharactersAM Standing Orders: TAANA Ad Hoc VariantThe following table and fields can be used to analyze the yearly and monthly distribution of standing orders:BKKSOHD Z_VALID_TO_YEAR Z_VALID_TO_MONTH© 2011 SAP AG page 93/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.05.27 AM Withdrawal with SettlementAM Withdrawal with Settlement: DescriptionA withdrawal with settlement is an order that changes the calculation and posting of interest when awithdrawal is made from an account in the Account Management (FS-AM) system.The withdrawal with settlement is managed in the Account Management system as an order by OrderManagement.AM Withdrawal with Settlement: Archiving Object and ConfigurationThe archiving object for withdrawal with settlement is ORDER_WWS. It should be used with the ArchivingEngine.I. Definition of residence timesIn the IMG activity Define Residence Time for Withdrawal With Settlement, you define the period of time afterwhich withdrawals with settlement are archived in the operational system. This must be at least one day.II. ActivitiesYou must always specify the bank posting area and the residence time. Ensure that you enter at least theresidence time for each bank posting area.You can further differentiate your settings for the residence time with the product and order statusattributes. The product and order status are optional.The residence time and resubmission period consist of a period unit and a number of periods. The residencetime and the resubmission period refer to calendar days, not to posting days or working days. The residencetime must be at least one day. The basis for the residence time for withdrawal with settlement depends on theorder status: Order Status Base Date of Residence Time 0100 (Entered) If the order has been changed during its lifetime, the base date is the changed on date. If it has not changed, the base date is the created on date 0110 (Deleted) The base date is the changed on date 0150 (Executed) The base date is the latest date of withdrawal date and value date 0160 (Reversed) The base date is the changed on dateThe current product of the contract is used to determine the residence time.The system determines the residence time of a withdrawal with settlement by checking whether its attributescorrespond to the details specified in the IMG activity. The system checks from the most matches possible(all attributes match) down to the least matches possible (only the bank posting area matches) in thefollowing sequence: 1. Bank posting area, transaction type, product 2. Bank posting area, transaction type 3. Bank posting area, product 4. Bank posting area© 2011 SAP AG page 94/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0III. NotesIf you do not make an entry in this IMG activity, the standard residence time applies. This is the residencetime you defined for Account Holder Change in Customizing for Account Management (FS-AM) underArchiving  Maintain Global Archiving Control with Archiving Engine.The residence time you enter must be longer than—or the same as—the minimum residence time set in IMGactivity Maintain Global Archiving Control with Archiving Engine.AM Withdrawal with Settlement: PreconditionsNo business-related checks are made for this archiving object. For this reason, choose a residence time thatensures that all orders created for an account holder change are executed before the residence time expires.AM Withdrawal with Settlement: Display Archived DataYou can find the Display Archived Withdrawal With Settlement report from the SAP Easy Access screenby choosing Financial Services  Account Management  Archiving  Data Display BVW_ORDER_WWS - Withdrawals with Settlement (Archving Object ORDER_WWS).AM Withdrawal with Settlement: TablesThe tables for AM withdrawal with settlement are:Table name DescriptionBCA_OR_LINK Link Table: Assignment Order - ObjectsBCA_OR_WWS Order Withdrawal With SettlementBCA_ORDER Order (General Data)BCA_REL_LOG_D Detail Data of Log Table for ReleaseBCA_REL_LOG_H Header Data of Log Table for ReleaseCDCLS Cluster structure for change documentsCDHDR Change document headerCDPOS_STR Additional Change Document - Table for STRINGsCDPOS_UID Additional Table for Inclusion of TABKEY>70 CharactersAM Withdrawal with Settlement: TAANA Ad Hoc VariantThe following table and fields can be used to analyze the yearly and monthly distribution of withdrawal withsettlement with restriction to entries with order category (ORDER_CATG) = WWS:BCA_ORDER ORDER_CATG Z_LAST_UPDATE_TS_YEAR Z_LAST_UPDATE_TS_MONTH© 2011 SAP AG page 95/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.06 Archiving Engine in Account Management6.1 Archiving Engine: PurposeThe Archiving Engine is primarily intended for archiving large amounts of data. It manages the completeprocess chain for archiving, including monitoring.You can archive your data using parallel processing. You can preset the server group and the maximumnumber of simultaneously active work processes (tasks) that can be used for archiving in this server group.In the Archiving Monitor, you can follow how the Archiving Engine works between the master server and theclient servers. You can see which packages are formed on the master server and which archiving tasksprocess these packages on the client servers.Snapshots are saved as events. This means you can trace the history of the data volume and the results ofthe Archiving Engine.The Archiving Monitor displays an InfoCube showing when business objects are included in the archivingcheck in the future. Furthermore, the business-related rejection reasons can be displayed in a graphic.From this graphic, you can see which periods have a particularly large number of objects scheduled foranalysis. We recommend planning sufficient resources for archiving for these times.6.2 Archiving Engine: FeaturesThe Archiving Engine check only includes the business objects that are currently waiting to be checked.Business objects that cannot be archived are scheduled for the archiving check; that is, they are set toresubmission.The Dynamic Selections button allows you to restrict the data that will be selected by the Archiving Enginebased on attributes in the header table for the archiving object. You can also use these restrictions for a shortperiod, such as for observation in the Archiving Monitor.The analysis phase consists of two checks (security levels):  Residence time check  Business-related checkOnly business objects that pass both checks are flagged as archivable; the others are set to resubmission.The Archiving Engine creates equally sized data packages to achieve optimum server usage:  The smaller the package size you select, the higher the network load.  The maximum permitted package size is limited by the main memory of the server on which the Archiving Engine runs (master server).  The number of resulting archiving runs is restricted by the number of simultaneously active work processes (tasks) on the clients.  This results in archiving runs that have approximately the same number of business objects.These archiving runs can be deleted in parallel.© 2011 SAP AG page 96/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0Since the deletion phase is usually very time-consuming, you need to provide at least as many tasks as forthe write phase.If you do not specify a server group, the archiving tasks can potentially be divided between all availableapplication servers.You can specify default values for the Archiving Engine in the object-specific Customizing (choose the Object-Specific Customizing button). Take into account your technical resources. In this object-specific Customizing,you can also specify the functions and phases provided by the Archiving Engine. This enables you to adjustthe Archiving Engine to the requirements of the usage phase and its specific tasks.In Customizing, you can define residence intervals for the business objects to be archived specifically forarchiving, depending on specific attributes (Define Residence Time button).You can schedule the Archiving Engine as a background job (periodic) (Schedule in Background button).During the test, you can use the button to reset the status to the previous level.In dialog mode, you can use the Archiving Monitor to monitor the results of the Archiving Engine that isrunning in the background (Archiving Monitor button). You can use SAP business graphic program to displaythe sequence of archiving runs.If you use the Archiving Engine for a hybrid archiving object, you can use both the previous IMG activity,Maintain Global Archiving Control, and the new IMG activity, Maintain Global Control for Archiving Engine, inCustomizing.© 2011 SAP AG page 97/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.07 Deletion Reports and Objects for Account ManagementIn Account Management, several major deletion reports exist for application data. These reports should beexecuted on a regular basis to reduce maintenance efforts and to increase system performance.Deletion Reports/Transactions in Account Management Report/Transaction Description RFBDELSIM Deletion Report for SIM Tables of Settlement BCA_BAST_DATES_DEL Bank Statement Creation Dates BCA_CORR_DELETE Correspondence BCA_AR_GL_BLNCE_DEL FI Balances (Delete Object GL_BALANCE) BCA_AR_GL_BP_DEL Balance Sheet Preparation (Delete Object GL_BALPREP) BCA_AR_SNITEM_DEL Non-Balance Changing Postings (Delete Object SNITEM) BCA_AR_RECONC_DEL Reconciliation Data (Delete Object RECONC) BCA_AR_GL_SUMS_DEL FI Totals Records (Delete Object GL_SUMS) BCA_AR_INVENTORY_DEL Inventory Data (Delete Object INVENTORY) BCA_AR_PRENOTE_T_DEL Technical Prenotes (Delete Object PRENOTE_T)The deletion reports RFBDELSIM for settlement simulation data and accruals, BCA_BAST_DATES_DEL forbank statement creation dates, and BCA_CORR_DELETE for correspondences are described in section 7.1.The deletion objects of Account Management, which can be started from the SAP menu by choosingFinancial Services  Account Management  Archiving Data Deletion, are explained in sections 7.2 and7.3.© 2011 SAP AG page 98/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.07.1 AM Deletion ReportsAM Accruals and Settlement SimulationsDescriptionIn the Account Management (FS-AM) system, the accruals and settlement simulations are created whenexecuting the following applications:  Simulation of settlement by BAPI StartSingle  Accrual/deferral of settlement by BAPI StartSingle  Alternative settlement  Simulation in the past  Settlement without posting by BAPI StartSingle  Mass settlement in online mode using Save Simulation ResultsAs the data in the tables is not intended for archiving, use report RFBDELSIM to delete the data and to restrict theamount of data contained in the table.FeaturesThe report identifies the data to be deleted using selection criteria and deletes the data from the databasetables using a DELETE. You can define the number of records after which a commit is executed. By default,a commit is executed after 100 records are deleted from BKK92_SIM.SelectionThere are three selection options that can be used to identify the data to be deleted:  By technical run ID  By settlement type and period  By execution dateOutputThe output displays how many records are deleted from BKK92_SIM.TablesThe tables for AM settlement simulations are:Table name DescriptionBKK92_SIM Account Settlement - Simulation ResultsBKK92_SIM Totaled Amounts for Account Settlement-Simulation ResultsBKK96_SIM Account Settlement Detailed Data - Simulation Results© 2011 SAP AG page 99/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0Age of RecordsThe following table and fields can be used to analyze the yearly and monthly distribution of settlementsimulations: BKK92_SIM Z_START_TMSTP_YEAR Z_START_TMSTP_MONTH* The virtual fields Z_START_TMSTP_YEAR and Z_START_TMSTP_MONTH are available in transactionTAANA after you implement the latest version of the solutions tools plug-in ST-A/PI.© 2011 SAP AG page 100/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0AM Bank Statement Creation DatesDescriptionIn the Account Management (FS-AM) system, the generation dates for bank statements are created with thebank statements.As the data in the tables is not intended for archiving, use report RBCA_BAST_EVT_DELETE_PROCESSED todelete the data and to restrict the amount of data contained in the table. The report is available in the SAP menu:Financial Services  Account Management  Archiving  Data Deletion  BCA_BAST_DATES_DEL -Bank Statement Creation Dates.FeaturesThe report identifies the data to be deleted by using the selection criterion Residence time, which is enteredin the selection screen. It deletes all generation dates for bank statements (events) that meet the followingrequirements:  They have status Processed or Deleted.  The residence time that you entered on the selection screen of this report has expired.SelectionYou can set a simulation flag in the selection screen to identify the data to be deleted.OutputThe output displays how many records are deleted.AM CorrespondencesDescriptionCorrespondences serve a wide range of communication purposes, including:  Sending information (for example, notification of condition changes)  Documenting business processes based on agreements between customer and bank (for example, notification of creation of a standing order or confirmation of notice)Correspondence created in Account Management focuses on standardized mass correspondence, initializedfrom transactions. Correspondences are generated in single and mass runs. Correspondence can be sent tothe recipient using various media (for example, by letter, e-mail, or fax).FeaturesCorrespondences can be archived as described in section 5.3. It is possible to start the deletion reportwithout archiving. From the SAP menu, choose Financial Services  Account Management  Archiving Data Deletion  BCA_CORR_DELETE – Correspondence.You can find more information in section 5.3.© 2011 SAP AG page 101/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.07.2 Deletion ObjectsIn Account Management, the data deletion described in section 7.3 uses the framework of archiveadministration, as well as the Framework for Parallel Processing. This means that deletion objects are used.The common features of deletion objects are discussed in this section, while application-specific configurationis described in detail in section 7.3.PrerequisitesBecause deletion objects use the archive administration framework, you define residence times similar to theresidence times of archiving objects. You can maintain the default residence times, resubmission period, andsettings for the parallel processing in the IMG activity Maintain Global Archiving Control. If a residence timecannot be determined for a particular business object, the residence time defined here is used instead. Youcan use report RBCA_ARCHIVING_CUST_CHECK to check the Customizing settings.To improve performance, the delete program uses parallel processing, meaning that several jobs are startedin parallel. During program runtime, the system generates an application log containing statistical data andwrites the current status in an activity log. You can display this information using the Archiving Monitor.The IMG activity Job Distribution for Parallel Processing must be maintained.FeaturesThe deletion program finds out which data can be deleted. This process consists of several different steps,some of which run in parallel. i. Preparation: Here, the global and object-specific Customizing settings are imported, the authorization check for the archiving process performed, and the application and activity logs initialized. ii. Check residence time: Before parallel processing starts, the system checks the residence time for all business objects that the application transferred. If the residence time has not yet elapsed, these entries are flagged as not being for deletion, and are therefore not relevant for continued processing. iii. Generate package templates: In global Customizing, you specify the internal program analysis mode, which means that packages are always created dynamically during runtime with a package number defined in Customizing. A predefined profile is not allowed here. iv. Analysis/delete mass run: The mass run is executed in parallel, meaning that the maximum number of package administrators defined in the Customizing settings are started as parallel jobs. The package administrators take the generated package templates from the worklist and process them. The package administrator imports all the data records and deletes them from the operational database. v. Completion: The completion is the point at which parallel processing is synchronized. Once all the parallel processes have been completed, the application and activity logs are completed as well.© 2011 SAP AG page 102/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0SelectionThe analysis/delete program does not contain any selection parameters and, therefore, never has anyvariants. There is only one global control option, namely the archiving mode entry. You can set this in theglobal archiving control.The archiving mode has the following characteristic values:  Productive mode: The parallel package administrators are started as jobs in the background. The data is deleted from the database.  Simulation mode: The parallel package administrators are started as jobs in the background. The data is not deleted from the database.  Test mode: The package administrators are started in dialog processing and therefore run sequentially rather than in parallel. The data is not deleted from the database. This mode is useful for testing and tracking the analysis/delete program.OutputThe analysis/delete program generates an application log and an activity log in which statistical data and thestatus of the program run are entered during the process. You can view both logs using the archiving monitor.Organizational measuresThe following section 7.3 describes the necessary activities to delete the application data after it is no longerneeded in the system. The residence time for each object has to be agreed with the user departmentbeforehand. This is even more important for the objects described in 7.3 as the system will not create anyarchive files. Instead, Account Management provides two print reports to create a list of the balancepreparation data, the non-balance-changing posting data, and the inventory data. The system will check if theprint jobs were executed before deleting the data, but it will not check if the print lists themselves wereactually archived.Deletion potentialTo determine the amount of data that has expired the residence time, you can use the Data VolumeManagement work center in SAP Solution Manager. Here you can define a detailed analysis for the businessobjects to determine the deletion potential. The detailed analysis is based on the execution of transactionTAANA in your banking services system. The following sections show the table and the corresponding fieldsthat should be analyzed with transaction TAANA for each business object.A detailed description of the Data Volume Management work center is available in the SAP Online Help forSolution Manager 7.1, Solution Manager  Technical Operations  Data Volume Management.© 2011 SAP AG page 103/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.07.3 AM GL Interface DataAM GL Interface Data: DescriptionDuring the general ledger transfer, the items posted on the accounts in Account Management (FS-AM) aretransferred to the corresponding accounts in the general ledger (FI-GL).The following data and details are included:  The accumulation of the line items entered in Account Management on the checking accounts and the posting of these totals on the G/L accounts in FI  Calculation of the corresponding reconciliation totals and a follow-up balance check  Distribution of the flow totals of the transferred current accounts to receivable or payable accounts, depending on the account balance +/- sign  Net of associated current accounts on the balance sheetAdditionally, accruals/deferrals for interest and charges can be calculated at any time for balance sheetpurposes. The deletion of accruals data is described in section 7.2.AM GL Interface Deletion ObjectsPre-stepSome information about GL interface data (balance preparation, non-balance changing postings, andinventory data) can be printed before deleting the corresponding data. The print lists can be archivedafterwards.ConfigurationYou can specify that the data of the general ledger transfer is deleted from the database after a certain periodof time has elapsed.You define this period of time for each bank posting area in the Customizing for Account Management (FS-AM) under Item Management  General Ledger Transfer  Archiving  Deletion Objects.PrerequisitesThe deletion objects will execute business related checks.7.3.1.1 Deletion Object for FI BalancesDescriptionThe FI balances, which are also called technical balances for general ledger transfer, are the balances inFI for each account in the Account Management system. They are required to identify a balance statuschange. The data is stored in table BCA_GL_BALCN. When you display the payment items, the table is usedto format the general ledger information. It is also used for balance follow-up checks and to create aninventory.The most up-to-date balance is always in the table, even if it is several years old.The data in the table is not archived, but is deleted when the residence time expires.© 2011 SAP AG page 104/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0The system determines a key date for each company code on the basis of the current posting date of thebank posting areas assigned to the company code and the residence time per company code. Any balancesafter this key date may not be deleted. You can only create an inventory for a key date in the past if thebalance valid on this date is also contained in the table. You have to set the residence time so that thenecessary inventories can be carried out.The most up-to-date record of an account is never deleted. The only exception to this rule is in the case ofclosed accounts with expired reactivation periods.To ensure that the general ledger information is formatted when you display the payment items, the accountrecords are only deleted if there are no more payment items in the operational system for the account on theset posting date.Residence timeThe residence time for technical balances of the general ledger is defined in the IMG activity FinancialServices  Account Management  Archiving  Deletion Objects  Define Residence Time for TechnicalBalances of the General Ledger (Object GL_BALANCE).The residence time is calculated based on the posting date BCA_GL_BALCN-DATE-POST and refers solelyto calendar days.ActivitiesDefine the residence time for each company code. The residence time you enter must meet the prerequisitesbelow: The residence time must be longer than—or the same as—the minimum residence time defined in IMG activity Maintain Global Archiving Control. If you do not make an entry in this IMG activity, the standard residence time defined in Maintain Global Archiving Control applies.RequirementsBefore you can delete the data, you must execute IMG activity Maintain Global Control of Archiving.PreconditionsThe business check checks, for each contract/date value transferred in the input table, whether the entriesfrom the BCA_GL_BALCN table can be deleted. A record cannot be deleted if there is no newer record forthe contract in the BCA_GL_BALCN table, or if there are still contract items for this date. To run this check,you need to ensure that the input table always provides all the entries for a contract.TablesThe GL_BALANCE object consists of table BCA_GL_BALCN.© 2011 SAP AG page 105/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0Age of recordsThe yearly and monthly distribution of data can be analyzed by executing transaction TAANA for the followingtable and fields: BCA_GL_BALCN Z_DATE_POST_YEAR Z_DATE_POST_MONTH© 2011 SAP AG page 106/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.07.3.1.2 Deletion Object for Balance Sheet PreparationDescriptionReport RBCA_GL_BSPREP is used to summarize the turnovers of the posting day for the general ledger. Itthen writes the data in tables as summarized documents, but does not yet transfer it to the general ledger.Reconciliation keys are used to summarize the documents. A reconciliation key is a technical aid in AccountManagement for grouping postings to be transferred to the FI general ledger.Posting totals are generated using reconciliation keys, in which the general ledger account, amounts, andadditional data for the FI document are saved.Reconciliation keys are used to summarize data from Account Management and to form useful units. Theposting totals for a reconciliation key are always posted in full as FI documents, so there is always aconsistent status for each reconciliation key in FI.Reconciliation keys are automatically created and managed according to the bank posting area, the differentsources of document generation in Account Management, and on the posting date or a program run.A reconciliation key can have the following statuses: Value Meaning 1 Currently opened 2 Open for back posting 3 Posting day closed 4 In settlement for the general ledger 5 Settled for the general ledger 6 Transferred to the general ledgerAt the end of balance sheet preparation, all reconciliation keys must be settled for the general ledger (status5).Balance sheet preparation needs to be carried out daily within an automatic process as part of end-of-dayprocessing.Residence timeThe residence time for balance preparation data is defined in the IMG activity Financial Services  AccountManagement  Archiving  Deletion Objects  Define Residence Time for Balance Sheet Preparation Data(Object GL_BALPREP).The residence time is calculated based on the posting date and refers solely to calendar days.© 2011 SAP AG page 107/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0ActivitiesDefine the residence time for each company code.The residence time you enter must meet the prerequisites below: The residence time must be longer than—or the same as—the minimum residence time defined in IMG activity Maintain Global Archiving Control. If you do not make an entry in this IMG activity, the standard residence time defined in Maintain Global Archiving Control applies.RequirementsBefore you can delete the data, you must execute IMG activity Maintain Global Control of Archiving.PreconditionsYou can use report RBCA_BSPRPR_RUN_PP to output the table data in print lists. This permits you todocument the FI postings in the AM system at individual account level. The print list can be archived.The Balance Sheet Preparation data can only be deleted after the report used to create print lists has run forthe data. The system does not check whether the data has been saved correctly in the archive; you musttake organizational measures to ensure that this is done.The business check determines the data that was transferred to the general ledger.TablesThe GL_BALPREP object consists of tables BCA_GL_BSPR_PROT and BCA_GL_BPITEM.Table BCA_GL_BSPR_PROT (log table for balance sheet preparation) comprises totals summarized ataccount level for the following data:  Balance-changing postings  Non-balance-changing postings in the context of individual value adjustmentTable BCA_GL_BPITEM contains data on transfer postings. These are made during a balance statuschange, for changes to a balance sheet item (general ledger group change) or general ledger nettings. Thebalance sheet preparation uses this data, along with other details, to create the FI postings. These are thenarchived in the FI system.TAANA Ad Hoc VariantThe yearly and monthly distribution of data can be analyzed by executing transaction TAANA for the followingtable and fields: BCA_GL_BSPR_PROT Z_DATE_POST_YEAR Z_DATE_POST_MONTH© 2011 SAP AG page 108/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.07.3.1.3 Deletion Object for FI Totals RecordsDescriptionThe AM FI totals records are the posting totals for generating FI documents from AM. The FI totals recordsare not archived within Account Management (FS-AM). You can archive the objects using FinancialAccounting (FI).In the AM system, the data is stored in table BCA_GL_SUMS. After the totals records are transferred to FI,and if no further verification or reconciliation is necessary, the data can be deleted.Residence timeThe residence time for FI totals records is defined in the IMG activity Financial Services  AccountManagement  Archiving  Deletion Objects  Define Residence Time for FI Totals Records (GL_SUMSObject).The residence time is calculated based on the posting date BCA_GL_SUMS-BUDAT and refers solely tocalendar days.When maintaining the residence time, keep in mind that the FI totals records data is required to create theinventory.ActivitiesDefine the residence time for each bank posting area.The residence time you enter must meet the prerequisites below: The residence time must be longer than—or the same as—the minimum residence time defined in IMG activity Maintain Global Archiving Control. If you do not make an entry in this IMG activity, the standard residence time defined in Maintain Global Archiving Control applies.RequirementsBefore you can delete the data, you must execute IMG activity Maintain Global Control of Archiving.PreconditionsYou need the object data to create the inventory. No business check is executed for FI total records.TableThe GL_SUMS object consists of table BCA_GL_SUMS.TAANA Ad Hoc VariantThe yearly and monthly distribution of data can be analyzed by executing transaction TAANA for the followingtable and fields: BCA_GL_SUMS Z_BUDAT_YEAR Z_ BUDAT_MONTH© 2011 SAP AG page 109/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.07.3.1.4 Deletion Object for Inventory DataDescriptionInventory data is the volume of posting-date-based balances of all AM accounts on a key date. The dataresults from an inventory run or a legacy data transfer and is stored in the table BCA_INV_DETAILS.Residence timeThe residence time for inventory data is defined in the IMG activity Financial Services  AccountManagement  Archiving  Deletion Objects  Define Residence Time for Inventory Data (INVENTORYObject).The residence time is based on the key date for an inventory run or legacy data transfer from theBCA_INV_HEADER table.ActivitiesDefine the residence time for each company code.Note that the residence time you enter must meet the prerequisites below: The residence time must be longer than—or the same as—the minimum residence time defined in IMG activity Maintain Global Archiving Control. If you do not make an entry in this IMG activity, the standard residence time defined in Maintain Global Archiving Control applies.RequirementsBefore you can delete the data, you must execute IMG activity Maintain Global Control of Archiving.PreconditionsThe data in table BCA_INV_DETAILS can be printed in lists with the RBCA_INV_ANALYSIS_PRINT report.This enables the inventory to have values entered in it for individual accounts in AM. The print lists can bearchived. The data in the BCA_INV_DETAILS cannot be deleted unless reportRBCA_INV_ANALYSIS_PRINT has run.The inventory data may only be deleted once the AM subledger has been reconciled with the general ledger.The business check function module checks the characteristics DELETED and PRINTED. Only data with thefollowing values will be deleted:  DELETED Blank Dependent Data Not Yet Deleted P Dependent Data Partially Deleted  PRINT_STATUS 1 Data Printed for Entry 2 No Detail Data Found 3 Data Not Relevant For Archiving© 2011 SAP AG page 110/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0TablesThe INVENTORY object consists of tables BCA_INV_HEADER, BCA_INV_DETAILS, BCA_INV_TOTALS,BCA_INV_TOTALSGL, and BCA_INV_VERSIONS.TAANA Ad Hoc VariantThe yearly and monthly distribution of data can be analyzed by executing transaction TAANA for the followingtable and fields: BCA_INV_HEADER Z_INV_DATE_YEAR Z_INV_DATE_MONTH7.3.1.5 Deletion Object for Non-Balance-Changing PostingsDescriptionA non-balance-changing posting is a posting that can be clearly and unmistakably assigned to an account butdoes not change the account balance.Non-balance-changing postings are generated in the following processes:  Inventory data transfer (only for the legacy data transfer)  Interest and charge accrual/deferral  P&L net postings settlement  Individual value adjustment, for example, the splitting of net postings for an account settlementIf a general ledger update is activated, FI postings are generated. These are archived in FI. ReportRBCA_GLARCH_BSPR can be used to verify the FI postings at the individual account level. This can bearchived as a print list.Residence timeThe residence time for non-balance-changing postings is defined in the IMG activity Financial Services Account Management  Archiving  Deletion Objects  Define Residence Time for Non-Balance-ChangingPostings (SNITEM Object).The residence time is based on the posting date or the release date of the non-balance-changing posting,whichever is late. The residence time refers to calendar days.When maintaining the residence time, keep in mind that the non-balance-changing postings can only bedeleted if the AM subledger is reconciled with the general ledger.ActivitiesDefine the residence time for each bank posting area. You can use the Non Balance Changing Processattribute to differentiate between your residence time settings in greater detail.The residence time you enter must meet the prerequisites below: The residence time must be longer than—or the same as—the minimum residence time defined in IMG activity Maintain Global Archiving Control.© 2011 SAP AG page 111/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0 If you do not make an entry in this IMG activity, the standard residence time defined in Maintain Global Archiving Control applies.RequirementsBefore you can delete the data, you must execute IMG activity Maintain Global Control of Archiving.PreconditionsIf the general ledger update has been activated, the data can only be deleted once the reportRBCA_BSPRPR_RUN_PP, which is used to create print lists, is executed for print object SNITEM.TablesThe SNITEM object consists of tables BCA_SNITEM and BCA_GL_SNITEM.TAANA Ad Hoc VariantThe yearly and monthly distribution of data can be analyzed by executing transaction TAANA for the followingtable and fields: BCA_SNITEM Z_DATE_POST_YEAR Z_ DATE_POST_MONTH7.3.1.6 Deletion Object for Reconciliation DataDescriptionReconciliation in Account Management (FS-AM) includes procedures for the statement that shows thecompleteness of the daily turnover processing in accordance with the regulations for orderly accounting.These procedures provide statements of the completeness and accuracy of daily turnover processing. Thesestatements promptly identify errors in daily turnover processing (totals reconciliation) and promptly find theincorrect items (individual statement).During processing (inbound processing, general ledger preparation, and general ledger transfer), the systemsummarizes the items and saves the ensuing totals records in the database tables intended for this purpose.The totals are calculated from the key fields Posting Day, Reconciliation Unit, Currency, Status, andDebit/Credit Indicator. The system also stores the number of items that make up this total.The statement showing completeness of the daily turnover processing is based on various lists created byprograms. The system reconciles the lists by using the overall totals, subtotals, and individual records. Theindividual records fill the subtotals, and the subtotals fill the overall totals.Residence timeThe residence time for reconciliation data is defined in the IMG activity Financial Services  AccountManagement  Archiving  Maintain Global Archiving Control.The residence time is calculated based on the posting date BCA_GL_SUMS-BUDAT and refers solely tocalendar days.When maintaining the residence time, keep in mind that the FI total records data is required to create theinventory.© 2011 SAP AG page 112/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0ActivitiesFor technical reasons, no object-specific Customizing is required for the residence time for the deletion objectRECONC. However, you need to maintain the residence time and other data for the Global ArchivingControl for this deletion object.PreconditionsNo business check is executed for reconciliation data.Only reconciliations with no errors can be deleted. This is not checked by the system and must be ensured byorganizational measurements.TablesThe RECONC object consists of tables BCA_RCN_DETAIL, BCA_RCN_SUMS_IN, BCA_RCN_CROSS,BCA_RCN_CMP_CMPL, BCA_RCN_CMP_CROS, and BCA_RCN_CMP_GLOI.TAANA Ad Hoc VariantThe yearly and monthly distribution of data can be analyzed by executing transaction TAANA for the followingtable and fields: BCA_RCN_DETAIL Z_DATE_POST_YEAR Z_ DATE_POST_MONTH7.3.1.7 Deletion Object for Technical PrenotesDescriptionA prenote is a reservation for a future turnover (for example, for a debit resulting from a debit charge).You can create prenotes for both credit and debit postings. Amount, posting date, and payment method areopen. When there is a posting for a prenote, the system finds the prenote using a reference and its statusbecomes assigned. Otherwise the prenote is deleted after the residence time set in the customizing hasexpired.Prenotes do not affect the account balance, the posting-date-based, or the value-date-based balance.However, depending on the prenote type, it can be labeled as relevant for posting control and is thenincluded in the calculation of the available amount.In the IMG customizing, you define if a prenote is archived (meaning written to an archive file and thendeleted from the database) or deleted (without writing any information to an archive file). Choose the IMGactivity Financial Services  Account Management  Item Management  Prenote  Define PrenoteTypes. You can set the Archive flag in the control data for each Prenote type. If you do not set this indicator,the corresponding prenotes of a prenote type are deleted when you execute stepBCA_AR_PRENOTE_T_DEL in the SAP menu: Financial Services  Account Management  Archiving Data Deletion.You can find more information in section 5.22.© 2011 SAP AG page 113/114
  • Best-Practice DocumentData Volume Management Guide: SAP Banking Services 6.0© 2011 SAP AG. All rights reserved.SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP BusinessObjects Explorer, StreamWork, and other SAP products andservices mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and othercountries.Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, andother Business Objects products and services mentioned herein as well as their respective logos are trademarks or registeredtrademarks of Business Objects Software Ltd. Business Objects is an SAP company.Sybase and Adaptive Server, iAnywhere, Sybase 365, SQL Anywhere, and other Sybase products and services mentioned herein aswell as their respective logos are trademarks or registered trademarks of Sybase, Inc. Sybase is an SAP company.All other product and service names mentioned are the trademarks of their respective companies. Data contained in this documentserves informational purposes only. National product specifications may vary.These materials are subject to change without notice. These materials are provided by SAP AG and its aff iliated companies (―SAPGroup‖) for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors oromissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in theexpress warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituti ng anadditional warranty.© 2011 SAP AG page 114/114