Currently, when a new transaction is created in Manager the current date automatically defaults into the date field in the transaction. This date can be changed manually. However, there are occasions when a series of transactions need to be created in Manager that occurred in the past & which need to be back-dated to the date they actually occurred.
An instance would be if a series of purchase/sales invoices & payments/receipts from them need to be created in Manager that occurred in the past (couldnât be created on the actual date because of unavoidable circumstances).
When creating an invoice the invoice date can be manually changed from the current date to the actual date that the transaction occurred in the past & the transaction can be saved. Then, when the receipt or payment transaction is created from the invoice the date now defaults back to the current date instead of retaining the date that was entered on the invoice.
Is it possible to create a âSession Dateâ check-box option in Manager that would allow a user to set a default date that the system would default to when a new transaction is created in any of the modules? Normally the date would default to the current date on a new transaction, but the âSession Dateâ check box could be checked & a date entered that would remain in effect for that session or that could be changed to a different one, as required. Closing the Manager application would cause the system to default back to the current date the next time it is launched.
Please do not divert topics with unrelated issues. Your post had nothing to do with report dates, which virtually guaranteed it would be ignored. It has been moved to a new topic.
Sorry for the error Tut. I am relatively new to the forum & donât know the ins & outs very well. I did a search on topics & so I added my post to the only topic I could find that had anything to do with dates.
Thanks,
Dale
You donât need a âsession dateâ function, you just need Manager to retain the date of the last transaction to be the date for the next transaction. So if you enter a transaction for 10/11/2018, the next transaction date is 10/11/2018 and not have it revert to 26/11/2018 being the current date. Then if you edit your next transaction to be 12/11/2018, then the next transaction displays 12/11/2018.
Hi Brucanna
Thanks for the reply. Yes, I agree that the date of the last transaction is retained when a new transaction is created in the same module but if you switch modules & enter a new transaction the date switches back to the current date. Actually where I would find the session date check box most valuable is when I create an Invoice transaction that occurred in the past in the Sales or Purchase module & then want to create a same-day receipt or payment by clicking the new New Receipt or New Payment button at the top of the invoice screen. When I do that the date on the newly created receipt or payment switches back to the current date. I canât count how many times I have had to go back into a receipt or payment transaction & correct the date (often not discovered until a month end reconciliation is performed). It seems like a small problem but can take a lot of time to find the transactions with the incorrect dates. I notice some other accounting software packages allow one to set a session date. Hoping this clarifies the concern & can make it onto the software improvement list.
@dmclain, I suspect that you and many others would experience just as many errors if your suggestion were implemented, and possibly more. With the current implementation, it is certainly possible to forget to put in the old date when making a late entry. But at least the behavior is consistent. Imagine how many times one might check a âsession dateâ option and forget to uncheck it. Then dozens or even hundreds of transactions might need to be corrected. The current approach is consistent, and research on interfaces clearly shows the advantage of consistency in training users and reducing errors.
I would like to agree with the OP on this topic. If the date is defaulted to the last entry date during a session (this assumes when you close and reopen manager it would default back to current date) it would make multi entry of past transaction quicker.
I donât agree with you Tut, for all users who only use the current date, it would be basically unchanged from current. Those affected would mostly be those who are adding transactions that occurred on past dates. The toggle could be located in the options menu for default fields, this would remove the random person who would otherwise not use the feature from forgetting.
I am going to make the assumption that the OP, like myself, update Manager on a weekly (or longer) basis rather than day to day. For my business, i use Manager to track much more than day to day finances. For the most part, Manager is only required to be updated monthly, but due to the amount of entries I update weekly.
For many, this is a non-issue as as been pointed out. For some it would be a great feature. I only hope the idea is reviewed by the programmers, even if they decide not to implement it. Hate to see ideas shot down just because some people or even most do things differently. We are not all carbon copies of one another.
A option to change the date value for the ânew paymentsâ screen seems usefull to me as well.
I imagine that a lot of accountants enter invoices and payments on a date other than the transaction date.
In practice this would mean when using the ânew paymentâ option for a purchase invoice to enter a cash payment the default would be the so called session date as OP puts it. Since it currently initializes to the current date it would mean that when used this has to be manually changed (in my case every time).
For banktransactions with a later date of payment you wouldnât need to use the ânew paymentâ way of entering a date since the payment date is included with the bank transaction.
If your only concern is having to re-enter dates that are not the current date, use the Clone function. After entering one transaction with the âsession date,â clone it. The date will be preserved. Editing the remaining information is the same amount of work as entering from scratch. And chances are good some information wonât require editing (like tax codes) and sometimes customers or suppliers or bank accounts. So it actually might be less work. It also does not have to be removed when done with the âsession dateâ. Just stop cloning.
Thanks for your reaction Tut. I can understand your POV in the sense that it might be more confusing if added everywhere. Plus the cloning option does the trick when working with a lot of payments.
The situation I meant is a very specific one:
- After entering a purchase invoice thereâs the button âNew Paymentâ in the âViewâ window for that purchase invoice.
- When clicked, the current date as well as the supplier, account, invoice and amount info is already prefilled (which is great).
- The only thing that I have to change every single time in that window is the date (to the date of the invoice).
I repeat the above steps per invoice (enter purchase invoice => add cash payment => repeat).
Since I only use this workflow when entering invoices and their cash payments it would be an improvement if the date is automatically set to the invoice date for this specific action.
@maarten, your scenario is a little bit unusual. Most users would bypass the purchase invoice if the payment is made on the date of the purchase. Why bother with the extra transaction?
I also think that setting a session date would be more work in the long run than it is worth. The only application it would have to your scenario is if you enter a group of purchase invoices that you know in advance all have the same issue date. You would have to navigate somewhere and set the session date. Then you would use it for a few purchase invoices and their payments. Then you would have to navigate back and cancel the session date. Then you would repeat for the next group of purchase invoices.
I was thinking more in terms of a option in the settings to apply the invoice date instead of the current date to payments when started from the invoice screen.
After pressing the ânew paymentâ button the date of the payment would be the same as the invoice it was called from.
But other than that your point of âMost users would bypass the purchase invoice if the payment is made on the date of the purchase.â is correct. This would only regard less than usual situations where a client sends the invoices sooner and separate from the list of cash payments.
Think about that, though. It would mean having to edit the date of every payment of a purchase invoice that was entered in a more conventional fashion, that is, some days after the purchase invoiceâs issue date. People forget what theyâve done in Settings, because those settings are meant to be things that donât change often.
How often are payments actually made the same date as a purchase invoice? For many users, seldom. I know some users follow the double-transaction approach (invoice/payment) unnecessarily because they want to track their history with a supplier. But even in those situations, entry of the two transactions usually occurs the same day. You are speaking of a scenario in which entry of both is delayed. I think that is an edge case.
I can understand that argument
Is it necessary to enter each sale separately - would just entering a Daily Sales total be good enough with the total by product? - one invoice, one cash receipt
Presumably you can check the details of the Sales history on the server