Kasse [POS] in Python plus Warenwirtschaft und Onlineshop

Alles, was nicht direkt mit Python-Problemen zu tun hat. Dies ist auch der perfekte Platz für Jobangebote.
Py-Paul
User
Beiträge: 26
Registriert: Freitag 30. August 2013, 11:55

Hallo zusammen,

seit einer Ewigkeit bin ich auf der Suche nach einer für mich (und wahrscheinlich auch viele andere) geeigneten Verkaufs (Laden-) Kasse, neudeutsch auch POS-System [Point of Sale] genannt.

Es gibt schon einen Fred zum Thema (nämlich hier: viewtopic.php?f=5&t=10938), in dem viele interssante Dinge stehen, die auch Grundlage für das hier gemeinte System sein können.

Nach Empfehlung von gerold, der sich darin offenbar gut auskennt, sollte das Ganze mit PostgreSQL realisiert werden.

Bekannt sind mir die Exostenzu vieler rechtlicher Bedingungen, hier in Deutschland zB GDPdU bzw. GOB, usw.; in anderen Ländern, zB Österreich, gib te swieder andeere Normen. Das mag alle erstmal einschüchternd klingen, ist aber nach vielen Rücksprachen alles zu beherrschen.

Ein absolut entscheidendes Kriterium für mich ist dabei ein auffüllbares Kunden-Guthabenkonto. Das sollte mit Vorteilen für Kunden gekoppelt werden können (Neusprech: Incentives, Loyality-Programm, Rabatte).

Soweit ganz grob die Kasse.

Wer sich mal damit beschäftigt hat, sieht, dass eine Kasse selten alleine steht- sie hängt immer zusammen mit einer

Lagerhaltung bzw. einer Warenwirtschaft [WaWi]

Das wäre wohl das, was u.a. in der Datenbank abgelegt wäre.

Und damit kommen wir zu sinnvollen Erweiterungen, die man auch in vielen anderen Systemen finden kann, wobei gefühlt 90% dieser Systeme auf Windows-Servern laufen, warum auch immer.

Nämlich: eine vollständige Lagerhaltung / WaWi (hätte man im Grunde schon teilweise), hier aber auf alle Lager ausgedehnt, auch die, die keine Kasse haben (z.B. ein Zentrallager für zB Onlinehandel).

Wenn ich diese Lagerverwaltung hätte, wäre es schön, wenn ich Bewegungen zwischen diesen Lagern darstellen könnte:

Laden 1 (= Lager1) verkauft eine Kaffekanne --> Feststellung des Lagerbestandes --> Bei Unterschreitung des Meldebestandes: Bestellung wird an Zentrallager oder ein anderes peripheres Lager (Lager 2,3,4,...) bzw. Lieferanten gesendet usw.

Die Lagerwirtschaft / das WaWi soll an einen Webshop gekoppelt werden können.

Damit wäre das eine runde Sache.

Falls es das schon zufriedenstellend geben würde, würde ich mir nicht überlegen, sowas selbst zu machen bzw. machen zu lassen. Lange Zeit hatte ich Hoffnungen in Odoo (früher Open ERP) gesetzt, aber hier habe ich auch die Hoffnung aufgegeben.

Sollte jemand hier bereits kennen, was ich suche, so wäre ich natürlich für jeden Hinweis dankbar!
Py-Paul
User
Beiträge: 26
Registriert: Freitag 30. August 2013, 11:55

Hmmm.... scheint dann doch ein sehr off-topices Thema zu sein... :K
Benutzeravatar
snafu
User
Beiträge: 6731
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Naja, wenn Dir selbst ODOO nicht zusagt, für das es ja auch einige Erweiterungen zwecks Anpassung an das eigene Vorhaben gibt, dann fällt zumindest mir auch nichts mehr ein. Du hast im ersten Post ja einen sehr ausführlichen Vortrag gehalten. Ich konnte da leider nicht rauslesen, welche besonderen Ansprüche Du hast, die ODOO Deiner Ansicht nach nicht beherrscht.
Benutzeravatar
snafu
User
Beiträge: 6731
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Py-Paul hat geschrieben:Ein absolut entscheidendes Kriterium für mich ist dabei ein auffüllbares Kunden-Guthabenkonto. Das sollte mit Vorteilen für Kunden gekoppelt werden können (Neusprech: Incentives, Loyality-Programm, Rabatte).
Das Buchen einer Gutschrift auf dem Rechnungskonto des Kunden sollte wohl kein Problem sein...
Py-Paul
User
Beiträge: 26
Registriert: Freitag 30. August 2013, 11:55

