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?
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.
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.
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
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.
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.
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. ;-)
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/
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.
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.
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....
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.
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! :-)
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 ;)
Dieser Thread ist jetzt schon etwas älter, allerdings ist das Thema Open
Source ERP nach wie vor für viele relevant, daher eine kurze Ergänzung:
Wir waren ebenfalls auf der Suche nach einem Open Source ERP-System.
Open Source nicht wegen des Preises, sondern wegen der Möglichkeit, ggf.
eigene Anpassungen vornehmen zu können - und um bereits im Vorfeld
schauen zu können, wie zugänglich/verständlich das System für solche
Aktivitäten gestaltet ist. Anpassung, da wir einen eigenen SaaS-Service
über das System verwalten und abrechnen wollten, was mit den üblichen
Standard-Shop-Anbindungen nicht machbar ist.
Kurzum: Wir haben uns ebenfalls für Dolibarr entscheiden - nach einer
sehr gründlichen Recherche, um nicht versehentlich unsere Ideallösung zu
verpassen. Dazu haben wir zunächst nach allen auffindbaren Open Source
ERP-Systemen gesucht - und 44 Stück gefunden (die oben genannte
Wikipedia-Seite ist in der Tat nicht vollständig). Wenn man die
eingeschlafenen/übernommenen/umbenannten Projekte herausfiltert, bleiben
16 aktive, "echte" Open Source Projekte übrig. Und nachdem wir uns mit
allen beschäftigt haben, war für uns Dolibarr die geeignetste Lösung.
Das kann individuell je nach Kriterien natürlich anders sein.
Bisher hat sich unsere Entscheidung als richtig herausgestellt - wir
nutzen Dolibarr seit einem Jahr und sind immer noch sehr zufrieden.
Einige Verbesserungen haben wir inzwischen selbst ins Projekt einfließen
lassen, und die Zusammenarbeit mit der Community war dabei auch immer
positiv.
Wer jetzt selbst auf der Suche ist: Wir haben die gesamte Liste der 16
Open Source ERP-Systeme, die wir identifiziert haben, in unserem Blog
veröffentlicht: https://www.bloxera.com/blog-open-source-erp-liste.php
Businesses with more than a handful of employees have a lot to balance
including pricing, product planning, accounting and finance, managing
payroll, dealing with inventory, and more. Stitching together a set of
disparate tools to handle those jobs is a quick, cheap, and dirty way to
get things done.
That approach isn't scalable. It's difficult to efficiently move data
between the various pieces of such an ad-hoc system. As well, it can be
difficult to maintain.
Instead, most growing businesses turn to an enterprise resource planning
system.
The big guns in that space are Oracle, SAP, and Microsoft Dynamics.
Their offerings are comprehensive, but also expensive. What happens if
your business can't afford one of those big implementations or if your
needs are simple? You turn to the open source alternatives.
Find Best ERP Software- https://technologycounter.com/erp-software/india
