SAP Form Functional Specification ZFSD__F_

ZFSD_Billing_01_Customer Invoice.docx

SAP Form Functional Specification ZFSD_Billing_F003_ Intercompany_InvoiceProspector Offshore Drilling

Table of Contents

1OBJECT REQUIREMENTS SUMMARY41.1Object Information and Attributes41.2Requirements Summary and Business Driver41.3Assumptions51.4Current Functionality51.5Required Functionality51.6Project / Development Constraints61.7Performance Criteria61.8Other Objects Affected61.9External References71.10Definitions/Acronyms/Abbreviations7

2FORM DESIGN DETAILED SPECIFICATIONS7

2.2 Data Selection-Screen / Criteria:72.3 Form Output Layout:82.4 Form Other Information102.5 Printing / Media Requirements:112.6 Error Handling Method:122.7 Post Execution Notification Details:142.8 Process Log Details143.ADDITIONAL INFORMATION153.1 Unit Test Plan153.2 Information Security163.3Audit193.4Questions / Issues / Risks19

Business Process Organizational Structure

Process Owner

Original Author(s)

Current Revision Author(s)

VersionDateAuthor(s)Revision Notes

1.007/24/2012Channaveerswamy

2.009/07/2012ChannaveerswamyDescription corrections

OBJECT REQUIREMENTS SUMMARY

Object Information and Attributes

The following is current information about this object and document:

Object IDZFSD_SD_E_003_Intercompany Invoice

TitleThis form will be used by Prospector for printing the customer invoices in SAP.

Author(s)Channaveerswamy

Team Which Owns the ObjectSAP SD

System VersionECC 6.0

Development TypeForm

PriorityHigh

Estimated ComplexityMedium, From PRICEFW Justification

Link to Process FlowActual link to the associated Level 3 Process Flow(s) to maintain traceability.

FTM Team Validation RequiredMark this as Yes or No if FTM Process Team has to validate the follow-on financial process (triggers a financial posting) in SAP during Unit Test of this Object|_| Yes |_| No

Requirements Summary and Business Driver This document describes the design for processing Billing documents for Prospector. The main objective is to process billing and invoice output for Intercompany using billing document type ZIC. This form will be used by Prospector for printing the Intercompany invoices in SAP.

Billing is the final step in Intercompany sales order processing. During this process, the Intercompany sales order will be billed to the intercompany customer and invoices are created. The accounting documents are generated automatically. System has the ability to update the respective G/L accounts automatically after releasing to accounting. The billing process in SAP is controlled by billing document types ZIC.

The Intercompany service transactions, Intercompany STO delivery and billing will be processed thru sales and distribution and rest intercompany transactions will be covered in respective modules like FI & MM.

During this process, the Intercompany sales order will be billed to the Intercompany customer and invoices are created. The accounting documents are generated automatically.

The SAP system shall have the ability to print the Intercompany customer invoice as per the attached Layout and the table/field mapping.

Mandatory field values are: Item number, Description, Quantity, Rate per Unit, Total Amount.

Alternatives to Object

SAP Menu Path: VF01, VF02, VF03

Output Determination: V3 Billing

Output Type: ZRD2

Mode of Execution: Manual at the time of Invoice processing

Program Name: RLB_INVOICE

Layout Set Name: Intercompany Invoice

Impact of Implementation

All the Intercompany invoices, will be printed thru SAP system.

Impact of No Implementation

N.A

Assumptions All the Intercompany invoices will be already created in the system.

Current FunctionalityPresently Prospector prints the Intercompany invoice out of their legacy system. The format, layout and field mapping of the same is detailed in this document in the respective sections.

Required Functionality

This is a special billing type used for processing Intercompany Sales transactions. An intercompany sale transaction is when a sale occurs and the selling sales organization belongs to a different company code than that of the supplying plant (Rig). It represents the internal invoice used between the two company codes belonging to the same business.

In SAP, Prospector shall have the facility to print Intercompany Invoices in the format detailed in the document. The different Billing document type (ZIC Intercompany Invoice) will be configured in SAP.

Project / Development ConstraintsNone

Performance CriteriaDescription:Capture any system performance criteria and requirements that must be met. Note: add any additional performance considerations that arent captured in the following tables Please refer to the same section in Functional Specification for more details. Update this section based on Functional Specification.

Performance Requirements for Forms

Average Frequency: Every time when Intercompany Invoice is created, user needs to take printout of that.

Frequency per Peak:Every time when Intercompany Invoice is created, user needs to take printout of that.

Availability:/

Expected Average Response Time:

Expected Peak Response Time:

Other Objects AffectedDescription: In order to better understand the total impact of this Functional Specification, please describe other known related/impacted PRICEFW objects. It is important this step be done with reasonable thoroughness. Think carefully through both downstream impacts and upstream dependencies. Please discuss with your Architect and Technical Team Lead. Additionally, this should include impacts from both legacy and SAP perspectives.

