Complete Project Working.

--------------------------------------------------
Total 3 roles for login user (Creator,Approval,Viewer).
Based on roles user will be able to access different pages.
Creator will have access to Create,Manage and view Page, while Approval have
access to Approver and view page and Viewer has access to view page only.

NOTE: Creator can create from specific debitaccount number but cannot be an
approver of the same debit account_number but can be approver of different
debit_account_number. Same goes for an Approver. Viewer can only view the account
statement of debit_account_number assigned to him.

So Creator can also be an approver but not for the same account he created but for
a different account

Acceptance Criterias (Keep this in check):

-----------------------
Verify that valid credentials are used for login authentication
Proper error message for any failure cases
Verify that account is locked after three (3) failed login attempts.
Valid Data for every fields to be able to enter by user
Payment Submission for further processing, if all the required input values
available
Save as Draft to be available for modify the data in future
Batching to be done for each set of transaction for easy management and Access
segregations
Amount in respective Base Currency and Account Currency to be available.
Valid Data for every fields to be able to enter by user
Payment Submission for further processing, if all the required input values
available
Save as Draft to be available for modify the data in future
All transactions belongs to the user to be displayed in a list
User to be able to take actions for these transactions
Any restriction of access available to be able to apply on the list of transactions
and batches
All transactions belongs to the user for approval to be displayed in a list
User to be able to take actions for these transactions (Approve / Reject)
Any restriction of access available to be able to apply on the list
Print Transaction details in a user readable format
Multiple transaction should be able to print
Dynamic html preview layout should be able to define
The access restrictions to be done for the transaction / Batch printing based on
user access
Accounts along with the balance to be displayed

How the Whole UI and Functionality Works

-----------------------------------------

1) Login:
Login page contains Email and password. If the credentials match,
the respective user login otherwise after 3 wrong login attempts will lock the
account. Login page have an hyperlink for forgot password, which asks user for
email , set of secret questions, respective secret answer, create new
password and confirm new password. After resetting password, the old password
gets updated in the database and user is back to login page, with a toastify saying
Password updated successfully.
Make sure that localhost path is not changeable from url to any other routes,
if he tries, then he will be signed out and redirected to login page.

As soon as we login we got to a login page, based on the role, the sidebar(sandwich
bar that will close and open) will consist only that options
such as Creator role will have only Create and Manage options in sidebar with a
logout and home options at the bottom of the sidebar.
Approver will have only Approve option in sidebar with a logout and home options at
the bottom of the sidebar..
Viewer will have only Account Statement of Debit acc. in side bar with a logout and
home options at the bottom of the sidebar.
Based on the number of roles assigned to user with specific debit account no. those
role options will be available in the sidebar.
Other options will be disabled(not accessible by the user) or not visible.

2) Create: So as soon as we click on login with proper credentials based on role

we will got to the respective page mentioned in sidebar, rest will be disabled,
following fields are there:
Fixed at top of the page: Debit account no.s for which the user has access to.(from
which the amount will be sent), Date on which the amount will get debited and sent
to the employee(payee), Total Amount(Sum of the Amount for each transaction) with a
drop down option with which he can view the amount in different currencies., No.of
Transactions(based on the data uploaded or added),
Below the components of fixed page at top there will be 4 buttons equally spaced
in the page "Save As Draft", "Add Employee", "Submit" and "Upload" .
Filter: User can filter the users based on Payee name, payee Bank Id.
Pagination component below the above Fixed part:Payee Bank Id, Payee Name, Acc no.,
Amount, Remarks. (One page contains only 10 Transactions)
If user wants to add an employee he can upload details through csv file by clicking
on "Upload" button or can add each employee one by on by clicking on "Add
Employee".
There will be a pop up asking the user whether he wants to replace the data he
entered or he want to append it further
After filling these details with proper validations and leaving no fields blank we
can either save this as draft
by clicking it on "Save As Draft" button or just "Submit" it for approval.This will
auto generate a BatchID for that particular batch which is either saved as draft or
submitted.
Note: The no. of transactions will show the count based on the no. of employees
added or uploaded. and Total Amount will show sum of the Amount of every employee
in that particular batch.
A batch can consist of only one transaction or multiple transaction.

Creator can Manage and View the account in Manage option of sidebar.
3)Manage:
If saved as draft, you can manage the data in manage section where you will
see BatchID(Auto Generated non-editable), Total no. of transactions, Total Amount,
Debit Account no.,Remarks(That was entered in Create page), Remarks(which we will
obtain from approval page),
Batch Status(i.e Saved as draft or Approved or Rejected or Pending). If the status
is Saved as Draft then only we can access the hyperlink(BatchID) to edit the saved
draft of the batch,
that is it will be redirected to Edit page with all the options and UI similar to
Create page but with an addition of BatchID(Non Editable) at the top fixed,
otherwise hyperlink is not accessable.
Edit page will also have an option to discard the entire data that means the whole
data entered will be deleted with BatchID from database, before deleting user will
also be asked to confirm his decision with a popup.
Once saved draft is submitted the status will change to pending until its approved
or rejected by approver in the page before accessing the hyperlink. All the status
done by the approver on specific account number for each batch will be reflected
i.e updated in the Batch Status including the remarks provided by the approver in
approve page.

