Copyright 2012. Capgemini U.S. LLC. All rights reserved.
SAP Form Functional
Specification
ZFSD_Billing_F003_
Intercompany_Invoice
Prospector
Offshore Drilling
Document1x
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 ...................................................................... 6
1.7 PERFORMANCE CRITERIA ............................................................................................... 6
1.8 OTHER OBJECTS AFFECTED........................................................................................... 6
1.9 EXTERNAL REFERENCES ................................................................................................ 7
1.10 DEFINITIONS/ACRONYMS/ABBREVIATIONS ..................................................................... 7
2 FORM DESIGN DETAILED SPECIFICATIONS ......................................................... 7
2.2 DATA SELECTION-SCREEN / CRITERIA: .......................................................................... 7
2.3 FORM OUTPUT LAYOUT: ................................................................................................. 8
2.4 FORM OTHER INFORMATION ...................................................................................... 10
2.5 PRINTING / MEDIA REQUIREMENTS: ............................................................................. 11
2.6 ERROR HANDLING METHOD: ......................................................................................... 12
2.7 POST EXECUTION NOTIFICATION DETAILS: .................................................................. 14
2.8 PROCESS LOG DETAILS ................................................................................................ 14
3. ADDITIONAL INFORMATION......................................................................................... 15
3.1 UNIT TEST PLAN ............................................................................................................ 15
3.2 INFORMATION SECURITY ............................................................................................... 16
3.3 AUDIT ............................................................................................................................ 19
3.4 QUESTIONS / ISSUES / RISKS ........................................................................................ 19
Document1x
Copyright 2012. Capgemini U.S. LLC. All rights reserved. Page 3
Business Process Organizational
Structure
Process Owner
Original Author(s)
Current Revision Author(s)
Version Date Author(s) Revision Notes
1.0 07/24/2012 Channaveerswamy
2.0 09/07/2012 Channaveerswamy Description corrections
Document1x
Copyright 2012. Capgemini U.S. LLC. All rights reserved. Page 4
1 OBJECT REQUIREMENTS SUMMARY
1.1 Object Information and Attributes
The following is current information about this object and document:
Object ID ZFSD_SD_E_003_Intercompany Invoice
Title This form will be used by Prospector for printing the customer invoices
in SAP.
Author(s) Channaveerswamy
Team Which Owns
the Object
SAP SD
System Version ECC 6.0
Development Type Form
Priority High
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 Billing documents for Prospector.
The main objective is to process billing and invoice output for Intercompany using billing
document type ZIC. This form will be used by Prospector for printing the Intercompany
invoices in SAP.
Billing is the final step in Intercompany sales order processing. During this process, the
Intercompany sales order will be billed to the intercompany customer and invoices are
created. The accounting documents are generated automatically. System has the ability
to update the respective G/L accounts automatically after releasing to accounting. The
billing process in SAP is controlled by billing document types ZIC.
The Intercompany service transactions, Intercompany STO delivery and billing will be
processed thru sales and distribution and rest intercompany transactions will be covered
in respective modules like FI & MM.
During this process, the Intercompany sales order will be billed to the Intercompany
customer and invoices are created. The accounting documents are generated
automatically.
Document1x
Copyright 2012. Capgemini U.S. LLC. All rights reserved. Page 5
The SAP system shall have the ability to print the Intercompany customer invoice as per
the attached Layout and the table/field mapping.
Mandatory field values are: Item number, Description, Quantity, Rate per Unit, Total
Amount.
1.2.1 Alternatives to Object
SAP Menu Path: VF01, VF02, VF03
Output Determination: V3 Billing
Output Type: ZRD2
Mode of Execution: Manual at the time of Invoice processing
Program Name: RLB_INVOICE
Layout Set Name: Intercompany Invoice
1.2.2 Impact of Implementation
All the Intercompany invoices, will be printed thru SAP system.
1.2.3 Impact of No Implementation
N.A
1.3 Assumptions
All the Intercompany invoices will be already created in the system.
1.4 Current Functionality
Presently Prospector prints the Intercompany invoice out of their legacy system. The
format, layout and field mapping of the same is detailed in this document in the
respective sections.
1.5 Required Functionality
This is a special billing type used for processing Intercompany Sales transactions. An
intercompany sale transaction is when a sale occurs and the selling sales organization
belongs to a different company code than that of the supplying plant (Rig). It represents
the internal invoice used between the two company codes belonging to the same
business.
Document1x
Copyright 2012. Capgemini U.S. LLC. All rights reserved. Page 6
In SAP, Prospector shall have the facility to print Intercompany Invoices in the format
detailed in the document. The different Billing document type (ZIC Intercompany
Invoice) will be configured in SAP.
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 Intercompany Invoice is
created, user needs to take printout of that.
Frequency per Peak: <Number> Every time when Intercompany Invoice is
created, user needs to take printout of that.
Availability: <24/7>/<12/6>
Expected Average Response
Time:
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
VF01 / VF02 / VF03
In addition List of the application areas being changed or affected by this design.
SAP System SAP Module Impact/Change Description
SD VF01 / VF02 / VF03 transactions
Document1x
Copyright 2012. Capgemini U.S. LLC. All rights reserved. Page 7
NON-SAP / Legacy
System
Impact/Change Description
N.A N.A
Dependencies:
Before processing Intercompany Billing document, Intercompany Sales orders must be
created / processed in the system.
Dependent Configuration:
Maintaining output type condition master record (VV31) based on key combination will
enable system to automatically select the output type.
1.9 External References
Document Title Author Attachment / Links
NA
1.10 Definitions/Acronyms/Abbreviations
N.A
2 FORM DESIGN DETAILED SPECIFICATIONS
2.1 Detail Requirements:
In this context, a form refers to a printed form and not an SAP screen. (Please
mention SMARTFORM / SAPScript / Adobe Form.)
In this process for printing Customer Invoice we will be using Smart Form.
2.2 Data Selection-Screen / Criteria:
Describe the data selection screen / criteria if any.
Document1x
Copyright 2012. Capgemini U.S. LLC. All rights reserved. Page 8
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
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
Document1x
Copyright 2012. Capgemini U.S. LLC. All rights reserved. Page 9
9 VBFA VBELN Contract # From table VBFA and get
reference Sales order
number. Again in table
VBFA for this sales order
number fetch the reference
contract number
8 Numeric
10 VBRP WERKS Drilling Rig 12 - Alpha Numeric
characters
11 VBAK BSTKD Location / Well # 12 - Alpha Numeric
characters
12 VBAK BSTKD_E OCSG number 12 Numeric
characters
13 VBRP MATNR Material Code
10 characters
numeric
14 VBRP ARKTX Description Text 50 characters
15 VBRP FKIMG Total hours System shall print all
line item quantity. If any
line item is having 0
(ZERO) hour in the
billing document then
the item should be
suppressed in the billing
output.
i.e If VBRP_FKIMG EQ
0, then system must
suppress in billing.
5 characters numeric
16 VBRP NETWR Rate per unit 8 characters numeric
17 Amount 8 characters numeric
18 Total Amount
Invoiced
8 characters numeric
22 VBBK Text Object 50 Characters
Prospector
documents F_SD_001_Customer_Invoice.xls
INTERCOM_INVOICE
_FORM.pptx
Additionally, mention the following:
Document1x
Copyright 2012. Capgemini U.S. LLC. All rights reserved. Page 10
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_CUST_INVOICE
Output Type: ZRD0
Billing Document Type: ZIC Intercompany Invoice
Print Program Name: RLB_INVOICE
Standard Text:
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
Billed Quantity
If any line item is having 0 hour in the billing document then the item
should be suppressed in the billing output
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>
Document1x
Copyright 2012. Capgemini U.S. LLC. All rights reserved. Page 11
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
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)
NA
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 Format Portrait
Paper Size A 4
Document1x
Copyright 2012. Capgemini U.S. LLC. All rights reserved. Page 12
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
Document1x
Copyright 2012. Capgemini U.S. LLC. All rights reserved. Page 13
Failure Points
Possible Point Of
Failure
Rules For Handling Failure
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
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
Document1x
Copyright 2012. Capgemini U.S. LLC. All rights reserved. Page 14
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.
Print in Portrait form.
Document1x
Copyright 2012. Capgemini U.S. LLC. All rights reserved. Page 15
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 -
[Link]
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
Document1x
Copyright 2012. Capgemini U.S. LLC. All rights reserved. Page 16
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:
Prospector
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:
Document1x
Copyright 2012. Capgemini U.S. LLC. All rights reserved. Page 17
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.
Document1x
Copyright 2012. Capgemini U.S. LLC. All rights reserved. Page 18
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>
VF02 / VF03
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.
[Link] 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
[Link] 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
Document1x
Copyright 2012. Capgemini U.S. LLC. All rights reserved. Page 19
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
