[jira] [Updated] (FINERACT-1677) Teller/Cashier Management not working
[ https://issues.apache.org/jira/browse/FINERACT-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajarshi Singha updated FINERACT-1677: -- Fix Version/s: 1.8.0 > Teller/Cashier Management not working > - > > Key: FINERACT-1677 > URL: https://issues.apache.org/jira/browse/FINERACT-1677 > Project: Apache Fineract > Issue Type: Bug > Components: Organization >Affects Versions: 1.7.0 >Reporter: Rajarshi Singha >Priority: Blocker > Fix For: 1.8.0 > > Attachments: error log.txt > > > 1) Teller Management allocate cash , settle cash throwing error 500 > 2). No Transaction is showing on Teller Management -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1677) Teller/Cashier Management not working
[ https://issues.apache.org/jira/browse/FINERACT-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajarshi Singha updated FINERACT-1677: -- Priority: Blocker (was: Major) > Teller/Cashier Management not working > - > > Key: FINERACT-1677 > URL: https://issues.apache.org/jira/browse/FINERACT-1677 > Project: Apache Fineract > Issue Type: Bug > Components: Organization >Affects Versions: 1.7.0 >Reporter: Rajarshi Singha >Priority: Blocker > Attachments: error log.txt > > > 1) Teller Management allocate cash , settle cash throwing error 500 > 2). No Transaction is showing on Teller Management -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1682) Inactive job's job key does not refresh for multiple tenants
[ https://issues.apache.org/jira/browse/FINERACT-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Saghy updated FINERACT-1682: - Description: When a job is inactive (does not scheduled), it still can be executed. Unfortunately for inactive jobs the job key does not refreshed during scheduling (which is fine), but without the job key refresh, these jobs will be still executed, however the execution details transaction will fail if multiple tenants are present. When a job is executed 2 transaction is occurs: 1. The job's logic 2. Saving the jobs execution details was:When a job is inactive (does not scheduled), it still can be executed. Unfortunately for inactive jobs the job key does not refreshed during scheduling (which is fine), but without the job key refresh, these jobs will fail if multiple tenants are present > Inactive job's job key does not refresh for multiple tenants > > > Key: FINERACT-1682 > URL: https://issues.apache.org/jira/browse/FINERACT-1682 > Project: Apache Fineract > Issue Type: Bug >Affects Versions: 1.8.0 >Reporter: Adam Saghy >Assignee: Adam Saghy >Priority: Major > Fix For: 1.9.0 > > > When a job is inactive (does not scheduled), it still can be executed. > Unfortunately for inactive jobs the job key does not refreshed during > scheduling (which is fine), but without the job key refresh, these jobs will > be still executed, however the execution details transaction will fail if > multiple tenants are present. > When a job is executed 2 transaction is occurs: > 1. The job's logic > 2. Saving the jobs execution details -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (FINERACT-1682) Inactive job's job key does not refresh for multiple tenants
[ https://issues.apache.org/jira/browse/FINERACT-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Saghy resolved FINERACT-1682. -- Resolution: Fixed > Inactive job's job key does not refresh for multiple tenants > > > Key: FINERACT-1682 > URL: https://issues.apache.org/jira/browse/FINERACT-1682 > Project: Apache Fineract > Issue Type: Bug >Affects Versions: 1.8.0 >Reporter: Adam Saghy >Assignee: Adam Saghy >Priority: Major > Fix For: 1.9.0 > > > When a job is inactive (does not scheduled), it still can be executed. > Unfortunately for inactive jobs the job key does not refreshed during > scheduling (which is fine), but without the job key refresh, these jobs will > fail if multiple tenants are present -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1685) Unhandled exceptions were not logged properly
[ https://issues.apache.org/jira/browse/FINERACT-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Saghy updated FINERACT-1685: - Fix Version/s: 1.8.0 > Unhandled exceptions were not logged properly > - > > Key: FINERACT-1685 > URL: https://issues.apache.org/jira/browse/FINERACT-1685 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Adam Saghy >Assignee: Adam Saghy >Priority: Major > Fix For: 1.8.0 > > > There are undhandled exceptions which are not logged with details. Without > the proper logging it is hard to debug and monitor the application behaviour. > > *A.C.* > *-* Log unhandled exception on WARN level -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1682) Inactive job's job key does not refresh for multiple tenants
[ https://issues.apache.org/jira/browse/FINERACT-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Saghy updated FINERACT-1682: - Fix Version/s: 1.9.0 > Inactive job's job key does not refresh for multiple tenants > > > Key: FINERACT-1682 > URL: https://issues.apache.org/jira/browse/FINERACT-1682 > Project: Apache Fineract > Issue Type: Bug >Reporter: Adam Saghy >Assignee: Adam Saghy >Priority: Major > Fix For: 1.9.0 > > > When a job is inactive (does not scheduled), it still can be executed. > Unfortunately for inactive jobs the job key does not refreshed during > scheduling (which is fine), but without the job key refresh, these jobs will > fail if multiple tenants are present -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1688) Activation date should never be earlier than the submitted on date
[ https://issues.apache.org/jira/browse/FINERACT-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Saghy updated FINERACT-1688: - Fix Version/s: 1.8.0 > Activation date should never be earlier than the submitted on date > -- > > Key: FINERACT-1688 > URL: https://issues.apache.org/jira/browse/FINERACT-1688 > Project: Apache Fineract > Issue Type: Bug >Reporter: Adam Saghy >Assignee: Adam Saghy >Priority: Major > Fix For: 1.8.0 > > > Activation date should never be earlier than the submitted on date -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1686) Auditor fix - Detached Auditor entity was not persisted during cascade persisting
[ https://issues.apache.org/jira/browse/FINERACT-1686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Saghy updated FINERACT-1686: - Fix Version/s: 1.8.0 > Auditor fix - Detached Auditor entity was not persisted during cascade > persisting > - > > Key: FINERACT-1686 > URL: https://issues.apache.org/jira/browse/FINERACT-1686 > Project: Apache Fineract > Issue Type: Bug >Reporter: Adam Saghy >Priority: Major > Fix For: 1.8.0 > > > While the AppUser (entity) was the auditor, the Spring JPA Auditing was not > working perfectly. When a detached entity was saved through assosication the > AppUser auditor was not set and it was null in the DB. > Example: > * Find Loan by id > * Create a new transaction > * Add the loan transaction to the Loan > * Save the Loan entity > Outcome: > * Loan transaction created by id was null > Solution > The AppUser entity was changed to be just the AppUser id. It is working just > fine now, and anyway the AppUser was never used and was unnecessary anyway to > be fetched. > Similar issue: > [https://stackoverflow.com/questions/38828189/spring-data-jpa-auditing-fails-when-persisting-detached-entity] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1682) Inactive job's job key does not refresh for multiple tenants
[ https://issues.apache.org/jira/browse/FINERACT-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Saghy updated FINERACT-1682: - Affects Version/s: 1.8.0 > Inactive job's job key does not refresh for multiple tenants > > > Key: FINERACT-1682 > URL: https://issues.apache.org/jira/browse/FINERACT-1682 > Project: Apache Fineract > Issue Type: Bug >Affects Versions: 1.8.0 >Reporter: Adam Saghy >Assignee: Adam Saghy >Priority: Major > Fix For: 1.9.0 > > > When a job is inactive (does not scheduled), it still can be executed. > Unfortunately for inactive jobs the job key does not refreshed during > scheduling (which is fine), but without the job key refresh, these jobs will > fail if multiple tenants are present -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1684) Introduce Business date concept
[ https://issues.apache.org/jira/browse/FINERACT-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Saghy updated FINERACT-1684: - Fix Version/s: 1.8.0 > 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
[jira] [Updated] (FINERACT-1689) Fix job mismatched logic
[ https://issues.apache.org/jira/browse/FINERACT-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Saghy updated FINERACT-1689: - Fix Version/s: 1.8.0 > Fix job mismatched logic > > > Key: FINERACT-1689 > URL: https://issues.apache.org/jira/browse/FINERACT-1689 > Project: Apache Fineract > Issue Type: Bug >Reporter: Adam Saghy >Assignee: Adam Saghy >Priority: Major > Fix For: 1.8.0 > > > In short about the issue: We marked the jobs as mismatched if they were > triggered from the “wrong” node, however when they were executed on the > “right” node, the “isMismatched” flag was not lifted -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (FINERACT-1689) Fix job mismatched logic
[ https://issues.apache.org/jira/browse/FINERACT-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Saghy resolved FINERACT-1689. -- Resolution: Fixed > Fix job mismatched logic > > > Key: FINERACT-1689 > URL: https://issues.apache.org/jira/browse/FINERACT-1689 > Project: Apache Fineract > Issue Type: Bug >Reporter: Adam Saghy >Assignee: Adam Saghy >Priority: Major > > In short about the issue: We marked the jobs as mismatched if they were > triggered from the “wrong” node, however when they were executed on the > “right” node, the “isMismatched” flag was not lifted -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-1687) Migrating from java.util.Date to java.time.LocalDate/LocalDateTime
[ https://issues.apache.org/jira/browse/FINERACT-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17577303#comment-17577303 ] Adam Saghy commented on FINERACT-1687: -- [~awasum] Let me add the missing information > Migrating from java.util.Date to java.time.LocalDate/LocalDateTime > -- > > Key: FINERACT-1687 > URL: https://issues.apache.org/jira/browse/FINERACT-1687 > Project: Apache Fineract > Issue Type: Improvement > Components: Performance >Affects Versions: 1.7.0 >Reporter: Adam Saghy >Assignee: Adam Saghy >Priority: Major > Labels: hardening > Fix For: 1.8.0 > > > java.util.Date is outdated and flawed. It is making hard to support multi > tenancy and multiple timezones. > See more: > [https://programminghints.com/2017/05/still-using-java-util-date-dont/] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1687) Migrating from java.util.Date to java.time.LocalDate/LocalDateTime
[ https://issues.apache.org/jira/browse/FINERACT-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Awasum Yannick updated FINERACT-1687: - Labels: hardening (was: ) > Migrating from java.util.Date to java.time.LocalDate/LocalDateTime > -- > > Key: FINERACT-1687 > URL: https://issues.apache.org/jira/browse/FINERACT-1687 > Project: Apache Fineract > Issue Type: Improvement > Components: Performance >Affects Versions: 1.7.0 >Reporter: Adam Saghy >Assignee: Adam Saghy >Priority: Major > Labels: hardening > Fix For: 1.8.0 > > > java.util.Date is outdated and flawed. It is making hard to support multi > tenancy and multiple timezones. > See more: > [https://programminghints.com/2017/05/still-using-java-util-date-dont/] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1687) Migrating from java.util.Date to java.time.LocalDate/LocalDateTime
[ https://issues.apache.org/jira/browse/FINERACT-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Awasum Yannick updated FINERACT-1687: - Component/s: Performance > Migrating from java.util.Date to java.time.LocalDate/LocalDateTime > -- > > Key: FINERACT-1687 > URL: https://issues.apache.org/jira/browse/FINERACT-1687 > Project: Apache Fineract > Issue Type: Improvement > Components: Performance >Affects Versions: 1.7.0 >Reporter: Adam Saghy >Assignee: Adam Saghy >Priority: Major > > java.util.Date is outdated and flawed. It is making hard to support multi > tenancy and multiple timezones. > See more: > [https://programminghints.com/2017/05/still-using-java-util-date-dont/] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1687) Migrating from java.util.Date to java.time.LocalDate/LocalDateTime
[ https://issues.apache.org/jira/browse/FINERACT-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Saghy updated FINERACT-1687: - Fix Version/s: 1.8.0 > Migrating from java.util.Date to java.time.LocalDate/LocalDateTime > -- > > Key: FINERACT-1687 > URL: https://issues.apache.org/jira/browse/FINERACT-1687 > Project: Apache Fineract > Issue Type: Improvement > Components: Performance >Affects Versions: 1.7.0 >Reporter: Adam Saghy >Assignee: Adam Saghy >Priority: Major > Fix For: 1.8.0 > > > java.util.Date is outdated and flawed. It is making hard to support multi > tenancy and multiple timezones. > See more: > [https://programminghints.com/2017/05/still-using-java-util-date-dont/] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1687) Migrating from java.util.Date to java.time.LocalDate/LocalDateTime
[ https://issues.apache.org/jira/browse/FINERACT-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Awasum Yannick updated FINERACT-1687: - Affects Version/s: 1.7.0 > Migrating from java.util.Date to java.time.LocalDate/LocalDateTime > -- > > Key: FINERACT-1687 > URL: https://issues.apache.org/jira/browse/FINERACT-1687 > Project: Apache Fineract > Issue Type: Improvement >Affects Versions: 1.7.0 >Reporter: Adam Saghy >Assignee: Adam Saghy >Priority: Major > > java.util.Date is outdated and flawed. It is making hard to support multi > tenancy and multiple timezones. > See more: > [https://programminghints.com/2017/05/still-using-java-util-date-dont/] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-1687) Migrating from java.util.Date to java.time.LocalDate/LocalDateTime
[ https://issues.apache.org/jira/browse/FINERACT-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17577302#comment-17577302 ] Awasum Yannick commented on FINERACT-1687: -- Great work [~adamsaghy] ... Please [~avidakovic] and [~arnoldgalovics] wonder which fixed version this falls under? > Migrating from java.util.Date to java.time.LocalDate/LocalDateTime > -- > > Key: FINERACT-1687 > URL: https://issues.apache.org/jira/browse/FINERACT-1687 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Adam Saghy >Assignee: Adam Saghy >Priority: Major > > java.util.Date is outdated and flawed. It is making hard to support multi > tenancy and multiple timezones. > See more: > [https://programminghints.com/2017/05/still-using-java-util-date-dont/] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-1689) Fix job mismatched logic
[ https://issues.apache.org/jira/browse/FINERACT-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17577301#comment-17577301 ] Adam Saghy commented on FINERACT-1689: -- PR https://github.com/apache/fineract/pull/2439 > Fix job mismatched logic > > > Key: FINERACT-1689 > URL: https://issues.apache.org/jira/browse/FINERACT-1689 > Project: Apache Fineract > Issue Type: Bug >Reporter: Adam Saghy >Assignee: Adam Saghy >Priority: Major > > In short about the issue: We marked the jobs as mismatched if they were > triggered from the “wrong” node, however when they were executed on the > “right” node, the “isMismatched” flag was not lifted -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FINERACT-1689) Fix job mismatched logic
Adam Saghy created FINERACT-1689: Summary: Fix job mismatched logic Key: FINERACT-1689 URL: https://issues.apache.org/jira/browse/FINERACT-1689 Project: Apache Fineract Issue Type: Bug Reporter: Adam Saghy Assignee: Adam Saghy In short about the issue: We marked the jobs as mismatched if they were triggered from the “wrong” node, however when they were executed on the “right” node, the “isMismatched” flag was not lifted -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-1670) Introduce Auditable entities - Storing date time in UTC
[ https://issues.apache.org/jira/browse/FINERACT-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17577300#comment-17577300 ] Adam Saghy commented on FINERACT-1670: -- PR: [https://github.com/apache/fineract/pull/2407] [GitHub Pull Request #2482|https://github.com/apache/fineract/pull/2482] [https://github.com/apache/fineract/pull/2418] [https://github.com/apache/fineract/pull/2468] [https://github.com/apache/fineract/pull/2467] [https://github.com/apache/fineract/pull/2444] > Introduce Auditable entities - Storing date time in UTC > --- > > Key: FINERACT-1670 > URL: https://issues.apache.org/jira/browse/FINERACT-1670 > Project: Apache Fineract > Issue Type: Improvement >Affects Versions: 1.7.0 >Reporter: Adam Saghy >Assignee: Adam Saghy >Priority: Major > Attachments: Re_ Timezone issues with Daylight savings.rtfd.zip > > > AbstractAuditableCustom interface to be used more widely with entities. > Many Fineract entity has no proper audit fields (creation date & time, last > modification date & time, created by, modified by entries. > Many entities has a variety of the above fields but with custom > implementation and not fit perfectly for audit purposes (see LoanTransaction). > All business entity ( utility entities excluded) should implement the above > interface and fill properly the audit fields with a common, generic way. > The similar custom fields to be removed / repurposed. > The Datetime fields to be stored in UTC! The datetime fields when its fetched > from the DB it is UTC, so it needs to be converted to the proper tenant > timezone if there is any business logic attached to them. > > Storing in UTC is important to avoid daylight savings and "incorrect timezone > is used" issues: > - Some places the tenant timezone used > - Som places the system timezone used > > *Acceptance criteria* > * Every custom fields with similar purpose to be decommissioned > * All datetime field to be utc > * It must be a backward-compatible change! > ** Column cannot be removed! > *Change proposal* > * created_on_utc: Timezone aware datetime field > * last_modified_on_utc: Timezone aware datetime field > * created_by: Long (AppUser id) > * last_modified_by: Lond (AppUser id) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-1684) Introduce Business date concept
[ https://issues.apache.org/jira/browse/FINERACT-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17577299#comment-17577299 ] Adam Saghy commented on FINERACT-1684: -- PRs: [https://github.com/apache/fineract/pull/2358] [https://github.com/apache/fineract/pull/2362] [https://github.com/apache/fineract/pull/2384] [https://github.com/apache/fineract/pull/2390] [https://github.com/apache/fineract/pull/2391] [https://github.com/apache/fineract/pull/2402] [https://github.com/apache/fineract/pull/2412] > 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 > 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
[jira] [Commented] (FINERACT-1688) Activation date should never be earlier than the submitted on date
[ https://issues.apache.org/jira/browse/FINERACT-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17577297#comment-17577297 ] Adam Saghy commented on FINERACT-1688: -- PR: https://github.com/apache/fineract/pull/2433 > Activation date should never be earlier than the submitted on date > -- > > Key: FINERACT-1688 > URL: https://issues.apache.org/jira/browse/FINERACT-1688 > Project: Apache Fineract > Issue Type: Bug >Reporter: Adam Saghy >Assignee: Adam Saghy >Priority: Major > > Activation date should never be earlier than the submitted on date -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-1687) Migrating from java.util.Date to java.time.LocalDate/LocalDateTime
[ https://issues.apache.org/jira/browse/FINERACT-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17577298#comment-17577298 ] Adam Saghy commented on FINERACT-1687: -- PR: [https://github.com/apache/fineract/pull/2416] [https://github.com/apache/fineract/pull/2417] [https://github.com/apache/fineract/pull/2420] [https://github.com/apache/fineract/pull/2423] [https://github.com/apache/fineract/pull/2426] [https://github.com/apache/fineract/pull/2428|https://github.com/apache/fineract/pull/2428/files] > Migrating from java.util.Date to java.time.LocalDate/LocalDateTime > -- > > Key: FINERACT-1687 > URL: https://issues.apache.org/jira/browse/FINERACT-1687 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Adam Saghy >Assignee: Adam Saghy >Priority: Major > > java.util.Date is outdated and flawed. It is making hard to support multi > tenancy and multiple timezones. > See more: > [https://programminghints.com/2017/05/still-using-java-util-date-dont/] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (FINERACT-1688) Activation date should never be earlier than the submitted on date
[ https://issues.apache.org/jira/browse/FINERACT-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Saghy resolved FINERACT-1688. -- Resolution: Fixed > Activation date should never be earlier than the submitted on date > -- > > Key: FINERACT-1688 > URL: https://issues.apache.org/jira/browse/FINERACT-1688 > Project: Apache Fineract > Issue Type: Bug >Reporter: Adam Saghy >Assignee: Adam Saghy >Priority: Major > > Activation date should never be earlier than the submitted on date -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FINERACT-1688) Activation date should never be earlier than the submitted on date
Adam Saghy created FINERACT-1688: Summary: Activation date should never be earlier than the submitted on date Key: FINERACT-1688 URL: https://issues.apache.org/jira/browse/FINERACT-1688 Project: Apache Fineract Issue Type: Bug Reporter: Adam Saghy Assignee: Adam Saghy Activation date should never be earlier than the submitted on date -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (FINERACT-1687) Migrating from java.util.Date to java.time.LocalDate/LocalDateTime
[ https://issues.apache.org/jira/browse/FINERACT-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Saghy resolved FINERACT-1687. -- Resolution: Fixed > Migrating from java.util.Date to java.time.LocalDate/LocalDateTime > -- > > Key: FINERACT-1687 > URL: https://issues.apache.org/jira/browse/FINERACT-1687 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Adam Saghy >Assignee: Adam Saghy >Priority: Major > > java.util.Date is outdated and flawed. It is making hard to support multi > tenancy and multiple timezones. > See more: > [https://programminghints.com/2017/05/still-using-java-util-date-dont/] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FINERACT-1687) Migrating from java.util.Date to java.time.LocalDate/LocalDateTime
Adam Saghy created FINERACT-1687: Summary: Migrating from java.util.Date to java.time.LocalDate/LocalDateTime Key: FINERACT-1687 URL: https://issues.apache.org/jira/browse/FINERACT-1687 Project: Apache Fineract Issue Type: Improvement Reporter: Adam Saghy Assignee: Adam Saghy java.util.Date is outdated and flawed. It is making hard to support multi tenancy and multiple timezones. See more: [https://programminghints.com/2017/05/still-using-java-util-date-dont/] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (FINERACT-1686) Auditor fix - Detached Auditor entity was not persisted during cascade persisting
[ https://issues.apache.org/jira/browse/FINERACT-1686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Saghy resolved FINERACT-1686. -- Resolution: Fixed > Auditor fix - Detached Auditor entity was not persisted during cascade > persisting > - > > Key: FINERACT-1686 > URL: https://issues.apache.org/jira/browse/FINERACT-1686 > Project: Apache Fineract > Issue Type: Bug >Reporter: Adam Saghy >Priority: Major > > While the AppUser (entity) was the auditor, the Spring JPA Auditing was not > working perfectly. When a detached entity was saved through assosication the > AppUser auditor was not set and it was null in the DB. > Example: > * Find Loan by id > * Create a new transaction > * Add the loan transaction to the Loan > * Save the Loan entity > Outcome: > * Loan transaction created by id was null > Solution > The AppUser entity was changed to be just the AppUser id. It is working just > fine now, and anyway the AppUser was never used and was unnecessary anyway to > be fetched. > Similar issue: > [https://stackoverflow.com/questions/38828189/spring-data-jpa-auditing-fails-when-persisting-detached-entity] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FINERACT-1686) Auditor fix - Detached Auditor entity was not persisted during cascade persisting
Adam Saghy created FINERACT-1686: Summary: Auditor fix - Detached Auditor entity was not persisted during cascade persisting Key: FINERACT-1686 URL: https://issues.apache.org/jira/browse/FINERACT-1686 Project: Apache Fineract Issue Type: Bug Reporter: Adam Saghy While the AppUser (entity) was the auditor, the Spring JPA Auditing was not working perfectly. When a detached entity was saved through assosication the AppUser auditor was not set and it was null in the DB. Example: * Find Loan by id * Create a new transaction * Add the loan transaction to the Loan * Save the Loan entity Outcome: * Loan transaction created by id was null Solution The AppUser entity was changed to be just the AppUser id. It is working just fine now, and anyway the AppUser was never used and was unnecessary anyway to be fetched. Similar issue: [https://stackoverflow.com/questions/38828189/spring-data-jpa-auditing-fails-when-persisting-detached-entity] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-1686) Auditor fix - Detached Auditor entity was not persisted during cascade persisting
[ https://issues.apache.org/jira/browse/FINERACT-1686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17577293#comment-17577293 ] Adam Saghy commented on FINERACT-1686: -- PR: https://github.com/apache/fineract/pull/2406 > Auditor fix - Detached Auditor entity was not persisted during cascade > persisting > - > > Key: FINERACT-1686 > URL: https://issues.apache.org/jira/browse/FINERACT-1686 > Project: Apache Fineract > Issue Type: Bug >Reporter: Adam Saghy >Priority: Major > > While the AppUser (entity) was the auditor, the Spring JPA Auditing was not > working perfectly. When a detached entity was saved through assosication the > AppUser auditor was not set and it was null in the DB. > Example: > * Find Loan by id > * Create a new transaction > * Add the loan transaction to the Loan > * Save the Loan entity > Outcome: > * Loan transaction created by id was null > Solution > The AppUser entity was changed to be just the AppUser id. It is working just > fine now, and anyway the AppUser was never used and was unnecessary anyway to > be fetched. > Similar issue: > [https://stackoverflow.com/questions/38828189/spring-data-jpa-auditing-fails-when-persisting-detached-entity] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-1685) Unhandled exceptions were not logged properly
[ https://issues.apache.org/jira/browse/FINERACT-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17577292#comment-17577292 ] Adam Saghy commented on FINERACT-1685: -- PR: https://github.com/apache/fineract/pull/2392/files > Unhandled exceptions were not logged properly > - > > Key: FINERACT-1685 > URL: https://issues.apache.org/jira/browse/FINERACT-1685 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Adam Saghy >Priority: Major > > There are undhandled exceptions which are not logged with details. Without > the proper logging it is hard to debug and monitor the application behaviour. > > *A.C.* > *-* Log unhandled exception on WARN level -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (FINERACT-1685) Unhandled exceptions were not logged properly
[ https://issues.apache.org/jira/browse/FINERACT-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Saghy reassigned FINERACT-1685: Assignee: Adam Saghy > Unhandled exceptions were not logged properly > - > > Key: FINERACT-1685 > URL: https://issues.apache.org/jira/browse/FINERACT-1685 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Adam Saghy >Assignee: Adam Saghy >Priority: Major > > There are undhandled exceptions which are not logged with details. Without > the proper logging it is hard to debug and monitor the application behaviour. > > *A.C.* > *-* Log unhandled exception on WARN level -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FINERACT-1685) Unhandled exceptions were not logged properly
Adam Saghy created FINERACT-1685: Summary: Unhandled exceptions were not logged properly Key: FINERACT-1685 URL: https://issues.apache.org/jira/browse/FINERACT-1685 Project: Apache Fineract Issue Type: Improvement Reporter: Adam Saghy There are undhandled exceptions which are not logged with details. Without the proper logging it is hard to debug and monitor the application behaviour. *A.C.* *-* Log unhandled exception on WARN level -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (FINERACT-1685) Unhandled exceptions were not logged properly
[ https://issues.apache.org/jira/browse/FINERACT-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Saghy resolved FINERACT-1685. -- Resolution: Fixed > Unhandled exceptions were not logged properly > - > > Key: FINERACT-1685 > URL: https://issues.apache.org/jira/browse/FINERACT-1685 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Adam Saghy >Assignee: Adam Saghy >Priority: Major > > There are undhandled exceptions which are not logged with details. Without > the proper logging it is hard to debug and monitor the application behaviour. > > *A.C.* > *-* Log unhandled exception on WARN level -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (FINERACT-1684) Introduce Business date concept
[ https://issues.apache.org/jira/browse/FINERACT-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Saghy resolved FINERACT-1684. -- Resolution: Fixed > 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 > 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 >
[jira] [Assigned] (FINERACT-1684) Introduce Business date concept
[ https://issues.apache.org/jira/browse/FINERACT-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Saghy reassigned FINERACT-1684: Assignee: Adam Saghy > 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 > 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
[jira] [Updated] (FINERACT-1684) Introduce Business date concept
[ https://issues.apache.org/jira/browse/FINERACT-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Saghy updated FINERACT-1684: - Description: 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
[jira] [Created] (FINERACT-1684) Introduce Business date concept
Adam Saghy created FINERACT-1684: Summary: 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 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. 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
[jira] [Updated] (FINERACT-1683) Webhook URL is not executed after a webhook is created and triggered
[ https://issues.apache.org/jira/browse/FINERACT-1683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davies Tobi Alex updated FINERACT-1683: --- Description: When webhooks is created and triggered, the hook url is not called. (was: When webhooks are triggered, the hook url is not called.) > Webhook URL is not executed after a webhook is created and triggered > > > Key: FINERACT-1683 > URL: https://issues.apache.org/jira/browse/FINERACT-1683 > Project: Apache Fineract > Issue Type: Bug > Components: System >Affects Versions: 1.6.0, 1.7.0 >Reporter: Davies Tobi Alex >Priority: Major > > When webhooks is created and triggered, the hook url is not called. -- This message was sent by Atlassian Jira (v8.20.10#820010)
