ABC Company Project Report

8/12/2019 ABC Company Project Report

1/72

A Project Report on

ABC Finance Company

Submitted in Partial Fulfillment of Requirement

For the VI sem MCA Project

Under

Visvesvaraya Technological University, Belgaum

Karnataka

By

Srinivas G

1RZ10MCA33

Under the guidance of

R. V. COLLEGE OF ENGINEERING

MYSORE ROAD, BANGALORE560 059

June 2013

Mr. Navin kumar

Senior Consultant

Capgemini India Pvt Ltd

A1 Technology Park,

Pune 412114

Dr. B Renuka Prasad

Asst. Professor

R.V.College of Engineering

Mysore Road

Bangalore 560059


2/72

R.V. COLLEGE OF ENGINEERING

DEPARTMENT OF MASTER OF COMPUTER APPLICATIONS

AFFILIATED TO VISVESVARAYA TECHNOLOGICAL UNIVERSITY BELGAUM

APPROVED BY ALL INDIA COUNCIL FOR TECHNICAL EDUCATION NEW DELHI

BANGALORE - 560059

JUNE 2013

CERTIFICATE

This is to certify that the project entitled ABC Finance Company Submitted in

Partial Fulfillment of the VI sem MCA Project is a Result of the Bonafide Work

Carried Out by

Srinivas G

1RZ10MCA33

During the Academic year 2013

Principal

R. V. College of engineeringBangalore - 560059

Dr. B Renuka Prasad

Asst. ProfessorDepartment of MCA


Mysore Road

Bangalore 560059

Dr. Sumithra Devi K.A

Professor and DirectorDepartment of MCA


Mysore Road

Bangalore 560059


3/72


4/72

UNDERTAKING BY THE STUDENT

I, Srinivas G, 1RZ10MCA33, hereby declare that the project ABC Finance

Companyis carried out and completed successfully by me and is my original work

as assigned by the company.

Srinivas G

(1RZ10MCA33)


5/72

ACKNOWLEDGEMENT

I express my sincere gratitude to our beloved Principal, Prof.

B.S.Satyanarayana, RVCE, Bangalore, for all the encouragement and permitting me

to do this project at Capgemini India Pvt Ltd, Pune.

I express my sincere thanks to Dr. Sumithra Devi K. A., Director,

Department of MCA, for her inspiring guidance and encouragement throughout

the course of work.

I express my sincere gratitude to my external guide Mr. Navin kumar, Senior

Consultant at Capgemini India Pvt Ltd, Pune for his guidance, throughout the

project.

I express my sincere thanks to my internal guide Dr. B Renuka Prasad, Asst.

Professor, Department of MCA, for his extra support, inspiring guidance and

encouragement throughout the course of work.

Srinivas G

1RZ10MCA33


6/72

INDEX

College Certificate i

Company Certificate ii

Undertaking of the student iii

Acknowledgement iv

List of Figures v

List of tables vi

Synopsis vii

Page No.

CHAPTER 1: PREAMBLE

1.1 Introduction 1

1.2 Project Description 11.3 Literature Survey 2

1.4 Features of the Project 6

1.5 Platform used in Implementing Project 6

1.6 Timeline of the Project 7

1.7 Dissertation 8

1.8 References 8

CHAPTER 2: SOFTWARE REQUIREMENT SPECIFICATION

2.1 Introduction 132.2 General Description 19

2.3 Functional Requirement 20

2.4 External Requirement 21

2.5 Performance Requirement 22

2.6 Design Constraint 23

CHAPTER 3: DESIGN DOCUMENT SPECIFICATION

3.1 Architectural Design 15

3.2 Detailed Design 26


7/72

CHAPTER 4: TESTING AND RESULTS

4.1 Testing 38

4.2 Results 44

4.3 Conclusion and Future Enhancement 52

ANNEXURE 53

BIBLIOGRAPHY 61


8/72

LIST OF FIGURES

Figure No. Particulars Page No

1.1 Overview of project 1

1.1 Timeline of the Project 7

3.1 E-R Diagram of Application module 17

3.2 E-R Diagram of Payments module 18

3.3 Level-0 DFD 19

3.4 Level-1 DFD 20

3.5 Level-2 DFD 21

3.6 Structure chart 22

4.1 Snap shot of Blank Field 44

4.2 Snap shot of loan details 45

4.3 Snap shot of loan condition 46

4.4 Snap shot of repayment period condition 47

4.5 Snap shot of updated details 48

4.6 Snap shot of blank field 49

4.7 Snap shot of loan details 50

4.8 Snap shot of options 51

A.1 Blank field 53

A.2 Loan details 54

A.3 Loan Condition 55


9/72

A.4 Repayment Period 56

A.5 Updated details 57

A.6 Blank field 58

A.7 Loan details 59

A.8 Options required 60


10/72

LIST OF TABLES

Table no. Particulars Page No.

3.1 Applications master Table 22

3.2 Payments master Table 24

3.3 Error codes 35

4.1 Test Cases 39


11/72

SYNOPSIS

ABC finance company is a company which provides loans to its customers. Based on the

functionality the system can be divided into two subsystems.

1. Applications. 2. Payments.

The Applications are used when ever a customer comes to avail a loan, he/she is asked to

give the required details which his/her Personal details and Rating details [DOB,

Salary/month, Assets Value (Rupee value of any vehicles, property he/she owns),].Using

the rating details we calculate an amount ( the maximum amount of loan, which the

company can provide the customer). If he/she is fine with that amount, we carry on with

further processing.

The customer is asked to give the loan details (Loan amount the customer is planning to

take, and also the repayment period). Based on the loan details we calculate the EMI and

convey it to the customer. The customer can make inquiry for the EMI any number of

times (i.e., for any permutations and combinations of Loan amount and repayment

period). Once the customer decides upon the amount he is planning to take and the

repayment period, he's provided with an automatically generated customer number which

is a must for any further transaction with the company.

When the customer comes to make his loan repayments, payments department attends

him/her. The customer is allowed to pay his EMI through Cash or a Cheque. We have

