I have searched the Forum and seen that there has been some discussions on this topic a couple of years ago, but I wanted to check the latest status and how other users are handling the situation.
If a Company changes its name, or moves to a new address, you can easily update this from settings. BUT you don’t want to change past records. They ought to have the information that was correct “at that time”. I noted that some users therefor created a new business with the new name, but in my view that is not optimal. The business is still the same legal entity, just with a new address (or a new name).
I feel that a good solution would be if it was possible to set a “start date” for any change of business details (name, address, logotype) and that this information will only affect records (invoices etc) which are dated after this “start date”. I note that this was proposed by some users earlier as well, but it seems like the discussion “died out”.
Is there any chance that such change could be implemented in the system?
How are other users handling this (quite common) situation in the current system?
I am putting this into the ideas category. But rather than “start date” I suggest terminology like “effective date.” “Start date” was previously used to mean something quite different. I also edited the subject.
Yes I agree, effective date is more appropriate.
Not sure how big problem this is. When business changes their address or contact details, I’d assume they want up-to-date details applied retrospectively everywhere.
If business is going to print something historic for customer or supplier, why would they want to display out-of-date contact details on it?
If the argument is that once invoice is issued, it should NEVER change then what if your bank details change? You do want new bank details to be shown on all unpaid invoices retrospectively. Why wouldn’t you?
What kind of information? Including bank details?
And if the answer is that… yeah, bank details should actually update across all invoices retrospectively, then we are no longer talking in absolute terms that “nothing should change”.
I’m not against the idea of having multiple business details and then business has a choice to either keep updating the first one (in case they want changes to be applied retrospectively) or you can create new one and then select new one on newly issued documents. This would have added flexibility in case business wants to simultaneously issue invoices across multiple trading names / business details.
I would disagree. See below.
Because, very often, the reason for reprinting a document is to resolve a dispute. Contract disputes might even include issues concerning where payments were supposed to be sent, what notifications were actually delivered, and so forth. Imagine providing a sales invoice in a legal proceeding with a business address the opposition can prove was not your place of business when you “supposedly” sent the invoice in question. That would cast doubt on the entire document or lead to accusations of falsification of evidence. Personally, I’ve always thought this was a potentially big problem for businesses that change address. The same is true when an entity changes its business name while legally remaining the same entity.
Everything should be fixed as at the date of issuance.
This would be great. But printing something with current business details that were not in effect when the document in question was created should require conscious action. The default should be fixed information.
Reprinting something from your accounting system cannot ever prove anything. It’s a system under your control, you can make it generate whatever you want to win dispute if it would be that simple.
If you need to re-print from accounting system, that would imply the receiving party doesn’t have a copy and simply requests new one. And new copy should contain up-to-date information for practical reasons. E.g. bank details on unpaid invoice should be current.
@Tut, realistically. You have a customer who has unpaid invoice and requests it again because they lost it and want to pay it. Your bank details have changed since the last time you issued the invoice. Are you telling me it’s desirable to send them invoice with out-of-date bank details?
I agree with Lubos here, the only change worth keeping track of is change in business identifier, however, this is better handled using a fresh business file.
However, I also see that both solutions put forward by @Tut & @Lubos are two faces of the same coin. However, the solution proposed by Lubos is valid across a wide range of use cases: multiple addresses, multiple trade names, change in address … etc
The only difference is that instead of chosing an effective date, just switch to the new address in form date and the History tab would reflect the date.
I hope that this is what @lubos has in mind when he said this:
The gist of this argument is that invoice must never change. To some businesses it appears to be important. I don’t understand it however we still need ability to define multiple business details in case business is trading under multiple names.
If this feature is used to make historical printed documents immutable, I have no problem with it even though I personally would not go that far.
This discussion is similar to recent “copy lines on transactions” where feature request was shot down because presented use-case was not valid to many even though there were many other use-cases for this feature that were clearly valid.
So there is no point discussing who is right or wrong on this use-case. It doesn’t matter because this feature needs to be implemented for other reasons regardless.
I see your point about tinkering with records, @lubos. I like the idea you have proposed. It would seem to address all desires and situations.
I agree with the need to know what was sent out to an external party. The fact it did or didn’t contain old or incorrect data is important to know. It is possible the history function in Manager could achieve this functionality.
In contrast if I was sending out a new copy then that should have errors and obsolete information corrected.