Verkaufs- Kassensoftware in python

Alles, was nicht direkt mit Python-Problemen zu tun hat. Dies ist auch der perfekte Platz für Jobangebote.
pyStyler
User
Beiträge: 311
Registriert: Montag 12. Juni 2006, 14:24

Montag 18. Juni 2007, 19:04

Hallo Gerold,

ersteinmal ein dickes dankeschön für die ganze infos, die du für uns übrig hast.

Jezte werde ich deine postings detaillierter analysieren und hoffe, mir fällt eine frage dazu ein. :D

Sr4l hat geschrieben:PS: Gerold behalt ein paar Betriebsgeheimnisse noch für dich Man muss ja immer soviel lesen.
Das sind doch keine Betriebsgeheimnisse. :wink:
Ich denke es ist so - ein extrem erfahrener Programmierer versucht uns klar zu machen, wo die schwierikeiten beim Programmieren eines Kassensytems sind.

Danke und Gruss
pyStyler


p.s @Sr4l ich weiss wie du das gemeint hast. :D
pyStyler
User
Beiträge: 311
Registriert: Montag 12. Juni 2006, 14:24

Montag 18. Juni 2007, 22:14

Hallo,
ein Paar Gedanken von mir,

**Internationalisierung

da das Kassensystem vollkommen von der Gui abgetrennt wird, werde
ich eine englische Gui mit allem drum und dran mitgeben. Ich denke, das
ist einfacher als mit gettext zu arbeiten ?

**Netto nicht Brutto

Frage: das heisst, in der Datenbank muss ich meinen tatsächlichen
Gewinn nach Abgaben der Steuern speichern ?

**Zahlmittel
Was mache ich, wenn einer mit der Karte zahlen will ?
gibt es dafür externe Opensource Programme ?

**Fremdwährung

reicht datum + Kassenbonnummer ?

**Touchscreen oder doch nicht?
also es ist einfach so, dass ich mich mit Tkinter "Gut" auskenne, deshalb
wird die Windows Version in Tkinter sein.
( sieht unter Windows Gut aus finde ich. Auf Wunsch gibt es einen Screen )
Frage: Gerold weisst du ob man Tkinter mit einem Touchscreen bedienen
kann ( ich weiss, ist ein bisschen lolig :D )
wahrscheinlich muss der Fokus über alle Widgets sein?

**Authentifizierung und Rechtevergabe

das wird echt mal schwierig denke ich!
eventuell hat einer eine Idee, wie ich es am besten lösen kann.

**Branchenunterschiede
das ist echt mal komisch. Wie soll man da eine anständige Lagerführung
betreiben können?

**Rabatte und Kundenkarten
am überlegen bin.

**Die richtige Datenbank
das ist echt mal ein grosses Problem was ich im Moment habe.
ich muss noch ein paar Nächte drüber schlafen.

Gruss
pyStyler
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Dienstag 19. Juni 2007, 09:52

Hallo pyStyler!
pyStyler hat geschrieben:**Internationalisierung
da das Kassensystem vollkommen von der Gui abgetrennt wird, werde ich eine englische Gui mit allem drum und dran mitgeben. Ich denke, das ist einfacher als mit gettext zu arbeiten?
Eine Trennung ist teuer. Die kostet dich "geschätzt" 1/5 deiner Arbeitszeit. Aber sie ist vernünftig, wenn du ein erweiterbares Programm schreiben möchtest.

Gettext ermöglicht es anderen, dein Programm zu übersetzen. Aber wenn du dein Programm eh in englisch schreibst, dann lässt sich das später auch noch einbauen. --> http://www.python-forum.de/topic-10711.html

pyStyler hat geschrieben:**Netto nicht Brutto
Frage: das heisst, in der Datenbank muss ich meinen tatsächlichen Gewinn nach Abgaben der Steuern speichern?
Nein. Ich meinte damit, dass du nirgends den Brutto-Verkaufswert der Ware speichern sollst. Rechne erst beim Verkauf den Brutto-Verkaufswert der Ware aus. Bei Verkäufe an Endkunden arbeitest du mit dem Brutto-VKP. Bei Verkäufen an gewerbliche Inlandskunden arbeitest du mit Netto-VKP und rechnest zum Schluß die MwSt dazu. Bei Verkäufen an gewerbliche Auslandskunden mit gültiger UID arbeitest du mit Netto-VKP ohne die MwSt dazuzurechnen. Dafür muss dann aber auch auf der Rechnung drauf stehen, dass es sich um so einen Kunden handelt.

