Forms Definition Document

SAP Adobe Forms: Credit /Debit Memo(MX)

Author:Kranthi Gurram Project: Fast Track Version: 1.0

Document History
Document Location
This is a snapshot of an on-line document. Paper copies are valid only on the day they are printed. Refer to the author if you are in any doubt about the currency of this document.

Revision History
Date of this revision: 16.02.2011 Revision Revision Summary of Changes Number Date 1 16.02.2011 Initial Date of next revision (date) Revised By Kranthi Gurram

Approvals
This document requires the following approvals: Name Kranthi Gurram Title Functional Realization Date

Distribution
This document has been distributed to: Name Title

Form Definition Document (FDD) Kranthi Gurram

Page 2

04-Oct-13

Kranthi Gurram

OTC Business Analyst

Form Definition Document (FDD) Kranthi Gurram

Page 3

04-Oct-13

Contents
1.1 Identification....................................................................................................................................... 5 1.2 Document Information........................................................................................................................ 6 1.3 Design Considerations....................................................................................................................... 7 1.4 Prerequisites ..................................................................................................................................... 8 1.5 Inputs and Dependencies................................................................................................................... 9

2. Forms Definition Details...............................................................................................10

2.1 Description....................................................................................................................................... 10 2.2 Forms Specification Details.............................................................................................................. 11 2.3 Forms Example................................................................................................................................ 11 2.4 Solution:........................................................................................................................................... 12

3. Test Case.....................................................................................................................14 4. Technical Design Document........................................................................................20

Form Definition Document (FDD) Kranthi Gurram

Page 4

04-Oct-13

Forms Narrative
This form depicts the Credit/Debit memo print output that will be created after the Credit/Debit memo has been created in SAP. This out put will be processed after the Credit/Debit memo is completed in all the respect and ready to be sent out to Customer as a memo print out. The output will be created via Manual processing (Individual Memo). The onus of creating this printout lies with the creator or the modifier of the memos( Customer Services manager and A/R Supervisor) Based on this memo output either customer is going to send us the cash (for Debit Memo) or we are going to pay them (for Credit Memo) or they take a deductions from their payment to us (For Credit Memo) For Your Knowledge for Credit / Debit Memo in SAP: Credit memo request is a sales document used in complaints processing to request a credit memo for a customer. If the price calculated for the customer is too high, for example, because the wrong scale prices were used or a discount was forgotten, you can create a credit memo request. The credit memo request is blocked for further processing so that it can be checked. If the request is approved, you can remove the block. The system uses the credit memo request to create a credit memo. Debit memo request is a sales document used in complaints processing to request a debit memo for a customer. If the prices calculated for the customer were too low, for example, calculated with the wrong scaled prices, you can create a debit memo request. The debit memo request can be blocked so that it can be checked. When it has been approved, you can remove the block. It is like a standard order. The system uses the debit memo request to create a debit memo

1.1

Identification

Form is prepared By Kranthi Gurram for Abode developers: All the very best

Form Definition Document (FDD) Kranthi Gurram

Page 5

04-Oct-13

1.2

Document Information

Title:

Adobe forms_V01_Credit/ Debit memo(MX) Release 1

Date:

02.16.2011

Implementation Release: Brief Description:

Standard Credit/Debit memo:-LB_BIL_INVOICE

Document Type: Priority: Team: Development Team Contact: Developer: Specification Author: Status: Category: Priority Complexity: Duration of Development Work (days): Is there an alternative in the standard system?

Functional Spec (FS) High/mandatory Sales and Distribution Kranthi Gurram Input High Complex 6 Days Yes No Output Medium Average Computerized Low Simple Manual Medium/recommended Low/optional

Form Definition Document (FDD) Kranthi Gurram

Page 6

04-Oct-13

Description of alternative: Reason(s) why alternative is not acceptable: Development Labor Estimate:

Generic Standard Credit/Debit memo Out put Standard Credit/Debit memo will not cater the need of YARMEX legal and Business requirement. 6 Days 48 Hours

Planned Start Date: Actual Start Date:

Planned End Date: Actual End Date:

Project cost: Cost approved by: Date of project 02.16.2011 management approval:

Charge cost to: Date of steering committee approval:

1.3

Design Considerations None

Release 1 Fasttrak Debit/Credit memo

Open Design Issues: Implementation Release: Legacy Reference Form: Report Class:

Form Definition Document (FDD) Kranthi Gurram

Page 7

04-Oct-13

Execution Information: Module: Transaction Code: Security Requirements:

Manual Individual output. SAP SD VF01, VF02 Authorization to pint individual Cr/Db memo through VF01/VF02. ( Customer Services Manager, A/R Supervisor) Also the authorization for printing is to be given based on the Sales Org/Company Code.( YAN should not be able to print YARMEX Cr/Db memo)

Business Requirements Specifications

