SAP TAO - Expert intelligent testing services: Testing SAP Bank Analyzer 8.0

SAP BA Test Analysis and detail test cases for each of the Business transactions

Financial and risk calculations within the Bank Analyzer 8.0

Accounting for Financial Products

a) Calculation and Valuation

• Key date valuation for individual financial product positions <Test set  template product positions>
• Key date valuation for group of asset class <KDV – individual and Group – Test set- amortization of 20% loans, fair value calculation, time series distribution of valuation, and deferred taxes,  fluctuated tax rate >
• Key date valuation of portfolio financial positions<<KDV – individual and Group – Test set- amortization of 20% loans, fair value calculation, time series distribution of valuation, and deferred taxes,  fluctuated tax rate >>

 b) Accounts Level test results

• External business transactions with indicator for each of the work list #
• Accounting for Financial Instruments with Aggregation <AFI Aggregation - different process – Test set #>

 d) Net Present Values and Calculation

• Generation of the finance positions – with Aggregation
• Individual Aggregate Financial Transactions – account mapping and balance processing before posting
•  Accrual Results <Input test case and output results>
• Application Events for source data aggregation (single day – overnight processing)
• Importing Sub-Ledger Documents (ISD) for Loans Results

Cost Accounting Processes

• Profitability analysis of financial products < Group of test cases a+e= contribution margin- cost centre base + 6 division, 52 cost centres)
• Direct and indirect costs with the financial transactions and financial instruments – <Scenario failed – need feeder systems changes to amend tariffs, rates etc>

SAP Bank Analyzer Test Strategy -high level contents (upgrade)...

Phase of SAP BA  Testing

Sand box testing phase….(Upgrade only)

Note -  Sandbox testing should be managed and controlled formally using project template documentation  e.g. 1)) List of the Scope including static check and transaction etc 2) expected result document in hand with functional users 3) keep developing issue list- comments and resolution and any fix date etc . As we understand Sandbox testing is performed in screening mode hence less likely to be documented comprehensively such as actual test scripts, it is recommended to develop formal scripts so a knowledge base can be build for origination. An organised test activity can save lot of time for the users and functional teams who will be performing testing…

Once you basic configuration done, such as BP, Conditions, account created also the required additional business partners, we can execute basic functions in the system such as creating and changing conditions, accounts, and losses in Basic System and creating and processing in Risk Manager.

 Test cases should be available that have been developed specifically for this purpose. The scope of the sandbox test environment does not include the connection to a current account system. Instead it can be used for a dummy current account system to create and relates accounts on the system interface but cannot trigger the actual processing of these – it can be exercised in dev – unit box

AFI Processes (the application side) – can be proved for stability here – running a demo test

AFI positions and postings – During sandbox position management can be calculated and a demo documentation to review postings…

AFI valuations – It is complex area to test standalone however an experience prison can develop cases for valuation and risk management to credit entities –one of the limitation is that a full portfolio can be not tested within SAP BA – we tried to define characteristics and results for test purpose of individual portfolio of instruments and calculation work for curve and broad range of effectiveness tests using key dates but because of the nature of the scenario I believe it was not best utilization of time

Application Event Management test considration for SAP Bank Analyzer, as per our experience  other than applying tsting in  the Development System where either no data available or activities planned purely for development not much testing can be performed for SAP BA upgrade –however full  Application Event Management  testing is being performed in the SAP QA during the “Realisation Phase” of the project –

Please note test team should understand the concept of SAP Bank Analyzer's function, worklist, indexes, application events and accounting events so that the Application Events teting can be applied effectively. A carefull selection of the busines processes/ functional with detail scripts can help here not only for ad-hoc daily but monthly (periodcal processes)

  

…

Full list of tests / business processes available in the document on demand

…

Automation in or before SAP upgrade – Optimum effective and cost saving approach

Testing SAP Upgrade : SAP upgrade Testing (Unicode) - under development Sol Man best practice...

