BUG? `Account` under `Invoices` keeps links to old accounts

BUG? Account under Invoices keeps links to old accounts… when changing an invoice item to a non-inventory item

Sorry for the ambiguous name, let me explain by way of example:

When attempting to delete a COA account type, I found I could not delete it because it was still referenced within manager, although it was not visible in any invoice I could find. It turns out it was referenced by an invoice where a line item had been later edited to become a non-inventory item type where the associated COA had been changed (I did want to change the COA). However, the underlying COA Account was still linked, even though it did not appear on the invoice.

###Create some expense accounts in COA

###Create a non-inventory item and associate it to a different COA:

###Here they are in the summary tab

##Start using it
###Create a purchase invoice

###Lock it in

###Check summary tab

###Go back and edit the invoice, make it a non-inventory item

^^^ the above has a wrong price because it’s updated from the non-inventory item price. This is not relevant, I just made it a different price by mistake.

###So correct the price :slight_smile:

###Check the summary tab again

^^^ The invoiced items appear in the correct account.

###clicking on the “nil cost” against AAAAAA (the little - at the end) shows that no expenses exist

###Let’s try and delete the COA account

^^^ It shows us an invoice where AAAAAA is used, so let’s go and delete that line item

###Open it, but there is no AAAAAA, only AABBBB
The reason I could not find this originally is my invoices have 20+ items in it and I’d forgotten I had changed an invoice item from a normal item to a non-inventory item.

###Remove the non-inventory item code and the old COA Account re-appears.

###Delete the Account

###Re-apply the non-inventory item type

###and update

This is so much easier to find now because of the way @lubos has implemented a cross-check to find any remaining references. Back when I created these accounts, this reference finding tool didn’t exist.

I’m not sure if it’s a bug that the old account is linked behind the scenes. I can see a use case for it being there (like when you remove the item type making it not a non-inventory item anymore. It can revert to the old account. It’s possibly though that if yo made it a non-inventory item then you would want it associated with that account and making it NOT a non-inventory item anymore doesn’t necessarily mean you want to revert to the old account.

I would think that most people would not be changing accounts often, it’s just that back at the time I was refining where things should be for me, and so I did change it.

Anyway, that’s my story of how I cleaned out some old COA accounts I wanted to delete a long time ago.


@d3mad, I think you deserve an award for what must be the longest post (at least with images) ever. :trophy:

I think the behavior you’ve described is a byproduct of a couple design philosophies:

  • You’ve noticed how changing from the strict definition of a non-inventory item doesn’t delete or overwrite most existing information. That’s because non-inventory items are shortcuts, not actual subsidiary ledgers like inventory items. So the program is perfectly happy for you to have information about them that contradicts what you set up for the non-inventory item. Changing some portions of a line item created with a non-inventory item leaves the rest unscathed.

  • Manager hates Suspense. So if it can remember anything that will avoid plunking an entry into that account, it will. In your case, the AABBBB account was part of a shortcut. When you got rid of it, AAAAAA was handy, so it used it. Manager is, at heart, a browser. That’s why the back button works. And in this case, that memory supplied the AAAAAA account.

So…bug? I don’t really think so, though I don’t really know how the memories of things past are implemented. Perplexing? Definitely. And you’ve uncovered a troubleshooting trick that might be useful for others in the future.

Put on guide category lol, instead bug

Well, it only appears a long post because of the images. Take them out it’s only a doxen lines or more.:stuck_out_tongue:

One of the reasons I posted it was BECAUSE it took so long to get rid of it. and the fact I uncovered it in a way that isn’t intuitive at the “screen” level (ehich I still feel in some way, is a lol, errr bug)

Personally I believe if you activate a non-inventory category (which has an account attached to it), then the line item of the invoice needs to be attached to that account at all levels (past and present) because in so choosing such a “shortcut” you are changing the account you would like to assign it to. In no world would you want to assign it to two accounts. So delete the history, attach it to the shortcut as that is where the user really wants to assign it. < $0.02c

Knowing that it really doesn’t matter, the emphasis of the post/thread was to bring it to everyone’s attention. Many months ago I spent DAYS trying to delete that chart of account. Thankfully, it’s easier to do now because of where the package has progressed.

It might still not be obvious to some in some situations.

I have no disagreement with your point of view. My comments were about why it probably is the way it is. I suspect, however, that changing it would likely mean revamping the entire underlying concept of what non-inventory items are. I doubt that will happen; nor should it necessarily. I often insert a non-inventory item as a way saving time, knowing full well I will change it. Then again, I’ve never had a non-inventory item involved with revamping how I use my chart of accounts after the fact, as you described.

As you say, the recent addition of pointers to references that prevent account (or other) deletions is very useful. Whether this constitutes a bug will be for @lubos to determine.

I could not a agree more. I did a little happy dance when it appeared on the screen :slight_smile:

Well, I’m not in need to revamp the chart of accounts currently, So, I didn’t know about it. Maybe I might in the same situation as @d3mad later. I bookmark your topic just in case.