This also changes the name on the already send invoices. So when i legally change the name of the company all the invoices in the past are changed also, this can’t be right. The name on the already issued invoices should remain the same.
If you are legally changing the name of a business then in effect you are starting a new business.
Therefore you should backup the business as at the close of the old business to preserve those records as is and then you have two options:
- Import that Business and do the name changes, this way you have the history of the old business combined with the activity of the new business.
- Start a new business with opening balances from the old business’s closing balances.
If you are changing the businesses entity type, unincorporated to incorporated, you only have the choice of option 2.
Either way, you end up with two businesses listed on the Manager’s opening screen.
Hello @Brucanna i understand your workaround but the information on submitted invoices shouldn’t change. I checked and the other business information (f.i. the adres) also changes. So when moving to another location all the invoices wil be rewritten. The proper way would be to make the business information a part of the invoice and not to include it as a variable.
It wasn’t a workaround, in both cases a new business was created which is a minimum requirement, it was just that one included the previous business history for “reference” purposes only. That history can be completely eliminated for reporting purposes.
The proper way “when I legally change the name of the company” is to start a completely new business. The legal obligations of the previous business have absolutely nothing to do with the legal obligations of the new business.
The only reason that you have the previous business’s transactions there at all is for your own convenience of seeing transaction history, but that history doesn’t belong to the new business entity.
Changing a name is in effect closing down one business and starting up a new business.
The same process applies with having the same business name but a new location, backup as of closing / shifting date and open a new business for the new location…
1 Like
In Holland for small company’s you can change the name and all the legal obligations, IRS etc. remain totally the same. You can also add trading names which you can use.
Do i also have the start a new administration when i change e.g. my email adres or bankaccount. This solution sounds to me as a kind of workaround.
Off course you can do it the way as you describe but you shouldn’t change issued invoices. This only makes things more complicated. If the company information is a part of an invoice (and for @lubos is this very easy to do) and not included as a variable the invoice would always be correct and would’t change when company information is changed.
I’ve moved posts related to this question to a new topic and put it in the ideas category.
My opinion matches @Frankie’s. Businesses change addresses all the time, and it is poor practice to have all prior transactions reflect a new address that was not the place of business at the time of the transaction.
Likewise, legally changing a business’ trade name (known in some locations as a “doing business as” name) is not the same as closing the business and starting a new one. Even corporations change their names without becoming new enterprises under the law. For example, International Business Machines became IBM, Apple Computer became Apple, but both were the same legal entities before and after the name changes. A law firm, Higgins Copperfield, might take on a new partner and become Higgins Copperfield Smith, maintaining its status as the same partnership because its original partnership agreement included provisions for addition of partners.
Once a transaction has been entered, it should not be changed by subsequent alteration of business details. Any such change should require conscious editing.
2 Likes
Get your balances down.
Make a backup of the old company.
Start a new company with the balances.
Set up new business details.
Easy
not as easy as setting a Lock Date which would prevent any change to the data (not the transactions alone) prior to the date.
You have to recreate your custom fields and when you want to lookup something you have to search in separate files. When the IRS wants the check you company you have to present them different files (that looks professional).
I have another solution, just hard-code the business info in a custom invoice template. When info changes just copy the template (theme) and adjust the info.
And al this hassle just because the company info is not included in the invoice dbase, seriously…
What is wrong with that?
Let see if Lubos can solve this by enabling a freeze feature that will make your request available.
The solution i provided above is the one that you can have now.
I’m reluctant to make business details part of every document as @Frankie suggests. It would just make every form more cluttered right of the bat.
Perhaps this is best to be solved with custom themes. Rather than having business information under Settings, business information could be part of the theme.
If you are changing trading name and it is undesirable to rename business name on prior documents, you just create new theme and “archive” the old one.
This would also solve the issue where businesses trade under multiple trading names, so they have multiple trading themes side-by-side.
Of course, themes will need to evolve a bit so users are not exposed to HTML for this basic functionality. Thoughts?
Are you saying that the input (create) screen would also have to display the business details, which is the added clutter ?
So the “View” screen is not a captured document as such where the business details could be “locked”, but a pull together of various elements ?
For the simple business detail changes and for the non-technical user, what if Setting > Business Details had a “Add New Details” where an additional set of business details could be added with a “starting date”. Then documents based on their date could select the appropriate business details.
Yeah, that’s the principle I go by. If information is preserved on document-level, it should be exposed when editing the document so you have a chance to change it.
Yeah, keeping business details under Business Details is more intuitive. So the best solution is to allow to have users create multiple trading names under Business Details and if you have multiple, then every form would have an option to select which one you want applicable for given document. Most users wouldn’t see this option on forms since they would have just one trading identity.
My belief has always been that it was wrong for business detail modifications to retroactively change prior transactions. My reasons were explained in post #6 above.
At the same time, I’ve always understood that a viewed document is only a representation of data from a combination of sources. Some is universal, such as the business details. Some is specific to a transaction’s record in the database, such as dates, line item information, and custom field content. So I’ve always realized that the documents we view are not fixed things.
I would generally support @Brucanna’s suggestion on the ability to add new business details with a start date. But @lubos’s idea of having multiple sets of business details that are selectable is even more powerful. Of course, you would want to be able to set a matching group of business details as form defaults, too, without having to individually set (and make mistakes on) trading name, address, bank numbers, etc. In other words, enter the details correctly once and choose the ensemble.
On a purely mechanical note, it would be necessary to be able to name the sets with something besides the trading name itself. If you changed addresses, for example, but not the trading name, you would not want to be choosing from a dropdown menu showing Northwind Traders and Northwind Traders. Better to choose between Northwind 1st Avenue and Northwind Pacific Boulevard, then have the exact data appear on documents.
The longer you think about this, the more attractive the idea gets. Bank transfer numbers change, phone numbers and email domains change, etc., all without altering the legal identity of the business.
i would defer from the idea of making business details a part of the theme.
we cannot expect a user to build a custom theme with changes only made to the business details. they may or may not modify other parts of the theme as they find necessary. and these modified codes are not guaranteed to work after every Manager update.
so suppose a user who had archived an old theme with their previous business details wants to check their year old data, Manager which has been updated would promptly show an error because the variables used in the custom theme then is not valid anymore.
I did not address the subject in my earlier posts, but I strongly agree with @sharpdrivetek. A user should not have to write a custom theme to change something as mundane as a business address. I didn’t mention this because @lubos seemed to abandon the notion when he said “…keeping business details under Business Details is more intuitive….”
Any changes to Manager regarding this idea so far?
news?
No.
Agree, this is an efficient way of generating documents and is appropriate. For reports having them remain dynamic is generally optimal
Agree.
In fact in may jurisdictions a record of tax related transactions is required to be kept for 5 to 7 years.
Actually I believe it is valuable to keep a record of everything which is sent to any external source, both for official requirements and also should a third party question what I have sent to them. So imo it also applies things such as payslips, quotes, and tax reports submitted to tax office.
How I currently achieve this for important documents is to save a pdf copy and attach it to the relevant page. This process could be automated and generalise to achieve this threads requirements. For example, Manager could have an option to attach a pdf copy of a document, named “Emailed” and the current date or "Printed and the current date, whenever it is sent (which depending on a users work flow may typically occur when it is emailed, printed , saved as pdf [so this may need to be a configurable option]).
Again how this thread’s aims are achieved isn’t important to me, but I do value have a record of what I have actually sent to another person or organisation, even when the old document is now obsolete or wrong.