Test Scripts

The test scripts covered by this report include the following:

Doc No. Test Script Final Execution
Approval Date
FI -01 BTC: Master Data Maintenance. G/L Accounts
and Account Data.
6/7/2010
FI-2.1 BTC: Journal Entry Processing 6/7/2010
FI-2.2 BTC: Journal Entry Processing 6/7/2010
FI-03 BTC: Month End Close 6/11/2010
FI-04 BTC: Fixed Asset 6/11/2010
FI-4.1 BTC: Asset Posted Directly into FI 6/4/2010
FI-4.2 BTC: Fixed Asset Acquisition 6/4/2010
FI-05 BTC: Budgeting and Planning 6/4/2010
FI-06 BTC: Controlling 6/7/2010
FI-07 BTC: Internal Orders 6/4/2010
FI-08 BTC: Accounts Payable 6/3/2010
FI-09 BTC: Accounts Receivable 6/7/2010
FI-10 BTC: Import Electronic Bank Statement 6/14/2010
FI-11 BTC: Employee Expense Report 5/26/2010
FI-12 BTC: Inter-company Journal Entries 6/14/2010
MM-01 RTP: Create Standard Purchase Order 6/3/2010
MM-02 RTP: Create Standard Purchase Order 6/3/2010
Doc No. Test Script Final Execution
Approval Date
Radioactive Material
MM-03 RTP: Create Standard Purchase Order for IT
Product. Product Returned Before Invoice is
Applied
6/3/2010
MM-04 RTP: Create Agreement Purchase Order 6/3/2010
MM-05 RTP: Create Standard Purchase Order for
Controlled Substance
6/3/2010
MM-06 RTP: Create Standard Purchase Order - GMP 6/3/2010
MM-07 RTP: Create Blanket Purchase Order 6/3/2010
MM-08 RTP: Create Standing Purchase Order 6/3/2010
MM-09 RTP: Create Agreement for Software
Maintenance
6/3/2010
MM-10 RTP: Create Agreement for Software License 6/3/2010
MM-11 RTP: Change Standard Purchase Order Add
Lines
6/3/2010
MM-12 RTP: Create Master Contract 6/3/2010
MM-13 RTP: Purchasing Credit Card Process 5/26/2010
MM-14 RTP: Standard Purchase Order for Services
Processing
5/24/2010

MM-15 RTP: Create Agreement Purchase Order for
Prepaid Account
6/3/2010
MM-17 RTP: Create Purchase Order for Inter-company 6/11/2010
Doc No. Test Script Final Execution
Approval Date
SC-01 SC: Master Data Maintenance. Material, Info
Record and Source List
6/2/2010
SC-02 SC: Procure Finish Goods from GmbH to Deliver
to 3PL
6/7/2010
SC-03 SC: Miscellaneous Warehouse Movements 6/7/2010
A stress test was also performed following completion of the function test scripts.
Acronyms
AP: Accounts Payable
BTC: Budget-To-Close
FI: Finance
HCM: Human Capital Management
HR: Human Resources
IT: Information Technology
MM: Material Management
RTP: Requisition-To-Pay
SC: Supply Chain
SDLC: Software Development Life Cycle
SOP: Standard Operating Procedure
References
Document Number Title
SOP 01-043-IT revision 02 Software Development Life Cycle (SDLC)
methodology SOP
CSV-0014-VPL SAP Financial System Validation Plan
CSN-0014-ITS SAP Financial System Test Scripts
CSN-0014-ETS SAP Financial System Executed Test
Scripts

Testing Overview and Results
Test Cycles
Three cycles of testing were executed during the period 5/25/2010 through 6/9/2010. All
test scripts were executed in each cycle, except for the following:
The Supply Chain scripts, which were executed once during Cycles 2 and 3
The Month End script was only executed in Cycles 2 and 3
The Consolidation and Inter-Company scripts were only executed in Cycle 3
The Expense Report script was executed in Cycle 2, but based on using the
script the business process for expense report processing was changed to rely
on journal entries. Since journal entries were tested in detail, no further testing
was required.
The testing of AMEX credit card processing was performed in Cycles 2 and 3.