some pre-defined rules according to which surcharges are levied on customers who do

not make the payments regularly. If at any point of time, the due amount to date (that

should have been paid by now, but not paid), is greater than 4 times his EMI then, his

tenure is cancelled and he will be subject to juridiction. A warning letter will be sent to

the customer when the total amount due becomes greater than 3 times the EMI.


12/72

ABC Finance Company June 2013

Department of MCA RVCE Page 1of 61

Chapter 1

PREAMBLE

1.1

Introduction

ABC finance company is a finance company which provides loans to its

customers. To improve its efficiency, they chalked out a plan to automate its entire

process. Based on the following specifications we were required to develop the

system for them.

The objective was to create a system, that calculates the maximum amount of

loan one can take depending on his income and wealth, and the EMI amount for

certain repayment period. And if the customer chooses to take the loan, then create a

new loan account. On certain time of every month generate report on the new loan

accounts. An automatic payment interface for user to pay EMI, and again, every

month calculate and adjust interests, generate report, and based on the status, generate

letter to certain customers. Overall the complete system was automated.

1.2 Project Description

Based on the functionality the system can be divided into 2 subsystems.

APPLICATIONS

PAYMENT

Figure 1.1 Overview of project


13/72



Applications

Whenever a customer comes to avail a loan, he/she is asked to give the

required details which include his/her Personal details and Rating details [DOB,

Salary/month, Assets Value (Rupee value of any vehicles, property he/she owns),].

Using the rating details we calculate an amount (the maximum amount of loan, which

the company can provide to the customer). If he/she is fine with that amount, we carry

on with further processing.

The customer is asked to give the loan details (Loan amount the customer is

planning to take, and also the repayment period). Based on the loan details we

calculate the EMI and convey it to the customer. The customer can make inquiry for

the EMI any number of times (i.e., for any permutations and combinations of Loan

amount and repayment period). Once the customer decides upon the amount he is

planning to take and the repayment period, hes provided with an automatically

generated customer number which is a must for any further transaction with the

company.

Payments

When the customer comes to make his loan repayments, payments department

attends him/her. The customer is allowed to pay his EMI through Cash or a cheque.

We have some pre-defined rules according to which surcharges are levied on

customers who do not make the payments regularly. If at any point of time, the due

amount to date (that should have been paid by now, but not paid), is greater than 4

times his EMI then, his tenure is cancelled and he will be subject to jurisdiction. A

warning letter will be sent to the customer when the total amount due becomes greater

than 3 times the EMI.

1.3 Literature Survey

Literature Survey on Mainframes

Mainframe is a very large and expensive computer capable of supporting

several thousands of users simultaneously. In the hierarchy that starts with a simple

microprocessor (in watches, for example) at the bottom and moves to supercomputers


14/72



at the top, mainframes are just below supercomputers. In some ways, mainframes are

more powerful than supercomputers because they support more simultaneous

programs. But supercomputers can execute a single program faster than a mainframe.

"A mainframe is a continually evolving general purpose computing platform

incorporating in it architectural definition the essential functionality required by its

target applications." - Anonymous.

Bulk data processing such as census, industry and consumer statistics,

enterprise resource planning, and transaction processing, big companies like Banks,

Insurance Companies, Travel and Retail Sector, Telecom Companies employ

Mainframes for processing their business data. Today, thousands of people around the

globe book flights do Electronic Money Transfers; swipe their credit-cards for

purchases. These transactions are processed in a snap by a Mainframe computer.

Literature Survey on History of mainframes

From 1952 into the late 1960s, IBM manufactured and marketed several large

computer models, known as the IBM 700/7000 series. The first-generation 700s were

based on vacuum tubes, while the later, second-generation 7000s used transistors.

These machines established IBM's dominance in electronic data processing. IBM had

two model categories: one (701, 704, 709, 7090, 7040) for engineering and scientific

use, and one (702, 705, 7080, 7070, 7010) for commercial or data processing use. The

two categories ($2M USD in the mid-1950s), scientific and commercial, generally

used common peripherals but had completely different instruction sets, and there were

incompatibilities even within each category.

All that changed with the announcement of the System/360 (S/360) in April,

1964. The System/360 was a single series of compatible models for both commercial

and scientific use. The number "360" suggested a "360 degree," or "all-around"

computer system. System/360 incorporated features which had previously been

present on only either the commercial line (such as decimal arithmetic and byte

addressing) or the technical line (such as floating point arithmetic). However, models

were upward compatible and most were also downward compatible. The System/360

later evolved into the System/370, the System/390, and the 64-bit zSeries, System z,


15/72


16/72


17/72



oriented), but background transactions are possible. Even a front end written by Java

or dot net can be connected to s Mainframe through CICS.

CICS provides services that extend or replace the functions of the operating system

and are more efficient than the generalized services in the operating system

Literature Survey on DB2

Short for Database 2, a family of relational database products offered by IBM.

DB2 provides an open database environment that runs on a wide variety of computing

platforms. A DB2 database can grow from a small single-user application to a large

multi-user system. Using SQL, users can obtain data simultaneously from DB2 and

other databases. DB2 includes a range of application development and management

tools.

DB2 is unparalleled for using very large database, and thats why DB2 is widely

used in mainframe, mainframe databases often contain tables with millions of records.

With the flexibility of SQL, DB2 is used almost everywhere mainframe is used.

1.4

Features of the Project:

The main features of the project are

End to End solution for ABC finance company. It handles the loan

processing from beginning to end of the customer.

It provides user friendly interface for customers of the finance company.

Helps to build an interactive Loan processing system.

Provides many criteria for evaluating customers loan.

Helps to calculate different operations in loan availing process.

1.5 Platform used in Implementing the Project:

IBM Mainframe Z/OS system with basic configuration.

Basic desktop to access remote Mainframe system

Operation System : MVS(Multiple Virtual Storage)

Business Logic : COBOL programs


18/72



Database : IBM DB2

Server : IBM Mainframe Z/OS system

System Environment : Mainframe.

1.6 Timeline for the Project:

Analysis of core

modules and

