The process of entering relevant data in ERPNext proves to be very lengthy in some cases.
For example in the company there are around 7000 Work Orders created every year.
Each Work Order in turn has 12 to 16 Job Cards (depending on item being manufactured).
Currently what is happening is that if a use has to make entry in a particular Job Card then the user will have to first find the Work Order then open it and then go to Job Card and then make an entry in Job Card. This will again create Material Transfer Entry and then one has to Submit it, etc.
Add to this the fact that in some Items which have multiple sub assemblies the complexity seems to multiply multi folds!
This task becomes very laborious looking at the amount of data that is produced and the process of reaching to the relevant DocType and entering data in it.
Instead of so many steps what I am looking to do is show user data of Work Order and the Job Cards in a Table and allow a user to click on the Job Card to access it and perform necessary activity.
In this view it would be possible for user to see all Work Orders that are open and all the Job Cards for each Work Order and all batches that are completed and ones that are pending with Qty.
The documentation on pages isn’t great, but there are some good examples if you search for Page from the desk. The bank reconciliation tool, for example, is conceptually similar in some ways to what you’re trying to do.
With pages, you’re really building whatever UI you want from scratch. This takes some work but is completely flexible.
I agree that the documentation could use a boost, especially regarding how to get started. I’m working on a few pages right now and I’ll try to come up with some minimal examples for the docs in the process.
That said, part of the reason that the API is so minimal is that it’s pretty much a blank slate. You can add whatever code you want directly to the parent defined in make_app_page, and from there it’s all just regular js/html/vue/whatever.
The new frappe-ui library seems to be a very interesting addition for all this:
Pages are great for highly interactive UX with specialized layout. See the POS, the bank reconciliation tool, or the customize form tool for examples. The only downside is development time and energy.
I would suggest you look into creating a ‘dummy’ Single Doctype, then create a Child Table, and fill the child table on load of the form with whatever query you want. Then hide the save button of the form. ERPNext is using this technique, you can check Quick Stock Balance which is defined as a single doctype only to help building the UI form (from my understanding).
Another option would be to add an HTML field to the Single Doctype, and load a Vue component inside it. You can get some guidance how to do this here: Vue component inside from html field
That’s a great idea about the single doctypes. That would allow a lot to be done purely client side, without the need for a custom app.
As far as pages go, I don’t think they’re any more or any less jquery-ladened than anything else. The API itself doesn’t do much, mostly just managing the chrome around the page. For the page content itself, you’re on your own to use whatever you feel comfortable with. For anything complicated, my preference would certainly be Vue.
We were creating ~100 Work Orders per day, and found that the workflow was to clunky to run this effectively. We ‘optimized’ by having a single job car per Work Order, and a script to create the material transfer entry automatically.
However, the issue isn’t the existing workflow, the whole Manufacturing Module workflow requires a rethink.
As a manufacturing user, I can discuss ideas with developers interested in taking this up.