2 4 2 1 Fs Otc Form f003 Credit Debit Memo v2

Copyright 2012. Capgemini U.S. LLC. All rights reserved.
SAP Form Functional

Specification
ZFSD_Cr/Dr_F002_Credit /
Debit Memo Form
Prospector
Offshore Drilling

Document1

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

Table of Contents

1 OBJECT REQUIREMENTS SUMMARY ................................................................. 4
1.1 OBJECT INFORMATION AND ATTRIBUTES ................................................................ 4
1.2 REQUIREMENTS SUMMARY AND BUSINESS DRIVER ................................................ 4
1.3 ASSUMPTIONS ..................................................................................................... 5
1.4 CURRENT FUNCTIONALITY .................................................................................... 5
1.5 REQUIRED FUNCTIONALITY ................................................................................... 5
1.6 PROJECT / DEVELOPMENT CONSTRAINTS .............................................................. 5
1.7 PERFORMANCE CRITERIA ..................................................................................... 5
1.8 OTHER OBJECTS AFFECTED ................................................................................. 6
1.9 EXTERNAL REFERENCES ...................................................................................... 6
1.10 DEFINITIONS/ACRONYMS/ABBREVIATIONS ............................................................. 7
2 FORM DESIGN DETAILED SPECIFICATIONS ...................................................... 7
2.1 DETAIL REQUIREMENTS: ..................................................................................... 7
2.2 DATA SELECTION-SCREEN / CRITERIA: .................................................................. 7
2.3 FORM OUTPUT LAYOUT:....................................................................................... 7
2.4 FORM OTHER INFORMATION .............................................................................. 9
2.5 PRINTING / MEDIA REQUIREMENTS: ..................................................................... 10
2.6 ERROR HANDLING METHOD: .............................................................................. 11
2.7 POST EXECUTION NOTIFICATION DETAILS: .......................................................... 13
2.8 PROCESS LOG DETAILS ..................................................................................... 13
3 ADDITIONAL INFORMATION ............................................................................... 14
3.1 UNIT TEST PLAN................................................................................................ 14
3.2 INFORMATION SECURITY .................................................................................... 15
3.3 AUDIT ............................................................................................................... 18
3.4 QUESTIONS / ISSUES / RISKS .............................................................................. 18

Document1


Business Process Organizational
Structure
Sales & Distribution
Process Owner
Original Author(s)
Current Revision Author(s)

Version Date Author(s) Revision Notes
1.0 07/24/2012 Channaveerswamy
Wodeyar

2.0 09/07/2012 Channaveerswamy
Wodeyar
Description changes

Document1


1 OBJECT REQUIREMENTS SUMMARY

1.1 Object Information and Attributes

The following is current information about this object and document:

Object ID ZFSD_SD_004_Credit/Debit memo Form
Title Credit / Debit Invoice Memo Form
Author(s) Channaveerswamy Wodeyar
Team Which Owns
the Object
SAP, SD
System Version ECC 6.0 EPH 4
Development Type Form
Priority Medium
Estimated
Complexity
Medium, From PRICEFW Justification
Link to Process
Flow
Actual link to the associated Level 3 Process Flow(s) to maintain
traceability.
FTM Team
Validation
Required
Mark 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

1.2 Requirements Summary and Business Driver

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

1.2.1 Alternatives to Object

Document1


1.2.2 Impact of Implementation

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

1.2.3 Impact of No Implementation

N.A

1.3 Assumptions

Credit / Debit memo are already processed in the system.

1.4 Current Functionality

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

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

1.6 Project / Development Constraints

None

1.7 Performance Criteria
Description:
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: <Number> Every time when credit/debit memo invoice is
created, user needs to take printout of that.
Frequency per Peak: <Number> Every time when credit/debit memo invoice is
created, user needs to take printout of that.
Availability: 24/7 All the time
Expected Average Response
Time:

Document1


Performance Requirements for Forms
Expected Peak Response
Time:

1.8 Other Objects Affected
Description:
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.

Object Impact/Change Description

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

SAP System SAP Module Impact/Change Description
ECC 6.0 SD VF01/VF02/VF03

NON-SAP /
Legacy
System
Impact/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.

1.9 External References

List of all the external references.
Document Title Author Attachment / Links
N.A

Document1


1.10 Definitions/Acronyms/Abbreviations
List of all the definitions /acronyms /abbreviations used within the document.

2 FORM DESIGN DETAILED SPECIFICATIONS

2.1 Detail Requirements:

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

2.2 Data Selection-Screen / Criteria:
Describe the data selection screen / criteria if any.
Field Name
Table Field /
Checkbox /
Radio Button
Select-
Option (S) or
Parameter
(P)
Comments (Range,
Single/Multiple Selection,
Patterns, Mandatory, etc.)
Validations
(For Each
Field if any)
Default
Value
VBELN VBAK-
VBELN
Parameter Single

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

Field Name
Field Description

Conditions / Data Retrieval
Logic
Maximum Number of
Characters to print
2 VBRK VBELN Invoice number 8 - Numeric
3 VBRK FKDAT Invoice Date

8 (MM/DD/YYYY)
4 Billing date From - To 8 (MM/DD/YYYY)
8 (MM/DD/YYYY)
5 Payment due
date

To be calculated as
(Invoice date + No of days
in Payment terms)

8 (MM/DD/YYYY)
6 VBRK ZTERM Terms Text -25 characters

Document1


8 VBRK

ADDR1_DATA
ADDR1_DATA
ADDR1_DATA
ADDR1_DATA

ADDR1_DATA
ADDR1_DATA

KUNRG

NAME1
STREET
CITY1
POST_COD
E1

