kleines Warenwirtschaftssystem

[MeisterLampe]

Hi zusammen,

wollte für meinen Vater (selbständiger Unternehmer) eine kleine Warenwirtschaftslösung schreiben.
Momentan wird alles mit Excel gemacht. Materialliste, Auftragsdaten, Inventuren usw.
Hintergrund: Da ich in meinen alten Betrieb mit einer an einer Warenwirtschtssoftware (Baustein-System) entwickelt hab bring ich schon einiges an KnowHow zur Umsetzung mit. Nur bei der Umsetzung mit Python und Co. fehlt mir die nötige Kenntnis.

Was ich mir so vorstelle....
Frontend: HTML Masken (simple Formular zur Anzeige, Bearbeitung und Ausgabe von Daten) (mit Druckoptimierung=Reporting)
Im Kern: Python (...???)
Backend: kleines DB-System like SQLite (sollte später dann mal auf ein größeres wie MySQL/PostgreSQL portierbar sein)

So jetzt meine Frage an euch:
Wie setze ich das ganze jetzt am besten mit Python um. (welche Libs - Frameworks - etc.)

Vielen Dank schon mal im Voraus
MeisterLampe

[Hyperion]

Also da würd ich doch einfach mal Django in den Raum werfen. Damit hast Du ein Rundum-Sorglos-Paket bezüglich, Datenbankanbindung, Frontend, Adminoberfläche, Doku usw.

Beim Reporting kommt es sicherlich auch auf die Anforderungen an (reicht ein angepasstes CSS, oder solls schon PDF sein?), aber da gibts ja mit ReportLab eine gute Lib, die man dazu nutzen könnte. Evtl. gibt es aber auch bereits Erweiterungen für Django, die so etwas beherrschen.

Last but not least: Hast Du mal auf dem Open Source Markt evaluiert, ob es nciht etwas gibt, was Deinen Vorstellungen entspricht? Ist der Wunsch nach einer Lösung der Antrieb, so findet man da bestimmt eine Lösung, die das wichtigste bietet, was man erwünscht. Liegt der Fokus bei Dir auf der Entwicklung, so denke ich fährst Du mit Django auf jeden Fall gut.

Evtl. meldet sich ja Gerold mal zu Worte; der dürfte hier im Forum der Experte bei solcher Art von Anwendung sein.

[burli]

Muss es Webbasiert sein? Ich finde solche Programme als Webanwendung grausig. Ich will mal zwei Programme nennen:

1. Tryton: ist ein fertiges WaWi Programm, sehr umfangreich, aber IMHO für vieles gut geeignet und auch für deutsche Buchführung geeignet.

2. Camelot: ist ein Datenbank Frontent, im entferntesten vergleichbar mit Excel. Kann Daten in SQLite, Postgresql und anderen SQL Datenbanke speichern und man kann relativ einfach auch Reports erstellen

[snafu]

@MeisterLampe: Ohne dir zu nahe treten zu wollen, aber ohne Erfahrung in Python würde ich davon abraten, sozusagen als erstes Projekt gleich ein Programm zu schreiben, welches produktiv in einer Firma eingesetzt wird. Das kann u.U. ganz schön in die Hose gehen. Wieso nimmst du denn dafür nicht die Programmiersprache, die du beherrscht? Das soll dich natürlich nicht davon abhalten, mit Python warm zu werden und es vielleicht in 1-2 Jahren für Programme in der freien Wirtschaft zu benutzen. Es gibt doch sicherlich auch Kurse in der Hinsicht, falls du das beruflich machen willst. Oder ist das mehr die Schiene "komm Papa, jetzt programmiert dir dein Sohn mal was feines"?

[sma]

Ich kann nicht beurteilen, wie groß der Unterschied von Excel zu einem "echten" Warenwirtschaftssystem ist und daher nicht den Aufwand abschätzen, aber ich würde ein derartiges Projekt in jedem Fall als Webanwendung angehen, da es auf diese Weise einfach installierbar, von überall erreichbar (wenn man einen Server im Internet hat), hoffentlich einfach benutzbar und schnell anpassbar ist. Screens lassen sich als Webseiten IMHO einfacher bauen als als traditionelles GUI. Und dem Vater wird man ja wohl auch einfach Chrome installieren können um so das Problem zu umgehen, Webseiten noch passend für den antiquierten IE bauen zu müssen.

Ich hatte mir gestern angeschaut, was das neue Ext 4 von Sencha alles so bietet und ich denke, das wäre für so ein Projekt mehr als ausreichend. Allerdings hat Ext eine recht steile Lernkurve. Das Backend könnte man mit Django bauen. Bei einer Ext-Anwendung könnte Django aber seine Vorteile nicht richtig ausspielen, ein anderes einfaches Web-Rahmenwerk, dass JSON-Daten zur Verfügung stellt, ist genauso denkbar.

