ERPNext Roadmap - Help Define and Contribute

Ladies & gentlemen, Boys & girls,

Let’s revive, reinvigorate and re-energize the ERPNext Foundation.

The Foundation needs you. I want to build a Foundation that’s more service provider friendly, a Foundation that respects your constraints and partners with you to contribute.

The first part is defining the Roadmap for ERPNext. Here’s a survey (it captures your E-Mail ID and you need to log in to Google).

We are building a transparent, democratic approach to the road map. But your involvement is critical. Transparency does not matter one bit if there’s nobody (or very few) watching. Democracy isn’t democracy if there is nobody (or very few voting).

Here’s the schedule for the Roadmap Process:

Till July 24th: Ideas: Module (Accounts/Stock/Manufacturing, etc. Etc.)/ Area (within module - like General Ledger, P&L, Cash Flow, etc.) And development/enhancement short description

July 25 - July 30 need one volunteer per module one for others (no modules) crystallizing the ideas into broad themes and presenting those themes to the community.

July 31- August 6: Community provides inputs on the themes.

August 7&8: Same Module Volunteers make the final themes and present the themes for voting.

August 9-16: Community votes

August 17-18, Themes are finalized. Top 5 themes are determined.

August 19-25: Module volunteers and other willing volunteers write the specs for all the themes.

August 26-28: Service provider estimates effort for each theme and based on the rate we have the budgetary outlay for each theme.

August 29 - 31: We optimize budgetary outlay and okay the top 2 or 3 themes. We reserve 20% extra budget for the peripheral GitHub issues that are covered in the code that is being touched (delta effort while the code is being touched).

September 1st onwards we build. Module volunteers are available to answer developers / service provider questions and work with the community to optimize effort/features.

As code is ready: Volunteers help in testing.

Once code is tested and passed we push it to master.

Here is where you can help. If you don’t we move on. If nobody writes the specs for a theme, we move to the next theme. If nobody writes any themes, on September 1st we begin building what I think is a good idea. If you don’t want that - Participate! Vote!! Contribute!!!


@JayRam let me know if I am doing this right… This week the challenge is to come up with ideas or “buckets” that we feel would be worth pursuing. I have three to start:

  1. Testing: It just feels like we could stand an upgrade in this area. Maybe that means talking to an expert on the subject, maybe it is just documenting some procedures that all submissions are required to meet. But we will all benefit from putting more testing into our systems (H/T @clarkej) … and yes, I know that I am making it a little tougher to get PRs through which is something that I complain about regularly. Sorry.

  2. GDPR: There is so much that I don’t know, but it feels like we are all at least a little bit out of compliance here. Again, we might need an outside expert to tell us, but getting this tight would be good for all, and an important “gotta-have” for prospective users of ERPnext.

  3. Security: As I said elsewhere,our systems got hacked and it taught us some lessons, but I haven’t heard if those breaches have been sealed and I sure would like to know that we had a sustained effort on this issue.

… as they say on the advertising for a big grocery chain around here: “What’s on your list today?”


… and one more…

I have said elsewhere that our team is sponsoring a QBO connector and when that is done, we will sponsor a Xero connector. We have no need for a Tally connector, (does ERPnext already have one?) But it wouldn’t be a big hill to climb after doing the other two. Should we consider these “financial system upgrade kits” for small business to be a priority? I think the QBO connector could be very big for ERPnext in the Americas.


Can you please put that into the survey?

Hi @JayRam, it seems that some of the Modules are missing in your Survey, namely :

(maybe I’m missing some as well)

We’re currently working on improving the Agri module along with @tmatteson and @Tropicalrambler


I apologize. I have a personal bias against those modules. But I admit I shouldn’t. Correcting those omissions. Apologies! And thanks for pointing it out.

Update: Included those modules. Thanks guys for pointing out my mistakes and biases.




I know what you mean, I’m also not in favor of having a monolithic structure that includes all domains (the namespace collisions are already bothersome)

