Need timestamp for transactions

1

@lubos i have previously addressed the issue of transactions in Manager not listed in the order they were entered.

below was your reply.

this issue has been giving a lot of headache recently where we have to crosscheck the data like in the bank transactions tab with the bank statement. checking a few transactions is okay but transactions over a period of time is really hard.

if i may suggest, please add an internal timestamp to the transactions captured from the user’s system clock (this would be applicable for desktop edition. cloud and server editions may use the server time). this timestamp need not be visible to the user.

the transactions shall be sorted in the order of date, timestamp, reference and then by amount.
the timestamp should be of the time the transaction is created in Manager and not when it is edited to update information. i can explain a few situations.

  1. a transaction entered on 9th May will retain the timestamp of its creation even if the transaction has been edited later and the transaction date remains the same.

  2. for the above, if the transaction is edited and the date is changed to a future date, then the timestamp will check the first record for the new date and add the timestamp prior to it.

  3. if the transaction is edited and the date is changed to a previous date, then the timestamp will check the last record for the new date and add a successive timestamp to it.

users who do not want Manager to automatically sort their edited transactions wrt the timestamp can simply delete and reenter the incorrect transaction.

having a timestamp will ensure all transactions appear in order of any third party list like a bank statement.

2

I have to differ with you on this, @sharpdrivetek. I can think of several reasons immediately why time stamps would be of little value:

  • There is no reason to believe a bank will process transactions in the order in which they occur. They come in from several sources, including cheques and multiple credit card processors. Some card transactions are posted immediately, others not for days, depending on the merchant’s degree of automation and contract with its processor. Some recipients hold cheques for days or weeks before presenting them. Transactions from the same bank process quicker than from corresponding banks.
  • Even supposing bank transactions are listed in the order they happened, there is little hope any user will enter them in exactly the same order. A group of transaction vouchers are handed in to accounting: no one knows the exact order in which they occurred. There is a real possibility they are sorted by paper size into a manageable stack and entered that way.
  • Why should a corrected transaction be assigned some time stamp based on other transactions unrelated to it if the date is changed?
  • Conversely, why should a time stamp remain the same if the date stays the same? What if that transaction was the last that actually occurred but was entered first?
  • What happens when a card transaction is pending at the bank and shows online, but is changed when final processing is completed? Some banks list by clearance date, some by original transaction date.

The result would possibly be a different sort order for transactions in Manager, not one that matched the bank statement necessarily. And not one that made any sense.

The idea Manager needs to match some third-party list makes no sense to me at all. Can you explain why you think this is important? Or why having a different sort order that still doesn’t match your bank’s would be any more helpful?

3

the transaction date and cleared date are different in Manager. the timestamp would be applicable to the transaction date, the date on which the transaction is entered. i do not believe any user would enter bank transactions in Manager without actually making one.

these are the users who should not be concerned about the timestamp. they would not care whatever order the transactions appear anyway. but for those who do care will be happy to have it.

because the timestamp is dependent on the date. i had clearly mentioned if the transaction date is edited.

because editing a transaction can be a correction of mistake made initially. just because the description in a transaction was edited for a typo does not have to change the time the transaction occurred.

i do not think there is a point to this question as Manager at present shows the transactions based on the transaction date and not the cleared date.
if there was a column that shows the cleared date and a timestamp applicable to the same, it would be an added advantage.

this is the situation where i believe showing the cleared date as a column would be beneficial. the user can sort the transactions according to the transaction date or the cleared date.

it is only your assumption that all users would have the same situations as you have pointed out. there are still many business like mine where we make all digital transactions. and all transactions happen in the order they have been scheduled to happen.

by the way i never mentioned this is just for the Bank Transactions.
if you make cash transactions, you will have the same difficulty when you have separate series reference for cash sales, cash purchases, etc.

for example, on a single day you enter the reference number for a cash sales as C100 and then later in the day a cash purchase as B100, Manager would list the cash purchase prior to the cash sales.

4

My point was not about users entering transactions. It was about banks posting them. Often, bank transactions are not initiated by the user. For example, firms authorized to make direct withdrawals do not always do so on the same day of the month, even when payments are due that way, because of weekends, holidays, etc. Yet a user might dutifully enter a regularly planned payment.

You contradict yourself with this statement. Yes, dependent on date, but not solely on date. Your suggestion would arbitrarily assign time stamps, not based on when transactions were entered, but on time stamps for previously entered, unrelated transactions—only because a transaction is being edited. Why should the edited transaction be placed before or after such other transactions?

True. But leaving a date unchanged is no guarantee the time stamp had anything to do with the moment of the transaction in the first place. Remember, your time stamps would be entirely fictitious attributes, not connected to the order or time of a transaction with the bank, but only with when they were entered into Manager. Thus, they would not reflect any real-world information about the transaction, only about when it was entered.

But that was not your suggestion and is unrelated to time stamps.

I make no assumptions about the situations others might experience. I only mentioned a few possibilities that came quickly to mind. But the paragraph quoted above, I believe, undermines your entire argument. If your business is fully digital and everything happens in the scheduled order, you have some hope of matching a bank statement with the order in Manager. Even that, though, depends on several factors related to bank processes. And if everything is “digital,” (which I assume includes entering your bank transactions by imported statements) how are you getting anything in different order in the first place? And what hope does any other type of business have?

I don’t want to argue about this, so I won’t respond to any further posts in this topic. I’ve made my points, so others are welcome to make theirs.

1 Like
5

i do not want to debate on the topic either. i really am not sure why you oppose to an idea which even if has the issues you mentioned, would not affect in any way the present workflow for users who are not concerned about the order of transactions list. atleast those who are concerned about the same would benefit from the same if implemented.

my only question would be whether it is okay for Manager to show a spend money transaction of say USD1000 when the account balance was zero listed prior to a receive money transaction of USD1000 just because both the transactions occurred on the same date.

the user would have entered the transactions in the correct order of occurrence.

other users are welcome to provide their own ideas.

1 Like