I was wondering if someone could help me?
I have created two new Master Doctype’s.
One called “IT Equipment” and another called “IT Service Repairs”.
I have added the “IT Equipment” Doctype as a table field into my Customer Doctype (via custom field).
This works great as I can add multiple different pieces of “IT Equipment” to each individual Customer with out any extra scripting.
I then try to add “IT Service Repairs” as a table field into the “IT Equipment” Doctype (via custom field).
This way I could add several Service/Repair jobs to each piece of IT Equipment.
However when I do this the “IT Service Repairs” table field fails to add/open correctly.
It just automatically creates a new “IT Service Repair” row with its Doctype defaults being published. I cant modify the row after creation either.
Does ERPnext allow for this type of “nesting”?
Or have I just stuffed up somewhere along the way and need to delete both of the new IT Doctypes and re create them properly this time?
Thanks rmehta you were right. I did a few tests today and thought that the error almost looked like a javascript onClick / onFocus type issue rather than a DB “nesting” issue. I will hopefully have time to look into this over the weekend as having a third level would have been handy in my case. I will make both Doctypes top level instead. Thanks again.
For what it’s worth, I was earlier attempting the same thing (child table on child table) and couldn’t get it working. I had to move on after a half day of poking at grid.js to try and get the event handles propagating the way I would expect.
I wanted A=>B=>C, for a 2-level collapsible presentation that can be entered in one shot. Nested child tables made sense because my business use case dictates B is a one-of-a-kind for A.
What I had to settle for was:
A=>b(link field to B)
B=>C
I also locked down CRUD permissions on B and b and added a button to A to handle add/removal of B instances. I wrote serverside create/update hooks on B to manage the rows of b. Submitting A cascades and submits all related instances of B. Not quite as neat a presentation, but workable.
Thanks for the info jvermette. Good to hear it wasn’t just me wanting to create a second level child table setup
I ended up adding some extra custom fields to the address doctype so I no longer needed the inbuilt contact doctype features.
I then changed the contact doctype into my B doctype with a table field linking to my C doctype.
This seems to have worked well. I still haven’t found time to explore the .js files to find a more flexible global solution. Cheers Rick
We are developing one budget estimation app.
One estimate has many Line Item.
Each line item associated with multiple jobs.
For that, we need nested child table.
How can we achieve this in frappe? Please give suggestion if you have.
I have created a master Brand Group in which two fields are there one is a linked of Brand Master and second one is a data field which denotes the name of Brand Group Master.
I need to customize the Item Form where I want Brand Group list should display the filtered data. First I will select Brand then on the basis of Brand selection, Brand Group drop down should show only those data which are belong to the selected Brand.
Issue is my Brand Group list is showing all data. I have added both fields Brand and Brand Group. Both fields are created as Link type field. Please suggest.
My scenario is Customer DocType with a Table-field to a ChildTable and the linked ChildTable contains also a Table-field to a ChildTable.
It seems to be really a fact, that nested Child-Tables are not working in ErpNEXT. This is a big problem, because now such a scenario must be solved in a not clean way. Nested Child-Tables are a common pattern in business-solutions.
Maybe it would be a good idea to make such a scenario possible.
Nested tables can very quickly spiral out of control and create more problems than they solve. They can be a nightmare to debug! The framework has to balance user customizations with making sure that nothing gets broken, and by virtue of that, has to force you into a few design decisions. While a master-child-child’s child structure certainly can make sense in our brains, there are other solutions that can make more sense to the end-user and be more performant.
I would think about the structure of your data if you need to double-nest tables. A child table provides very little detail, and you end up with a different subset of the built-in controllers as well. You could consider making your first child it’s own doctype, and linking it to the customer from there (or vice versa, depending on what type of data you’re dealing with).
good luck!