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 <jamespdai...@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
