Function spec abap report

Unity 2AA
FI Functional Design
Clearing of payment based on FIFO
File Name: functionspecabapreportth-2108260121489 Page 1 of 15
Status: FINAL Confidential
Prepared by Ayhan Karakoc Reviewed by Ayhan Karakoc Approved by
Date March 29, 2010 Date March 29, 2010 Date
Clearing of payment based on
FIFO

Unity 2AA
TABLE OF CONTENTS
GENERALINFORMATION..................................................................................................................................................................................4
SIGN OFF.................................................................................................................................................................................................................4
REVISION HISTORY............................................................................................................................................................................................4
CATEGORYOF CHANGE....................................................................................................................................................................................4
CONTACTAND PHONENUMBER....................................................................................................................................................................4
RICEF WORKUNIT #:..........................................................................................................................................................................................5
FORMTITLE:..........................................................................................................................................................................................................5
MODULE& SUB MODULE: ................................................................................................................................................................................5
REGIONAL/ COUNTRYPROJECT:..................................................................................................................................................................5
EXPECTED DELIVERYTIMELINE:....................................................................................................................................................................5
1A. GENERALREQUIREMENTS ........................................................................................................................................................................5
1B. DESIGN.............................................................................................................................................................................................................6
DETAILED DESCRIPTION OF NEW FORM/CHANGES TO EXISTING FORM.................................................................................................6
HEADER DATA ....................................................................................................................................................................................................8
FOOTER DATA.....................................................................................................................................................................................................8
BREAKING.............................................................................................................................................................................................................8
TOTALS.................................................................................................................................................................................................................8
SORTING...............................................................................................................................................................................................................8
SUMMARY DATA ................................................................................................................................................................................................8
PROCESSING DETAILS (BUSINESS RULES/SELECTION CRITERIA AND VALIDATION):............................................................................8
PRE-PROCESSING/POST-PROCESSING DEPENDENCIES...................................................................................................................................9
DATA INCLUSION/EXCLUSION..........................................................................................................................................................................9
DESIGN CONSTRAINTS........................................................................................................................................................................................9
FORM LAYOUT ....................................................................................................................................................................................................9
OUTPUT FIELD DESCRIPTIONS........................................................................................................................................................................9
2A. SELECTION CRITERIA..............................................................................................................................................................................10
SELECTION CRITERIA (INPUT PARAMETERS FOR THE FORM PRINT PROGRAM).................................................................................10
SECURITY AND AUTHORIZATION CHECK ...................................................................................................................................................10
2B. ERROR HANDLING....................................................................................................................................................................................10
POTENTIAL ERRORS.........................................................................................................................................................................................10
3A. EXISTING/SAMPLEFORMOR RELATED TRANSACTION............................................................................................................12
EXISTING SAP PROGRAM NAME ....................................................................................................................................................................12
EXISTING SAP MENU/TRANSACTION ...........................................................................................................................................................12
LEGACY FORM NAME.......................................................................................................................................................................................12

Unity 2AA
LEGACY FORM NUMBER ..................................................................................................................................................................................12
3B. RELATED DOCUMENTS............................................................................................................................................................................12
3C. CONFIGURATION REQUIREMENTS:....................................................................................................................................................12
3D. COMPONENT TESTINGREQUIREMENTS...........................................................................................................................................12
TEST DATA ........................................................................................................................................................................................................13
3E. PERFORMANCEWATCH..........................................................................................................................................................................13
REVIEW RESULT................................................................................................................................................................................................13
FS STATUS ...........................................................................................................................................................................................................14
APPENDIXA: SCREEN SHOTS OF PROCESS ..........................................................................................................................................15

