Adjustment Operation: Software Requirements Specification

Adjustment Operation
Software Requirements Specification
Product Baseline PAY 3.4

Document Version 02.00
Status Approved
Reference eSGE_SRS_FR1-002662-07_EN
Distribution Confidential
Adjustment Operation: Software Requirements Specification
Version control
Author Version Comments Date

T. Papot 00.01 Initial draft version 2016-09-02
T. Papot 00.02 Update after MGU remarks 2016-09-19
T. Papot 01.00 Release version 2016-10-04
T. Papot 01.01 Update version after FDE remarks 2016-10-26
T. Papot 02.00 Approved by Product Management version 2016-11-07
Document purpose
This document specifies the requirements for the software release in the scope of the project defined below. It
constitutes the Technical Engagement of Engineering to Services Delivery and Product Management.
SRS provides a complete functional description of the system behavior as well as non-functional requirements that could
constraint the software design or its implementation (such as performance requirements, security, reliability, or quality
standard). This document does not define the requirements for ongoing tasks such as system backup or maintenance.
It is to be read in conjunction with the User and Administration Guides of each product baseline impacted by the project.
Document Scope
This SRS document plus eventual "Form Ds" to answer CRs constitute the main technical reference for the project:
Adjustment Operation/FR1-002662-07
It is not feasible for an SRS document to reproduce all the product features so it will provide requirements in delta mode.
Audience
This document is intended for:
 eServGlobal Project Staff
 the Customer's Project Staff
Due to documentation in iterative mode the documentation assumes that the person reading this has already the
knowledge of the system.
Reviewers
Name/Function: <name> / Engineering Architect (when EA is not the author)
Review Date: dd mmm ccyy
Name/Function: Manuel Guzman / Senior Technical Manager
Review Date: 4th October 2016
Name/Function: Francis Delhaye / Product Manager (for Features or Product Validation project)
Review Date: 04 November 2016
Reference : eSGE_SRS_FR1-002662-07_EN Version: 02.00 Page: 2/44
eServGlobal Proprietary – Confidential Document
Please consider environment before printing this document

Name/Function: <name> / Solution Architect (from Services Department)
Review Date: dd mmm ccyy
Approval
Name/Function: <name> / Engineering Project Manager
Approval Date:
Document Filename
478429894.docx
Reference Documents
Reference Title
[1] eSGP_SCD_PayMobile_TierInitiatedMoneyTra Solution Concept Document from Product Management
nsfers_E00.04
Copyright
This document contains proprietary, confidential, or customer-sensitive information, and may not be copied or circulated
without prior approval. Those who rightfully receive this document are entitled to copy or multiply this document only for
internal use.

Table of Contents
2.1 GENERAL............................................................................................................................................. 7
2.2 PROJECT SCOPE.................................................................................................................................. 7
3.1 OVERVIEW........................................................................................................................................... 8
3.2 ADJUSTMENT OPERATION..................................................................................................................... 8
4.1 HIGH LEVEL ARCHITECTURE............................................................................................................... 29
4.2 ARCHITECTURE DESCRIPTION............................................................................................................. 29
5.1 TRAFFIC ASSUMPTIONS...................................................................................................................... 30
5.2 DIMENSIONING RULES........................................................................................................................ 30
5.3 PLATFORM MAXIMUM CAPACITY.......................................................................................................... 30
6.1 GENERAL HARDWARE REQUIREMENTS................................................................................................ 31
6.2 GENERAL PACKAGE REQUIREMENTS................................................................................................... 31
6.3 DOCUMENTATION REQUIREMENTS....................................................................................................... 31
6.4 INSTALLATION AND UPGRADE REQUIREMENTS.....................................................................................31
6.5 PRODUCT INTEROPERABILITY/COMPATIBILITY REQUIREMENTS..............................................................32
7.1 MANAGEMENT GUI............................................................................................................................. 33
7.2 FAULT MANAGEMENT.......................................................................................................................... 33
7.3 STATISTICS........................................................................................................................................ 33
7.4 EVENT DETAIL RECORDS.................................................................................................................... 33
7.5 SERVICE REPORTS............................................................................................................................. 33
8.1 SCALABILITY....................................................................................................................................... 34
8.2 REDUNDANCY AND HIGH AVAILABILITY................................................................................................. 34
8.3 DISASTER & RECOVERY..................................................................................................................... 34
8.4 BACK-UP POLICY................................................................................................................................ 34
9.1 <COMPONENT> CONFIGURATION........................................................................................................ 35
10.1 SERVICE AVAILABILITY........................................................................................................................ 36
10.2 GUI SECURITY................................................................................................................................... 36
10.3 PLATFORM SECURITY......................................................................................................................... 36

Conventions and Terminology

Requirement Format
This document contains a series of bulleted, tagged and testable requirements. These are of the format: R-
XXX-number. In this document, XX stands for the specific requirement category, and is an arbitrary label
grouping functionality for clarity.
Non-tagged text is included for clarification purposes. The tagged requirements shall constitute the complete
set of customer requirements that are to be met. Verification of the tagged requirements shall constitute the
complete acceptance of the project by 02.00.
Responsibility for completion of all sections of this document rests with eServGlobal and its subcontractors,
except where a section heading explicitly states otherwise.
R-XXX-10: This is an example of the numbering of a requirement.
Icons
The following icons are used as visual cues to draw attention to important information.
Note:
Indicates useful and complementary information. Explanation, comment, or short expansion of the
text object that is intended to catch your attention.
Tip:
Indicates practical but non-essential information that makes the solution easier to use or operate (e.g.
keyboard shortcut, alternative way to perform a step in a procedure, etc.).
Warning:
Indicates a caution. If this information is ignored, it could cause possible and irreversible damage to
the equipment, data or software.

