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.
Benutzeravatar
kbr
User
Beiträge: 950
Registriert: Mittwoch 15. Oktober 2008, 09:27

Dienstag 16. Januar 2018, 09:23

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: 5598
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Dienstag 16. Januar 2018, 10:23

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...
shcol (Repo | Doc | PyPi)
Py-Paul
User
Beiträge: 26
Registriert: Freitag 30. August 2013, 11:55

Dienstag 16. Januar 2018, 11:56

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: 5598
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Dienstag 16. Januar 2018, 12:07

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.
shcol (Repo | Doc | PyPi)
__deets__
User
Beiträge: 3762
Registriert: Mittwoch 14. Oktober 2015, 14:29

Dienstag 16. Januar 2018, 12:28

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.
Benutzeravatar
pillmuncher
User
Beiträge: 1116
Registriert: Samstag 21. März 2009, 22:59
Wohnort: München

Dienstag 16. Januar 2018, 12:54

Py-Paul hat geschrieben:...Kundenkonten, in denen die jeweiligen Guthabenbeträge stehen. Das ist notwendigerweise aus Platzgründen unvollständig...
Sobald es um Geldkonten geht, ist das alleinige Speichern des aktuellen Guthabens zu wenig. Man will ja wissen, wie es zu diesem Guthaben gekommen ist. Was würdest du davon halten, wenn deine Bank dir am Monatsende eine Nachricht schickt, in der lediglich steht "Ihr Guthabenstand ist so-und-so" aber nicht die Kontobewegungen? Für Lagebestände gilt übrigens dasselbe. Ein zu googlendes Stichwort wäre Event Sourcing.
In specifications, Murphy's Law supersedes Ohm's.
Py-Paul
User
Beiträge: 26
Registriert: Freitag 30. August 2013, 11:55

Dienstag 16. Januar 2018, 13:17

snafu hat geschrieben:Der übliche Weg bei solchen großen Vorhaben ist halt, sich bestehende Software (z.B. Odoo) zu nehmen und diese anzupassen.
Das hatte ich auch lange Zeit vor..... eben mit Odoo. Aber auch da gibt es eben nicht nur Licht.... Der ganze Haufen von Code, bei dem kaum noch jemand durchblickt usw. Ich beschrieb das ja schon weiter oben...

Ich schaue mir gerade die Kasse von Odoo 11 an.

snafu hat geschrieben: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...
Zu Odoo hatte ich ja schon oben was geschrieben. Vieles galt als buggy und nicht gerade schlank programmiert. Ich sehe schon die Vorteile von OpenSource und funktionierenden Communities- man sollte aber auf der anderen Seite so realistisch sein, darin nicht die Gewähr für ein gut gestaltetes und programmiertes System zu sehen ("optimal" habe ich nicht geschrieben!). Das ergibt sich aus vielen "Metarecherchen" zu Odoo und weil ich zufällig einen Odoo Entwickler kenne. Im Umkehrschluss muss Odoo nicht schlecht sein. Was Preise angeht, zu denen ich mich nicht äußere, kann man jedenfalls feststellen, dass der belgische Hersteller (oder wie nennt man das bei OpenSource Projekten?) jetzt verstärkt in die Monetarisierungsphase geht- was er wiederum mit Gegenwerten aufwiegen möchte. Allerdings sind dabei einige Details aus meiner bescheidenen Sicht zweifelhaft: die kostenfreie Communityversion lässt sich nicht auf mobilen Geräten darstellen, die kostenpflichtige Enterpriseversion dagegen schon. Betrachtet man das echte Leben, würde die Communityversion damit von vornherein wegfallen. Das neue Odoo 11 soll aber viel besser als alle Odoos zuvor sein.

snafu hat geschrieben: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.
Ja, das hängt später natürlich alles zusammen. Die Produktauflistung mit Bestand für die Kasse wäre dazu ja schon ein Anfang.

__deets__ hat geschrieben: 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.
Ich habe auch das Gefühl, dass ich das unterschätze. Irgendwann muss ich aber mal versuchen die Sachen zu finden, die ich immer übersehe. Wenn man die Berichte über Webshops liest, dann wird einem ganz anders... :cry:

