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 <adamsa...@gmail.com > <mailto: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 >>> <mailto: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 >>