1 Glossary of Terms and Acronyms

TERM DESCRIPTION

2 Introduction
2.1 General
The solution will provide the Adjustment operation which will allow a third party to transfer money from
anyone’s balance to any other balance having the same currency in order to solve financial issues or handle
services needing third party initiated transfers.
2.2 Project scope

The scope of the project is to provide an Adjustment operation which will allow third initiated transfers that
can be approved. The operation will use a generic template already implemented for eRetail Transfer and
Domestic Transfer. The Adjustment operation will be managed in CC Admin Web GUI or via Batch file.

3 Functional Requirements
3.1 Overview
The Adjustment operation is money transfer between Party A and Party B but initiated by Party C.
The operation is mainly used to do administration of Ledger accounts, perform correction or manual refund.
3.2 Adjustment Operation
3.2.1 Description
The Adjustment operation is a financial operation where the requester is able to perform a money transfer
between 2 other actors.
Based on requester profile configuration, the adjustment operation could require approval.
The Adjustment operation must be available either via CC_ADMIN Web GUI or via Batch files.
3.2.2 Use Cases

A financial manager is transferring money from Tax Ledger account to Main Ledger account.
A Privileged Customer Care agent is performing a Manual refund of a specific operation.
3.2.3 Sequence Diagrams

3.2.4 Web GUI Requirements
3.2.4.1 Adjustment Screen
Figure 1 – Adjustment Operation screen
R-ADJ-0010: The CC Admin Web GUI provides access to the Adjustment feature through the
“Adjustment” item of the “Mobile Money” group of the “Point Of Sales” service.
R-ADJ-0020: Access to the Adjustment screen is subject to permission.
The adjustment page of CC Admin Web GUI will propose to enter the identifier of the debited actor.
R-ADJ-0030: In the Adjustment screen, one must provide the debited identifier of the actor which
will provide the money to be transferred.
In the Adjustment screen, the Debited identifier can be:
 R-ADJ-0040: Actor Id
 R-ADJ-0050: username
 R-ADJ-0060: Tsn
 R-ADJ-0070: MSISDN

 R-ADJ-0080: Shortcode
R-ADJ-0090: In the Adjustment screen, one can trigger the search of the debited identifier.
R-ADJ-0100: In the Adjustment screen, if several actors match the debited identifier, a dialog pops
up asking to select which one had to be used.
R-ADJ-0110: In the Adjustment screen, if the debited identifier retrieval is successful, the public
identifier of the debited party must be displayed.
Once the debited source of fund information is retrieved, the list of debited source of funds is displayed.
The agent selects one of the debited sources of fund.
R-ADJ-0120: In the Adjustment screen, if the debited identifier retrieval is successful, the list of
available Sources of fund of the debited party. By default the Source of fund with the
higher preference (minimal rank number) is selected.
R-ADJ-0130: In the Adjustment screen, when displaying the list of available sources of fund of the
debited party, the following information must be displayed for each source of fund:
 Source of fund name

 Currency Name
 Current balance value (for internal balances)
R-ADJ-0140: In the Adjustment screen, if the debited identifier retrieval fails, an error dialog pops
up. The entered information is preserved so one can correct it.
R-ADJ-0150: In the Adjustment screen, one must provide the amount of the adjustment operation
in the currency of the selected debited source of fund.
The agent is able to indicate if notification had to be sent to debited actor.
R-ADJ-0160: In the Adjustment screen, one must indicates if the debited party must receive a
notification. By default, the notification is sent.
The agent next enters the identifier of the beneficiary (credited) party.
R-ADJ-0170: In the Adjustment screen, one must enter the beneficiary identifier of the actor which
will receive the money.

In the Adjustment screen, the Beneficiary identifier can be:
 R-ADJ-0180: Actor Id
 R-ADJ-0190: username
 R-ADJ-0200: Tsn
 R-ADJ-0210: MSISDN
 R-ADJ-0220: Shortcode
R-ADJ-0230: In the Adjustment screen, one can trigger the search of the beneficiary identifier.
R-ADJ-0240: In the Adjustment screen, if several actors match the beneficiary identifier, a dialog
pops up asking to select which one had to be used.
R-ADJ-0250: In the Adjustment screen, if the beneficiary identifier retrieval is successful, the public
identifier of the Beneficiary must be displayed.
Once the credited source of fund information is retrieved, the list of credited source of funds is displayed.
The agent selects one of the credited sources of fund.
R-ADJ-0260: In the Adjustment screen, if the beneficiary identifier retrieval is successful, the list of
available Sources of fund of the beneficiary of the same currency as the debited party
must be displayed. By default the Source of fund with the higher preference (minimal rank
number) is selected.
R-ADJ-0270: In the Adjustment screen, when displaying the list of available sources of fund of the
beneficiary, the following information must be displayed for each source of fund:
 Source of fund name

 Currency Name
 Current balance value (for internal balances)
