Hi,
I like to propose an enhancement that will be useful to most including me especially.
To include the time of the transaction in all the transaction lists and printed document
Like below
None of our banks indicate time of transaction on payments and receipts. As we use bank statement imports and allocate the payments and receipts to the various accounts and reconcile we would have just an empty column.
Time is available in the history file. But what will you do when you enter transactions at the end if a day? Or only at the end of the month? You will end up with conflicting information.
Hi.Tut
Yes, it is in History, I couldn’t understand conflict at the end of a day or the end of a month.
I simply thought if it’s in the list it will be easy to handle things in a spreadsheet when the list is copied and pasted. We can find the time of the transaction and sort out certain things only with the spreadsheet
We are not in a position to copy the History and show it to everyone
Conflict will arise when, for example, you enter a transaction made on the 20th of the month on the 30th as you close out the books for the month. Now you have a transaction dated the 20th, but showing the 30th in your tab list and printed on a hard copy.
Maybe you enter all transactions instantly as they happen, but that would be highly unusual. Entries occur at the end of the day, or on weekends as users catch up, or monthly when they import bank statements, or even once a year when they take a shoebox full of documentation to their bookkeeper or accountant in preparation for tax filing. In each case, you would have conflicts built into your records.
Thank You for the thought, I was talking about real-time entering transactions.
As we do a lot of transactions every single day and are careful about conflicts in the dealings as many users enter the same type of transactions from different locations
It will be useful to us if implemented
@AMM those that do many transactions in a day such as restaurants and supermarkets are advised to use a POS system and use Manager for Accounting as it will soon become sluggish.
Mr. Eko please can you explain more on this?
Search the forum. Manager becomes slower the more transaction records it contains. Typical restaurant and super-market sales quickly add to this and Manager was designed for accounting not as a Point of Sales (POS) system. Therefore @Lubos and others advise to use a separate POS and enter daily summaries for accounting purposes in Manager.
I got it, thanks.
The Server and Cloud Versions of Manager are expected to be “geared” well and handle many transactions while still performing as expected. Large databases do affect performance but that is largely offset by the Server Host performance even in a multi user environment. In my view a time stamp if desired / needed is not a show stopper by should be a turn on turn off feature.
2 Likes
@compuit I can not find the post by @Lubos on this but also on server and cloud editions things become sluggish. If you have more than 2,000 transactions try to generate a General Ledger Transactions report or batch-update, etc. It may not even manage that or will take a long time or hang.
It indeed is not so much the power of a server or cloud or desktop installation because Manager and SQLite are pretty efficient. It is related to the way Manager and SQLite are being used on a local system. We use Manager Network edition on a VPS with 8 vCPU Cores, 60GB Ram and 200GB NVMe storage and I mostly use my 2022 Macbook pro with 64Gb Ram to access it. Normal operations do fine but some become slow as mentioned.
One solution @Lubos delivered was pagination so only a portion of data is being served into memory but when you select all thousands of records it is significantly slower. A large good working restaurant or shop will easily rack up thousands of receipts per year, hence the advise not to use Manager for large volume Sales (or Purchase) transactions.
eko At the risk of hi-Jacking this topic - I seem to recall something related to this. In a similar vein I suspect then that this is why the ability to search on recipient email address was removed from email tab / search function ages ago? There too we are looking at a massive record list. Yeah I did a General Ledger Transactions report and if I do not report on small date range chunks, Manager fails to produce a report / result and simply dies a “death” 
. Fortunately, The GL Transactions is not a report we generally pull.
There is no doubt the developer will be aware of this shortcoming and trust that it is addressed in a way offering some “fail safe” work around.