My accountant just picked up that I cloned an invoice from last year for this year as the information was identical, but I forgot to update the invoice date - for this year! Is there some reason why the date of the invoice is cloned as well because I never once used the issue date in the original invoice when cloning an invoice. I am always copying the rest of the information in the invoice.
We have now put a lock date on to prevent that from occurring again, which is a good idea, but does not address the reason why the invoice date is cloned in the first place. If there is any benefit to cloning the issue date, please state what this is, because I have never used the issue date in any cloning transaction whether it’s quotes, orders or invoices. I have always used today’s date for the new cloned transaction.
Your accountant may have just picked this up, but you have asked this question previously, and it has been explained at length several times in the forum. Here is a discussion you and I had on this very topic more than a year ago:
See also some other threads. The reasoning has not changed:
Other than talking about consistency, I still have not seen a user case (other than the below which is not really a common scenario for the vast majority of companies) -
I agree that consistency is important, but not when it results in errors like the one above and particularly as in the vast majority of cases with a cloned invoice, you want today’s date not the original invoice date. Your example is not a common scenario. The current status makes it too easy to make mistakes.
@dalacor, the current practices for cloning were introduced in response to frequent complaints from many other users about just what you are suggesting. Their arguments were that the old method increased both work and mistakes. Since the change, you are the only one who has complained. I would not harbor false hopes that the developer will reverse course.
No the original complaint was that there was inconsistency between the forms. For example on the receipts form, cloning would carry the dates, but on the payments form the date was not cloned. Or vice versa. There were many inconsistencies between different forms. This has now been fixed.
My issue (which is not just me by the way as I can point you to more than one post complaining about this), is completely unrelated in that I am not arguing about inconsistency, I asking about a specific field to not be cloned (exactly like invoice numbers are no longer cloned).
Please don’t rewrite history to pretend that users supported that the date be cloned. What users asked for at the time was consistency in the cloning process. However, I have yet to see any real world user case for cloning invoices dates as it’s pretty much the same concept as cloning invoice numbers and just results in errors like the above issue reported.
I’m not rewriting history, @dalacor. Here is the first example, six years ago, shortly after cloning was introduced, of someone who wanted the dates cloned:
Yes, part of that post had to do with consistency. But the request for cloning dates was explicit. I really do try hard not to make this stuff up.
I gave you one in one of the linked discussions. That is an extremely common situation, especially with larger customer organizations. And other users provided examples when they requested the change to the cloning approach. A very common one was monthly service contract invoices. Since Manager does not have the ability to generate sales invoices in bulk, users often clone a single invoice and change only the customer name. Once the customer list exceeds what can be prepared on a single day, the static date becomes a decided advantage. (They are cloning what is essentially a current, monthly invoice, not resurrecting something from weeks earlier.)
A forum search on this subject reveals you have been raising this topic over and over again since at least 2015. A repeated theme in your justifications for change is your claim that virtually everyone does things the same way you do. That just is not true. A large percentage of accounting records, if not most, are entered after the fact, when current dates would be just as error-prone as past dates. And, based on what you’ve said about your business, you deal with one customer and opportunity at a time. Many businesses deal repetitively with dozens or hundreds of simultaneous, identical customer transactions.
With respect, the program’s consistency did not produce the one error you began this thread with. The user did, by not editing the date on the cloned transaction. If your change had been in effect when the clone was made, but you had cloned the transaction one day later, you would have had a similar but opposite error. Your accountant probably would not have noticed it because it would have fallen into the current accounting period. But it would not have matched supporting documentation at audit time, and would have been just as wrong. The door swings both ways. And you are responsible for editing your cloned transactions.