ObjectImpact/Change Description

VF01 / VF02 / VF03

In addition List of the application areas being changed or affected by this design.

SAP SystemSAP ModuleImpact/Change Description

SDVF01 / VF02 / VF03 transactions

NON-SAP / Legacy SystemImpact/Change Description

N.AN.A

Dependencies:Before processing Intercompany Billing document, Intercompany Sales orders must be created / processed in the system.

Dependent Configuration:Maintaining output type condition master record (VV31) based on key combination will enable system to automatically select the output type.

External References

Document TitleAuthorAttachment / Links

NA

Definitions/Acronyms/AbbreviationsN.A

1 FORM DESIGN DETAILED SPECIFICATIONS

2.1 Detail Requirements:In this context, a form refers to a printed form and not an SAP screen. (Please mention SMARTFORM / SAPScript / Adobe Form.)

In this process for printing Customer Invoice we will be using Smart Form.2.2 Data Selection-Screen / Criteria:Describe the data selection screen / criteria if any.Field NameTable Field / Checkbox / Radio ButtonSelect-Option (S) or Parameter (P)Comments (Range, Single/Multiple Selection, Patterns, Mandatory, etc.)Validations (For Each Field if any)Default Value

VBELNVBAK-VBELNParameterSingle

2.3 Form Output Layout:Insert Pictorial view of form output. Also, mark each of the fields in the output with specific numbers and then mention the mapping of those fields to SAP fields for data retrieval / display.Moreover, include field layout, spacing, header/footer details. Indicate whether times should indicate local or system time. Also, include language requirements. and then provide the following mapping information. (Mandatory)

Number of the field on the attached Form LayoutTable NameField NameField DescriptionConditions / Data Retrieval LogicMaximum Number of Characters to print

2VBRK VBELNInvoice number 8 - Numeric

3VBRK FKDATInvoice Date

8 (MM/DD/YYYY)

4Billing dateFrom - To 8 (MM/DD/YYYY) 8 (MM/DD/YYYY)

5Payment due date

To be calculated as (Invoice date + No of days in Payment terms)8 (MM/DD/YYYY)

6VBRK ZTERMTerms Text -25 characters

8VBRK

ADDR1_DATA ADDR1_DATAADDR1_DATAADDR1_DATA

ADDR1_DATAADDR1_DATA

KUNRG

NAME1 STREET CITY1 POST_CODE1

REGION COUNTRYPayer customer master

NameStreetCityPostal code

RegionCountryPass the customer value /description from the table KNA1 and print it along with the customer numberCode: 8 NumericCust Address: 40 characters Alpha Numeric Text -25 charactersText -25 charactersText -20 characters 6 Numeric characters

Text -15 charactersText -15 characters

9VBFAVBELNContract # From table VBFA and get reference Sales order number. Again in table VBFA for this sales order number fetch the reference contract number8 Numeric

10VBRP WERKSDrilling Rig12 - Alpha Numeric characters

11VBAKBSTKDLocation / Well #12 - Alpha Numeric characters

12VBAKBSTKD_EOCSG number12 Numeric characters

13VBRPMATNRMaterial Code

10 characters numeric

14VBRPARKTXDescriptionText 50 characters

15VBRPFKIMGTotal hoursSystem shall print all line item quantity. If any line item is having 0 (ZERO) hour in the billing document then the item should be suppressed in the billing output.

i.e If VBRP_FKIMG EQ 0, then system must suppress in billing.5 characters numeric

16VBRPNETWRRate per unit8 characters numeric

17Amount8 characters numeric

18Total Amount Invoiced8 characters numeric

22VBBKText Object50 Characters

Additionally, mention the following:Is it a modification to standard form?(If yes, check the box)|_|

Is it complete new custom form development?(If yes, check the box)|_|

SAPScript / SMARTFORM / Adobe Form:(Mention the type of form)Smartform

SAPScript / SMARTFORM / Adobe Form Name:ZSDF_CUST_INVOICE

Output Type:ZRD0

Billing Document Type: ZIC Intercompany Invoice

Print Program Name:RLB_INVOICE

Standard Text:

Logo:(Attach as files)Prospector Logo to be printed on the left had top corner of the layout

Bar Codes (field names):Not required

Language translation constraints:(List languages to be considered for form development)Not required

Output Destination:(Check all that apply)|_| Hard Copy |_| EDI |_| FAX|_| Hard copy to a specific printer

Number of forms to print per run:1

IMG Configuration, if any:Will be done in configuration / master data

Menu Path to Generate Form:Tcode: NACE

2.4 Form Other Information