R-ADJ-0280: In the Adjustment screen, if the beneficiary identifier retrieval fails, an error dialog
pops up. The entered information is preserved so one can correct it.
The agent is able to indicate if notification had to be sent to credited actor.
R-ADJ-0140: In the Adjustment screen, one must indicates if the beneficiary party must receive a
notification. By default, the notification is sent.

R-ADJ-0280: In the Adjustment screen, one can enter a comment to the operation.
Once the agent has validated the operation, a verification screen is displayed where the agent is able to
confirm the operation or to modify it.
R-ADJ-0290: In the Adjustment screen, one has the possibility to cancel the adjustment operation.
The Adjustment screen is then displayed and previous information is cleared.
R-ADJ-0300: In the Adjustment screen, one has the possibility to validate the adjustment operation.
The Adjustment Verification screen is then displayed.
Figure 2 – Adjustment Verification Operation screen
In the Adjustment Verification screen, one can see:
 R-ADJ-0310: the Beneficiary Public Name
 R-ADJ-0320: the selected Beneficiary source of fund.
 R-ADJ-0330: the amount to be transferred including the associated currency.
 R-ADJ-0340: the amount of Service Charge including currency associated.

 R-ADJ-0341: The VAT value including the currency when using a non-monetary SoF
 R-ADJ-0342: The indicative public price including the currency when using a non-monetary
SoF
 R-ADJ-0350: if the Credited actor will receive a notification.
 R-ADJ-0360: the Debited party Public Name
 R-ADJ-0370: the selected Debited Party source of fund.
 R-ADJ-0380: if the Debited actor will receive a notification.
 R-ADJ-0390: the comment of the adjustment operation.
In the Adjustment Verification screen, one has the possibility to:
 R-ADJ-0400: cancel the Adjustment. The Adjustment screen is then displayed and previous
information is cleared.
 R-ADJ-0410: modify the adjustment. The Adjustment Screen is then displayed and previous
information is preserved so one can modify it.
 R-ADJ-0420: confirm the Adjustment.
R-ADJ-0430: If the Adjustment operation is successful, the Adjustment receipt dialog pops up.
R-ADJ-0440: If the Adjustment operation fails, an error dialog pops up. The entered information is
preserved so one has the possibility to retry or cancel the Adjustment.
In the Adjustment operation result popup, one can see:
 R-ADJ-0450: the operation name performed
 R-ADJ-0460: the requested amount to transfer including the currency
 R-ADJ-0470: the status of the operation
 R-ADJ-0480: the date
 R-ADJ-0490: the beneficiary identifier
 R-ADJ-0500: the beneficiary source of fund
 R-ADJ-0510: the beneficiary delta including the currency which is the same as the
Beneficiary Source of fund currency
 R-ADJ-0520: the identifier of the payer
 R-ADJ-0530: the payer source of fund
 R-ADJ-0540: the payer delta including the currency which is the same as the payer Source
of fund currency
 R-ADJ-0550: the list of Taxes, Fees and Commissions

SoF
 R-ADJ-0560: the operation id
 R-ADJ-0570: the comment
In the Adjustment operation result popup, in list of Taxes, Fees and Commissions, one can see:
 R-ADJ-0590: the Taxes, Fees and Commissions type
 R-ADJ-0600: the Taxes, Fees and Commissions amount including the currency
 R-ADJ-0610: the Taxes, Fees and Commissions Payer identifier
 R-ADJ-0620: the Taxes, Fees and Commissions Beneficiary identifier
R-ADJ-0630: In the Adjustment operation result popup, one has the possibility to print the receipt
of the Adjustment operation.
R-ADJ-0640: In the Adjustment operation result popup, when closing the popup, the Adjustment
operation default screen is then displayed
3.2.4.2 Financial Operation Approval Screen
To manage the Adjustment Approval screen, a new generic screen will be created. This screen will be able
to display approval for whatever financial operation.
The Generic Approval page of Self-care Web GUI will propose to approve financial operations.
The generic Approval page will retrieve the list of financial operation Approval which are pending and display
it.

Figure 3 – Financial Approval screen
R-ADJ-1000: The Self Care Web GUI provides access to the Financial Approval feature through the
“Financial Operation” item of the “Approval Mobile Money” group of the “Administration”
service.
R-ADJ-1010: Access to the Financial Operation approval screen is subject to permission.
R-ADJ-1020: In the Financial Operation Approval screen, one must see the list of financial
operations which has to be approved by the current logged user. The current logged user
must be a member of a financial approval Group to see any operation.
In the list of financial operations to be approved, one must see:
 R-ADJ-1030: the Operation Type.
 R-ADJ-1040: the Operation Date.
 R-ADJ-1050: the Public Identifier of the Initiator.
 R-ADJ-1060: the Public Identifier of the Sender.
 R-ADJ-1070: the Public Identifier of the Beneficiary.
 R-ADJ-1080: the transaction Amount including the Currency.
R-ADJ-1090: In the Financial Operation Approval screen, one must be able to select one financial
operation to approve.