__deets__ hat geschrieben:
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.
Ja, ok, dazu schrieb ich ja schon was.
A propos "gesetzliche Vorgaben": Jetzt fällt mir gerade einer der wichtigsten Gründe ein (habe ich AFAIR hier noch nicht erwähnt). Bei allen bestehenden Systemen, die ich dann entsprechend modifiziere, hätte ich nie ein ausreichend sichers Gefühl (von "wissen" gar nicht die Rede), dass diese tatsächlich diese Normen erfüllen. Nur bei einer selbst kontrollierten Neuentwicklung hätte ich eine gewisse, hoffentlich hinreichende Sicherheit.
Das gilt dann also für Odoo und alle, zB die weiter unten verlinkten, Entwicklungen. Schon das $-Zeichen bei den Beträgen deutet darauf hin, dass eine Software zumindest nicht ursprünglich für den deutschen Markt entwicklet wurde.


__deets__ hat geschrieben:
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.

OK, dass das in speziellen professionellen Bereichen gern genommen wird, ahbe ich auch schonmal gehört. Allerdings sind die Kassen, die ich meine, alles OpenSource Entwicklungen- darum wunderte mich das besonders. Siehe zB hier: https://blog.capterra.com/the-top-6-fre ... solutions/
Py-Paul
User
Beiträge: 26
Registriert: Freitag 30. August 2013, 11:55

Dienstag 16. Januar 2018, 13:23

pillmuncher hat geschrieben:
Py-Paul hat geschrieben:...Kundenkonten, in denen die jeweiligen Guthabenbeträge stehen. Das ist notwendigerweise aus Platzgründen unvollständig...
Sobald es um Geldkonten geht, ist das alleinige Speichern des aktuellen Guthabens zu wenig. Man will ja wissen, wie es zu diesem Guthaben gekommen ist. Was würdest du davon halten, wenn deine Bank dir am Monatsende eine Nachricht schickt, in der lediglich steht "Ihr Guthabenstand ist so-und-so" aber nicht die Kontobewegungen? Für Lagebestände gilt übrigens dasselbe. Ein zu googlendes Stichwort wäre Event Sourcing.
Interessanter Hinweis, Danke.

Dass es Bewegungsrichtungen diesbezüglich gibt, war mir klar. Den Fachausdruck Event Sourcing kannte ich noch nicht. Ich hatte das aus der buchhalterischen Sicht mit Buchungssätzen gesehen. Insofern würde vermerkt werden, dass Bargeld eingezahlt und ein bestimmtes Guthabenkonto entsprechend aufgefüllt wurde- also buchhalterisch ein "Zahlungsmitteltausch", bilanz- und USt-neutral.
Benutzeravatar
kbr
User
Beiträge: 950
Registriert: Mittwoch 15. Oktober 2008, 09:27

Dienstag 16. Januar 2018, 15:38

Py-Paul hat geschrieben:Bei allen bestehenden Systemen, die ich dann entsprechend modifiziere, hätte ich nie ein ausreichend sichers Gefühl (von "wissen" gar nicht die Rede), dass diese tatsächlich diese Normen erfüllen. Nur bei einer selbst kontrollierten Neuentwicklung hätte ich eine gewisse, hoffentlich hinreichende Sicherheit.
Das ist das "Not Invented Here"-Syndrom, das oftmals Ursache, oder zumindest teilweise, für verspätete, fehlerhafte, finanziell aus dem Ruder gelaufene oder gar gescheiterte Projekte ist.
Py-Paul
User
Beiträge: 26
Registriert: Freitag 30. August 2013, 11:55

Dienstag 16. Januar 2018, 16:53

kbr hat geschrieben:
Py-Paul hat geschrieben:Bei allen bestehenden Systemen, die ich dann entsprechend modifiziere, hätte ich nie ein ausreichend sichers Gefühl (von "wissen" gar nicht die Rede), dass diese tatsächlich diese Normen erfüllen. Nur bei einer selbst kontrollierten Neuentwicklung hätte ich eine gewisse, hoffentlich hinreichende Sicherheit.
Das ist das "Not Invented Here"-Syndrom, das oftmals Ursache, oder zumindest teilweise, für verspätete, fehlerhafte, finanziell aus dem Ruder gelaufene oder gar gescheiterte Projekte ist.
Hehe..., ja da hast Du aus dieser Sicht sicherlich auch recht...