4)Approve:
Now comes the scenario where the creator submits the data for approval either from
Manage section or Create section.

NOTE: Creator cannot approve the accounts or batch that he created but he can
approve or reject other accounts.
There is always a Creator and an Approver for each batch. So check all 3 scenarios
where
one user can only be creator or can only be approver or can be both but for
different batches.

Approver will only be able to view the approve part only for those Batches for
which he is assigned to, that is for the batches other than accounts that he
created and specifically assigned with a debit account_no.
Once we login with a role of approver, we can click on only approve section.Approve
section consists of
BatchID, TotalAmount(of that Batch), Created By, Created On, No. Of
Transactions,Debit Account No.
beside each detail 2 Buttons of Approve and Reject. When clicked on Approve or
Reject a pop up will appear
to confirm user password and remarks, which will be stored in remarks column and
status and remarks will also get update the same in Manage section
and buttons will dissapear and batch status will get updated for approved or
rejected respectively based on the button clicked.
which will be showin in approval history which contain BatchID, Total Amount, Total
Transactions, Status and Remarks.

Viewer will have a view section in which he will be able to view only that account
statement for which he is mapped with that is the debit account number that he is
assigned with.
View: In which he will be able to view all the related details necessary for an
account statement(Debit Account). From all above 3 given scenarios and can also
print the statement in respective file format.
A drill down to transaction level details to be available for view
Account statement to be able to download or view through selecting the account and
the date range

For this entire project we are using React for frontend UI and MaterialUI for
enhancements or any other libraries for beautification.
Springboot and Postgres for backend connectivity. Creation of APIs and testing
using Postman.

Project Structure:
------------------
UI folder
---------
src
|---->Components
 |----->necessary components.
|---->Features
|----->related features
|---->Contents
|---->Constants
|----->API
|---->App.js
|---->AppRoutes.js
|---->App.css

API folder
----------
src
|----> repository
|----> controller
|----> service
|----> entity
|----> security
|----> utils
|----> App.java

Here’s a detailed description of the connections between each table based on the
database schema:

1. Users → Debit Accounts

Connection: One-to-Many (1:N)
Description: A single user can be assigned multiple debit accounts. The user_id in
the users table is referenced as a foreign key (FK) in the debit_accounts table.
Foreign Key: debit_accounts.user_id references users.user_id.

1) CREATE TABLE users (

user_id SERIAL PRIMARY KEY,
user_name VARCHAR(100) NOT NULL,
email VARCHAR(100) UNIQUE NOT NULL,
password VARCHAR(255) NOT NULL,
role VARCHAR(50) NOT NULL, -- 'Creator', 'Approver', 'Viewer', or combination
is_locked BOOLEAN DEFAULT FALSE, -- For account locking after failed attempts
failed_attempts INT DEFAULT 0,
secret_question VARCHAR(255),
secret_answer VARCHAR(255)
);

2. Debit Accounts → Batches

Connection: One-to-Many (1:N)
Description: A single debit account can be used in multiple batches. The account_id
in the debit_accounts table is referenced as a foreign key in the batches table.
Foreign Key: batches.debit_account_id references debit_accounts.account_id.

2) CREATE TABLE debit_accounts (

account_id SERIAL PRIMARY KEY,
account_number VARCHAR(50) UNIQUE NOT NULL,
user_id INT REFERENCES users(user_id),
assigned_role VARCHAR(50), -- Role for this account ('Creator', 'Approver', or
'Viewer')
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

3. Users → Batches
Connection: One-to-Many (1:N)
Description: A single user (with the Creator role) can create multiple batches. The
user_id of the creator is referenced as a foreign key in the batches table.
Foreign Key: batches.creator_id references users.user_id.

3) CREATE TABLE batches (

batch_id SERIAL PRIMARY KEY,
batch_code VARCHAR(50) UNIQUE NOT NULL, -- Auto-generated (e.g., 'BRID001')
debit_account_id INT REFERENCES debit_accounts(account_id),
creator_id INT REFERENCES users(user_id), -- User who created the batch
total_amount DECIMAL(10, 2),
transaction_count INT,
status VARCHAR(50) DEFAULT 'Draft', -- 'Draft', 'Pending', 'Approved',
'Rejected'
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
remarks_creator TEXT,
remarks_approver TEXT
);

4. Batches → Transactions
Connection: One-to-Many (1:N)
Description: Each batch can have multiple transactions associated with it. The
batch_id in the batches table is referenced as a foreign key in the transactions
table.
Foreign Key: transactions.batch_id references batches.batch_id.

