Technical Story Card

Revision History

Version Date Prepared by / Significant Changes

No. Modified by

1 24 Mar 2021 VijayaRaghavan J Draft version

Glossary

Abbreviation Description

BSC Business Story Card

TSC Technical Story Card

 Table of Contents
1 Introduction.......................................................................................................................................................3
2 Scope of Change.................................................................................................................................................3
3 List of impacted modules..................................................................................................................................3
4 Design and Detailed technical updates............................................................................................................4
4.1 Process model........................................................................................................................ 4
4.1.1 Use case Model......................................................................................................... 4
4.1.2 Sequence diagram.................................................................................................... 4
4.2 Proposed user Interface design.............................................................................................. 4
4.3 Database design changes....................................................................................................... 4
4.4 Refactoring related changes................................................................................................... 4
4.5 Construction strategy and re-use............................................................................................ 4
5 Details of Alternative Design Approach..........................................................................................................4
6 Other Technical changes...................................................................................................................................5
6.1 Automation tasks  / changes................................................................................................... 5
6.2 CI / Build relates tasks / changes............................................................................................ 5
6.3 Non-functional related changes.............................................................................................. 5
7 Additional details...............................................................................................................................................5
7.1 Open Questions / clarifications / Assumptions........................................................................5
7.2 Additional notes to technical team........................................................................................... 5
8 References..........................................................................................................................................................5

Page 2 of 18
1 Introduction
Supplier finance is a concept, describing a set of technology-based solutions that aim to lower
financing costs and improve business efficiency for buyers (or clients) and sellers (or suppliers) linked in a
sales transaction. The idea work by automating transactions and tracking invoice approval and settlement
processes, from initiation to completion.

Under this paradigm, clients request the bank to approve their supplier's invoices and pay the
supplier. And by providing short-term credit that optimizes working capital and provides liquidity to both
parties. It also offers distinct advantages to all participants. While suppliers gain quicker access to money
they are owed, clients get more time to pay off their balances.

On either side of the equation, the parties can use the cash on hand for other projects to keep their
respective operations running smoothly.

2 Scope of Change
Change will not be entertained and whatever specifications mentioned in this document is final.

3 List of impacted modules

All the functional modules will be created from scratch.

Page 3 of 18
 4 Design and Detailed technical updates
4.1 Process model
4.1.1 Use case Model

Page 4 of 18
Brief Description Client Registration
Basic Flow This use case describes how a client register in to the system
1. The client has to register himself into the system.
2. After the successful registration, client will get a success
message.
3. The following information is required during registration.
 Name
 Address
 Email
 Mobile Number
 Loan Account Number
 Loan information
Alternate Flow 1. The system will validate the information provided. If any
invalid data is found, the input form will be redirected with
error message.
Validation 1. Name is required and minimum 3 characters and max 30
characters.
2. Address can be alphanumeric.
3. City/State/Country/Province should be selected from a
drop-down.
4. The Email should be valid.
5. Account details should be valid.
Pre-Conditions User should have network access and Browser with latest updates.
Post-Conditions Success message should be shown.

Page 5 of 18
Brief Description Supplier Registration
Basic Flow This use case describes how a supplier register in to the system
1. The supplier has to register himself into the system.
2. After the successful registration, supplier will get a success
message.
3. The following information is required during registration.
 Name
 Address
 Email
 Mobile Number
 Credit Account Number
 Credit information
Alternate Flow 1. The system will validate the information provided. If any
invalid data is found, the input form will be redirected with
error message.
Validation 1. Name is required and minimum 3 characters and max 30
characters.
2. Address can be alphanumeric.
3. City/State/Country/Province should be selected from a
drop-down.
4. The Email should be valid.
5. Account details should be valid.
Pre-Conditions User should have network access and Browser with latest updates.
Post-Conditions Success message should be shown.

Brief Description Login

Page 6 of 18
Basic Flow This use case describes how a user log-in in to the system
1. The client has to register himself into the system.
2. After the successful login, user will be taken to the
appropriate landing page.
3. The following information is required to login.
 username
 password
Alternate Flow 1. The system will validate the credentials provided. If
credentials are invalid, login form will be redirected again
with error message.
Validation 1. Valid username
2. Valid password
Pre-Conditions User should have network access and Browser with latest updates.
Post-Conditions Landing page has to be displayed.

