mikrocontroller.net

Forum: Ausbildung, Studium & Beruf Open Source ERP Systeme


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Julian B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,
ich beschäftige mich gerade damit ein ERP für mein kleines Unternehmen 
zu suchen. Selbst schreiben kommt definitiv nicht in Frage, da man mit 
seiner selbst gestrickten Bastellösung sowieso nie zufrieden ist.

Erstmal soll es Quelloffen sein und möglichst nichts in der Anschaffung 
kosten. Falls das nicht möglich ist wäre die zweite Option etwas dafür 
zu bezahlen.

Ich habe bisher mal Dolibarr genauer angesehen und muss sagen, dass es 
von den Funktionen her genau das hat was ich brauche. Die Oberfläche und 
insbesondere die Barcodefunktion ist einfach klasse gelungen.

Leider musste ich feststellen, dass die Datenbank ziemlich gefrickelt 
wirkt (Habe es mit Postgresql probiert). Die Spaltennamen sind eine 
Mischung aus Englisch und Französisch. Darüber kann man hinweg sehen. 
Bei der Migration einiger Testdaten ist mir jedoch ziemlich sauer 
aufgestoßen, dass die Datenbank relativ leicht in einen inkonsistenten. 
Beispielsweile werden die extrafield von Lieferantendaten nicht mit 
einer CASCADE Anweisung mit den Extrafield verknüpft, was im Endeffekt 
heißt, dass die Extrafield auch bei Löschung eines Lieferanten erhalten 
bleiben. Generell wird ziemlich wenig mit Constraints in der Datenbank 
gearbeitet, was ich für meine Zwecke schade finde, da für die Zukunft 
eventuell doch mal selbst geschriebene Tools mit der Datenbank 
interagieren sollen.

Bei Durschsicht des PHP code ist mir ebenfalls aufgefallen, dass SQL 
Strings generiert werden und direkt ausgeführt werden. Prepared 
Statements scheinen wohl an denen vorbeigegangen zu sein.

DIe Wikipedia Tabelle zu ERP Systemen ist jetzt auch nicht so lang. 
Ledger habe ich wegen Perl nicht richtig ans laufen bekommen. Werde dann 
mal die Java basierten Tools evaluieren wobei ich persönlich kein großer 
Java freund bin. hat jemand vielleicht erfahrung mit Alternativen, die 
vom Funktionsumfang etwa das können, was Dolibarr mir bietet?

Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Julian B. schrieb:
> Ich habe bisher mal Dolibarr genauer angesehen und muss sagen, dass es
> von den Funktionen her genau das hat was ich brauche. Die Oberfläche und
> insbesondere die Barcodefunktion ist einfach klasse gelungen.
>
> Leider musste ich feststellen, dass die Datenbank ziemlich gefrickelt
> wirkt (Habe es mit Postgresql probiert). Die Spaltennamen sind eine
> Mischung aus Englisch und Französisch. Darüber kann man hinweg sehen.

Also, wenn das System kann, was Du suchst, und Dir im Wesentlichen nur 
eine konsistente Benamsung der Datenbankobjekte sowie ordentliche 
Constraints fehlen (was mich im Übrigen sicherlich genauso nerven würde 
-- eine DB darf nie in einen inkonsistenten Zustand geraten), dann wäre 
es doch eventuell eine Möglichkeit, Dich mit konstruktiven Patches und 
Deinem Fachwissen an diesem Projekt zu beteiligen? Diese Dinge dürften 
doch recht einfach zu realisieren sein (ich kenne das Projekt allerdings 
nicht und weiß deswegen auch nicht, wie aufwändig das wäre).

Auch Deine geplaten Skripte und Tools könnten im Übrigen durchaus eine 
sinnvolle Erweiterung für das Projekt darstellen.

