[V13] [Breaking changes] Proposal for cleaning up naming

9

I would also argue that the following 2
contact => profile
HR => People.

are debatable.

From Google and Apple we know well what contact entails. Profile is more related to user.
I undertand that in many big organizations there is a switch from HR to People services or related semantic.

2 Likes
10

My opinions:

Change

  • Item: “Keep inventory” in lieu of “Maintain Stock” (If Stock is changed)

Keep

  • Support → Support
  • Contacts → Contacts (similar to original OS apps)
  • Location → Allow to use as Dynamic Link. Pending improvements WIP for describing
    polygons in geospace, or simply coordinates.

Agree:

  • Selling → Sales
  • Buying → Purchasing
  • HR → People
  • Stock → Inventory
  • Loan Management → Loans
  • Quality Management → Quality
  • Retail (move POS from accounting to Retail)
  • Move integrations into custom apps
5 Likes
11

Hi,
Only one point here about

DocType Renaming:

* Warehouse -> Location (merge) (and all fields along with it)

Since warehouse is a parent child structure, should keep the name warehouse to give stronger meaning of that doctype, location is more to indicate an address.

Warehouse is about to build your inventory structure.

Thanks
Nofal

4 Likes
12

I was also a bit conflicted about the warehouse naming change.

Warehouse is very specific to inventory management, and in this case that is what the doctype is for (As far as i can tell). Location may be a bit confusing from an inventory management perspective

1 Like
13

I agree Support should remain support

14

If selling is sales, it only makes sense that buying becomes purchases in plural

In HR Employee Advance can be improved to Expense Advance Employee Advance / Expense Claim - same as "Reimbursement" isn't it? - #19 by vrms

15

How about storage or storage location

2 Likes
16

Also move Fleet Management out of Human Resources.

9 Likes
17

Another consideration about naming:

It creates a lot of headaches for integration development that objects can change their name. How about a unique ID for each object?

It could be hidden from the user everywhere except in the URL. Otherwise, the user only gets to see the title. This way we have one human-friendly identifier (Contact Rushabh from Frappe Inc) that can change and one machine-friendly (Contact/adf78gdf8) identifier that stays the same. For example, Google does this in Drive.

I already had this discussion with @Mario_Truss. Also the topic often comes up with the request for “title links”.

I hope I’m being clear what I mean and sorry for extending this discussion to the naming of single records.

8 Likes
18

Yes. That would make total sense.

19

One more suggestion

Buying - Procurement instead of Purchases

5 Likes
20

Not just renaming, but it would be probably a good time to refactor customer and supplier records into a generic “party” record, so the same party could be supplier and customer without data duplication. Would there be interest from the community?

7 Likes
21

Agreed with Procurement

3 Likes
22

I also agree that Procurement seems more ideal

23

I agree with many things here, the proposed changes makes the naming of the modules and doctype more clear and consistent, for new people.

About, change “Item” to “Product”, nah!, it’s not good ,“Item” is generic enought to represent many things, like “Articles”, “Products”, “Services” to don’t forget “Accounting Concepts” (these are the configuration I see people doing in ERPNext on top of “Items”.

Procurement, makes sense, but I think “Purchases” is clear enought.

I think, since it’s the moment to rething few things, I need to make a question here:

  • Why an party cannot be attached to multiple accounts (Receivable and Payable), since I can pay a customer and vice-versa, we always need to sticky to one account per party, and if we have more cases, we need to duplicate parties, creating a non-sense seguimentation of parties.

It’s more about having a clear answer about “Why we have stuck with this model”, than having a “No tabs!” answer!

@lefebvre_bern

8 Likes
24

Is the direction of erpnext being a single giant monolith app changing to another direction?

3 Likes
25

Good to see ERPNext is refactoring. I think it’s a good idea

26
  1. I think it has to be decided that the naming is based on “thing/object” or “function”.
    I suggest the Modules group is based on basic organization operation functions. So maybe the group can be named Operation.
  • Selling → Sales [agree]
  • Buying → Purchase [-> Purchasing]
  • HR → People [if People, than Contact should be here too], so maybe Personnel is more suitable.
  • Stock → Inventory [agree]
  • Loan Management → Loans [agree]
  • Quality Management → Quality [agree]
  • Support → Helpdesk [Support is better because it can include other related information/doctype, like the Warranty etc.]. Some company call this After Sales Service.
  • Retail (move POS from accounting to Retail) [agree]
  • Contacts → Profile [Contact is better because clearer]

  1. Warehouse stays Warehouse.
    Item says Item.

  2. CRM change name to Marketing. So it’s not only about contacts and communication but more to function.

  3. Tools is named Desk Tools (or Desk for short - because there is no desk anymore in v13 so it’s fine to use) in Administration group together with User (but not Permissions), Dashboard, Leaderboard.
    Marketplace can go here too, or stay in Places with Social.

  4. Settings, Integration, Developer, Customization go to Setting / Enhancement group. And Permissions is here too.

  5. Domain modules should have modules in Domains group. Activating them should have effect on the desk. These includes Service and Distributor.
    This become specialty group/modules for the business.

  6. Merge Contacts with Customer, Supplier, Party in terms of info. So Contact is the person/party, and Customer, Supplier, Student, Farmer, Scientist, etc. is the role defining how they are engaged with the organization.
    Maybe also divide it into External and Internal contacts.

  7. Accounting module has became bigger so maybe can be divided into Accounting (Bookkeeping) and Finance.
    Assets get into one of these categories.

  8. Move Subcription to Sales.

  9. Fleet Management becomes top group in Operation/Module card.
    Delivery can be here.

  10. and one more important I think is the consistency of breadcrumb which should (as the name implies) trace our way back. So cross group menu/module/document won’t land back in different module/group.
    e.g. Item can be everywhere which confuse (and sometimes get in the way) when we work back and forth between documents.

  11. If Integrations move to custom app, will it still be supported by Frappe/ERPNext team? If so, maybe all integrations can go to one pooled custom app instead of 1 integration as 1 app. So any user custom integration can also be made standard to this Integration app.

I hope this long list is seen as my gesture of love to ERPNext :smiley:

4 Likes
27

Merge Contacts with Customer, Supplier, Party in terms of info. So Contact is the person/party, and Customer, Supplier, Student, Farmer, Scientist, etc. is the role defining how they are engaged with the organization.
Maybe also divide it into External and Internal contacts.

It is great to see that it is not just me, who thinks refactoring this part of ERPNext is a good idea. :slight_smile:

I am not completely sure that “Contact” as the central element would be the best approach though. In my mind Party is an entity that can be a natural person or an organization. If it is a company, then it can have multiple different contacts (both generic and specific contact persons). It is also possible, that the contact person should be also a Party, because she could also be a Customer / Supplier as well, not just the Organization that she represents.

However, this is also a difficult topic due to the GDPR in EU (and similar legislations in other countries). If the data is stored in a normalised fashion, it could become harder to identify which data is handled based on a revocable consent, and which data is handled based on a contract, law or a justified interest of the ERP owner. What makes matters even more complex: the basis for data handling can (and will!) change over time. We should consider this aspect as well, as we start working on an updated data model.

What do you think?

28

Yes you are right about using Contact as center. Maybe more appropriate is to use Party as central and Contact is part of it.