While making any Voucher Like (Sale, Purchase, Receipt, Inter Account Transfer…)
Date should be automatically picked by Software should be Last Generated Voucher
EG Today is 29/03/2023 but Last Voucher Generated on 27/03/2023
Date should be picked up by software should 27/03/2023
Thanks
What do you mean with voucher? Please use the terminology used in Manager. And it’s recommended to clarify your point by posting screen shots.
Also always indicate the edition and version of Manager, and the OS on which it is installed.
What is your justification for this request, @mihirdedhia? Why should the program choose various dates in the past if you are, for example, entering sales invoices, quotes, and payments in a single session? They will all almost certainly be wrong.
for a specific use-case, example Manager is used to encode backlog transactions from the past. Like my client, upon conversion to Manager decided to encode transactions from January 1, 2023. By that feature, you can save more time encoding contiously, instead of changing the current date everytime.
You can’t really appreciate that if you’re doing current transactions, but if you have a backlog, this is a nifty feature as default.
In some countries, the printed payment form is called “voucher”, that supports the actual cash or check payments.
In that situation, there is no way to know the date of the next transaction to be entered. It could be the same date as the last one, the next day, or the following day or month. You would still be editing a large portion of the entries.
Nope, if you have 50 transactions for let’s say January 5, 2023, you will be saving time if the system goes back to January 5, 2023 after every posting of transaction. Let’s consider the other side of the coin @Tut , if this will be default setting of the system, it doesn’t matter even you’re recording the current transaction, right? It just benefit those encoding post-dated or backlogged transactions.
For such cases why not use the Clone function? The date will remain the same for each new entry like January 5, 2023.
@eko is right, and I was going to suggest that, but decided not to clutter my response unless you provided further information, as you now have.
Cloning keeps the old date. Copying inserts today’s date. Neither will always be correct for the unusual situation of manually entering historical transactions. But Manager is not designed for that. It provides starting balance capability so you do not have to undertake such tedious efforts when migrating from another accounting system.
When you are entering such a body of historical data, you can use a combination of cloning and copying to avoid re-entering full transaction information. All transactions from one date could be cloned, then edited for customer/supplier/etc. and line items. (All that information would have to entered for each transaction anyway.)
Or you could clone and/or copy all transactions involving the same payers/payees to reduce the amount of editing.
The bottom line, @Christopher_Esmeres, is that you are suggesting a change to default behavior of the program that would benefit very few users who have already decided to bypass migration features built into the program at considerable effort. And it might make things more confusing and difficult. What happens when you reach the end of your 50 transactions for January 5th? Your next entry would enter January 5th and would be wrong. Would your data entry person notice or have been lulled into complacency by the previous 50 entries? You would still need to check and confirm every entry. Then, when all historical information was in the database, every new entry would be wrong.
This was actually worked out years ago with extensive input from forum members as the cloning and copying functions were being added. Since then, you are the first person who has complained. I have taken that as indication that the current design meets the needs of the vast majority of users.
@Tut i never complained, we suggested, this is a healthy discussion. You should understand where some of us coming from, as for me, i have been an Accounting Information System practitioner for the last 20 years, we never complained to MYOB, XERO, Quickbooks, Peacthree or SAP before. We suggested. We should be open to ideas.
Well, Quickbooks for one is doing what @mihirdedhia mentioned. The default settings is the last date of entry. We can’t always assume that the vast majority likes the current settings unless we make a poll here and let’s see. We are willing to adopt to the best practices around the world. My accounting firm is open for new best practice. That’s why we are here, to be part of this great development that all of us could benefit in the future. We are not the big bully providers that don’t listen to end-users, are we?
yes currently i’m doing this.
The Manager development team assumes current date as the logical default for realtime transaction recording. In actual fact, a large number of transactions are recorded at a later date than that of the particular source document. While it is frustrating to catch up on the source doc date for each and every item, a change in the program would require that source documents for (say) purchase invoices will have to be manually sorted in date sequence, before attempting the data capture.
In my environment it would be “nice” to at least set a default for the particular month for which a “back log” of source documents exist.
I also agree that at least a particular user is to be able to make a specific date a default one unless he changes - this makes more time saving as well as minimizes data entry errors by bookkeeper entry past transactions. We encounter such cases with those who used Qbooks which has somewhat temporary date defaulting.
Your query is vague. Why would the date for a transaction done today (10/4/23) be pre dated back to 8/4/23 if that was the date of the last voucher created?
It does not work that way. Unless you want to manually enter a purchase invoice or a payment receipt received on that date, then it is not legally permissible.
This makes no sense at all. There is no reason for any existing data to be sorted before entering new transactions. The date of a transaction in Manager should be the date it occurred.
Why? Just because you have a backlog does not mean all those transactions should be entered on the same date in the past. Each of them should be entered with the date the transaction happened, no matter how late you are in making entries. This is what allows you to create a correct chronological sequence of events and create reports for time period regardless of how backlogged you may be entering data.
Reasoning: the system defaults to present dates for transaction entry. If you have a backlog (many small businesses fall in a category of enforced backlog) you have to navigate from present back to a couple of months earlier and then have to pick up the day.
Any business that has to regularly go back a couple of months to select a date for an accounting transaction is not being managed properly.
How can you possibly have an idea of your revenues, costs and profit levels if you are month’s behind in your accounting entries?
mr @Joe91, there are cases where back-dated transactions need to be recorded. As an accountant or a buzz consultant, some times I have new clients who need their accounts to be moved from manual books to Manager - these clients have their accounts closed - e.g. Dec 31-2022. Now what we gonna do is to Setup their financials in two ways:
@Burhania, that is a poor justification, because there is no reason for the default condition to suppose one transaction’s date will be the same as a previously entered transaction’s date. That statement holds true regardless of whether you are entering current or ancient transactions.
As a user and Fan of Manager.io, I never expected to experience such an aggressive reaction/answer. However, I still assume that the Forum is positive and Idea/wishlist-sharing platform where all Manager.io users will have their own suggestions for likely improvements - anyone has the right to oppose an idea politely.
On the other hand, as a QuickBooks, Sage/Peachtree & DacEasy consultant/trainer since 2002, I believe I have more ideas and Insights to share with as other users in the forum - Suggestion is for us; Implementation is for the Developer.