snafu hat geschrieben:Naja, wenn Dir selbst ODOO nicht zusagt, für das es ja auch einige Erweiterungen zwecks Anpassung an das eigene Vorhaben gibt, dann fällt zumindest mir auch nichts mehr ein. Du hast im ersten Post ja einen sehr ausführlichen Vortrag gehalten. Ich konnte da leider nicht rauslesen, welche besonderen Ansprüche Du hast, die ODOO Deiner Ansicht nach nicht beherrscht.
Ich beschäftige mich mit dem Thema -eher als User- leider viel länger als mir lieb ist. Odoo, da hatte ich, wie gesagt, eine Menge Hoffnungen reingesetzt. Ja, Odoo kann "optisch" erstmal eine Menge- sobald es konkret wird, fangen aber die Probleme an. Man könnte einwenden, dass das bei allen ERP-Systemen so ist.... ja stimmt auch wieder.

Ich muss an dieser Stelle doch nochmal einen kleinen Exkurs hinsichtlich der engen Verknüpfung rechtlicher, fiskalischer Aspekte einerseits und technischer Aspekte andererseits machen:
Im Laufe dieser langen Zeit habe ich wirklich immer wieder die Erfahrung gemacht, dass die Welt +/- diesbezüglich in eine "juristische Community" und eine "technische Community" einteilbar ist. Wenn man in der Schnittmenge beider ist (und die ist, gefühlt, sehr klein), dann hat man am ehesten eine Chance durchzublicken. Odoo bietet eine Menge Möglichkeiten- was aber ist mit der Normenkonformität? Viele Entwickler werden jetzt ratlos gucken oder lapidar mit einem "gibt's auch" abtun- dabei ist diese essentiell! Normenkonformität ist sogar die Grundvoraussetzung zur Benutzbarkeit im operativen Betrieb. Bei vielen Softwarelösungen, auch Odoo, habe ich den Eindruck, dass da viel rumgebastelt wird (und bei einem Riesentanker wie Odoo dann auch noch mit ungewissem Ausgang wegen der vielen Dependenzen, die es wahrscheinlich gibt), sich aber über die in Deutschland gültigen Normen kaum jemand Gedanken macht- allenfalls mit einem "kann ja angepasst werden". Kann es das? Immer? Wenn ja mit welchem Aufwand- und welchen Risiken (zB Updatefähigkeit des Grundsystems)?

Das Gegenstück bieten Applikationen bekannter Softwarehäuser aus diesem Bereich, zB Haufe-Lexware oder Buhl. Es ist sicher kein Zufall, dass diese Herausgeber gleichzeitig wirtschaftlich-rechtliche Fachbücher verlegen. Aber auch diese Systeme haben ihre Nachteile. Teurer als Odoo sind sie dagegen nicht unbedingt, denn auch Odoo muss i.d.R angepasst werden- und wenn ich das von einem Odoo-Kenner machen lasse, dann kann es schnell teuer werden. Denn in Python programmieren können reicht bei solch einem Dickschiff wie Odoo sicher nicht alleinig aus- man muss das ganze Ding kennen. Und das Ganze dann auch noch von einem Fachmann in Buchhaltung, Steuer- und Wirtschaftsrecht und.... begutachten lassen. Softwaretechnisch ist es wohl auch so, dass Vieles in Odoo nicht gerade schlank gecoded und buggy ist. Ob die neue, von Odoo selbst bejubelte Version 11 sooo viel besser ist (soll 30% schneller sein), sei mal dahingestellt. Dann die Preisgestaltung: zB 24€ allein für ein Logistikmodul (jeweils zB DHL oder UPS) - wenn ich nicht total daneben liege waren die vor einiger Zeit sogar noch teurer (kann das?).
Odoo ist und bleibt für mich ein interessantes Ding- aber im Moment sehe ich das nicht.