Unity 2AA
General Information
Document Location
Associated
Documentation
Sign Off
Team Name Date Signature
U2K2 Vietnam
RAC Ayhan Karakoc 29.03.2010
Revision History
Version CR No/
FUR No
Date Author Status CR Description
1.1 5102 24.03.2010 Ayhan Karakoc Draft Initial Creation
1.2 5102 24.03.2010 Ayhan Karakoc Review Review
< version 1.x: First FS of CR
version 2.x: If any FUR created to related CR
version 3.x: For another FUR
version x.1:First version of FS after CAB approval which is called DRAFT.
version x.2:Under Review
version x.3:SIGNOFF version of FS after country and RAC agreement..>
Category of Change
New Business Process Enhancement Interface with Local System
Productivity Improvement Interface with Regional System Legal / Statutory
Performance Improvement Others (Please indicate details):
Contact and Phone number
Name Surname E-mail Phone Number
Ayhan Karakoc ayhan.karakoc@unilever.com

Unity 2AA
RICEF Work Unit #: (Required)
[<Fun_Module>-F-###]
5102
Form Title: (Required)
[Title of the functional form specification.]
FIFO clearing
Module & Sub module: (Required)
[Indicate the SAP Module and Sub module based on SAP Hierarchy, e.g.: FI AR, MM PUR, etc]
FI-AR
Regional / Country Project:
<Regional or Country>
Regional
Expected Delivery Timeline:
<dd.mm.yyyy>
Before ITC1
1a. General Requirements
Functional Description of Form: (Required)
[Describe briefly the purpose of the form and contents that it displays]
For the countries not using invoice based clearing, there is a need to automate the clearing process according to FIFO
logic.
Frequency: (Required) Processing Type: (Required)
[Indicate how often the form is run.] [Enter the processing type of the form:
Online – The form is executed online
Batch – The form will be schedule as a background job
Both – Both Online and Batch]
Ad-hoc Online
Owner: (Required) Audience: (Required)
[Enter the owner of this form. E.g.: Buyer] [Enter the audience of this form. E.g.: Global Purchasing]
Finance Accounting
Business Driver: (Required)
[Describe the business driver for this form. E.g.: Audit Requirement, KPI, etc]
Because of the volume of data, there is a need to automate the clearing process according to FIFO logic.

Unity 2AA
Priority:
[Enter the relative priority of the form based on its necessity to run the business. Use the following criteria:
Low - Item has little or no impact on running the business and does not support the business case or quality of the project.
Medium - Item is not required to run the business on 'day one' and indirectly supports the business case and quality of the project.
High - Item is required to run business on 'day one' and directly support the business case of the project.]
Medium
Complexity:
[Enter the following complexity:
Easy - Minor modifications to the SAP standard forms. Printing of forms is configured into SAP, no custom ABAP programming required. No
custom database access is required.
Medium - Creating a form from scratch, and printing it on pre-printed paper. No need to create cosmetics such as grids, or boxes.
Printing of forms may require custom ABAP programming.
Difficult - Creating a form from scratch, but printing it on plain paper. Will need to create cosmetics such as grids, or boxes. Printing of
forms may require custom ABAP programming.
Very Diff. - Graphics. Variable layout. Large variance in number of rows processed. Data drives layout format.]
Medium
Initiating Transaction/Program:
[Indicate the transaction and/or program that cause this form to be produced.]
Custom tcode
Design Assumptions:
[Describe the expectations external to this document that directly affect the outcome and are not discussed in detail. Areas discussed
should include: Entry criteria prior to design document, things that need to be done prior to design completion, resource support and
requirements sign-off.]
Open Issues
S No Issue Description
Date Raised
(MMDDYYYY)/Owner
Resolution Status
1b. Design
Detailed Description of New Form/Changes to Existing Form: (Required)

Unity 2AA
[Use this section to describe the major features of the document. Include header and trailer information, user specified parameters ( i.e.
List by customer, list by product, or list by sales region) and any specifics on summary information ( commonly placed at the end of the form
such as totals, sub-totals, etc.). If required list rank-by, sort-by, or group-by criteria.]
1. All the FI Documents
No. FI Documents Document
(Dr: +, Cr: - )
Including in FIFO
Clearing
1 FI Invoice (From SD, FI transaction) +
2 Debit Note (from SD, from NUTI, FI
transaction)
+
3 Credit Note (from SD, from NUTI, FI
transaction)
-
4 Payment -
5 Prompt payment (Direct bonus deduction to
net off AR balance)
- See the below note
for example
6 Special G/Ls (e.g. deposit, advance) - Special G/L is not
processed via FIFO
2. Order
- Select CN/Payment. No sorting is necessary for CN and payment because all selected items will be
cleared but document date and amount in ascending order can be used.
- Invoice/DN will be selected from the oldest due date to the newest due date. As another criterion,
amount in ascending order can be used.
Example:
CN (Document date: 1, 2, 5)
Payment (Document date: 2, 3, 4)
 Select CN (1) against Invoice/Debit (Due Date)
 Select CN(2), Payment (2) against Invoice/Debit (Due Date)
 Etc.
Default clearing logic:
The program will run until CN/Payment is processed all (if total of CN/Payment is bigger that total of
DN/Invoice). Residual items will always be generated for credit side (payments, credit notes), no
residual item is generated for invoices not to let any confusion for original invoices. To separate the
residual items generated automatically, a reason code configured in custom table will be assigned
(optional. If not configured, no reason code is assigned) and this information is available in line item
reports. Accordingly, if;
Invoice 1: 50
Invoice 2: 40
Invoice 3: 30
Payment 1: 100
Inv1 and Inv2 are cleared with the payment, Inv3 is not cleared because there is not enough
payment and a residual payment item having the amount - 10 is generated. So as an open item, Inv3

Unity 2AA
(30) and a residual payment item of - 10 are listed. Here, there should be at least 2 open items to
keep the original invoice.
The program will allow the residual posting for debit side if “ALLOW DEBIT RESIDUAL?” is selected:
This will add more flexibility. If this checkbox is selected, it allows generating the residual item also
for invoice side (if invoice amount is more than payment amount). For above example, all 4 items
will be cleared and a debit residual of 20 will be generated.
Note for Prompt payment:
Invoice: 100 (Due Date: 20 Feb 2010) – Pay before 10 days: discount 6%; Pay before 5 days: 2%
– Payment: 100 on 09 Feb (sooner than 10 days) => should be get bonus 6%.
 Payment offset with Invoice : 94 + bonus: 6.
 Remaining Payment (6) will be offset with another invoice/DN in FIFO.
Cross currency clearing is optional. In default, it will clear if the currency is same.
3. Manual/Automatic program
The FIFO program should be able to run manually/automatically by background job. SM35 session will be
used to process the generated postings and check relevant posting logs. In case of any posting problem,
user will be able to see via SM35 and make necessary manual corrections.
Header Data:
[Describe the content found in the header]
Footer Data:
[Describe the content found in the header]
Breaking:
[Describe what criteria will be used for page breaking]
Totals:
[List any totals that should be accumulated on the form.]
.
Sorting:
[List any columns that should be sorted with the sort order (ascending, descending).]
Summary Data:
[Describe the content found in the summary]
Processing Details (Business Rules/Selection Criteria and Validation): (required)
[Describe the frequency of form, steps and any dependencies required.]
The transaction is run periodically or whenever it is required, the steps are following:

Unity 2AA
1. The created custom tcode will be used to clear items
Pre-Processing/Post-Processing Dependencies:
[Enter the prerequisite steps, i.e., any customized table that the program retrieved the data from. In that case, the user must provide valid
data record in the table. Also state the post-processing step, i.e. form is sent to a dept via spool request.]
Important Notes:
Data Inclusion/Exclusion:
[Any data to be excluded/included by default]
Design Constraints: (Required)
[Describe limiting factors/dependencies/expectations and items that must be met.]
Form Layout: (Required)
[Enter sample layout or provide a document containing the layout.]
Output Field Descriptions: (Required)
[Please provide the fields and their descriptions in the record layout.]
The below output will be generated for both foreground and background runs. The items that will be cleared are listed in
this output. The residual item amount generated can be seen via subtotal by customer.
SAP
Table
SAP Table
Field
SAP Table-Field Name
BSID BUKRS COMPANY CODE
BSID KUNNR CUSTOMER NO
KNA1 NAME1 CUSTOMER NAME
BSID BLART DOCUMENT TYPE
BSID BELNR DOCUMENT NO
BSID XBLNR REFERENCE NO
BSID ZUONR ASSIGNMENT
BSID BUDAT POSTING DATE
BSID BLDAT DOCUMENT DATE
BSID CALCULATED NET DUE DATE
BSID ZTERM PAYMENT TERM
BSID ZLSCH PAYMENT METHOD
BSID WAERS CURRENCY
BSID WRBTR AMOUNT IN TRANSACTION CURRENCY
BSID DMBTR AMOUNT IN LOCAL CURRENCY
BSID SGTXT LINE ITEM TEXT

Unity 2AA
2a. Selection Criteria
Selection Criteria (Input Parameters for the Form Print Program)
[Provide select options (ranges), parameters (single value options), whether the item is mandatory/optional and whether the input parameter
should have a drop-down list with values for selection. Group the selection criteria in frames.]
Selection parameters:
SAP
Table
SAP Table
Field
SAP Table-Field Name
BSID BUKRS COMPANY CODE Mandatory Multiple selection
BSID KUNNR CUSTOMER NO Mandatory Multiple selection
BSID BLART DOCUMENT TYPE Optional Multiple selection
BSID BELNR DOCUMENT NO Optional Multiple selection
BSID XBLNR REFERENCE NO Optional Multiple selection
BSID ZUONR ASSIGNMENT Optional Multiple selection
BSID BUDAT POSTING DATE Optional Multiple selection
BSID BLDAT DOCUMENT DATE Optional Multiple selection
BSID WAERS CURRENCY Optional Multiple selection
- CHECKBOX ALLOW CLEARING CROSS CURRENCIES? Optional
- CHECKBOX ALLOW DEBIT RESIDUAL? Optional
- CHECKBOX Test run Optional
For those 2 checkboxes;
ALLOW CLEARING CROSS CURRENCIES? : This will allow the clearing between different currencies. In
default, the clearing will be done if the currency is same.
ALLOW DEBIT RESIDUAL? : Normally, the residual item will be generated only if payment amount is more
than invoice amount and if invoice amount is more than payment amount, no clearing will be done (e.g
invoice is 100, payment 80; then there will be 2 open items). If this checkbox is selected, it allows
generating the residual item also for invoice side (if invoice amount is more than payment amount. E.g.:
invoice is 100, payment 80; those are cleared and 20 debit residual is generated).
Test run: Postings are not generated, just the output for selected items is displayed.
Security and Authorization Check
[Provide the security and authorization check requirements, such as the field to check, authorization objects, field value, etc. This
authorization check should be able to control that only user with the correct authorization can execute/view the data in this form. ]
2b. Error Handling
Potential Errors:

Unity 2AA
[Describe instances where errors may occur. This should include the extent to which the organization is responsible for error monitoring in
correction versus users responsibilities. Full details on how operations will be notified are not required; however, state the business
expectations for level of service provided.]

Unity 2AA
3a. Existing/Sample Form or Related Transaction
Existing SAP Program Name:
[Enter the name of the related SAP program]
Existing SAP Menu/Transaction:
[Enter the related SAP Menu path and/or transaction]
-Custom t-code will be assigned
Legacy Form Name:
[Indicate document/sample cross reference or link design object into form.]
NA
Legacy Form Number:
[Indicate legacy number on document/sample cross reference.]
NA
3b. Related Documents
No. Related Documents Description Attachment
1.
2.
3c. Configuration Requirements:
[What configuration is required to support this process? Does this process require master data to be loaded? Do all configuration,
master, and transactional data exist in the development system? ]
3d. Component Testing Requirements
[List at a high level any requirements that exist to fully test this program.. Please enter functional conditions that are required for testing.
Please include normal conditions and error handling conditions. This should include the following categories of test conditions:
(1) Normal Processing: To test and display the form as the normal situation.
(2) Exception Processing: To test and display the exception process (e.g.: zero amounts are not display, do not show deleted material, etc).
(3) Error Processing: To test and display the error message (e.g.: invalid company code, invalid sales order number, etc).]
Test condition Expected results
Normal Processing :
Execute the report for multiple customers having
multiple postings
Clearing session will be generated and
run in SM35 transaction.
Execute for partial clearing (Total Dr > Total Cr):
- (1) Check “Allow Debit Residual”
- (2) Uncheck “Allow Debit Residual”
(1) After FIFO is processed, there
will be invoices/debit note and
credit notes.
(2) After FIFO is processed, there
will be debit notes which are
created from invoices.
Execute for full clearing (Total Dr <= Total Cr): After FIFO is processed, there will be

Unity 2AA
- (1) Check “Allow Debit Residual”
- (2) Uncheck “Allow Debit Residual”
credit notes only.
For Credit Note, payment:
- (1) Different Doc date, same amount
- (2) Same doc date, different amounts
(1) The program will sort Credit
Note/payment by doc date.
(2) The program will sort by amount.
For Debit Note, Invoice:
- (1) Different due date, same amount
- (2) Same due date, different amounts
(1) The program will sort by Due date
(2) The program will sort by amount.
Clear by multiple currency:
- (1): Check “Allow clearing cross currencies”
- (2): uncheck “Allow clearing cross
currencies”
(1) The program will clear cross
currencies.
(2) The program will not clear cross
currencies.
Document Type:
- (1) Only payment (no Credit Note)
- (2) Only Credit Note (No payment)
- (3) Both payment and Credit Note
- (4) Only invoice (no Debit Note)
- (5) Only Debit note (No invoice)
- (6) no invoice and no debit note for payments
The program will run correctly
corresponding to document types.
Reason code:
Maintain the reason code
For Credit Note (created by payment), for
Debit Note (created by Invoice), there
should be Reason code for each
document.
Testing for prompt payment case The program will run correctly.
Testing for Special G/Ls, statistical posting. These documents will not be processed
by FIFO program.
Test Data: (Required)
[Provide the test data that to perform the above test conditions]
3e. Performance Watch
[Consider the following items:
1. Online & time critical reports.
2. Transaction volume.]
Review Result
<To be filled by Regional Application Team after review of the document>
<This section captures the reviewers results regarding the FS Status>
Is the Change Request content adequate
enough to move ahead?
Is it a newrequirement or can be reusedwith
modification? Please specify:

Unity 2AA
Summarize Business Requirement:
Definition of Change (Technical Details /
Addendum to the Change):
Brief description - Feasibility assessment for
proposedchange:
Describe Assumption if any: -
Describe in detail impact of change (On
existing systems / inter project related):
Is the proposedchange / feature available in
SAP? (If Applicable)
Risk Rating High Medium Low
Financial Processing Integrity impact
FS Status
FS Status Approved Rejected Deferred
Escalated
Regional Application
Manager
(ERP / Information
Management / Customer
Development etc.)
Name:
Date:
Signature / Email Rejection
Comments / Reasons if rejected or escalated:

Unity 2AA
APPENDIX A : Screen shots of process
[Set of screen shots to clarify steps of process. For example if the form is a standard modification, then provide the screen shots of
transaction]

Function spec abap report

More Related Content

What's hot (19)

Recently uploaded (20)

Function spec abap report