Please read what is credit/debit Memo used for in SD module before you start. Understand the business requirement.(Use google or SDN) The standard Cr/Db memo output format is to be modified accordingly. Modify the standard form LB_BIL_INVOICE . We need to pull the data from the ADRC,KNVV,KNVA, VBRK, VBRP ,KOMV and KOMP tables

ERP Modification Specifications: Action Plan:

1.4

Prerequisites

a. Customer Master should be updated b. Payment Terms should be definite in the Cr/Db memo. c. Cr/Db memo request or the Return order is to be completed in all respects.

Form Definition Document (FDD) Kranthi Gurram

Page 8

04-Oct-13

d. The print output condition record is to be updated properly. Also the print program along with the Smartforms needs to be modified for the variables fields in the Credit/Debit memo. e. In case of return processing the Return Deliveries are to be completed in all respects. f. The Cr/Db memo and Accounting Document is to be completed in all manners .

1.5

Inputs and Dependencies

Inputs:1. Cr/Db memo request . 2. Out put processing method (Properly maintained condition record, printer, etc.) 3. If you create a standalone program create an input selection screen with credit/debit memo as parameter(VBRK-VBELN)

Selection Screen: (If not configured in NACE) Data: P_VBELN type VBELN_VF.

Form Definition Document (FDD) Kranthi Gurram

Page 9

04-Oct-13

2. Forms Definition Details

See Section 1 for details.

2.1

Description

Create a Layout as given and place the fields given in data mapping file in repective places of Credit/Debit memo print form Using ADOBE forms Credit /Debit Memo Data Mapping Credit / debit Memo mapping

C:\Docum ents and DATA Mapping and Form Mapping Settings\rchaudhu\Desktop\Yazaki\20080430090815156_0003.pdf retrival logic_KGURRAM.xls _KGURRAM.pdf

Test Data in AD1:Credit /Debit Memo

0090000068

Form Definition Document (FDD) Kranthi Gurram

Page 10

04-Oct-13

2.2

Forms Specification Details

Rep Print/Layout Set ID: Frequency: Numb Number of Pages Media Output type: Report ID:

ZCRDRMemo_XXX Daily print 1 Print ZCRDRMemo_XXX

Note: Where XXX is your Unique identifier as per your seating or user ids

2.3

Forms Example

Form Definition Document (FDD) Kranthi Gurram

Page 11

04-Oct-13

Credit Memo / Debit memo

C:\Docum ents and Settings\rchaudhu\Desktop\Yazaki\20080430090815156_0003.pdf If this form is a copy of the standard form or is a template from the legacy system, please insert a copy here. Enter the name of the standard form, the corresponding path in Customizing and the transaction in the SAP System below.

Name of standard form: Path in Customizing/Easy access:Transaction:

LB_BIL_INVOICE Tools-Form printout-Interactive Forms SFP

2.4 Solution:
Create a driver program as per Section 2.2 using SE38. Create a interface with required structures and table types with fields to be displayed on form using SFP transaction. Use Given billing document as Input fetch required details as per mapping sheet given above in section 2.1. Fill the final tables with the same structures or table types as per your interface.

Form Definition Document (FDD) Kranthi Gurram

Page 12

04-Oct-13

Create a Adobe layout as given in section 2.1 using SFP Translation and give the interface name created. Design form as advised , activate and call the required function modules in your driver program as your trainer advises Run the driver program input 0090000068 in selection screen or VF02/VF03 and see the credit/debit Memo Output.

Form Definition Document (FDD) Kranthi Gurram

Page 13

04-Oct-13

3. Test Case

Instructions for Unit Test Plans Note: Delete this table of instructions before beginning. (Highlight the table and use shift+del to completely eliminate the table, not just remove its contents.) It is recommended to print a copy of these instructions prior to commencing work. Column Use Explanation Test Condition A phrase that briefly describes the condition/functionality to be tested. Test Conditions should be numbered sequentially. The number should be indicated with the description. (i.e.: 1. Validate Material Number Screen Field). A Test Condition should comprise one unique test, not multiple tests that are similar. For example, a correct test condition would include validating one selection screen field, not validating all the selection screen fields and then listing them as steps of the condition. Each Test condition should appear in its own table row. Step # The step number within the condition. Each condition will probably have several steps. Steps are the individual actions the unit test controller must perform in order to test the condition. You can reference previous condition(s) steps as required (for instance, you've already opened the transaction in the first test condition and now you need to validate the Plant so you'd indicate something like: 2.1 After step 1.5, enter a valid Plant in the Plant field and press return. Steps within each condition should also be numbered sequentially and include the condition number first. (i.e., 1.1, 1.2, 1.3, 1.4, 2.1, 2.2, 2.3, 3.1, 4.1, 4.2, etc) Step Description The description of the action to be performed for each step number. Test Data The actual data to be used for the test step or, if data is not available, give a business description of the data needed to test the step (i.e., customer number = 40389). Actual data used during final test run should be recorded here if only a business description was provided initially (this can also be done by referencing a screen shot of the selection screen showing the inputs).