Next article will be from an experiences SAP upgrade consultant about the Sol Man best practices BPCA and SAP Tao usage in a SAP upgrade project, a full upgrade tests strategy applied in a global organisation

Please join this blog as member to receive actual implemented test strategy contents or plan – or send email to info@saptao.co.uk

SAP TAO - Expert intelligent testing services: Testing SAP Upgrade

SAP TAO - Expert intelligent testing services: Testing SAP Upgrade: SAP upgrade Testing (Unicode) - under development Sol Man best practices BPCA and SAP Tao

SAP upgrades- Yes, we know that upgrades need extensive testing - someone expert in SAP upgrade stated that SAP upgrades is  like providing SAP system a new heart and lung transplant hence any organizations having SAP-based business solutions will be involved one point of time to upgrade SAP solution/ project with new heart and lung transplant .

 As we understand planning is important that include the test strategy of upgrades so as its planning. In this article we will discuss what the best suitable test strategy and suitable measurement to ensure testing being conducted on the SAP grade is successful, optimum and effective either be it improvements through enhancement SAP packages, or an installation of new components per the needs of the organization.

Needless to say, the success of SAP upgrade projects relies on efficient and comprehensive test planning of testing activities that start from the project kick-off itself and last until a couple of weeks before the project go live date.
Organizations involved in SAP upgrade projects find difficult over the testing of the upgraded and the unicoded SAP-based business solution.
First question comes how much, when and detail scope effort involved in testing. To allocate a wise dollar, important that the optimum testing approach is defined upfront for the SAP upgrade project and then controlled and followed.
Testing involves careful allocation of project resource with a comprehensive plan and the project cost.
For SAP upgrade test strategy it is not simply just "grab a product manual and jump on the system to start tests" following points listed from industry experiences and we believe  should be considered to SAP upgrade strategy

1)      Detail project plan to fit appropriate testing in phase based approach

2)      Effective change management strategy with appropriate resource commitment

3)      Upgrade documentation and existing system functionality document/ blueprints

4)      SAP upgrade methodology /upgrade consultants knowledge on the existing system infra and landscape 

5)      List main business drivers for the SAP upgrade

6)      Ensure that new upgrade environment mirrors your existing environment, with sandbox, development, QA, and production systems in order to ensure a smooth cut over.

7)      Wherever possible – combine Test Plan for a "functional" and technical features during system and integration tests phase

8)      Ensure Unit test during the Unicode conversion process

9)      Ensure 50 % of data coverage for functional  business process coverage and 110% coverage for non functional performance tests

10)   Ensure a possible access to Solution Manager prior and during test phase of upgrading – try this it is vey effective if Test team member know internals of SolMan – use BPCA or if practical use test automation

11)   Ensure before Integration phase, objects, processes and methods tested with reasonable coverage in the Unit tests phase.

12)   Ensure End-user can lend a useful hand during later phases of tests

13)   Ready with an in-depth skills "gap analysis" to determine which skills you can to assist you in testing e.g. basis, functional and end-user business users other than testing team members.

14)   Bring user testing early you may say "user training." – it is advisable to allocate a complete Sanbox for training -  log defects if they identify during sandbox user training so known for later stages of the project testing

15)   Create role-based  test role and mimic it like real time business processes

Low level points that we believe should be considered for an effective test strategy on upgrade-
Each Incremental test approach on Sandbox -
Sandbox testing is to ensure the important scope of changes and any issues in the upgraded or/ and unicoded.
It is recommended that some scope preparation on the project tests activities starts in parallel while the sandbox is being built and assisted by functional consultants. Hence when Sandbox is finished & ready test can case set is ready to start on the sandbox testing- it help is saving time.

Further, it is quite effective in the test strategy to list important tests (high priority- critical and important tests) to identify transactions of the business processes from the various functional teams to ensure the extent of changes in the new system is evaluated early with reasonable coverage.