Form Processing RequirementsDescription: Identify the processing requirements for this form.Calculations / Transformations

Value to be DerivedBusiness Rules / Algorithm For This Transformation

Billed QuantityIf any line item is having 0 hour in the billing document then the item should be suppressed in the billing output

Company LogoStatutory

Company AddressShall print at footer of last page

Number of line items if exceedsIf number on line items exceeds, then shall flow to second / subsequent page.

Other Updates Performed During Processing Not Specified Above

Initiating EventUpdated InformationRules For Update

Description: Identify any additional requirements not captured above (e.g. unique printing requirements or other formatting considerations)Other Form Requirements (Not Specified Elsewhere in This Document)

NumberDescription of Requirement

1.

2.

2.5 Printing / Media Requirements:Output Device Name:(Mention the Output Device Name)LOCL Printer

Number of Copies:(Mention number of copies to be printed)

Spool Request Name:(Mention if any specific spool request name) NA

Print Immediately:(Check the box if yes)|_|

Delete after Output:(Check the box if yes)|_|

New Spool Request:(Check the box if yes)|_|

Close Spool Request:(Check the box if yes)|_|

Paper FormatPortrait

Paper SizeA 4

2.6 Error Handling Method:Describe the Error Handling Method that needs to be followed. Specify the following information wherever applicable.

List all the Exceptions. Specify if applicable.

Description:Solution Teams are responsible for the design of their functional error logs (i.e. detail, messages, frequency, types, format, etc) which will include procedures for error resolutions. Functional errors are defined as those which can occur as a result of normal application processing (e.g. user inputs a vendor which is not found in the vendor master, numeric field above a certain value, etc.). Technical errors are defined as those which can occur as a result of faults in the underlying infrastructure (e.g. out of disk space) and are automatically reported/handled as part of a runtime framework already in place for applications and interfaces.

Description: Identify known potential failure points.Failure Points

Possible Point Of FailureRules For Handling Failure

For maintenance, query input screen, validation check results in an exception that needs remediation.Force a message notification on the screen and force user to correct input data element.

For maintenance, query input screen, validation check result in an exception that needs to be notified and the user prompted for acceptance or correction of inputted data.Force a message notification on the screen as a warning, Recommend corrective action, Request correction action and prompt Yes/No. Based on the input, force user to correct data or accept input

For maintenance, query input screen, validation check result into an exception that needs to be notified to the user for information purposes.Force a message notification on the screen for information purposes.

For enhancements, reports, validation check result in an exception that needs remediationFor foreground processing on a single transaction, force an error message to be displayed on the screen and stop processing. For foreground processing on a dataset with multiple transactions, in the event of exceptions: Log error in a list to be displayed on the screen. Process rest of the validated transactions, if there is no adverse impact due to dependency between records in the data set. The Dependency and the impact need to be defined by the functional analyst. For background processing, the errors should be logged in a list, which can be viewed in the spool list in sm37 Simple Job Selection.

For enhancements, reports, validation check result into an exception which needs to be notified to the user for information purposes.For foreground processing on a single transaction, force an Information only message to be displayed on the screen and complete processing. For foreground processing on a dataset with multiple transactions, in the event of exceptions: Log warning/Information message in a list to be displayed on the screen. Process rest of the validated transactions, if there is no adverse impact due to dependency between records in the data set. The Dependency and the impact need to be defined by the functional analyst.For background processing, the Warning/Information should be logged in a list, which can be viewed in the spool list in sm37 Simple Job Selection.

Description: The procedure is to work through the Workflow Process Steps & Description of Activities locating validation activities and inserting documentation on how to handle each possible functional error. Every validation point must include directions for:Error Handling Requirements

Information NeededDescription

Error DetectionRange check validation errors on screen inputs will be logged on the screen input via message notification. For forms used for processing, reporting, Error List will be directed to spool output and an email notification will be sent.

Error NotificationFor screen inputs, the notification will be via message display on the screen. For Forms used in processing and reporting, error notification will be accomplished via an Email. Error List will be available as spool output that can be accessed from sm37

Error Logging (beyond notification)Pleased provide Function Mail Group that will need email notification and member list of the mail group

Error Remediation

2.7 Post Execution Notification Details:Describe the Post Execution Notification Method that needs to be followed. Specify the following information wherever applicable.

2.8 Process Log DetailsDescribe whether the output needs to be written to an application log or spool. Specify the following information wherever applicable.

Print in Portrait form.

3. ADDITIONAL INFORMATION

3.1 Unit Test PlanDescription:The Solution Team member will utilize this section to document unique test requirements. This is an input to the development team in order to carry out the unit testing. The Solution Team member will identify any unique scenarios and business transactions for the object to be tested and identify the test data requirements. Although not part of the Functional Specification, the Solution Team member is also responsible for creation and maintenance of the unit test data required to support the unit test cases

