CYBERSOURCE DATA MIGRATION

BILLING AND REVENUE MANAGEMENT FOR

CYBERSOURCE
FUNCTIONAL SPECIFICATIONS DOCUMENT

DATE: FEBRUARY 264, 2014

POLICY CHANGES AND ENDORSEMENTS

Document Control

Version Date Status: Author Comment / Changes from Prior Version

<Draft/
Final>
01 28th Jan 2014 Draft Initial Draft for GL Assignment

Table of Content

PAGE 2 OF 10
POLICY CHANGES AND ENDORSEMENTS

s
1 End to End Functional overview..............................................................................................................................................5
1.1 Glossary........................................................................................................................................................................... 6
2 Functional Specification – GL Assignment..............................................................................................................................6
2.1 Requirements................................................................................................................................................................... 6
2.2 Overview.......................................................................................................................................................................... 7
2.3 Detailed Description....................................................................................................................................................... 11
2.4 User Interface Details.....................................................................................................................................................16
2.5 Business Rules / Calculations.........................................................................................................................................16
2.6 Assumptions................................................................................................................................................................... 16
2.7 Open Items.....................................................................................................................................................................16
2.8 Interfaces........................................................................................................................................................................16
2.8.1 Chart of Accounts Interface....................................................................................................................................16
2.8.2 GL Extract Download.............................................................................................................................................17
2.9 Use Case Model.............................................................................................................................................................19
2.9.1 Use Cases...............................................................................................................................................................19
3 Non Functional Requirements................................................................................................................................................25
3.1 Operational..................................................................................................................................................................... 25
3.2 Performance................................................................................................................................................................... 25
3.3 Audit.............................................................................................................................................................................. 25
3.4 Regulatory...................................................................................................................................................................... 25
4 Appendix................................................................................................................................................................................ 25

Figure 1 – Logical Data Model of Financial Transactions in the System.........................................................................................9

Figure 2 – Distribution Code UI.....................................................................................................................................................10
Figure 3 – Generate Journal Entries...............................................................................................................................................12
Figure 4 – Use Case Model............................................................................................................................................................ 17

List of Tables
No table of figures entries found.

PAGE 3 OF 10
POLICY CHANGES AND ENDORSEMENTS

1 END TO END FUNCTIONAL OVERVIEW

The purpose of this document is to provide an outline of the overall high-level functionality to be
implemented to fulfill the end to end business requirements of the CyberSource project with respect to
the following Level 1 & 2 business processes:
 Merchant Setup
o Manage Setup
 Setup Clients Systemic
 Manage Billing / Invoicing / AR Configuration
 Manage Invoice Line / GL / Mapping
 Setup FX Rates
1.1 Glossary
ORMB Object Description
Person Represents the Merchant
MID Usage Account Represents the account where transactions are stored

2 FUNCTIONAL SPECIFICATION – GL ASSIGNMENT

2.1 Requirements
The requirements listed below are a representation of the requirements covered in the GL
Assignment section. For the complete list of business requirements and descriptions please refer
to the Business Requirements Document or the Fit / Gap Document.

Process Req # Requirements Description Notes

Maintain General Ability for the system to automatically interface billing
Ledger GLE4 and AR activities with GL on a daily basis
Maintain General Ability to support GL revenue mapping recognize
Ledger GLE6 revenue by geography and product; Geography = Country Code
Interface INT5 Ability to interface with Visa GL Outbound and Inbound Interface

2.2 Overview
This section describes the GL Interface which provides system accounting transaction data, in the
form of a sequential file, to the GIFS application. This interface will provide billed revenue,
payments and adjustments GL information to GIFS.
Below is a logical data model of financial transactions in the System.  Every payment segment, bill
segment, and adjustment creates one financial transaction record, which is linked to multiple
financial transaction general ledger lines.  The number of general ledger lines depends on the
segregation of charges set up for that financial transaction. 
 

PAGE 4 OF 10
POLICY CHANGES AND ENDORSEMENTS

Figure 1 – Logical Data Model of Financial Transactions in the System

The following table lists the major financial events, their standard accounting, and the source of
distribution codes used to derive the GL accounts sent to the general ledger and the dates of GL posting.
Financial Event Financial Event GL Accounting Source Of GL Dating
Category Distribution Code
Bill Create a bill segment Debit: A/R Contract Type Bill Cycle Date
(creating an invoice) (last date of the
month) or
Credit: Revenue Rate Component
invoice date for
ad-hoc
Adjustment Create AP segment Debit: Commission Adjustment Type Bill Cycle Date
Expense (last date of the
Credit: A/P A/P Contract Type month) or
invoice date for
Credit: A/R Contract Type
ad-hoc

2.3 Detailed Description

PAGE 5 OF 10
POLICY CHANGES AND ENDORSEMENTS

Figure 2 – Generate Journal Entries

2.4 User Interface Details

N/A

2.5 Business Rules / Calculations

Rule # Business Rule

PAGE 6 OF 10
POLICY CHANGES AND ENDORSEMENTS