Ein sicherlich deutlich weiter gehendes Unterfangen wäre es, die manuell 
zusammengestoppelten SQL-Queries durch ordentliche Prepared Statements 
oder idealerweise sogar durch einen leistungsfähigen OR-Mapper wie 
Doctrine zu ersetzen. Aber einen Vorschlag ist das IMHO vielleicht 
wert... ;-)

Wie dem auch sei und wie viel oder wenig Du bereit bist, Dich im Projekt 
zu engagieren: am Ende lebt OSS vom mitmachen.

Autor: Tobias B. (Firma: www.elpra.de) (ttobsen)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Julian B. schrieb:
> Erstmal soll es Quelloffen sein und möglichst nichts in der Anschaffung
> kosten. Falls das nicht möglich ist wäre die zweite Option etwas dafür
> zu bezahlen.

Ich kann dir nur empfehlen dich von diesem Gedanken zu lösen. 
Quelloffene Software ist meiner Meinung nach eine erstrebenswerte Sache, 
keine Frage. Aber von der Suche nach möglichst kostenfreier Software 
würde ich mich im Unternehmensumfeld ganz schnell von distanzieren.

Stelle besser eine Kosten/Nutzen Rechnung auf und wenn dir der Einsatz 
einer Software mehr Geld spart als sie kostet, greife zu.

Ein persönliches Beispiel von mir ist Gitlab. Der Kern ist quelloffen, 
jedoch kostet die Enterprise Version gutes Geld, dass ich gerne bereit 
bin zu bezahlen. Der Einsatz der Software spart mich einfach deutlich 
mehr Geld als ich investieren muss. Durch die Quelloffenheit habe ich 
sogar die Möglichkeit innerhalb der Community Einfluß auf die Software 
zu nehmen (leider nicht durch Code Commits, da ich kein Ruby 
Programmierer bin, jedoch durch konstruktive Kritik und Vorschläge).

Just my two cents.