The Unit test plan will be updated in the Realization Phase during the technical specification Design.

Identify the Test Scenario to be used to test the development with:

Test ConsiderationsScope of Testing (Inside SAP (IS) / Outside SAP (OS) / Both (BO))Target Test Date

MM-DD-YY

3.2 Information SecurityDescription:Provide details according to Functional Specification.

3.2.1 Information ClassificationGeneral Information

Businesses Impacted:

Information Classified by whom:Date

Contact Information

CompanyNamePhoneE-mail Address

List PotentialInformation Owners:Prospector

Architecture

Environments: (impacted by this T spec): |_| Development |_| Test |_| Training |_| Production

Architecture: (system exposure):|_| Public (Internet) Facing |_| Internal Only|_| 3rd Party Hosted |_| Company * Hosted

Identity & Access Management

During Project3rd party system access required?|_| Yes|_| NoOffshore?|_| Yes|_| NoList the 3rd Parties:

Post Implementation3rd party system access required?|_| Yes|_| NoOffshore?|_| Yes|_| NoList the 3rd Parties:

Business Impact Analysis

What may be impacted if the system or information/data is compromised? Check all that may apply.

|_| Brand Reputation/Trust|_| Associate Relations|_| Competitive Advantage|_| Financial Impact|_| Productivity|_| Supply Chain|_| Contractual (i.e. NDAs, MSAs)

|_| Regulatory|_| Compliance|_| Securities & Exchange Commission (SEC)|_| Payment Card Industry (PCI)|_| Sarbanes-Oxley (SOX)|_| Privacy Laws

Input any additional details related to business impact in the event of compromise:

Information Classification

Action #1: Check the box below that represents the most restrictive classification.Action #2: If Level 1 or 2 is selected, check the box below indicating data storage or data transmission.

See Information Classification, Labelling and Handling in [Clients]s ISC Standards for details on the formal classifications and data handling standards.

|_| Level 1 Confidential Secure Handling Required SHR

Confidential Secure Handling Required represents the most sensitive data classification related to individual personal identifiable information and personal financial account information. This information considered critical to [Clients] such that, if disclosed, may disrupt or impede business operations, and due to legal, reputational, or operational concerns, requires additional security controls. Information in this category includes, but is not limited to: 1. Social Security Number 2. Drivers License Number or Government-issued Identification Number 3. Financial Account Number (card number or personal bank number) 4. Protected Health Information & Electronic Protected Health Information

|_| SHR data stored? |_| SHR data transmitted? |_| SHR data stored and transmitted?

|_| Level 2 Confidential

Confidential represents the second most sensitive data classification related to operationally significant business information. This information considered critical to [Clients] such that, if disclosed, may disrupt or impede business operations. Examples of Restricted Confidential include but are not limited to regulatory governed data, trade secrets, mergers and acquisition discussions, product formulas and designs, corporate earnings data prior to public announcements, reorganization details prior to announcements, current/closed company investigations and litigation, detailed network diagrams that could jeopardize network security, strategic development/marketing plans and information integral to the success and operations of the company.

|_| Confidential data stored? |_| Confidential data transmitted? |_| Confidential data stored and transmitted?

|_| Level 3 Internal [Clients] Use Only

Internal [Clients] Use Only represents the third most data. It represents information that is less critical to privacy and business operations but still must not be publicly disclosed. This information is not approved for general circulation outside [Clients].

|_| Level 4 - Public

Public represents information that has been declared public knowledge by the information owner and can freely be given to anyone without any possible impact to [Clients]. As a result, no special data handling protections are required.

3.2.2 Security Roles (Profiles and Authorizations)Define the general security administration for this design as per Functional Specification. This section should define the general security administration for this design. Security roles, profiles and authorizations will be finalized later other Workshops. Define the general security for this design including any organizational level restrictions required (e.g. report should be available for [Client].Com only). List a Standard TCode/Report/Object that most resembles the custom development. Outline general authorization checks for special reports and/or enhancements due to data classifications and any other special security considerations.

Please assign role defined in FDD for performing the activity/task using the form, report, enhancement, portal and interface object. Please collaborate with the security team to fill the document. Security Requirements for Workflow

Security TypeRoleAccess Allowed

Screen Level Security

VF02 / VF03

Field Level Security

Button Security

Data Security

This section should define the security requirements for this design. Once all required security checks have been incorporated into the ABAP/4 program, they must be tested and signed off by the Security Administration.

3.2.2.1 Table Security (if applicable)If new table needs to be created to support the business application, the custom table need to be assigned to authorization group for access protect. Please work with Security team to get the proper authorization group information. Custom TableAuthorization Group