This test strategy can help ensuring the frequently used SAP standard and custom transactions for expected results.

Suggested a parallel / comparability testing here – to ensure usage from system are intact, it depends upon the nature of upgrade however it is advice to consider a comparability study between to boxes

Check critical interfaces early with reasonable test, -All the critical interfaces should be identified and their connectivity must be established with corresponding test systems. e.g., inbound, outbound, file-based, database connects – this is more important if the upgrade involved any of the OS updates along with system

Cross reference matrix between old and new systems for interfaces is maintained with responsibilities agreed to and from side of the systems impacted.   

If the number and nature of defect is high, the testing scope should be accordingly enhanced to achieve a successful testing, this assist increasing the confidence of stakeholders.


Next article will from an experiences SAP upgrade consults about Sol Man best practices BPCA and SAP Tao usage in upgrade ----

Please join this blog as member to receive actual implemented test strategy contents or plan – or send email to info@saptao.co.uk

Testing SAP Bank Analyzer 8.0

SAP TAO - Expert intelligent testing services: Testing SAP Bank Analyzer: Testing SAP Bank Analyzer – This article will explain best approach and test strategy to test SAP Bank Analyzer
 

With SAP Bank Analyzer, a Familiar statement is that SAP Bank Analyzer supports overall bank controlling by calculating, evaluating, and analyzing financial products and structure of Bank Analyzer is per IFRA and it provide facility to meet the current requirements ((IAS), Basel II, and Risk Adjusted Performance Measurement) for the value range of financial products. So let's evaluate the above statement first, In last couple of decades SAP offering Business Management Software Applications to meet industry problems, so in simple words SAP bank analyzer packaged applications that has been engineered for Banking Analytics (data management and arithmetic calculation) to streamline business process management / business requirement to meet Accounting for Financial Instruments, risk assessment, performance evaluating of the financial products in an Integrated Finance and Risk Architecture (IFRA) that is required not only for the bank's internal controlling over the Credit Portfolio Management but also reporting to external stakeholder from compliance perspective.

Above is a typical statement to define what is SAP Bank Analyzer, lets outline business and technical information of SAP Banal Analyzer and how does it work & where does it fit in a bank/ institution's  along side the testing and data strategy.

SAP Bank Analyzer is not single application to meet above stated business requirement but a product family that contains multiple components as:

• Data Load Layer (FS-BA-DL)  
• Source Data Layer (FS-BA-SD) - SDL
•  Processes and Methods (FS-BA-PM) - PML
•   Results Data Layer (FS-BA-RD) - RDL
•    Analytics (FS-BA-AN)
•   Infrastructure (FS-BA-IF)
•   Tools (FS-BA-TO)

 

Testing of Data Load Layer (FS-BA-DL) & Source Data Layer (FS-BA-SD)

One of the typical needs for risk assessment within Risk department is the need of data (either current real or a time series historical data) for risk modelling or reporting – First component of the SAP bank analyzer is the Data Load layer, information about the SAP Data Load Layer is available on the SAP Website " Documentation website" so here we will not repeat what is not relevant for our testing discussion.

Please note in any "Risk modelling solution" or a product implementation 50% time is being spent on sourcing data into tools therefore need of testing for DL/SDL layer is foremost important form system, business perspective.

Data Load Layer constitutes functions for importing source data and results data from SAP NetWeaver BI (tool BI) to the interfaces in the Source Data Layer (SDL) or some time Results Data Layer (RDL) in the SAP Bank Analyzer. This is fairly simple to test and can be proved using a general extraction, transformation and loading process test that can prove transfer of source system data to Bank Analyzer.

