What is the reason for cloning dates

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.