Autor: Hans (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Ganz im Gegenteil.

Dein Beispiel Gitlab zeigt ganz genau was der TO nicht haben möchte.
Das ding funktioniert möglicherweise *bian  und *hat oder M$ jeweils in 
Version 42 aber das wars.
Dagegen rennt beispielsweise gogs "einfach so" weil sauber implementiert 
und ohne schräge dependencies.

Zum Thema kann ich leider nix beitragen... suche selber...

73

Autor: Mathefreak (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Wenn erstmal open source gefragt ist dann sollte man das so hinnehmen. 
Wenn der Hersteller mal dicht macht stehst du nämlich blöd da. Dann hast 
du im besten Fall eine Datenbank, die du mühsam migrieren darfst.

Gitlab haben wir bei uns auch aber das ist rausgeschmissenes Geld. 
Gerade für gut reichen recht einfache tools und dieser Ruby Tanz bei 
gitlab ist ja grauenhaft.

OK zum Thema. Es gibt noch postbooks, was auf plv8 in Verbindung mit 
PostgreSQL aufbaut. Das haben wir mal evaluiert und die die Nutzer sind 
von der GUI aus direkt an der Datenbank angebunden. Das usermanagement 
macht also PG. Die Oberfläche erschlägt dich.

Autor: Dienstleister (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
> Aber von der Suche nach möglichst kostenfreier Software
> würde ich mich im Unternehmensumfeld ganz schnell von distanzieren.
Ich habe selbst vor einigen Jahren ein Unternehmen in den USA gegründet 
und unter Verwendung hauptsächlich quelloffener Software betrieben. Nach 
ein paar Jahren (bei 20 Mitarbeiter angekommen) habe ich den Laden 
verkauft.
Es gab einen Käufer - trotz des ungewöhnlichen Ansatzes und der in der 
Industrie vorhandenen Fixierung auf proprietäre Systeme.
Trotz - oder vielleicht aufgrund?

Julian B. schrieb:
> ich beschäftige mich gerade damit ein ERP für mein kleines Unternehmen
> zu suchen.
Julian B. schrieb:
> DIe Wikipedia Tabelle zu ERP Systemen ist jetzt auch nicht so lang.
Sei froh.
Denn meines Erachtens wird Dir nichts anderes bleiben, als:
- Dir vorher gründlich Gedanken über die Prozesse zu machen, die Du 
abbilden willst. Niemand hier kann Dir raten, denn niemand kennt Deine 
Geschäftsprozesse so wie Du.
- dann Odoo, Adempiere, xTuple usw. alle in virtuellen Maschinen zu 
installieren und Deine Prozesse durchzuspielen,
- dann hinter die Kulissen zu schauen, ob Du mit dem Konzept, der/den 
Programmiersprachen usw. klar kommst. Oder ob Du das outsourcen musst.
Viele quelloffene Systeme sind dann auch nicht wirklich kostenlos, 
sondern der "Hersteller" bietet kostenpflichtigen Service und 
Anpassungen. Das "quelloffen" heißt dann nur, dass man Zuarbeiten, die 
andere uneigennützig zur Verfügung stellen, gerne aufnimmt, wenn sie 
denn ins Konzept passen.

Ohne Deinen Laden zu kennen, kann man nur raten.
Also lass Dir nicht raten. Wühl Dich da selber durch. Es ist Dein Laden. 
Du bist der Entscheider, Du löffelst die Suppe auch aus.

Autor: Tobias B. (Firma: www.elpra.de) (ttobsen)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Vielleicht kam das falsch rüber, aber ich habe mich klar FÜR quelloffene 
Software ausgesprochen. Jedoch heißt quelloffen nicht gleichzeitig 
umsonst. Freie Software ist nunmal frei im Sinne von Freiheit und nicht 
Freibier.

Daher auch mein Einwand: Man sollte im Business Umfeld nicht umsonst als 
Vorgabe setzen, sondern Kosten/Nutzen.

Hans schrieb:
> Dein Beispiel Gitlab zeigt ganz genau was der TO nicht haben möchte.
> Das ding funktioniert möglicherweise *bian  und *hat oder M$ jeweils in
> Version 42 aber das wars.
> Dagegen rennt beispielsweise gogs "einfach so" weil sauber implementiert
> und ohne schräge dependencies.

Ich verwende sowohl Gogs als auch Gitlab. Gogs auf einem Server im 
Internet, Gitlab rein im Intranet, aufgesetzt als Docker Container.

Kann deinen Standpunkt bzgl. Gitlab in keinster Weise nachvollziehen, 
evtl. solltest du deinen SysAdmin wechseln. Und auch Gogs hatte bis vor 
kurzem extreme Probleme im Zusammenhang mit MySQL, z.B. das hier hatte 
echt Ärger gemacht: https://github.com/gogs/gogs/issues/4894

Alles in allem ist die Code Qualität von Gitlab um einiges besser als 
bei Gogs. Beide Entwicklungsprozesse sind offen und können problemlos 
mitverfolgt werden, einfach mal reinschauen. Wäre auch traurig wenn es 
nicht so wäre, bei Gitlab arbeiten schließlich eine Menge Leute auf 
Vollzeit.

Vielleicht wäre einfach mal eine Gitlab Schulung notwendig, biete ich 
gerne an. ;-)

: Bearbeitet durch User
Autor: Stefan H. (Firma: dm2sh) (stefan_helmert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tryton könnte nützlich sein. Man muss aber noch viel selbst 
konfigurieren. Ich habe das einmal ausprobiert:

https://github.com/TheTesla/tryton-invoice-template

https://github.com/TheTesla/ansible-tryton

Autor: Anon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich werfe hier einfach mal ERPNext ein. Im Produktiveinsatz hatte ich es 
noch nicht, allerdings sah es auf den ersten Blick sehr gut aus.

https://erpnext.com/

Autor: Julian B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich wollte nur mal beitragen wie der Stand ist. Wir haben jetzt auch ein 
paar Java basierte Systeme getestet. Um mal ein Beispiel zu nennen gibt 
es Ofbiz. Die Oberfläche wirkt wie aus den 90ern und die Datenbank ist 
eher unaufgeräumt. Haben wir dann gleich mal verworfen.

Bei Tryton ist das Problem, dass man immer eine gesonderte Anwendung für 
die Oberfläche braucht. Das ist prinzipiell in Ordnung, jedoch ist 
Python meiner Meinung nach die Pest und Python in Verbindung mit 
grafischer Oberfläche erst recht.

Es ist jetzt so, dass Dolibarr genommen wird und daran mitgearbeitet und 
verbessert wird. Ob das in Form eines Forks oder in Form von Patches 
sein wird ist noch unklar. Es bildet unsere Prozesse einfach am besten 
ab und ist gut erweiterbar.

Autor: Tobias B. (Firma: www.elpra.de) (ttobsen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Julian B. schrieb:
> Es ist jetzt so, dass Dolibarr genommen wird und daran mitgearbeitet und
> verbessert wird. Ob das in Form eines Forks oder in Form von Patches
> sein wird ist noch unklar. Es bildet unsere Prozesse einfach am besten
> ab und ist gut erweiterbar.

Danke für das Update. Nachdem ich den Thread gelesen hatte, habe ich 
auch mal geschaut ob was passendes für mich dabei ist. Und Dolibarr hat 
bei mir ebenfals den besten Eindruck hinterlassen.

Dabei bin ich diese Liste durchgegangen

https://de.wikipedia.org/wiki/Kategorie:Freies_Unternehmens-Informationssystem

Es scheint allerdings, dass die alles andere als vollständig ist.

Autor: Bernd B. (berbog)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In dieser Liste fehlt Fakturama

https://www.fakturama.info/downloads/

Bisher mein Favorit
Gruss Bernd

Autor: D.M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd B. schrieb:
> In dieser Liste fehlt Fakturama

Es ist kein ERP; deshalb muss es auch in der Liste fehlen.

Autor: Starlord (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also wir benutzen HeliumV (siehe www.heliumv.com).
Läuft sowohl unter Windows als auch Linux+MacOS

Recht schnell, ziemlich umfangreich aber weniger gute Anleitung.
Die verdienen ihr Geld eben mit Support....

Autor: Julian B. (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Tobias B. schrieb:
> Julian B. schrieb:
>> Es ist jetzt so, dass Dolibarr genommen wird und daran mitgearbeitet und
>> verbessert wird. Ob das in Form eines Forks oder in Form von Patches
>> sein wird ist noch unklar. Es bildet unsere Prozesse einfach am besten
>> ab und ist gut erweiterbar.
>
> Danke für das Update. Nachdem ich den Thread gelesen hatte, habe ich
> auch mal geschaut ob was passendes für mich dabei ist. Und Dolibarr hat
> bei mir ebenfals den besten Eindruck hinterlassen.
>
> Dabei bin ich diese Liste durchgegangen
>
> https://de.wikipedia.org/wiki/Kategorie:Freies_Unt...
>
> Es scheint allerdings, dass die alles andere als vollständig ist.

Vor allem ist es in jedem Browser einsetzbar und als Datenbank wird 
etwas etabliertes benutzt. Es hatte bisher einfach den durchdachtesten 
Eindruck gemacht und anstatt wenig dokumentierte Software zu nehmem 
(HeliumV) und den Support dann zu bezahlen kann man lieber 
Arbeitsstunden in Erweiterung investieren und es nach seinen wünschen 
Anpassen.

Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Julian B. schrieb:
> Bei Tryton ist das Problem, dass man immer eine gesonderte Anwendung für
> die Oberfläche braucht. Das ist prinzipiell in Ordnung, jedoch ist
> Python meiner Meinung nach die Pest und Python in Verbindung mit
> grafischer Oberfläche erst recht.

Das ist allerdings keine fachliche oder technische Frage, sondern nur 
eine Deines persönlichen Geschmacks. Immerhin ist Python heute die 
beliebteste und verbreitetste Allround-Skriptsprache, und dafür gibt es 
gute Gründe.

Eine seriöse Software-Evaluation und -Auswahl wird allerdings primär von 
den fachlichen Anforderungen bestimmt, gefolgt von den technischen. Erst 
wenn am Ende mehrere diesbezüglich gleichwertige Kandidaten vorne 
liegen, dürfen Eure persönlichen Vorlieben oder Abneigungen in die 
Entscheidung einfließen. Dies gilt natürlich insbesondere bei einer 
langlebigen und geschäftskritischen Sofware wie eben einem ERP-System, 
das man ja meist nicht ohne größere Aufwände austauschen kann. ;-)

Bitte versteh' mich nicht falsch, aber ich habe schon zu oft gesehen, 
daß irgendjemand (Admins, Entwickler, Management, ...) sich aus Gründen 
seiner persönlichen Vorlieben und Abneigungen für ein System entschieden 
hat, das die Anwendungsfälle am Ende dann doch nicht optimal abgebildet 
und so oft große Probleme durch Bedien- und Anpassungsaufwänden 
verursacht hat.

> Es ist jetzt so, dass Dolibarr genommen wird und daran mitgearbeitet und
> verbessert wird. Ob das in Form eines Forks oder in Form von Patches
> sein wird ist noch unklar. Es bildet unsere Prozesse einfach am besten
> ab und ist gut erweiterbar.

Ich finde es gut, daß Du / Ihr meinen ersten Vorschlag beherzigt und 
Euch an der Entwicklung beteiligen wollt. Das fördert nicht zuletzt auch 
Euer eigenes Verständnis der betreffenden Software, was wiederum die 
Entwicklung von Erweiterungen und des eigenen Toolings erleichtert und 
beschleunigt. Und am Ende hat sogar die OSS-Community etwas davon, 
prima!

Allerdings noch ein abschließender Tipp: einen eigenen Fork zu machen, 
ist im Zweifelsfall meistens teurer als die eigene Entwicklung ins 
originale Projekt zurück fließen zu lassen. Insofern ist es vermutlich 
die beste Idee, Euch mit den Entwicklern von Dolibarr in Verbindung zu 
setzen und herauszufinden, ob diese überhaupt Interesse an Eurer 
Mitarbeit im Projekt haben, ob die von Euch gewünschten Änderungen 
willkommen sind, und ob Ihr eine gemeinsame Sprache finden könnt.

Bitte bedenkt dabei: diese Leute kennen Euch und Eure Fähigkeiten nicht, 
daher solltet Ihr Euch für Eure Kontaktaufnahme ein wenig Zeit nehmen 
und dabei unbedingt sehr behutsam vorgehen. Aus der eigene Erfahrung 
weiß ich: viele OSS-Projekte haben so ihre Schwierigkeiten mit 
dahergelaufenen Klugscheißern, die ihnen sagen wollen, wie "man es 
richtig" machen würde. Insofern: vielleicht erstmal die Software loben, 
dann ein paar kleinere Verbesserungsvorschläge (die Sache mit den 
ForeignKey-Cascades hattest Du hier ja schon angesprochen) machen, und 
dann freundlich nachfragen, ob die an einer langfristigen und 
dauerhaften Mitarbeit interessiert sind. Und, ach ja: auch einer 
finanziellen Unterstützung sind viele OSS-Projekte durchaus nicht 
abgeneigt -- die Vereinssatzung des Dolibarr-Vereins ist diesbezüglich 
recht aufschlußreich.

Viel Spaß und Erfolg! :-)

Autor: Bernd B. (berbog)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat jemand die Open Source Version von Helium V mal installiert  oder 
ein Userforum gefunden?

Gruss und Danke
Bernd

Autor: Dr. Orgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nimm SelectLine oder deren mitbewerber, aber spare die nerven und zeit 
mit dem OSS gefrickel... es hat schon gründe warum niemand bei verstand 
auf OSS ERP setzt ;)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.