Es ist, schlicht einfacher, wenn du in der Datenbank (bei den Artikeldaten) den NETTO-VKP stehen hast. Z.B. in der Schweiz haben manche Artikel unterschiedliche MwSt-Sätze, je nachdem, ob die Ware im Lokal genossen wird, oder ob sie mitgenommen wird.

Wo wir dann bei den MwSt-Sätzen sind. Ich würde die MwSt-Sätze eines Artikels NICHT in die Artikel-Tabelle schreiben. Ich würde die MwSt-Sätze in eine eigene Tabelle schreiben. So, dass ein Artikel mehrere MwSt-Sätze besitzen kann. Und dann muss noch eine Regel aufgestellt werden, die dem Programm bekannt gibt, welcher MwSt-Satz zu verwenden ist. Idealerweise nimmt man einen "Action"-Artikel für so etwas. Also ein Artikel, der zwar an der Kasse gebucht werden kann, aber nichts anderes zu tun hat, als dem System als Schalter zu dienen. --> Wenn dieser Artikel nicht in der Detailliste auftaucht, dann wird bei jedem Artikel der erste MwSt-Satz verwendet. Taucht dieser Artikel in der Detailliste auf, dann werden alle Artikel der Detailliste noch einmal durchlaufen und geprüft ob jetzt der zweite oder dritte MwSt-Satz verwendet werden soll.

Code: Alles auswählen

vat_groups
===================================
id | group_id | percent | condition
===================================
1  |    1     |   14    |   NULL
-----------------------------------
2  |    1     |   7     |   A1234
-----------------------------------
3  |    2     |   10    |   NULL
-----------------------------------
4  |    3     |   20    |   NULL
-----------------------------------

articles
=============================================
article_nr | name         | vat_group | ...
=============================================
L13        | Bio-Joghurt  |     1     |
---------------------------------------------
E234       | Radio        |     3     |
---------------------------------------------
S667       | Wiener Schn. |     2     |
---------------------------------------------
G567       | Sachertorte  |     1     |
---------------------------------------------
Bei dieser Art der MwSt-Zuweisung, ist es möglich, einem Artikel mehrere MwSt-Sätze zuzuweisen. Und das Kassenprogram sucht sich dann den richtigen Satz aus der Tabelle raus. Wenn der Artikel "A1234" nicht in der Liste mit den Verkaufsdetails enthalten ist, dann wird der Artikel "G567" mit 14% verkauft. Ist der Artikel "A1234" allerdings in der Liste mit den Verkaufsdetails, dann wird der Artikel "G567" mit 7% verkauft. Dieser ominöse Artikel "A1234" könnte den Namen "Ware wird mitgenommen" haben. Somit weiß das System, dass die Ware nicht im Lokal gegessen, sondern mitgenommen wird und kann darauf reagieren. Ob dieser Artikel dann auch auf dem Bon steht oder nicht, ist dann nicht mehr wichtig.
Wichtig ist nur, dass dadurch der richtige MwSt-Satz verwendet wurde und dass ich später exakt auswerten kann, wieviel im Lokal verzehrt wurde und wieviel die Kunden mitgenommen haben.

So kannst du schon mal ziemlich viele Länder abdecken und kannst auch flexibel auf Steueränderungen reagieren.

pyStyler hat geschrieben:**Zahlmittel
Was mache ich, wenn einer mit der Karte zahlen will ?
gibt es dafür externe Opensource Programme ?
Fast alle Anbieter von Kreditkarten-Terminals können das Terminal so einstellen, dass es unabhängig vom Kassenprogramm arbeitet. Der Kassier muss dann den Betrag direkt in das Terminal eingeben.

Wenn du dein Kassenprogramm mit so einem Terminal verbinden möchtest, dann musst du mit einer dieser Karten-Terminal-Anbieter zusammenarbeiten. In Österreich musst du dich sogar zertifizieren lassen, sonst lassen die dich nicht an die Bankomat-Terminals ran. In Österreich ist z.B. die Firma Europay oder besser deren Partner First Data Austria GmbH zuständig. Bei FDI kann man sich die Schnittstellenbeschreibung besorgen und sich zertifizieren lassen. In Deutschland ist es, glaube ich, einfacher.

