ERPNext - cost-effective ERP solution

[jadudm]

@andreasdueren I've packaged one or two things for myself on Cloudron, and I took a look at Frappe/ERPnext.

First, for the thread: Cloudron does not run Docker images "as-is." Or, if you prefer, simply because a project runs in Docker does not mean that it will immediately be runnable under Cloudron. A Cloudron app needs to be packaged up so that it will "play nicely" with the control architecture that Cloudron provides. Put simply, to get that friendly Cloudron experience, some work is needed when packaging an app.

In the case of ERPnext, it has a compose file that specifies many software services. Traefik is used for routing and load balancing (I assume); Nginx fronts the service; it seems like Frappe (the API backend) is written in Python (another service). There's worker processes of several flavors, a scheduling service, a Redis cache, MariaDB (which, for porting to Cloudron, we'd want to integrate with it's built-in DB add-on), the site creator service... and a large number of storage volumes.

Cloudron does not, to the best of my understanding, support running docker-compose files. As a result, to package this, we'd have to pull all of these services into a single container image. That would take some thinking, especially since Docker "likes" to have one process per container. Or, if there is another way/it is possible, I don't personally know how to package up a multi-container Cloudron application.

The Cloudron team may have something else to say, but I thought I'd drop a note in the thread that helps explain why this app is a more complex proposition than others (perhaps) when it comes to packaging. Yes, it is open, and yes, it installs easily on a VM when you do a docker-compose up. Unfortunately, that is not the same as packaging things up to run under the Cloudron framework.

[andreasdueren]

@jadudm Fair and not a problem. I'm just a little bit disappointed by the lack of communication. If it won't get packaged for a while then a short note would have been sufficient instead of letting people like me guessing whats planned next.

[girish]

@andreasdueren We are not working on packaging this. We try to leave a note when we start packaging an app. Currently, we are working on 7.1 - https://forum.cloudron.io/topic/5982/what-s-coming-in-cloudron-7-1 and there's also many existing apps that need to be updated.

[girish]

For future reference, I found https://github.com/frappe/frappe/wiki/The-Hitchhiker's-Guide-to-Installing-Frappe-on-Linux . Fairly complicated!

[andreasdueren]

@girish Thank you, that makes it easier forme to decide on my next steps with ERPNext. I'll check out that guide.

[Aizat]

@andreasdueren Hey, sorry for the late reply. I have followed this protocol closely and it works like a charm:

It's fairly straightforward if you apply the same method as the video above, it uses the GitHub method that was posted here.
ERPnext is a solid system, worth the hassle. Good luck
Kind regards.

[infogulch]

From what I've seen looking at the frappe/erpnext system design, it looks like a lot of the service complexity comes from their "bench" system tool that provides multitenancy / "environment duplication" capabilities via their backup and restore system. From my experience being able to branch environments is vital for these kinds of tools, but... that's basically cloudron's core competency. With a bit of work cloudron could probably match any missing features that "bench" has over it.

With bench factored out and its features provided by cloudron directly, I think you'd be left with a single python service that needs redis, mariadb/mysql, and postgresql, which cloudron provides as services already.

Notes:

• "frappe" is the company and also the name of the development/deployment framework for erpnext and other applications developed by the same team
• The frappe/frappe-worker docker image referred to in the frappe_docker/compose.yaml file is built from the source in frappe dir in the frappe/frappe repo
• The bench worker --queue short command (and similar) runs scheduler.py:start_worker()
• The queue workers are a Python RQ-based job scheduling/background task system. RQ uses redis queues

[nj]

Teaser

[nj]

Two major issues that I ran into while testing on cloudron.

• frappe framework requires the database name and database username to be the same (its hardcoded and all over the place). When testing locally it worked but in cloudron, db name is appended with “db” and username with “user”

• frappe framework needs root access to the database, eg. password of the user named “postgres” (its hardcoded, even if —dbroot-username exists, it’s for mariadb only)

That’s why I’m running postgres server on the Docker container itself, and not use any db addons. I’ll map the db storage to /app/data so it gets backed up regularly.