3.2.2.2 ABAP Program Security (if applicable)The two different types of authorisation checks used to ensure appropriate data security are:Value

Authorization Group Check

Authorization Check

Specify what transaction code should be assigned to users so that they can execute this Workflow.Transaction Code

Define by Process Step, which Business Process Roles will be required to execute this Workflow.Process StepBusiness Process Role

If data access or functionality should be controlled via authorizations, please describe the restriction requirement for each data set or functionality in the table below. Data set / FunctionalityDescribe what authorization a User must be assigned to access the data set or functionality

3.3 AuditThis section should define any audit solution for this design. Transactional data and changes to master data within the SAP application are captured by standard SAP in the CDHDR table. If there are additional requirements to capture audit history on new custom tables defined for fulfilling the functional requirements in this FSPEC, please specify the same. The name of the custom tables and the detailed design would be described in the Realization Phase of the project in the technical specs.

Audit Trail Requirements

Audit EventDescriptionAudit Trail Updates

3.4 Questions / Issues / Risks

Questions/Issues/Risks

Asked ByQuestion/Issue/RisksResolutionResolution Date

Copyright 2012. Capgemini U.S. LLC. All rights reserved.

Copyright 2012. Capgemini U.S. LLC. All rights reserved. Page 19

InvoiceForm Reference #Form FieldForm Field DescriptionSAP Table and FieldSpecial Considerations1LogoHNAWill be preprinted on the stationary2Invoice #HInvoice number from SAPVBRK - VBELN3Invoice DateHInvoice creation dateVBRK - FKDAT4Billing PeriodHFrom - To billing periodNA5Due DateHPayment due dateTo be calculated as (Invoice date + No of days in Payment terms)6TermsHPayment termsVBRK - ZTERM7InvoiceHNAF2 - Customer Invoice8Customer # Description & AddressHVBRK - KUNRGFor this value find out description from the table KNA1 and print it along with the customer number9Contract #HVBFAFor invoice # go to table VBFA and get reference Sales order number. Again in table VBFA for this sales order number fetch the reference contract number10Drilling RigHVBRP _WERKSThis has to be printed on invoice header but the field actually has to be taken from line item level in the invoice document11Location / Well numberHVBAK_BSTKDFor getting this value pass the invoice number and derive the sales order number from the VBFA table. For this sales order number look up the table VBAK and get the value in the field BSTKD12OCSG numberHVBAK_BSTKD_EFor getting this value pass the invoice number and derive Sales Order number from the VBFA table. For this sales order number lookup the table "VBKD" and fetch the value from the field "BSTKD_D"13DateIVBRP_FBUDAservice rendered date14Material # and descriptionIVBRP_MATNR VBRP_ARKTX15QuantityIVBRP_FKIMG16Rate per unitIVBRP _NETWR17AmountIQuantity * Rate Per Unit18Total AmountITotal of amounts for all the line items19Prospector Bank DetailsINAWill be preprinted on the invoice format20Prospector AddressFooterNAWill be preprinted on the invoice format21Telephone and Fax details for ProspectorFooterNAWill be preprinted on the invoice format22Text InformationIText Object VBBKWill print after Total Amount Value

Sheet1DayMaterial code and DescriptionHours / DayRate per UnitAmount03/01/201210002 Operation Drilling2410002400003/02/201210002 Operation Drilling10500500003/02/201210002 Operation Drilling12600720003/02/201210003 Down time billable220040003/03/201210002 Operation Drilling1010001000003/03/201210002 Operation Drilling1410001400003/04/201210003 Down time billable10500500003/04/201210002 Operation Drilling12600720003/04/201210002 Operation Drilling220040003/05/201210002 Operation Drilling2412002880003/06/201210002 Operation Drilling2410002400003/07/201210002 Operation Drilling03/08/201210002 Operation Drilling03/09/201203/10/201203/11/201203/12/201203/13/201203/14/201203/15/201203/16/201203/17/201203/18/201203/19/201203/20/2012

Sheet2

2345678910111213141516171

192120Header Text Information

2218

Form Unit Test Specifications

Form Name:

Date Of Test:

Tester:

Approval:

[Note: It is intended that this template is followed for all new Forms that are developed as part of the SCORE system. A copy of this template should be created. The tester is then instructed to hand-complete all sections of this template and store the document as evidence that the required testing has been performed.]

TestCaseUnit TestConfirmation /Defect Form

1Print a copy of the Form. Do the following for the Form:

1.1Confirm that the Form matches the Form layout given in the Form Specification Document.

1.2Confirm that the header, footer, subtotals, and body of the Form match the layout given in the Form Specification Document.

1.3Confirm that the Screen Type matches the Screen Type given in Form Specification Document

