Everythings are awesome, but I think these are good to be as they are:
HR
Warehouse
Item
Item may be assigned default Income Account and Expense Account, but Item does not have Asset Account.
Asset Account for the is assigned through the Warehouse which has the Asset Account for stocks.
So, two items may be stored side by side in the same Warehouse location, but if they have different Asset Accounts, they have to be placed in separate Warehouses which have their respective account codes.
It would be nice if Item doctype (or more precisely Item Default) can have its own Asset Account for the Company, and not have to depend on the its default Warehouse’s Account. This way we can say that the semantics of warehouse is really location.
Rethinking this, Assets can be the group, with the following conditions:
- Depreciation moves to Accounting.
- Assets includes property, vehicles, warehouse Bld, office Bld, Equipment and Machinery.
- So Warehouse (as building or assets) goes here, and semantically (as location) can be renamed.
e.g Location: Area A, Purpose: Warehousing, Asset: WH Building 1.
e.g Location: Area B, Purpose: Office, Asset: Office Bld. - In this case, items (as product) might also be here. with its depreciation, loss, etc. But the Item management (i.e as stock) still have its own Stock (Inventory) group.
- Other document in need of assets item can get it from Assets doctype.
e.g Fleet Management: Vehicle: Car 1 (from Assets), Assigned to: Employee A, etc.
My concern is translation. Please use different terms for different matters.
1 Like
Assets should remain separate as is, Payroll too shouldn’t be moved back to Hr.
An usability consideration.
As is, Accounts and HR already have too many items, i.e. they are too deep. Users get lost looking for items there.
On the same breadth, there are reports that never appear on the Desk, but are on specific DocTypes under reports. These too, they are missed a lot by users.
3 Likes
What is in a name? I would leave Items…it is neutral…item can be a service…a service that is a product seems to be confusing
-I suggest in a new version 13 Add Module a Banking between A company and Exchanger Deposit & Withdrawal.
-I suggest Helpdesk to Supporting
-I suggest HR to Employees.
-I suggest HealthCare to Medical.
-I suggest Retail to POS.
thanks.
1 Like
I submitted this as a suggestion a while ago, but my one rename request would be to change the fact that the popup for renaming an item says “New Item Name” and “New Name.” Really what the “New Name” field is displaying is the Item Code. Can it say “New Item Name” and “New Item Code” instead? That would be much more clear.
2 Likes
Love these
1 Like
Do remember that Location was created as a way to represent coordinates or polygons on a map. This belongs to Agriculture module. They correlate to physical areas or pins. The intent is specific for the agriculture module.
“Physical Location” might be more appropriate. Warehouse can have an address, and a Physical Location attached (or not) based on crop cycle doctype for agriculture.
My $0.02:
If Selling–>Sales, it would make sense that Buying–>Purchasing (vs. Purchase). At least here in the US, “Sales” and “Purchasing” are common department names, not “Sales” and “Purchase.”
I also support Warehouse–>Location. It doesn’t make sense to call a bin or shelf a “Warehouse”, and I think warehouse location is a pretty standard WMS term.
Instead of “Location” for a physical address, can you use “Place” instead?
1 Like
I second this idea of renaming as we hold towards V13 on most suggested items in discussion. This will bring a new outlook to ERPNEXT.
Selling = sales (OK)
Warehouse = location
Buying = purchase (though “procurement” would take a bigger picture)
Accounting (to remain as it is just for market purpose though it’s a subset of Finance)
I prefer Warehouse (and the likes) renamed to Place because it is a place (to keep items) including bin, shelf, etc. to point where something is kept/placed.
And use Location for physical location for coordinate as in Agriculture, address, etc to point where something is located.
EDIT:
Why not rename Warehouse to Storage.
So Storage Type (renamed from the existing WH Type) can be from as big as a Warehouse or a Yard, down to as detail as a bin.
The change in the existing Warehouse doctype:
- Add Description field to describe the storage.
- Add Parent Storage to mark where this Storage is kept (Bin in Rack, Rack in Shelf, Shelf in Row, Row in Room, Room in WH, etc)
- Hide the Adress and Contact and Warehouse Contact Info sections.
- Add a checkbox
is a Location. If checked, open the hidden sections.
EDIT 2:
There is doctype Location (geolocation) for Asset.
So if Warehouse is to be renamed to Location can conflict with this.
But it is inline with my proposition. Use this Location to mark the Location of the Warehouse. A rack/shelf/bin doesn’t need geolocation, but location in terms of where these storage is kept in which warehouse.
1 Like
I like that suggestion a lot and it does make lots of sense to me. Hopefully, it will stick 