R-ADJ-1100: In the Financial Operation Approval screen, when selecting an Adjustment operation
to approve, an Adjustment detail Dialog pops up.
Figure 4 – Adjustment Approval Detail dialog
In the Adjustment Approval Detail Dialog, one can see;
 R-ADJ-1110: the operation name.
 R-ADJ-1120: the amount of the Adjustment operation.
 R-ADJ-1130: the current status of the Adjustment operation.
 R-ADJ-1140: the date of the Adjustment operation.
 R-ADJ-1150: the public identifier of the initiator (requester) of the Adjustment operation.
 R-ADJ-1160: the public identifier of the Beneficiary party.
 R-ADJ-1170: the Source of fund of the Beneficiary party.
 R-ADJ-1180: the delta amount of the Beneficiary party.
 R-ADJ-1190: the public identifier of the Payer (Sender) party.
 R-ADJ-1200: the Source of fund of the Payer (Sender) party.
 R-ADJ-1210: the delta amount of the Payer (Sender) party.

 R-ADJ-1220: the list of Tax/Fees/Commissions of the Adjustment operation.
 R-ADJ-1230: the operation Id of the Adjustment operation selected.
 R-ADJ-1240: the Comment of the Adjustment operation selected.
SoF
In the Adjustment Approval Detail Dialog, in the list of Tax/Fees/Commission of the Adjustment
operation, one can see:
 R-ADJ-1250: the type of the line: TAX, FEE or COMMISSION.
 R-ADJ-1260: the amount of the line including currency name.
 R-ADJ-1270: the public identifier of the Payer of the line.
 R-ADJ-1280: the public identifier of the Beneficiary of the line.
R-ADJ-1290: In the Adjustment Approval Detail Dialog, one has the possibility to cancel the
adjustment approval operation. The Adjustment Detail Dialog is closed and the previous
Adjustment Approval screen is then displayed with previous information.
In the Adjustment Approval Detail Dialog, one has the possibility to:
 R-ADJ-1300: reject the adjustment operation. The Adjustment Detail Dialog is closed and
the previous Adjustment Approval screen is then displayed with the line previously rejected
removed from the list.
 R-ADJ-1310: approve the adjustment operation. The Adjustment Detail Dialog is closed and
the previous Adjustment Approval screen is then displayed with the line previously approved
removed from the list.
3.2.4.3 Financial Operation Approval History Screen

The Financial Operation Approval History Screen allows an actor to display the list of financial operations
which have previously been approved or rejected.

Figure 5 – Financial Operation Approval History screen
R-ADJ-1500: The Self Care Web GUI provides access to the Financial Operation Approval History
feature through the “Financial Approval History” item of the “Approval Mobile Money”
group of the “Administration” service.
R-ADJ-1510: Access to the Financial Operation approval History screen is subject to permission.
In the Financial Operation Approval History screen, one must select:
 R-ADJ-1515: the kind of Operation Type he wants to see.

 R-ADJ-1520: the kind of decision approval he wants to see.
 R-ADJ-1530: the start date of the financial operation where he wants to see history.
 R-ADJ-1540: the end date of the financial operation where he wants to see history.
R-ADJ-1545: In the Financial Operation Approval History screen, the Operation Type criteria must
be one financial operation or ALL (meaning all financial operations):
R-ADJ-1550: In the Financial Operation Approval History screen, the decision criteria must be one
of the following:
 APPROVED
 REJECTED
 ALL: include APPROVED + REJECTED

R-ADJ-1560: In the Financial Operation Approval History screen, one is able to display the list of
past Financial Operation approval by triggering the Search button.
In the Financial Operation Approval History screen, in the list of past Financial operation approval by
his approval group, one must see:
 R-ADJ-1565: Operation Type of the approval.
 R-ADJ-1570: Decision taken.
 R-ADJ-1580: the date of the Decision.
 R-ADJ-1590: the Identifier of the Financial Transaction.
 R-ADJ-1600: the date of the financial operation.
 R-ADJ-1640: the Transaction Amount including the Currency.
R-ADJ-1700: The CC Admin Web GUI provides access to the SP Financial Operation Approval
History feature through the “Financial Approval History” item of the “Approval history”
group of the “Administration” service.
R-ADJ-1710: Access to the SP Financial Operation approval History screen is subject to

permission.
In the SP Financial Operation Approval History screen, one must select:
 R-ADJ-1715: the kind of Operation Type he wants to see.

 R-ADJ-1720: the kind of decision approval he wants to see.
 R-ADJ-1730: the start date of the financial operation where he wants to see history.
 R-ADJ-1740: the end date of the financial operation where he wants to see history.
R-ADJ-1745: In the SP Financial Operation Approval History screen, the Operation Type criteria
must be one financial operation or ALL (meaning all financial operations):
R-ADJ-1750: In the SP Financial Operation Approval History screen, the decision criteria must be
one of the following:
 APPROVED
 REJECTED
 ALL: include APPROVED + REJECTED

R-ADJ-1760: In the SP Financial Operation Approval History screen, one is able to display the list
of past Financial Operation approval by triggering the Search button.
In the SP Financial Operation Approval History screen, in the list of past Financial operation approval
by his approval group, one must see:
 R-ADJ-1765: Operation Type of the approval.
 R-ADJ-1770: Decision taken.
 R-ADJ-1780: the date of the Decision.
 R-ADJ-1790: the Identifier of the Financial Transaction.
 R-ADJ-1800: the date of the financial operation.
 R-ADJ-1840: the Transaction Amount including the Currency.
 R-ADJ-1850: the Approver public identifier