As data is being core backbone for the basis for the evaluation in the next layer of the Bank Analyzer - Processes and Methods (FS-BA-PM) – testing operations system data with certain checkpoints within the SDL reduce any GAP of data or inconsistency in upstream layers, Parameterize data-driven Tests can also offer variance of tests so recommended to use a data scenarios spreadsheet or database to overcome any cumbersome changing requirements for example, when its is simple sandbox tests "LSMW" routine can be run with minimum data (e.g. master data (legal entity, account and transaction or data being verified between source application to Data load/SDL layer. 

Some time SDL component needs to be quickly supplied a large amount of input especially when functional test are stable and Tool BI or any ETL need for the purpose of system performance tests.  It is also recommended that Re-Usable data sets developed, reviewed and validated keeping High level business scenarios coverage in mind within tests of the SDL layers tests.

Data load layer testing (BI) is core to test to ensure the system selects the required data, and fills the extraction structure correctly. Only by doing these tests can you ensure that the BI data extraction works as expected using your settings, and that the system will later extract the data in the required form.

Further testing strategy depends upon the nature of the solution implementation e.g. a vanilla implementation, upgrade or prototype tests, if there are limitation of the source data or a prototype or data weaver in place to use /real time/ live data, this case, a data generator tool can help to develop required test data with all logical entities in place. You can create test data sets instead going to tedious work to develop data manually. As required for success of data-driven testing approach, all input data and expected results tests are kept in one place, reviewed with SME, updated when required.

Source system data, feeder system mapping, (ETL) and data set types and basic configuration can be agreed with data migration and functional team before or during the early phase of test cycle. It is also advisable that test coverage of the SDL layer testing should be moderate as downstream layers i.e. PML - Processes and Methods (FS-BA-PM),  RDL- Results Data Layer (FS-BA-RD), ,AN -Analytics (FS-BA-AN) and  tool and Infrastructure require more a Object based  tests, so may be we can looking to apply Object-Driven Tests
 

Data-driven testing test strategy is best approach to run together with related data migration sets/scenarios in a framework. An iterative and incremental approach is more useful during the SanBox – Config test runs, it must be applied using data scenario to check integrity of objects and processes. Other data drive test strategy depends upon the implementation consideration such as if requirement is for BASEL traceability of the in-house model input and output with time series of future validation based on model etc       

Best Testing practice -

• Data Load Layer does not contain data validation. The system data is being imported that has been transformed and mapped directly to the inbound interface of the SAP Bank Analyzer system (primary DSO). Relying on the data load loading results can not be prove enough system data quality checks therefore need for testing increases here, SDL need consistency checks of the data, integrity checks verification and in some case where stress test involves some data enrichment test as well  specifically in DLL using ABAP routine.
• Each load process supplies the last version of an object hence minimum tests should be run when processes are run. It is also not possible to process more than one version for each business day therefore keeping data set ready to utilize in short time span helps to ensure system quality. If an error occur during the data loading (Dala load). Remember to check business date or event date key when identifying new objects to be loaded. – This check must be pre-request of the identified tests.
• The SAP BA system does not load business partner data- master data. The only way that the system can load business partner data into the Bank Analyzer system is by using a BAPI. – Therefore need of tests increases when any BAPI is introduced to updated etc.

In short statement, the separation of the components ensures data is stored help in testing integrated and consistent way, Source systems / operational systems data is first mapped and migrated into the Source Data Layer (SDL). The FS Data Load Function is being used in the definition of a BI process chain (Check with BI -ETL team that it is in place so success of the tests is recorded) the process is scheduled and monitored within BI hence test representative should have appropriate access. Process control is part of the Data Load Layer that contains process chain also in event of change – CNS Change Notification Service (CNS) within the BI tested for any object change e.g. any primary object change – Change log for the primary objects change also provide assurance.

Any need for the BP (Business Partner) tests along with the operational system Data load or change within the SAP BA interface tests however this depends upon questions before finalizing test data strategy

Eg

·         Do we need Parallel runs and what is the data loading architecture?

·         What is the source data that they would require to be used in BA?

·          Would it be the financial instrument level of data or extension?
What data that lands in these BA or its tools require reconciliation to financial figures?

As we understand, each tool requires setup time. Will there be any blueprint on the implementation/mapping for SAP BA data for product and how the team structure is setup etc. Going forward, is there any requirement for building a in-house Data warehouse?

What and when the reports are coming out for the products – Daily, Monthly – IFRS, management or accounting statement reports etc?

Each of the data or each module required different data set and their timely testing

Following data attributes should be considered whilst developing test data strategy –

Master Data

• Reference Data items that are required to support the transactional data.

 Transactional Data

• Trading and non-trading financial data.

 Configuration Data

• This is data that is set up on SAP during the build and configuration process.  This type of data is not part of the migration process, as it will be transported to the production system through the SAP transport procedure

 Financial Instruments

- From defined business line

 Financial Transactions

• “Live” trades or an ongoing business transaction in scope.

  Counterparty data

• Counterparty data details - legal entity, region, and name etc.

  Valuation data 

• “Live” trades, yield curves, fair value, exchange rates etc.

  Business Transactions

• Current outstanding trades yet to settle or any other Business Transactions entries required to build up model

 From Performance testing perspective - Multiple Sources Data Synchronization, Volume of data and need for parallel runs and what is the data loading system architecture, hardware should be looked along side functional and integration tests?

Other Functions test consideration for the SDL, following functions for the primary objects to be tested -

● Validations -

● Authorizations

● Archiving

Removed as contents are client specific scenarios….

 

Fig – 1 Quick  dirty diagram to depicts ETL process to load Operation data into SAP BA – DL / SDL layer

Testing of the Processes and Methods (FS-BA-PM)

Before moving to Testing of the Processes and Methods, remember, SAP-AFI comprises a variety of processes that altogether form a complete subledger for Financial Products. The overall architectural idea of SAP-AFI is to have a thick subledger, i.e. one that contains all information required for financial reporting, and a thin general ledger, i.e. one that that holds just enough information to fulfill the daily reporting requirements with reasonable performance.

 

During defining testing of the PML, Keep in mind that the SAP BA infrastructure testing is incomplete for any business blueprint/ business processes until functional level summaries functions are not clearly listed and executed in the test strategy or detail plan –

Testing of the Processes and Methods (FS-BA-PM)

< >

Below list is the possible SAP BA E2E scenarios, each of the scenario will be decompose to describe Testing of the Processes and Methods (FS-BA-PM) in a typical FI implementation, Please join this blog and also send email if you are looking for complete End to end test scripts that has defined input and expected results, documentation of test results and resolution.

- Please note outlined SAP BA test strategy features have not been discussed for typical test management activities e.g. Resources, domain expertise, hands-on experience or accounting knowledge etc …

It is essential that consultant should understand basic of FI, Accounting (IAS - IFRS) & also technical structure of the SAP BA especially it a new implementation either be in FI or for credit risk implementation.

Moreover Financial Basis should be known to test resource to implement an effective testing strategy…

List tests are essentially function tests; there are two characteristics of the tests –

1)Component Integration test phase

2) E2E business processes tests.

