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?
:
Verschoben durch Moderator
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. ;-)
:
Bearbeitet durch User
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
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.
In dieser Liste fehlt Fakturama https://www.fakturama.info/downloads/ Bisher mein Favorit Gruss Bernd
Bernd B. schrieb: > In dieser Liste fehlt Fakturama Es ist kein ERP; deshalb muss es auch in der Liste fehlen.
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! :-)
Hat jemand die Open Source Version von Helium V mal installiert oder ein Userforum gefunden? Gruss und Danke Bernd
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 ;)
Beitrag #6683992 wurde von einem Moderator gelöscht.
Beitrag #6684007 wurde von einem Moderator gelöscht.
Beitrag #6996410 wurde von einem Moderator gelöscht.
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.