Releasing a new version is always a good time to clean up some of the old stuff that gets pushed back due to backward compatibility. Here are somethings that need cleanup:
Refactor module groups:
Frappe/Core
ERPNext/Utilities
Module Renaming:
Selling → Sales
Buying → Purchase
HR → People
Stock → Inventory
Loan Management → Loans
Quality Management → Quality
Support → Helpdesk
Retail (move POS from accounting to Retail)
Contacts → Profile (cancelled)
Fleet (move out of HR)
Masters (Item / Location / Company / Territory etc) - common master data
DocType Renaming:
Warehouse → Location (merge) (and all fields along with it)
Move integrations into custom apps
Website / Portal
Remove all Web Forms (make the custom)
Remove “Homepage”, “About Us” and “Contact” pages, make them custom
I understand this will cause a migration headache (specially the renaming) but in the long term interest of semantic consistency, we should do it.
Item > Product… Some items should be used as services, right?
And CRM have Contract inside… Should we create a Contract management? Or relationship management, addin clients and suppliers inside?
Accounting to Finance (and move the Asset Management back to be a part of Finance )
HR to either Human Capital Management or Talent Management (and move payroll back to HR)
I totally second moving PoS from accounting to Retail
Item does not bother me.
Changing item to product seems like it’s going to be lots of headache for not much of a difference.
For the rest, I would agree.
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.
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.
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
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.
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?