In contrast to the other test scenarios, all the steps for AFI are collected in a typical sequence shown below.

Finance Accounts Testing scenario and their Results

Category 1 - business transactions

· Post external business transactions

· Update secondary business Transactions

Category 2 - date valuation

· Key date valuation for all financial positions

· Financial Positions for Period (PICC) event processing etc

· Update costing for period before GL and during transferring GL documents

· Calculation for all PICC

Category 3 – SAP GL Postings

· GL Connector and document generation – Journal and document review and finance reconciliation of the GL, Profit centre and any material code posting review

· Balance processing step 1 - (SV)

· Balance processing step 2 - (ATP)

Testing of the accounting for FI with Aggregation (AFI) for Accounts Results before RDL and GL

The Accounting Management comprises a number of accounting procedures that in turn cater for the correct derivation of postings for a certain business event.

Category 1 – position management

· Generate Finance Instruments position

· Aggregate Financial Transactions

· Prepare Business Transactions for Aggregation

· Process Reassignments for Business Transactions

· Aggregate Business Transactions

· Aggregate Current Accrual Results

· Process Reassignments for Accrual results

· Aggregate Retroactive

· Accrual Results

· Derive Application Events for source data aggregation

Imported Sub-Ledger Documents (ISD) for Results

ISD sub-ledger import