2Review the Form Specification Document to determine all of the fields on the Form. Make a list of each of these fields below. Repeat test cases 2.1 through 2.14 for each field on the Form. Check each of these test cases for the first, last, and several intermediate lines on the Form. Repeat these test cases on the first and last page of the Form as well.

Enter Field Checked Here:

Enter Field Checked Here:

Enter Field Checked Here:

Enter Field Checked Here:

Enter Field Checked Here:

Enter Field Checked Here:

Enter Field Checked Here:

Enter Field Checked Here:

Enter Field Checked Here:

2.1Confirm that the Field Label matches the label as shown on the Form Specification Document.

2.2Confirm that this Field Label is spelled correctly.

2.3Confirm that the Data Type matches the Characteristics for the field in the Field Definition section of the Form Specification Document.

2.4If the Data Type is Numeric, confirm that the field is right justified, properly displays numeric values including all specified decimal places and commas, and that leading zeroes are not displayed.

2.5If the Data Type is Alphanumeric, confirm that the field is left justified.

2.6If the field has any other special characters (such as in dates, phone numbers, or social security numbers), confirm that they are printed as is shown in the Form Specification Document.

2.7Confirm that the field length is the same number of characters/digits specified in the Form Specification Document by creating transactions for the Form that have the same, fewer, and one more number of digits/characters specified in the Characteristics section. (Note: if the source field is the same size as the field on the Form, simply fill the source field.)

2.8Confirm that the field is formatted correctly as it is in the Form Design and Field Definitions sections.

2.9If the Field Description states that the field is to show a specific value, confirm that the value shown matches the specifications given in the Field Definitions.

2.10Fill the field to its maximum size with valid data (per the Form Specification). Save the form and redisplay the form. Confirm that all digits or characters entered are saved and displayed again on the form.

2.11Enter data that is consistent with and inconsistent with each of the edits outlined in the Form Specification Document. Confirm that each of these edits work in a representative sample of both positive and negative test cases. Also confirm that the error message specified in the Form Specification is displayed.

2.12If the Field Description states that the field is to be calculated or transformed in some way, confirm that it is calculated or transformed as specified in the Form Specification Document.

2.13If the Field Description states that the field is to be display a source value, print the source file and confirm that the field is correctly displayed.

2.14Confirm that the system properly handles missing or invalid data as specified in the Form Specification Document.

2.15Confirm that the proper data is displayed in the field as specified in the Form Specification Document. If different data may display depending on certain business conditions, confirm that the proper information is displayed under each of these conditions. Check this using the first, last, and a middle record in the database.

2.16Confirm that the field properly handles instances in which the data is missing from the system as is specified in the Form Specification Document.

3Review the Form Specifications Document to get a list of all of the Events in the Event Action Matrix. Make a list of each of those events below. Confirm that the Action specified for that event occurs each time that event occurs.

Enter Event Here:

Enter Event Here:

Enter Event Here:

Enter Event Here:

Enter Event Here:

Enter Event Here:

4Confirm that the Form formatting works as specified in the Form Specification Document as follows:

4.1Confirm that the Form is sorted as specified in the Form Specification Document.

4.2If sortable columns are specified in the Form Specification Document, confirm that the columns are sorted as specified in the Form Specification Document.

5Number each of the calculations outlined in the Form Specification Document. Confirm that each of the calculations outlined in the Form Specification Document are performed as outlined in the Form Specification Document. Repeat this test with various values to confirm that the calculations are performed correctly in all instances.

Calculation # 1:

Calculation # 2:

Calculation # 3:

6Confirm that the security for the Form operates as specified in the Form Specification Document, as follows:

6.1If any Button Exclusions Based On Security are specified in the Form Specifications Document, confirm that the buttons are only displayed per the specifications outlined in the Form Specifications Document. Display the form with profiles that match the Button Exclusions and do not match the Button Exclusions. Confirm that the buttons are displayed as specified in the Form Specifications Document in all of these instances.

6.2Log-in using a user with each of the profiles specified in the Security section of the Form Specification Document. Confirm that the user is allowed to either update the Form or access the Form as specified in the Form Specification Document.

6.3Log-in using a user with a profile not specified in the Security section of the Form Specifications Document. Confirm that this user is not allowed to access or update the Form. Repeat this test with at least 3 different profiles not specified in the Form Specifications Document.

6.4 Add another security profile that should allow access to the Form that matches one of the profiles that were just rejected above. Confirm that a user with that profile can now view or update the Form.

6.5 Delete the security profile that was added above Confirm that a user with that profile can no longer view and/or update the Form.

6.6 If Data Security is specified in the Form Specification, log-into the system using a user that has each of the profiles specified in the Form Specifications Document. For each of these profiles, confirm that the user can access data per the rules outlined in the Form Specification Document. Select various data that the user should not be able to access per the Form Specification Document and confirm that this data is not displayed for the user. Confirm that no data is displayed for at least 3 profiles that have profiles that are not specified in the Form Specifications Document.