Du musst aber zugeben, dass die Abwägung schwer ist: Bei bestehenden Systemen mit einer Menge Datenmüll und kryptischem Code- egal ob Open Source oder proprietär- anzuknüpfen, birgt schon Risiken- besonders dann, wenn man bedenkt, dass das Finanzamt die Kassenführung über 10 Jahre rückwirkend verwerfen und dann (nach oben) schätzen darf. Womit wir wieder bei dem sind, was ich anfangs hervorgehoben hatte, die beiden Communities.... :wink:
DasIch
User
Beiträge: 2473
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

Dienstag 16. Januar 2018, 16:57

Py-Paul hat geschrieben: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.
49 € kann man schon alleine für Hosting, Backups usw. ausgeben. Jährliche Entwicklungskosten in mindestens 6-stelliger Summe kommen da noch dazu. Außerdem haben Software Projekte eine unschöne Tendenz haben schief zu gehen. Du solltest also bereit sein soviel auch ggfs. in den Sand zu setzen und am Ende bei Orderbird o.ä. zu stehen.
Benutzeravatar
kbr
User
Beiträge: 950
Registriert: Mittwoch 15. Oktober 2008, 09:27

Dienstag 16. Januar 2018, 17:12

@Py-Paul: Wenn Du bestehenden Softwarelösungen nicht vertraust, kannst Du das Thema auf eine einfache Betrachtung reduzieren. Du schreibst es selbst, oder gibst es in Auftrag. Ersteres kannst Du nicht (und falls doch, so brauchst Du Zeit und hast kalkulatorische Kosten), letzteres wird teuer.
Und da es sich um eine unternehmenskritische Anwendung handelt, ist auch der sichere Betrieb mit Kosten verbunden.
Py-Paul
User
Beiträge: 26
Registriert: Freitag 30. August 2013, 11:55

Dienstag 16. Januar 2018, 18:00

DasIch hat geschrieben: 49 € kann man schon alleine für Hosting, Backups usw. ausgeben. [...]
Dieses Orderbird entspricht aber eben nicht meinen persönlichen Preferenzen. Und meine bescheidene persönliche Meinung ist, dass ich für solch eine Gastrokasse, auch mit Fernbonnierung, mindestens 49 € im Monat als teuer empfinde, denn es sind ja regelmäßige Zahlungen und das System ist nicht für zB 1000 € gekauft (mit folgenden kostenfreien Sicherheitsupdates und Bugfixes und kostenpflichtigen Verbesserungen bzw. Erweiterungen).
Die 49 € oder mehr stehen ja gar nicht zur Debatte- die würde ich für passende Software schon monatlich bezahlen- allerdings ist mir das Kaufmodell (mit Updates) lieber als das SAAS-Modell. Das wäre aber wieder ein eigenes Diskussionsthema.
kbr hat geschrieben:@Py-Paul: Wenn Du bestehenden Softwarelösungen nicht vertraust, kannst Du das Thema auf eine einfache Betrachtung reduzieren. Du schreibst es selbst, oder gibst es in Auftrag. Ersteres kannst Du nicht (und falls doch, so brauchst Du Zeit und hast kalkulatorische Kosten), letzteres wird teuer.
Und da es sich um eine unternehmenskritische Anwendung handelt, ist auch der sichere Betrieb mit Kosten verbunden.
Jaja, ich muss Dir ja -leider- schon wieder recht geben. Ich habe einfach den Umfang der Arbeiten nicht so groß eingeschätzt. Ich weiß ja immer noch nicht wieviel das ist und inwieweit man das mit einem Webshop vergleichen kann.
Selbstmachen würde mich zwar reizen, aber es ist einfach illusorisch. Also schaue ich mich weiter um :K
Odoo könnte -vielleicht- doch was werden.Ich würde aber schon gern wissen, wie das mit den GOBD dort realisiert ist- und da habe ich wieder ein ungutes Gefühl.
bfm
User
Beiträge: 74
Registriert: Donnerstag 14. März 2013, 09:42

Dienstag 16. Januar 2018, 22:39

Hallo zusammen,

ich bin gerade dabei, mein etwas in die Jahre gekommenes Haushaltsbuch für den reinen Privatgebrauch (ab 1990 in Basic geschrieben) neu in Python umzusetzen.

