P a g e | 1
The Department of Justice & Constitutional Development: Guardians Fund Management System
SAP CRM and ECC: BUSINESS PROCESS DESIGN
Document Purpose
The intent of the Business Process Design (BPD) document is to map the Guardian’s Fund processes with the SAP Customer Relationship Management (“CRM”) solution. To further identify delta requirements or gaps and document the conceptual design of the to-be solution for the Guardian’s Fund. Administration of the Guardian’s Fund processes is done in the Customer Relationship Management system (CRM). The CRM will integrate with SAP ECC (PSCD-FI) for financial data processing.
P a g e | 2
PROJECT IDENTIFICATION
Project Name CPI Project Number
DoJ&CD – GFS PR18_004690
Customer Name Customer Number
Department of Justice 647311
SAP Project Manager Customer Project Manager
Mariette Viljoen Lucky Doncabe
DOCUMENT IDENTIFICATION
Author Document Location (repository/path/name)
Sampath Kumar Konduri
Version Status Date (YYYY-MM-DD)
1.0 Released to Customer for review 2019-01-29
REVISION HISTORY
Version Date Description
0.1 2018-10-15 DoJ&CD GFS Solution design initial version
0.2 2019-02-05 DoJ&CD GFS Solution design document
0.3 2019-02-11 DoJ&CD GFS Solution design document - updated
0.4 2019-02-14 DoJ&CD GFS Solution design document V0.4
0.5 2019-02-22 DoJ&CD GFS Solution design document V0.5
REVIEW AND APPROVAL
NAME AND DESIGNATION SIGNATURE DATE
Vinay Ramnath
DOJ&CD BUSINESS PROCESS OWNER
Gerda Marais
DOJ&CD BUSINESS PROCESS OWNER
Ntenga Maluleke
DOJ&CD BUSINESS ANALYST
Lucky Doncabe
DOJ&CD PROJECT MANAGER
Manduleli Mdudu
DOJ&CD PROJECT SPONSOR
Mariette Viljoen
SAP PROJECT MANAGER
P a g e | 3
Table of Contents SAP CRM AND ECC: BUSINESS PROCESS DESIGN ............................................................................................. 1
DOCUMENT PURPOSE .............................................................................................................................................. 1
PROJECT IDENTIFICATION ...................................................................................................................................... 2
DOCUMENT IDENTIFICATION ................................................................................................................................... 2
REVISION HISTORY ................................................................................................................................................... 2
REVIEW AND APPROVAL ......................................................................................................................................... 2
BACKGROUND ........................................................................................................................................................... 6
LOCATIONS WHERE THIS BUSINESS PROCESS IS PERFORMED ...................................................................... 8
DATA MIGRATION ...................................................................................................................................................... 8
1. FUNCTIONAL SOLUTION DESIGN ................................................................................................................. 9
1.1. ORGANISATION STRUCTURE ........................................................................................................................ 9
1.2. MASTER DATA CREATION ........................................................................................................................... 13
1.2.1. MASTER DATA CHANGES ............................................................................................................................ 14
1.2.1.1. BUSINESS PARTNER (BP) CHANGES ......................................................................................... 15
1.2.1.2. NAME CHANGE – NOT APPLICABLE .......................................................................................... 15
1.2.1.3. ADDRESS CHANGE ....................................................................................................................... 15
1.2.1.4. BANK DETAILS CHANGE .............................................................................................................. 15
1.2.1.5. CHANGE IN DATE OF BIRTH – THIS CAN BE UPDATED BY DHA SYSTEM ............................ 15
1.2.1.6. ID CHANGE - THIS CAN BE UPDATED BY DHA SYSTEM ......................................................... 16
1.2.1.7. DATE OF DEATH - THIS CAN BE UPDATED BY DHA SYSTEM ................................................ 16
1.2.1.8. DATE OF MARRIAGE ..................................................................................................................... 17
1.2.1.9. USUFRUCT / FIDEICOMMISSUM .................................................................................................. 17
2. DEPOSIT FILE PROCESSING ....................................................................................................................... 18
2.1. BUSINESS PROCESS REQUIREMENTS ...................................................................................................... 18
2.2. BUSINESS PROCESS DESCRIPTION .......................................................................................................... 18
2.3. BUSINESS PROCESS DIAGRAMS ............................................................................................................... 19
2.4. MASTER DATA ............................................................................................................................................... 19
2.5. DEPOSIT FILE PROCESSING/ CREATION .................................................................................................. 22
2.5.1. DRN GENERATION ........................................................................................................................................ 24
2.5.2. BENEFICIARY STRUCTURE CREATION ..................................................................................................... 24
2.5.3. CHANGE DEPOSIT FILE PROCESS ............................................................................................................. 30
2.5.4. BUSINESS PARTNER (BP) CHANGES ......................................................................................................... 31
2.5.4.1. NAME CHANGE – NOT APPLICABLE .......................................................................................... 31
2.5.4.2 ADDRESS CHANGE ....................................................................................................................... 31
2.5.4.3 BANK DETAILS CHANGE ............................................................................................................................ 32
3. CHANGE IN DATE OF BIRTH – THIS CAN BE UPDATED BY DHA SYSTEM............................................ 32
3.1. ID CHANGE - THIS CAN BE UPDATED BY DHA SYSTEM ......................................................................... 32
3.2. DATE OF DEATH - THIS CAN BE UPDATED BY DHA SYSTEM ................................................................ 33
3.3. DATE OF MARRIAGE ..................................................................................................................................... 33
P a g e | 4
3.4. DEPOSIT FILE CHANGES ............................................................................................................................. 33
3.4.1. DEPOSIT REVERSAL ..................................................................................................................................... 33
3.5. DEPOSIT CANCELLATION ............................................................................................................................ 33
3.6. BENEFICIARY ALLOCATION CHANGES BEFORE DEPOSIT CLEARANCE ............................................ 34
3.7. BENEFICIARY ALLOCATION CHANGES AFTER DEPOSIT CLEARANCE ............................................... 34
3.8. CHANGE OF INTEREST STATUS ................................................................................................................. 34
3.9. ADDITIONAL DEPOSIT ON AN EXISTING FILE ........................................................................................... 34
3.10. CONVERSION TO MAJOR ............................................................................................................................. 35
3.11. COURT ORDER TO STOP INTEREST ........................................................................................................... 35
3.12. CLAIMABLE DATE CHANGE ........................................................................................................................ 35
3.13. NOTIFICATIONS ............................................................................................................................................. 35
4. OPERATIONAL DECISIONS AND LOGIC WITHIN THE PROCESS ............................................................ 36
5. INTEGRATION WITH ECC - CREATE DEPOSIT / CHANGE DEPOSIT / REVERSAL / CANCEL DEPOSIT FILE 36
6. PAYMENT FILE PROCESSING ...................................................................................................................... 38
6.1. BUSINESS PROCESS REQUIREMENTS ...................................................................................................... 38
6.2. BUSINESS PROCESS DESCRIPTION (RECEIVE APPLICATION) ............................................................. 38
6.3. MASTER DATA ............................................................................................................................................... 40
6.4. APPLICATION AND PAYMENT PROPOSAL FILE ....................................................................................... 40
6.5. CHANGE PAYMENT PROCESS .................................................................................................................... 44
6.6. NOTIFICATIONS ............................................................................................................................................. 45
7. REFUND TO DEPOSITOR .............................................................................................................................. 45
8. FRAUD/ LOSS/ OVERPAYMENT ................................................................................................................... 46
9. INTEGRATION WITH ECC – CREATE PAYMENT PROPOSAL / CHANGE PROPOSAL, REFUND TO DEPOSITOR AND FRAUD/ LOSS/ OVERPAYMENT .................................................................................... 48
9.1. PAYMENT RUN ............................................................................................................................................... 50
9.2. RETURNED PAYMENTS ................................................................................................................................ 51
10. JOURNALS ..................................................................................................................................................... 52
10.1. SUSPENSE TO BENEFICIARY ...................................................................................................................... 53
10.2. BENEFICIARY TO BENEFICIARY ................................................................................................................. 54
10.3. BENEFICIARY TO SUSPENSE – THIS WILL NOT BE USED IN GFS ......................................................... 54
11. PIC INVESTMENT AND WITHDRAWAL PROCESS ..................................................................................... 55
12. FINANCE PROCESSES .................................................................................................................................. 56
12.1. BANK ACCOUNTING ..................................................................................................................................... 56
12.2. AUTOMATIC CLEARING PROCESS ............................................................................................................. 58
12.3. PIC INVESTMENT & WITHDRAWAL PROCESS .......................................................................................... 58
12.4. PIC INVESTMENT JOURNAL ENTRY (INTEREST RECEIVED) .................................................................. 59
12.5. DOCUMENT REVERSAL ................................................................................................................................ 59
13. TECHNICAL/DEVELOPMENT RELATED ITEMS .......................................................................................... 60
13.1. WORKFLOW ................................................................................................................................................... 60
13.2. REPORTING .................................................................................................................................................... 61
P a g e | 5
13.3 FINANICIAL REPORTING REQUIREMENT .................................................................................................. 71
13.4 BUSINESS PROCESS FINANCIAL IMPACT ................................................................................................. 72
13.5 INTERFACES .................................................................................................................................................. 74
13.6 ENHANCEMENTS ........................................................................................................................................... 75
13.7 OUTPUT (E.G. FORMS) .................................................................................................................................. 76
14 TECHNICAL/ DEVELOPMENT RELATED ITEMS ......................................................................................... 76
14.1 USER AUTHORISATION ................................................................................................................................ 76
14.2 RECOMMENDATIONS ................................................................................................................................... 77
14.3 ASSUMPTIONS ............................................................................................................................................... 77
15 RISKS 78
16 ABBREVIATIONS ........................................................................................................................................... 78
P a g e | 6
BACKGROUND
The Guardian's Fund (GF) falls under the administration of the Master of the High Court. It is a fund created to
hold and administer funds that are paid to the Master on behalf of various persons known or unknown, for
example, minors, persons incapable of managing their own affairs, unborn heirs, missing or absent persons or
persons having an interest in the monies.
The purpose of the Guardian’s Fund is to protect the funds of minors, persons lacking legal competence and
capacity, known or unknown, absent as well as untraceable heirs. It is important to note that unclaimed money
that remains in the Guardian’s Fund for a period of 30 years from the date that the person became entitled to
claim it is forfeited to the state.
The purpose of this document is to outline the processes in SAP CRM and ECC (PCSD&FI) that will facilitate
the receipt, management and payment of these funds in a secure and efficient manner. Then SAP CRM
module will act as frontend for Guardian’s Fund Administration users and feed financial data into ECC.
The implementation of the Guardians fund end to end business processes has the following advantages:
CRM system can store massive volumes of Customer data, transactional data and will be available in
real time for reporting and analysis
Data replication will happen through standard middleware. This will completely avoid the “Data
Leakages”.
Since both CRM and ECC systems are tightly integrated, DoJ&CD can avoid the “Day end process”
by using the standard integration.
In the entire File approval processes, the approver will have the latest and complete information along
with supported documents, using this information DoJ&CD can avoid the “Fraud and Losses” and
“Time consumption while File approvals”.
Below standard Business Process will support the DoJ&CD business process,
Case Management with Approvals – any point of time, user can understand about the case status,
Originator, Beneficiary, Approver and location information.
360-degree view of customer – user can see the complete customer’s financial and non-financial
information.
Change history & Document flow to track processes – Changes in the file will store as history and the
authorised person can monitor the same.
Document Attachment- Users can attach the document as a link or append the actual document in the
case document, which will store in the Content Management. If there is an existing attachment linked
to the case with the same name, it will overwrite with the most current one from the hard drive.
Integration with DMS server would be possible; specific requirements need to be determined
P a g e | 7
The diagram below displays the high-level integration/data replication points to facilitate the different Guardians Fund business processes within the SAP solution:
The solution will be built using the following three SAP components:
SAP Customer Relationship Management (CRM);
SAP Public Sector Collections and Disbursements (PSCD); and
SAP Financials (FI)
The data replication uses one standard SAP BADI. This design provides the users with the ability to monitor the data replication status using the SAP CRM Middleware and full protection against data leakages.
Register File
Receive Application
Create Payment Process
Process Journals
Log Fraud and Loss
Public Investment Corporation
Reporting
Master Data Maintenance , DRN/ARN Generation, workflow, Bank, DHA Interface
Master Data Maintenance , Fund Application, Workflow
Payment Request, Refund, Workflow
Transfer (Funds/Product Types)
Create Fraud, Loss & Theft case, Fraud Reporting
Investment PIC/ Withdraw funds from PIC
Process Integration (PI)
Administration Reports, Financial Reports and Annual Financial Statements
BADI, CRM Middleware, Netweaver
Process Payments
Fraud and Loss
Admin Reports
Receive Deposit
Guardians Fund Administration Business Processes:
SAP CRM
Guardians Fund Financial Business Processes:
SAP PSCD&FI
Receive & Reconcile Deposits
Execute Payments
Financial Reports
P a g e | 8
LOCATIONS WHERE THIS BUSINESS PROCESS IS PERFORMED
Locations
Location Country Function Number of Users
Point of Contact
National Offices South Africa View data of all locations and Financial reports, process general journals.
XX XX
Pretoria South Africa Deposits, Payment Application XX XX
Pietermaritzburg South Africa Deposits, Payment Application XX XX
Bloemfontein South Africa Deposits, Payment Application XX XX
Cape town South Africa Deposits, Payment Application XX XX
Grahamstown South Africa Deposits, Payment Application XX XX
Kimberley South Africa Deposits, Payment Application XX XX
* Guardian’s Fund will provide the number of users and point of contact for each office.
DATA MIGRATION For successful implementation of the SAP solution for the Guardians Fund business, the existing/legacy data will have to be migrated from the existing Legacy System into SAP. The following data must be considered for migration:
Active files and beneficiary cards (with all the transaction history)
Closed files and beneficiary cards
Suspense account information The data migration process is not part of this business process design document and must be included into the scope of the solution implementation/realization project.
P a g e | 9
1. FUNCTIONAL SOLUTION DESIGN
1.1. ORGANISATION STRUCTURE Guardian’s Fund operates from 6 locations across South Africa along with head office at Pretoria, CRM and ECC will be implemented across all these seven locations. Deposits are accepted from these six offices and consolidation happens at head office for all the deposits.
Proposed enterprise structure for Guardian’s Fund:
Note: Above Codes for Company, Chart of accounts, controlling area, Profit Center and Cost center could be changed based on the requirement during implementation. Each office will be created as a Profit center and cost center. Controlling Area A Controlling Area is an organizational unit used to represent costs for accounting purposes. In SAP, the Controlling Area constitutes the framework for planning, allocation and monitoring of costs. It allows for the creation of both the profit center and cost center. A single controlling area has been proposed for Guardian’s Fund.
P a g e | 10
Description Controlling Area Code
Guardian’s fund 4000
Chart of Accounts
A chart of Accounts (CoA) must be maintained to allow for Document processing and integration to GL Posting. A chart of Accounts lists all GL accounts used by one or several company codes. For each GL account, the chart of accounts contains the account number, account name, and the information that controls how an account functions and how a GL account is created within a company code. The CoA will be maintained centrally. This maintenance includes the creation, maintenance and deletion of GL Accounts. All updates will need to be duly authorized.
Chart of Accounts defined for Guardian’s Fund.
Description Chart of Accounts
Guardian’s Fund 4000
Accounting setup is detailed in embedded sheet below.
COA.xls
GL Account Group: The Account group is a summary of Accounts based on criteria that effect how Master records are created. The Account group determines:
The Number interval from which the Account number is selected When a GL account is created.
The Screen layout for creating GL Accounts in the company code-specific area.
The Account Group also defines the Set-up when creating a GL Account in the Company Code and Chart of Accounts. By defining the number interval and the screen layout, you simplify GL account creation by reducing the number of entry fields.
Account Group Description Number Range From Number Range To
R001 Revenue 100001 199999
E001 Management Fees 200201 200299
E002 Distribution to Beneficiaries 202001 202999
E003 Provision for doubtful debts 201001 201999
A001 Financial Investment available for Sale
300301 300399
A002 Receivables 300501 300599
A003 Cash and Cash Equivalent 300601 300999
A004 Other receivables 302001 302999
L001 Beneficiary Liability 400410 400499
L002 Control payable account 400510 400599
L003 Payables 400610 400699
L004 Other payables 401400 401499
P a g e | 11
Account Group Description Number Range From Number Range To
P001 Net Profit & Loss 500510 500599
Company Code A company code is an organizational unit used in financial accounting to structure the business organization from a financial accounting perspective. It is the organizational unit of external accounting for which a complete, self-contained set of accounts can be created. This includes the entry of all transactions that must be posted and the creation of all items for legal individual financial statements, such as the balance sheet and the profit and loss statement
The following is the proposed company code for Guardian’s Fund.
Description Company Code
Guardian’s Fund 4000
Guardian’s Fund will be having single currency ZAR for company Code 4000.
Profit Center A Profit Center is a business organization unit that is set up for internal management & external control purposes. Profit Centers are used to categorize revenue and expense by responsibility within the organization. These areas of responsibility (Profit Centers) could be based on regions, functions, or products. Profit Centers are primarily used for Internal Management Reporting but can also be used to fulfil regulatory reporting requirements. For instance, full P&L and Balance Sheets are possible at Profit Center level.
The following are the proposed Profit centers for Guardian’s Fund.
Description Profit Center
National Office 4001
Pretoria 4002
Pietermaritzburg 4003
Bloemfontein 4004
Cape town 4005
Grahamstown 4006
Kimberley 4007
Note: User authorisation for transaction and reports will be defined at profit center level. No user can view the interoffice transactions in to the SAP system. Only head office will have display authorisation across all offices.
Cost Center
Cost centers are the lowest level of an organization where cost is collected and analyzed.
Cost Centers typically represent Departments.
Departmental expense budgets/forecasts are typically loaded at the cost center level.
Each Cost Center is assigned to a Profit Center and a Company Code
The following are the proposed Cost Centers for Guardian’s Fund.
Description Cost center
National Office 4001
Pretoria 4002
Pietermaritzburg 4003
Bloemfontein 4004
Cape town 4005
Grahamstown 4006
Kimberley 4007
P a g e | 12
Fiscal Year Variant Fiscal Year Variant represents the Accounting Period for which Financial Reporting is required to be disclosed as per statute. It is usually a period of twelve months for which a company regularly creates financial statements and checks inventories. For Guardian’s Fund, one Fiscal year variant V3 (i.e. April to March, 4 special Periods) will be defined for internal company level reporting and internal group level consolidation reporting. The following is the proposed Fiscal year variant for Guardian’s Fund.
Description Fiscal year variant
Guardian’s Fund 4000
Posting Period Variant Posting Period Variants are defined for opening and closing of periods in the Fiscal Year Variant. You can open and close these posting periods for posting. As many periods as required can be opened for posting simultaneously. Usually, only the current posting period is open for posting, all other posting periods are closed. At the end of this posting period, the period is closed, and the next posting period is opened. Special periods can be open for adjustment postings during the period-end closing.
The following is the proposed posting period variant for Guardian’s Fund.
Description Posting Period Variant
Guardian’s Fund 4000
Field status Variant A Field Status Variant has to be defined and assigned to the Company Code. The field status variant has various field status groups used to specify the field requirement (required, optional or hidden) for each GL account at the time of posting. The field status group is assigned to individual GL accounts in the GL account master record. For example, we can create a field status group configured to make the assignment field mandatory. If this field status group is assigned to a particular GL account, then at the time of posting to this GL account, the user will be forced to enter a text in the assignment field in the document line item. A field status variant with predefined field status groups is already present in the standard SAP system that will be copied to a field status variant created specifically for Guardian’s Fund. If required, more groups would be configured in addition to the existing ones.
The following is the proposed field status variant for Guardian’s Fund.
Description Field status variant
Guardian’s Fund 4000
CRM Organisation Management
The Organisation Structure offers a flexible tool for displaying the company’s information i.e. Company Code,
Branch information and each branch responsible employees. In SAP CRM the following are the organisational
objects:
a) Organisational Unit
Organisational units are functional units of a company. Depending on how task distribution is
organised in a company e.g. departments or project teams.
P a g e | 13
The organisational units can be mapped as Sales Organisation (Head Office), Sales Office
(Branch Office) and Sales Group (Administration, Accounts and Legal department).
b) Position
Organisational object (object type key S) which shows the functional task distribution of
individual items and their reporting structure in the organisational model. Positions are
concrete items in a company, to be assigned to holders (employees or CRM users), for
example, people responsible from Various Branches, tele-sales Department, Contact Centre.
Positions (Employee Role) can be linked to an Organisation Units and Employees are
assigned to the position.
1.2. MASTER DATA CREATION
Note:
SAP PSCD is ECC and FI modules in DoJ&CD Master Data will be maintained in CRM system and replicated into the ECC system with same
structure. a) SAP Master Data Model defines the primary SAP CRM Master Data objects and their relationships to
each other, within the context of the overall solution.
b) Master data is defined as data that remains unchanged over a long period of time whereas transactional
Data on the other hand is data relating to day-to-day transactions.
c) There are three primary Master Data objects that are of interest, namely:
SAP Business Partner (BP);
SAP Contract Account (CA); and
SAP Contract Object (CO).
d) Guardian’s Fund will be using following Identification types for Business Partners:
South African ID for citizens
Passport Number for foreigners
Other foreign identification number
Company Registration number for Organisations / School Registration number
Trust Registration number for Trusts
P a g e | 14
e) Identification numbers will be defined as unique in SAP system, so as to prevent the creation of
duplicate BP’s.
f) A Business partner can have set of addresses with their effective dates, multiple identification numbers
and multiple bank accounts etc.
g) Multiple addresses with contact details like, telephone numbers and email addresses can be maintained.
Work address
Residential address
h) Contract Account (CA) is defined as a ‘structure used to bill the posting data for contracts or contract
items for which the same collection / disbursement agreements apply’. Essentially, CAs are used to
group together similar Contract Objects. At Guardian’s Fund, a CA is created for a deposit file type and
beneficiary product type.
i) The CO is the primary object against which individual transactions will be processed. Deposits at
Guardian’s Fund will have one Contract Object per file. This CO will be unique and will be at file level. At
Guardian’s Fund we refer this as ARN (Account reference number).
a. Account Reference Number (ARN) or Document Reference Number (DRN) involves the assignment of
a unique reference per CO in order to manage incoming payment, a separate DRN per depositor is
necessary for scenarios that requires differentiation between payments made by different depositors in
a single file using an incoming payment channel.
j) For Guardian’s Fund solution, one BP may link to one or more CAs, which in turn must link to one or
more CO(s). One CA may not link to more than one BP. One CO may link to more than one CA,
provided that each CA links to a different BP.
k) BP’s that do not require financial transactions to be processed against them will not be linked to any
CAs (and consequently any COs) in the standard SAP PSCD Master Data relationship model.
Example: 3RD
party Payee.
l) Since Deposits and Payments are specific to a particular office within Guardian’s Fund, each Contract
Object is assigned to a particular office through a Profit Centre.
1.2.1. MASTER DATA CHANGES
Start
End
Business Partner
Change Request
Does BP exists
in SAP?
Apply business
Partner changesYes
Get all Beneficiary Cards
linked to this BP in
Beneficiary/Guardian Role
Place Payment lock on
Beneficiary Card
Reverse all payments
which are scheduled and
yet to be paid
Update lock status on
CRM per Beneficiary
Card
No
P a g e | 15
Note: Reversal of all un-processed payments transactions are not a standard process, to achieve this functionality custom development is needed (Enhancement).
1.2.1.1. BUSINESS PARTNER (BP) CHANGES
a) Every change on existing business partner will go through an approval process in CRM system or Authorised users can change the data in CRM system directly.
b) If there are any Beneficiary/Guardian changes, all beneficiary cards linked to the Beneficiary/Guardian will be locked and proposals (one-time/Recurring) will be stopped.
c) Following Business partner changes are done on CRM system at Guardian’s Fund:
Contact Details (Email Address, Telephone, Cell phone)
Address change
Bank details change
Change in Date of birth
Change in ID
Date of death
Date of Marriage
1.2.1.2. NAME CHANGE – NOT APPLICABLE
a) There is a possibility to have change in surname, initials, first, last and middle names for a business partner (the functionality will be driven by the DHA integration to the system, the relevant changes will be extracted from the Home affairs database).
b) Change in data will be sent to ECC through standard middleware. c) ECC will update the relevant changes on BP.
Note: This can be updated via Webservice.
1.2.1.3. ADDRESS CHANGE
a) Any changes in Contact details, physical and postal address for a business partner will be done in CRM system.
b) Change in data will be sent to ECC through standard middleware c) ECC will update the address details.
1.2.1.4. BANK DETAILS CHANGE
a) CRM system can maintain multiple bank accounts per business partner b) CRM system will send Swift/Branch code, account number, account type, Account holder name to
ECC. c) ECC will determine whether to create a new account or change an existing account based on the
Swift/branch code and account number.
1.2.1.5. CHANGE IN DATE OF BIRTH – THIS CAN BE UPDATED BY DHA SYSTEM
a) There could be a possibility for change in Date of birth for a business partner.
b) Date of birth changes for business partners can be updated in CRM system based on user authorisation and the same will replicate to ECC system via middleware.
c) Change in Date of birth of business partners who are beneficiaries, will have impact on claimable
date, Interest.
P a g e | 16
Interest bearing to Interest bearing change – If the beneficiary was in interest bearing account and with this change if beneficiary still remains in interest bearing, ECC will have to update the claimable date considering already made payments and adjust interests accordingly.
Interest bearing to Non-interest-bearing change – If the beneficiary was in interest bearing account and with this change if beneficiary is moving to non-interest bearing, CRM system will create a new beneficiary card with product type “Non-Interest bearing” and capital amount will be transferred through journals. Interest adjustments will be done by ECC accordingly. Old beneficiary card and contract account will be set to “Obsolete”
Non-interest-bearing to Interest-bearing change – If the beneficiary was in non-interest-bearing account and with this change if beneficiary is moving to interest bearing, CRM will create a new beneficiary card with product type “Interest bearing” and capital amount will be transferred through journals. Interest adjustments will be done by ECC accordingly. Old beneficiary card and contract account will be set to “Obsolete”
Non-Interest-bearing to Non-interest-bearing change – If the beneficiary was in non-interest-bearing account and with this change if beneficiary is moving to non-interest-bearing, ECC will have no financial impact and will update the claimable date.
1.2.1.6. ID CHANGE - THIS CAN BE UPDATED BY DHA SYSTEM
a) There could be changes for Identification for Business partners.
b) If the Identification type is Passport/foreign ID, then there is no financial impact because of this change, this change will happen in CRM system based on user authorisation and the same will replicate to ECC system via middleware.
c) South African ID’s will have date of birth of the citizens as part of the ID number. First 6 digits of the
ID number indicate the date of birth of a person.
If the change is on first 6 digits, the change will follow the date of birth change described above.
If the change is not on first 6 digits, change can be applied to ECC as there is no financial impact due to this change.
1.2.1.7. DATE OF DEATH - THIS CAN BE UPDATED BY DHA SYSTEM
a) When the date of death of a beneficiary is notified to Guardian’s Fund, the information will be updated in CRM system.
b) CRM system will send date of death and claimable date which will be updated in ECC. c) ECC will do the interest adjustments accordingly (if applicable).
P a g e | 17
1.2.1.8. DATE OF MARRIAGE
a) When the date of marriage of a beneficiary is notified to Guardian’s Fund, same will be updated in CRM system.
b) CRM system will send date of marriage and claimable date which will be updated in ECC.
c) ECC will do the interest adjustments accordingly (if applicable).
1.2.1.9. USUFRUCT / FIDEICOMMISSUM
Usufruct / Fideicommissum is one of the sub classification types for Interest bearing product type. Business processes are different from other interest-bearing product types.
a) Beneficiary card sub-classification “Usufruct” / Fideicommissum would need transfer of interest or
Capital to a new beneficiary card.
b) Business will use new beneficiary card creation functionality and use Journal to transfer the amounts.
c) ECC must accept Interest journals only for Usufruct / Fideicommissum sub-classification.
d) Since both Interest and capital are used for usufruct / Fideicommissum cases, automatic interest adjustments are not required.
e) Interest adjustment indicator to be identified for all usufruct / Fideicommissum journal cases and ECC to do the interest adjustments based on this indicator.
f) Capital transfers in case of usufruct / Fideicommissum can also come with Transfer effective date. In these cases, ECC need to do the interest adjustments based on the transfer effective date rather than Receipt Date.
P a g e | 18
2. DEPOSIT FILE PROCESSING
2.1. BUSINESS PROCESS REQUIREMENTS
Deposit is the main business process in DoJ&CD business, DoJ&CD accepts money from different entities based on the file types.
Once the Deposit file is approved in CRM system, the record will replicate into ECC via middleware.
2.2. BUSINESS PROCESS DESCRIPTION
Deposit applications are received at 6 different Guardian’s Fund offices. These documents are manually
validated and approved for completeness by Deposit clerk, Assistant Master and Finance teams.
Deposit clerk creates the Deposit file in CRM System when the manual file is ready for processing. Deposit
file goes through various approvals in CRM system. Once the final approval is done in CRM, the financial
information (credit memo request / debit memo request record) will replicate into ECC automatically via
middleware.
Process Characteristics
Process Trigger Approval of Deposit File in CRM System
Process Input Approved Deposit Case Document
Process Output Deposit financial record
Process Owner DoJ&CD – Guardian’s Fund Masters
Process Volumes Approx. 20,000 deposit records per year
Process Frequencies Daily
P a g e | 19
2.3. BUSINESS PROCESS DIAGRAMS
Create Deposit File Business Process Flowchart
2.4. MASTER DATA
1. Business partners are unique numbers and a Business partner could be a person, organisation,
group of persons, or group of organisations in which Guardian’s Fund has a business interest. For
example:
Depositor - refers to the organisation or the individual that is making a deposit into the Guardian Fund on behalf of someone.
Originator - (Source of Funds) – Refers to the person who the money belongs to.
Beneficiary - refers to the person the money belongs to.
Guardian - refers to a person who has been nominated to care for the minors who are
beneficiaries of the fund
NRF – National Revenue Fund
PIC - Public Investment Corporation
DOJ&CD
2. Business partner relationships will be used for maintaining the relationships between originator,
guardian, beneficiary and depositors (the relationship list is available in CRM system).
3. For Guardian’s Fund solution, one BP may link to one or more CAs, which in turn must link to one or
more CO(s). One CA may not link to more than one BP. One CO may link to more than one CA,
provided that each CA links to a different BP.
Start Create FileDoes ARN
Exists?
Does Originator
Exists?Yes
Check and Create Originator BP, CA
YesValidation with
DHA
Does Depositor
Exists?
Check and Create Originator BP, CA
YesValidation with
DHA
Does Beneficiary
Exists?
Check and Create Originator BP, CA
YesValidation with
DHA
Does Guardian Exists?
Check and Create Originator BP, CA
YesValidation with
DHA
Change FileEnd
Check and create Originator (BUAG)
ARN
Update Beneficiary
structure table in ARN with Split
details
Create Beneficiary Cards (CA, CO)
Approved By ASS Master?
Approved by
Approver 1? Yes
Approved by
Approver 2?Yes
Replicate in ECC System
Yes
Generate DRN In ECC
Update DRN in CRM
Create Beneficiary Cards (CA, CO)
No
No
Legend:
SAP CRM SAP ECC DHA System
P a g e | 20
4. Following diagram shows the structure of Master data for Deposits in new Guardian’s Fund system:
a. Deposit File may have different Deposit types. Deposits contract account category is mapped to deposit
type. Deposit types will remain same throughout the life of the case document.
Following are the deposit types:
Deceased Estate
Curatorship
Trust
Insolvency
Expropriation
Future Maintenance
Company in Liquidation
Close Corporation in Liquidation
Order of Court (Third Party)
Other (Provide a field to be populated with information)
Testamentary (trust) fund
Land Restitution
PIC Withdrawal
Note: Deposits Contract object category will always be “Deposits”.
b. Deposits contract account categories will be mapped to classification types (Product Types):
Interest Bearing Account
Non-Interest-bearing Account
P a g e | 21
Commission Account
Security Items
Public Investment Corporation – Withdrawal/Investment
c. Deposits contract object categories will be mapped to sub-classification types (Sub-Product Types).
Interest Bearing Account Non-Interest-Bearing Account Commission Account
Minors Unborn / Undetermined
Heirs Majors Creditors (Creditors,
Members, Shareholders)
Ward of court Untraced heirs / Unknown heirs Creditors (Section 93)"
Usufruct - Calculate interest Insolvent (Section 116 of insolvent act)
Fideicommissum Future maintenance - Major dependent
Future Maintenance Deceased Estate (Estate late)
Expropriation of Land (majors) Unproved claim in respect of Mortgage bond
Expropriation of Land (minors) Trust
Expropriation of Land (majors)
Land Restitution (Deceased
Estates)
5. Beneficiary details captured from Deposit files are updated on Deposit contract object in a custom
data table created for Guardian’s Fund.
6. Important (Custom fields) are in below table
Description Information Type Type of BP Mandatory
Date of Insolvency Blank Text Originator No
Place of Death Blank Text Originator No
Date of Death Blank Date Originator No
Claimable Date Blank Date Beneficiary Yes
Claimable Age (e.g. As per Will or Court Order)
Blank Number Beneficiary No
Gazette Publish Date Blank Date Beneficiary Yes
Interest Effective Date Blank Date Beneficiary Yes
Stop Interest Date (Claimable Date + 5yrs)
Blank Date Beneficiary Yes
PayOver (NRF) Date Blank Date Beneficiary Yes
Stop Interest Date Blank Date Beneficiary Yes
P a g e | 22
7. Integration with DHA system
a. When user enter the ID number in the CRM System, DHA system should populate the below information,
Surname,
Full Name
Initials
Address
Date of birth
Date of marriage
Date of death
8. Business Agreement (BUAG) will create for each BP with Category as “Deposit File Type” and will replicate to ECC system as Contract Account (CA).
9. One Contract Object (CO) for the File with Originator and Category as “Deposits”. CO number is also referred as Account Reference Number (ARN)
Gaps:
a. Contract Object enhancement for beneficiary structure details
b. Important dates (Claimable date, file information on Contract Object)
c. Claimable Capital Limit, Used Capital Amount fields on Business Partner (Beneficiary) -
Linked to payment request or type (Private Investment)
Please refer to - Enhancement section
Note: Standard integration between CRM to ECC for creation/change of the deposit file.
2.5. DEPOSIT FILE PROCESSING/ CREATION
Following is the process flow for Deposits at Guardian’s Fund in the to-be system:
Rec
eive
Dep
osi
t
Create / Maintain Master Data
Update Beneficiary Stucture
Create File
Submit for ApprovalSubmit to Assistant Master for Approval
Submit to Approver 1
Submit for final approval by Approver
2
Replicate Data into ECC
Create DRN and Beneficiary Allocation
Update DRN in CRMReceive Deposit From
the Bank
Clear (DRN) Open items and distribute to Beneficiary Cards
Update Receipt number in CRM
Interest postings in Interest Bearing
AccountsPrint Receipt Process payment
P a g e | 23
1. Incoming payments for Deposits can come in through Electronic Fund Transfer (EFT) or Journal.
2. Each file contains Originators, Depositors, Beneficiaries and Guardians and system will allow more than one BP
3. New file will be created in CRM, with a unique number.
4. A file can consist of single or multiple deposits
5. Cross Reference Number – is Unique, system will not allow the duplicate value.
6. User will store related documents in the system (PDF, XLSx, DocX and images)
7. Important Dates, please refer Section 1.2.1 - Change Business Partner (BP) Changes
8. Once the file is created in CRM, system will trigger a workflow, approver can take decision to approve/reject.
9. Once the file will be approved finally in CRM system, all financial data will be replicated into ECC system.
10. ECC will generate master data for deposits and update beneficiary details on deposit contract object
11. ECC will post an open item for deposit (DRN) with beneficiary structure on document line items.
12. DRN number will be updated back into CRM system and a daily report will be generated from ECC that will be sent to bank with details like ARN, DRN Number, amount, Depositor etc.
13. Bank statement will be placed in a defined folder in application server by Bank.
14. Batch job in ECC will pick this file and upload it for processing. Any unprocessed records have to be processed manually.
15. Incoming deposit payments will be processed through Payment lots for EFT payments at Guardian’s Fund.
16. Value date of the incoming payment document will be considered as Receipt Date and updated in beneficiary credit document(s) through revenue distribution
17. Receipt Date and Status will be sent to CRM and Receipt number for every received deposit will be generated in ECC. ECC sends back receipt number to CRM for reporting purposes.
Receipt document can be printed once as “Original Document’;
Duplicate document should be setup under Forms to reflect as ‘Duplicate’
Depositor will get notified via e-mail for the Original document.
18. Batch job for Revenue distribution will distribute the deposits into beneficiary cards according to the splits provided.
19. Bulk deposit payments (Refers to monies that come in from Legal Aid department, Municipalities etc, where a single amount is deposited into the Guardian’s Fund Account for multiple files). These deposits
P a g e | 24
will be negotiated to send them as individual deposits instead of Bulk going forward to avoid human errors in processing them.
Note:
If the file is missing any mandatory field(s) information, the system will not allow the submission for approval.
2.5.1. DRN GENERATION
1. Guardian’s Fund has large number of funds sitting in Suspense account due to incorrect referencing of the incoming deposit payments. It is essential that incoming payments come with correct reference number, so that they get allocated to correct file / deposit.
2. Funds that cannot be allocated automatically are referred as unclassified money. High number of unclassified monies lead to negative service delivery impact on the Guardian’s Fund beneficiaries.
3. To avoid this in the to-be system, Guardian’s Fund have requested to have a unique reference number for each deposit.
4. In the to-be system, once the deposit file application is submitted in CRM, the system will trigger a workflow, approver can take decision to approve/reject.
5. When the application is approved, data will be pushed to ECC along with the expected deposit amount details.
6. ECC system will create relevant master data structure for the file and to also post an open item / items for expected deposits on the file. Deposit open item document number will be used as Deposit reference number (DRN).
7. A daily report with all valid deposit DRN numbers and expected deposit amounts will be sent to the banking institution for accepting incoming payments.
8. DRN is valid only for 30 days and once lapsed, deposit cannot be accepted through this DRN number. ECC will reverse these DRNs on expiry. Daily report that is sent to Bank will consider this and send only valid DRN numbers.
9. ECC system will update to CRM when the DRN is expired. i.e. CRM set the file status as “DRN expired”.
If there are no financial transactions in ECC, the CRM system will set the file status as “Closed” automatically and the file should be archived.
If there are financial transactions in ECC, the CRM system set the file status as “DRN Deactivated” automatically. The ECC system must reverse the affected financial transactions.
Gaps:
a. For capturing ARN number (Unique reference number) in the file, field does not exist. Please refer to section 5.4 Enhancements.
2.5.2. BENEFICIARY STRUCTURE CREATION
Beneficiary master data structure will be created in CRM system and the same will be replicated into ECC, with the details captured on the deposit contract object (ARN). Following picture depicts a deposit file that involves multiple depositors and beneficiaries.
P a g e | 25
1. If there are multiple Originators for a file, master data structure will be as follows:
2. Any changes to beneficiary structure that happen through Change deposit file after this will be intimated to
ECC system through CRM. Please refer to Deposit File Changes section for details. Once it is approved in CRM system it will replicate into ECC. “Beneficiary Allocation is custom field”.
3. Credit items are posted on to Beneficiary cards according to splits given on the Deposit contract object using Revenue distribution in a batch job.
4. For interest bearing accounts posting, credit documents will be posted with interest key defined in the system for interest calculation. Non-interest-bearing and Commission product types will not have any interest key updated for the credit documents posted on them.
5. Interest key contains interest calculation rule to be used at Guardian’s Fund. Interest calculation rule will use the reference interest rate declared for the financial year.
6. Interest calculation will start from first day of next month (Deposit Payment Document Date).
Example:
o Deposit Payment R1000 is received on 15 September 2018.
P a g e | 26
o Interest calculation will start from 1st October 2018.
o Interest calculation is done at the month end and it will be compound interest calculation, through a mass interest program.
o In this case, 31st October 2018 for R1000. Say calculated interest is R100
o If there is a new deposit payment R2000 is received on 1st November 2018
Interest calculation for November month end (30th Nov) will consider Interest base
amount as 1000 + 100 = R1100 (R2000 is considered for the month of November)
Say interest amount will be R110 for the month of November 2018.
o For the month of December, interest base amount will be R1100 + R110 + R2000 = R3210
o Say interest amount will be R321
7. Interest Calculation
a) At Guardian’s Fund interest is calculated for the documents on Beneficiary card with product type “Interest bearing”. Hence, only “Credit interest” is calculated at Guardian’s Fund.
b) Interest rate will be declared more than once in a financial year with effective dates for each of them.
Example:
a. 1st April 2018 to 30 June 2018 – 8%
b. 1st July 2018 to 31 March 2019 – 6%
c) An interest key will be created that will refer to the declared reference interest above. This interest key will be assigned to credit documents on beneficiary card (CO).
P a g e | 27
d) Interest calculation should consider the number of days in a month to calculate interest.
Example:
o For a deposit of R10,000 deposited on 15 December 2015 will have following interest calculation
Reference interest rates:
1st April 2015 to 31
st Mar 2016 – 8%
1st April 2016 to 31
st March 2017 – 7%
Interest calculations:
Interest base amount
Interest calculation date
Interest rate Days
Days in a Year
Calculated interest amount
10,000 31-Jan-16 8% 31 366 67.75956284
10,068 29-Feb-16 8% 29 366 63.81749231
10,132 31-Mar-16 8% 31 366 68.65112322
10,200 30-Apr-16 7% 30 366 58.52589938
10,259 31-May-16 7% 31 366 60.82376052
10,320 30-Jun-16 7% 30 366 59.21069251
10,379 31-Jul-16 7% 31 366 61.5354402
10,440 31-Aug-16 7% 31 366 61.90028147
10,502 30-Sep-16 7% 30 366 60.25866374
10,562 31-Oct-16 7% 31 366 62.62455718
10,625 30-Nov-16 7% 30 366 60.9637314
10,686 31-Dec-16 7% 31 366 63.35730742
10,749 31-Jan-17 7% 31 365 63.90756129
10,813 28-Feb-17 7% 28 365 58.06613344
10,871 31-Mar-17 7% 31 365 64.63271997
e) Mass interest run will be executed every month end that will post the interest amount on the credit documents with interest key.
f) There will be no correspondence on Interest earned information to beneficiary. But IT3(B) certificate will be issued at the end of financial year.
g) Interest effective date and stop interest effective date are maintained as part of Facts on beneficiary card.
h) Interest calculation program will look at facts to calculate interest through an event enhancement detailed in enhancement section.
i) Interest Effective date will be maintained as Facts on Beneficiary card.
Please note that the Interest calculation will happen in the ECC system not in CRM
Gaps
Beneficiary allocation, need to create custom field
enhancement is required to check the total allocation
Please refer to section 5.4 – Enhancement
P a g e | 28
Important fields’ information
Description/ Default Type Mandatory
File Type Blank Dropdown Yes
Cross Reference Number Blank, Unique Free Text No
File Description Blank Free Text Yes
Application Number Blank System Generated Yes
File Guardian Fund Number
Blank Free Text Yes
File Registration Date Blank Calendar Yes
External Reference Number
Blank Free Text No
Fund Deposit Type Blank Dropdown Yes
Notes Blank Free text N/A
Attachment Blank N/A N/A
DRN Number Blank N/A N/A
DRN Expiry Date Blank N/A N/A
Receipt Number Blank N/A N/A
Receipt Date Blank N/A N/A
Deposit Amount Blank N/A N/A
Beneficiary Default Entry
Claimable Date System should calculate based on Date of birth and legal age which is 18
Date N/A
Publish Date System should calculate based on claimable date + 1 year and published for 3 years
Date N/A
PayOver Date System should calculate based on claimable date + 30 years to pay over to SARS (NRF)
Date N/A
Stop interest Date System should calculate based on claimable date + 5 years or claimable date as per will
Date N/A
Effective Date Manual entry Date N/A
Beneficiary Will Entry
Claimable Date As per Will Manual entry Date N/A
Claimable Age Manual Entry Date N/A
Publish Date System should calculate based on claimable date + 1 year and published for 3 years
Date N/A
PayOver Date System should calculate based on claimable date + 30 years to pay over to SARS (NRF)
Date N/A
Stop interest Date System should calculate based on claimable date + 5 years or claimable date as per will
Date N/A
P a g e | 29
Description/ Default Type Mandatory
Effective Date Manual entry Date N/A
Beneficiary Date of Marriage Entry
Claimable Date Manual Entry - Date of Marriage Date N/A
Publish Date System should calculate based on claimable date + 1 year and published for 3 years
Date N/A
PayOver Date System should calculate based on claimable date + 30 years to pay over to SARS (NRF)
Date N/A
Stop interest Date System should calculate based on claimable date + 5 years or claimable date as per will
Date N/A
Effective Date Manual entry Date N/A
Beneficiary – Custom Entry
Claimable Date Manual Entry Date N/A
Publish Date System should calculate based on claimable date + 1 year and published for 3 years
Date N/A
PayOver Date System should calculate based on claimable date + 30 years to pay over to SARS (NRF)
Date N/A
Stop interest Date Manual Entry Date N/A
Effective Date Manual entry Date N/A
P a g e | 30
2.5.3. CHANGE DEPOSIT FILE PROCESS
Deposit File changes like Beneficiary changes, Guardian changes, Delete Deposit etc. are processed in CRM system and approved changes are sent to ECC as Changes to the deposit file. Changed information will be replicated into ECC via standard middleware.
Beneficiary details*
Guardian: Change Guardian assignment for a Beneficiary who is minor
Interest effective date: Change interest effective date of a beneficiary card
Stop interest effective date: Update Stop interest effective date on Beneficiary card
Claimable date: Update claimable date on beneficiary card
Change reason: For every change capture update “change reason” sent by CRM
P a g e | 31
In CRM system,
User needs to open the existing file for editing in CRM and the status will be set automatically set as” Re-Open”.
After re-opening the file, o The user can add/remove the Business Partners i.e. Depositor, Beneficiary, Guardian. o The user can add the new Deposits.
After updating the appropriate information, user needs to submit it for approval. This information will have only 2 levels of approval i.e. 1) Asst. Master (Approver1) 2) Final Approval (Approver2)
When the document is submitted for approval, system will trigger workflow and the approvers can take decision to approve/reject.
After completion of the approval process, information will replicate to ECC via middleware.
Change deposit file could have any of the following changes:
Addition of a Beneficiary, Depositor, Guardian
Change in Guardian (BP)
Change in Interest Effective Date
Stop Interest Effective Date
Claimable Date
Change in Beneficiary Structure
Cancel Deposit
Change deposit amount
Additional deposits
Note: Change in product type will be managed by creating new beneficiary card with required product type and journaling the amounts. These changes are described in respective sections below. In case of any exceptions, send Error messages back to CRM system.
2.5.4. BUSINESS PARTNER (BP) CHANGES
a) Every change on existing business partner will go through an approval process in CRM system or Authorised users can change the data in CRM system directly.
b) If there are any Beneficiary/Guardian changes, all beneficiary cards linked to the Beneficiary/Guardian will be locked and proposals (one-time/Recurring) will be stopped.
c) Following Business partner changes are done on CRM system at Guardian’s Fund:
Address change
Bank details change
Change in Date of birth
Change in ID
Date of death
Date of Marriage
2.5.4.1. NAME CHANGE – NOT APPLICABLE
a) There is a possibility to have change in surname, initials, first, last and middle names for a business partner. (The functionality will be driven by the DHA integration to the system, the relevant changes will be extracted from the Home affairs database).
b) Change in data will be sent to ECC through standard middleware. c) ECC will update the relevant changes on BP.
Note: This can be updated via Webservice.
2.5.4.2 ADDRESS CHANGE
Any changes in physical, postal address for a business partner will be done in CRM system.
P a g e | 32
Change in data will be sent to ECC through standard middleware
ECC will update the address details.
2.5.4.3 BANK DETAILS CHANGE
CRM system can maintain multiple bank accounts for a business partner
CRM system will send Swift/Branch code, account number, account type, holder name to ECC.
ECC will determine whether to create a new account or change an existing account based on the Swift/branch code and account number.
3. CHANGE IN DATE OF BIRTH – THIS CAN BE UPDATED BY DHA SYSTEM
There could be a possibility for change in Date of birth for a business partner.
Date of birth changes for business partners can be updated in CRM system based on user authorisation and the same will replicate to ECC system via middleware.
Change in Date of birth of business partners who are beneficiaries, will have impact on claimable
date, Interest. a. Interest bearing to Interest bearing change – If the beneficiary was in an interest-bearing
account and with this change the beneficiary remains in interest bearing, ECC will have to update the claimable date considering already made payments and adjust interests accordingly.
b. Interest bearing to Non-interest-bearing change – If the beneficiary was in interest bearing account and with this change if beneficiary is moving to non-interest bearing, CRM system will create a new beneficiary card with product type “Non-Interest bearing” and capital amount will be transferred through journals. Interest adjustments will be done by ECC accordingly. Old beneficiary card and contract account will be set to “Obsolete”
c. Non-interest-bearing to Interest-bearing change – If the beneficiary was in non-interest-
bearing account and with this change if beneficiary is moving to interest bearing, ECC will create a new beneficiary card with product type “Interest bearing” and capital amount will be transferred through journals. Interest adjustments will be done by ECC accordingly. Old beneficiary card and contract account will be set to “Obsolete”
d. Non-Interest-bearing to Non-interest-bearing change – If the beneficiary was in non-interest-
bearing account and with this change if beneficiary is moving to non-interest-bearing, ECC will have no financial impact and will update the claimable date.
3.1. ID CHANGE - THIS CAN BE UPDATED BY DHA SYSTEM
There could be changes for Identification for Business partners.
If the Identification type is Passport/foreign ID, then there is no financial impact because of this change, this change will happen in CRM system based on user authorisation and the same will replicate to ECC via middleware.
South African IDs will have date of birth of the citizens as part of the ID number. First 6 digits of the ID number indicate the date of birth of a person.
o If the change is on first 6 digits, the change will follow the date of birth change described above.
o If the change is not on first 6 digits, change can be applied to ECC as there is no financial impact due to this.
P a g e | 33
3.2. DATE OF DEATH - THIS CAN BE UPDATED BY DHA SYSTEM
a) When the date of death of a beneficiary is notified to Guardian’s Fund, the information will be updated in CRM system.
b) CRM system will send date of death and claimable date which will be updated in ECC. c) ECC to do the interest adjustments accordingly if required.
3.3. DATE OF MARRIAGE
a) When the date of marriage of a beneficiary is notified to Guardian’s Fund, same will be updated in CRM system.
b) CRM system will send date of marriage and claimable date which will be updated in ECC. c) ECC to do the interest adjustments accordingly if required.
3.4. DEPOSIT FILE CHANGES
a) Searching for Deposit files is a requirement. SAP supports standard search criteria i.e. BP, File Number, Creation date, etc., DoJ&CD users also require search capability on the fields below,
Bank Account Number
Date of payment
ID Number / Passport
b) File Changes,
Any field that needs to be changed in the system must go through the 2 levels of approval.
Changes made at a client (Guardian/Beneficiary) level, the system must block the beneficiary card and cancel all pending payments.
If the client exists on multiple file and in different offices must, the system must block the Beneficiary card until the Card is unblocked by the respective office.
Once the document got final approval, the system automatically Unblock the file.
3.4.1. DEPOSIT REVERSAL
a) Deposit reference number (DRN) generated in ECC is valid only for 30 working days from the date of document generation. If the funds are not deposited during this time, the DRN will expire and document will be reversed.
b) This information will update in CRM system, c) Bank cannot accept any deposit with this expired DRN. d) Status of the Contract Account and Contract Object related to this Deposit will be set to “Obsolete”. e) Batch program to check and reverse the expired DRNs on a daily basis.
3.5. DEPOSIT CANCELLATION
a) User can cancel a Deposit even after final approval in CRM system.
User need to search the existing Deposit file
P a g e | 34
Open the existing file and set the status as “Deposit Cancellation”
System will trigger workflow for approval process (This process as like new Deposit file)
b) Once the deposit file is approved by final approver, then the information will be replicate into ECC system via middleware.
c) DRN created for this deposit will be reversed in ECC system and updates in CRM system. d) Bank cannot accept any deposit with this cancelled DRN. e) Status of the Contract Account and Contract Object related to this Deposit will be set to “Obsolete”.
3.6. BENEFICIARY ALLOCATION CHANGES BEFORE DEPOSIT CLEARANCE
a) There is a possibility of change in beneficiary data in CRM system even after the approval.
User need to search the existing Deposit file
Open the existing file and Edit the document, system will set the status as “Re-Open” automatically
System will trigger workflow for approval process (This process as like new Deposit file)
b) Once the deposit file is approved by final approver, then the information will be replicate into GFS system via middleware.
c) GFS will update the beneficiary structure table with the changes. d) Existing DRN will be reversed and new DRN with new allocations will be created and sent back to
CRM system
3.7. BENEFICIARY ALLOCATION CHANGES AFTER DEPOSIT CLEARANCE
a) There is a possibility of change in beneficiary data in CRM system even after the approval and deposit clearance.
o User need to search the existing Deposit file o Open the existing file and Edit the document, system will set the status as “Re-Open”
automatically o System will trigger workflow for approval process (This process as like new Deposit file)
b) Once the deposit file is approved by final approver, then the information will be replicate into ECC
system via middleware. c) ECC will update the beneficiary structure table with the changes if there is an addition of new
beneficiaries or deletion of old beneficiaries. At this stage beneficiary structure is already created in ECC.
d) Interest would have been calculated on Interest bearing funds for the duration before this change. e) Change in financial data will come in as part of journal processing from CRM System.
3.8. CHANGE OF INTEREST STATUS
a) For example, a non-interest-bearing account, there could be a court order which instructs GF to pay interest on the Beneficiary card (disabled etc.) and vice versa.
b) In this case, BP data needs to be updated in CRM system, c) Create a new beneficiary card with relevant product type. d) CRM system will use journal transfer to move capital amounts to the new beneficiary card e) ECC to do the interest adjustments as part of financial adjustments.
3.9. ADDITIONAL DEPOSIT ON AN EXISTING FILE
a) Additional deposits can come into an existing file e.g. recurring deposits from GEPF; with additional business partners
b) CRM system will send deposit file details to ECC system.
P a g e | 35
c) For the additional deposit, the user needs to open the existing deposit case and need to create new deposit document. The approval process remains same as the new deposit file creation process.
d) GFS will update beneficiary structure table file on the existing Contract object for the deposit file.
e) Based on the beneficiary structure table, Beneficiary cards will be created if not existing already.
f) GFS will create a DRN for this new deposit and update CRM system with the same.
g) Overnight revenue distribution batch job will transfer the credits to respective beneficiary cards
3.10. CONVERSION TO MAJOR
a) When a beneficiary turns major (18yrs), System should update automatically in BP (CRM).
b) Claimable date will not change, and calculation of interest will continue till claimable date + 5 years.
c) However, they are exception to the conditions above e.g. In a case where a minor is married, the claimable date will change to Date of Marriage + 5 years
d) The latest information will replicate into ECC system.
3.11. COURT ORDER TO STOP INTEREST
a) Court could direct GF to stop interest for a beneficiary based on some circumstances.
b) User need to update the file with stop interest in CRM system and will submit for approval.
User need to search the existing Deposit file
Open the existing file and set the status as “Stop Interest”
System will trigger workflow for approval process (This process as like new Deposit file)
c) Once the deposit file is approved by final approver, then the information will be replicate into ECC system via middleware.
d) ECC will stop interest for the beneficiary through interest lock and also adjust interest calculated on the beneficiary accordingly.
3.12. CLAIMABLE DATE CHANGE
a) Court can direct Guardian’s Fund to change the claimable date on a Beneficiary card.
User need to search the existing Deposit file
Open the existing file and set the status as “Re-Open” and enter the Claimable date information.
System will trigger workflow for approval process (This process as like new Deposit file) b) Once the deposit file is approved by final approver, then the information will be replicate into ECC
system via middleware. c) Once the case is approved, the information will replicate into ECC. d) ECC will update the beneficiary claimable date and adjust any interest calculations.
3.13. NOTIFICATIONS
a) Once the file is approved in CRM, E-Mail notification will send to the Depositor
DRN Number
Amount
P a g e | 36
b) DRN expired information detailed information will be available at Verifier-2 WEBUI page
c) Depositor will get notified via e-mail when the Deposit has been cleared.
d) For internal communication, the user will be creating a Task transaction.
4. OPERATIONAL DECISIONS AND LOGIC WITHIN THE PROCESS
Create deposit file triggers following activities in ECC system:
Deposit Master Data Creation
o Business Partner (BP) Creation for Depositors, Originators, Beneficiaries, Guardians.
o Contract Account (CA) for each Originator with Category as “Deposit File Type”
o One Contract Object (CO) for the File with Originator and Category as “Deposits”. CO number is also referred as Account Reference Number (ARN)
o Create AR/AP relationship for all originators on the File
Update Custom table with Beneficiary structure given in the File
Create master data structure for Beneficiaries (CA, CO)
For each deposit create DRN with line items reflecting beneficiary allocations.
This document number will be used as Deposit Reference Number(DRN) for incoming deposit payments to be made by Depositors
Change deposit file could have any of the following changes:
New Deposit into an existing file
Addition of an Originator, Beneficiary, Depositor, Guardian
Change in Guardian
Change in Interest Effective Date
Stop Interest Effective Date
Claimable Date
Change in Beneficiary Structure
Cancel Deposit
Change deposit amount
Note: Change in product type will be managed by creating new beneficiary card with required product type and journaling the amounts.
5. INTEGRATION WITH ECC - CREATE DEPOSIT / CHANGE DEPOSIT / REVERSAL / CANCEL DEPOSIT FILE
a) The data exchange between the SAP CRM and SAP ECC (PSCD and FI) components is handled via
SAP CRM Middleware Adapters. The adapters are used for mapping and converting data between
the two SAP systems.
b) In CRM system user will fill the data (Attached field’s data), All the required data will be replicated to PSCD system.
c) Please find the enclosed high-level fields information.
Worksheet Deposits
and MasterData DOJ Solution Design.xlsx
P a g e | 37
d) SAP has provided the standard integration/replication functionalities in PSCD Business suite, which will be used for creating deposit file, changing deposit file, reversal of deposit file and cancelling deposit file.
e) Once the file is approved in CRM system, data will be replicated to PSCD system for further activities.
f) Find below diagram which is explaining the standard integration/replication functionalities.
g) Each file (case) contains unique number.
h) Each file and Deposits (SSP) contains Business Partners (Originator, Depositors, Beneficiaries and Guardians).
a. Business Partners will be replicated via standard middleware functionality.
i) For account postings in PSCD system Contract Account (Business Agreement in CRM) is required.
Implement the standard BADI (PSSC_ACC_MD_CREATE) to replicate the data
automatically to PSCD system.
j) Using enhanced Interface, system will create a Contract Object (unique number). This is linked with Business Agreements (Contact Account).
(As per the standard process, user needs to create manually. Based on the project requirements an enhancement to the standard BADI would be required have this automatically created by the system).
The contract object master data from PSCD is mapped technically in CRM as an individual
object. The basic and contract accounting data (Contract account, contract partner) of the
contract object in CRM is defined using specific set or relationship types.
k) Deposit (SSP) – This transaction will replicate to ECC system via standard CRM middleware as SXP
transaction (This is standard process).
Class CL_CRM_PS_4S_ERP_PERISTENCY
Middleware Object SXP_DOCUMENT
l) File (Case) – This will not replicate to any system. It will store the file (case) information.
m) In PSCD
Master Data Business Partner, Contract Account and Contract Object for all Deposits
Send Contract Object of the File(Case) – ARN to CRM
P a g e | 38
Get the Beneficiary split % (Percentage) and derive the amounts
Create Beneficiary cards (Contract objects)
Create DRNs(Documents) for each deposit and maintain the split
Upon receiving the Deposit amount, standard Job (Revenue distribution) will post the credits
as per the split maintained for each beneficiary Card
6. PAYMENT FILE PROCESSING
6.1. BUSINESS PROCESS REQUIREMENTS
Payment proposal file process will start in CRM and when the payment proposal is approved, the financial
data will replicate into ECC automatically via middleware.
6.2. BUSINESS PROCESS DESCRIPTION (RECEIVE APPLICATION)
Applications are received at all 15 Masters Office’s and DoJ&CD Service Points.
These application documents are received by administration clerk at service points or Guardian’s Fund
Offices then sent for validation and approval to the Reviewer at the 6 Guardians Fund offices.
Process Characteristics
Process Trigger Receiving of the Application in CRM System
Process Input Receive Application for withdrawal
Process Output Application record
Process Owner DoJ&CD – Guardian’s Fund Masters
Process Volumes Approx. 100,000 payment records per year
Process Frequencies Daily
P a g e | 39
Receive Application process flow diagram:
Applicant submits document
Documents complete?
Inform Applicant
No
Funds Available
Requirements Met?
Reviewer checks for completeness
Create Application
Request Additional Documents/
Declined
Validation with DHA
Yes
Yes
No
Submit Application to Main Office
Start
CRM DHA
Legend:
End
No
Move to other office?
Yes
Route Application to the relevant
office
Create Payment Proposal
No
Yes
Business Process Description (Payment Proposal)
Applications are received at 6 different offices of Guardian’s Fund. These application documents are validated
and approved for completeness by Accounting clerk, Assistant Master and Finance teams. Once the
application is ready for processing in system, clerk creates the payment proposal in the SAP CRM System.
Payment proposal application record goes through various approvals in the system. Once the final approval is
done in the CRM system, financial data is created and payment is ready to be processed in FI.
Process Characteristics
Process Trigger Creation of the Proposal in CRM System
Process Input Payment Proposal
Process Output Payment record
Process Owner DoJ&CD – Guardian’s Fund Masters
Process Volumes Approx. 100,000 payment records per year
Process Frequencies Daily
P a g e | 40
Create Payment proposal file process flow diagram:
Acc Clr - Creates Payment Proposal
Asst Master Approved?
Verifier 1 Approved?
Yes
Verifier 2 Approved?
Yes
Replicate in GFS
Yes
ProcessPayments
End
Start
No
No
No
6.3. MASTER DATA
1. Business partners are unique numbers and Business partner could be a person, organisation, group of
persons, or group of organisations in which Guardian’s Fund has a business interest. For example:
Beneficiary - refers to the person the money belongs to.
Guardian - refers to a person who has been nominated to care for the minors who are beneficiaries
of the fund
Payment Recipient – Schools, Transport (Payee)
2. Business partner relationships will be used for maintaining the relationships between originator, guardian
and beneficiary
3. Bank account details will be made mandatory for Payee role as outgoing payments are done only through
Electronic Fund Transfer (EFT) payment method.
6.4. APPLICATION AND PAYMENT PROPOSAL FILE
Application:
1. The applicant submits the application document and service point or Helpdesk.
2. The Helpdesk / Service point Clerk, verifies the documents,
P a g e | 41
While checking fund availability, system should display the existing deposits and location
While creating the application,
o System will display the beneficiary card details with location (excluding financial
information)
o The user will have an option to select the card.
o Once user has selected the card, the system will automatically determine the location.
3. Create Payment Application in CRM
There are four types of applications – Allowance, Investment, Final payment and Refund
(Refund to Depositor). ECC uses the payment proposal type – allowance payments to
calculate available capital balance.
System will populate the Surname, Full Name and Address
Banking Details - BP
Attach documents – using Document Management System
Applicant will sign electronically - Digital Signature
4. User will verify the thumb impression with DHA system
5. The clerk will send the physical documents to Guardians Fund office.
6. The reviewer (Guardian fund office), review the application documents and can take the decision to
approve, request additional documents/information or reject.
If the application is approved, it will be submitted to Accounting Clerk.
If additional information/documents are required, the application status set to ‘Pending’ and
notification is sent to the applicant.
If the application is rejected a notification must sent to the applicant and the application status
will set automatically as ‘Rejected by Reviewer’.
Note:
Service desk clerk will have ‘File Create’ authorization only
Payment Proposals:
a) Once document verification is completed, the Accounting Clerk creates a new Payment proposal in the CRM system and will submit to the Asst. Master for approval via Workflow. (attached payment proposal template)
b) Asst. Master, can approve or reject or can change the financial information.
If it is reject the Payment proposal goes back to Accounting Clerk and the status set to
‘Reject by Asst. Master’.
If the payment proposal is approved, it will submit to Verifier1.
c) Verifier1, can approve or reject, once the payment proposal is approved it will go to Verifier 2,
d) When the Verifier2, approves the financial information will replicate automatically to ECC via
middleware.
P a g e | 42
Note:
1. Payment proposal file is a unique number
2. Each file contains Originators, Beneficiaries, Payee and Payment Recipient.
3. User will attach the additional supporting scanned documents in the system.
4. Payment request could be from multiple beneficiary cards from multiple deposit files. However, CRM
sends the financial information one request per proposal to ECC.
5. There is a R 250 000.00 capital amount payment limit on allowance payments, for a beneficiary, till they reach claimable age.
6. This limit of R 250 000.00 is subject to change on court orders or in any other exceptional cases.( Application Type Private Investment will be used)
7. ECC will maintain Claimable capital limit and used capital amount balance fields at Beneficiary (Business partner) level. Used capital limit will be updated for every payment made out of beneficiary cards assigned to this beneficiary for “Allowance”. Payment Proposal type is sent by CRM system and is maintained in Document header (DFKKKO). Available Capital = Capital limit – Used capital and this information will update in CRM BP master.
8. Change in capital claimable amount limit will be sent by CRM system to ECC as part of Business Partner changes process after approvals and ECC updates the limit amounts accordingly.
9. There are Six types of payment proposals:
Allowance,
Private Investment (Property, Financial Institutions)
PIC Investment,
NRF Payment
Final payment and
Refund (Refund to Depositor).
P a g e | 43
ECC will use the payment proposal type – allowance payments to calculate available capital balance.
10. NRF will be created as a Business partner in CRM with Bank Details. 11. NRF receives 5% Commission and unclaimed beneficiary amount after 30 years of claimable date
ECC will trigger a regular job to check and identify funds that are due to be paid over to NRF (30 Years unclaimed funds), the program will take the funds and move them to General Ledger NRF Liability Account and the monies in the GL NRF Liability will be paid over toe the DoJ Vote account (NRF Business Partner) once a year.
System will have application type NRF payment with 2 General Ledger Accounts where money will be deposited into and paid to NRF Vote Account.
Each Guardian Office will have 2 Specific GL Accounts for NRF (Liability account and 5% Commission Account)
Commission product type payments will have 95% payment to creditors and 5% as commission payable to the NRF.
i. When a creditor requests a payment from the Guardian’s Fund - 5% of the amount must be paid to NRF 5% GL Account and will only be paid over to the DOJ&CD Vote Account once a year.
ii. Application Type: NRF Payment will be used for NRF 30 Years and NRF 5% iii. The system must have a dropdown selection from with GL account monies must flow
from and to Beneficiary (Business Partner) NRF. iv. The System must also have ability to specify the dates (From/To) to allow user to
select the period in which monies must be paid over to NRF
12. Any changes in existing payment proposal like frequency, payee, duration, amounts etc., are not allowed. Payment proposal can only be stopped and a new proposal is created after approvals in CRM system.
13. If there are any Beneficiary/Guardian changes, all beneficiary cards linked to these Beneficiary/Guardian will be locked and proposals (one-time/Recurring) will be stopped.
14. Lock is only for outgoing payments.
15. Deposits can be accepted on to this locked beneficiary card.
16. Request to unlock a beneficiary card will come from CRM after approvals and ECC will unlock only that beneficiary card.
17. Approved payment proposal triggers following activities in the ECC system:
a) One-Time Payment:
Post payment document on Beneficiary card with payee details provided in payment proposal.
Actual payment to the payee account is done through payment runs.
Scheduling of payment runs is done as decided by the Guardian’s Fund Business.
b) Recurring Payments:
Create payment request.
Actual payment to the payee account is done through payment runs.
Scheduling of payment runs is done as decided by the Guardian’s Fund Business.
18. If the file is missing any mandatory field(s) information, the system will not allow it to be submitted for approval.
P a g e | 44
Important field’s information
Description Default Type Mandatory
Application Type Blank Dropdown Yes
Application Number & Date Blank System generates N/A
Last Document Date Blank Date Yes
Proposal Number Blank N/A N/A
Beneficiary Blank Free text - Search enabled Yes
Guardian Blank Free text - Search enabled Yes
Payee Blank Free text - Search enabled Yes
Quotation Details
School Fee, Transportation, Allowance
Allowance Dropdown Yes
Required Amount Blank Number Yes
Notes
Attachment
6.5. CHANGE PAYMENT PROCESS
Changes will happen in the following areas,
a) Master data b) Transaction data
The following Master Data changes can be applied based on user authorisations and applicable approval flow:
Payee Bank details, Address (Business Partner)
Frequency of payments (Contract Account - Business Agreement)
The following Transaction data changes can only be applied if the payment process is not completed and based on user authorisations & applicable approval flow:
Add Payee
Payment amount changes - only Asst. Master can change the amount Only when the changes are approved, will the information flow to ECC system automatically via middleware When the user triggers the change process, the system automatically locks the BP’s beneficiary cards across the locations and once it is finally approved, it will unlock automatically for the user’s location, and other location’s beneficiary cards should unlock manually.
P a g e | 45
Based on user authorization, user can unlock the beneficiary cards.
6.6. NOTIFICATIONS
a) The system will display unprocessed applications on the user’s WEBUI page b) If the application not processed with in 36hrs, a notification will be sent to the “Reviewer’ for re-
allocation. c) Once payment process is approved / rejected, a notification will be sent to the applicant. d) When the application is submitted/ approved/ rejected a notification will be sent to the applicant.
7. REFUND TO DEPOSITOR
Create Refund Request
Does Depositor Exist?
Post Receivable Documents on
Beneficiary CO with Payers as Depositor
Process PaymentStart Does the
Beneficiary Card Exist?
Yes Yes End
No
No
a) There are scenarios where Guardian’s Fund could refund the deposit amount back to depositor or when the user identifies funds that should be refunded to depositor, the user will capture the Refund Request (payment proposal).
b) Request for this will be triggered from CRM system through payment proposal with payment type as “Refund”.
c) These will be created as Refund payments to the depositor as a payee (BP).
d) If payee is not available, system will show an error message.
e) User need to create Refund Request in system with beneficiary ID and amount. System should
calculate the amount (this is enhancement)
Start
End
Change (Stop) ProposalDoes Proposal Number Exist?
Cancel Payment(s)
Update CRM with Status
Cancel Payment(S)
Are there Payment Details?
Yes
Proposal Type
Scheduled Payments?
RecurringIs the Payment
Made?One-Time Yes
Yes
No
Update CRM with Status
No
P a g e | 46
f) When the user submits the Refund Request for approval, system will trigger the same approval
workflow as the Payment Proposal approval. g) Once the payment proposal is approved finally in CRM, the financial information will replicate into
ECC.
h) ECC will make the required payment to the depositor.
i) ECC will only pay Capital amount from the beneficiary card after deducting the interest payments made.
j) Adjustment for interest will be done from the Receipt Date.
Gaps
Automatic amount display (calculation), It is not a CRM Standard functionality it requires an enhancement/customization to display the amount in CRM.
8. FRAUD/ LOSS/ OVERPAYMENT
Fraud/ Loss/ Theft/ Overpayment are identified on a file; Guardian’s Fund gets refund from Legal liability or fraudulent person. This is processed as a separate incoming payment into Beneficiary card. In the new SAP solution,
There will be no Overpayment due to automatic calculations and system will not allow for negative balances.
P a g e | 47
Process flow for Fraud will be as follows:
1. Applicant submits application for payment 2. Official identified the fraudulent transaction 3. Official create a Task in CRM system, start the internal investigation process 4. If the investigation is positive, the information will pass to Loss Control officer. If investigation is negative
the task will end. 5. Loss Control Officer will create a new Fraud Case in the CRM system and starts the investigation
process. And, the user attaches all scanned documents in CRM. E.g. affidavit, audit trail, and bank statements of applicant.
Loss control Officer must compile a report and complete Annexure-K (AK) – Annexure K should trigger by CRM.
Report case to SAPS or request applicant to open case with SAPS. Scanned document will be attached in CRM (This is out of system)
6. Loss Control Officer will send the Case to Deputy Master for further investigation. Deputy Master verify the information and will start the investigation process and if the fraud is
identified,
P a g e | 48
user will generate Memo in the system with reflecting the case details, reflecting possible negligence, request determination of liability, and request to refund the relevant amount to Guardians Fund with accrued interest
Send to Chief Director/ Chief Master for further investigation. If need more information the file will be re-direct to Deputy Master.
7. Office of Chief Master (OCM) will check for negligence and takes up the case with legal liability department (LLD) by sending a memo reflecting the case details, reflecting possible negligence, request determination of liability, and request to refund the relevant amount to Guardians Fund with accrued interest.
8. Legal liability department will allocate the case to internal official. 9. Legal liability department conduct and investigation for the case on behalf of Guardian’s Fund and
inform the office about the status 10. The legal liability office will provide the office with the verdict of the case. 11. If case is resolved, the fraudulent beneficiary/perpetrator is asked to refund money into the Guardian’s
Fund. Deposit will be accounted for in terms of the acceptance of money process. ECC system will generate DRN number and the same will be updated in CRM.
12. If a case is not resolved in a stipulated time, legal liability department refunds the amount to Guardian’s Fund
13. Guardian’s Fund receives money from legal liabilities and the deposit clerk accounts for it in the acceptance of money process.
Important fields to consider:
Description Default Type Mandatory
Fraud Case Type Blank Dropdown Yes
Notes Blank N/A N/A
Create Date Current Date N/A Yes
Loss Controller Officer System will determine automatically N/A Yes
Deputy Master System will determine automatically N/A Yes
CD/CM System will determine automatically N/A Yes
LLD Officer System will determine automatically N/A Yes
Loss Controller System will determine automatically N/A Yes
LLD Allocation User System will determine automatically N/A Yes
DRN Number System will determine automatically N/A Yes
Amount System will determine automatically N/A Yes
Dates System will capture automatically the dates N/A Yes
9. INTEGRATION WITH ECC – CREATE PAYMENT PROPOSAL / CHANGE PROPOSAL, REFUND TO DEPOSITOR AND FRAUD/ LOSS/ OVERPAYMENT
Note: As standard functionalities are proposed, the integration process will be the same from CRM point of view.
Business Partner replication will happen via middleware as like Deposit process. Here, we are replicating Beneficiary, Guardian and Payment Recipient for Payment Proposal
In CRM the system user will fill the data (Attached field’s data), All the required data will be replicated to PSCD system.
P a g e | 49
Please find the enclosed high-level fields information.
Worksheet Deposits
MasterData and Proposal DOJ Solution Design.xlsx
SAP has provided the standard integration/replication functionalities in PSCD Business suite, which will be used for creating application, payment proposal file, changing payment proposal and refund to depositor
Once the file is approved in CRM system, data will be replicated to PSCD system for further activities.
Find below diagram which is explaining the standard integration/replication functionalities.
Each file (case) contains unique number.
Each file and payment proposal, refund to depositor (SSP) contains Business Partners (Beneficiary, Guardian and Payment Recipient).
o Business Partners will be replicated via standard middleware functionality.
For account postings in PSCD system Contract Account (Business Agreement in CRM) is required.
o Implement the standard BADI (PSSC_ACC_MD_CREATE) to replicate the data
automatically to PSCD system.
Payment Proposal (SSP) and Return to Deposit – This transaction will replicate to ECC system via
standard CRM middleware as SXP transaction (This is standard process).
o Class CL_CRM_PS_4S_ERP_PERISTENCY
o Middleware Object SXP_DOCUMENT
Application (Case) – This will not replicate to any system. It will store the file (case) information.
In PSCD Create payment proposal triggers following activities:
• One-Time Payment:
o Post payment document on Beneficiary card with payee details provided in payment proposal
o Actual payment to the payee account is done through payment runs.
P a g e | 50
o Scheduling of payment runs is done as decided by the Guardian’s Fund Business
• Recurring Payment:
o Create payment request
o Actual payment to the payee account is done through payment runs. Scheduling of payment runs
is done as decided by the Guardian’s Fund Business
Changes to an existing proposal will trigger “Stop Payment”. And a new proposal data will be sent by CRM to ECC.
In case of any exceptions, send Error messages back to CRM. Upon bank statement upload, send status of Payments back to CRM.
9.1. PAYMENT RUN
1. Only Electronic Fund Transfer (EFT) is used for making outgoing payments. 2. All the outgoing payments are initiated by Guardian’s Fund and processed through payment program.
3. Payment status is updated back to CRM system.
4. Payment program considers open items due for all beneficiaries (BP’s) or contract accounts/contract
objects selected as part of the payment program execution.
5. Clearing rules will be configured in ECC to take into consideration interest first rule for payments from Beneficiary card. In case of refunds to depositor, only capital is paid. This will be achieved through clearing rules configuration.
6. Frequency of the payment runs can be based on the business requirements and payee types (Regular
beneficiary payments /NRF payments)
7. Commission product type payments will have 95% payment to creditors and 5% as commission to NRF
8. NRF payments will not be paid on a regular basis but as a consolidated amount at defined frequency by business (once in a year)
9. NRF will be created as a Business partner in ECC. NRF will also receive unclaimed beneficiary amount
after 30 years of claimable date
10. Trigger for NRF (5% or 30-year unclaimed) payment runs will come from CRM with from / to dates
Gaps:
Batch program to identify and transfer 30-year unclaimed beneficiary amounts to NRF Interface for NRF payment Trigger
P a g e | 51
9.2. RETURNED PAYMENTS
1. SAP returns component enables to process returns which may occur with Cheque deposits or outgoing
payments.
2. Returns are combined in return lots which are created automatically by copying return data from electronic bank statement.
3. Once the return lot is processed an additional document is posted for reversal.
4. Following diagram shows the standard activities performed as part of returns.
5. Guardian’s Fund does not use charges for return and no “further activities” are executed as part of return. Returns at Guardian’s Fund will cancel the clearing and also update the return history.
6. For a returned outgoing payment CRM will be updated with payment status through interface.
7. Return reasons will be configured and updated on reversal document.
8. Indicative Return reasons could be:
a. Insufficient funds in an account b. Closed account c. False account
P a g e | 52
10. JOURNALS Journals are used to move money from one account to another account. Journal transfers will always be Capital amount transfers except in case of usufruct and FC cases where Interest amount transfers are possible. Following scenarios are possible at Guardian’s Fund for Journal:
User will create file (Credit Memo request & Debit Memo request) in the system with Beneficiary details and amount and submit for approval.
While creating the document, system will check the fund availability. If funds are not available, an error message will display and will stop further activities.
Once approved the file, the information will replicate into ECC system automatically via middleware. In ECC, the posting will happen and DRN number will be updated in CRM system.
Important Fields to Consider
Description Default Type Mandatory
Journal Number Blank System will generate Yes
Date Current Date Date Yes
Beneficiary from Blank Text – Search functionality enabled
Yes
Start Journals
Journal Category
Items Found?
Check Suspense Account Item and Beneficiary
CardSuspense - Ben
Show Error Message - CRM
No YesCheck and Adjust
Interest
Check From and To Beneficiary cards
Ben - Ben
Check Surplus GL Account and Beneficiary
Card
Surplus-Ben
Start
Post Entries
P a g e | 53
Description Default Type Mandatory
Beneficiary To Blank Text – Search functionality enabled
Yes
Amount Blank Number Yes
Accounting Clerk System determines automatically N/A N/A
Assistant Master System determines automatically N/A N/A
Approver 1 System determines automatically N/A N/A
Reason Blank Text Yes
Suspense Account Guardian’s Fund has unidentified monies maintained in a separate module called “Suspense Account” in their legacy system. These suspense records will be moved from legacy system to CRM/ECC as part of data migration.
10.1. SUSPENSE TO BENEFICIARY
CRM will send details of Suspense account line item id and amount along with the file information for these
cases. Suspense to beneficiary journals could lead to a new file creation or new deposit to an existing file.
a) New file:
i. If there is no file created so far for the deposit, need to create a new file with Beneficiary,
Originator and amount details along with line item details.
ii. Once the file submitted for approval, CRM system will trigger workflow to take decision. When
the file is approved, the file information will be sent to ECC.
iii. ECC will create ARN for File and beneficiary structure table will be updated with ‘0.00’ amount
for each beneficiary.
iv. There will be no DRN generated for this scenario as we have amount already available in
suspense account.
v. Create Beneficiary master data as per the data maintained on Deposit contract object (ARN)
vi. CRM will send Journal from Suspense Account record to Beneficiary cards (one Journal
transaction per beneficiary card)
vii. Only the capital amount will be Journaled from suspense account to beneficiary card
viii. Negative interest adjustment document for the interest calculated amount from the Receipt Date
will be posted against suspense account
ix. User will capture the Interest calculation receipt date in CRM and the information will be sent to
ECC. ECC will calculate the interest for all interest-bearing beneficiary cards and post it as a
positive interest adjustment
b) New deposit into an existing file:
i. This will be treated as an additional deposit into an existing file described in Change deposit file
scenario.
ii. Beneficiary structure table will be updated with new beneficiary structure records for this deposit
with ‘0.00’ amount for each beneficiary.
iii. There will be no DRN generated for this scenario as we have amount already available in
suspense account.
iv. Create Beneficiary structure as per the data maintained on Deposit contract object (ARN)
v. CRM will send Journal from Suspense Account record to Beneficiary cards (one Journal
transaction per beneficiary card)
vi. Only the capital amount will be Journal-ed from suspense account to file
vii. Negative interest adjustment document for the interest calculated amount from the Receipt Date
will be posted against suspense account
P a g e | 54
viii. User will capture the Interest calculation receipt date in CRM and the information will be sent to
ECC. ECC will calculate the interest for all interest-bearing beneficiary cards and post it as a
positive interest adjustment
10.2. BENEFICIARY TO BENEFICIARY
These journals could be from one product type to other product type or with in the same product type.
Interest adjustments will be triggered in ECC accordingly.
From To From - int Adjustments? To - int Adjustments?
Interest Non-Interest Yes No
Interest Commission Yes No
Non-Interest Interest No Yes
Non-Interest Commission No No
Commission Interest No Yes
Commission Non-Interest No No
Interest Interest Yes Yes
Non-Interest Non-Interest No No
Commission Commission No No
GL - Surplus Interest Yes Yes
GL – Surplus Commission No No
GL - Surplus Non-Interest No No
Interest adjustment scenarios and indicative calculations are provided in the embedded document for
different scenarios discussed.
Interest_Adjustments.
xlsx All previous years’ interest adjustments will be done in immediate prior year and current year
adjustments are done in current year
All interest adjustments will be posted to Interest payable GL account.
10.3. BENEFICIARY TO SUSPENSE – THIS WILL NOT BE USED IN GFS
1. Journal Reason is captured as part of Journals interface, for reporting purpose.
2. CRM to send interest adjustment indicator (Product type) for all usufruct journal cases and ECC will do the interest adjustments based on this indicator. Only in case of usufruct/FC, interest to interest journals are processed. The Interest adjustment date will be entered by user in CRM system
3. Capital transfers in case of usufruct/fc can also come with Transfer effective date. In these cases, ECC needs to do the interest adjustments based on the transfer effective date rather than Receipt Date. The Transfer effective date information will be entered by user in CRM system.
Gaps:
If suspense account is maintained as G/L account in GFS, then need to enhance the program to select
the suspense record. Standard CRM does not have the functionality to select the GL record.
P a g e | 55
11. PIC INVESTMENT AND WITHDRAWAL PROCESS Investment process diagram
Withdrawal process diagram
PIC Investment and Withdrawal process steps:
CRM system will send the PIC Investment or Withdrawal information through middleware.
In case of Investment,
o User create file (Credit memo request / Debit memo request) and submits for approval.
o When it is submitted for approval, system will trigger workflow.
o Once approved, the information will be sent to ECC via middleware.
o Post document in ECC for investment with PIC business partner and amount instructed
by CRM system.
o Pay out to PIC using payment run in ECC, which posts the financial entry for PIC
investment.
In case of Withdrawal,
o User must create Credit memo request / Debit memo request and submits for approval.
o When it is submitted for approval, system will trigger workflow.
o Once approved, the information will be sent to ECC via middleware.
o Post document in ECC for withdrawal with PIC business partner and amount instructed
by CRM system. This document number is referred as Deposit Reference Number
(DRN).
o ECC will send DRN back to CRM system.
Note: Deposit reference number generated through interface is valid only for 30 working days (number of days will be decided as part of implementation). If there is no deposit received before expiry date, DRN will be reversed in ECC through a batch program.
P a g e | 56
12. FINANCE PROCESSES
12.1. BANK ACCOUNTING Bank accounting module helps company manage all its transactions to be done via its bank accounts. These transactions include: bank master data management, automatic payments and bank statements. In this document, we will cover – bank master data management and bank statement. Bank Master Data For a company to conduct transactions though its own bank account, ‘House Bank’ master data set up is required in the system. Following characteristics are maintained for the house bank: House bank id and Account id. Account id consists of: bank’s account number, account currency and the relevant GL account. At present, there are six (6) bank accounts are being used by Guardian’s Fund. Following three general ledger accounts are to be defined for each bank account as follows:
Incoming transfer,
Outgoing transfer and
Main Control Account. For ease of use, the general ledger account convention is: last digit ‘0’ for main control account, ‘1’ for outgoing transfer and ‘2’ for transfer incoming. All six (6) bank accounts are having at different branches of ABSA bank. All accounts will be created under separate house bank. Following is the process map for creating/changing the bank master data: usually undertaken by the master data management team.
Bank Master Data
SAP System
Bank
Mas
ter D
ata
Man
agem
ent P
roce
ss
Request to Open House Bank
Create House bank account(FI12)
Request to Open Bank GL Account
Created Bank GL Account(FS00)
Request to Open Bank Account ID
Create banks Account ID
(FI01)
Electronic Bank Statement (MT940 format) Following are the process steps for Automatic bank reconciliation process:
Bank will place bank statement (MT940 format) in a defined folder in application server.
Batch Job will pick bank statement from this folder in application server and uploads.
P a g e | 57
Business transactions need to be configured in SAP system, which are mapped in the line items
of Bank statement
System will automatically assign to the open items and post them.
If there are any error items, user can correct them by accessing FEBAN transaction.
Whenever any error item is corrected by user, Guardian’s Fund requires an approval work flow to
be triggered.
This request will be approved by Verifier 1 and verifier 2.
At any level if the request is rejected, corrected entry should not be processed.
If all approvers approve this item, then only post the financial entry.
Electronic Bank Reconciliation
SAP System
Elec
tron
ic B
ank
stat
emen
t Pr
oces
s
Bank statement(MT940
format) available in defined path.
Batch Job to upload bank statement
Any unprocessed
records?
Manual correction
FEBAN
Check and trigger Payment/return Lot
to PSCD
Post financial entry
No
Yes
Manual correction
FEBAN
Workflow triggered and send to approvers
Any error found by the approvers?
Posted the financial entry
Rejected by the approver
Yes
No
Check and trigger Payment/return Lot
to PSCD
P a g e | 58
12.2. AUTOMATIC CLEARING PROCESS Guardian’s Fund Automatic clearing happens as part of transaction processing (bank statement upload and payment runs).
12.3. PIC INVESTMENT & WITHDRAWAL PROCESS
PIC Investment and Withdrawal process steps:
ECC will send request for PIC Investment or Withdrawal through interface PIC Investment /
Withdrawal.
In case of Investment,
o Post document in ECC for investment with PIC business partner and amount instructed
by CRM.
o Pay out to PIC using payment run in ECC, which posts the financial entry for PIC
investment.
In case of Withdrawal,
o Post document in ECC for withdrawal with PIC business partner and amount instructed
by CRM. This document number is referred as Deposit Reference Number (DRN).
o ECC will send DRN back to CRM.
Note: Deposit reference number generated through interface is valid only for 30 working days (number of days will be decided as part of implementation). If there is no deposit received before expiry date, DRN will be reversed in ECC through a batch program.
Refer to technical section for flow of PIC Investment / Withdrawal interface.
P a g e | 59
12.4. PIC INVESTMENT JOURNAL ENTRY (INTEREST RECEIVED)
Guardian’s Fund needs to post the journal entries for PIC investment and other adjustment postings. Interest received from PIC will be directly posted in SAP. No interface required.
12.5. DOCUMENT REVERSAL This scope item describes the procedure for reversing FI documents. During this process, the system generates accounting documents, adds information to existing documents and updates the transaction figures in the affected ledgers. When business posts the reversal, the system reverses the source document. The selection of the reversal reason allows business to give the transaction figures (following the reversal) the status they would have had without posting the reversed document and its reversal document. This type of reversal is called a negative posting. Whenever user posts the accounting document (ex. PIC Interest document), there is the possibility that the posted document would need to be reversed. In this case the user would need to execute the T-Code FB08 (Transaction launcher from CRM). When document is reversed the Guardian’s Fund wants to trigger approval flow of two levels (verifier 1 and verifier 2). If workflow is rejected at any level, reversal should not post any negative document. If workflow is approved by all approvers, then only reverse the document.
P a g e | 60
13. TECHNICAL/DEVELOPMENT RELATED ITEMS
13.1. WORKFLOW
Workflows
WRICEF ID
Description Data Object (Sales Order)
Engaged Parties Owner
W001 File (Case) Approval Document Based on org. CRM
W002 File - Change Process Approval
Approvals Based on Approvers CRM
W003 FEBAN Corrections Approvals
Bank statement record
To be defined by Guardian’s Fund during implementation
ECC
W004 FI Document Reversal Approvals
FI Document To be defined by Guardian’s Fund during implementation
ECC
W005 FEBAN Corrections Approvals
Bank statement record
To be defined by Guardian’s Fund during implementation
ECC
W006 FI Document Reversal Approvals
FI Document To be defined by Guardian’s Fund during implementation
ECC
File (Case) Approvals:
For Deposits/Payment file creations, 3 level approvals are needed.
P a g e | 61
File – Change Process Approvals
For Deposits/Payment, each change processes, 2 level approvals are needed.
FEBAN Corrections Approvals:
When the bank statement is uploaded some of the transactions in the bank statement may not have proper data to match the ECC records. These records will be put into Unprocessed record list (FEBAN). When user corrects these records manually approval workflow is triggered to process.
Number of levels of approvals and approval user details will be decided and configured as part of implementation.
FI Document Reversal Approvals
Whenever manual document is posted incorrectly, user will reverse this document. Reversal process would trigger this workflow. Use BTE event 1040 can be used to trigger workflow. Business Object BKPF and Event “ACCOUNTINGDOCUMENT.CLEARINGREVERSED” of business object BKPF can be used. During implementation phase business will decide based on the detailed requirement.
13.2. REPORTING
WRICEF
ID Description
Report Type
(ABAP, BI,
BOBJ)
Online/
Batch Owner
R001 Allocation Bucket List Report (Application Report)
ABAP Online CRM
R002 Application Analysis Report ABAP Online CRM
R003 Audit Trail Report ABAP Online CRM
R004 Beneficiary Card details ABAP Online CRM
R005 Beneficiary List Report ABAP Online CRM
R006 File Age Analysis (APP) Report ABAP Online CRM
R007 File Details Changes Report ABAP Online CRM
R008 File Tracking Report ABAP Online CRM
R009 Fraud and Loss Report ABAP Online CRM
R010 Gazette Fund Report ABAP Online CRM
R011 Identity Verification Certificate ABAP Online CRM
R012 Production Report ABAP Online CRM
R013 Report to show workflow activities ABAP Online CRM
R014 Service Point List Report ABAP Online CRM
R015 User Profile Report ABAP Online CRM
R016 30 Year Unclaimed Beneficiary Report ABAP Online ECC
R017 5% Commission List Report ABAP Online ECC
R018 Bank Reconciliation ABAP Online ECC
R019 Bank reconciliation processed Items report ABAP Online ECC
R020 Bank reconciliation unprocessed Items ABAP Online ECC
R021 Beneficiary card Report ABAP Online ECC
R022 Cash Book ABAP Online ECC
R023 Close Beneficiary cards ABAP Batch ECC
R024 Daily report with valid DRNs (Bank) ABAP Batch ECC
R025 IT3(B) Certificate (Interest Earned for Beneficiary card in an income tax year)
ABAP Online ECC
P a g e | 62
WRICEF
ID Description
Report Type
(ABAP, BI,
BOBJ)
Online/
Batch Owner
R026 IT3(B) File to SARS ABAP Online ECC
R027 Journal Report ABAP Online ECC
R028 Journal Report ABAP Online ECC
R029 List of payments Report ABAP Online ECC
R030 List of posted deposits Report ABAP Online ECC
R031 Negative balance Report ABAP Online ECC
R032 Recurring payment list Report ABAP Online ECC
R033 Reversal of DRNs after expiry ABAP Batch ECC
R034 Suspense account Report ABAP Online ECC
P = Parameter which accepts only single value. If no value is given, fetches all data
S = Select options which can accept multiple values. If no value is given, fetches all data.
Administration Reports Specification
DoJCD_GFS_ Reports_Final_Review.pdf
Financial Reports Specification
DoJCD_GFS_Solution Design Document_V0 4.docx
Beneficiary Card Report
Purpose
The purpose of this report is to provide users with the ability to view all monies which are allocated to a Beneficiary. This will include the balances, debit entries, credit entries, and interest generated.
Trigger:
This is an ad-hoc report and should be accessed through CRM system via SAP GUI in HTML
Input
Parameter Type Description
DPSOB-ZZ_FILE_GFNUM P File GF Number
DPSOB-LEGACYOBJK1 P Beneficiary reference Number (card number)
Person: BUT000-NAME_LAST Organization: BUT000-NAME_ORG2 Group: BUT000-NAME_GRP2
P Beneficiary Name
Person: BUT000-NAME_FIRST Organization: BUT000-NAME_ORG1 Group: BUT000-NAME_GRP1
P Beneficiary surname
BUT0ID-IDNUMBER P Beneficiary ID Number
Person: BUT000-BIRTHDT Organization: BUT000-FOUND_DAT
P Beneficiary DOB
DPSOB-ZZ_GF_OFFICE P Guardian Fund office
DFKKKO-CPUDT S Date From, Date To
P a g e | 63
Output
For provided selection data, get Beneficiary details and display ALV report with:
Column Mapping
Header DoJ&CD Logo Logo
Masters: Guardian Fund Office DPSOB-ZZ_GF_OFFICE
Office Address Use BAPI_PROFITCENTER_GETDETAIL to get address
Tel Number use BAPI_PROFITCENTER_GETDETAIL to get Tel Number
Date (DD/MM/YYYY) From and To dates from selection screen
Beneficiary Surname Person: BUT000-NAME_LAST Organization: BUT000-NAME_ORG2 Group: BUT000-NAME_GRP2
Beneficiary Name Person: BUT000-NAME_FIRST Organization: BUT000-NAME_ORG1 Group: BUT000-NAME_GRP1
Beneficiary DOB BUT000-BIRTHDT
Guardian Full Name Get Guardian BP maintained in Facts and derive Name from BUT000 accordingly
Beneficiary DOM BUT000-ZZ_DOM for Person
Classification Type DPSOB_BP_ACC-PARTNERACCTYP
Sub Classification Type DPSOB-PSOBTYP
Details
File Status/Activity
ZZ_FILE_STATUS from facts for file status and "Deposit", "Payment" "Interest" "Balance" "Int. Adjustment" "Cap. Adjustment" etc., in activities
Description Description of the Activity
Date Date on which activity happened
Capital Capital amount DFKKOP-BETRW of Beneficiary card
Payment Payment amount DFKKOP-BETRW of Payment document of Beneficiary card
Accrued Interest Interest accrued amount DFKKOP-BETRW of Accrued Interest document of Beneficiary card
Balance – Capital Give the split of Payment amount taken from Capital then give the Capital Balance DFKKOP-BETRW
Balance – Interest Give the split of Payment amount taken from Interest and then give the Interest Balance
Negative balance Report
Purpose
There are scenarios where the Beneficiary card may end up in negative balance. This report will give details of those beneficiary cards.
Trigger
This is an ad-hoc report and should be accessed through CRM system via SAP GUI in HTML
Input
Parameter Type Description
DPSOB-LEGACYOBJK1 S Beneficiary reference Numbers
P a g e | 64
DFKKKO-CPUDT S From and To Date
Output
Header DoJ&CD Logo Logo
Masters: Guardian Fund Office DPSOB-ZZ_GF_OFFICE
Office Address use BAPI_PROFITCENTER_GETDETAIL to get address
Tel Number use BAPI_PROFITCENTER_GETDETAIL to get Tel Number
Date (DD/MM/YYYY) From and to dates from selection screen
Details
Beneficiary Surname Person: BUT000-NAME_LAST Organization: BUT000-NAME_ORG2 Group: BUT000-NAME_GRP2
Beneficiary Name Person: BUT000-NAME_FIRST Organization: BUT000-NAME_ORG1 Group: BUT000-NAME_GRP1
Beneficiary Reference Number DPSOB-LEGACYOBJK1
Classification Type DPSOB_BP_ACC-PARTNERACCTYP
Sub Classification Type DPSOB-PSOBTYP
Amount DFKKOP-BETRW
ID Number BUT0ID-IDNUMBER
List of Posted Deposits Report
Purpose
This report will give details on list of all Deposits.
Trigger
This is an ad-hoc report and should be accessed through CRM system via SAP GUI in HTML
Input
Parameter Type Description
DFKKKO-CPUDT S From and To Dates
Drop Down P Financial Year
Check box P Show Detail
Status P Deposit status
Output
Column Mapping
Header
DoJ&CD Logo Logo
Masters: Guardian Fund Office DPSOB-ZZ_GF_OFFICE
Office Address use BAPI_PROFITCENTER_GETDETAIL to get address
Tel Number use BAPI_PROFITCENTER_GETDETAIL to get Tel Number
Date (DD/MM/YYYY) From and To dates from selection screen
P a g e | 65
Column Mapping
Header
Deposit Reference Number (DRN) ZCPSOB_BEN- DEPOSIT_REFNUM
Receipt Number ZC_RECEIPTS-RECIPT_NUM
Drawer's Name
Depositor BP
Person
BUT000-NAME_LAST and NAME_FIRST
Organization
BUT000-NAME_ORG2 and NAME_ORG1
Group
BUT000-NAME_GRP2 and NAME_GRP1
Amount DFKKOP-BETRW of the Deposit
Details
GF File Number ZCPSOB_BEN-ZZ_FILE_GFNUM
File Description ZCPSOB_BEN-ZZ_FILE_DESC
Classification Type ZCPSOB_BEN-BENEFICIARY_TYPE
Sub Classification Type ZCPSOB_BEN-BENEFICIARY_SUB_TYPE
Beneficiary Get Beneficiary name using ZCPSOB_BEN-BENEFICIARY_BP
Amount Split ZCPSOB_BEN-BENEFICIARY_SPLIT_AMT
Status Deposit Status (Created, Cleared, Rejected)
Receipt Date Date on which deposit is received (Value date of the Deposit)
Sub Total per Payment Method (EFT /Journal) Day, Month and year and Grand Total
List of Payments Report
Purpose
This report will give list of all one-time or recurring payments list.
Trigger
This is an ad-hoc report and should be accessed through CRM system via SAP GUI in HTML
Input
Parameter Type Description
DFKKKO-CPUDT S From and To Dates
Drop Down P Financial Year
Check box P Show Detail
Status P Payment status
Output
Column Mapping
Header
DoJ&CD Logo Logo
Masters: Guardian Fund Office DPSOB-ZZ_GF_OFFICE
Office Address use BAPI_PROFITCENTER_GETDETAIL to get address
P a g e | 66
Column Mapping
Header
Tel Number use BAPI_PROFITCENTER_GETDETAIL to get Tel Number
Date (DD/MM/YYYY) From and To dates from selection screen
GF File Number DPSOB- ZZ_FILE_GFNUM
File Description DPSOB- ZZ_FILE_DESC
EFT Number Payment Document Number
Amount Payment Amount
Details
Payee
Person BUT000-NAME_LAST and NAME_FIRST Organization BUT000-NAME_ORG2 and NAME_ORG1 Group BUT000-NAME_GRP2 and NAME_GRP1
Beneficiary
Person BUT000-NAME_LAST and NAME_FIRST Organization BUT000-NAME_ORG2 and NAME_ORG1 Group BUT000-NAME_GRP2 and NAME_GRP1
Classification Type ZCPSOB_BEN-BENEFICIARY_TYPE
Sub Classification Type ZCPSOB_BEN-BENEFICIARY_SUB_TYPE
Amount ZCPSOB_BEN-BENEFICIARY_SPLIT_AMT
Status Payment Status (Created, Cleared, Rejected)
Payment Date Date on which Payment is made(DFFKKOP-AUGDT)
Sub Total per Day, Month and year and Grand Total
Daily report with valid DRNs (Bank)
Purpose
This report gives the list of all valid DRNs that will be validated by bank before accepting deposit.
Trigger
This is a batch job in ECC which will create a file with valid DRNs for the day and places the file in defined folder in application server.
Input
Parameter Type Description
DFKKKO-CPUDT S DRN Date
Output
Column Mapping
Depositor BUT0ID-IDNUMBER/KNA1-LIFNR
ARN DPSOB-PSOBKEY
DRN DFKKOP-OPBEL/ BSEG-BELNR
Amount DFKKOP-BETRW BSEG-DMBTR
P a g e | 67
5% Commission List Report
Purpose
This report will give list of records with 5% NRF amounts.
Trigger
This is an ad-hoc report and should be accessed through CRM system via SAP GUI in HTML
Input
Parameter Type Description
DFKKKO-CPUDT
S From and To Dates
Drop Down P Financial Year
Check box P Show Detail
Status S Status of payment
Output
Column Mapping
Header DoJ&CD Logo Logo
Masters: Guardian Fund Office DPSOB-ZZ_GF_OFFICE
Office Address use BAPI_PROFITCENTER_GETDETAIL to get address
Tel Number use BAPI_PROFITCENTER_GETDETAIL to get Tel Number
Date (DD/MM/YYYY) From and To dates from selection screen
Date DFKKKO-BUDAT
Description Creditor Name
Debit DFKKOP-BETRW (in case of returns)
Credit DFKKOP-BETRW ( in case of payments)
Details
GF Number DPSOB-ZZ_FILE_GFNUM
Reference Number DFKKOP-OPBEL
From/To Creditor CO(Beneficiary Card number ) to NRF / NRF to Creditor CO(Beneficiary Card number )
Amount DFKKOP-BETRW
Status Status of the Payment (Created, Cleared)
30 Year Unclaimed Beneficiary Report
Purpose
This report gives the list of all unclaimed monies for 30 years from claimable date
Trigger
This is an ad-hoc report and should be accessed through CRM system via SAP GUI in HTML
Input
Parameter Type Description
DFKKKO-CPUDT S From and To Dates
Drop Down P Financial Year
P a g e | 68
Check box P Show Detail
Output
Column Mapping
Header DoJ&CD Logo Logo
Masters: Guardian Fund Office DPSOB-ZZ_GF_OFFICE
Office Address use BAPI_PROFITCENTER_GETDETAIL to get address
Tel Number use BAPI_PROFITCENTER_GETDETAIL to get Tel Number
Date (DD/MM/YYYY) From and To dates from selection screen
Date DFKKKO-BUDAT
Details
Reference Number DFKKOP-OPBEL
Account DPSOB-PSOBKEY
GF File Number ZCPSOB-ZZ_FILE_GFNUM
Amount DFKKOP-BETRW
Pay-over due Date Claimable date + 30 years
Paid Date Payment to NRF Date
Classification Type DPSOB_BP_ACC-PARTNERACCTYP
Sub classification type DPSOB-PSOBTYP
IT3 (B) Certificate (Interest Earned for Beneficiary card)
Purpose
This certificate will be given to the beneficiary on accrued interest amount for the year and is given individual beneficiaries.
Trigger
This is an ad-hoc report and should be accessed through CRM system via SAP GUI in HTML
Input
Parameter Type Description
BUT000-BPEXT P Beneficiary BP
Drop Down P Tax Year
DPSOB-LEGACYOBJK1 S Beneficiary Card No
Output
P a g e | 69
Beneficiary master data details from BUT000, address from BUT020, ADRC and Bank details from BUT0BK.
Account balance and interest received should be from DFKKOP-BETRW for document types Capital and Interest for this Beneficiary.
IT3 (B) File (to SARS)
Purpose
This certificate will be given to the beneficiary on accrued interest amount for the year and is sent to SARS.
Trigger
This is an ad-hoc report and should be accessed through CRM system via SAP GUI in HTML
Input
Parameter Type Description
Drop Down P Tax Year
Output
Refer to the attachment for layout (This document can change based on SARS requirements)
Business
Requirement Specification IT3s Data Submission.pdf
Details Get details data from ZC_JOURNALS table
JRN Journal Reference Number
DPSOB-ZZ_FILE_GFNUM GF File Number
DPSOB-ZZ_FILE_DESC File Description
FROM_ACCOUNT Journal from account
TO_ACCOUNT Journal to account
FROM_CAPITAL_DOC Capital Amount
FROM_INTEREST_DOC Interest Amount
TO_CAPITAL_DOC Depositor BP Number
TO_INTEREST_DOC Interest Amount
JOURNAL_DATE Journal date
JOURNAL_REASON Journal Reason
P a g e | 70
Suspense Account Report
Purpose
This report gives the details on records that are in Suspense account.
Trigger
This is an ad-hoc report and should be accessed through CRM system via SAP GUI in HTML
Input
Parameter Type Description
DFKKKO-CPUDT S From and To Dates
Drop Down P Financial Year
Check box P Show Detail
Output – Field details will be decided as part of migration
Header -
Date Description Debit Credit
Details:
Reference number From / To Amount
Reversal of DRNs after expiry
Purpose
This is an internal job to reverse expired DRNs.
Trigger
This is a batch job in ECC to reverse expired DRNs.
Input
Parameter Type Description
DFKKKO-CPUDT S From and To Dates
Output
Column Mapping
Depositor BUT000-BPEXT
ARN DPSOB-LEGACYOBJK1
DRN DFKKOP-OPBEL
Expired Date DRN creation date + 30 working days
Bank Reconciliation
R-Bank Recon.xlsx
Cash Book
P a g e | 71
R-Cash Book.xlsx
Bank reconciliation unprocessed Items (FEBAN)
R-FEBAN.xlsx
Bank reconciliation processed Items report (FEBAN)
R-FEBANPROCITEM.xl
s.xlsx
Following standard reports will be used at Guardian’s Fund
Account Statement – FPL9
List of Open items – FPO1
13.3 FINANICIAL REPORTING REQUIREMENT Finance department has requirement for the following reports.
No. Report name Business Requirement Standard Report Yes/No
Format Attached
1 Trial Balance and General Ledger
To view the trial balance/General Ledger with opening and closing balances
Yes
R-TB.xlsx
2 Statement of Financial
Performance Report for surplus/deficit for the financial year.
Yes
R-Fin Perf.xlsx
3 Statement of Financial
Position Report net assets and liabilities as at financial year end.
Yes
R-Fin Post.xlsx
4 Equity Statement Report statement of changes in net
assets for the financial year ended. Yes
R-Equity.xlsx
5 Cash Flow Statement Report for net increase/decrease in
cash and cash equivalent. Users will download the file in excel and some values need to put manually.
Yes
R-Cash Flow.xlsx
6 Notes to financial
statements Report for consolidated financial statement. Users will download the file in excel and some values need to put manually.
Yes
R-Notes Fin.xlsx
7 Bank Reconciliation Report for Bank reconciliation, where
in Cash book and bank details with processed and unprocessed items for payment, receipt, bank charges and interest.
No
R-Bank Recon.xlsx
P a g e | 72
No. Report name Business Requirement Standard Report Yes/No
Format Attached
8 Cash Book Report for daily incoming/outgoing receipt and payments classified per product type.
No
R-Cash Book.xlsx
9 Bank reconciliation
unprocessed Items Report for bank reconciliation unprocessed items in T Code FEBAN.
No
R-FEBAN.xlsx
10 Bank Reconciliation
processed items report
Report for processed items of Bank reconciliation.
No
R-FEBANPROCITEM.xl
s.xlsx
Note: Configuration required by the functional consultant for making reports such as statements of Financial Performance, Financial Position, Equity Statement, Cash Flow and notes to financial statements. No technical efforts required. Document Type Document types are valid for all clients. We specify a number range key for each document type. We create the desired internal number range intervals for each number range key based on the company code. Hence, in SAP, the document number control will be at the legal entity level. Further, the number range will be year dependent and needs to be created for each financial year in each company code. At the start of a new fiscal year, the existing number ranges of the current fiscal year will be copied to the next year. Therefore, the same number ranges will be used every year for each document type, but the document numbers will be repeated year to year. A particular financial transaction in SAP can be uniquely identified by the combination of company code, document number and fiscal year. Following are the documents types for Guardian’s Fund Business process.
Description Number Ranges Number from Number To
PIC Investment 11 1100000001 1199999999
PIC Withdrawal 12 1200000001 1299999999
BP receivable invoice 13 1300000001 1399999999
BP Receivables Receipt 14 1400000001 1499999999
BP Receivables Cr Memo 15 1500000001 1599999999
BP Payable Invoice 16 1600000001 1699999999
BP Payable Payment 17 1700000001 1799999999
BP Payable Dr. Memo 18 1800000001 1899999999
Bank Reconciliation 19 1900000001 1999999999
Reversal PIC Investment 20 2000000001 2099999999
Reversal PIC withdrawal 21 2100000001 2199999999
PIC Interest Received 22 2200000001 2299999999
Automatic Clearing 23 2300000001 2399999999
13.4 BUSINESS PROCESS FINANCIAL IMPACT Following are the business process financial entries.
No Business Process Financial Entry
1 Open item creation before deposit
300510 Business Partner (Depositor Organization) Account Dr. 300520 Business Partner (Depositor Trust) Account Dr. 300530 Business Partner (Depositor Individual) Account Dr.
P a g e | 73
No Business Process Financial Entry
400510 Guardian’s Fund Payable Account Cr.
2 Non-receipt from depositor
400510 Guardian’s Fund Payable Account Dr. 300510 Business Partner (Depositor Organization) Account Cr. 300520 Business Partner (Depositor Trust) Account Cr. 300530 Business Partner (Depositor Individual) Account Cr.
3 Receipt from Depositor 300612 Bank Incoming Account Dr. 300510 Business Partner (Depositor Organization) Account Cr. 300520 Business Partner (Depositor Trust) Account Cr. 300530 Business Partner (Depositor Individual) Account Cr.
4 Transfer to beneficiaries Account
400510 Guardian’s Fund Payable Account Dr. 400410 Interest bearing beneficiaries – Pretoria Cr. 400420 Non-Interest-bearing beneficiaries – Pretoria Cr. 400430 Commission beneficiaries – Pretoria Cr.
5 Making payment to Creditors
400430 Commission beneficiaries – Pretoria Dr. 300611 Bank Outgoing Cr. 401465 NRF Liability Cr.
6 Interest Bearings Transfer to Beneficiaries
202220 Interest paid – interest bearing beneficiaries -Pretoria Dr. 400410 Interest bearing beneficiaries – Pretoria Cr.
7 Adjustment of Interest (Wrongly calculated)
202220 Interest paid – interest bearing beneficiaries -Pretoria Dr./Cr. 400410 Interest bearing beneficiaries – Pretoria Cr./Dr.
8 Booking Payment Liability to beneficiaries (Application Received)
400410 Interest bearing beneficiaries – Pretoria Dr. 400420 Non-Interest-bearing beneficiaries – Pretoria Dr. 400430 Commission beneficiaries – Pretoria Dr. 400610 Business Partner (Interest bearings) Account Cr. 400620 Business Partner (Non-Interest bearings) Account Cr. 400630 Business Partner(Commission) Account Cr.
9 Payment to beneficiaries (Application Received)
400610 Business Partner (Interest bearings) Account Dr. 400620 Business Partner (Non-Interest bearings) Account Dr. 400630 Business Partner (Commission) Account Dr. 300611 Bank Outgoing Cr. 401465 NRF Liability Cr.
10 PIC Investment open item creation (CRM Interface)
300310 PIC investment Dr. 300540 Business Partner (PIC Investment) Account Cr.
11 PIC Investment (CRM Interface)
300540 Business Partner (PIC Investment) Account Dr. 300611 Bank Outgoing Account Cr.
12 Interest Received from PIC Investment (Direct FI Posting)
300310 PIC investment Dr. 100110 Interest received (PIC) Cr.
13 PIC withdrawal open item creation (CRM Interface)
300540 Business Partner (PIC Investment) Account Dr. 300310 PIC investment Cr.
14 PIC Withdrawal (CRM to SAP)
300612 Bank Incoming Account Dr. 300540 Business Partner (PIC Investment) Account Cr.
15 Unclaimed Money to National Revenue Fund(NRF)
400420 Non-Interest-bearing beneficiaries – Pretoria Dr. 401460 SARS 30-year Cr.
16 Unclaimed Money to National Revenue Fund (NRF) from Creditors
400430 Commission beneficiaries – Pretoria Dr. 401460 SARS 30-year Cr.
17 Payment to NRF 401460 SARS 30 years Dr. 300611 Bank Outgoing Cr.
18 Bank Reconciliation 300610 Main Bank Account Dr. 300612 Bank Outgoing Account Cr. 300611 Bank Incoming Account Dr. 300601 Main Bank Account Cr.
P a g e | 74
13.5 INTERFACES
Interfaces
WRICEF ID
Description Interface Method
Applications Frequency / Volumes
Owner
I001 DOH system BP For thumb verification CRM
I002 DMS Integration Case Documents Uploading CRM
I003 Active Directory
I004 Digital Signature Deposit, Application
While Printing the Deposit form & Application
CRM
P a g e | 75
13.6 ENHANCEMENTS
Enhancements
WRICEF ID Description Data Object (Sales Order)
E001 Interest Calculation Contract Object
E002 Deposit Receipt Date Document
E003 BP – Beneficiary Structure Transaction
E004 PIC Investment FI
E005 BP – Product BP
E006 BP – BUAG BUAG
E007 Custom Fields in BP BP
E008 Custom Fields in Transaction Case, Cr/Dr. Note, Activity, Task, Social Service Plan
E009 DRN Update Document
E010 WEBUI – Case Document General Data – Custom Fields
E011 WEBUI – SSP, Cr. /Dr. Memo Request
General Data – Custom Fields
E012 BADI Create Contract Object per Case (File)
E013 BADI Deposit File replication along with custom fields
E014 Interest Calculation Contract Object
E015 Receipt Date Document
E016 PIC Investment FI
E017 CO screen enhancement Contract Object in GFS
E018 CA Screen enhancement Contract Account in GFS
E019 Enhancement to update Payment status back to CRM
Payment status
E020 BP Change process – Reversal un-process payment transactions
Transactions
Interest Calculation Contract object data like Interest effective date, stop interest effective date and Product type are stored in Facts. Hence interest calculation mass run must consider these parameters while calculating interest. Event 2010 can be used to adapt this logic. Use BAPI_CTRACPSOBJECT_GETDETAIL to read facts. The Interest calculation enhancement must also validate the Claimable date + 5 years condition to stop interest on the card. Receipt Date Receipt Date is used for interest calculation on beneficiary cards. Custom field on Document header will be added to capture Receipt Date from deposit file to beneficiary cards. This date will be carried forward in journal process as well when capital is moved from one beneficiary card to another beneficiary card. Event 1872 can be used to move Receipt Date to Beneficiary credit documents. This event can be used to determine main and sub transaction for credit documents as part of revenue distribution process.
P a g e | 76
PIC Investment When payment run batch, job is executed in FI, this enhancement will pick the unprocessed records from ZC_PIC_TRIGGER table and updates the table with processed data.
13.7 OUTPUT (E.G. FORMS)
Every report can be printed using standard feature available.
WRICEF ID Description Data Object
F001 Annexure K Fraud Case
F002 Dunning Letter
F003 Memo Fraud Case
F004 J - Forms Please refer section 9.0
14 TECHNICAL/ DEVELOPMENT RELATED ITEMS
14.1 USER AUTHORISATION
SAP Authorizations are used to control user access within the SAP system (i.e. what actions a user can
or cannot perform, what data a user can or cannot access). In general, authorizations are grouped into
roles or profiles that are then assigned to system users.
SAP security is based on field values assigned to authorisation objects within a profile. A profile is assigned to a security a Role, which is assigned to a User within the User Master Record.
Office based access for Guardian’s Fund will be achieved through profit Centre assignment to the users.
Individual users will be assigned authorisations based on the office locations they work.
Authorisations could be given both at Profit Centre level and Transaction level.
Each of the office will be assigned with Profit Centre as well as required transactions in a User profile. For head office display access will be given for all the profit Centres and transactions. In addition to that create general journal and document reversal transaction authorisation will be given to head office.
P a g e | 77
14.2 RECOMMENDATIONS BP Changes: Method 1:
User can create a request on behalf of the end customer and this can store in Service Ticket. Based on the Service ticket approval, Master data team can update in the BP transaction.
Method 2:
The authorised persons can change the information and submit for approval. If the changes are approved, system will automatically replace the latest information.
Note: users can see the change history throughout the life cycle.
14.3 ASSUMPTIONS
1. Important fields and custom field’s information captured based on discussions with DoJ&CD business team. During Realisation this information need further discussion, if required.
2. J-Forms and form templates are attached for information purpose and will develop the forms where it is required
3. Data migration from legacy system to CRM is not considered in the scope of this functional design. Data migration activities will all form part of the implementation scope.
4. If there are any unforeseen complex scenarios that are not discussed during the design sessions, business will have to include them in the implementation scope as new requirements.
5. All Suspense account related processes are relevant only for Migration as the to-be system will not
have any Suspense account.
6. It is assumed that the bank will accept all deposit payments based on ARN, DRN number and for exact amounts given.
7. Beneficiary card will always be assigned to a particular office.
8. Business to decide on frequency of payment runs as part of implementation.
9. Sequencing of batch jobs will be decided as part of implementation.
10. Bank statement format will be MT940.
11. ECC reports and any transactions that require direct user interaction in ECC will be accessed through transaction launcher functionality.
12. Screen enhancements (i.e. additional custom fields) for additional data on Business Partner, CA and
CO are not considered as these objects will not be accessed directly in SAP. Enhanced data will be residing in backend tables.
13. Interest will be posted as a cumulative document by calculating interest on available balance for the period (based on interest rules).
14. Change beneficiary requests, with amounts, that are more than currently available on the cards will
not be accepted.
15. Scanning of Supporting Documents - CRM provides standard functionality to link electronic documents to CRM records. However, a separate technical solution is required to do any scanning of hardcopies (i.e. to create the electronic documents) and to store these documents in document storage.
P a g e | 78
16. Two Outbound Notification Channels have been identified for the solution, namely email and SMS
a) The Microsoft Exchange Mail Server will need to be configured to track outbound emails sent from
SAP CRM.
b) Details of SMS integration are dependent on the chosen service provider.
15 RISKS
Risk Description Impact
Failed Transactions If there are any failed transactions in CRM due to incomplete / incorrect data user need to monitor Middleware and Queues
Failed data replication.
Deposit Reference Number approach
Agreement with banks on proposed DRN approach for accepting the exact deposits mentioned in DRN.
Possibility of unclassified monies
Additional effort in handling over/under payments
16 ABBREVIATIONS
ABBREVIATION DESCRIPTION
AP/AR Accounts Payable / Accounts Receivable
ARN Account Reference Number
BADI Business Add In
BUAG Business Agreement
BPD Business Process Design
BP Business Partner
CA Contract Account
CC Cost Centre
CO Contract Object
DoJ&CD Department of Justice and Constitutional Development
DRN Deposit Reference Number
ECC ERP Central Component
EFT Electronic Fund Transfer
ERP Enterprise Resource Planning
FC Fideicommissum
FI SAP Finance Module
GF Guardian's Fund
GL General Ledger
NRF National revenue Fund
PC Profit Centre
PI SAP NetWeaver Process Integration
PIC Public Investment Corporation
PRN Payment Reference Number
PSCD SAP Public Sector - Collections and Disbursements