So, Exkurs beendet :wink:
snafu hat geschrieben:
Py-Paul hat geschrieben:Ein absolut entscheidendes Kriterium für mich ist dabei ein auffüllbares Kunden-Guthabenkonto. Das sollte mit Vorteilen für Kunden gekoppelt werden können (Neusprech: Incentives, Loyality-Programm, Rabatte).
Das Buchen einer Gutschrift auf dem Rechnungskonto des Kunden sollte wohl kein Problem sein...
Hört sich plausibel an... ob es so, wie gedacht, auch funktioniert ist eine ganz andere Frage...

Es soll ja so funktionieren:
Kunde zahlt Guthaben auf sein Kunden-Guthabenkonto ein (am ehesten bar, aber evtl. auch unbar). Dazu erhält er eine Kundenkarte, mit der der Kassierer Zugriff auf dieses Konto hat. Kauft der Kunde wieder ein, so wird die Kundenkarte eingelesen (gerne als Chipkarte; im einfachsten Fall als Barcode) und der jeweilige Betrag abgebucht. Reicht das Restguthaben nicht mehr, so kann entweder wieder eingezahlt oder der übrige Restbetrag bar ergänzt werden. So einfach, so gut :D

Warum komme ich immer weider auf den Plan zurück, eine eigene Kasse stricken zu wollen?

Einmal würde ich dann das bekommen, was ich suche. Denn das dauerfrustrierende Erlebnis bei etlichen existierenden Applikationen ist, dass man eine Menge Zeit investieren muss, um diese ansatzweise zu verstehen (--> Zeit --> Kosten). Leider stellt sich dann irgendwann heraus: das System kann nicht, was ich suche (zwar unendlich viele andere Dinge- aber die brauche ich alle nicht).

Dann habe ich keinen "Datenmüll" bzw. irgendwelche mitgeschleppten Legacy-Codezeilen, deren Funktion nur Entwickler der ersten Stunde dieses jeweiligen Systems mit viel Glück und Zeit entziffern können (--> Kosten).

Damit kann von Anfang an eine sauber und schlank (mit Kommentaren!) geschriebene Kassenapplikation geschrieben werden.

Soweit die Vorteile.

Vom konkreten Vorgehen her stelle ich mir das so vor:

