That is exactly the problem. The bank’s timeline depends on when cheques were presented, how they were shuffled by the processor, bank practices on exploiting the “float” so they can loan your money to others before you make a demand on it, policies about transactions coming through other banks’ ATMs, and so on. You—and there Manager—simply cannot know these things.
Take your own example. Suppose Alice’s loan to Bob is in the form of a $100 cheque, which Bob deposits at an ATM. Bob now thinks he has $100. But the ATM actually belonged to another bank system. Under their agreement, the bank owning the ATM uses the money for 24 hours before transferring it to Bob’s bank. And, under the terms of service for Bob’s account, his bank does not put the $100 into Bob’s account for another 24 hours. Meanwhile, Bob wrote a cheque to the utility company for $50, which is deposited immediately. And, because the utility company is a big customer, Bob’s bank posts that transaction the same day. So Bob is technically overdrawn, even though his records in Manager never showed a negative balance. Meanwhile, just after depositing Alice’s cheque, Bob also had a cash customer who bought $200 worth of merchandise. So he walked next door and handed Alice $100 to repay the loan. Alice is happy, but Bob is sad. And differences in how Manager sorts transactions recorded for the first day of this story would not save him from being overdrawn.
I totally agree. This is a pretty complex transaccion scheme which may cause transaction oder sliding in almost any accounting software unless “Deposit” and “Clearing” dates with, maybe, respective hours will be specified and used by software to build an effective transaction timeline.
I’m one on those users who will enter every possible details to transaction, even hour, minute and second if it’s possible, as same as add every related document, like payment tiket or something similar. To make inter-account transfers and payment/receipts be in chronological order I applied reference ID scheme “YYYYMMDDHHMM”, for instance 202101222003 (on my local time right now), so transactions are sorted correctly if there was more than one per specific date. Thank you again for your feedback
I had assumed the majority of user who use sales invoices or receipts do use Manager as a point of sale system, so do enter data into Manager in real time.
For them a low running total would correspond to low real cash in a cash account / physical till.
Manager does now have time stapes on transactions as part of the history functionality so can reliably display transactions in time/ date entered within each transaction day.
So in my opinion time entered is the most meaningful default order (others accessible via normal sort options).
However as an alternative scheme has now been implemented I believe further discussion is very unlikely to be reflected in Manager code.