3.2.5 Business Services Requirements
3.2.5.1 Business Logic
eMoney Transfer Business Service
R-ADJ-2000: eMoney Transfer endpoint provides a SOAP method backed by a business process to
perform an Adjustment.
R-ADJ-2010: Adjustment Business Service takes the following information in input:
 identifiers of the debited and credited parties

 identifiers of the debited source of funds
 identifiers of the credited source of funds (Optional)
 amount (including currency) to be transferred
 comment
 notification flags for debited actor and credited actor
R-ADJ-2020: Adjustment Business Service performs the following consistency checks:
 debited party exists

 credited party exists
 debited source of fund exists and is owned by debited party

 credited source of fund, if provided, exists and is owned by credited party

 debited and credited sources of funds are of the same currency than the amount to transfer
R-ADJ-2030: Adjustment Business Service must use the standard “Transfer” template to manage
the financial transaction.
R-ADJ-2040: In case of success, Adjustment Business Service uses the notification flags to
determine if a notification must be sent.
R-ADJ-2050: In case of success, Adjustment Business Service returns following information:
 standard receipt
 human task information (in case of approval)
R-ADJ-2060: In case of failure, Adjustment Business Service returns a Web Service Exception
R-ADJ-2070: eMoney Transfer endpoint provides a SOAP method backed by a BPEL business
process to perform an Adjustment Approval.
R-ADJ-2080: Adjustement Approval Business Service must use the standard “TransferApproval”
template to manage the financial transaction.
Approval Group Business Service
R-ADJ-2100: Approval Group endpoint provides a SOAP method backed by a BPEL business
process to retrieve the list of Pending Financial operation
(getApprovalGroupPendingFinancial).
R-ADJ-2110: getApprovalGroupPendingFinancial BPEL takes the following information in input:
 service
 operation Type
 Language Code
R-ADJ-2120: getApprovalGroupPendingFinancial BPEL performs the following consistency

checks:
 Operation Type is equal to an approvable financial operation

 Language Code provided is defined in PayMobile
R-ADJ-2140: getApprovalGroupPendingFinancial BPEL performs the following operations:
 Retrieve the list of Financial operations which have to be approved by the approval group of
the requester

R-ADJ-2150: In case of success, getApprovalGroupPendingFinancial BPEL returns following

information:
 Operation Id
 Financial operation information:
o Human Task Id (Optional)
o Decision
o Decision Date (Optional)
o Approver First name (Optional)
o Approver Last name (Optional)
o Approval Group Name (Optional)
o Operation Id (Optional)
o Operation Name
o Operation Date
o Operation Requester Id
o Operation Requester First Name
o Operation Requester Last Name
o Sender Actor Id (Optional)
o Sender First Name (Optional)
o Sender Last Name (Optional)
o Sender MSISDN (Optional)
o Receiver Actor Id (Optional)
o Receiver First Name (Optional)
o Receiver Last Name (Optional)
o Receiver MSISDN (Optional)
o Amount
o Currency Id
R-ADJ-2160: In case of failure, getApprovalGroupPendingFinancial BPEL returns a Web Service

Exception exception
R-ADJ-2170: In viewApprovalDecisionGlobalHistory BPEL, the Adjustment operation must be also

taken into account in the view
R-ADJ-2180: In viewGlobalPendingDecisionHistory BPEL, the Adjustment operation must be also

taken into account in the view
R-ADJ-2190: Approval Group endpoint provides a SOAP method backed by a business process to
retrieve the list of Approval Financial operation History operation
(viewApprovalFinancialDecisionHistory).
R-ADJ-2200: viewApprovalFinancialDecisionHistory Business Process takes the following

information in input:
 service

 operation Type
 decision (Optional)
 from
 to (Optional)
R-ADJ-2210: viewApprovalFinancialDecisionHistory Business Process performs the following

consistency checks:
 “From” must be before “To”

 If “To” is not provided, it is assumed that it is current date
 If “Decision” has been provided, it must be one of APPROVED or REJECTED
R-ADJ-2230: viewApprovalFinancialDecisionHistory Business Process performs the following

operations:
 Retrieve the list of financial operations matching input criteria which have been approved by
the approval group of the requester.
R-ADJ-2240: In case of success, viewApprovalFinancialDecisionHistory Business Process returns

following information:
 Operation Id
o Decision
o Operation Name
o Operation Date


o Amount
o Currency Id
R-ADJ-2250: In case of failure, viewApprovalFinancialDecisionHistory Business Process returns a

Web Service Exception exception
R-ADJ-2195: Approval Group endpoint provides a SOAP method backed by a business process to
retrieve the list of SP Approval Financial operation History operation
(viewAnyApprovalFinancialDecisionHistory).
R-ADJ-2205: viewAnyApprovalFinancialDecisionHistory Business Process takes the following

information in input:
 service
 operation Type
 decision (Optional)
 from
 to (Optional)
R-ADJ-2215: viewAnyApprovalFinancialDecisionHistory Business Process performs the following

consistency checks:
 “From” must be before “To”

 If “To” is not provided, it is assumed that it is current date
 If “Decision” has been provided, it must be one of APPROVED or REJECTED
R-ADJ-2235: viewAnyApprovalFinancialDecisionHistory Business Process performs the following

operations:
 Retrieve the list of financial operations matching input criteria which have been approved.