Stefan

[Xynon1]

...wie groß der Unterschied von Excel zu einem "echten" Warenwirtschaftssystem ist...

Ungefähr zwei Universen, ernsthaft Excel ist nichts weiter als ein Tabellenkalkulations-Programm jedweder anderer Nutzen wird nur über unleserliche und nicht mehr definierbare Macros erreicht.

[sma]

...wie groß der Unterschied von Excel zu einem "echten" Warenwirtschaftssystem ist...

Ungefähr zwei Universen, ernsthaft Excel ist nichts weiter als ein Tabellenkalkulations-Programm jedweder anderer Nutzen wird nur über unleserliche und nicht mehr definierbare Macros erreicht.

Nun, aber es scheint ja zu reichen. Die Frage muss ja nicht sein, was wäre alles möglich, sondern was ist das "minimal viable product", sprich die minimale Version eines Systems, das ein kleines bisschen besser als Excel ist und damit genutzt werden würde.

Stefan

[Xynon1]

Nun, aber es scheint ja zu reichen.

Wieso existiert dann dieser Thread ?

Und sicher kann Excel dafür reichen, wie jedes andere Tabellenverwaltungs Programm auch. Eine Datenbank stellt ja die Daten auch in Tabellen zu verfügung. Allerdings fehlen in Excel alle möglichen Features einer Datenbank, es sind nur einige per Macros von MS selbst nachgezogen. Es gibt aber nicht mal einfache Beziehungen zwischen den Tabellen....

Mit anderen Worten es macht warscheinlich einen ganzen Haufen arbeit damit ein 'funktionierendes' oder 'echtes' Warenwirtschaftssytem zu basteln. <-- und diesen Aufwand nicht nur einmal sondern immer wieder.
Ich denke schon, das Camelot da schon keine schlechte Wahl wäre.

[lunar]

@Xynon1: Bestimmt nicht, um Dir Gelegenheit zum Excel-Bashing zu geben Vor allem nicht bar jeder Kenntnis, denn Excel kennt durchaus Beziehungen zwischen Daten aus verschiedenen Tabellen. Das ist zwar nicht die Art von Beziehungen, die man aus Datenbanken kennt, aber wohl dem, der erkennt, dass Excel keine Datenbank ist.

Vielleicht existiert diese Diskussion einfach nur, weil der OP Spaß daran findet, ein Warenwirtschaftsprogramm für den Betrieb seines Vaters zu entwickeln. Nicht hinter jedem Projekt steht konkreter Bedarf. In jeden Fall Stefans Punkt, dass sich das Projekt an der existierenden Lösung orientieren muss, richtig, Excel hin oder her. Schließlich muss eine neue Software sinnvolle Neuerungen bieten, ohne bisherige Aufgaben zu schweren oder gar unmöglich zu machen, ansonsten könnte man ja gleich bei der alten Lösung bleiben.

Soll heißen, der OP sollte nicht versuchen, ein vollständiges Warenwirtschaftssystem zu schreiben, sondern eine Alternative zur aktuell verwendeten Lösung.

[Xynon1]

@lunar
Sorry, ich weiß nicht das überfällt mich immer wenn ich Excel im Zusammenhang/Vergleich mit Datenbanken höre
Und ja, Excel kann Tabellenbeziehungen darstellen, es ist dennoch ein Graus. Ich empfehle schließlich auch niemanden mit Word eine Tabellenkalkulation zu machen.

Soll heißen, der OP sollte nicht versuchen, ein vollständiges Warenwirtschaftssystem zu schreiben, sondern eine Alternative zur aktuell verwendeten Lösung.

Deswegen wäre Camelot auch keine schlechte Alternative, vorallem weil der Anwender sich nicht sehr umgewöhnen muss. Natürlich könnte man jetzt auch MS Access vorschlagen, wenn schon MS verwendet wird, aber von einem solchen Programm habe ich noch nie etwas gehört .

[lunar]

@Xynon1: Früher war es durchaus üblich, mithilfe von VB betriebliche Anwendungen auf Basis von Excel oder Access zu schreiben. Die resultierenden Anwendungen sehen auch nicht mehr nach Access oder Excel aus, sondern "anders", da man mit der umfangreiche API von Office so ziemlich alles verändern konnte. Es gab und gibt noch immer nicht wenige Firmen, die ausschließlich auf sowas spezialisiert sind, und damit nicht wenig Geld verdienen.