Other – FS-BA-PM – Tests

 

Testing SAP Upgrade

SAP upgrade Testing (Unicode) - under development

Sol Man best practices
BPCA and SAP Tao

SAP Bank Analyzer Implementation Strategy -High Level Contents / Overview

Testing SAP Bank Analyzer –

This article will explain best approach and test strategy to test SAP Bank Analyzer solutions, upgrade or integration. Recently I've had opportunity to work on two demo solutions for a banking system SAP Bank analyzer implementation within risk and profit analyses team and a short term test strategy development for rapid SAP bank analyzer implementation within an investment bank.

This article will explain best approach and test strategy to test SAP Bank Analyzer solution 8.0,or  upgrade from 7.0 50 8 or integration. Recently we worked on two demo solutions for a banking risk system SAP Bank analyzer implementation within risk and profit analyses team and a short term test strategy development for rapid SAP bank analyzer implementation within an investment bank.

In next couple of blogs we will detail an effective way to test SAP Bank analyzer and its individual components.

SAP Bank Analyzer Test Strategy - high level contents - anyone interested to see detailed strategy – please follow blog and send email so we can review version of test strategy that has following :

 

Detailed contents

1          Overview..................................................................................... 5

1.1       Introduction.................................................................... 5

1.2       Document Purpose....................................................... 5

1.3       Document Scope........................................................................................................... 5

1.4       Document Context....................................................................... 5

1.5       Document Status....................................................................................... 5

1.6       Document Hierarchy.......................................................... 5

2          Service Design and Business Architecture......................................... 7

2.1 SAP BA (Sub-Ledger) Project Scope

- <doc name -SAP GL and Sub Ledger Testing Strategy v0.1 20121110>

- SAP BA - Test Objectives in upgrade and in new Implementation

- upgrade objectives

- new SAP BA implementation

           

Service Documentation................................................................. 7

2.2       Business Architecture........................................................................ 8

3          Test Approach

SAP BA - Testing Approach (As standalone components – Integration and E2E

- Testing Process and Procedures, compliance, tool, on infrastructure

- Defect and resolution Plan

- Roles and Responsibilities – Mainly SMEs, BA engagement

- Process and any improvement (constant feedback) and Root cause analysis

- Deliverables

- All deliverables eg Common deliverables test plans, test cases, test scripts, test matrix and a defect log etc

-Schedule – specific to project

-Environmental Needs

-Data Need

-Resource Management – Important from skills of all personnel involved in the

- testing Risk and Contingencies Plan

-Approvals and Workflow – Functional consultants' engagement

 
               SAP GL and bank Analyzer Testing Overview.....................

3.2       Test Process Map and Key Products.......................................... 11

3.3       Test Workshops............................................................................ 11

3.4       Test Stage Overview............................................... 11

3.5       Test Preparation......................................... 13

3.6       Test Readiness Review Meeting...................................................... 13

3.7       Test Execution...................................................................... 13

3.8       Test Metrics........................................................................ 14

3.9       Test Completion Reports

3.10     Test Completion Review Meeting...................................................... 15

3.11     Test Documentation Deliverables...................................................... 15

3.12     Test Traceability........................................................................ 16

3.13     Test Observation Reports.............................................................. 17

4          Banks FI Testing.......................................................................................... 18

Clarity and definition of the SAP BA features and functions can be tested and can not to be tested

 

4.1       Early SMEs SAP BA Testing Overview................................................ 18

5          Early Testing...................................................................................... 20

5.1       SandBox Testing Scope................................................................................................. 20

5.2       SandBox Testing Pre-requisites...................................................................................... 2

5.3       Entry Criteria for Industry Test Stage

5.4       Success Criteria for Industry Test Stage.......................................................

5.5       Suspension / Resumption of Testing................................................. 23

5.6                High Level scenarios

5.7                      Finance Accounts Testing scenario and their Results

There could be two scenarios either – Accounting IFRS implementation or risk architecture – see below diagram for both ..  

A)  Accounting IFRS implementation (accounting consequence, SGL scenarios)