R-ADJ-2245: In case of success, viewAnyApprovalFinancialDecisionHistory Business Process

returns following information:
 Operation Id
o Decision


o Operation Name
o Operation Date
o Amount
o Currency Id
R-ADJ-2255: In case of failure, viewAnyApprovalFinancialDecisionHistory Business Process

returns a Web Service Exception exception
3.2.5.2 Transversal impacts
TFC
R-ADJ-2260: Adjustment financial transactions are subject to standard taxes, fees and commission
logic. They can be identified through the use of the EMONEY.ADJUSTMENT operation
type.
Limits
No limits apply to EMONEY.ADJUSTMENT operation
History
R-ADJ-2300: The information of each successful Adjustment is stored in an ADJUSTMENT

process. This process contains an ADJUSTMENT operation. The latter contains
exhaustive information from the financial transaction and the receipt. Both the process
and the operation assign the REQUESTER, SENDER and RECEIVER roles to the actor. In
case of approval, the process contains an additional ADJUSTMENT_APPROVAL
operation. This last operation will contain the detail of the approval.

R-ADJ-2310: The information of each failed Adjustment is stored in an ADJUSTMENT process. This
process contains an ADJUSTMENT operation. The latter contains information about the
input data and the error. If the error occurs on an approval step, the process contains an
ADJUSTEMENT operation.
Permissions
R-ADJ-2320: Adjustment execution is subject to permission EMONEY.ADJUSTMENT. Permission

check can be based on the REQUESTER, SENDER and RECEIVER roles.
Restrictions
Adjustment execution cannot be restricted in exclusive groups.
Reports
R-ADJ-2330: Adjustment financial transactions can be identified through the use of the
EMONEY.ADJUSTMENT operation type in the transaction reports.
R-ADJ-2340: Adjustment financial transactions EDRs will have the same format as the other
financial transactions EDRs and will contain the following information:
 Operation Id
 Operation Type
 Operation Article Id (Not used for Adjustment operation)
 Operation Article Quantity (Not used for Adjustment operation)
 Operation medium
 Operation State
 Transaction Amount
 Transaction VAT Amount
 Transaction FEE Amount
 Transaction Commission Amount
 Transaction Currency Name
 Transaction Public Price
 Transaction Vat Price
 Transaction Public Price Currency
 Transaction Creation date/time
 Requester actor detailed information including Profile Code, Actor Id, Identifier used in
transaction
 Debited actor detailed information including Actor Id, Identifier used in transaction
 Credited actor detailed information including Actor Id, Identifier used in transaction
 Debited Balance Id
 Credited Balance Id
 Balance Currency
 Delivered Subscriber (Not used for Adjustment)
 Transaction Error Status
 Comment

 Requester MSISDN
 Requester USERNAME
 Requester PROFILE
 Sender MSISDN
 Sender USERNAME
 Sender PROFILE
 Receiver MSISDN
 Receiver USERNAME
 Receiver PROFILE
 External Id List
 TRIGGER_RECHARGE_ID
 PMX_REWERD_ID
Notifications
R-ADJ-2350: Successful Adjustment notification uses notification templates having operation set
to EMONEY.ADJUSTMENT and role to SENDER. These templates can use following
pieces of information:
 operation id
 requested amount (including currency)
 debited amount (including currency)
 credited amount (including currency)
 debited wallet new balance (including currency)
 Beneficiary public identifier
 Debited Source of fund Name
 Credited source of fund name
 Requester public identifier
 Vat Price (including currency) for non-monetary account
 Public price (including currency) for non-monetary account
R-ADJ-2360: Successful Adjustment notification uses notification templates having operation set
to EMONEY.ADJUSTMENT and role to RECEIVER. These templates can use following
pieces of information:
 operation id
 requested amount (including currency)
 debited amount (including currency)
 credited amount (including currency)
 credited wallet new balance (including currency)
 Payer public identifier
 Debited Source of fund Name
 Credited source of fund name

 Requester public identifier

 Vat Price (including currency) for non-monetary account
 Public price (including currency) for non-monetary account
Configuration
Adjustment feature does not support specific configuration in this version.
3.2.6 Batch file Requirements

R-ADJ-2500: eMoney Adjustment endpoint provides a batch task to perform bulk adjustment
R-ADJ-2510: Bulk Adjustment input files contain following information for each Adjustment:
 Sender identifier: Either

o Sender Id (optional if Access and Access Type are provided)
or
o Sender Access (Optional if Sender Id is provided)

o Sender Access Type (Optional if Sender Id is provided)
 Sender Source of Fund Id Receiver identifier: Either
o Receiver Id (optional if Access and Access Type are provided)
or
o Receiver Access (Optional if Receiver Id is provided)

o Receiver Access Type (Optional if Receiver Id is provided)
 Receiver Source of Fund Id (Optional)
 Amount
 Currency name
 Sender Notification Flag (YES/NO)
 Receiver Notification Flag (YES/NO)
 Comment
R-ADJ-2520: In Bulk Adjustment the requester of the Adjustment operation will be a Batch user
defined in PayMobile configuration.
R-ADJ-2530: Bulk Adjustment output files contain following information for each Adjustment:

 Input information
 Operation Id
 Operation state: SUCCESS/FAILED/WAITING_FOR_APPROVAL
 Error Detail (Optional)
