Try ERPNext Buy Support Partners Foundation

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

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:

  1. Refactor module groups:
    • Frappe/Core
    • ERPNext/Utilities
  2. 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
  3. DocType Renaming:
    • Warehouse -> Location (merge) (and all fields along with it)
  4. Move integrations into custom apps
  5. 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?

18 Likes

Can we move the QuickBooks Migrator too?

Yes, I meant all integrations, let me remove the list.

1 Like

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?

2 Likes

Item to Product might not be a good idea considering all the other things Itens are used for ( eg Fixed Assets)

4 Likes

Stock Module to Inventory Management ?

3 Likes

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

1 Like

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.

2 Likes

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

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
4 Likes

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

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

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?

How about storage or storage location

2 Likes

Also move Fleet Management out of Human Resources.

9 Likes

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.

7 Likes

Yes. That would make total sense.

One more suggestion

Buying - Procurement instead of Purchases

5 Likes

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