[
https://issues.apache.org/jira/browse/FINERACT-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17783540#comment-17783540
]
John Ruhiu commented on FINERACT-1684:
--------------------------------------
[~adamsaghy] this is incredible. Is there functional documentation(user manual)
for this feature I can use to test this feature?
> Introduce Business date concept
> -------------------------------
>
> Key: FINERACT-1684
> URL: https://issues.apache.org/jira/browse/FINERACT-1684
> Project: Apache Fineract
> Issue Type: Improvement
> Reporter: Adam Saghy
> Assignee: Adam Saghy
> Priority: Major
> Fix For: 1.8.0
>
> Attachments: image-2022-08-09-10-53-39-750.png
>
>
> h1. Introducing Business Date into Fineract - Community version
> Business date as a concept does not exist as of now in Fineract. It would be
> business critical to add such a functionality to support various banking
> functionalities like “Closing of Business day”, “Having Closing of Business
> day relevant jobs”, “Supporting logical date management”.
> h2. Glossary
> |*COB|Close of Business; concept of closing a business day|
> |*Business day|Timeframe that logically group together actions on a
> particular business date|
> |*Business date|Logical date; its value is not tied to the physical calendar.
> Represents a business day|
> |*Cob date|Logical date; Represents the business date for actions during COB
> job execution|
> |*Created date|When the transaction was created (audit purposes). Date + time|
> |*Last modified date|When the transaction was last modified (audit purposes).
> Date + time|
> |*Submitted on date / Posting date|When the transaction was posted. Tenant
> date or business date (depends on whether the logical date concept was
> introduced or not)|
> |*Transaction date / Value date|The date on which the transaction occurred or
> to be accounted for|
> h2. Current behaviour
> * Fineract support 3 types of dates:
> ** System date
> *** Physical/System date of the running environment
> *
> ** Tenant date
> *** Timezoned version of the above system date
> *
> ** User-provided date
> *** Based on the provided date (as string) and the provided date format
> * There is no support of logical date concept
> ** Independent from the system / tenant date
> * Jobs are scheduled against system date (CRON), but aligned with the tenant
> timezone.
> * During the job execution all the data and transactions are using the
> actual tenant date
> ** It could happen some transactions are written for 17th of May and other
> for 18th of May, if the job was executed around midnight
> * There is no support of COB
> ** No backdated transactions by jobs
> *
> ** There is no support to logically group together transactions and store
> them with the same transaction date which is independent of the physical
> calendar of the tenant
> All the transactions and business logic are tied to a physical calendar
> h2. Business date
> !image-2022-08-09-10-53-39-750.png!
> h3. Design
> By introducing the business day concept we are not tied anymore to the
> physical calendar of the system or the tenant. We got the ability to define
> our own business day boundaries which might end 15 minutes before midnight
> and any incoming transactions after the cutoff will be accounted for the
> following business day.
> It is a logical date which makes it possible to separate the business day
> from the physical calendar:
> * Close a business day before midnight
> * Close a business day at midnight
> * Close a business day after midnight
> Closing a Business Day could be a longer process (see COB jobs) meanwhile
> some processes shall still be able to create transactions for that business
> day (COB jobs), but others are meant to create the transactions for the next
> (incoming transactions): Business date concept is there to sort that out.
> Business date concept is essential when:
> * Having COB jobs:
> ** When the COB was triggered:
> *** All the jobs which processing the data must still accounted for actual
> business day
> *
> **
> *** All the incoming transactions must be accounted to the next business day
> * Business day is ending before / after midnight (tenant date / system date)
> * Testing purposes:
> ** Since the transactions and job execution is not tied anymore to a
> physical calendar, we can easily test a whole loan lifecycle by altering the
> business date
> * Handling disruption of service: For any unseen reason the system goes down
> or there are any disruption in the workflow, the “missed days” can easily be
> processed one by one as nothing happened
> ** There is a disruption at 2022-06-02
> *
> ** The issue is fixed by 2022-06-05
> *
> ** The COB flow can be executed for 2022-06-03 and when it is finished for
> 2022-06-04 and after when the time arrives for 2022-06-05
> * This logical date is manageable via:
> ** Job
> *
> ** API
> To maintain such separation from physical calendar we need to introduce the
> following new dates:
> * Business date
> * COB date
> ** Can be calculated based on the actual business date
> *** Depend on COB date strategy (see below)
> h3.
> h3. Business date
> The - logical - date of the actual business day, eg: 2022-05-06
> * It does not support time parts
> * It can be managed manually (via API call) or automatically (via scheduled
> job)
> * All business actions during the business day shall use this date:
> ** Posting / submitted on date of transactions
> *
> ** Submitted on date of actions
> *
> ** (Regular) jobs
> * It will be used in every situation where the transaction date / value date
> is not provided by the user or the user provided date shall be validated.
> ** Opening date
> *
> ** Closing date
> *
> ** Disbursal date
> *
> ** Transaction/Value date
> *
> ** Posting/Submitted date
> *
> ** Reversal date
> * Will not be use for audit purposes:
> ** Created on date
> *
> ** Updated on date
> *COB date*
> The - logical - date of the business day for job execution, eg: 2022-05-05
> * It can be calculated based on the the business date
> ** COB date = business date - 1 day
> *
> ** Automatically modified alongside with the business date change
> * It does not support time parts
> * It is automatically managed by business date change
> ** Configurable
> * It is used only via COB job execution
> ** When we create / modify any business data during the COB job execution,
> the COB date is to be used:
> *** Posting date of transactions
> *
> **
> *** Submitted on date of actions
> *
> **
> *** Transaction / value date of any actions
> *Some basic example*
> h4. Apply for a loan
> h5. #1
> Tenant date: 2022-05-23 14:22:12
> Business date: 2022-05-22
> Submitted on date: 2022-05-23
> Outcome: *FAIL*
> Message: *The date on which a loan is submitted cannot be in the future.*
> Reason: Even the tenant date is 2022-05-23, but the business date was
> 2022-05-22 which means anything further that date must be considered as a
> future date.
> h5. #2
> Tenant date: 2022-05-23 14:22:12
> Business date: 2022-05-22
> Submitted on date: 2022-05-22
> Outcome: *SUCCESS*
> Loan application details:
> * Submitted on date: 2022-05-22
> *Repayment for a loan*
> h5. #1
> Tenant date: 2022-05-25 11:22:12
> Business date: 2022-05-24
> Transaction date: 2022-05-25
> Outcome: *FAIL*
> Message: *The transaction date cannot be in the future.*
> Reason: Even the physical date is 2022-05-25, but the business date was
> 2022-05-24 which means anything further that date must be considered as a
> future date.
> h5. #2
> Tenant date: 2022-05-25 11:22:12
> Business date: 2022-05-24
> Transaction date: 2022-05-23
> Outcome: *SUCCESS*
> Loan transaction details:
> * Submitted on date: 2022-05-24
> * Transaction date: 2022-05-23
> * Created on date: 2022-05-25 11:22:12
> *Changes in Fineract*
> We shall modify at all the relevant places where the tenant date was used:
> * With very limited exceptions all places where the tenant date is used we
> need to modify to use the business date.
> * Replace system date with tenant date or business date (exceptions may
> apply)
> * Add missing Value dates and Posting dates to entities
> * Having a generic naming conventions for JPA fields and DB fields
> * Renaming the fields accordingly
> * Evaluate value date (transaction date) and posting date (submitted on
> date), created on date usages
> * Jobs to be checked and modified accordingly
> * Native queries to be checked and modified accordingly
> * Reports to be checked and modified accordingly
> * Every table where update is supported the AbstractAuditableCustom should
> be implemented
> * Amend Transactions and Journal entries date handling to fit for business
> date concept
> * For audit fields we shall introduce timezoned datetimes and store them in
> database accordingly
> ** Storing DATETIME fields without Timezone is potential problem due to the
> daylight savings
> *
> ** Also some external libs (like Quartz) are using system timezone and
> Fineract will using Tenant timezone for audit fields. To be able to distinct
> them in DB we shall use DATETIME with TIMESTAMP column types and use
> timezoned java time objects in the application
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