Form Definition Document (FDD) Kranthi Gurram

Page 14

04-Oct-13

Expected Result The output or action that should occur according to the specification. Expected Results should describe the screen or output appearance, indicating the fields, lists, etc. with expected values, error messages with message text, etc. Also indicate where to verify the data. This verification should be made via SAP transactions (not just table) whenever possible. For example, for an output that displays purchase order information could refer the UTP controller to transaction ME13 (Display Purchase Order). Column Use Explanation Continued Actual Result What actually happens. By the time you're done testing and fixing this should match your expected result. If actual result matches expected result, enter 'As Expected' in this column. If you're really spiffy, you'll indicate the page number your screen shot(s) for the test occur on in the UTP Results Document. Other possible entries include "Failed", "Not Tested", "Partial Failure", and "Not as expected but acceptable". Remarks Comments on the test (indicates specific work around to be performed, if the test couldn't be performed adequately because of data, etc.) Difference from expected results should be indicated. The implications of a not "as expected" test should also be noted. (What problems might result because the condition couldn't be tested or failed.) Executed By/Date Date executed and test controller's initials.

Additional UTP Guidelines Unit test results should be screen-printed using SnagIt (if available), reduced to monochrome, and included in the UTP Results Document. Results should be cross-referenced to the appropriate unit test plan step by indicating 'Step 1.1', etc. plus a description. This step number and description should be placed just above the screen print in the UTP Results Document (see the instructions in the UTP Results Document for more details). All selection screen entries and corresponding results appearing during execution of the UTP should be screen-printed and crossreferenced. The following should be tested in the UTP: Defaults All calculations

Form Definition Document (FDD) Kranthi Gurram

Page 15

04-Oct-13

Check that database selects are returning the correct data Check return codes Screen flows are correct Screen information is correctly displayed Database updates/modifications are correct Standard header is used (if applicable) Sorts are correct Subtitles are correct Negative signs on numbers are in the right place Any rounding is occurring correctly Any truncation is occurring correctly If there is no data to be displayed, an appropriate message occurs Any error checks and/or validations performed by the program Etc.

Normal Functionality - test cases that ensure the program functions as it should. (e.g. updates fields correctly, processes all records)

Test Condition

Step

Step Description

Test Data

Expected Result

Actual Result/ Remark s

Executed By/Date

1 Check the Cr/Db Print for mexico

Create the output from the complete Cr/Db memo with Accounting document created Tcode:- VF02

Cr/Db Memo:-Cr/Db memo# Output type:- RDXX Medium:- Print Communication method:- Printer#

The Output will be successfully issued and the printout can be taken.

Form Definition Document (FDD) Kranthi Gurram

Page 16

04-Oct-13

Test Condition

Step

Step Description

Test Data

Expected Result

Actual Result/ Remark s

Executed By/Date

Check the printed Cr/Db output

Cr/Db memo Cr/Db Memo Number:-Cr/Db Memo# Memo date:- 10 July 2008 Bill to:- Bill to Party# No De Preveedor:- Vendor# Terminos:- 30 Days LAB:- Proveedor No. De Parte: -Mex Cr/Db memo Material ## Description/Text field at the item level:- Reff Invoice 1234# Total:- 200.00 USD

1. If we are checking the output in the blank page then the different values to be displayed will come in the exact location. 2.If we are checking in the preprinted form then the different fields will come in the exact positions it is supposed to be populated 3. The font type, size , layout etc is to be the same as mentioned in the data mapping. Also there should not be any overlapping of data. 4. The Cr/Db memo number should be the same as the FACTURA Number mentioned on the top right hand

Form Definition Document (FDD) Kranthi Gurram

Page 17

04-Oct-13

Test Condition

Step

Step Description

Test Data

Expected Result

Actual Result/ Remark s

Executed By/Date

2. Check the Descripcion in the output

Check the Printed Cr/Db memo

Cr/Db memo output Text data in the item level:- Invoice Number 0090000068

The Descripcion should be the the text data maintained in the item text of the Cr/Db memo which is the Invoice Numbers against whom the Cr/Db memo is given.

Exception - special logic or exceptions (e.g. do not process Government Markets customers, only process pre-packs)

Test Condition

Step

Step Description

Test Data

Expected Result

Actual Result/Remarks

Executed By/Date

Error Handling - functionality in case of errors (e.g. Customer not found, Record already exists)

Form Definition Document (FDD) Kranthi Gurram

Page 18

04-Oct-13

Test Condition Cr/Db memo output

Step 1

Step Description Check the output if the Invoice is not complete or the Accounting Doc is not generated

Test Data Cr/Db memo:Cr/Db memo 0090000068

Expected Result The output will not be generated

Actual Result/Remarks

Executed By/Date

Form Definition Document (FDD) Kranthi Gurram

Page 19

04-Oct-13

4. Technical Design Document

Insert the Technical Design Document here, if you choose.

Form Definition Document (FDD) Kranthi Gurram

Page 20

04-Oct-13