Brief Description Upload Invoice

Basic Flow This use case describes how a client upload an invoice in to the
system
1. The client has to login into the system.
2. The following information is required during upload invoice.
 Supplier code
 Invoice number
 Invoice Date
 Invoice amount

Page 7 of 18
  Currency
 Invoice file
Alternate Flow 1. The system will validate the information provided. If any
invalid data is found, the input form will be redirected with
error message.
Validation 1. Supplier code should be valid
2. Invoice date should be a future date.
3. Currency can be either USD/ GBP/ Euro
4. File size should not be greater than 1MB
Pre-Conditions User should have already logged into the system.
Post-Conditions Success message should be shown.

Brief Description View Invoice (Client/Supplier)

Basic Flow This use case describes how a client can view the status of the
uploaded invoices.
1. The client/supplier has to login into the system.
2. The following information has to be displayed.
 Supplier code
 Invoice number
 Invoice Date
 Invoice amount
 Currency
 Invoice Status
Alternate Flow Not Applicable
Validation Not Applicable

Page 8 of 18
Pre-Conditions User should have already logged into the system.
Post-Conditions Not Applicable

Brief Description Request Payment (Supplier)

Basic Flow This use case describes how a supplier can request for payment,
which are applicable for them.
1. The supplier has to login into the system.
2. Allows supplier to search based on following attributes.
 Invoice number
 Supplier code
 Invoice between a date range.
3. Display the invoice matches the given criteria.
4. Request for payment.
5. Status of the invoice has to be updated.
Alternate Flow Not Applicable
Validation Not Applicable
Pre-Conditions User should have already logged into the system.
Post-Conditions Success message should be shown.

Page 9 of 18
Brief Description Authorize Payment (Bank)
Basic Flow This use case describes how a bank agent can authorize payment
for a supplier.
1. The banker has to login into the system.
2. Allows banker to view the invoices, that were requested for
payment.
3. Authorize or Reject the request based on internal criteria.
4. Status of the invoice has to be updated.
Alternate Flow Not Applicable
Validation Not Applicable
Pre-Conditions User should have already logged into the system.
Post-Conditions Success message should be shown.

Page 10 of 18
Architecture Diagram

Layer Logical View Technology/

Framework

UI Components
HTML/ CSS/
Presentation Export (pdf) Validations JavaScript/
Layer AJAX/ Angular
Report Resources

Web-Server Classes
Java 1.8/ Spring
Application/ Configuration Controllers
MVC
Business
Layer Service REST Controllers

Entity/ Model Classes

Data Access Hibernate ORM

Repository classes
Layer

Oracle 11g
Database

Presentation Layer:
This layer consists of all UI components.
 Export component: The plug-in is used to export the reports in pdf format. It helps to reduce the
workload on the web/ application server.
 Validation component: All basic level data validations should be done at UI level.
 Report component: All reports to be generated to the user, will be processed and generated at
the browser end.

Page 11 of 18
  Resources: All HTML/CSS/ images, which are required for the page design.
Application Layer:
This layer comprises of all server and business classes.
 Configuration settings (XML or Class based) will define the application and server configuration.
 Spring Controllers defines the server classes, which are required to process the incoming http
requests.
 Service classes are required to perform the required business services.
 REST Controllers to process the HTTP AJAX requests.
 Model classes are used the define the functions of the entities present in the system.
Data Layer:
Data layer is implemented through Hibernate ORM. It will contain the repository classes, which provides
interface to the table.

Class Diagram

4.1.2 Sequence diagram

Page 12 of 18
Page 13 of 18
Page 14 of 18
Page 15 of 18
Page 16 of 18
    

<Mention details of code re-factoring requirements; objective and scope of re-factoring and Changes to
be done >

5 Other Technical changes

5.1 CI / Build relates tasks
<If the story requirements are about implementation of continuous integration or build, update the details
to be done here>

Page 17 of 18
5.2 Non-functional related changes
<Non-functional requirements related to response time, System load or Network load>

6 Additional details

6.1 Open Questions / clarifications / Assumptions

<Mention the details of any open technical questions/clarifications or assumptions made, pertaining to
story >

6.2 Additional notes to technical team

<provide details if any>

7 References
< Provide reference details if any >

Page 18 of 18