See you guys with good news next time. Most apps made in Python seem to write all over the filesystem so I’m testing it on readonly environment; once done ErpNext should be available soon. Thank you for your patience.

[girish]

@nj said in ERPNext - cost-effective ERP solution:

frappe framework requires the database name and database username to be the same (its hardcoded and all over the place). When testing locally it worked but in cloudron, db name is appended with “db” and username with “user”

That's a pretty rough requirement but we can fix the platform code I guess to have an option to generate such names.

frappe framework needs root access to the database, eg. password of the user named “postgres” (its hardcoded, even if —dbroot-username exists, it’s for mariadb only)

Keeps getting rougher There's no chance we will allow an app to have root db access.

Is the situation any better with mariadb instead of postgresql?

[infogulch]

frappe framework needs root access to the database

Surely this is not actually necessary to run the app, but is just part of their custom dynamic deployment system (ick). I hope it's possible to extricate the actual app from the framework...

[nj]

@girish for the initial release, I've given up on the idea of using Cloudron addons for now. Postgres is also getting over-complicated so I think I'd stick with MariaDB. Let's see how it goes. The build-run-test cycle is quite tedious when there are all kinds of new errors to resolve. ErpNext turned out to be a lot harder than I expected.

Current status: frappe installed, up and running. ErpNext won't install, and require all its dependencies (apps) to be installed. My target is to publish it by this week.

[nj]

@infogulch said in ERPNext - cost-effective ERP solution:

frappe framework needs root access to the database

Surely this is not actually necessary to run the app, but is just part of their custom dynamic deployment system (ick). I hope it's possible to extricate the actual app from the framework...

I thought so too. Unfortunately, it keeps asking for "postgres super user password".

[LoudLemur]

@nj Thanks for all your hard work. Few have the necessary skills.

[nj]

Help Needed. Please check issue on github.

I'm inches away from either successfully running ErpNext or quitting the idea of packaging it. Never had I ever stuck with this kind of stupid errors.

When everything goes smooth, one of the modules (Payment Module in particular) make the entire table crash in the middle of loading the modules. Fix one error, then another pops up, then another.

I no longer have time nor patience to package this after this week. Here's the progress.. github.com/njsubedi/cloudron-erpnext if anyone has time, skill and patience, please go ahead and continue packaging this piece of sofware.

If anyone knows people from Frappe, please tell them to stop putting spaces and uppercase letters in table names, and at least retry any database operation instead of leaving the entire database in broken state when something fails, then have the user restart the minutes long process from the beginning.

Hours spent: 100+

Please check the issue on Github

[marcusquinn]

@nj You might not want to hear this, but in 100 hours, you could probably reproduce anything you need from ERPNext in EspoCRM using the Entity Manager to build copies of any specific data structures and Reports for anything specific there.

That's basically a lot of what I've been doing lately, taking Espo from being a CRM to an ERP system.

[nj]

@marcusquinn I could do the entire EspoCRM in Directus if I had to.

I wanted to package it because it's one of the most wanted apps, but I think it takes someone else who knows python and databases more than me.

[marcusquinn]

@nj After 18 months working with Espo, I doubt it, and I'm a fan of Directus too.

I see value in having ERPNext, and Odoo, packaged and available too. Even if only so that people can compare all of these similar apps, and take inspiration from all of them to make the best solution with the one they choose to develop among them.

I think you're right though, this one needs cooperation from the original author if it's not versatile enough to handle errors in building in Cloudron's tighter security Docker environment.

[nj]

Trailer
You know what's disappointing? I started packaging ERPNext for the HR module. Unfortunately, the HR Module is not available after installation. Now I'm here thinking where the hell it go, and why I spent weeks packaging something that doesn't have the particular module I was looking for.

Update: Looks like version-14 of ERPNext does not have HR module. Only version-13 has it. Now packaging version 13.

[subven]

@nj said in ERPNext - cost-effective ERP solution:

Looks like version-14 of ERPNext does not have HR module.

They refactored the HR and Payroll module into a "new" app --> #31467. Maybe this could still be installed within the current V14 docker app --> ERPNext HRMS installation.

PS: Thank you for your hard work