But we have to make do with what we have :man_shrugging:

1 Like

With projects like ERPNext and Frappe Framework somebody has to take a leadership position and decide what needs to get done and where things should be heading. Few good projects and almost no good company is created through a democratic process. It takes some driven people with great ideas to get things done. I believe we have this with the Frappe team and with Rushabh.

This doesn’t mean that there shouldn’t be a community element and a strong foundation to help decide where things are going. I am just trying to say we need both: strong leadership and innovation from Rushabh/Frappe and good ideas, code contributions and direction from the foundation.

I believe this happens, maybe not to the extent that is good but ultimately it does happen and we need to improve upon what is instead of revolutionizing the process.

One huge problem in all of this is, that people say „I would really like to have ABC“ but almost nobody is willing to pay for it or to dedicate the resources to get things done. When things done they are not done right or they might actually be counter-productive to the project as a whole.

I have experienced a lot of important features that we (selfishly) needed being integrated into ERPNext over the past 6 months I am grateful for that. Also we were able to develop better code faster and to contribute some of it back. We are not where we want to be when it comes to contribution but we are working on it.

I don’t think that the idea of somebody taking responsibility for a module makes too much sense. This failed in the past. Also we are not just interested in one module, we are improving bits and pieces everywhere.

We will contribute our opinion soon, I have asked our devs what they believe needs fixing. Some preliminary comments from me (in no particular order):

  • More security testing
  • Better Project Management
  • Multilanguage websites
  • Improved and more current user documentation
  • Improved and more detailed developer documentation
  • More stable releases that are tested better to be enterprise ready
  • Modern design for the website and some attention to the website module
  • Webpages need to be redesigned to feature modern technology like vue.js that hook to DocTypes with
  • Handling big screens better for more information displayed
  • Ability to silently print on POS or printers (invoices, delivery notes)
  • Single Doctypes to be linkable on Desk
  • other

This time, these are not Module leaders. These are Module volunteers that write Specs get that developed and then the group is disbanded.

Let’s go with what needs to be done for now. The roadmap is missing from the community and in the absence of that the Foundation Board has taken the best decision they could.

Once we have a roadmap of features we can figure out who does what. But for now we do need about a dozen volunteers , so please do get your team to chip in.



1 Like

For roadmap we can take any feature request which is liked by 10+ users.

Also developer need details specs, mockups and use case to develop something meaningful. We can give some funds who write specs and help in development lifecycle via testing/ communication.

1 Like

Err, when will ERPNext fully migrate to Python 3?

1 Like

Here comes my ideas

  1. setup to Make it directly testable for new feature request before merge
    currently if community members are interested in some new feature submitted, and willing to contribute testing, they need to first pull the most
    recent branch to their own local development repository, and test on the local machine, either there is no local repository available or there are
    some other problems during the pull and merge into local repository, the testing effort will simply end up as giving up!
    there is for reference

  2. build green ERPNext installable
    the current documentation and forum discussion thread about how to install /setup ERPNext in the target OS is good enough, but it is far from perfect because
    there are still quite a lot questions back and forth, even so many frastrated installation failure reported, to make the setup / installation more easy and
    error free, I would like to suggest bundle all needed dependent packages together to create independent executable environment, then the user can simply
    download the bundle to the target folder, run the bench or supervisorctl command to start the system right away!
    There is Green Odoo for reference, which is a solution by provided and maintained community

  3. drag & drop form builder
    currently frappe framework is advertised as meta driven, it is possible for admin / end user to customize the user interface especialy form and list views via
    maintaining the doctype or customize form, either way, the meta data: both the property of the doctype itself or its fields to be changed via traditional data
    input form and tabular grid. this simply works as meta driven, but it is still not user friendly and far from perfect.
    the most popular and true non technical way of building user interface is a kind of form builder just like how C#, java and delphi do for tradional front end
    in client-server context

    1. drag and drop a form control from the control panel into the form designer
    2. drag and drop container control(in ERPNext: section and column break) to the target area
    3. drap and drop the field control into the container area
    4. mouse select the target control, double click to invoke the property setting screen, set the relevant property,
      select the available event, double click to jump to the code editor window to write event handler code
    5. click the preview tab button to preview the layout
    6. click the source tab to view and modify the code generated
    7. in the control panel, common non visible tools can be provided

