I just cloned an invoice as I made an identical purchase today as I did last week. I discovered that the cloned invoice does not use today’s date! Should this be the case as I cannot see the logic of using the date of the original invoice?
You could argue this either way: keep the original date so that you have, literally, cloned the transaction, or default to today’s date for, possibly, greater convenience. Either way, some transactions will probably be entered via cloning that are for neither date. So I’m not sure it matters a lot.
However, consistency might be a good idea. When you clone bank/cash receipts and payments and sales invoices, you automatically get the old date. But when you clone an expense claim, you get today’s date. Those are the only modules I use with the clone feature, so there may be other inconsistencies. I wonder if @lubos has some underlying scheme in mind or if these are just small “features” of the software.
Consistency would be a good start. However, I would be in favour of cloning to default to today’s date as I can’t think of any occasion when one would want to use another date and even if that were the case, the user would still have to specify that date. Thus setting to default to today’s date would make more sense as odds are the user wants to use today’s date! But consistency would be helpful which is why I suggested today’s date when you create a new invoice it uses today’s date so logically a cloned invoice would do the same.
Some people create the same invoice for multiple customers at the same time so cloning while preserving issue date is useful.
It’s true you can argue either way and this is the reason for inconsistency at the moment.
I guess one way to solve it is to make
Clone button work the way so the issue date is preserved. Then
Copy to... button perhaps wouldn’t preserve issue date. This way there could be consistency and both ways of cloning/copying would be supported.
I suppose it would depend on whether people want the original issue date to be preserved. I personally cannot see any reason why anyone would want the original issue date, but if people do want the original issue date, then its not a problem to keep it that way. I would have assumed that most people would want to use todays date when cloning invoices etc as generally speaking people doing accounting are usually working with todays date - I would assume. Anyway, its up to you how you want to handle that.
I am pretty flexible on this but would prefer on the aspect of cloning “Sales Invoices” that the issue date of the cloned invoice to be the current date (the date the clone was created) and then the due date of the cloned invoice to reflect the company policy due date of say the 20th of the following month. My reasoning for this is that it would eliminate the checking the invoice numbers when cloning say month or two month old invoices reducing chance of error. I have fallen into this trap when processing in a hurry.
I agree. This is my thinking as well.
@compuit’s point is a good one. I like @lubos’s idea that invoices would Clone with original issue and due dates, so they were literally exact duplicates. But Copy to would adopt today’s date and default due date.
That way, when creating multiple invoices for same things at same time, all you would do is Clone and change the customer/supplier. But if you were creating an invoice for same thing you bought/sold previously, you could Copy to and automatically get current dates.
Unless I’m overlooking something, the exact same convention should work for sales invoices, purchase invoices, quotes, sales orders, journal entries…anywhere the Clone or Copy to buttons now appear. New options in dropdown Copy to boxes may be required. For example, in
Sales Invoices, the only current option is New Recurring Sales Invoice. Something like New Standard Sales Invoice should be added.