SAP Form Functional Specification ZFSD_Cr/Dr_F002_Credit / Debit Memo Form

ZFSD_Cr/Dr_04_Credit/Debitmemoform.doc

SAP Form Functional Specification ZFSD_Cr/Dr_F002_Credit / Debit Memo FormProspector Offshore Drilling

Table of Contents

1OBJECT REQUIREMENTS SUMMARY41.1Object Information and Attributes41.2Requirements Summary and Business Driver41.3Assumptions41.4Current Functionality41.5Required Functionality51.6Project / Development Constraints51.7Performance Criteria51.8Other Objects Affected51.9External References61.10Definitions/Acronyms/Abbreviations62FORM DESIGN DETAILED SPECIFICATIONS82.1 Detail Requirements:82.2Data Selection-Screen / Criteria:82.3Form Output Layout:82.4Form Other Information92.5Printing / Media Requirements:102.6Error Handling Method:112.7Post Execution Notification Details:142.8Process Log Details143ADDITIONAL INFORMATION143.1Unit Test Plan143.2Information Security163.3Audit193.4Questions / Issues / Risks19

Business Process Organizational StructureSales & Distribution

Process Owner

Original Author(s)

Current Revision Author(s)

VersionDateAuthor(s)Revision Notes

1.007/24/2012Channaveerswamy Wodeyar

2.009/07/2012Channaveerswamy WodeyarDescription changes

OBJECT REQUIREMENTS SUMMARY

Object Information and Attributes

The following is current information about this object and document:

Object IDZFSD_SD_004_Credit/Debit memo Form

TitleCredit / Debit Invoice Memo Form

Author(s)Channaveerswamy Wodeyar

Team Which Owns the ObjectSAP, SD

System VersionECC 6.0 EPH 4

Development TypeForm

PriorityMedium

Estimated Complexity Medium, 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 DriverThis document describes the design for processing Credit/Debit memo invoices for Prospector customer. If a customer refund has to be processed against the invoice or if a customer has been charged for incorrect invoice or charged less in the invoice then Prospector will use this form (Credit/Debit memo) to correct this accounting entry. This form will be used by Prospector for printing the credit or debit memo invoices in SAP for customer.

This is the final step in credit/debit memo invoice creation. During this process, the Credit or Debit memo request is created in the system SAP. This document will be blocked for accounting. Once the Credit / Debit Memo request is approved by the Rig/ Country manager on paper, then the Operations accounting department will remove the block for accounting, and the credit/debit memo will be generated in the system. The different Billing document types (G2/L2) will be configured in SAP. The debit / credit memo (billing document) will be printed thru SAP.

Alternatives to Object

Impact of Implementation

All the Credit/Debit memo invoices, will be printed thru SAP system

Impact of No Implementation

N.A

AssumptionsCredit / Debit memo are already processed in the system.

Current FunctionalityPresently, Prospector is manually handling this process and print the credit/debit memo invoice out of their legacy system.

Required Functionality

During this process, the Credit or debit memo request is created in the SAP system. This document will be blocked for accounting. Once the Credit / Debit Memo request is approved by the Rig/ Country manager on paper, then the Operations accounting department will remove the block for accounting and the credit/debit memo will be generated in the system. The different Billing document types (G2/L2) will be configured in SAP.

In SAP, Prospector should have the facility to printout Debit / credit memo document in the format detailed in the document.

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 credit/debit memo invoice is created, user needs to take printout of that.

Frequency per Peak:Every time when credit/debit memo invoice is created, user needs to take printout of that.

Availability:24/7All the time

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

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

SAP SystemSAP ModuleImpact/Change Description

ECC 6.0SDVF01/VF02/VF03

NON-SAP / Legacy SystemImpact/Change Description

N.A

Dependencies: Credit/Debit memo request is to be created. This request will be blocked for accounting and that can be released only by authorised person. Only after release user will be able to process it and create credit / debit memo invoices.

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

External References

List of all the external references.Document TitleAuthorAttachment / Links

N.A

Definitions/Acronyms/AbbreviationsList of all the definitions /acronyms /abbreviations used within the document.

FORM DESIGN DETAILED SPECIFICATIONS

1.1 Detail Requirements:

In this process for printing Credit/debit memo invoice we will be using Smart Form.

1. 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

1. 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

9VBRP WERKSDrilling Rig12 - Alpha Numeric characters

10VBAKBSTKDLocation / Well #12 - Alpha Numeric characters

11VBAKBSTKD_EOCSG number12 Numeric characters

12VBRPFBUDADateService rendered date 8 (MM/DD/YYYY)

13VBRP

MATNR

Material Code

10 characters numeric

14VBRPARKTXDescriptionText 50 characters

15VBRPFKIMGTotal hours5 characters numeric

16VBRPNETWRRate per Hour8 characters numeric

17Amount8 characters numeric

18Total Amount8 characters numeric

22VBBKText Object50 Characters

Field mapping and credit invoice template is attached.

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_Cr_Dr_INVOICE

Output Type:ZRD1

Billing document typeL2 / G 2

Print Program Name:SD_INVOICE_PRINT01

Standard Text:Allowed

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

1.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

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.

1.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)N.A

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

1.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

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

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

ADDITIONAL INFORMATION

1.9 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

1.10

1. 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:

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

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 18

2345678910111213141516171

Header Text Information

1819202122Sheet1Form 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 periodNAFor US it is twice a month like billing periods will be from 1st of every month to 15th of every month 2nd will be from 16th of every month to last day of the month5Due DateHPayment due dateTo be calculated as (Invoice date + No of days in Payment terms)6TermsHPayment termsVBRK - ZTERM7Credit/Debit InvoiceHNAFor invoice type G2 - Credit Invoiceand for L2 - Debit Memo8Customer # Description & AddressHVBRK - KUNRG For this value find out description from the table KNA1 and print it along with the customer numberADDR1_DATA -NAME1NameADDR1_DATA-STREETStreetADDR1_DATA-CITY1CityADDR1_DATA-POST_CODE1Postal codeADDR1_DATA-REGIONRegionADDR1_DATA-COUNTRYCountry9Drilling RigHVBRP _WERKSThis has to be printed on invoice header but the field actually has to be taken from line item level in the invoice document10Location / Well numberHVBAK_BSTKDFor getting this value take 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 BSTKD11OCSG numberHVBKD_BSTKD_EFor getting this value take the invoice number and derive SO number from the VBFA table for this invoice number. For this sales order number lookup the table "VBKD" and fetch the value from the field "BSTKD_D"12DateIVBRP_FBUDA13Material CodeIVBRP_ARKTX

14DescriptionIVBRP_MATNR15Total hoursIVBRP_FKIMG16Rate per unitI17AmountIQuantity * Rate Per Unit18Total Amount InvoicedITotal of amounts for all the line items19Prospector Bank DetailsINAWill be preprinted on the invoice format20Prospector AddressFooterNAWill be preprinted on the invoice format21Telefone and Fax details for ProspectorFooterNAWill be preprinted on the invoice format22Header Text InformationText Object , Character 50

Sheet2

Sheet3

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 TESTER1Test for margin and layout2Customer code and description3Material code and description4Payment terms5Net and Total Amount

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.