R-ADJ-2540: In Bulk Adjustment, for each Adjustment, the following consistency checks are done:
 If sender Id is not provided, Sender Access and Sender Access Type must be provided
 If Receiver Id is not provided, Receiver Access and Receiver Access Type must be provided
 If Source of fund Id is provided, it must be of the same currency than the amount
R-ADJ-2550: In Bulk Adjustment, for each Adjustment, if source of fund Id is not provided, it must
be computed based on currency, operation Type, Source of fund category (if provided)
and sub-Category (if provided) and source of fund Rank.
3.2.6.2 Transversal impacts
Approval
R-ADJ-2560: Bulk Adjustment can be subject to approval.
3.2.7 Profile Settings Requirements

Currently in Profiles settings, an administrator is able, for a specific profile, to define for each operation if the
operation must be approved or not and define the Approval group for each operation.
In order to be able to approve Adjustment and Adjustment operation by batch, the Profile Settings had to be
enhanced.
3.2.7.1 Web GUI
CC Admin Create Profile Page
R-ADJ-2700: In Create Profile Page of CC Admin Web GUI, the list of eMoney operations subject to
approval must be generated dynamically based on eMoney Operation Subject to approval
list provided by getComboBox operation
R-ADJ-2710: In Create Profile Page of CC Admin Web GUI, the list of eRetail operations subject to
approval must be generated dynamically based on eRetail Operation Subject to approval

CC Admin View Profile Page
R-ADJ-2800: In View Profile Page of CC Admin Web GUI, the list of eMoney operations subject to
R-ADJ-2810: In View Profile Page of CC Admin Web GUI, the list of eRetail operations subject to
CC Admin Modify Profile Page
R-ADJ-2900: In Modify Profile Page of CC Admin Web GUI, the list of eMoney operations subject to
R-ADJ-2910: In Modify Profile Page of CC Admin Web GUI, the list of eRetail operations subject to
Profile Business Service: addProfile
R-ADJ-3000: in addProfile operation of Profile Business Service, the input parameters will be
modified as followed:
 Requester Information
 ExternalIdList
 requestPropertyList
 Profile:
o Code
o State
o DomainId
o actorType
o kycTemplate
o publicIdentifier
o shortCode
o Medium List
o Access Type List
o Internationalization List (Profile Name in all languages)
o Temporary Profile Id (Optional)

o OTP required List

o Approval operation List
 Approval Operation Type
 Approval Group
R-ADJ-3010: in addProfile operation of Profile Business Service, the new Adjustment approval
operations must be managed in a generic way and must be stored in Profile properties in
a generic way (at least for Adjustment operation for this project in order to not impact
other approved operations).
Profile Business Service: getProfile
R-ADJ-3100: in getProfile operation of Profile Business Service, the output parameters will be
 Operation Id
 Profile:
o Profile Id
o Code
o State
o DomainId
o actorType
o kycTemplate
o publicIdentifier
o shortCode
o Medium List
o Access Type List
o Last Update
o OTP required List
 Approval Group
R-ADJ-3110: in getProfile operation of Profile Business Service, the new Adjustment approval
operations must be managed in a generic way and must be retrieved from Profile
properties in a generic way (at least for Adjustment operation for this project in order to
not impact other approved operations).
Profile Business Service: updateProfile
R-ADJ-3200: in updateProfile operation of Profile Business Service, the input parameters will be

 Requester Information
 ExternalIdList
 Profile:
o Profile Id
o Code
o State
o DomainId
o actorType
o kycTemplate
o publicIdentifier
o shortCode
o Medium List
o Access Type List
o Last Update
o OTP required List
 Approval Group
R-ADJ-3210: in UpdateProfile operation of Profile Business Service, the new Adjustment approval
operations must be managed in a generic way and must be retrieved from Profile
properties in a generic way (at least for Adjustment operation for this project in order to
not impact other approved operations).
3.2.8 Combo Requirements

New combo Types will be added in order to provide the list of operations which can be approved (used in
Profile creation or modification)

R-ADJ-3500: in getComboBox operation of Combo Business Service, one must be able to retrieve
the list of eMoney operations which are subject to approval.
R-ADJ-3510: in getComboBox operation of Combo Business Service, one must be able to retrieve
the list of eRetail operations which are subject to approval.

4 Architecture
4.1 High Level Architecture
4.2 Architecture Description
4.2.1 Supported Networks

No impact.
Same as it’s currently.
4.2.2 Supported external interfaces

The interfaces required for the solution are summarized below:
INTERFACE PROTOCOL DESCRIPTION REF

HTTPS It’s highly recommended to secure SOAP exchange via HTTPS

1
as login/password transmitted in clear in the SOAP request

5 Solution dimensioning
5.1 Traffic Assumptions
5.2 Dimensioning Rules

5.3 Platform Maximum Capacity


6 Software System Requirements

This section defines the generic requirements, which apply to the whole system. These refer to the nature of
the components that will be provided, the key network protocols, which they will support, and defines key
approaches to hardware and software implementation, which apply to the entire system.
6.1 General Hardware Requirements

R-GHR-10 Priority : P0
Packages must be compliant with x86 platforms.
6.2 General Package Requirements

Will be defined in the Global Solution definition
6.3 Documentation Requirements

R-DOC-10 Priority : P0
Business Services SOAP operations must be documented in the Business Services