1 The FERIS internal exchange rate for conversion is the rate effective on the financial
transaction date
2 The validation of the chart of account GL strings must be done against Active GL strings

2.6 Assumptions
1. N/A GL string validation will happen at the time of GL extract
2.7 Open Items
Confirm if Intercompany Transfers requirement(s) are out of scope.
1. Need a list of the values for Cost Center
2. GL extract example from PlaySpan
3. Can Siebel send the ISO country code instead of country name?
4. What information is CMLS loading for PlaySpan today for the COA. Do we need additional
information loaded for CyberSource?

2.8 Interfaces
2.8.1 Chart of Accounts Interface
The Chart of Accounts coming from the GIFS will be interfaced to a staging table in the system
by Ab Initio. This will be used to allow the system to validate the Financial Transaction GL Strings
created against the valid Chart of Accounts. This is an incremental data only (All rows that have
LAST_UPDATED_DATE greater than the previous execution date/time of the program). This
interface will be re-used from PlaySpan.
2.8.1.1 Data Attributes
# Attribute Name Description Value Validations Mandatory
1 CODE_COMBINATION_ID ID Left pad with ‘0’
2 START_DATE_ACTIVE Start Date YYYYMMDD
3 END_DATE_ACTIVE End Date YYYYMMDD
4 SEGMENT1 Entity
5 SEGMENT2 Account
6 SEGMENT3 Cost Center
7 SEGMENT4 Activity
8 SEGMENT6 Product
9 SEGMENT7 Service
10 SEGMENT5 Country
11 SEGMENT8 Intercompany
12 SEGMENT9 Regional
13 ENABLED_FLAG Active/Inactive Y/N
2.8.1.2 Frequency
This would be a scheduled daily batch interface, to run before the deriving the GL
stringassignment job. This process can also be manually run.

PAGE 7 OF 10
POLICY CHANGES AND ENDORSEMENTS

2.8.1.3 Validations
1. Ab Initio validates the file format and does not process if file format is invalid.
2. System performs validation on fields marked above
2.8.1.4 Error Handling
1. N/A The batch would stop processing if any records are in error
2. The batch would set the status of the record as an error if any mandatory fields are
missing. A To-do would be created for an IT user to review the error records notify Rev
Ops and manually manage correcting the errors. .When the error is corrected the batch
can be re-run.
2.8.1.5 Assumptions
1. CMLS inserts the Chart of Account data into the Staging table.
2. System will use the data in this table to validate the GL Chart of Account during Financial
Transaction GL Account creation.

2.9 Use Case Model

Figure 3 – Use Case Model

2.9.1 Use Cases

2.9.1.1 UC1 – Configure product GL distribution codestring

Name Configure product GL distribution codestring

Covers the configuration of one component of the GL string setup at the Product
Description Level
Process Map ID 1.1.3 – Manage Invoice Line / GL Mapping
Requirement SET19, SET26, SET27
Assumptions No approval required, Products are linked to the merchant
Actors System, AnalystBilling IT Support
Product is set up, Merchant, Legal Entity and Distribution Code GL String
components already defined Rev Ops opens a ticket for Billing IT Support to
Pre- Conditions create or update Product
Product is assigned a 36 digit code to be used as part of the GL string, Rev Ops
Post Condition reviews product GL string and closes Ticket

PAGE 8 OF 10
POLICY CHANGES AND ENDORSEMENTS

Basic Flow
Use Case Busines Commen
Step Description Actor s Rule ts
Open product UI Billing IT N/A N/A
1.1 SupportAnaly
st
Open the product record Billing IT N/A N/A
1.2 SupportAnaly
st
Add a characteristic for product GL stringAssign Billing IT N/A N/A
1.3 GL string product distribution code SupportAnaly
st
Save changes Billing IT N/A N/A
1.4 SupportAnaly
st
System runs validation for the entire GL string System N/A N/A
against the Oracle GL valid chart of accounts GL
strings. Below indicates where the different
components are defined to create the GL
String.
Example:
731.524650.76001.00000.000.840.000.000.000
00000 where
731 – Legal Entity – Defined at the Division
524650 – Account – Defined at the Distribution
Code
1.5 76001 – Cost Center – Defined at the
Distribution Code
00000 – Activity – Defined at the Distribution
Code
000 – Inter Company – Defined at the
Distribution Code
840 – Country – Defined at the Merchant
000 – Product – Defined at the Product
000 – Service – Defined at the Distribution
Code
00000000 – Region – Defined at the
Distribution Code
1.6 GL string validation is successful and saved System N/A N/A
‍
1.57 Use Case Ends System N/A N/A

PAGE 9 OF 10
POLICY CHANGES AND ENDORSEMENTS

3 NON FUNCTIONAL REQUIREMENTS

3.1 Operational
Requirement SET29: Ability for the system to accept Siebel configuration for merchant data in UTF
8 character set and pass to invoice as is.

A process to periodically clean up the Merchant interface table (clean up all processed records
older then X number of days and all In error records older then Y number of days)
3.2 Performance
N/A

3.3 Audit
N/A

3.4 Regulatory
N/A

4 APPENDIX
N/A

PAGE 10 OF 10