[Roadmap] Path to v9

ERPNext
61

Yes wholeheatedly agree about a LTS, even stability in Master would be nice. Did you know a recent commit broke email incoming usage so it sucked 99% cpu and i ended up with many lost emails due to 300s timeouts on the html parsing? Its fixed now but was broken for about 10 days … this is just not acceptable in any business.

I really like ERPNext and what Frappe have done but if I hadn’t been just using this for test and had have implemented it a few weeks ago, it would be dead on its feet by now …

5 Likes
62

I understood something completely different. The market for, say, a paypal or bitcoin integration, that could actually be very strong and reasonably portable. If that’s where you’re headed, good luck!

63

You can not compare a linux distribution composed of thousands of packages, in the case of debian with +43,000 in the main repository, with specific software.

With the current release plan, the time to make a new version is less than 6 months, since the tests and patches of the current and previous version are mixed with the development of new features.

This does not mean that previous versions have to disappear when a new one comes out, it would always keep two or three versions active. With periods of 12 months means that they would have a life of 36 months (3 years).

Another approach would be to adopt the new Django release system. What they are going to do is launch releases every 6 months but with ‘minimal’ changes being the important version to change every 3 of these (2.0, 2.1, 2.2, 3.0, 3.1, 3.2, 4.0, 4.1, 4.2 …). With this release plan the LTS version is always the version * .2 (2.2, 3.2, 4.2 …) I personally like this versioning system quite clearly that if you want to help in development you can use the versions .0 and .1 if you want stability you must implement the .2 always

1 Like
64

I have suggested before that if the team can at least maintain n-1 for 1 year with bug fixes only that would go along way. In this case the 7.2.x branch would be maintained until A) 1 year passes or B) v9 comes out making v7 n-2. bench needs to be fixed to actually handle the switch that is mentioned in the upgrade function to stay on a particular version. git supports this dual branch system today.

The release cycle also needs work. As to @Julian_Robbins comment. Way too often a release fixes or improves one thing but break one or more other things. There needs to be a process in place where releases are tested before being merged into master and let loose to the world.

I have gotten in the practice of every month updating by test instance. I restore the prod database there since they are both the same version and then update the code base and do some regression testing. Right now it is a bit ad hoc. I want to create an actual test plan, but have not had the time. However, even with my ad hoc testing I find strange behavior. I wait a few days and a few releases and then the issues do get fixed, often without a git issue being opened and often with hardly no mention in the notes.

I am pretty sure we all experience this. This conversation has lots of other examples on it.

6 Likes
65

I think James’s idea sounds sane. I appreciate all software has bugs but if it was a car that would very occasionally just stop or only go along at 10mph we’d have something to say about it. But when the update does things like this (which I’ve seen this week a couple of times) then I think it shows it did need more testing.

1 Like
66

Warehouse > Location

This seems fine, but what about the accounting? having an account for bins doesn’t make sense. Also, having to request parts from a specific bin within a warehouse isn’t practical. For this reason I have added two custom fields in the item file: Primary Location and Secondary Location. I would have rather used warehouses, but it was too much.

Delivery Note > Fulfilment

This doesn’t sound like a document as much as it sounds like a category. I would like to see improvements to the packing slip DocType, right now I have a custom workflow on the Delivery Note so that the Packing team packs the order > The order is cleared by the Customer Support Team > The order is cleared by QA > The order is shipped. One problem with the delivery note that I have found is that if you wanted to ship two orders with different POs, the first PO loaded will be overwritten. There needs to be a way to record both. Also, in our case, If there was a problem with the Batch/Serials, it would be nice if there was some way to test the validation that happens when submitting without actually submitting. This way the pack team could catch problems early.

UOMS

Being able to change the UOM in the sales order would be helpful. Being able to change it in BOMs seems like it should have already been there.

Edit 1: LTS is a great idea. Currently we are using V7 at our company, and probably will be for the next year, simply to avoid too many changes.

Edit 2: Make all child tables blank on creation of a new document. This seems to be a perpetual source of confusion here.

Edit 3: Either add the ability to assign multiple batches to one line item in a delivery note, or the ability to split a line item so that it still links with the sales order.

Edit 4: Better revision control for items. Not sure what that would look like, but something better than having different item files for different revs.

4 Likes
67