4) CREATE TABLE transactions (

transaction_id SERIAL PRIMARY KEY,
batch_id INT REFERENCES batches(batch_id),
payee_name VARCHAR(100) NOT NULL,
payee_account_number VARCHAR(50) NOT NULL,
payee_bank_id VARCHAR(50),
amount DECIMAL(10, 2),
remarks TEXT
);

5. Users → Approvals
Connection: One-to-Many (1:N)
Description: A user (with the Approver role) can approve multiple batches. The
user_id of the approver is referenced as a foreign key in the approvals table.
Foreign Key: approvals.approver_id references users.user_id.

5) CREATE TABLE approvals (

approval_id SERIAL PRIMARY KEY,
batch_id INT REFERENCES batches(batch_id),
approver_id INT REFERENCES users(user_id),
status VARCHAR(50) NOT NULL, -- 'Approved' or 'Rejected'
approval_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
remarks TEXT
);

6. Batches → Approvals
Connection: One-to-One (1:1)
Description: Each batch can have one approval or rejection by an approver. The
batch_id in the batches table is referenced as a foreign key in the approvals
table.
Foreign Key: approvals.batch_id references batches.batch_id.

6) CREATE TABLE account_statements (

statement_id SERIAL PRIMARY KEY,
debit_account_id INT REFERENCES debit_accounts(account_id),
transaction_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
transaction_details TEXT, -- JSON or relevant format to hold statement data
total_balance DECIMAL(10, 2)
);

7. Debit Accounts → Account Statements

Connection: One-to-Many (1:N)
Description: A single debit account can have multiple account statements (usually
for different dates). The account_id in the debit_accounts table is referenced as a
foreign key in the account_statements table.
Foreign Key: account_statements.debit_account_id references
debit_accounts.account_id.

Summary of Foreign Key Relationships:

debit_accounts.user_id → users.user_id (A user can have multiple debit accounts)
batches.debit_account_id → debit_accounts.account_id (A debit account can have
multiple batches)
batches.creator_id → users.user_id (A creator can create multiple batches)
transactions.batch_id → batches.batch_id (A batch can have multiple transactions)
approvals.approver_id → users.user_id (An approver can approve multiple batches)
approvals.batch_id → batches.batch_id (Each batch has one approval or rejection)
account_statements.debit_account_id → debit_accounts.account_id (A debit account
can have multiple account statements)

These relationships ensure that data related to users, debit accounts, batches,
transactions, approvals, and account statements are well connected and normalized.

1) CREATE TABLE users (

user_id SERIAL PRIMARY KEY,
user_name VARCHAR(100) NOT NULL,
email VARCHAR(100) UNIQUE NOT NULL,
password VARCHAR(255) NOT NULL,
role VARCHAR(50) NOT NULL, -- 'Creator', 'Approver', 'Viewer', or combination
is_locked BOOLEAN DEFAULT FALSE, -- For account locking after failed attempts
failed_attempts INT DEFAULT 0,
secret_question VARCHAR(255),
secret_answer VARCHAR(255)
);

2) CREATE TABLE debit_accounts (

account_id SERIAL PRIMARY KEY,
account_number VARCHAR(50) UNIQUE NOT NULL,
user_id INT REFERENCES users(user_id),
assigned_role VARCHAR(50), -- Role for this account ('Creator', 'Approver', or
'Viewer')
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
3) CREATE TABLE batches (
batch_id SERIAL PRIMARY KEY,
batch_code VARCHAR(50) UNIQUE NOT NULL, -- Auto-generated (e.g., 'BRID001')
debit_account_id INT REFERENCES debit_accounts(account_id),
creator_id INT REFERENCES users(user_id), -- User who created the batch
total_amount DECIMAL(10, 2),
transaction_count INT,
status VARCHAR(50) DEFAULT 'Draft', -- 'Draft', 'Pending', 'Approved',
'Rejected'
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
remarks_creator TEXT,
remarks_approver TEXT
);

4) CREATE TABLE transactions (

transaction_id SERIAL PRIMARY KEY,
batch_id INT REFERENCES batches(batch_id),
payee_name VARCHAR(100) NOT NULL,
payee_account_number VARCHAR(50) NOT NULL,
payee_bank_id VARCHAR(50),
amount DECIMAL(10, 2),
remarks TEXT
);

5) CREATE TABLE approvals (

approval_id SERIAL PRIMARY KEY,
batch_id INT REFERENCES batches(batch_id),
approver_id INT REFERENCES users(user_id),
status VARCHAR(50) NOT NULL, -- 'Approved' or 'Rejected'
approval_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
remarks TEXT
);

6) CREATE TABLE account_statements (

statement_id SERIAL PRIMARY KEY,
debit_account_id INT REFERENCES debit_accounts(account_id),
transaction_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
transaction_details TEXT, -- JSON or relevant format to hold statement data
total_balance DECIMAL(10, 2)
);