the form builder can further combine the existing customize form and custom script(also server side script?)

Odoo studio can be referenced

  1. more easy data input via direct copy and paste into child table in form view, barcode scan into child table also
    the current import feature for both doctype and child table is not so efficient and user friendly, copy(Ctrl+C) from Excel/CSV , then paste(ctl+v) into the
    first column of the child table is more user friendly
    also for material related transactions such as goods movement, orders, packing etc smooth barcode scan input feature is badly needed if the transaction volume
    is high.
    for more details please kindly refer to the recent forum thread

  2. more powerful global search, support and (&) operator in the search term, convert the where condition from fulltext search to simple content like
    the current global search feature is awesome, by simply search fulltext(the OR logic is applied for multi terms separated by space) the content field
    from the global search help table, it is far from the real internal google search engine in ERP, at least it should support the and(&) operator to get
    a meaningful search result for complex search, also for other non English local languages which have no space between the words, the full text search by index
    on individual key words simply fails, in this case the simple solution is to search those term by where condition: content like %text%.
    for more details refer to the open pull request, till now still missing the test!

  3. further enhancement to the form view, especially the grid child table
    currently the grid in the form simply works as expected, the following feature can be considered
    6.1 Allow personalized layout: in SAP, the grid is called table control, on the upper right corner, there is a customize button, after click it
    there is a popup window by which the user can define his/her own table columns, simply which column should be displayed, in which sequence and the width,
    each such definition can be saved as a layout, the saved layout can either be set as default when open the form the next time it will be applied, the user
    can select any save layout to switch and refresh the columns o ad hoc.
    this same feature can also be applied to the grid report

6.2 copy row, there is open issue requesting it

6.3 fast change selected column: currently purchase order and sales order have delivery date at header level, by changing the delivery date at header level
all the item level delivery date in grid will be auto copied from header, this can be a generic feature at grid level, how it works? either user place the
cursor in the cell of the target column, click the fast change button, there will be a popup window with the field of the focused column, user select a valid
value or input it , click OK button , then all selected grid rows are changed accordingly.

6.4 position/filter button, just like fast change, after user input the value for the target field, the grid rows will be filtered accordingly

6.5 sorting by clicking the column head label

6.6 frozen the selected( mostly the first) column

6.7 display via mourse hover the content of hidden columns, sometimes user are only interested in certain grid rows with specific content in hidden column,
if mouse hover can reveal the needed info quick, then no need to open each grid form form to check.

  1. auto save the last failed authorization check to database for easy issue analysis and fixing
    the current authorization check failure message to the end user and admin is not enough for quick issue fixing, it is preferably to save the failed auth check
    with context info such as the required auth, the assigned auth together with relevant roles, from which program source code file and line no. with these detailed
    info readily available via checking the user’s last auth check failure doctype, this will simply speedup the isse fixing!
    this feature is available in SAP as transaction code SU53 and SU56
    the other related possible improvement is to add a auth check simulation button in user and role maintenance form, by clicking this button, the role admin can
    select a target document or create a dummy document, select operation type(create/change/read etc) select the to-be assigned new roles or tick the existing
    roles to be removed, then system can simulate(check) whether auth check will be OK or not!

  2. further enhancement of message feedback to user
    8.1 normally the message popup from either backend or frontend frappe.msgprint is informative, it tells user which master or system setting is missing or incorrect
    or which mandatory fields are missing etc, it is better to add the relevant link to the target list or form view, or focus on the incorrect/missing field!