Cycle 1 testing did not include converted data, however, there was data available in
Cycles 2 and 3 that was used by the testers. This helped ensure that the data
conversion programs and data structures established for accounts was done properly
and allowed the team to identify some missing accounts. Data validation will occur as
part of cutover, but including early samples of converted data in the testing cycles
helped to confirm the conversion process.

User roles were tested in Cycles 2 and 3. Each user logged in with the login and
planned role assignments they will be assigned in the production system. Problems with
role assignments were corrected during testing. Following testing, a listing of the
permissions for each user was generated for approval by the business owner to ensure
that no segregation of duty issues existed in the assignments.
Following completion of the three functional test cycles, a system stress test was run in
the production environment to verify that the Production environment would be able to
operate under heavy system usage.
Test Team
The functional test team was comprised of the following business users:
NAMES OF TESTERS LISTED


The following IT and consultant staff supported functional testing activities:
NAMES LISTED
The following IT and consultant staff supported the System Stress test activities:
NAMES LISTED
Test scripts were created based upon testing scenarios requested by the business.
Appendix A contains a mapping of test scenarios requested by the business to test
cases executed during system integration testing. As shown, all scenarios were
represented in the test cases. The users also performed other informal tests, where
they executed transactions that were reflective of specific work they perform in their day-
to-day jobs to ensure that they were satisfied that the system could handle all
requirements.
Overview of the Test Process
Test scripts were assigned to business users, based on the roles and backup roles that
they would perform during production. The following instructions were provided to the
testers:
1. Each step in each test script must be executed. The tester must initial and date
each step as it is performed and indicate whether the step passed or failed,
based on expected results.
2. When a step was executed successfully:
a. Initial the script and marked the step as completed successfully.
b. Where appropriate, record the actual results.
c. If requested, attach a screen shot to the test package and write the date,
test script name, and step number on the screen shot.
3. If a deviation is found when executing a step:
a. Call one of the test managers to review the problem
b. If instructed by the test manager, complete the top portion of a deviation
form.
c. If instructed by the test manager, print a screen shot that describes the
deviation and attach it to the deviation form.
d. Mark the test script as failed.
e. If possible, continue on with the test script, although in many instances
you may not be able to complete subsequent steps due to the error.
4. If an error is found in the test script
a. Correct the script by editing in ink and initialing and dating the change
b. Provide a comment at the end of the test script that describes the change
c. Record results of the test (step 2 or 3 above)
5. If a data error is found when executing a step:
a. Call one of the test managers to review the problem
b. If instructed by the test manager, complete the top portion of a deviation
form and mark the type as data.
c. If the test manager makes a change to the data, record the event in the
comments section of the test script and continue testing. You may need
to repeat some of the steps of the test script.

At the end of each day scripts were collected and reviewed. Script errors identified
during testing were corrected for use in subsequent testing. The results of each
executed test script in all test cycles are contained in the executed test script document
(CSN-0014-ETS).
Deviations
Deviations identified during tested were recorded on deviation forms and assigned a
category based on the following criteria:
Critical - The defect results in the failure of the system or core business
functionality can not be performed as a result of the defect. Workarounds do not
exist to resolve the problem.
Major - The defect results in the failure of the system and/or core business
functionality can not be performed, however, workarounds do exist that allow
business functions to be performed
Medium - The defect does not result in a failure, but causes the system to
produce incorrect, incomplete, or inconsistent results, or the defect impairs the
usability of the system.

Minor - The defect does not result in a system failure, does not impair usability, and the
desired processing results can easily be obtained by working around the defect.

Integration between the Project System (PS) and Funds Management (FM) components
enables you to monitor budget-relevant network processes.

If you are using integration between the Materials Management (MM) component and
FM, this is particularly relevant to external procurement transactions and withdrawals
from your own warehouse.

If you are using integration between Controlling (CO) and FM and FM-CO posting
integration is active, CO transaction completion confirmation and settlement transactions
also have an effect on FM.