pyStyler hat geschrieben:**Fremdwährung
reicht datum + Kassenbonnummer ?
Wenn beim Bezahlen des Bons **in Deutschland** "Britische Pfund", "Amerikanische Dollar" und "Euro" verwendet wurden, dann musst du mindestens den dafür verwendeten Wechselkurs für "Britische Pfund" und "Amerikanische Dollar" abspeichern. Natürlich mit Bezug zum Bon. Bezug zu einem Datum funktioniert nicht, da der Kurs sich auch im Laufe des Tages ändern kann.

Idealerweise speicherst du mit, wie und mit welcher Währung der Kunde bezahlt hat. Dann kannst du beim Tagesabschluss auch auflisten, was eigentlich in der Kassenschublade drinnen sein sollte. Wieviel Euro, wieviel Dollar und wieviel Pfund.

Fremdwährungen sind in Europa für den Einzelhandel nicht mehr so wichtig wie vor der Euro-Einführung. Aber wenn dein Programm auch in anderen Ländern Verwendung finden soll, dann kommst du um Fremdwährungen nicht herum.

pyStyler hat geschrieben:**Touchscreen oder doch nicht?
also es ist einfach so, dass ich mich mit Tkinter "Gut" auskenne, deshalb wird die Windows Version in Tkinter sein.
( sieht unter Windows Gut aus finde ich. Auf Wunsch gibt es einen Screen ) Frage: Gerold weisst du ob man Tkinter mit einem Touchscreen bedienen kann
Die meisten Touchscreen-Monitore simulieren einfache Mausklicks. Wenn dein Programm ohne Tastatur, nur mit der Maus bedienbar ist und die Buttons nicht zu klein gehalten werden, dann ist dein Programm mit einem TS bedienbar.

Viele Händler wollen TS-Lösungen. Weil sie einfach aussehen und hip sind. Händler, die darüber nachdenken und wollen, dass die Waren die Kassen schnell passieren, arbeiten mit programmierbaren Tastaturen und mit Barcodescannern. Das ist viel, viel schneller als TS-Lösungen. Aber auch eine Kombination aus Barcodescanner und Touchscreen kann schnell sein. Es kommt immer auch auf den Anwendungsfall an.

Z.B. bei McDonalds und Co würde ich niemals eine reine Tastaturlösung verwenden. Die haben exakt angepasste TS-Lösungen. Diese stehen dem Kassier zur Seite und weisen auf Menükombinationen und Angebote hin. Außerdem kann die Oberfläche auf neue Anforderungen angepasst werden.

Im Gastgewerbe haben sich TS-Lösungen auch bewährt. Erstens ist der Bildschirm hell, so dass auch in dunklen Lokalen alles gesehen werden kann. Zweitens gibt es im Gastgewerbe viele Kombinationen von Artikeln, die man über einen TS recht schnell auswählen kann.

Aber im Handel, oder z.B. bei Schellbedienungsrestaurants bin ich klar gegen den Einsatz von Touchscreens. Da ist ein geschulter Mitarbeiter mit einer programmierbaren Tastatur um Welten schneller.

pyStyler hat geschrieben:**Authentifizierung und Rechtevergabe
das wird echt mal schwierig denke ich!
eventuell hat einer eine Idee, wie ich es am besten lösen kann.
Bei PostgreSQL hast du ein Berechtigungssystem mit dabei, das du auch für dich verwenden kannst. Du kannst Rollen anlegen und Datenbankbenutzer diesen Rollen zuweisen. Später kannst du abfragen, welche Rollen einem Benutzer zugewiesen wurden.

http://www.postgresql.org/docs/8.2/stat ... manag.html

Und damit findest du z.B. raus, an welche Rollen der aktuell angemeldete Benutzer gebunden ist:
http://www.postgresql.org/docs/8.2/stat ... roles.html

Mit Rollen kannst du also erstens den Zugriff auf die Datenbank regeln und zweitens auch an Berechtigungen in deinem Kassensystem binden. Du musst nur irgendwo definieren, welche Rolle was tun darf. Das ist aber nur ein Beispiel. Es gibt auch andere Möglichkeiten.

pyStyler hat geschrieben:**Die richtige Datenbank
das ist echt mal ein grosses Problem was ich im Moment habe.
ich muss noch ein paar Nächte drüber schlafen.
Kassenprogramme sind typtische Datenbank-Programme. Ich habe oft überlegt, ob ich die Daten nicht irgendwie in das Dateisystem legen könnte, aber es spricht nichts dafür. Irgendwie muss man sich da alles selber programmieren. Jede kleine Suche oder ein Datenabgeleich endet dann in einer Programmier-Orgie.


