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