Database Design

Designing or

Architecture

Development of

Core Modules(

Coding)

Gradual

implementation

Practices

Testing,

Maintenance and

Documentation

February

2013

March 2013 April 2013 May 2013 June 2013

Fig 1.2: Time line for the project.

Timeline of the project helps to analyze the time taken by the different modules of the

project. Requirement, Design, Coding and Testing are the different phases of this

project.

In the first month we started with requirement and design phase. First fifteen days we

worked with some mainframe examples. Next fifteen days we started planning our

project. In the second month we started coding and thus we started testing. In this

project we got the requirements by studying the previous research works. More time

spent on learning the mainframe platform.

In the third month, we were done with the requirement phase concentrated on coding

and design phase. In the 4thmonth more time spent on coding. In the 5 thmore time

spent on coding and testing.


19/72



1.7 Dissertation:

Chapter 2 starts with Software Requirement Specification. Here we discuss on

purpose of the project and scope of the project. Then we specify different definitions,

acronyms and abbreviations used in the project. Later we discussed on overview of

the project. In this scope we discussed on architecture of the project and the key

components of the system and the project.

Chapter 3 is about Design Specification. This specifies actual working of the

project. The project follows Procedure Oriented Approach. Here we specify the E-R

diagram of the project. We explain the design part with the help of Data flow

diagrams and all DFD diagrams.

In later part we specify main modules of the project. In Detailed Design we

specify logical part of the project. This will includes algorithm and mathematical

computation results.

Chapter 4 is about Testing and Results. Testing deals with different test cases

and testing methods used in the project. In results we specify screenshots of different

results of the project with explanations.

1.8 References:

www.mainframegurukul.com

IBM Mainframe Handbook, Alexis Leon.

DB2 Developers Guide, Third Edition, Craig S. Mullins

CICS Handbook, Kageyama

COBOL PROGRAMMING, M K Roy
http://h/ABC%20aritra%20doc/www.mainframegurukul.comhttp://h/ABC%20aritra%20doc/www.mainframegurukul.com


20/72



Chapter 2

Software Requirements Specification

2.1 Introduction

The scope of this project is limited to a banking domain with mainframe

access. Though several thousand customers as well as operators can work with this

application simultaneously, without mainframe access, its not possible. So, the

application can only be run within the ABC Finance company only, even though the

branches scattered within the globe.

2.1.1 Purpose

The main purpose of the project is to develop a processing system for the ABC

Finance Company on the IBM mainframes. The project aims to provide all solutions

to the requirement of the customer availing a loan in the finance company.

2.1.2 Scope

The project is developed mainly for the financial sector where the transactions

take place in a large numbers. In order to handle the large amount of transactions we

need an efficient system to be used for the development. The IBM mainframe systems

can handle millions of transactions per second and hence we develop our processingsystem for the ABC Finance Company on the main frame system.

2.1.3 Definitions, Acronyms and Abbreviations

JCL: Job Control Language.

3270: Terminal used to connect to Mainframe

VSAM: Virtual Storage access Method

MVS: Multiple Virtual Storage.


21/72



CICS: Customer Information Control System.

2.1.4 References

o www.mainframegurukul.com

o IBM Mainframe Handbook, Alexis Leon.

o DB2 Developers Guide, Third Edition, Craig S. Mullins

o CICS Handbook, Kageyama

o COBOL PROGRAMMING, M K Roy

2.1.5 Overview

This project is concerned with the development of a software for the finance

company which comprises of overall transactions between the customer and the

company. The finance company project can be broadly divided into two categories

namely. They are:

1. Application processing.

2. Payments processing.

The application processing deals with the customer applying for the loan in the

finance company. The company gathers the required information from the customer

for the processing of the loan. The gathered information is processed for the

calculations for the maximum loan amount that the customer is eligible. The

payments processing deals with the payment of the EMI by the customer to the

finance company. The customer has to pay the EMI at specified date to avoid

different circumstances which leads to increase in the loan amount to be payed to the

finance company. The Customer Information Control System(CICS) will be used as

the front end to the project. The IBM DB2 will be used as the backend for the data

storage. The Finance company project will be developed on the IBM Mainframe

system


22/72



2.2 General Description

2.2.1 Product Perspective

The product which we are going to develop serves all the needs for the loan

processing in the finance company. The CICS screen will be developed for the

customer to enter the required information for the loan processing. The CICS acts as

an interface between the User and the Mainframe system. The mainframe system

refers to IBM Z/OS system which is the platform for the development of the finance

company project. The COBOL is the programming language used on mainframe

system. The JCL (Job Control Language) acts as an intermediate between COBOL

and the Mainframe system.

2.2.2 Product Functions

o This product functions involve :

o

Rating Routine

o Date Routine

o Applications Processing functions

o Payments Processing functions

o Reports generation functions

o EMI functions

o Batch processing

o

Online Processing

2.2.3 User Characteristics

The application users must know the functioning of the software for effective

usage.

The user in this project is the finance company customers.

The customer's purpose is to avail a loan which he needs based on his inputs given

to the finance company


23/72



2.2.4 General Constraints

The developer needs complete prior knowledge about the finance sector to

develop a good software. The customer's requirements tend to change dynamically

and the developer should be able to handle such requirements. Reusability of the

codes which is one of the major pros is possible only if there are no interface

changes/modifications within the solution. Developing the plans to execute workflows

can be sometimes consuming.

2.2.5 Assumptions and Dependencies

The system does not expect its users to have technical expertise of any sort, its not

meant to be used by layman either. The users are assumed to be aware of the usage

of the software which is one of the major assumptions.

The system design is based on the current version of the requirements and any

changes to the latter impacts the solution.

2.3 Functional Requirements

2.3.1 Introduction

Functional Requirements specify the key functions to be performed by the proposed

system. These describe the functionality or services that the system is expected to

provide.

2.3.2 Input

The customer information serves as the input for the finance company software.

The monthly salary, asset values and other major information serve as input for the

software.


24/72



2.3.3 Processing

The CICS accepts the input and submits to the COBOL program for execution.

