Prologue
Below is an 11 page PDF that suggests changes that might be made to the new Tab View of the Item DocType. There are lots of specifics but the overall idea is that we could make things easier for the hundreds of thousands (soon millions?) of ERPNext users if we thought about the “Story” behind a DocType.
In the case of the Item DocType, the simplest story is Buy It → Stock It → Sell It.
Now, things are never that simple and we end up needing more “Tabs” than that. But the idea is that we gather all of the Sections into a limited number of Tabs and then present those Tabs in a logical order.
Caveats
I’m a marketing guy, so Users & Devs that are Accounting/Manufacturing/etc - oriented might have a different take.
OTOH, I’m a marketing guy. We know how to tell stories to customers. And ERP systems need to be sold/told over and over again to Executives, Engineers, Managers, and USERS!
I have only spent a weekend with v14 and there is lots I don’t know. (I look forward to learning from you!). Don’t be shy about pointing out what I have missed and misstated.
Our team has an immediate problem in front of us that involves adapting a 20+ year old system for a client. That is what drove me to redesigning the Item DocType (until the incomparable @vjFaLk and @RohanB pointed out that v14 could already do many of the things that I was asking for). Make no mistake, Tab view is AWESOME! But as I took a closer look, I saw some places where we could improve the DocType even more and that is what this post is about.
Lastly, I think that the idea of a “story” applies to other DocTypes as well.
POs could be:
Who are we buying from
What are we buying
What are our terms
How/where is it shipping
Any special accounting we need to do?
SOs could be:
What Marketplace/Channel delivered the Order
Who is the customer
What did they buy/pay
Any discounts
any other fees charges
Did they get terms/ how are they paying?
Is this a Subscription
What sales teams/partners are involved
And I know that there are others and we look forward to working through those with the community.
As noted above, we have a pressing need to move ahead and will need to make many of the changes noted in the PDF. But we will also find ways to post these changes so that other community members and maintainers can see what we came up with.
Looks good layout. Will make it easier for user to work at better speed.
Only concern I have is that any section below last tab is not visible if you click any tab that is prior to last tab. User has to click last tab for the sections to be visible.
Irrespective of which tab you are on the sections after last tab should be visible. It’s framework issue here. Seems there is no closing of tabs like what you see on websites on WordPress, Laravel etc. Hope Frappe team will look into it.
@MichaelPinkowski were your changes ever put into practice via a custom app or at least modified with the customize option (assuming that is how the screenshots were created) to test out how well it “sells”? Also did any of these suggestions make it over to git?
@eleben Hi David! We made the changes for our client using DocType Layout. (And if I recall we came across a few ideas that we contributed to make that tool a bit better.)
We make the same changes for new customers when we do an implementation.
My goal was to influence the direction of future versions so we didn’t consider putting anything in GitHub. I haven’t looked at v15 yet to see if this concept was used there.
The suggestions were very sound and I hope some of them make it into v15. If not I will submit some of them as feature requests in github to hopefully put more eyes on it.
Hey Michael,
I really like your approach. Indeed, telling the story is the hardest part about an ERP. I have worked with the ‘item’ doctype before and it was really confusing for me at first. I still have to search for things when I use it.
I think these changes are really helpful for the end-user to decrease the learning curve.
This is an exciting feature, and puts ERPNext closer to some of the more established ERPs with regards to customization capabilities (the standard DocType form builder was never the most intuitive). Making Options a linked field also helps a lot.
Two other questions/comments:
Are there any plans in the future to control the width of individual fields? Having a screen-wide or column-wide field to hold, for instance, a narrow checkbox or 5-digit postal code doesn’t really adhere to best practices. (I know this would complicate the UI layout, especially re: responsiveness on mobile devices; it might require more granular sections than the traditional screen-wide section break in Frappe with evenly spaced columns).
It appears that standard fields of core doctypes still can’t be moved outside their current sections or tabs, so I assume the form builder wouldn’t directly address the OP’s goal of re-arranging Item field locations. I assume that’s because there could be scripting or interdependencies of some standard fields which might break if the field order is changed?
Hello,
We another suggestion on this topic.
Under the sales tab of Item Master, the table of customers should auto-populate based on the sales of that specific item. i.e. if there is an item bearing an item code ABC-XYZ and we have sold that specific item to 5 customers say A, B, C, D and E.
so when we go to sales tab of the item master, all the previous sales should be listed under customer table.
similarly, if we are buying the item from 6 different suppliers, the supplier table under purchasing tab should auto populate.
It given several advantages to Sales as well as Purchase Teams.
Sales teams will be able to focus on the existing customers of item and Purchase team will have a handy list of suppliers when floating a RFQ for re-stock/repurchase.
You can see things as an end-user. My only addition could be