8.2 for most of the case, the message from the msgprint is clear enough and actionable to end user, but for further technical analysis, it is preferable to make
available as advanced/extended info the following internal technical info, such as frappe._dict, request, response, user, session, it can be hidden by default,
but it is availalbe by click the button.

8.3 currently in backend python frappe.log() together with server side config setting logging = 2 will trigger the db.sql() to log /output the raw query and its
values to the browser console, this is pretty nice for indepth debug, on one hand, the end user and even admin on SAAS have no access to the config file on backend
server, on other hand if all output for all db.sql() call without further filtering by either user, doctype or module, there will be a lot of unwanted log cluttered
in the browser, making sorting out the suspecious query more difficult. so in my opinion it can be refined further to make it more useful, to allow the authorized user
preferably the admin to activate such logging by user, by module or by doctype with defined timeframe. this is how exactly SAP defines the trace by user, transaction,
table! the relevant transaction code are ST01 and ST05.

8.4 support user defined traceback point(python method call), just like the above mentioned db.sql() logging mechanism, during development and bug fixing, when the
system does not work as expected but without any error (traceback), it is hard to pinpoint where the error occurred at source code level, it is especially for guys
like myself without proper IDE for debugging! with the server side script feature, this can be easily achieved by hook up certain event via custom server action in
which simply call the get_traceback! for more details check the closed pull request.

  1. further enhancement for reports
    9.1 customizable drilldown, double click the amount/qty field to the grid list(linked report) to document item detail on amount/qty
    9.2 personalized layout
    9.3 inline filter at header
    9.3.1 support search by multi value(, or ; separated)
    9.3.2 add awesome complete with data source as distinct value of the current column
    9.4 first column frozen
    9.5 group by and subtotal
    9.6 base on group by column, collectively ssend mail to relevant partner/user with his/her own data records as attachment(PDF/HTML)
    9.7 drag and drop report builder for multi doctypes auto joined by link/child table.
    9.8 report builder to define pivot table (SAP’s report painter)

I have a lot of other improvement ideas if needed!


Would you consider to implement e-invoicing?

In Europe is becoming mandatory in many countries:

I’m afraid that many organizations will stop using ERPNext if they cannot issue e-invoices.

Thanks for considering


I think we have enough to work on. I think! :slight_smile:

Thanks really for pouring your heart out Really! :slight_smile:

We absolutely will consider this idea… Maybe it’s already a part of the deliverables of The Hub. Maybe @rmehta can confirm if it is part of The Hub!



Not the hub? …strange … #kidding .:joy: …do not get me seriously :+1::muscle:

In V11

A short note here: I think this topic is dying the death of so many foundation related discussions in the past. A good idea starts with a few good replies, then turns into a back and forth of small comments and eventually dies without consequence. That’s too bad because I appreciate Jay’s initiative and this is a very important discussion to be had.

I will try to contribute my and some of my team’s thoughts here:

What ERPNext and Frappe Framework Really Needs

Disclaimer: ESO is a small enterprise industry user so what we need may be different or even opposed to the needs of other users. Agriculture, Hotels, Restaurants, Software Development all may have completely different needs. I am saying this because I want our suggestions to be understood in the context of what we believe enterprise industry users need.

Another Disclaimer: I know that Frappe and Rushab as well as the community are all trying hard. A lot of the things I am addressing here are work in progress that has been started. I also include myself and our team in how we have to improve to make this experiment a success.

1. Stay Focused, Stop developing distractions

My biggest mistakes when implementing ERPNext in our company (we are now 3 months live and thriving!) was to immediately develop features instead of focussing on core processes. A ridiculous hyperbolic example would be having implemented a Barbecue Party DocType which logs what kinds of foods are available, who attends and who has paid. We didn’t implement that but the ease of how fast you can develop things in ERPNext makes you sometimes lose track and ultimately instead of cracking the tough nuts like accounting you will implement a nice to have feature.