lg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
ete
User
Beiträge: 218
Registriert: Montag 19. Februar 2007, 13:19
Kontaktdaten:

Mittwoch 23. April 2008, 11:38

Hallo Gerold!

Ich möchte für eine Freundin eine minimal Version einer Kassensoftware machen. Deine Tips haben mir schon grossartig weitergeholfen.
Kennst du vielleicht eine Demo von einer guten Kassensoftware, das man sich das ganze mal anschauen kann?

Liebe Grüsse
Stefanie
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Mittwoch 23. April 2008, 13:08

ete hat geschrieben:Kennst du vielleicht eine Demo
Hallo Stefanie!

Nein, leider.

lg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
pyStyler
User
Beiträge: 311
Registriert: Montag 12. Juni 2006, 14:24

Freitag 25. April 2008, 18:52

Hallo ete,

du kannst dir mal die Demo von http://www.bonit.eu/asp/download.asp laden und ausgiebig testen......

Gruss
pyStyler
BlackJack

Dienstag 6. Mai 2008, 10:41

Man sollte bei Kassensystemen auf jeden Fall diesen Testfall berücksichtigen: Lidl und der Kassen-Bug. :-D
Leon
User
Beiträge: 9
Registriert: Dienstag 10. Juni 2008, 22:06

Freitag 22. November 2019, 16:19

Hey ihr Kassierer :)
zwar schon etwas älter, der Eintrag hier... Aber: ich habe meine Kassensoftware in python geschrieben und bin damit ganz zufrieden.
Allerdings gibt es ja bald die Verpflichtung eine TSE (Technische Sicherheitseinrichtung) mit einzubauen.
Hat sich jmd von euch da mal mit beschäftigt?
lg, Leon
bwurst
User
Beiträge: 4
Registriert: Sonntag 22. Dezember 2019, 06:44

Sonntag 22. Dezember 2019, 19:03

Hallo.

Zunächst mal Hallo, ich bin hier neu im Forum. Ich hatte kurz Kontakt mit Leon per PN und wir haben beschlossen, dass es öffentlich weiter gehen soll. Lasst uns also diesen Thread wieder aufwecken. :)

Ich habe vor einiger Zeit auch ein Kassenprogramm in Python geschrieben. Allerdings einfach nur für meinen kleinen Betrieb zum Sebstnutzen. Den Aufwand der TSE-Unterstützung und DSFinV-K-Export kann ich noch nicht ganz überblicken aber ich wäre auf jeden Fall bereit, da Schweiß und im überschaubaren Rahmen auch Geld hinein zu stecken um mein geliebtes Kassenprogramm weiter nutzen zu können.

Leon, du hattest mir per PN angeboten, dass man sich gemeinsam ein TSE-Developer-Sample kaufen könnte. Ich würde sogar noch einen Schritt weiter gehen und versuchen gemeinsam eine Art Backend/Middleware zu machen um die damit verbundenen Klassen und Funktionen gemeinsam zu entwickeln. Da man die Hardware nicht gleichzeitig hat und der erste daher mehr Grundlagenforschung machen muss, könnte es auch so laufen dass ich das TSE zahle und du erstmal den grundlegenden Code machst, den ich dann übernehmen kann. Ich würde stark dafür plädieren, den daraus entstehenden Code des Backends unter einer FOSS-Lizenz (LGPL? BSD?) freizugeben.

Mein Kassenprogramm ist bisher ein Wildwuchs weil es eben nur von mir für mich entwickelt wurde. Da es bisher nicht im eigentlichen Sinne der GDPdU entspricht, habe ich diesen Code noch nicht als freie Software veröffentlicht, das kann ich aber bei Interesse gerne nachholen und für neuen Code strebe ich das auf jeden Fall an. Um das weiterhin gewerblich einsetzen zu können und damit auch mal eine Kassenprüfung zu überleben möchte ich die TSE-Einführung gleich dazu nutzen, die Datenverarbeitung und -Speicherung der Kassendaten neu zu machen und von meinen restlichen Geschäftsdaten getrennt zu verarbeiten. Diese Gelegenheit kann ich gerne dazu nutzen, Code auf einer anderen, gemeinsam Grundlage zu entwickeln, den ich nachher bei mir auch nutzen kann. Meine Programmierkenntnisse sind durchwachsen, ich bin eigentlich mehr Systemadmin und kein Programmierer. Da ich in den letzten Monaten einigen Code auf Python 3 migriert habe bin ich bei Python grade wieder ein bisschen mehr 'drin'.