Im ersten Schritt (nach möglichst weitgehender Panung auch zukünftiger Funktionen) Schreiben einer POS-Anwendung, die die anfangs wichtigen Sachen kann mit Fokus auf Erweiterbarkeit und Stabilität. Eine GOBD-Zertifizierung (http://www.bundesfinanzministerium.de/C ... onFile&v=1von offizieller Stelle gibt es nicht, aber es gibt +/- vertrauenswürdige Firmen, die dazu Audits machen- ist sicher machbar (nach dem, was ich da schon alles gesehen habe...).

Von diesem Grundsystem würd eich dann eben Schritt für Schritt weitergehen.

Nach meinen Erfahrungen würde ich das für einen guten Plan halten.

Wenn jemand eine tolles Sytem kennen sollte, das das kann: bitte her damit
__deets__
User
Beiträge: 14494
Registriert: Mittwoch 14. Oktober 2015, 14:29

Also nach deinem - durchaus interessanten! - Exkurs lehne ich mich mal aus dem Fenster & sage: hier kennt sich da keiner besser aus als du. Gerade was die rechtliche Situation anbelangt. Insofern glaube ich nicht, da du viele Antworten bekommst.
Py-Paul
User
Beiträge: 26
Registriert: Freitag 30. August 2013, 11:55

Ich bin nur leider ein DAC (also wie DAU, aber auf Coder bezogen)... :roll:
Was ich hoffentlich kann: Ein bisschen aus der genannten Schnittmenge und sagen was ich will (und was nicht). Nur beim Programmieren hört es dann leider auf....
Es gibt noch einige Open Source POS-Applikationen, von denen sehen auch einige optisch ganz gut aus, aber die scheinen alle (?) in Java geschrieben zu sein... Somit wäre also noch Platz für ein gut aufgesetztes Python System :D
Sirius3
User
Beiträge: 17712
Registriert: Sonntag 21. Oktober 2012, 17:20

@Py-Paul: ich bewundere Dein Engagement. Aber ich will Dir nicht viel Hoffnung machen, Pythonprogrammierer zu finden, die Lust haben, so ein großes Projekt in ihrer Freizeit zu stemmen und noch weniger, die dafür auch Zeit haben.
Py-Paul
User
Beiträge: 26
Registriert: Freitag 30. August 2013, 11:55

Hallo,

naja, es muss ja nicht in der Freizeit sein; ich denke mal, dass hier auch Freelancer mitlesen.

Wo ich wieder auf dem Schlauch stehe: Ich kann die Größe nicht abschätzen. Mein Bauch, der nicht immer die Wahrheit sagt, sagt jetzt, dass das Ganze auch relativ einfach gehalten werden kann- wenigstens für den Anfang (Kasse mit Kundenkonto).
__deets__
User
Beiträge: 14494
Registriert: Mittwoch 14. Oktober 2015, 14:29

Ist trotzdem mehrere Monate Arbeit. Pro Monat mehre tausend Euro (5K mindestens), und dann bist du schon bei 10-20K. Und dazu kommt, das es halt wenig sexy ist. Ist leider so. Du findest also eher keinen, der das aus Freude an der programmatischen Herausforderung selbst pflegt etc.

Die Shoplogik für unseren Webshop mal kräftig zu entrümpeln hat 4 gute Leute 3 Monate gekostet. Da waren zwar auch viele Altlasten zu schleppen bei, aber eben auch schon bekannt, was gebraucht wird, statt das noch eruieren zu müssen. Selbst unter optimistischsten Rausrechnungen bleiben da Mannmonate über für die eigentliche Arbeit. Und das war ja nur der Berechnungskern. Weboberfläche gabs ja schon.
Py-Paul
User
Beiträge: 26
Registriert: Freitag 30. August 2013, 11:55

Was mir wohl fehlt, ist erstmal eine Möglichkeit, das Ausmaß des Ganzen irgendwie sinnvoll abschätzen zu können. Ich würde schätzen, dass der meiste Kram Datenbankprogrammierung ist, richtig?

Gibt es da vielleicht eine für Laien gut verständliche Darstellung (sei es in Text-, Bild- oder Videoform), die einem solch eine Aufwandsschätzung näher bringt?

Dass dieses Zeug wenig "sexy" ist, habe ich auch schonmal von einem Entwickler gehört, da ging es um ein WaWi-System. Da kann ich leider nichts dran ändern :roll:
__deets__
User
Beiträge: 14494
Registriert: Mittwoch 14. Oktober 2015, 14:29

Ich glaube nicht, das du selbst dazu befähigt sein wirst, das abzuschätzen. Was nicht despektierlich gemeint ist. Sondern einfach der simplen Tatsache geschuldet, das heutzutage in der Projektarbeit mit agilen Methoden die Programmierer die sind, die abschätzen. Und trotzdem oft genug daneben liegen. Obwohl sie wenigstens wissen, wie es geht.

Und wozu soll das auch gut sein? Deine Abschätzung spielt doch keine Rolle. Wenn du was programmiert haben willst, ist es viel wichtiger, das du weißt, was du brauchst. Und dann kann ein Programmierer das abschätzen, und ein Angebot machen. Und du entscheiden ob du das annimmst.

Ich glaube du hast viel bessere Chance mit etwas bestehenden. Was ist denn mit Systemen wie orderbird?
Py-Paul
User
Beiträge: 26
Registriert: Freitag 30. August 2013, 11:55

Am liebsten würde ich das ja selbst machen.... ist aber momentan illusorisch :(
Was die Abschätzung angeht, hast Du bezüglich der professionellen Programmierer und Scrum & Co recht, aber vielleicht gibt es ja doch irgendwelche "Bauernregeln".

Orderbird hatte ich mir irgendwann mal kurz auf deren Website angeschaut (und jetzt gerade wieder):
Ist nichts für mich- aus verschiedenen Gründen-
- einmal unverschämter Preis (ab (!) 49 € (!) pro Monat (!))- das ist einfach jenseits von Gut und Böse...,
- hat dabei wohl auch nicht das von mir gesuchte Kundenguthabenkonto und
- ist eine reine Gastrokasse ohne vorgesehene Anbindungsmöglichkeit an bestimmte WaWis etc.
Die Werbewelle, die die Jungs machen, ist schon beeindruckend- aber ob man für ein Gatronomiekassensystem direkt eine AG gründen muss? Aus Letztem werden sich dann zumindest auch die Preise erklären...

OK, ich schaue mir gerade nochmal Odoo 11 an.... ich kenne dazu auch einen Entwickler, der nur leider notorisch unzuverlässig ist.... :?
Der Vergleich der kostenfreien Community- und der kostenpflichtigen Enterprise- Version (hier: http://www.ife.de/index.php/angebote/od ... rsion.html) zeigt schonmal, dass nur der Einsatz der Enterpriseversion sinnvoll ist, denn nur diese hat ein responsive Webdesign und ist somit auch für mobile Geräte geeignet. Oder weiß hier jemand, ob man die entsprechenden Templates in der Communityversion leicht gegen solche in responsive Design austauschen kann. Aber selbst wenn man das könnte: nur bei der Enterpreiseversion gibt es eine Kundenkarte zur Kasse....
__deets__
User
Beiträge: 14494
Registriert: Mittwoch 14. Oktober 2015, 14:29

Also für eine Stunde meiner Programmierzeit zahlst du ~80€. Unter 20 Manntagen a 640€, also ~13K passiert nicht viel. Da kannst du also 260 Monate orderbird von kaufen.... Jetzt mag es wen geben, der es halb so teuer macht, bleiben immer noch > 10 Jahre Orderbird.

Wenn es nicht kann, was du brauchst, hilft das natürlich nix, aber das sind so die Relationen. Und wenn die bald wieder glücklich vereinte GroKo die Regeln ändert, macht OB das mit. Du musst dein System dann für teuer Geld auf Stand bringen lassen.

Orderbird steht hier nur stellvetretend für solche Systeme. Ich kenne das nur zufällig weil ein Kumpel vor Jahren da gearbeitet hat, und ne Reihe von Freunden und bekannten in der Gastro es einsetzen. Die Idee, statt teurer nixdorf Kassen verhältnismässig billige i*-Geräte zu benutzen finde ich erstmal gut, jenseits davon - keine Ahnung. Und da mag es auch andere Anbieter geben.

Aber das du irgendwie BILLIGER da ran kommst, ohne dann gleich auch die ganzen von dir selbst erwähnten Regularien zu implementieren - ist nicht.

Das schaffst du nur, wenn du selbst Hand anlegst, und selbst dann ist es wahrscheinlich kaufmännisch nicht so recht sinnig - sondern eben ein Hobby.

Was anderes ist es, für bestehende Systeme (Odooo oder andere) Begleitfunktionen zu schreiben. Das setzt aber natürlich entsprechende Schnittstellen oder Reverse Engineering voraus.
Py-Paul
User
Beiträge: 26
Registriert: Freitag 30. August 2013, 11:55

Ob Orderbird völlig neue Voraussetzungen (sagen wir mal: statt 2 nun 5 USt-Sätze plus Fiskalspeicher) in ihr System implementiert, ohne den Kunden nicht doch nochmal zusätzlich zur Kasse zu bitten (huch, Wortwitz :lol: ), sei mal dahingestellt. Da müsste man sich die Mühe der AGB-Leserei antun.... Und auch die können einseitig geändert werden und der Kunde ist "frei" das Abo nicht zu verlängern :?

iPad-Kassen gibt es schon seit einiger Zeit.... rein aus der statistischen Unwahrscheinlichkeit waren Orderbird eher nicht die ersten.

"Das Original" ist hier m.W. OrderMAN- die haben schon lange mobile Geräte in der Gastronomie salonfähig gemacht (schon wieder einer, hihi :lol: )

Auf meinem gerade eingerichteten Odoo Testaccount probiere ich gerade ein bisschen am POS-Modul herum, aber es kommt erwartungsgemäß auch schon wieder zu Fehlfunktionen (können ja in der Cloud oder sonstwo stecken...)

Insgesamt ein frustrierendes Thema :x
Benutzeravatar
kbr
User
Beiträge: 1487
Registriert: Mittwoch 15. Oktober 2008, 09:27

Py-Paul hat geschrieben:Insgesamt ein frustrierendes Thema
Mit Odoo ist es ähnlich wie mit SAP. Du musst Deinen Workflow an die Software anpassen. Das klappt nicht immer gut. Wenn ich Dich richtig verstanden habe, dann möchtest Du eine Individualsoftware, aber bereits Stangenware erscheint Dir zu teuer. Das wird auch nichts werden. Meine Empfehlung: suche einen seriösen Kassenanbieter und bespreche mit diesem Dein Anliegen. Etwas Investitionsbereitschaft wirst Du allerdings mitbringen müssen.
Benutzeravatar
snafu
User
Beiträge: 6731
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Py-Paul hat geschrieben:Orderbird hatte ich mir irgendwann mal kurz auf deren Website angeschaut (und jetzt gerade wieder):
Ist nichts für mich- aus verschiedenen Gründen-
- einmal unverschämter Preis (ab (!) 49 € (!) pro Monat (!))- das ist einfach jenseits von Gut und Böse...,
(...)
Und Dein Programmierer, der alles von Null an selber bauen soll, bekommt dann 39 Euro pro Monat, oder wie stellst Du Dir das vor? Entschuldige die harten Worte, aber Deine Preisvorstellungen wirken im Kontext Deiner Anforderungen etwas lächerlich. Ich glaube, Du hast aus technischer Sicht wirklich wenig Ahnung, wieviel Arbeit hinter Erstellung und Pflege eines solchen Projektes steckt. Zumal ich das im Hinblick auf schon fertige Lösungen persönlich leicht sinnlos finde. Aber ist ja dem Auftragnehmer im Prinzip egal, solange Du als Kunde vernünftig dafür zahlst. Nur willst Du das ja anscheinend auch nicht.
Py-Paul hat geschrieben:Es gibt noch einige Open Source POS-Applikationen, von denen sehen auch einige optisch ganz gut aus, aber die scheinen alle (?) in Java geschrieben zu sein...
Aus Verbrauchersicht wäre mir das ziemlich egal, welche Programmiersprache es letztlich ist. Ich wollte schon die ganze Zeit fragen ob Du Dich noch nicht bei Java umgeschaut hast...
Py-Paul
User
Beiträge: 26
Registriert: Freitag 30. August 2013, 11:55

Es scheint ein Naturgesetz zu sein, dass auf Meinungen zu Preisen, auch wenn diese Meinungen schlüssig sind, oft heftig reagiert wird. Eine dauerhafte Rentenzahlung (finanztechnisch) i.H.v. mindestens 49 € ist schon einiges, schon absolut für sich genommen. In Relation zum Produkt, so, wie es sich für mich darstellt, ist das ziemlich viel. Unsachlich dagegen ist der Vergleich zum Programmierer, der 39 € im Monat bekommen soll- ich weiß nicht wohin eine solch unsinnige Anmerkung führen soll. Wenn jemand sowas selbst produziert oder produzieren lässt, so wäre er ja auch zB Inhaber der Nutzungsrechte und könnte diese Software selbst vermarkten- allein hier liegt ja schon ein großer Unterschied. Der nahegelegte Schluss, ich wolle für Software nichts oder zu wenig bezahlen ist hier offenbar ein Trugschluss, dessen Äußerungssinn sich mir nicht erschließt.

Zurück zum eigentlichen Thema:
kbr hat geschrieben:
Py-Paul hat geschrieben:Insgesamt ein frustrierendes Thema
Mit Odoo ist es ähnlich wie mit SAP. Du musst Deinen Workflow an die Software anpassen. Das klappt nicht immer gut. Wenn ich Dich richtig verstanden habe, dann möchtest Du eine Individualsoftware, aber bereits Stangenware erscheint Dir zu teuer. Das wird auch nichts werden. Meine Empfehlung: suche einen seriösen Kassenanbieter und bespreche mit diesem Dein Anliegen. Etwas Investitionsbereitschaft wirst Du allerdings mitbringen müssen.
Die Sache mit der Anpassung ans System ist ja noch ein weiteres Problem. Vielleicht einer der Gründe, warum in vielen Verwaltungen nichts funktioniert... Trotzdem schaue ich mir jetzt nochmal Odoo an.

Bei Kassenanbietern war ich früher mal, das bringt nicht viel, weil die eben "nur Kassen" können, v.a. noch die konventionellen Registrierkassen. Ich möchte aber ja ein System haben, das ich in eine weiter wachsende Umgebung integrieren kann, bzw. von dem aus eine Umgebung wächst. Sowas kann der normale Kassenverkäufer nicht.
snafu hat geschrieben: Ich glaube, Du hast aus technischer Sicht wirklich wenig Ahnung, wieviel Arbeit hinter Erstellung und Pflege eines solchen Projektes steckt.
Da brauchst Du nicht zu glauben: das schrieb ich selbst schon weiter oben!
Trotzdem versuche ich natürlich, mir eine Vorstellung davon zu machen- es mag naiv sein, aber ich kann mir dann tatsächlich nicht vorstellen, dass der Aufwand sooo gigantisch sein soll. Ich habe eine Datenbank mit Produkten, Preisen, USt-Sätzen, dann sollen die Einnahmen verbucht und am Ende, getrennt nach USt. Sätzen die Tageseinnahmen angezeigt werden. Dazu kommen dann noch diese Kundenkonten, in denen die jeweiligen Guthabenbeträge stehen. Das ist notwendigerweise aus Platzgründen unvollständig, aber das Wesentliche. Daneben habe ich Bedenken wegen evtl. Qualitätsmängel bestehender Software und hätte einfach ein besseres Gefühl, wenn es in guter Qualität "selbst gemacht" ist.
Was mir aber gar nicht klar ist, ist die "Pflege" des Systems. Was soll da wie gepflegt werden? Außer Ergänzung von Produkten und Preisänderungen, was aber ja für mich keine "Pflege" ist.... (OK, man sagt, glaube ich, "Preise / Produkte einpflegen").


snafu hat geschrieben:Zumal ich das im Hinblick auf schon fertige Lösungen persönlich leicht sinnlos finde.

Ich hatte eingangs erklärt, warum es hier sinnvoll ist (zB weil ich die gewünschte Funktion nirgendwo finden konnte). Also kenne ich bisher keine fertige Lösung. Wenn Du die Neuentwicklung für sinnlos hälst, dann in diesem Kontext, weil Du die von mir gewünschte Funktion für sinnlos hälst- was aber hier eine sinnlose Meinung ist, da Du ja nichts von meinen Geschäftsabläufen kennen kannst. Odoo mag hier eine Ausnahme sein mit vielen Fragezeichen ...

snafu hat geschrieben:
Py-Paul hat geschrieben:Es gibt noch einige Open Source POS-Applikationen, von denen sehen auch einige optisch ganz gut aus, aber die scheinen alle (?) in Java geschrieben zu sein...
Aus Verbrauchersicht wäre mir das ziemlich egal, welche Programmiersprache es letztlich ist. Ich wollte schon die ganze Zeit fragen ob Du Dich noch nicht bei Java umgeschaut hast...
Das ist hier ein interessanter Punkt: Wie kommt es dabei zur häufigen Benutztung von Java? Ist das für solche Anwendungen irgendwie prädestiniert?
Benutzeravatar
snafu
User
Beiträge: 6731
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Der übliche Weg bei solchen großen Vorhaben ist halt, sich bestehende Software (z.B. Odoo) zu nehmen und diese anzupassen. Odoo ist auch auf Anpassbarkeit ausgelegt. Keinesfalls sinnlos finde ich, dass Du Software willst, die auf Deine Geschäftsprozesse zugeschnitten ist. Da habe ich mich vielleicht unklar ausgedrückt. Nur die Schlüsse, die du daraus ziehst, dass es jetzt unbedingt etwas Eigenes sein muss, das finde ich im Hinblick auf Deine kaum vorhandenen IT-Kenntnisse äußerst ambitioniert. Du musst im Übrigen nicht gleich beleidigt auf Kritik reagieren. Wenn Dir mehrere Programmierer nahelegen, eine mögliche Eigenproduktion nochmal zu überdenken, dann könnte da durchaus was dran sein...
Py-Paul hat geschrieben:es mag naiv sein, aber ich kann mir dann tatsächlich nicht vorstellen, dass der Aufwand sooo gigantisch sein soll. Ich habe eine Datenbank mit Produkten, Preisen, USt-Sätzen, dann sollen die Einnahmen verbucht und am Ende, getrennt nach USt. Sätzen die Tageseinnahmen angezeigt werden. Dazu kommen dann noch diese Kundenkonten, in denen die jeweiligen Guthabenbeträge stehen. Das ist notwendigerweise aus Platzgründen unvollständig, aber das Wesentliche. Daneben habe ich Bedenken wegen evtl. Qualitätsmängel bestehender Software und hätte einfach ein besseres Gefühl, wenn es in guter Qualität "selbst gemacht" ist.
Du hast also Bedenken, dass ein jahrelang gepflegtes und von der Community angenommenes Produkt schlechter ist als etwas in Eigenregie innerhalb weniger Monate aus dem Boden gestampftes? Mkay...

Im Übrigen hattest du eingangs noch die Lagerhaltung und ein WaWi-System erwähnt. Das ist jetzt plötzlich nicht mehr relevant? Selbst wenn Du "nur" die Schnittstellen zu bestehenden Lösungen meintest, so ist auch hier der Aufwand nicht zu unterschätzen.
__deets__
User
Beiträge: 14494
Registriert: Mittwoch 14. Oktober 2015, 14:29

Py-Paul hat geschrieben: Trotzdem versuche ich natürlich, mir eine Vorstellung davon zu machen- es mag naiv sein, aber ich kann mir dann tatsächlich nicht vorstellen, dass der Aufwand sooo gigantisch sein soll. Ich habe eine Datenbank mit Produkten, Preisen, USt-Sätzen, dann sollen die Einnahmen verbucht und am Ende, getrennt nach USt. Sätzen die Tageseinnahmen angezeigt werden. Dazu kommen dann noch diese Kundenkonten, in denen die jeweiligen Guthabenbeträge stehen. Das ist notwendigerweise aus Platzgründen unvollständig, aber das Wesentliche. Daneben habe ich Bedenken wegen evtl. Qualitätsmängel bestehender Software und hätte einfach ein besseres Gefühl, wenn es in guter Qualität "selbst gemacht" ist.
Du unterschaetzt das. Wirklich. Massiv. Ich habe an einem Webshop gearbeitet, das sind dutzende Mannjahre, die da drin versenkt wurden. Es waere schlimmer in Java gewesen (siehe unten), aber es war trotzdem richtig viel Arbeit, und bleibt es auch. Unsere Webabteilung mit ~6 Entwicklern tut nahezu nur das. Und das ist "nur" das Frontend, die Datenbank, das Lizenzvergabe und Preisberechnungssystem. Der Anschluss ans Accounting erfolgt durch eine Schnittstelle zu Drittanbietern.
Py-Paul hat geschrieben: Was mir aber gar nicht klar ist, ist die "Pflege" des Systems. Was soll da wie gepflegt werden? Außer Ergänzung von Produkten und Preisänderungen, was aber ja für mich keine "Pflege" ist.... (OK, man sagt, glaube ich, "Preise / Produkte einpflegen").
Pflege bedeutet neue Funktionalitaet. Die kann in diesem Zusammenhang von dir gewuenscht sein, viel wichtiger aber in diesem Bereich durch gesetzliche Vorgaben vorgeschrieben werden - du *musst* also reagieren.
Py-Paul hat geschrieben: Das ist hier ein interessanter Punkt: Wie kommt es dabei zur häufigen Benutztung von Java? Ist das für solche Anwendungen irgendwie prädestiniert?
Nicht an sich, aber Java wird von boesen Zungen als das Cobol der 90er bezeichnet. Banken und Co verwenden es oft, und das ist halt eine business-affine Umgebung. Oder auch "enterprisey", wie man so schoen sagt.

Allerdings ist es auch ein ziemlich aetzendes Umfeld, wo immer die grossen Raeder gedreht werden, wenn es auch ein kleines taete.
Antworten