6.7 If Field Level Security is specified in the Form Specification, log into the system using a user that has each of the profiles specified in the Form Specifications. For each of these profiles, confirm that each of the fields on the form can only be accessed as specified in the Field Level Security section of the Form Specifications. Confirm that the restricted fields are not keyable (or displayed) as specified in the Form Specification Document and that the other fields that are normally keyable (as specified in the Form Specification Document) are keyable.

7If the Form Specification Document indicates that any updates are to be performed, do the following for each of the updates specified. Repeat these tests for several transactions on the Form including the first and last transaction on the first and last page as well as several intermediate transactions.

7.1 Confirm that the insert logic, if any, works as specified in the Form Specification Document. Check this using the first, last, and a middle record in the database.

7.2 Confirm that the update logic, if any, works as specified in the Form Specification Document. Check this using the first, last, and a middle record in the database.

7.3 Confirm that the delete logic, if any, works as specified in the Form Specification Document. Check this using the first, last, and a middle record in the database.

8Confirm that each of the Special Processing Rules works as specified in the Form Specifications Document, as follows:

8.1If any Performance Requirement is specified in the Performance Requirement Section of the Form test the Form for the Expected Average Response Time and verify it is less than the value specified in the Form Specification Document.

8.2Confirm that the Form can be rerun and will display the same information if it is run twice using the same Event/Parameters.

8.3Run the Form with no transactions. Confirm that the Form will process successfully and will display a blank Form.

8.4Confirm that the Control Form (if specified in the Form Specification Document) is displayed as specified in the Form Specification Document.

8.5If any requirements are given in the Other Requirements section of the Form Specifications Document, execute both positive and negative tests to confirm that each of the Other Requirements work as specified in the Form Specifications Document.

Unit Test PlanTEST CONSIDERATIONS (Technical)1. TEST CASE CONSIDERATIONSObject / WRICEF ID:Test Contact:Object / WRICEF DescriptionApprover:Server/ Client2. UNIT TEST CASE DETAILS (include Positive and Negative Test Scenarios)FUNCTIONAL TEAM NOTESDEVELOPER NOTESTEST CONSIDERATIONTEST EXECUTION RESULTSSTEPSTEP DESCRIPTION/ TEST CONDITIONEXPECTED RESULTACTUAL RESULTPASS / FAILTECHNICAL TESTER1Total AmountSummation of all line items value.2Customer code and addresscustomer code and address3Check Contract noContract No4Layout and marginsShould be in line and length

