I have been exploring the nooks and crannies of ERPNext v10 and since the conference have had some thoughts about where Hub might go.
Before hub becomes useful to all, I do believe we must agree on a classification scheme for it. I have mentioned it sporadically, but I am now adamant that in the absence of other proposals we go ahead with setting up a standardized categorization scheme for Hub, so that we can all “meet in the middle” with it.
Just by itself, the idea of Hub is wonderful in allowing you to list items. But I believe it has the potential to solve something much more complex than simply sharing our products with other ERPNext users.
Some ideas for where to take Hub:
- Once you have listed an item, assigning it to a standardized category will help to classify and keep the chaos in check. No need to invent something new here, the categorization scheme already exists with UNSPSC:
Basic guide to UNSPSC (short read)
https://www.unspsc.org/Portals/3/Documents/Introduction%20to%20UNSPSC.pdf
More complete and extensive guidelines and instructions for it:
https://catmaster.unspsc.org/Help/index.html
This hierarchical model is pretty comprehensive, allowing everything from items to services to exist in the categories. It follows the tree model that we are all familiar with regarding software development, warehouse categorization, account categorization, etc. I personally use it to great success already, and have found a way to pre-load mariadb cost centers and item groups as per UNSPSC in ERPNext. (I will post on Medium the methodology for it)
1.1 I propose that in the future, the foundation becomes a voting member of the UNSPSC $100 per year, so that we can propose categories captured through hub directly from hub users. This can be easily programmed in the logic of hub.
- Now that we have a classification scheme, we can then do really cool things with it!
The first would be to set up a category price index, with publication of the price index per category, perhaps even per items within a category. I know this sounds complex, but once the logic is the same for each item or category, the software and a server can handle the price calculations to update the index. Ideally, it would be updated live, but a twice daily process seems enough. A public site user can check prices quoted or prices when a transaction is registered. Clearly, the details of the transaction would be stripped, only datetime, price, quantity, place of origin, and destination would remain in the transaction to be used by hub category price index system. The data available would be simply whether items in that category have become more expensive, or less expensive, reflected by percentage change and colors, using frappe charts, mimicking the same charts used in stock market transactions.
the second would be to incorporate some form of suggesting whether a quoted price for an item within that same category seems right. Let’s assume you are quoting hammers. Hub has registered quotes or transactions for hammers in the past week to an average of $10 per hammer purchased at a physical store (regardless of type, size etc.) ERPNext user enters a quotation item for hammer, with the same hub category, and the quoted price from the supplier is $20. In this case, ERPNext would simply suggest verifying the price with a non intrusive color coded system for that line item. User can purchase at that price if desired (a shortage of hammers in that locality makes them expensive that month) or can opt to devote the extra time required to obtain a lower quoted price from another supplier. Perhaps the user can find the exact same hammer for $13, which is acceptable to the purchase manager, in which case the suggestions from Hub made the user save $7 on that purchase. Imagine this same process repeating over every purchase, then you can configure ERPNext to block any quotation whose total deviates more than x% from the Hub price index for all items in the quotation. This would allow you to focus only on those quotations that deviate strongly from what the same quotation is worth using only suggested prices (at current exchange rates)
If purchasing in bulk, it would allow you to better negotiate with the supplier for a price which reflects more fairness to both parties.
Just these two functions, initially programmed and working in a beta by May of this year would be significant.
- Hub price index can be geographically referenced:
For each quotation or transaction entered into the index, data from the smallest administrative unit registered to the company offering the product would be included, which can allow for a heatmap of category prices worldwide. For each category selected on a map view, the map can show the most expensive prices in red, and the least expensive in green for example. Within smaller map regions this can show that an item in location A is at $13, and an Item in location B is at $20. But to a buyer who is 100km away from location A, and 20km away from location B, shipping such item would cost $10 from location A, and $2 from location B. This brings the landed cost to $23 if purchased from location A, and $22 if purchased from location B. Clearly, location B offers a better landed cost price than location A. These decisions can be helped by having data shown on a map, and eventually a feature can be built to help estimate this, and by clicking one single button, the prices on the map updated to reflect landed cost to a selected destination, on the fly.
These are some ideas of what I think can be done with Hub.
Comments are welcome
Question is, anyone willing to support me in this endeavour?
Who is in charge of maintaining the hub server? or how is data stored?
I’m willing to sponsor these enhancements as well.
I offer the categories already parsed in a .csv format just to load to a Hub Category tree (which needs to be updated to show the initial, master category)