SAP Adobe Forms Credit Debit Memo(MX)

Forms Definition DocumentSAP Adobe Forms: Credit /Debit Memo(MX)

Author:Kranthi GurramProject: Fast Track

Version: 1.0

Document History

Document LocationThis 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 HistoryDate of this revision: 16.02.2011 Date of next revision (date)

Revision Number

Revision Date

Summary of Changes Revised By

1 16.02.2011 Initial Kranthi Gurram

ApprovalsThis document requires the following approvals:

Name Title DateKranthi Gurram Functional Realization

DistributionThis document has been distributed to:

Form Definition Document (FDD) –Kranthi Gurram Page 2 17-Apr-23

Name TitleKranthi Gurram OTC Business Analyst


Contents1.1..................................................................................................................................................Identification4

1.2 Document Information...................................................................................................................4

1.3 Design Considerations.................................................................................................................. 6

1.4 Prerequisites................................................................................................................................. 7

1.5 Inputs and Dependencies..............................................................................................................8

2. Forms Definition Details....................................................................................................................9

2.1 Description.................................................................................................................................... 9

2.2 Forms Specification Details...........................................................................................................9

2.3 Forms Example........................................................................................................................... 10

2.4 Solution:...................................................................................................................................... 11

3. Test Case........................................................................................................................................ 12

4. Technical Design Document...........................................................................................................18


Forms NarrativeThis 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 IdentificationForm is prepared By Kranthi Gurram for Abode developers: All the very best


1.2 Document Information

Title: Adobe forms_V01_Credit/ Debit memo(MX)

Date: 02.16.2011

Implementation Release: Release 1

Brief Description: Standard Credit/Debit memo:-LB_BIL_INVOICE

Document Type: Functional Spec (FS)

Priority: High/mandatory Medium/recommended Low/optional

Team: Sales and Distribution

Development Team Contact:

Developer:

Specification Author: Kranthi Gurram

Status:

Category: Input Output Computerized Manual

Priority High Medium Low

Complexity: Complex Average Simple

Duration of Development Work (days):

6 Days

Is there an alternative in the standard system?

Yes No


Description of alternative: Generic Standard Credit/Debit memo Out put

Reason(s) why alternative is not acceptable: Standard Credit/Debit memo will not cater the need of YARMEX

legal and Business requirement.

Development Labor Estimate: 6 Days

48 Hours

Planned Start Date: Planned End Date:

Actual Start Date: Actual End Date:

Project cost: Charge cost to: Cost approved by: Date of project management approval:

02.16.2011 Date of steering committee approval:

1.3 Design Considerations

Open Design Issues: None

Implementation Release: Release 1

Legacy Reference Form: Fasttrak Debit/Credit memo

Report Class:


Execution Information: Manual Individual output.

Module: SAP SD

Transaction Code: VF01, VF02

Security Requirements: 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)

ERP Modification Specifications: The standard Cr/Db memo output format is to be modified accordingly.

Action Plan: Modify the standard form ‘LB_BIL_INVOICE’ . We need to pull the data

from the ADRC,KNVV,KNVA, VBRK, VBRP ,KOMV and KOMP

tables

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.


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.


2. Forms Definition DetailsSee 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

Test Data in AD1:-

Credit /Debit Memo 0090000068


2.2 Forms Specification Details

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

2.3 Forms Example

Credit Memo / Debit memo


Rep Print/Layout Set ID: ZCRDRMemo_XXX

Frequency: Daily print

Numb Number of Pages 1

Media Output type: Print

Report ID: ZCRDRMemo_XXX

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: LB_BIL_INVOICE

Path in Customizing/Easy access:-

Tools-Form printout-Interactive Forms

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

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.


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

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 cross-referenced.

The following should be tested in the UTP:


Defaults All calculations 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

Check the Cr/Db Print for mexico

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


Test Condition


s

Executed By/Date

2 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


Test Condition


s

Executed By/Date

2. Check the Descripcion in the output

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


Test Condition

Step Step Description Test Data Expected Result Actual Result/Remarks Executed By/Date

Cr/Db memo output

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

Cr/Db memo:- Cr/Db memo 0090000068

The output will not be generated


4. Technical Design Document

Insert the Technical Design Document here, if you choose.


Documents

SAP Adobe Forms Credit Debit Memo(MX)