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:
- 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.
Any other badly named objects in ERPNext?
Can we move the QuickBooks Migrator too?
Yes, I meant all integrations, let me remove the list.
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?
Item to Product might not be a good idea considering all the other things Itens are used for ( eg Fixed Assets)
Stock Module to Inventory Management ?
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 especially welcome warehouse to location.
I would also argue that the following 2
contact => profile
HR => People.
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.
Only one point here about
* 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
I agree Support should remain support
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
How about storage or storage location
Also move Fleet Management out of Human Resources.
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.
Yes. That would make total sense.
One more suggestion
Buying - Procurement instead of Purchases
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?