The link between the network process and FM is established by entering an FM account
assignment when you create a network. This means that the system automatically takes
this account assignment from the network during subsequent processes triggered
automatically by the network, such as purchase requisitions.

The assignment of the FM account assignment is entered on header level for header-
assigned networks and is therefore valid for all network transactions; you have to
maintain the assignment of each transaction for activity assigned networks.

You have to enter the FM account assignment manually. However, if you have
maintained the relevant assignments of FM account assignment elements to Controlling
objects in one of the derivation steps of your derivation strategy, the system can derive
the FM account assignment from the network account assignment data, for example,
from the WBS element to which the network is assigned. The FM account assignment
determined with the derivation strategy then appears as a default value that cannot be
overwritten.

You can implement an alternative proposal logic for the activity assigned network plans
using enhancement SAPFMNV, (development class FMFS_E, component
EXIT_SAPLFRC4_003); and for header-assigned network plans using enhancement
SAPFMNP (development class FMFS_E, component EXIT_SAPLFRC4_004).

Prerequisites

Field control

The fields for the FM account assignment elements only accept input in the
network/network activity, if their field status is set as optional or required entry. You
make the necessary settings in Customizing for Funds Management Government by
choosing Actual/commitments update/Integration

Integration

Maintain field status for assigning FM account assignments.Automatic derivation of FM
account assignment in follow-on documents of the network

To allow the FM account assignment to be derived automatically in the follow-on
documents in the network, you must copy to your derivation strategy the Network header
assignment (Table FMZUOB) derivation step, which is provided by SAP. You make this
settings in the Customizing of Funds Management Government by choosing Master
Data Assignments to Account Assignments from Other Components Choose
Derivation Rules.

Derivation of funds center and fund from Controlling object

If you want to derive FM account assignment elements from Controlling objects, you
must have defined a rule in your derivation strategy, in which the funds center and fund
are assigned to the Controlling objects.

For more information on this topic, see Deriving FM Account Assignment Elements from
CO Account Assignments.

Derivation of commitment items

SAP recommends that you derive commitment items from the G/L account or the cost
element. You must also have defined an appropriate step in your derivation strategy for
this derivation.

For more information on the derivation of commitment items from the G/L account, see
Deriving Commitment Items from G/L Account.
Order completion confirmation and settlement

If you want to integrate the order completion confirmation (activity allocation) and
settlement transactions with FM, you must activate them in the Funds Management
Government IMG by choosing Actuals and Commitments Update Integration
Integration with Cost and Project Controlling Choose Business Transactions for
Integration.

Actuals activity allocation
(RKL)
Order settlement
(KOAO)

Process Flow
Creating the network/network activity

If the system can determine an FM account assignment from the derivation strategy, it
will appear as the default value.

If the system cannot determine an FM account assignment, you must enter one by
choosing Assignments Funds management.

The FM account assignment elements that you must enter depend on the field control.
SAP recommends that you set field control in such a way that you must enter the funds
center and, if necessary, the fund. In follow-on postings, the commitment item should be
derived automatically from either the G/L account or the cost element. If the commitment
item is derived from the cost element, this should ensure that the same commitment item
is assigned to the primary cost elements and to the settlement cost elements.

As long as the FM account assignment in a network/network activity is not complete
according to the field control, the order status HMKU (FM account assignment
incomplete) is active. This status prevents automatic generation of purchase requisitions
for components and services procured externally as well as releasing the order.
Processing the network

Procurement

If the system automatically triggers purchase requisitions, material reservations, or
goods issues by means of the network, the FM account assignment from the network is
automatically transferred for these business transactions. You cannot then change the
FM account assignment manually in these documents.

Completion confirmation

With the completion confirmation, the system transfers the FM account assignment from
the network/network activity for the debit posting.

Network settlement

With settlement, the system uses the FM account assignment from the network for the
credit posting.

1.3.1 Campaign Method

Phase 1

Get Sources of Information or data
Staff Observations
Collect Client Complaints or Comments
Market Research
Define the Market, Differentiate Market Niches
Competitor Activities Information
The New Product Development Process