SAP CRM and ECC: BUSINESS PROCESS DESIGN AnnexureB-DoJCD_GFMS...SAP PSCD is ECC and FI modules in DoJ&CD Master Data will be maintained in CRM system and replicated into the ECC system

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.

http://help.sap.com/saphelp_46c/helpdata/en/35/26b5d3afab52b9e10000009b38f974/content.htm

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


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


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


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?


YesValidation with

DHA

Does Beneficiary

Exists?


YesValidation with

DHA

Does Guardian Exists?


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


Date N/A


Date N/A


Date N/A

P a g e | 29

Description/ Default Type Mandatory


Beneficiary Date of Marriage Entry

Claimable Date Manual Entry - Date of Marriage Date N/A


Date N/A


Date N/A


Date N/A


Beneficiary – Custom Entry

Claimable Date Manual Entry Date N/A


Date N/A


Date N/A

Stop interest 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.


Open the existing file and Edit the document, system will set the status as “Re-Open” automatically


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.


Open the existing file and set the status as “Stop Interest”


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.


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 Trigger Receiving of the Application in CRM System

Process Input Receive Application for withdrawal

Process Output Application record


Process Volumes Approx. 100,000 payment records per year


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 Trigger Creation of the Proposal in CRM System

Process Input Payment Proposal

Process Output Payment record


Process Volumes Approx. 100,000 payment records per year


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:


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


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


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


Input


DPSOB-LEGACYOBJK1 S Beneficiary reference Numbers

P a g e | 64

DFKKKO-CPUDT S From and To Date

Output



Office Address use BAPI_PROFITCENTER_GETDETAIL to get address


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


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


Input


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





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


Input





Status P Payment status

Output

Column Mapping

Header

DoJ&CD Logo Logo



P a g e | 66

Column Mapping

Header



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


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


Input


DFKKKO-CPUDT

S From and To Dates



Status S Status of payment

Output

Column Mapping






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


Input




P a g e | 68


Output

Column Mapping






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


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


Input


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


Input


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


Input





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



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