Agreed with Procurement
I also agree that Procurement seems more ideal
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!
Is the direction of erpnext being a single giant monolith app changing to another direction?
Good to see ERPNext is refactoring. I think itâs a good idea
- 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 maybePersonnel
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]
-
Warehouse stays Warehouse.
Item says Item. -
CRM change name to Marketing. So itâs not only about contacts and communication but more to function.
-
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. -
Settings, Integration, Developer, Customization go to Setting / Enhancement group. And Permissions is here too.
-
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. -
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. -
Accounting module has became bigger so maybe can be divided into Accounting (Bookkeeping) and Finance.
Assets get into one of these categories. -
Move Subcription to Sales.
-
Fleet Management becomes top group in Operation/Module card.
Delivery can be here. -
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. -
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
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.
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?
Yes you are right about using Contact as center. Maybe more appropriate is to use Party as central and Contact is part of it.
Warehouse means the âparentâ structure that holds inventory. In the case of ERPNext it could be a shelf, or a bin or a room inside a warehouse, so its semantically wrong.
Helpdesk is the most dominant way to define the category â Zendesk, Freshdesk etc. ERPNext is more like a bunch of products now so each product should probably be know by its category label.
Purchase is the most common department name. I have heard its usually âPurchase Departmentâ not âPurchases Departmentâ (Procurement is also a good candidate, but Purchase is smaller and easier to pronounce?)
Accounting is way more just finance - Billing, Payments, Budgeting etc
Its a separate discussion we have had multiple times. The cost of this is to add hundreds of joins in every place. A doctype like Invoice has maybe a couple of dozen links - so every query will have a couple of dozen joins. Definitely out of v13 scope!
Partially. We are thinking of moving integrations out because they add a lot of unnecessary python dependencies that would make the application un-necessarily heavy (- additional doctypes are not heavy, so we will keep the functionality all tied in).
Maybe use Warehousing?
Agreed. More precise with Procurement
The procurement process flow is the strategic process of sourcing a product or service. This includes identifying a specific product or service requirement and the steps on how a business finds new or existing suppliers, builds supplier relationships, measures cost savings, minimises risk and is predominately focused on value and return on investment.
The purchasing process is a sub-process of procurement and focuses on the transactional phase associated with buying products and services. Activities involved within the purchasing process include creating purchase orders and ordering products / services, or receiving products and arranging payment. The key focus of purchasing is being able to achieve short term goals that include quantity, costs and timing.
With regards to Finance and Accounting you said
Actually it is the other way around, Finance is way more than accounting. For example Budgeting that you stated above is not an accounting function, it is a finance function. That is why in most organizations the Accountant reports to the Financial Controller where one exists.
As constituted the current Accounting Module has gone beyond just accounting. Calling it Accounting is becoming limiting and will become even more so as this module is further expanded.
My opinion, I might be wrong.
I think youâre right @olamide_shodunke. Finance is the broader term. Accounting is a subset of it.
Stock Settings â Item Settings
The settings apply to all items, not just the ones in stock.
Well, zero stock is still stock. The trend with naming âSettingsâ has been â{module} Settingsâ and I think itâs well accessible that way.
Accounting is about recording the past: journal, transactional document creation, deprecaiation counting, payment in/out record, etc.
Finance is about planning the future: financial statements, report, analytics, budgeting, fiscal year, etc.
I didnât mean Items that are out of stock, rather like this:
Makes a lot more sense now, thanks.
I agree