B) Risk architecture

Lets review each of the element in the diagram
See SAP SDN for SDS -

 First later is SD component to load original data from other operational systems or source systems into the Source Data Layer (SDL) by means of an extraction, transformation, and loading process (ETL process).  The SDL saves, consolidates, and manages the original data. At the same time it provides interfaces to additional operational systems.

The primary objects of the Source Data Layer (SDL) and their scenario versions are a flexible way of saving master data, flow data, and market data. They also group this data into units that belong together logically from a business perspective. This ensures that the Bank Analyzer components that are linked to the SDL have a standard, consistent data source.

In addition to storing primary object data, the SDL provides the following primary objects functions for applications linked to it:

 

●     Access to source data

●     General functions for source data layer

●     Methods for source data

●     General access to corrections

●     Tools

Integration

The SDL provides both the central original data basis and a part of the underlying infrastructure for linked applications. It is therefore a key element in ensuring the consistency of data and results.

 

<To be updated soon) - if you need detail document, please email your request

 

Category 1 - business transactions

 

• Post external business transactions
• Update secondary business Transactions

Category 2 - date valuation
 

• Key date valuation for all financial positions
• Financial Positions for Period (PICC) event processing etc
• Update costing for period before GL and during transferring GL documents
• Calculation for all PICC

Category 3 – SAP GL Postings

• GL Connector and document generation – Journal and document review and finance reconciliation of the GL, Profit centre and any material code posting review
• Balance processing step 1 - (SV)
• Balance processing step 2 - (ATP)

Testing of the accounting for FI with Aggregation (AFI) for Accounts Results before RDL and GL

Category 1 – position management

• Generate Finance Instruments position
• Aggregate Financial Transactions
• Prepare Business Transactions for Aggregation
• Process Reassignments for Business Transactions
• Aggregate Business Transactions
• Aggregate Current Accrual Results
• Process Reassignments for Accrual results
• Aggregate Retroactive
• Accrual Results
• Derive Application Events for source data aggregation

Imported Sub-Ledger Documents (ISD) for Results

 ISD sub-ledger import

 

6          Test Infrastructure......................................................... 38

6.1       Test Environment............................................. 38

6.2       Test Data......................................................... 38

7          Live (Pilot)...................................................................... 39

8          Test Observation Management..................................................... 40

8.1       Severity Levels............................................................... 40

8.2       Priority Levels........................................................... 41

9          Roles and Responsibilities.............................................. 42

9.1       Test Organisation Structure................................................ 43

10        High-Level Summary Timeline................................... 44

10.1     Key Milestones........................................................ 44

10.2     SAP GL and SAP  BA Testing Timeline.................................. 45

11        Risks and Issues......................................... 46

Appendix A - Glossary.................................................................... 47

Appendix B - Test Process Map....................................................... 52

Appendix C - Test Specification................................................................. 53

C.1       Test Documentation....................... 53

C.2       Example SAP GL Test Scenarios................................................ 53

C.3       Example SAP Bank Analyzer  Test Scenario & test coverage Information........ 55

Appendix D - Example Test Stage Plan Contents List........................... 56

Appendix E - Example Test Observation Form Contents List........................ 57

Appendix F - Example Test Completion Report Contents List.................. 58

Appendix G - Example Test Progress Report Contents List........................... 59

Appendix H - SAP BA Business Process List................................. 60