Detailed Report for FormsTest CaseUnit TestConfirmation/Defect Form1Print a copy of the Form. Do the following for the Form:1.1Confirm that the Form matches the Form layout given in the Form Specification Document.1.2Confirm that the header, footer, subtotals, and body of the Form match the layout given in the Form Specification Document.1.3Confirm that the Screen Type matches the Screen Type given in Form Specification Document2Review the Form Specification Document to determine all of the fields on the Form. Make a list of each of these fields below. Repeat test cases 2.1 through 2.14 for each field on the Form. Check each of these test cases for the first, last, and several intermediate lines on the Form. Repeat these test cases on the first and last page of the Form as well.Enter Field Checked HereEnter Field Checked HereEnter Field Checked HereEnter Field Checked HereEnter Field Checked HereEnter Field Checked HereEnter Field Checked HereEnter Field Checked HereEnter Field Checked Here2.1Confirm that the Field Label matches the label as shown on the Form Specification Document.2.2Confirm that this Field Label is spelled correctly.2.3Confirm that the Data Type matches the Characteristics for the field in the Field Definition section of the Form Specification Document.2.4If the Data Type is Numeric, confirm that the field is right justified, properly displays numeric values including all specified decimal places and commas, and that leading zeroes are not displayed.2.5If the Data Type is Alphanumeric, confirm that the field is left justified.2.6If the field has any other special characters (such as in dates, phone numbers, or social security numbers), confirm that they are printed as is shown in the Form Specification Document.2.7Confirm that the field length is the same number of characters/digits specified in the Form Specification Document by creating transactions for the Form that have the same, fewer, and one more number of digits/characters specified in the Characteristics section. (Note: if the source field is the same size as the field on the Form, simply fill the source field.)2.8Confirm that the field is formatted correctly as it is in the Form Design and Field Definitions sections.2.9If the Field Description states that the field is to show a specific value, confirm that the value shown matches the specifications given in the Field Definitions.2.1Fill the field to its maximum size with valid data (per the Form Specification). Save the form and redisplay the form. Confirm that all digits or characters entered are saved and displayed again on the form.2.11Enter data that is consistent with and inconsistent with each of the edits outlined in the Form Specification Document. Confirm that each of these edits work in a representative sample of both positive and negative test cases. Also confirm that the error message specified in the Form Specification is displayed.2.12If the Field Description states that the field is to be calculated or transformed in some way, confirm that it is calculated or transformed as specified in the Form Specification Document.2.13If the Field Description states that the field is to be display a source value, print the source file and confirm that the field is correctly displayed.2.14Confirm that the system properly handles missing or invalid data as specified in the Form Specification Document.2.15Confirm that the proper data is displayed in the field as specified in the Form Specification Document. If different data may display depending on certain business conditions, confirm that the proper information is displayed under each of these conditions. Check this using the first, last, and a middle record in the database.2.16Confirm that the field properly handles instances in which the data is missing from the system as is specified in the Form Specification Document.3Review the Form Specifications Document to get a list of all of the Events in the Event Action Matrix. Make a list of each of those events below. Confirm that the Action specified for that event occurs each time that event occurs.Enter Event HereEnter Event HereEnter Event HereEnter Event HereEnter Event HereEnter Event Here4Confirm that the Form formatting works as specified in the Form Specification Document as follows:4.1Confirm that the Form is sorted as specified in the Form Specification Document.4.2If sortable columns are specified in the Form Specification Document, confirm that the columns are sorted as specified in the Form Specification Document.5Number each of the calculations outlined in the Form Specification Document. Confirm that each of the calculations outlined in the Form Specification Document are performed as outlined in the Form Specification Document. Repeat this test with various values to confirm that the calculations are performed correctly in all instances.Calculation 1Calculation 2Calculation 36Confirm that the security for the Form operates as specified in the Form Specification Document, as follows:6.1If any Button Exclusions Based On Security are specified in the Form Specifications Document, confirm that the buttons are only displayed per the specifications outlined in the Form Specifications Document. Display the form with profiles that match the Button Exclusions and do not match the Button Exclusions. Confirm that the buttons are displayed as specified in the Form Specifications Document in all of these instances.6.2Log-in using a user with each of the profiles specified in the Security section of the Form Specification Document. Confirm that the user is allowed to either update the Form or access the Form as specified in the Form Specification Document.6.3Log-in using a user with a profile not specified in the Security section of the Form Specifications Document. Confirm that this user is not allowed to access or update the Form. Repeat this test with at least 3 different profiles not specified in the Form Specifications Document.6.4Add another security profile that should allow access to the Form that matches one of the profiles that were just rejected above. Confirm that a user with that profile can now view or update the Form.6.5Delete the security profile that was added above Confirm that a user with that profile can no longer view and/or update the Form.6.6If Data Security is specified in the Form Specification, log-into the system using a user that has each of the profiles specified in the Form Specifications Document. For each of these profiles, confirm that the user can access data per the rules outlined in the Form Specification Document. Select various data that the user should not be able to access per the Form Specification Document and confirm that this data is not displayed for the user. Confirm that no data is displayed for at least 3 profiles that have profiles that are not specified in the Form Specifications Document.6.7If Field Level Security is specified in the Form Specification, log into the system using a user that has each of the profiles specified in the Form Specifications. For each of these profiles, confirm that each of the fields on the form can only be accessed as specified in the Field Level Security section of the Form Specifications. Confirm that the restricted fields are not keyable (or displayed) as specified in the Form Specification Document and that the other fields that are normally keyable (as specified in the Form Specification Document) are keyable.7If the Form Specification Document indicates that any updates are to be performed, do the following for each of the updates specified. Repeat these tests for several transactions on the Form including the first and last transaction on the first and last page as well as several intermediate transactions.7.1Confirm that the insert logic, if any, works as specified in the Form Specification Document. Check this using the first, last, and a middle record in the database.7.2Confirm that the update logic, if any, works as specified in the Form Specification Document. Check this using the first, last, and a middle record in the database.7.3Confirm that the delete logic, if any, works as specified in the Form Specification Document. Check this using the first, last, and a middle record in the database.8Confirm that each of the Special Processing Rules works as specified in the Form Specifications Document, as follows:8.1If any Performance Requirement is specified in the Performance Requirement Section of the Form test the Form for the Expected Average Response Time and verify it is less than the value specified in the Form Specification Document.8.2Confirm that the Form can be rerun and will display the same information if it is run twice using the same Event/Parameters.8.3Run the Form with no transactions. Confirm that the Form will process successfully and will display a blank Form.8.4Confirm that the Control Form (if specified in the Form Specification Document) is displayed as specified in the Form Specification Document.8.5If any requirements are given in the Other Requirements section of the Form Specifications Document, execute both positive and negative tests to confirm that each of the Other Requirements work as specified in the Form Specifications Document.