Is it possible to have warehouses with the same name? There can be a “Rack 1” in different parent warehouses. But when I create it, it give the error that a duplicate name already exists.
When I looked at the doctype (?) (by clicking on ‘Customize’ in the warehouse list view, the field “warehouse name” is marked mandatory, but not marked as unique. So maybe the DB is complaining?
Is there a way around this? This puzzles me.
Thanks in advance!
It’s possible ERPNext uses the warehouse name as the primary key (although I’m not 100% sure). If you have multiple “Rack 1” locations, I would recommend having the name include the path (parent, grandparent, etc) for the rack. You could use abbreviations to keep it shorter.
I believe Frappe is working on a more comprehensive WMS, so hopefully future releases will include better ways to create, use and report on warehouse locations, location segments, etc.
ERPNext also includes inventory dimensions which might be of some help for your use case, although I haven’t looked at those too closely.
Thanks for the response and suggestion. While trying to import data across multiple areas, changing the name on one CSV trickles down to other related CSVs and becomes just too cumbersome.
I hope they fix this in upcoming releases. They really shouldn’t have user-generated primary keys.
“They really shouldn’t have user-generated primary keys”
Agreed. I think that was an early design decision by Frappe developers that many tables would have user-generated text primary keys (to reduce the number of lookups & joins, make the database more legible, etc - I know, a little lazy, but I guess we can all be that way sometimes :).
But user-friendly text keys does make record renaming more complex, and less efficient for indexing from a database standpoint.
I think Frappe has moved a bit more towards efficient storage, by creating an auto increment naming option, and the ability to show the doctype title in linked fields so that primary keys no longer have to be user-friendly. But there would be a lot of refactoring required to convert the existing schema over to a more efficient key methodology.
Database design 101.
It puzzles me why they did it the way they did.