Als ersten Schritt habe ich mal eine Anfrage an den DFKA geschickt um die Taxonomie-Unterlagen zu erhalten damit man die Datenfelder genau spezifiziert hat, die nachher für den Export gebraucht werden. Ich denke das ist auch als Grundlage für die lokale Datenverarbeitung ein guter Start.

Ich bin momentan unentschlossen ob man bei der sauberen Implementierung einer lokalen TSE auch gleich alle Daten für eine Ausgabe nach DSFinV-K bekommt oder ob es vor diesem Hintergrund ein Weg wäre, auf einen Cloud-Dienstleister zu setzen, der Fiskalisierung im Sinne von TSE, Datenarchivierung und -Export extern vornimmt. Dazu liegt mir aber bisher kein Angebot vor in welchen Preisbereichen wir uns da bewegen. Weiß da jemand eine Größenordnung?

Grüße
Bernd
Leon
User
Beiträge: 9
Registriert: Dienstag 10. Juni 2008, 22:06

Mittwoch 25. Dezember 2019, 09:26

Hey Bernd,
jo, von mir aus können wir das so machen: ich fange an mit der Programmierung und wir machen ein Open-Source-Projekt daraus.
Allerdings bin ich auch nicht so der Mega-Programmierer. Mein Kassensystem ist ja nur deshalb entstanden, weil ich das für meinen Laden gebraucht habe. Aber ich denke, zusammen werden wir das schon hinbekommen :)
Und dann brauchen wir ja noch einen Namen. Vielleicht sowas wie: python-tse ?
bwurst
User
Beiträge: 4
Registriert: Sonntag 22. Dezember 2019, 06:44

Donnerstag 26. Dezember 2019, 10:07

Der Name und auch der Erfolg des Projekts kommt ein bisschen drauf an, was der gemeinsame Code alles abdecken soll. Das liegt an zwei Faktoren: 1. wie die TSE-Ansteuerung funktioniert und wie sich das in den jeweiligen Code einbauen lässt und 2. Wie wir jeweils mit dem Code des anderen zufrieden sind bzw. wie sehr sich unsere Anforderungen da unterscheiden. Vermutlich lässt sich 1. nur klären wenn man mal angefangen hat.

Da ich ja auch nur so dahin programmiert habe und das anfangs nur ein kleines "rechne mir den Preis des Kunden aus" war, hatte ich das nie so als wiederverwendbaren Code konzipiert. Ich habe jetzt einfach mal meinen Code ohne Versionshistoy auf github gestellt: https://github.com/bwurst/bibkasse (Lizenzangabe ist ungenau weil ich noch ein paar Fremd-Libraries mit abweichender Lizenz im Repo habe)

Ich hab jetzt nicht erfasst welche dependencies das hat und ob das noch Zusatzkram braucht, der nicht enthalten ist (mind. die users.xml fehlt glaube ich komplett) aber zur Beurteilung wie weit voneinander unsere Coding-Skills sind, könnte es ja taugen.

Das Speicher-Backend ist bei mir wie gesagt nicht auf Kassendaten beschränkt und ich würde das daher gerne neu machen um dann gleich alle Daten in der Form zu haben wie es die neuen Verordnungen vorsehen.

Ich hab der Familie versprochen, die nächsten Tage das Thema nicht intensiv zu verfolgen, daher hab ich jetzt mal ein paar Tage Funkstille. :)

Wünsche daher schöne Restfeiertage und nen schwungvollen Start ins neue Jahr, dann können wir das Thema nochmal durchackern.

Gruß
Bernd
Leon
User
Beiträge: 9
Registriert: Dienstag 10. Juni 2008, 22:06

Freitag 27. Dezember 2019, 09:40

Moin,
das sieht ja schon ganz schön gut aus, die bibkasse.
Ich habe manche Sachen ähnlich gemacht, manche ein bisschen anders. Z.B. habe ich die GUI mit wxPython gemacht. Aber ich glaube, vom Coding-Style können wir uns schnell einig werden.
Ich glaube auch, dass unser Projekt nicht wirklich kompliziert wird. Wir brauchen doch eigentlich nur sowas hier:

Code: Alles auswählen

class PythonTSE:
    def bon_start():
        # TSE-Code aufrufen...
        # ...
    def bon_abort():
        # ...
Also, dann bis nächstes Jahr! :)
bwurst
User
Beiträge: 4
Registriert: Sonntag 22. Dezember 2019, 06:44