REGION
COUNTRY
Payer customer
master

Name
Street
City
Postal code

Region
Country
Pass the customer value
/description from the table
KNA1 and print it along
with the customer number
Code: 8 Numeric
Cust Address: 40
characters Alpha
Numeric
Text -25 characters
Text -25 characters
Text -20 characters
6 Numeric
characters

Text -15 characters
Text -15 characters
9 VBRP WERKS Drilling Rig 12 - Alpha Numeric
characters
10 VBAK BSTKD Location / Well # 12 - Alpha Numeric
characters
11 VBAK BSTKD_E OCSG number 12 Numeric
characters
12 VBRP FBUDA Date Service rendered date 8 (MM/DD/YYYY)
13 VBRP

MATNR

Material Code

10 characters
numeric
14 VBRP ARKTX Description Text 50 characters
15 VBRP FKIMG Total hours 5 characters numeric

16 VBRP NETWR Rate per Hour 8 characters numeric

17 Amount 8 characters numeric
18 Total Amount 8 characters numeric
22 VBBK Text Object 50 Characters
Field mapping and credit invoice template is attached.

CR_DR_INVOICE_FO
RM.pptx

credit_debit_memo(F
ield mapping).xlsx

Additionally, mention the following:

Document1


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 type L2 / 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

2.4 Form Other Information

Form Processing Requirements
Description: Identify the processing requirements for this form.
Calculations / Transformations
Value to be Derived Business Rules / Algorithm For This Transformation
Company Logo Statutory
Company Address Shall print at footer of last page
Number of line items if exceeds If number on line items exceeds, then shall flow to second / subsequent page.

Other Updates Performed During Processing Not Specified Above
Initiating Event Updated Information Rules For Update
<Event which causes the need
for an update to the database;
e.g., data is changed>
<Table / Field> <Source of data or calculations/transformations>

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)
Number Description of Requirement

Document1


Other Form Requirements (Not Specified Elsewhere in This Document)
Number Description of Requirement
1. <Description>
2.

2.5 Printing / Media Requirements:
Output Device Name:
(Mention the Output Device Name)
LOCL Printer
Number of Copies:
(Mention number of copies to be printed)

Spool Request Name:
(Mention if any specific spool request
name)
N.A
Print Immediately:
(Check the box if yes)

Delete after Output:

New Spool Request:

Close Spool Request:

Paper Format Portrait
Paper Size A 4

Document1


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

List all the Exceptions. Specify if applicable.

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

Description: Identify known potential failure points.
Failure Points
Possible Point Of
Failure
Rules For Handling Failure
<Failure Point> <Description of action to be taken such as Display error
message on screen and continue, Write error to error log
and continue processing, Terminate the screen and contact
the systems department, etc.> <Description of action to be
taken such as Print error on report and continue, Write error
to error log and continue processing, Terminate the report
and contact the systems department, etc.>
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

Document1


Failure Points
Possible Point Of
Failure
Rules For Handling Failure
For maintenance,
query input screen,
validation check
result into an
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
remediation
For 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 Needed Description

Document1


Error Handling Requirements
Information Needed Description
Error Detection <Describe how an error can be identified>
Range 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 Notification <Identify who/how to be notified List, Email Notification,
etc.>
For 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)
<Identify how/where errors are to be logged>
Pleased provide Function Mail Group that will need email
notification and member list of the mail group
Error Remediation <Identify what procedures are required to clear the error and
(if applicable) resubmit/re-run? There must be an associated
FDD/MFDD listed.>

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

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

Document1


3 ADDITIONAL INFORMATION

3.1 Unit Test Plan
Description:
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.

Unit Test Plan -
Forms.docm

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

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

Unit Test
Considerations

MM-DD-YY

Document1


3.2 Information Security
Description:
Provide details according to Functional Specification.

3.2.1 Information Classification
General Information
Businesses Impacted:

Information Classified by whom: Date
Contact Information
Company Name Phone E-mail Address
List Potential
Information Owners:

Architecture
Environments: (impacted by this T spec): Development Test Training Production
Architecture: (system exposure):
Public (Internet) Facing Internal Only
3
rd
Party Hosted Company * Hosted

Identity & Access Management
During Project
3
rd
party system access required?
Yes
No
Offshore? Yes
No
List the 3
rd

Parties:

Post Implementation
3
rd
party system access required?
Yes
No
Offshore? Yes
No
List the 3
rd

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:

Document1


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.

Document1


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 Type Role Access Allowed
Screen Level
Security
<FDD Role 1>
<FDD Role 2>
<read, read/update>
Field Level Security <FDD Role 1>
<FDD Role 2>
<Any restrictions on the fields that individuals with
this role can either see and/or update>
Button Security <FDD Role 1>
<FDD Role 2>
<Any restrictions on the buttons that someone
with this role can either see and/or invoke>
Data Security <FDD Role 1>
<FDD Role 2>
<Any restrictions on the data that someone with
this role can either see and/or update>

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 Table Authorization 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

Document1


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 Step Business 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 /
Functionality
Describe what authorization a User must be assigned to access the
data set or functionality

3.3 Audit
This 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 Event Description Audit Trail Updates
<Event which
causes the need for
an audit trail; e.g.,
data is changed>
<Description> <Audit message / fields audited>

3.4 Questions / Issues / Risks

Questions/Issues/Risks
Asked By Question/Issue/Risks Resolution Resolution
Date

2 4 2 1 Fs Otc Form f003 Credit Debit Memo v2

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

2 4 2 1 Fs Otc Form f003 Credit Debit Memo v2

Hochgeladen von

Copyright:

Verfügbare Formate

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

SAP Form Functional

Das könnte Ihnen auch gefallen