The Cobol program processes the input using rating routine and other routines.

The payments updation is done through the batch processing.

2.3.4 Output

The maximum loan amount is given as the output on the cics screen.

The EMI is calculated and given as the output on the cics screen.

The payments transaction are generated as a report which forms the output for the

batch processing.

2.4 External Interface Requirement

2.4.1 User Interfaces

This project uses IBM mainframe Z/OS system for the development of the finance

company software. The different technologies used by the mainframe system are:

JCL for submitting jobs on mainframe system.

MVS is the operating system on mainframes.

VSAM is used as a source of data storage.

Defining/Declaring variables.

Modification/Execution of codes.

2.4.2 Hardware Requirement

IBM Mainframe Z/OS system with basic configuration.

Basic desktop to access remote Mainframe system.


25/72



2.4.3 Software Requirement

Operation System : MVS(Multiple Virtual Storage)

Business Logic : COBOL programs

Database : IBM DB2

Server : IBM Mainframe Z/OS system

Environment : Mainframe Environment.

2.5 Performance Requirements

The software should be compatible enough to handle the unexpected conditions. The

software developed should give valid result for all valid inputs.

As it is the financial sector the amount of dataflow in and out of the system and data

security is the major issue.

2.6 Design Constraint

2.6.1 Standard Compliance

The results should be accurate and in the proper format.

Design of the system takes measures for invalid input to ensure reliability.

2.6.2 Hardware Limitations

Mainframe system can be afforded only by big organizations and it is very costly.

To install and run a mainframe system we need 1 month.


26/72



Chapter 3

Design Document Specification

3.1 Architectural Design

An Architecture design defines the components or building blocks that form

the entire system. It is a formal design of a system, organized in a way that supports

reasoning about the structural properties of the system. The design of the ABC

Finance company gives the functionalities of the entire system in a descriptive

manner.

Problem Specification

ABC finance company is a finance company which provides loans to its

customers. To improve its efficiency, they chalked out a plan to automate its entire

process. Whenever a customer comes to avail a loan, he/she is asked to give the