Samstag 28. Dezember 2019, 13:50

Okay, konnte es nun doch nicht lassen. :)

Was du vorschlägst ist also "nur" die Ansteuerung der Swissbit-TSE aus Python, also die Abbildung der in der TR-03151 definierten Vorgänge. Ja, das ist das Minimalprogramm und wär schonmal was. :)
Ich selbst muss auf jeden Fall noch einiges mehr an meinem bestehenden Code ändern, da ich bisher z.B. keine fortlaufenden Bonnummern, Transaktionsummern und so verwalte.

Nach Lektüre von TR-03151 und DSFinV-K sehe ich keinen Grund zur Annahme, dass die TSE mit Einzelposten gefüttert wird. Das Feld processData enthält ja nur Brutto-Beträge. Das bedeutet, dass auch der geforderte Export nach DSFinV-K nicht über die TSE geht sondern dass man das getrennt abwickeln / implementieren muss. Das ist vermutlich viel mehr Arbeit als die bloße Anbindung der TSE.

Ich habe jetzt die DSFinV-K durchgelesen und da werden für die Exportdateien extrem viele Datenfelder spezifiziert und ein Großteil davon sind für mich irrelevant. In den Beispielen sind auch viele Felder leer, in der Spezifikation ist aber leider nicht definiert welche Felder optional sind. Ich denke das wird die Herausforderung. :)

Natürlich weiß ich nicht, wie dein Betrieb arbeitet und welche Vorgänge da in der Kasse abgebildet sind aber falls wir eine gemeinsame Datenstruktur finden könnten, dann könnte man den Export nach DSFinV-K auch gemeinsam entwickeln. Wenn du dein Kassen-Programm nur bei dir einsetzt, würdest du den (vorhandenen) Code auch öffentlich zugänglich machen?

Gruß
Bernd
Leon
User
Beiträge: 9
Registriert: Dienstag 10. Juni 2008, 22:06

Samstag 4. Januar 2020, 12:13

Hey Bernd,
ich wäre dafür, dass wir erstmal mit der Minimallösung (die in TR-03151 definierten Vorgänge) anfangen. Wenn es gut klappt, dann können wir gerne mit dem Export etc. weitermachen.
Meinen restlichen Code möchte ich eigentlich nicht veröffentlichen, weil ich da evtl. nochmal ein kommerzielles Projekt draus machen will. Aber wenn es soweit ist, kann ich ja nochmal überlegen, oder wir vergleichen einfach die Datenstruktur und alles, was sonst noch für den Export benötigt wird.
lg, Leon
bwurst
User
Beiträge: 4
Registriert: Sonntag 22. Dezember 2019, 06:44

Samstag 4. Januar 2020, 12:33

Okay. Ich hab mir das auch nochmal durch den Kopf gehen lassen und ich kann mich auch erstmal mit einer Minimallösung anfreunden. Und wenn ich dann zunächst keinen Export habe, dann ist das halt so. Müsste ich im Notfall dann hacken wenn ihn einer haben will. Ich hab vermutlich alle dafür nötigen Daten schon jetzt greifbar irgendwo in der Datenbank.

So wie ich mir die Infos bisher zusammen gereimt habe, sollte es dann wirklich nicht viel Code sein, der für die TSE nötig ist, ein richtiges "Projekt" ist es dann erstmal nicht. :)

Also, wie können wir das jetzt organisatorisch machen? Magst du das DEV-Kit kaufen und ich kaufe es dir danach ab? Möglicherweise ist es auch angemessen, das zu behalten weil man das für weitere Tests und Weiterentwicklungen noch nutzen möchte. Vermutlich merkt man das erst wenn man's hat.

Ich bin nach wie vor dafür, Ressourcen zu teilen. Vorschlag: Entweder ich kaufe das DEV-Kit und leite es dir umgehend vollständig weiter (möchte mir natürlich irgendwie Zugang zu den Developer-Unterlagen verschaffen), im Gegenzug bekomme ich Zugriff auf den von dir erstellten Sourcecode um das Teil anzusteuern. Alternativ kaufst du das Kit und ich verspreche, dir das auf deinen Wunsch hin (z.B. bis spätestens Ende Februar damit ich auch noch Zeit habe was zu programmieren) wieder zum halben Preis abzukaufen, sofern das vom Hersteller nicht irgendwie verhindert wird. Willst du es behalten, kauf ich mir halt ein eigenes.
Antworten