Moderne Programmiersprachen und Datenbanken bieten halt ziemlich viele Möglichkeiten. Wenn ich nur daran denken, wie lange ich am Datenbankdesign rumüberlegt habe. Und das ist heute sicher nicht perfekt. Da wird sich sicher mit der Zeit auch noch etwas ändern, weil ganz einfach Erfahrung hinzu kommt. Mit der GUI oder der "Geschäftslogik" drunter ist es genau das Gleiche. Insbesondere wenn man erst dabei ist, die Programmiersprache zu lernen. Da gibt es auch Code von vor einem Jahr, den ich heute anders schreiben würde. Bei meinem nächsten Projekt werde ich mir mit Sicherheit auch einfacher tun, weil ich halt zwischenzeitlich Erfahrung gesammelt habe.

Dazu muss ich noch sagen, dass ich beruflich Anwender in einer Lohnsoftware schule, berate, Module einrichte, Fehler suche usw. Soll heißen, ich schaue das Auto nicht nur von außen an, sondern ich mache auch mal die Motorhaube auf, schraube den Ventildeckel runter, der Kollege gibt Gas und dann schauen wir mal was passiert. Ich gehe dann durchaus auch mal mit SQL auf die Datenbank und bereinige Datenschiefstände, die die Software durch fehlerhafte Programmierung produziert hat (soviel zum Thema GOB :lol: ). Ich bin in dem Thema Programmierung, Datenbanken usw. also nicht ganz jungfräulich.

Aus dem Grund schätze ich dein Projekt als nicht gerade einfach ein. Selbst ein geübter Programmierer ist da nicht in vier Wochen damit fertig.

mfg
Py-Paul
User
Beiträge: 26
Registriert: Freitag 30. August 2013, 11:55

Mittwoch 17. Januar 2018, 22:12

bfm hat geschrieben: ich bin gerade dabei, mein etwas in die Jahre gekommenes Haushaltsbuch für den reinen Privatgebrauch (ab 1990 in Basic geschrieben) neu in Python umzusetzen.
Dann brauchst Du ja nicht so sehr auf die geltenden Normen achten. Du hättest aber dafür auch fertige günstige / kostenfreie Alternativen.... Als Hobbyprojekt aber sicher interessant.

bfm hat geschrieben: Ich gehe dann durchaus auch mal mit SQL auf die Datenbank und bereinige Datenschiefstände, die die Software durch fehlerhafte Programmierung produziert hat (soviel zum Thema GOB :lol: ).
Das bezieht sich ja auf die Lohnbuchhaltung.... Grundsätzlich werden die GoBD auch hier gelten (und die GOB sowieso)- die relevanten Daten der Lohnbuchhaltung (Meldungen, Beitragsnachweise) werden aber ja direkt an die jeweilige Einzugsstelle übermittelt und dann ausgedruckt (sei es auf Papier oder virtuell als PDF). Daneben noch die Zahlungen der entsprechenden Beträge. Da würde man nachträglich, glaube ich mal, nichts wirklich manipuliert bekommen.

Die Manipulationssicherheit ist aber natürlich ein wichtiges Thema. Wie das konkret bewerkstelligt wird, würde mich mal interesieren. Logdateien spielen wohl eien Rolle- die hätten vielleicht in Deinem Fall den Zugriff auf die Datenbank geloggt, vielleicht auch die konkreten Änderugen aufgezeichnet. Dann müsste nur noch diese Logdatei geschützt werden...
Ich habe neulich das hier entdeckt: http://www.secumem.com/- ein "USB Speicher zur veränderungsgeschützten Archivierung [...]" Es gibt also auch Schutz auf Hardwareebene.

bfm hat geschrieben:Aus dem Grund schätze ich dein Projekt als nicht gerade einfach ein. Selbst ein geübter Programmierer ist da nicht in vier Wochen damit fertig.
Ja, ich fürchte, das wird wohl so sein...
Die Entwickler, die ich hier so kenne (und die nie Zeit haben außer ab und zu mal Kaffee trinken...), raten mir auch ständig ab (nee, stimmt nicht, einer sagt: "einfach anfangen"). Mich würde immer noch interessieren, wo meine Denkfehler liegen, wo der Aufwand eigentlich liegt... :roll:
Antworten