Ansonsten lässt sich nur sagen, dass Excel leicht missbraucht werden kann, aber für den eigentlichen Zweck, nämlich Tabellenkalkulation, mit das beste ist, was man bekommen kann. Insofern muss man nicht vorschnell ein schlechtes Urteil fällen, nur weil Excel erwähnt wird

[Xynon1]

Nein, gegen Excel habe ich doch auch gar nichts, im Gegenteil für das, wofür es gemacht wurde ist es -Excel-lent.
Was ich verabscheu sind die von dir oben erwähnten Methoden, aus Programmen etwas zumachen, wofür sie nie gedacht waren.

[/me]

Was ich verabscheu sind die von dir oben erwähnten Methoden, aus Programmen etwas zumachen, wofür sie nie gedacht waren.

Na ja, das ist die so genannte Ehda-Software: "Die Software ist eh da, lass uns das doch damit machen."

[HerrHagen]

@MeisterLampe: Schau dir Django an. Da ist alles drin was du brauchst. Die Lernkurve ist gerade für jmd. der noch nichts mit Python gemacht hat, recht steil. Aber es lohnt sich auf jeden Fall.

[MeisterLampe]

Ich hatte auch schon an Django gedacht und hab die letzte Zeit damit verbracht auch was zu machen. Das Konzept gefällt mir gut und bis jetzt glaube ich alles damit abzudecken. Un die Lernkurve ist wirklich sehr hoch... macht riesig Spaß

[MeisterLampe]

So .. bin schon recht weit aber ein Problem hab ich jetzt ... hab alles lokal auf meinem Mac entwickelt und es soll auf einem Windows System .. gibt da ne elegante Lösung so ein Projekt samt http+mysql.... auf dem Zielsystem zu bringen? .. das ganze soll nur lokal auf einem Computer laufen (einen extra Server dafür laufen zu lassen wäre unsinnig)

Jemand eine Idee wie man Django Projekte einfach als lokal Anwendung unter Windows zu starten (hab an Xampp gedacht aber der hat kein Python von Haus aus)

[Hyperion]

Na, ohne Webserver geht es natürlich nicht. Du könntest Dir ja mal Leichtgewichtige angucken im Vergleich zu Apache. CherryPy oder Tornado fielen mir da spontan ein; lighthttpd ist zwar ganz nett, aber es gibt iirc keine offiziellen Windows-Binaries. Apache geht natürlich auch

Und MySQL unter Windows zu installieren sollte doch auch nicht so schwer sein.

Was ich mich grad frage: Wenn das ganze nur lokal auf einem Rechner laufen soll, brauchst Du dann wirklich MySQL? Reicht da nicht SQLite aus? Dann würdest Du Dir schon mal die DB-Server-Komponente sparen.

Ich muss gestehen, dass ich dann auch nicht zu einer Webapplikation gegriffen, sondern eine native GUI-Anwendung gebaut hätte. Aber ok, zu Lernzwecken und mit Ambitionen in Richtung Webentwicklung ist das sicher schon ok.

[deets]

Ich schliesse mich Hyperion an, SQLite sollte die DB der Wahl sein.

Was die Server angeht halte ich seine Vorschlaege aber fuer ungeeignet, denn du hast ja wohl schon eine Django-Anwendung. Da bringt dir weder CherryPy noch Tornado was.

Es gaebe diverse WSGI-Server (von mod_wsgi fuer Apache bis hin zu wsgiref und Paster), aber wieso denn eigentlich? Django hat doch schon nen eingebauten Webserver, oder taeusche ich mich da?

[Hyperion]

Was die Server angeht halte ich seine Vorschlaege aber fuer ungeeignet, denn du hast ja wohl schon eine Django-Anwendung. Da bringt dir weder CherryPy noch Tornado was.

Es gaebe diverse WSGI-Server (von mod_wsgi fuer Apache bis hin zu wsgiref und Paster), aber wieso denn eigentlich? Django hat doch schon nen eingebauten Webserver, oder taeusche ich mich da?

Nutzt Django nicht den eingebauten Server von Python? Mag sein, dass der für den Stand-alone Betrieb geeignet ist, kann ich nicht beurteilen. Logging wäre da evtl. ein Argument für einen der von mir genannten bzw. separaten Webserver.

[/me]

Nutzt Django nicht den eingebauten Server von Python? Mag sein, dass der für den Stand-alone Betrieb geeignet ist, kann ich nicht beurteilen.

Die Verwendung im Produktivbetrieb wird nicht empfohlen. Ich habe allerdings trotzdem seit mehreren Monaten ein Miniprojekt mit sehr wenigen Zugriffen darauf laufen. Es funktioniert also grundsätzlich schon.