totally agreeing. there has been a discussion (including a procedure as a result) about this here though.

However I found 1 record in the forum it has been applied before 7.2.0 release but only a small comment on the side pre v8 release

So maybe the existing procedure needs to be better enforced.

68

I find it interesting that there isn’t much multi-company support. Yes you can create multiple companies and set different permissions. But in terms of functionality some limitations arise:

  1. “Default” values are available but since many of them are tied to company specifics they aren’t that useful. For example DocType Items have several “default” vaules like “Default warehouse” but since warehouses are tied to companies it’s only useful for one company. We should be able to set the defaults per company.
  2. inter-company/intra-company transactions are non-existant. For example, doing a company to company transfer of stock. There is more than just stock journal entries but accounting entries that might be invoved. ie. This may be considered a purchase order from one company to a sales order to another company. The landed cost is something that needs to take into account.
  3. Consolidates reports for the multiple companies in finance reports.

there are a couple of scenarios I can think of where these are useful:

  1. Sub-contracting: one company sub-contracts to other companies that are related
  2. Drop ship orders: one company is the distributor/retailer and another the manufactured that drop ships the order
  3. Franchise and Franchisee.

I believer erpnext is well suited for doing inter-company transactions. it just needs a little work to get it done. I have some custom code that has some of this functionality. I just don’t know how to submit it and it may need some refining.

Nathan

2 Likes
69

@Tropicalrambler and @revant_one are both looking at multi-company and consolidation efforts, maybe in slightly different directions.

70

You seem to be a very condescending guy. I respect the fact that ERPNext is a great piece of software, even though it’s not perfect. But the point raised about having to do some git stash and reset and some other git incantations just to run an update has happened to me as well even though I didn’t edit any file.

Your responses to some posts are needlessly inflammatory, condescending and sometimes outright unprofessional.

ERPNext has a really shitty upgrade process. I have never ever had a smooth upgrade right from V3. All installs that I have, I have decided to leave them at V7. I won’t bother upgrade. And as I speak, I am scaling down my recommendation of ERPNext to clients.

As a project, I deeply respect the community behind it, but user bkm raised genuine points about upgrade. At the moment, it’s garbage.

As a Java EE developer, I thought I could learn the frappe framework and see if I could contribute to ERPNext. Yes I can program in python quite comfortably. Spent my hard earned mobile data to download the frappe framework, followed the Library Management tutorial to the letter, time to run app, and poof! Crash. I have to run git incantations. Seriously?

If I can’t get a hello world of the framework, how can I be confident to contribute as a programmer? The elitism of the likes of Rushabh will be the end of this project.

3 Likes
71

Just my opinion, stability is the key. After updates, some database for custom app went missing. Also gone were custom naming series and I have to key in all again. Multi currency still need sorting out. There are many other things other users faced I am sure and this does not bode well for an ERP system where it is a mission critical software for businesses. At the end of the day, it is very frustrating for end users, be it developers or not.

Hope the Foundation look at stability of v8 before attempting to v9. The new features of v8 are great and I am sure it will take us quite a while to play around with it.

I like @James_Robertson post to solely focus on making things work for v8. Let it be a year or two. I just want stability especially after an update. It is at the hands of the Foundation to take ERPNext to the next level.

Looking forward to a stable v8.1!

4 Likes
72