Rushabh was rightfully so criticizing me for this all along and I think that the Frappe team is also making the same “mistake”. The website now lists what they do as “Frameworks + Apps”. A lot of attention seems to have been given to frappe.js and accounting, bench manager, agriculture and healthcare modules etc. All of this is fine and good but as an enterprise user, we need a robust framework and ERP system before these other things are dealt with. I am excited about frappe.js and accounting is a very cool implementation of it that could be showing the direction of ERPNext in the next years, but right now we might have bigger fish to fry.

So stay focused on frappe framework and ERPNext, within that make the framework and the core ERP perfect. Don’t try to widen the domains of ERPNext for the moment and don’t invest in new products.

2. Improve the documentation

If we really want to attract quality developers and customers to this framework we need an excellent documentation. Right now most people I come in contact with and what contributions there are are not up to standard because in part it is hard to know what the framework can do and because there are no standards.

Frappe and the foundation should consider experienced technical writers who can create a complete developer and up to date user documentation. Code style and contribution guidelines should be revised and enforced. The same goes for forum discussions or issues, things are proposed in many different places and there is no structure to it.

Create official documentation on how to set up servers and development environments. A lot of developers use windows and we have no way to set up a proper environment. Guidelines on how to set up servers with all security considerations and how to set up an ideal developer environment are for a framework that has so much essential. This would also make the framework easier to access for junior developers (think Django).

Hire technical writers to create better setup, developer and user documentation. Have someone full-time to take control of the issue tracker and discussion posts to ensure quality.

3. Open Day and Release Launches

A lot of functionality gets introduced to frappe and ERPNext without people really noticing or being alerted to the fact. There are attempts of webinars and open day slides which keep people up to speed. I believe the releases have to be bigger events that are structured so the growing number of stakeholders can tune in and follow exactly what is happening, how it affects them and what they need to consider.

This is not only true for the frontend but also things like a switch from NPM to Yarn or new API or utility functions are quietly introduced, not documented and thus get lost or go unnoticed

Have an Open Day presentation with a proper webcast in which we can see high-quality slides and presentation. Have a proper release presentation that is more user-specific and one that looks more at code-base for the developers.

4. Foundation Governance

As I have said before I believe a project like this needs a good company and a strong leader behind it. We have that with Frappe and Rushabh. However, as they have identified themselves, to have long-term trust in the foundation and the independent viability of the product as such we need a strong foundation with its own governance. It is somewhat problematic that the foundation and frappe are so entangled, at the same time nobody is really stepping up and the foundation can’t live on its own.

I don’t really have answers or suggestions. The only thing I would suggest is to try to keep the funds and not spend them lightly and to try to ensure the long-term viability of the foundation as a self-governing entity. At least this should be the goal.

Besides those topics that I addressed above here are some more thoughts on what would be a good road-map for the stability of the core system rather than be widening the domains:


  • Make Datatables stable
  • Better PDF library to replace WKHTMLTOPDF which does not messes up styling (or integrate it better)
  • Pay more attention to website and portal modules
  • Create better webforms
  • Clean up the 10 years of code, refactor and spend more time on improving docstrings
  • Do a security analysis and try to find security issues more consequently
  • Better Project Management
  • Single Doctypes to be linkable on Desk
  • Multilanguage websites
  • More stable releases that are tested better to be enterprise ready
  • Modern design for the website and some attention to the website module
  • Webpages need to be redesigned to feature modern technology like vue.js that hook to DocTypes with
  • Handling big screens better for more information displayed

Thanks for reading!



For a change, people should start taking responsibility for things they want to see in the product / community / foundation.

This is an open source project. This is a bazaar. No one pays frappe to do the things we do, so its not fair to demand something from us.

All of us belong to this bazaar, there is lots of opportunity to do something and contribute positively. Rights have always been given to people who want to do things. For example we have been very very liberal in giving moderator access on the forum and write access on the core repos.

This is a community and there are shared responsibilities. Lets talk about responsibilities too. This is the beauty of open source. Wikipedia is built by volunteers, Wikimedia foundation does not do all the heavy lifting.