Iâm interested 
. A great side effect of something like this is that we move away from having to write a lot of code in controllers to change presentation of a document based on specific field states and move towards achieving this same behaviour with configuration of variant doctypes. Less code. More value.
1 Like
Any other community member like this proposed feature? or has any other comments?
I would like to see at least 5 LIKES before start the PR:smiley:.
3 Likes
Still one more LIKE needed to start the PR, 
7 Likes
Are you going to implement it in some existing doctype too? Because that would be nice.
this feature is for creating existing doctypeâs variant.
So, there is actually no doctype that will use this âas defaultâ? Like, there is no âdoctypeâs variantsâ in the core of ERPNext?
Yes, this feature only enables end user to base on standard doctype creating his/her own doctype variant for specific business scenario, there will be no out of the box standard doctype variant after installation.
I do can offer an real user case!
I do have some customers that have Roles involved into the Sales Order
Sales User
Sales Manager
Accounts User
The Sales User is allowed to create the Order, by is not allowed to apply Order Discounts, but can apply discounts into the Items.
The Sales Manager, only is allowed to review the Order and Apply discounts on the grand total, on cases where itâs needed.
For Review, the Sales Manager only needs see (Customer Info, Address Info, Totals and Discounts)
The accounts User, needs also the same information of the Sales Manager, with the difference that him will attach the commissions for the 2 past users involved into the transaction, so Accounts User, can see Sales Team also, that is not allowed by the Sales Users and Sales Manager.
Itâs a simple case, but I think Itâs enough to offer one real Business Case.
I have been looking at this feature for long, especially in Payment/Receive and Stock Entry. It is difficult to make some users understand this One Doctype for many activities concept when some doctypes are used for operationally very different functions by the business
And you forgot to add that someone is going to use and test it in PRODUCTION
1 Like
Updated, thanks for your reminder.
I believe quite a few of us work with other ERPs where this is standard functionality in some shape or form so I think that if there is someone willing to pay for this or spend their time implementing it we may not insist on having a paying customer. Some of these gaps actually make it difficult to get some serious customers to adopt. It should be enough that someone is willing to contribute it and that the feature makes sense. If it makes sense and doesnât break any existing functionality then it should be accepted on its merit.
Use cases are myriad and we havenât even considered itâs application in child tables.
For example, in a Journal Entry scenario, we can have different fields in the item child table editable/visible depending on the content of a specific field (out group of fields). Not all the fields that apply when posting to a supplier account apply when posting to a P&L account.
@szufisher To achieve this the doctype variant can have an optional field that captures a condition to be met in order for the template described by the doctype variant to apply. Any change to the field referenced in the condition triggers a check to see if the condition is met and if so, applies the correct template to the field.
I had this chat with @szufisher personally, but putting it here for the public record.
- Any feature built without direct customer feedback and UAT is usually half baked, as no matter how experienced a developer is, there will be edge cases that will be missed, and use cases that will be missed all together.
- There are issues that only show up in production.
- There are issues that only show up at scale.
- We have worked with close to 1000 customers now without having the need of this feature (we do have field-level permissions to hide fields selectively)
- There is just too much maintenance headache to accept a mid / large feature without guaranteed maintenance (from a paying customer).
- YAGNI - âAlways implement things when you actually need them, never when you just foresee that you need themâ
1 Like
Dear Rushabh,
Thanks for your time and guidance, I understand your point and support your decision, I will try to fine tuning my solution internally and wait till there is real customer who need this feature.
1 Like
Point taken Rushabh,
But I think that, since I use ERPNext in my organisation, I probably qualify as a customer who can test it in production 
Also, Iâm acting here more like a system integrator than a developer and the prospects I talk to need many of these features discussed here (even when they donât know how to explain it clearly)
Hi @szufisher, I am really looking forward for this new feature as I am struggling with the existing user permission setting. I am not a programmer but how can I help?
if you are hosting ERPNext locally and you have total control of the server, you can hire a developer to adapt my code( available in this PR feat: Doctype Variant: more user friendly scenario specific user interface (form view) and permission control for complex process by szufisher ¡ Pull Request #7946 ¡ frappe/frappe ¡ GitHub) into your server, and testing it, after test you can move it the your production environment and help to prepare documentation about your real business case, then we have chance to apply review the PR by core team.
We may have a customer with a business case for this; if there is still interest in it and they choose to move forward, is there willingness from Frappe Tech and/or the foundation for this code to be integrated upstream?