required details which include his/her Personal details and Rating details [DOB,

Salary/month, Assets Value (Rupee value of any vehicle, property he/she owns).

Using the rating details we calculate an amount (the maximum amount of loan, which

the company can provide to the customer). If he/she is fine with that amount, we carry

on with further processing.

When the customer comes to make his loan repayments, Payment department

attends him/her. The customer is allowed to pay his EMI through Cash or Cheque. We

have some pre-defined rules according to which surcharges are levied on customers

who do not make the payments regularly. If at any point of time, the due amount to

date (that should have been paid by now, but not paid), is greater than 4 times his EMI

then, his loan service is cancelled and he will be subject to jurisdiction. A warning

letter will be sent to the customer when the total amount due becomes greater than 3

times the EMI. The development of this new system contains the following activities,

which try to develop the web-application entire process keeping in the view of

database integration approach. The purpose of developing finance system is to

provide an easy access to the customers to avail loans with more security and


27/72



flexibility. This system provides the customer to save lot of his time. This system also

gives loans to the customers after verifying each and every document so that fake

customers cannot avail loans.

E-R diagram

An Entity-Relationship Model in software engineering is an abstract and

conceptual representation of data. Entity-relationship modeling is a relational schema

database modeling method, used to produce a type of conceptual schema or semantic

data model of a system, often a relational database, and its requirements in a top-down

fashion. Diagrams created using this process are called Entity-Relationship diagrams.

In this application the entities are Customer, Loan, payments, and applications.

The attributes for each entity are shown in the figure below. The relationship between

customer and loan is applies loan. The payments and customer entities interact

through the relationship makes payments. The relationship generate exists

between customer number and loan entities. The cardinality ratio for each relationship

is specified below.

Entity: An entity may be defined as a thing which is recognized as being capable of an

independent existence and which can be uniquely identified.

Attribute: Attributes are the characteristics of the entities. The customer entity is

characterized by cust_num, first_name, last_name, DOB, pincode, salary and asset

value. These characteristics become the attributes of customer.

Relationship: A relationship captures how two or more entities are related to one

another. Relationships can be thought of as verbs, linking two or more nouns. The

cardinality ratio for a binary relationship specifies the number of relationship

instances that an entity can participate in. The possible cardinality ratios for binary

relationship types are 1:1, 1:N, N:1 and M:N.


28/72



Primary key: An entity is uniquely identified by a key called primary key. The

customer entity is uniquely identified by its cust_num attribute. The primary key

attribute is denoted by underlining the attribute.

Foreign key: A foreign key is a table column whose values exclusively represent a

relationship between tables. A foreign key is a column whose values are derived from

the primary key of some other table.

E-R DIAGRAM

Figure 3.1 E-R Diagram of Application module

The Entity Relationship Diagram in the above figure explains the attributes of the

entities Customer Number and LOAN. The attributes of the Customer Number entity

are cust_no and cust_no_timestamp. The attributes of the LOAN entity are cust_num,

loan_amt, loan_dt, emi_amt, repay_period and loan_stat.


29/72



Figure 3.2 E-R Diagram of Payments module

The Entity Relationship Diagram in the above figure explains the attributes of the

entities Customer and Payment. The attributes of the Customer entity are cust_num,

first_name, last_name, dob, pin, src_code, addr_line. The attributes of the Payment

entity are cust_no, pay_st_dt, pay_end_dt, pay_dt, loan_amt, paymode, curr_pay_amt,

curr_due_amt, emi_amt and pymt_stat.


30/72



Data Flow Diagram

A data flow diagram (DFD) is a graphical representation of the "flow" of data

through an information system, modeling its process aspects. A DFD shows what

kinds of data will be input to and output from the system, where the data will come

from and go to, and where the data will be stored. It does not show information about

the timing of processes, or information about whether processes will operate in

sequence or in parallel.

Zero Level DFD

Figure 3.3 Level-0 DFD

This Context level data flow diagram represents the overall description of the system

specifying the external entities that interact with the system. Here the entire system is

shown as a single process, and gives no clue about the internal organization, which is

explained in next level.


31/72



Level 1 DFD

Figure 3.4 Level-1 DFD

User Input

User Input

User Input

Invalid Input

Invalid

Invalid

Check

Result

Calculate Max Loan

Result

CalculateResult

Calculate

EMI

Latest

Update Cust

InsertNew

Invalid

Valid

Out ut

1.0Personal

and Rating

Details

1.3Loan

Details

1.2Rating

Routine

1.1Date

Routine

User

CUST_NUM_GENR

1.4Confirm

Loan

Details

APP_MSTR


32/72


33/72



Structure charts

A structure chart is a top-down modular design tool, constructed of squares

representing the different modules in the system, and lines that connect them. The

lines represent the connection and or ownership between activities and sub activities

as they are used in organization charts.

Figure 3.6 Structure chart

Data definitions/Dictionary

APPLICATIONS MASTER TABLE LAYOUT

LN FIELD NAME PIC VALUE REMARKS

01 APPLN-RECORD. (Application layout)

05 CUSTOMER-

NUMBER

X(10) Primary Key

10 NAME.

15 FIRST-NAME

X(20)


34/72



15 LAST-NAME X(20)

10 ADDRESS.15 ADDR-LINE-1

X(30)

15 ADDR-LINE-2

X(30)

10 PIN-CODE 9(06)

10 SOURCE-CD X(02)

10 DOB 9(08)

10 FILLER

REDEFINES DOB

15 DOB-CCYY 9(04)

15 DOB-MM 9(02)

15 DOB-DD 9(02)

10 ACT-LOAN-AMT

9(07)

10 ACT-REPAY-

PERIOD

9(03)

10 EMI-AMOUNT

9(07) COMP-3

10 LOAN-DATE 9(08)

10 FILLER

REDEFINES

LOAN-DATE


35/72



15 LOAN-CCYY 9(04)

15 LOAN-MM 9(02)

15 LOAN-DD 9(02)

Table 3.1 Application master table

Description: The Application master table stores details such as cust_num, name,

address, pincode, salary, DOB and asset value. The primary key is cust_num.

PAYMENTS MASTER TABLE LAYOUT

LN FIELD NAME PIC VALUE REMARKS

01 PYMNT-RECORD Payments Layout

10 CUSTOMER-

NUMBER

X(10) Primary Key

05 TERM-START-DT 9(08) COMP-3

05 TERM-END-DT 9(08)

05 FILLER

REDEFINES

TERM-END-DT

10 TERM-END-CCYY 9(04)

10 TERM-END-MM 9(02)

10 TERM-END-DD 9(02)

05 LOAN-AMOUNT 9(07)

05 TOTAL-AMOUNT 9(07)

05 AMOUNT-REPAID 9(07)

05 EMI-AMOUNT

9(07)

05 CURRENT-DUE-

AMT

S9(07)

05 CURR-PAY- 9(07)


36/72



AMOUNT

05 PAY-DATE 9(08)

05 FILLER

REDEFINES PAY-DATE

10 PAY-CCYY 9(04)

10 PAY-MM 9(02)

10 PAY-DD 9(02)

05 PAY-MODE X(02)

05 CHEQUE-

DETAILS.

10 CHEQUE-NBR X(07)

10 CHEQUE-DATE 9(08)

10 BANK-NAME X(20)

Table 3.2 Payment master Table

Description: The Payments master table stores details such as cust_num, term

_start_dt, term_end_dt, due_amount, total_amount.payment_mode, bank

_name and cheque_details. The primary key is cust_num

Module specification

o Applications Processing

Max loan amount calculation.

EMI calculation.

o Payments Processing

Future Date calculation

Module 1: Applications processing

o Module Name : Max loan amount calculation.

o Input: DOB, salary and asset value.

o Output : Max loan amount.

o

Purpose : To calculate max loan amount of the customer.


37/72



o Module Name : EMI calculation

o Input : Loan amount and Repayment Period.

o Output : EMI

o Purpose : To calculate the EMI for the customer.

Module 2 : Payments Processing

o Module Name : Future date calculation.

o Input : DOB and Repayment Period.

o Output : Future Date

o Purpose : To get the future date for loan payment.

Assumptions

The details given by the customer is valid.

The loan amount doesnt exceed max loan amount

The due date is valid as per customers information.

3.2 Detailed Design

Application Online

Whenever a customer comes to take a loan we enter into this program by typing in the

transaction ID for APPLICATIONS.

In this program there are 3 functions.

Function 1:To calculate the maximum amount of loan that the company can

give to the customer (This is based on his age, salary, etc).

Function 2: To calculate the EMI based on the loan amount and the

repayment period.

Function 3:To generate a customer number for customers those availing the

loan.


38/72



The program functionality should reach Function 2 if and only if Function 1 is

complete. And similarly, the functionality should reach Function 3 if and only if

Function 2 is complete.

Function 1:

When the screen is thrown for the first time, the user is asked to enter the personal

details and rating details of the customer. Once the customer enters the details and

presses enter, then the following validations should take place.

(Do the validations in the order mentioned. If at any point any validation fails, the

logic developed should be such that the program does not do any further validations.

It should throw the map with appropriate error message and cursor position.)

PERSONAL DETAILS:

NAME

FIRST NAME VALIDATION:

Valid values are alphabet

LAST NAME VALIDATION:

Valid values are alphabet

ADDRESS

LINE1:

Valid values are alphanumeric characters

LINE2:

Valid values are spaces, low values and alphanumeric characters.

PIN NUMBER:

This should be numeric and greater than 100000.

SOURCE CODE:

TV Television

RD Radio

IN Internet


39/72



FD Friend

NP Newspaper

ZZ Others

Rating Details(Function 2 & 3)

DOB:

Should be a valid past date

Age should be >=20 yrs and 6, add 1 to

difference in years else age will be = difference in years.

SALARY/MON:

This cannot be blank.

Should be numeric and greater than equal to 5000

ASSETS VALUE:

Valid values are spaces, low-values, zeros or any positive numeric value.

CONFIRM RATING DTS:

This should be Y. This is the last check, which confirms that all the details

provided above are correct.

Once all these validations are passed, this program LINKs to the rating routine. Input

to this routine will be DOB, Salary/Mon, Assets value and function that hold value

R. Output will be an amount, which is the maximum loan amount that the company

can give to the customer and the return code. If return code is zero then the amount

value is moved to the map field MAX LOAN AMOUNT. If not the error message is

moved to the message field of the map.

Until this point all other fields except those mentioned above will be protected. But

once this amount is calculated (& return code is zero), then the above-mentioned

fields are made protected and the rest of the fields (LOAN AMOUNT, REPAYMENT


40/72



PERIOD & CONFIRM LOAN DETAILS) are made unprotected and the map is

thrown, prompting the user to enter loan details.

Function 2:

LOAN DETAILS

LOAN AMOUNT:

Valid values are numeric values greater than equal to 10000.

This amount cannot be greater than the Max Loan Amount calculated.

REPAYMENT PERIOD:

Valid values are numeric values between and including 6 240 months. This

is the period in which the customer is planning to repay the loan amount.

If the values in both the above fields are valid, then the program LINKs to

rating routine. The input to this routine will be Loan Amount, Repayment

period and function that hold value E. The outputs of this program are an

amounts and a return code. The amount is the EMI for the specified loan

amount and repayment period. If the return code is zero, then the amount

values are moved into the map fields EMI AMOUNT. If not error message is

moved into the message field of map.

Function 3:

Unprotect The CONFIRM LOAN DETAILS field and throw the map again to the

screen. Receive the map with user response and check the CONFIRM LOAN

DETAILS field.

CONFIRM LOAN DETAILS:

Valid values are Y, N or blank

If this field is Y:

Generate a customer number for the customer automatically and move it to map

variable. And also write a record into the APPLICATION MASTER FILE for that

customer number with all the relevant details. Also write a record for this customer

number into Payments Master file with all relevant details.


41/72



Protect all the fields (Loan Amount, repayment Period and Confirm Loan Details) and

throw the map.

If this field is N or blank:

Only Unprotect the LOAN DETAILS fields and throw the map. User can re-enter

either the LOAN AMOUNT or REPAYMENT PERIOD or both and recalculate the

EMI as many times as he want.

At any point if the user presses PF3/clear the control should go back to CICS. If any

key other than ENTER, CLEAR, PF3 is pressed it should be treated as an invalid key

Automatic generation of Customer Number:

The first record of the APPLICATION MASTER FILE is the control record. The

control record holds the value of the last generated customer number. Read this file

and increment the value present in the file by 1. Assign this value to the customer as

the customer number. Also rewrite the control record with the incremented value (last

generated customer number).


42/72



1 ABC FINANCE COMPANY DATE : MM / DD /YY

2 APPLICATIONS DEPARTMENT TIME : HH : MMAM

34 CUSTOMER NUMBER : 99999999995 *************************************************************

************************************************************6 ************************************* P E R S O N A L D E T A I

L S ***********************************************7 FIRST NAME: XXXXXXXXXXXXXXXXXXXX LAST NAME:

XXXXXXXXXXXXXXXXXXXX8 ADDRESS L1: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX9 ADDRESS L2: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

10 PIN: 999999 SOURCE CODE: XX11 *************************************************************

************************************************************12 *************************************** R A T I N G D E T A I

L S *************************************************13 DOB : MM - DD - CCYY14 SALARY/MON: RS. 9999999 ASSETS VALUE: RS.

9999999999991516 CONFIRM RATING DTS: X MAX LOAN AMOUNT: RS.

999999999917 *************************************************************

************************************************************18 *************************************** L O A N D E T A I L

S **************************************************19 LOAN AMOUNT: RS. 9999999 REPAYMENT PERIOD: 999

MONTHS20 EMI AMOUNT: RS. 9999999

21 CONFIRM LOAN DETAILS: X22 *************************************************************************************************************************

2324 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXXXXXXXX


43/72



RATING ROUTINE

FUNCTIONS:

R- To calculate the maximum amount of loan that the company can provide.

E - To calculate the EMI.

Input to the program:

Salary/month (R/E).

AGE(R)

Assets Value (R).

Loan Amount (E).

Repayment Period (E).

Function (R/E).

Output from the program: (R/E)

Calculated Amount

Return Code

When the control comes to the program, check for the function. If it isanything other than R or E then return to the calling program with anappropriate return code.

If the function = R:

Move the values present in Salary/month, DOB, Assets Value and LoanAmount due to temporary variables and do the following:

Calculate the maximum loan amount using the following formula:

Max Loan Amt = [(5 * Salary/month)*(55-Age)] + [0.3 * Assets Value].Pass the control back to the calling program with RETURN CODE 000.

If the function = E:

Move the values present in Salary/month, Loan Amount and Repaymentperiod to temporary values and do the following:

Calculate the EMI using the following formula: (Round off the EMI amount)

X = Loan Amount + {Loan Amount * n/12 * r}

EMI = X/n.

Where,Present Value = Loan AmountrRate of interest per annum/100.nRepayment period in months

Rate of interest:


44/72



For loan Amount in the range Rate of interest per year

100002Lakhs 13.5%

2Lakhs5Lakhs 12%

5Lakhs10Lakhs 11%

10Lakhs20Lakhs 10%

20Lakhs and above 09.5%

If the EMI calculated is greater than 2/3rds the salary/month pass the control back tothe calling program with appropriate RETURN CODE.

If EMI calculated is less than equal to 2/3rds the Salary/month, pass the control backto the calling program with RETURN CODE 0 and error message spaces.

COPYBOOK LAYOUT

RATING ROUTINE COPYBOOK:

(PREFIX: RTRTN-)

INPUT-VARIBLESMONTHLY-SALARY 9(07)DOB 9(08)FILLER REDEFINES DOBDOB-CCYY 9(04)DOB-MM 9(02)DOB-DD 9(02)ASSETS-VALUE 9(09)

LOAN-DUE-AMT 9(09)LOAN-AMOUNT 9(07)REPAY-PERIOD 9(03)FUNCTION X(01)

88 VALID-FUNCTION VALUE R, E

OUTPUT-VARIABLESCALC-AMOUNT 9(07)RETURN-CODE X(03)

DATE ROUTINE

(Valid Date range: 19012300)FUNCTIONS:

VPValidate a date (Date should be valid and less than equal to current date).

FDCalculate a future date (For a given date and number of months).

DFDifference between 2 dates (In months and Years).

Input to the program:

In-Date1

In-Date2 (this will be passed only when we need to get the difference between

the dates) Months


45/72


46/72


47/72



value R. Output will be an amount, which is the maximum loan amount that the

company can give to the customer and the return code.

Design Decision

In the development of the above application, the procedure oriented approach has

been used. Procedure oriented approach emphasizes on organizing the

functionality into smaller procedures that change our data. In this approach

procedures or functions do not have an intrinsic relationship with the data they

operate on instead can directly access any shared data.

Logic Design

The PDL below is described in terms of a pseudo code. This pseudo code

describes the design plan that has been taken for the implementation of the actual

application. This code gives a detailed description of the proposed plan of coding

the final product.

Max loan amount calculation

Begin :

Enter the inputs on the cics screen

Validate input

If invalid input

Error message

ElseCalculate max loan amount

End-if

End :

EMI calculation

Begin :


48/72



Enter the inputs on the cics screen

Validate input

If invalid input

Error message

Else

Call rating routine for EMI calculation

If valid values

Returns the EMI to main program

Else

Error message

End-if

End-if

End


49/72



Chapter 4

TESTING AND RESULTS

4.1 Testing:

Automation of Loan processing system in ABC Finance company deals with

functioning of finance company in loan processing to the customers.

The application has been created on Mainframe in z/OS. It will run smoothly under

z/OS and MVS 3.8. To run in Operating system below MVS 3.8 needs some tweaking

of data, because those operating systems support COBOL 74 standard.

System Requirement

Operating System

z/OS

CICS Region

Map, PPT, PCT, PLAN entry should be made prior running the

program

DB2

Tables should be created with respective qualifier and the first entry of

CUST_NUM_GENR should be inserted prior running the program

Functional Testing

The objective of this test is to ensure that each element of the application meets the

functional requirements of the project as outlined in the Project Specification.

This stage will also include Validation Testing - which is intensive testing of the new

Front end fields and screens. CICS Standards; valid, invalid and limit data input;

screen & field look and appearance, and overall consistency with the rest of the

application.

The third stage includes Specific Functional testing - these are low-level tests which

aim to test the individual processes and data flows.

All the stages of the functional testing are done and the system passed it successfully.


50/72



Integration Testing

This test proves that all areas of the system interface with each other correctly and

that there are no gaps in the data flow. Final Integration Test proves that system works

as integrated unit when all the fixes are complete.

The system has passed the integration testing successfully.

User Acceptance Testing

This test, which is planned and executed by the Business Representative(s), ensures

that the system operates in the manner expected, and any supporting material such as

procedures, forms etc. are accurate and suitable for the purpose intended. It is high

level testing, ensuring that there are no gaps in functionality.

Black Box Testing

Black box testing assumes the code to be a black box that responds to input stimuli.

The testing focuses on the output to various types of stimuli in the targeted

deployment environments. It focuses on Validation Tests, Boundary Conditions,

Forced Error Tests, Reproducibility Tests, Performance Tests, Globalization, and

Security-Related testing. The descriptions of test cases including test data are enlisted

below.

Test

Case

Id

Test Case Description Excepted Result Actual ResultPass/F

ail

1 Functional

Press enter

without

entering any

details on the

screen.

It should display

PLEASE

ENTER

PERSONAL

AND RATING

DETAILS AND

PRESS

ENTER.

It displays

PLEASE

ENTER

PERSONAL

AND RATING

DETAILS

AND PRESS

ENTER.

Fail


51/72



2 Functional

If first name

is equal to

low values,

spaces,

numeric or

alpha-numeric

It should display

FIRST NAME

CAN NOT BE

BLANK OR

NUMERIC

It displays

FIRST

NAME CAN

NOT BE

BLANK OR

NUMERIC

Pass

3 Functional

If last name is

equal to

spaces,

numeric,

alpha-

numeric, low

values

It should display

LAST NAME

CAN NOT BE

BLANK OR

NUMERIC

It displays

LAST NAME

CAN NOT BE

BLANK OR

NUMERIC

Pass

4 Functional

If address

line1 is equal

to low values

or spaces

It should display

INVALID

ADDRESS

PLEASE

CHECK

It displays

INVALID

ADDRESS

PLEASE

CHECK

Pass

5 Functional

If pin code is

equal to low

values ,spaces

or less than

100000

It should display

INVALID PIN-

PLEASE

CHECK

It INVALID

PIN-PLEASE

CHECK

Fail

6 Functional

If source code

is not equal to

TV,RD,IN,F

D,NP,ZZ

It should display

INVALIDSOURCE

CODE-PLEASE

CHECK

It displays

INVALID

SOURCE

CODE-

PLEASE

CHECK

Pass

7 Functional

If DOB

Separator is

not -

It should display

SEPARATOR

SHOULD BE -

It displays

SEPARATO

R SHOULD

BE -

Pass


52/72



8 Functional

If date of birth

is given in

invalid format

It should display

INVALID

DOB-PLEASE

CHECK

It displays

INVALID

DOB-PLEASE

CHECK

Pass

9 Functional

If customers

age is not

between 18 to

50

It should display

AGE CAN

NOT BE MORE

THAN 50

YEARS OR

LESS THAN 18

YEARS

It displays

AGE CAN

NOT BE

MORE THAN

50 YEARS OR

LESS THAN

18 YEARS

Fail

10 Functional

If salary is

alpha numeric

or less than

5000

It should display

INVALID

AMOUNT-

PLEASE

CHECK

It displays

INVALID

AMOUNT-

PLEASE

CHECK

Pass

11 Functional

If

confirmation

flag is not

equal to y

It should display

CONFIRM

RATING

DETAILS

SHOULD BE

Y

It displays

CONFIRM

RATING

DETAILS

SHOULD BE

Y

Pass

12 Functional

If loan

amount is

equal to

spaces or

Blank or less

than 10000

It should display

INVALID

AMOUNT-PLEASE

CHECK

It displays

INVALID

AMOUNT-PLEASE

CHECK

Pass

13 Functional

If loan

amount is

greater than

Max Loan

Amount

It should display

LOAN

AMOUNT CAN

NOT BE

GREATER

It displays

LOAN

AMOUNT

CAN NOT BE

GREATER

Fail


53/72



THAN MAX

LOAN

AMOUNT

THAN MAX

LOAN

AMOUNT

14 Functional

If repay

period is not

between 6 and

240

It should display

REPAYMENT

PERIOD

SHOULD BE

BETWEEN/INC

LUDING 6-240

It displays

REPAYMENT

PERIOD

SHOULD BE

BETWEEN/IN

CLUDING 6-

240

Pass

15 Functional

If

confirmation

loan details is

not equal to

y n or

It should displayCONFIRM

LOAN

DETAILS

SHOULD BE

Y OR N OR

It displaysCONFIRM

LOAN

DETAILS

SHOULD BE

Y OR N

OR

Pass

16 Functional

If loan is

successfully

processed

It should

generate a new

customer no,

create a new

record for that

loan, insert into

APP_MSTR

table, display

new Customer

No with message

DETAILS

UPDATED

THANK YOU..

HAVE A NICE

DAY.

It generates a

new customer

no, creates a

new record for

that loan,

inserts into

APP_MSTR

table, displays

new Customer

No with

message

DETAILS

UPDATED

THANK

YOU.. HAVE

A NICE

Pass


54/72



Table 4.1 Test Cases

DAY.

17 Functional

If loan is not

successfully

processed

It should display

"SORRY LOAN

CANNOT BE

ISSUED".

It displays

SORRY

LOAN

CANNOT BE

ISSUED

Fail

18 Functional

If user presses

any keyexcept

ENTER,

CLEAR or

PF3

It should display

INVALID KEYPRESSED.

ENTER/PF3/CL

EARVALID

KEYS

It displays

INVALID

KEYPRESSED.

ENTER/PF3/C

LEAR

VALID

KEYS

Pass

19 Functional

If user inputs

N or in

the loan

confirmation

field

Loan Amount

and Repayment

Period should be

unprotected.

Loan Amount

and

Repayment

Period gets

unprotected.

Pass


55/72



4.2 Results

Figure 4.1 Snap shot of Blank field

The Application screen is displayed where all necessary fields are to be filled and then

the confirm rating details value should be entered. If the confirm rating details is not

entered then we get an message which tells us to enter the value (Y/N) in the confirm

rating details field and then press enter.


56/72



Figure 4.2 snapshot of loan details

The above screen displays the error message when the loan details field is given

empty. The loan details field is a mandatory field and should have valid numeric

values.


57/72



Figure 4.3 Snap shot of Loan condition

The above screen shows the validation for the maximum loan amount that a customer

can avail from the finance company. The loan amount should not be less than 10000

and greater than maximum loan amount.


58/72



Figure 4.4 Snap shot of Repayment period condition

The above screen is displayed when the invalid repayment period value is entered in

the repayment period field. The repayment period should be between 6 months to 240

months.


59/72



Figure 4.5 Snap shot of updated details

The above screen is displayed when all values are successfully entered with proper

validation. This message specifies that the details have been updated into the

database.


60/72



Figure 4.6 Snap shot of Blank field

The above screen displays the validation for the name field where numeric values are

invalid. The message prompts to enter the valid values.


61/72



Figure 4.7 Snap shot of Loan details

The above screen displays the validation for loan amount field where it cannot be

blank. Valid numeric values should be entered.


62/72



Figure 4.8 Snap shot of options

The above screen displays the different options to calculate EMI, to enter new loan

details and to confirm the existing loan details


63/72



4.3 Conclusion and Future Enhancement

Conclusion

The purpose of our project is to provide an elegant system satisfying the requisites

and attaining goals. We have designed the project so that it can be easily understood

by any person irrespective of his knowledge in computer science. The Real Time

Gross Settlement is expected to function as per the requirements and we expect that it

will satisfy the needs of the user.

The Automation of Loan Generation and Servicing project for ABC Finance

Company was successfully designed and is tested for accuracy and quality. During

this project we have accomplished all the objectives and this project meets the needs

of the organization. The developed project will be used in granting loans, retrieving

and generating customer number for the concerned requests.

Future Enhancement

It is not possible to develop a system that makes all the requirements of the user. User

requirements keep changing as the system is being used. Some of the improvements

that can be done to this system are:

As the technology emerges, it is possible to upgrade the system and can be adaptable

to desired environment.

As this project is based on procedure-oriented design, any further changes can be

easily implemented.

Security can be improved using emerging technologies according to the requirements.

Adding recovery module to roll back the transaction


64/72



Annexure

Figure A.1 Blank field


65/72



Figure A.2 Loan details


66/72



Figure A.3 Loan condition


67/72



Figure A.4 Repayment period condition


68/72



Figure A.5 Updated details


69/72


70/72



Figure A.7 Loan details


71/72



Figure A.8 Options required


72/72


Bibliography

[1] Kageyama. "CICS complete Guide fifth edition.

[2] Vikas, IBM MAINFRAME HANDBOOK , second edition

[3] Tata McGraw Hill COBOLPROGRAMMING Roy Dastidar, second edition

[4] Sams DB2 Developers Guide Fourth Edition

[5]Web www.wikipedia.com/mainframes/cics/

[6] Web www.ibmmainframeforum.com
http://www.google.com/http://www.google.com/http://www.ibmmainframeforum.com/http://www.ibmmainframeforum.com/http://www.ibmmainframeforum.com/http://www.google.com/

Documents

ABC Company Project Report