You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@fineract.apache.org by Muthu Kumar <mu...@korconnection.com.INVALID> on 2023/06/26 12:51:47 UTC
FINERACT-1943 (Savings Transaction Search Extension)
Hello community,
I am currently working on a task (
https://issues.apache.org/jira/browse/FINERACT-1943) related to extending
the savings transaction search API with a new parameter called
"submittedOnDate." However, I would appreciate some insights from the
community regarding the following question:
Can someone please clarify the distinction between transactionDate,
createdDate, and submittedOnDate?
Here is my understanding so far:
*Transaction date:* This refers to the specific date when a financial
transaction occurs, such as making a payment, withdrawal, or deposit.
*Created date:* This signifies the date when the transaction information is
initially entered into the system.
*SubmittedOnDate:* Initially, I assumed that this was the same as the
created date. However, I would like to hear from the community on this
matter. If you could help me comprehend how the community utilizes the
submittedOnDate field, it would be greatly appreciated.
Please feel free to correct me if my understanding is wrong.
Thanks.
Regards,
Muthu
Re: FINERACT-1943 (Savings Transaction Search Extension)
Posted by Ádám Sághy <ad...@gmail.com>.
Hi Muthu,
Submitted on date is DATE only (no time part)! The creation date is a DATETIME.
I hope it helps!
Regards,
Adam
> On 3 Jul 2023, at 13:53, Muthu Kumar <mu...@korconnection.com> wrote:
>
> Hi Adam,
>
> Thank you for providing the detailed explanation.
>
> I appreciate the proposed approach, and I would like to seek clarification regarding the creation_date and submitted_on_date fields. Could you kindly confirm if both of them should be Date Time fields? In transaction-related scenarios, it is usually considered to use Date Time to capture precise timestamps of events. This approach enables us to maintain a more accurate record of activities, calculate durations, intervals, and ensure proper event sequencing.
>
> However, I must admit that I am currently unsure about the specific scenario. So it would be helpful if you could further clarify if we require the precise tenant timestamp(submitted_on_date) for the transactions?
>
> Thank you.
>
>
> On Fri, Jun 30, 2023 at 3:03 PM Ádám Sághy <adamsaghy@gmail.com <ma...@gmail.com>> wrote:
>> Hi Muthu,
>>
>> The problem: submitted on date of savings transaction is calculated from creation datetime which is tied to system timezone. I think it is wrong: it should have been tied to the tenant date / business date!
>>
>> I see 2 options to handle this:
>> • Introduce a new column: submitted_on_date (nullable) AND update this based on the creation_date so backward compatibility is there and I would change at backend side to fetch the value from this new column. After adding not-null constraint on the new column.
>> • Introduce new column: submitted_on_date do not update with any value (nullable) and the backend is fetching its value, if it is empty then calculate the submittedOnDate from the creation_date. Again backward compatibility is there, but all the queries and all other logic need to be enhanced to either take the value from the new column or if its null then take it from the creation_date column.
>>
>> The submitted_on_date column shall get the value of the actual business date (DateUtils.getBusinessDate()) which would either set the actual date based on the tenant timezone or it set the actual business date (if business date is enabled).
>>
>> The 2nd is not so nice, so I would prefer the 1st one.
>>
>> Muthu and fellow community members: what do you think?
>>
>> Regards,
>> Adam
>>
>>> On 26 Jun 2023, at 17:58, James Dailey <jamespdailey@gmail.com <ma...@gmail.com>> wrote:
>>>
>>> Muthu - thanks for bringing this to the list.
>>>
>>> I think it is useful to try to search for mention in our history, but in this case, it fails.
>>>
>>> Looking on the fineract listserv, I find that we have not discussed anything about savings accounts and SubmittedOnDate vs CreatedDate. There isn't much about this in tickets either. You may want to search more...but my guess is that the reasoning is lost in the pre-Fineract days. Somewhere on the mifos-developer work.
>>>
>>> more recently...from 2022, Adam laid out how business date and CreatedOnDate ...https://lists.apache.org/list?dev@fineract.apache.org:gte=1d:CreatedOnDate
>>>
>>> ...from 2017, this ticket was resolved with regard to SubmittedOnDate for loans.
>>> https://issues.apache.org/jira/browse/FINERACT-18?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel
>>> .... also
>>> https://issues.apache.org/jira/browse/FINERACT-1379?jql=project%20%3D%20FINERACT%20AND%20resolution%20%3D%20Unresolved%20AND%20text%20~%20%22submittedOnDate%22%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>>>
>>> So, from my recollection, we initially had a paper driven process, whereby a form would be filled out in the field, then brought back to the offices, whereby the data would be entered. The TransactionDate would be the date that the payment was made in the field, and the SubmittedDate would be the date that the event was recorded in the system. We "likely" used SubmittedDate because we wanted to separate out the concept from the system idea of CreatedOnDate. Thus, this was an early version of "businessDate" although only partially designed.
>>>
>>>
>>>
>>> On Mon, Jun 26, 2023 at 5:52 AM Muthu Kumar <mu...@korconnection.com.invalid> wrote:
>>> Hello community,
>>>
>>> I am currently working on a task (https://issues.apache.org/jira/browse/FINERACT-1943) related to extending the savings transaction search API with a new parameter called "submittedOnDate." However, I would appreciate some insights from the community regarding the following question:
>>>
>>> Can someone please clarify the distinction between transactionDate, createdDate, and submittedOnDate?
>>>
>>> Here is my understanding so far:
>>>
>>> Transaction date: This refers to the specific date when a financial transaction occurs, such as making a payment, withdrawal, or deposit.
>>> Created date: This signifies the date when the transaction information is initially entered into the system.
>>> SubmittedOnDate: Initially, I assumed that this was the same as the created date. However, I would like to hear from the community on this matter. If you could help me comprehend how the community utilizes the submittedOnDate field, it would be greatly appreciated.
>>>
>>> Please feel free to correct me if my understanding is wrong.
>>>
>>> Thanks.
>>>
>>> Regards,
>>> Muthu
>>
Re: FINERACT-1943 (Savings Transaction Search Extension)
Posted by Muthu Kumar <mu...@korconnection.com.INVALID>.
Hi Adam,
Thank you for providing the detailed explanation.
I appreciate the proposed approach, and I would like to seek clarification
regarding the *creation_date *and *submitted_on_date *fields. Could you
kindly confirm if both of them should be *Date Time* fields? In
transaction-related scenarios, it is usually considered to use *Date Time*
to capture precise timestamps of events. This approach enables us to
maintain a more accurate record of activities, calculate durations,
intervals, and ensure proper event sequencing.
However, I must admit that I am currently unsure about the specific
scenario. So it would be helpful if you could further clarify if we require
the precise tenant timestamp(submitted_on_date) for the transactions?
Thank you.
On Fri, Jun 30, 2023 at 3:03 PM Ádám Sághy <ad...@gmail.com> wrote:
> Hi Muthu,
>
> *The problem*: submitted on date of savings transaction is calculated
> from creation datetime which is tied to system timezone. I think it is
> wrong: it should have been tied to the tenant date / business date!
>
> I see 2 options to handle this:
> • Introduce a new column: *submitted_on_date* (nullable) AND update this
> based on the *creation_date* so backward compatibility is there and I
> would change at backend side to fetch the value from this new column. After
> adding not-null constraint on the new column.
> • Introduce new column: *submitted_on_date* do not update with any value
> (nullable) and the backend is fetching its value, if it is empty then
> calculate the *submittedOnDate* from the *creation_date*. Again backward
> compatibility is there, but all the queries and all other logic need to be
> enhanced to either take the value from the new column or if its null then
> take it from the creation_date column.
>
> The *submitted_on_date* column shall get the value of the actual business
> date (DateUtils.getBusinessDate()) which would either set the actual date
> based on the tenant timezone or it set the actual business date (if
> business date is enabled).
>
> The 2nd is not so nice, so I* would prefer the 1st one*.
>
> Muthu and fellow community members: what do you think?
>
> Regards,
> Adam
>
> On 26 Jun 2023, at 17:58, James Dailey <ja...@gmail.com> wrote:
>
> Muthu - thanks for bringing this to the list.
>
> I think it is useful to try to search for mention in our history, but in
> this case, it fails.
>
> Looking on the fineract listserv, I find that we have not discussed
> anything about savings accounts and SubmittedOnDate vs CreatedDate. There
> isn't much about this in tickets either. You may want to search more...but
> my guess is that the reasoning is lost in the pre-Fineract days. Somewhere
> on the mifos-developer work.
>
> more recently...from 2022, Adam laid out how business date and
> CreatedOnDate ...
> https://lists.apache.org/list?dev@fineract.apache.org:gte=1d:CreatedOnDate
>
> ...from 2017, this ticket was resolved with regard to SubmittedOnDate for
> loans.
>
> https://issues.apache.org/jira/browse/FINERACT-18?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel
> .... also
>
> https://issues.apache.org/jira/browse/FINERACT-1379?jql=project%20%3D%20FINERACT%20AND%20resolution%20%3D%20Unresolved%20AND%20text%20~%20%22submittedOnDate%22%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>
>
> So, from my recollection, we initially had a paper driven process, whereby
> a form would be filled out in the field, then brought back to the offices,
> whereby the data would be entered. The TransactionDate would be the date
> that the payment was made in the field, and the SubmittedDate would be the
> date that the event was recorded in the system. We "likely" used
> SubmittedDate because we wanted to separate out the concept from the system
> idea of CreatedOnDate. Thus, this was an early version of "businessDate"
> although only partially designed.
>
>
>
> On Mon, Jun 26, 2023 at 5:52 AM Muthu Kumar
> <mu...@korconnection.com.invalid> wrote:
> Hello community,
>
> I am currently working on a task (
> https://issues.apache.org/jira/browse/FINERACT-1943) related to extending
> the savings transaction search API with a new parameter called
> "submittedOnDate." However, I would appreciate some insights from the
> community regarding the following question:
>
> Can someone please clarify the distinction between transactionDate,
> createdDate, and submittedOnDate?
>
> Here is my understanding so far:
>
> Transaction date: This refers to the specific date when a financial
> transaction occurs, such as making a payment, withdrawal, or deposit.
> Created date: This signifies the date when the transaction information is
> initially entered into the system.
> SubmittedOnDate: Initially, I assumed that this was the same as the
> created date. However, I would like to hear from the community on this
> matter. If you could help me comprehend how the community utilizes the
> submittedOnDate field, it would be greatly appreciated.
>
> Please feel free to correct me if my understanding is wrong.
>
> Thanks.
>
> Regards,
> Muthu
>
>
>
Re: FINERACT-1943 (Savings Transaction Search Extension)
Posted by Ádám Sághy <ad...@gmail.com>.
Hi Muthu,
The problem: submitted on date of savings transaction is calculated from creation datetime which is tied to system timezone. I think it is wrong: it should have been tied to the tenant date / business date!
I see 2 options to handle this:
• Introduce a new column: submitted_on_date (nullable) AND update this based on the creation_date so backward compatibility is there and I would change at backend side to fetch the value from this new column. After adding not-null constraint on the new column.
• Introduce new column: submitted_on_date do not update with any value (nullable) and the backend is fetching its value, if it is empty then calculate the submittedOnDate from the creation_date. Again backward compatibility is there, but all the queries and all other logic need to be enhanced to either take the value from the new column or if its null then take it from the creation_date column.
The submitted_on_date column shall get the value of the actual business date (DateUtils.getBusinessDate()) which would either set the actual date based on the tenant timezone or it set the actual business date (if business date is enabled).
The 2nd is not so nice, so I would prefer the 1st one.
Muthu and fellow community members: what do you think?
Regards,
Adam
> On 26 Jun 2023, at 17:58, James Dailey <ja...@gmail.com> wrote:
>
> Muthu - thanks for bringing this to the list.
>
> I think it is useful to try to search for mention in our history, but in this case, it fails.
>
> Looking on the fineract listserv, I find that we have not discussed anything about savings accounts and SubmittedOnDate vs CreatedDate. There isn't much about this in tickets either. You may want to search more...but my guess is that the reasoning is lost in the pre-Fineract days. Somewhere on the mifos-developer work.
>
> more recently...from 2022, Adam laid out how business date and CreatedOnDate ...https://lists.apache.org/list?dev@fineract.apache.org:gte=1d:CreatedOnDate
>
> ...from 2017, this ticket was resolved with regard to SubmittedOnDate for loans.
> https://issues.apache.org/jira/browse/FINERACT-18?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel
> .... also
> https://issues.apache.org/jira/browse/FINERACT-1379?jql=project%20%3D%20FINERACT%20AND%20resolution%20%3D%20Unresolved%20AND%20text%20~%20%22submittedOnDate%22%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>
> So, from my recollection, we initially had a paper driven process, whereby a form would be filled out in the field, then brought back to the offices, whereby the data would be entered. The TransactionDate would be the date that the payment was made in the field, and the SubmittedDate would be the date that the event was recorded in the system. We "likely" used SubmittedDate because we wanted to separate out the concept from the system idea of CreatedOnDate. Thus, this was an early version of "businessDate" although only partially designed.
>
>
>
> On Mon, Jun 26, 2023 at 5:52 AM Muthu Kumar <mu...@korconnection.com.invalid> wrote:
> Hello community,
>
> I am currently working on a task (https://issues.apache.org/jira/browse/FINERACT-1943) related to extending the savings transaction search API with a new parameter called "submittedOnDate." However, I would appreciate some insights from the community regarding the following question:
>
> Can someone please clarify the distinction between transactionDate, createdDate, and submittedOnDate?
>
> Here is my understanding so far:
>
> Transaction date: This refers to the specific date when a financial transaction occurs, such as making a payment, withdrawal, or deposit.
> Created date: This signifies the date when the transaction information is initially entered into the system.
> SubmittedOnDate: Initially, I assumed that this was the same as the created date. However, I would like to hear from the community on this matter. If you could help me comprehend how the community utilizes the submittedOnDate field, it would be greatly appreciated.
>
> Please feel free to correct me if my understanding is wrong.
>
> Thanks.
>
> Regards,
> Muthu
Re: FINERACT-1943 (Savings Transaction Search Extension)
Posted by James Dailey <ja...@gmail.com>.
Muthu - thanks for bringing this to the list.
I think it is useful to try to search for mention in our history, but in
this case, it fails.
Looking on the fineract listserv, I find that we have not discussed
anything about savings accounts and SubmittedOnDate vs CreatedDate. There
isn't much about this in tickets either. You may want to search more...but
my guess is that the reasoning is lost in the pre-Fineract days. Somewhere
on the mifos-developer work.
more recently...from 2022, Adam laid out how business date and
CreatedOnDate ...
https://lists.apache.org/list?dev@fineract.apache.org:gte=1d:CreatedOnDate
...from 2017, this ticket was resolved with regard to SubmittedOnDate for
loans.
https://issues.apache.org/jira/browse/FINERACT-18?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel
.... also
https://issues.apache.org/jira/browse/FINERACT-1379?jql=project%20%3D%20FINERACT%20AND%20resolution%20%3D%20Unresolved%20AND%20text%20~%20%22submittedOnDate%22%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
So, from my recollection, we initially had a paper driven process, whereby
a form would be filled out in the field, then brought back to the offices,
whereby the data would be entered. The TransactionDate would be the date
that the payment was made in the field, and the SubmittedDate would be the
date that the event was recorded in the system. We "likely" used
SubmittedDate because we wanted to separate out the concept from the system
idea of CreatedOnDate. Thus, this was an early version of "businessDate"
although only partially designed.
On Mon, Jun 26, 2023 at 5:52 AM Muthu Kumar <mu...@korconnection.com.invalid>
wrote:
> Hello community,
>
> I am currently working on a task (
> https://issues.apache.org/jira/browse/FINERACT-1943) related to extending
> the savings transaction search API with a new parameter called
> "submittedOnDate." However, I would appreciate some insights from the
> community regarding the following question:
>
> Can someone please clarify the distinction between transactionDate,
> createdDate, and submittedOnDate?
>
> Here is my understanding so far:
>
> *Transaction date:* This refers to the specific date when a financial
> transaction occurs, such as making a payment, withdrawal, or deposit.
> *Created date:* This signifies the date when the transaction information
> is initially entered into the system.
> *SubmittedOnDate:* Initially, I assumed that this was the same as the
> created date. However, I would like to hear from the community on this
> matter. If you could help me comprehend how the community utilizes the
> submittedOnDate field, it would be greatly appreciated.
>
> Please feel free to correct me if my understanding is wrong.
>
> Thanks.
>
> Regards,
> Muthu
>