I have recently got attracted to ERPNext, so keeping a low profile. Initially I thought this is just a wishlist of items for v9, which will help in creating the official v9 roadmap. However that doesn’t seem to be the case looking at another thread where community developers have already started working on the python migration(First Foundation supported Developer! - #10 by vrms). I can’t question the priority of python 3.0 migration, so merely trying to stress the importance of improving the process and communication. Sometimes we need to slow down in order to move faster later, especially while there are so many voices vouching for quality before features. Discussions take a lot of time, often feels counterproductive for many people. However that is essential when we are trying to scale-out the development with community help. Perhaps v9 roadmap is being discussed officially in community meetings, in which case it would really help to get a glance of meeting minutes.
I was in the recent code-sprint held at Kozhikode, so had the privilege to discuss the reasons behind merging healthcare to erpnext. While I understood the reasons to some extent, it also raised many more questions, like scale-out issues with same approach for other apps, unnecessary increase in upgrade times, stability, additional effort by the app team for merging, upgrades etc. Traditionally, in our design meetings, we used to have a table of advantages and disadvantages with priority for each item when it comes to deciding these things. By opening these discussions to wider community, we are likely to get more inputs which would help in taking decisions based on data.

1 Like
73

Love the enthusiasm and passion of everyone wanting stability. I think this is a great time for all of us to revise the first rule of open source software.

If you don’t like something, fix it.

–

Happy testing and fixing bugs :slight_smile:

7 Likes
74

Yes, but remember very many users of ERPNext are NOT programmers just users. I for one would not have a clue how to start fixing anything - nor would I want to. It would take me away from my real job - running the company that uses ERPNExt software.

  1. Fix the bugs to create a stable system
  2. Use something like Uservoice (or an equivalent open source system) for users to put in requests for enhancements / improvements and to be able to vote on them. That way the most popular requests are processed first
  3. Test each small improvement to death - never lose sight that the software is being used by real people in real businesses on a daily basis we NEED the software to function as it should all of the time
10 Likes
75

Regardless whether users or contributors, remember what rmehta is coping with here…

10 Likes
76

For me, I have to favorite feature requests:

  • import data from bank
    We have a lot of small amount invoices. I get a csv export from my bank account and it would be lovely to import the bank statements and create payment entries and link them to the invoices and set the status to “payed”.

  • usability:
    When I create a new customer, for example, I have to enter customer detail in the form. Then I have to create a new contact in a new form, save it and come back to the customer. Finally I have to create the Address details in a new form, save it and come back.
    → I would really like to have a possibility to enter contact and address details within one form (e.g. when selecting “create new contact” the new contact form will be shown inline the customer form)

This would help me to save a lot of time :slight_smile:

5 Likes
77

Some thoughts from my end:

###Framework

  1. Allow more columns to be displayed in Grid for “desk” view i.e if a user is logged in from desk,it should allow more than 4 columns to be shown in the grid. This can be detected based on the form factor of a device.

###Manufacturing

  1. Process based manufacturing, sequencing & bulk movement of stock from one process to another.

###Finance

  1. Inter-company transactions
  2. Bank Reconciliation

###Integrations

  1. Quick Books
  2. Tally
5 Likes
78

  • It would be nice the system send customer statment based on if theres is an outstanding.

  • On Accounts Receivable when convert to pdf, apears age(days)

  • Create a form to make sales partner payment, and clear the statement after the payment

79

@Dany_Carvalheiro It seems that this could be “easily” done by customizing …

80

I have not looked at this thread for a while, but now that @Chude_Osiegbu is leading the Roadmap group for ERPNext Foundation, and I’m his able(?) Deputy, this is a lot of excellent inputs we can work with.

I fear that we will not be able to meet all expectations and therefore there will be some disappointments and heartache to go around. But hopefully it will be minimal and I hope that we can all still be on talking terms a few (and many) years into the future.

I can’t claim that I’ve looked at each post, but I get the gist:

  1. Yes, the current upgrade process sucks and we (please note the WE here) need to get better.

  2. Everybody talks about stability. We need to get more stable.

These two are easy to find agreement. Where we may vehemently disagree is the new features, but we hope to put in a process that is transparent.

I saw a lot of big words being used and calling people names, even if such names are not Terrible names, it can still dampen the enthusiasm.

PLEASE NO PERSONAL ATTACKS PLEASE! Yes, I thought that sentence required two pleases. :slight_smile:

As far as fixing existing issues or adding new features is concerned, a lot of people have ideas. These ideas will be harnessed and we will come up with a roadmap. If your idea is up for execution on the roadmap soon, you’ll be happy.

What avenues do you have if your need or requirement is not on the Roadmap or is on the roadmap, but is not for immediate execution:

  • Build that yourself and contribute the code back to ERPNext.

But, I’m not a developer:

  • Find a developer and fund her/him to develop that fix or feature and contribute that code back to ERPNext

I can’t find a developer

  • Fund the development through Foundation developers - Only for those features that are on the roadmap

If you cannot do any of the three and we build a transparent and reasonably democratic way of building the roadmap in the first instance, would it be fair to expect you to wait till somebody (and it could be the Foundation) fixes it or develops that feature.

If you’ve lasted this long, it can only mean one thing: You are really keen on this roadmap thing. How about volunteering your time on the Roadmap committee?

Thanks

Jay

9 Likes