UX: Consistency of Entity vs Account

[ehuelsmann]

In various parts of the system, terms are being used interchangeably (while they are not): "Entity Control Code", "Customer Number", "Meta number" and "Account number".

This issue has been filed to log all cases where our UI is inconsistent with respect to these. (Reference to documentation to be added.)

The following steps need to be taken (at least) to create a consistent UI:

• [ ] Rename "Customer number"/"Vendor number" in search screens to "Entity number"
• [ ] Add "Customer account number"/"Vendor account number" to search screens which already have "Customer/Vendor number"
• [ ] Add "Role" column to contact search which lists the role of the entity credit account being included
• [x] Remove "Class" from entity record (it only serves to confuse, after all) (#8097)
• [ ] Add "Account number" to AR/AP search results (so as to make clear which account the invoice is for)
• [ ] In the AR customer/AP vendor selection dropdown, add visibility of the account (now only the customer/vendor, which means customers/vendors with multiple accounts get listed multiple times without visible differentiation)
• [ ] In the Order/Quotation customer/vendor selection dropdown, add visibility of the account (now only the customer/vendor, which means customers/vendors with multiple accounts get listed multiple times without visible differentiation)
• [ ] In the customer/vendor search for payments/receipts, add the ECA description (and customer number and customer account number) -- currently, there's only the entity name
• [ ] Add "Counterparty account" to "Template Transactions" view

Very much related to #5825

[0rir]

How often do you look up vendors and customers in one search and why?

My first impression of the entity/company/person/eca/contact SQL was that it was dictated more by meeting a normalization level than modelling business usage.

I accept that my own experience may be somewhat limited, but Customer Relation Management is not abbreviated ERM because the underlying business entity is not the normal focus of business. The _entity_credit_account where entityclass = 2 is lsmb's best representation of the business concept of customer. The concepts of entity and eca should be confined to users' accounting roles; all other personnel should just be seeing customers and vendors. (Accounting is the stand-in for the legal personnel.)

[ehuelsmann]

@rakool hi. I don't look up vendors and customers in one search at all; however, I just Search contacts without restricting the class, meaning that I actually get both vendors and customers. But: when you don't create an ECA, you get entities without a role. I think it's important to communicate that fact to the user. Currently, a user doesn't get any feedback that the entity he/she created isn't actually a customer.

[einhverfr]

I wonder if we are standardizing these, if we should move from "Entity" to "Counterparty" and from ECA to Counterparty Account

[0rir]

@einhverfr In American English there is no good term in common parlance. For "Entity", "Legal Entity" is correct and is provides enough context to look up quickly.

"Counterparty" is not common either but I find it intuitive; I don't always fit the curve but count one data point. I would think something that expresses the duality of "AR/AP account" or "Customer/Vendor" would good. But having those separate would be better.

[freelock]

Yay! Bikeshedding!

We did throw around a few alternatives in chat... I'd be in favor of moving away from Entity as that feels like a base class that a bunch of other stuff should extend (but maybe that's just because I spend so much time in Drupal!)

Organization? Business? Company? I can see "Legal Entity" as clarifying this too... maybe we should set up a quick poll to get a sense for which terms the community likes?

For ECA, that level seems to have several different types already -- customer, vendor, employee, user at a minimum. And you would rarely want to search across those, at least if your data is sane... Although "user" seems more like a trait that could be applied to any of those, if we were to allow them to authenticate in the system.

We were discussing "Person" for this level, but you would want to treat employees differently than customers here -- the specific contact at a customer might change repeatedly but you would never want to mix data across different employees... maybe that's as far as we can go? Customer, Vendor, Employee, all mapped to different classes of credit accounts under the hood. but use those terms in the UI?

[0rir]

As is said, "Friend @freelock speaks my mind." Right down to the implied doubts about 'organization', 'business' and 'company' which all have some merit but get cumbersome or confusing when labeling all of 'entity', 'company', 'person', and 'entity_credit_account'.

[nick-prater]

I may be a lone voice that actually likes 'Entity'.

The entity can be a natural person, or a legal entity. 'Organization' doesn't work in the case of a natural person, 'Person' doesn't work for a legal entity.

Chris's idea of 'Counterparty' works, but I find it more cumbersome and less clear than 'Entity'.

It will be a fabulous bike shed :)

Nick

[0rir]

I understand 'legal entity' to embrace all beings that have rights at law, personae ficta or natural persons.

I also don't mind 'entity'. It gave me the same moment of doubt I would get from company being over organization and person. I am critical of it for being obscure to others.

[einhverfr]

To what extent do we need to start with a glossary?

Basically if we start by having a glossary, we can then look at the definitions we have and how they relate and discuss changes.

[0rir]

@einhverfr, I think you have a good idea. The modifying and solidifying of the words that are the structure that is lsmb is something I hope to witness and perhaps something in which to participate.

Entities, their accounts and structures are core elements of lsmb. This is not bikeshedding.

I don't see your idea has specifically a user documentation glossary so I don't want to stray further from the narrower UI topic here.

[neilt]

An updated glossary exists in the book which we've started updating after this issue was created. Unfortunately, while trying to reference it I found out it is not being generated correctly in either the full book or split book html. However, you can see the current glossary by going to https://book.ledgersmb.org/dev/full-book/#A9.S2 and scrolling past the legal stuff. The glossary is also in the PDF. I am happy to make any additions necessary.