SOAP Technical Guide.
Web GUI pages must be documented in the Web GUI User Guide.
Batch File must be documented in the Batch File User Guide.
6.4 Installation and Upgrade Requirements
6.4.1 Current Data Structures & Sizing

No specific requirement.

6.4.2 Tools Requirements

None
6.4.3 Migration Phasing

Not Applicable. No migration planed.
6.4.4 Fallback Strategy

6.4.5 Verification
6.5 Product Interoperability/Compatibility Requirements

None

7 Platform Management Requirements

This section defines requirements for the day-to-day mechanisms for managing and monitoring the
platforms. Base platform configuration is covered in the following section. Configuration of the service is
covered in a later section.
7.1 Management GUI

No impact.
7.2 Fault Management

R-FAULT-10 Priority : P0
SOAP Exception are used to report error occurs during SOAP Request Process
7.3 Statistics
No impact.
7.4 Event Detail Records

None
7.5 Service Reports

None

8 Performance & Failover

8.1 Scalability
No impact.
8.2 Redundancy and High Availability

No impact.
8.3 Disaster & Recovery

No impact.
8.4 Back-up Policy

No impact.

9 Platform Configuration Requirements

This section specifies the configuration to be done on the base platform. The service features are defined in
other sections.
9.1 <Component> Configuration

10 Integrity & Security

This section describes the requirements related to integrity checking for the system, such as cross-platform
data consistency and service availability. It also defines security requirements within the platform, and for
cross-platform communications.
10.1 Service Availability

No impact.
10.2 GUI Security

No impact.
10.3 Platform Security

No impact.

11

12 Statement of Compliance
REFERENCE DOCUMENT # SCD/CSR REQUIREMENT FEATURES SRS CROSS REFERENCE
[1] ADJUST-01 R-ADJ-2000
R-ADJ-2010
Adjustment SOAP
…
R-ADJ-2360
R-ADJ-0020
Adjustment Web GUI
…
R-ADJ-1640
R-ADJ-2510
Adjustment Bulk
…
R-ADJ-2560

---ooo---

Adjustment Operation: Software Requirements Specification

Uploaded by

Copyright:

Available Formats

Adjustment Operation: Software Requirements Specification

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Adjustment Operation: Software Requirements Specification

Uploaded by

Copyright:

Available Formats

Adjustment Operation

Software Requirements Specification

Product Baseline PAY 3.4

Author Version Comments Date

T. Papot 00.02 Update after MGU remarks 2016-09-19

T. Papot 01.00 Release version 2016-10-04

T. Papot 01.01 Update version after FDE remarks 2016-10-26

T. Papot 02.00 Approved by Product Management version 2016-11-07

This document is intended for:

 eServGlobal Project Staff

 the Customer's Project Staff

Review Date: dd mmm ccyy

Name/Function: Manuel Guzman / Senior Technical Manager

Review Date: 4th October 2016

Review Date: 04 November 2016

Reference : eSGE_SRS_FR1-002662-07_EN Version: 02.00 Page: 2/44

eServGlobal Proprietary – Confidential Document

Please consider environment before printing this document

Name/Function: <name> / Solution Architect (from Services Department)

Review Date: dd mmm ccyy

Reference : eSGE_SRS_FR1-002662-07_EN Version: 02.00 Page: 3/44

eServGlobal Proprietary – Confidential Document

Please consider environment before printing this document

Reference : eSGE_SRS_FR1-002662-07_EN Version: 02.00 Page: 4/44

eServGlobal Proprietary – Confidential Document

Please consider environment before printing this document

Conventions and Terminology

R-XXX-10: This is an example of the numbering of a requirement.

Reference : eSGE_SRS_FR1-002662-07_EN Version: 02.00 Page: 5/44

eServGlobal Proprietary – Confidential Document

Please consider environment before printing this document

1 Glossary of Terms and Acronyms

Reference : eSGE_SRS_FR1-002662-07_EN Version: 02.00 Page: 6/44

eServGlobal Proprietary – Confidential Document

Please consider environment before printing this document

2.2 Project scope

Reference : eSGE_SRS_FR1-002662-07_EN Version: 02.00 Page: 7/44

eServGlobal Proprietary – Confidential Document

Please consider environment before printing this document

3.2 Adjustment Operation

3.2.2 Use Cases

A Privileged Customer Care agent is performing a Manual refund of a specific operation.

3.2.3 Sequence Diagrams

Reference : eSGE_SRS_FR1-002662-07_EN Version: 02.00 Page: 8/44

eServGlobal Proprietary – Confidential Document

Please consider environment before printing this document

3.2.4 Web GUI Requirements

3.2.4.1 Adjustment Screen

Figure 1 – Adjustment Operation screen

R-ADJ-0020: Access to the Adjustment screen is subject to permission.

In the Adjustment screen, the Debited identifier can be:

Reference : eSGE_SRS_FR1-002662-07_EN Version: 02.00 Page: 9/44

eServGlobal Proprietary – Confidential Document

Please consider environment before printing this document

The agent selects one of the debited sources of fund.

 Source of fund name

The agent is able to indicate if notification had to be sent to debited actor.

Reference : eSGE_SRS_FR1-002662-07_EN Version: 02.00 Page: 10/44

eServGlobal Proprietary – Confidential Document