TSE für Kassenprogramme - VB 6 Code Beispiel liegt vor

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 25 Antworten in diesem Thema. Der letzte Beitrag () ist von Harry55.

    TSE für Kassenprogramme - VB 6 Code Beispiel liegt vor

    Moin
    Ich habe ein eigenes Kassenprogramm in Visual Basic programmiert (vor Jahren). Dafür brauche ich ja nun bald eine TSE (Technische Sicherheitseinrichtung) um Manipulation an der Kasse zu verhindern. Die Hardware dafür habe ich bekommen (USB Stick), aber mit der Software komme ich nicht weiter. Ich war etwas verblüfft, dass ich vom Hersteller der TSE Beispiel Code in VB6 bekommen habe. Auf die dazugehörige DLL läßt sich aber in Visual Studio nicht verweisen. Denke ich falsch, wenn ich meine, dass VB6 echt alt ist für eine Hardware aus 2020? Es gibt auch Beispielcode in C, aber auch hier bekomme ich keinen Verweis zu der DLL hin (und ich will auch nicht in C programmieren)
    Hat sonst jemand Erfahrung mit der Einbindung von TSE in Kassenprogramme?

    Danke für eine Hilfe.
    Ich bin Umsteiger: Früher VB 4.0 prof, heute VB NET unter Studio 2019 Community Edition (und da noch ein Greenhorn :D )

    mgbig schrieb:

    Auf die dazugehörige DLL läßt sich aber in Visual Studio nicht verweisen.
    Wenn das ne native DLL ist, geht das auch.
    Schau mal hier rein: Austausch von Daten zwischen einer VB.NET-exe und einer C-DLL, 32 und 64 Bit
    Allerdings musst Du dann Dein Programm je nach dem auf x86 oder x64 umstellen, AnyCPU geht da nicht.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Danke, da muss ich mich reinlesen.

    Aber ist es grundsätzlich richtig zu sagen, dass VB6 veraltet ist? Oder gibt es noch Gründe heute damit zu arbeiten?
    mgbig
    Ich bin Umsteiger: Früher VB 4.0 prof, heute VB NET unter Studio 2019 Community Edition (und da noch ein Greenhorn :D )

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „mgbig“ ()

    VB 6 ist von 1998 und das letzte Update ist von 2012. Entscheide du, ob das veraltet ist. ;)

    Ich selbst entwickle auch noch in VB 6, wobei ich vor Kurzem auf .NET gewechselt bin. Aber ein Softwareprodukt wird weiterhin VB 6 bleiben, weil eine Portierung zu aufwendig ist. Da VB6-Programme selbst unter der neuesten Version von Windows 10 (auch 64 Bit) noch tadellos funktionieren, lehne ich diese alte Version nicht pauschal ab. Ich sehe bei VB6 den Vorteil, dass man den Quellcode der Programme nicht wiederherstellen kann.
    Besucht auch mein anderes Forum:
    Das Amateurfilm-Forum
    Ja, sorry, dass ich mich dazu noch nicht gemeldet habe. Ich habe jemanden gefunden, der mir eine DLL zur Verfügung gestellt hat (gegen Bares) und ich komme prima damit klar.
    Technisch spreche ich die TSE mit JSON an und bekomme eine passende JSON Antwort, die ich dann weiterverarbeiten kann.
    Mit JSON hatte ich davor keine Erfahrung, aber wenn man es einmal verstanden hat ist es gut zu händeln. Dafür habe ich natürlich auch die passende DLL bekommen.
    Verständlicher Weise kann ich die hier nicht zur Verfügung stellen, aber wenn jemand ein ähnliches Problem hat, kann er mich gerne kontaktieren.

    Davon ab habe ich einige TSE Bons aufgehoben. Zum einen sind noch lange nicht alle Bons mit einer TSE signatur versehenund zum anderen sind die Ausgaben nicht wirklich einheitlich....
    Dateien
    • Bons mit TSE .pdf

      (218,17 kB, 335 mal heruntergeladen, zuletzt: )
    Ich bin Umsteiger: Früher VB 4.0 prof, heute VB NET unter Studio 2019 Community Edition (und da noch ein Greenhorn :D )
    Ich habe jetzt seit gestern eine Möglichkeit gefunden.
    Notwendig ist lediglich eine SD Karte (TSE) und etwas VB6 Programmiercode, welchen ich in ein Klassenmodul gepackt habe.

    Mit..
    Dim cTSE as clsTSE
    set cTSE = new clsTSE
    cTSE.Start (plus Passwörter etc..)
    cTSE.AddItem (plus Beträge, MwSt, Währung etc..)
    cTSE.Close
    ist alles erledigt. EInfacher gehts nicht.

    Anfangs dachte ich, dass die Implementierung in eine bestehende Software eine unüberwindbare Hürde darstellt. Sicher - wer die entsprechende DLL programmiert, hat eine wahnsinns Arbeit gehabt. Aber der, der die DLLs einsetzt, hat einen Programmier-Aufwand von 30 Minuten und danach ist die bereits bestehende Software umgerüstet/erweitert.

    mgbig schrieb:

    Hi
    Gut zu lesen. Von welchem Hersteller ist die TSE? Und das ganz läuft dann unter VB6?
    Gruß mgbig


    @mgbig: Ja, das ganze läuft unter VB6 und zwar astrein. Sowohl 32- als auch 64bit. Weiteres in Kürze..

    @Harry55: Das Klassenmodul hab ich mir selbst gebastelt und "vollgepackt" mit Funktionen. Der Beispiel-Code zum Ansprechen der TSE-Module wurde zwar mitgeliefert, war aber teils fehlerhaft. Keine Ahnung ob derjenige wirklich in VB6 programmiert, oder einfach nur damit zeigen wollte, wie es ungefähr aussehen könnte. Jedenfalls war nach relativ wenig Zeitaufwand alles zurecht gebogen und die von mir erstellte Klasse könnte ich später mal zur Verfügung stellen. Zu deiner Frage bezüglich "etwas Programmiercode" muss ich sagen, dass das Netz voll ist mit Beispielen für VBA und VB6 und VB.Net welche TSEs ansprechen. Die sind aber ziemlich alle fehlerhaft oder nur auszugsweise. Wie bereits erwähnt, könnte ich später mal meine Klasse zur Verfügung stellen. Eines kann ich schonmal verraten: Der Code ist NICHT für EPS..-Module. Lasst euch überraschen.. (Ein bisschen Spannung muss sein)

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „RKCologne“ ()

    Moin,

    ich muss mal ganz doofe Fragen zum TSE allgemein stellen, da du ja schon etwas Erfahrung damit hast.
    Wir haben ein Swissbit Developer TSE inkl. SDK und dafür ist es jetzt meine Aufgabe, unsere Software anzupassen damit diese ihre Daten auf das TSE speichert.

    Das SDK ist relativ selbsterklärend, ein Test Projekt in C# liegt auch bei (selber programmiere ich nur in vb.net).

    Allerdings erschließt sich mir die allgemeine Funktionalität des Software nicht. Ich bekomme die Möglichkeit über Start, Update und Finish jeweils Daten in Textform schreiben zu lassen.
    Was genau muss hier rein?

    Ich habe folgende Daten, die da rein müssten:

    Quellcode

    1. Briefkopf, Zahlungsinformationen, Vorgangsnummern
    2. Positionen (Bezeichnungen, Artikelnummer, Positionsnummer, Brutto/Netto Preis, ausgewiesene MwSt, MwSt Satz, Menge)


    Die gesamte Logik von Start, Update und Finish erschließt sich mir nicht, da ich bei jedem der drei einen Text eingeben könnte.

    Du selber beschreibst es in deinem Beispiel oben mit:

    VB.NET-Quellcode

    1. ​cTSE.Start (plus Passwörter etc..)
    2. cTSE.AddItem (plus Beträge, MwSt, Währung etc..)


    Start = Start, AddItem = Update ???

    Können die Daten in einer beliebigen Formatierung geschrieben werden?
    @BlueLagoonX :
    Die Formatierung der Werte ist natürlich exakt vorgeschrieben. Beträge bspw. immer "0.00" und Einstellungen bspw. als Long bzw. UInt. Eben so, wie es die DLL Dokumentation vorschreibt. Wenn beispielsweise ein Admin Code verlangt wird, dann muss das ein String sein, der exakt 6 Stellen lang sein muss.
    Anderes Beispiel: Man kann auch eine 1 für "Beleg" oder eine 2 für "Rechnung" als Vorgangsnummer übergeben. Diese Werte gibt die mitgelieferte DLL vor. Manche DLLs lassen auch zusätzlich Texte zu, wie "Beleg^", oder "Rechnung^" (Man beachte das Sonderzeichen).
    Zahlungsinformationen können "Bar" und "Unbar" sein. Oder "Bar" und "Kreditkarte".

    Erklärung: Eine TSE ist nichts anderes als der Chip auf dem USB-Stick bzw. der Chip im BON-Drucker. Dieser Chip ist vom BSI zertifiziert. Die DLL "spricht" mit dem Chip. Ein beschädigter USB-Stick kann nicht repariert werden und muss ausgetauscht werden (ca. 270,00 EUR im VK, ca. 2,00 EUR Materialwert). Die Zertifizierungskosten werden auf das Produkt umgelegt und ein satter Gewinn ist anscheinend auch einkalkuliert.

    Meine eigene Klasse:
    cTSE.Start leitet bei mir die Initialisierung des USB-TSE-Sticks ein (Initialisierung, Datumseinstellung, Uhrzeiteinstellung, KassenNameÜberprüpfung, MHD der TSE etc..).
    cTSE.AddItem ist quasi das Update. Ich habe es AddItem genannt, da 1 Artikel in meinem Warenkorb der TSE übergeben wird. Jeder weitere Artikel im Warenkorb wird bei mir ebenfalls mit einem AddItem übergeben. Ob man seine Funktion nun Update oder AddItem benennt, ist egal. Für mich war die Benennung/Handhabung des Codes so logischer.

    Allgemein: Finish beendet den Buchungsvorgang/Transaktion und eine eindeutiger Code wird dabei zurück gegeben. Aber nicht nur der eindeutige Buchungs-Code an sich, sondern gleich noch 10 oder 15 oder 20 andere Werte (TSE-Zähler, TSE-Counter, TSE-Unterschrift...) die in einem Container auf dem TSE-Stick abgelegt werden. Diese muss man dann abfragen und in seiner Datenbank/in seinem Programm mit abspeichern. Erst dann ist das Prozedere beendet.

    Fazit zum Schluss: Doku der DLL lesen (Übergabewerte, Stringlänge, Datentypen..) Zudem: Jeder Hersteller (Epson, Swissbit, Cryptopvision etc..) handhabt seine DLL etwas anders. Eine allgemein gültige Formel gibt es dafür nicht. Selbst der Epson-TSE-Drucker und der Epson-TSE-USB Stick werden leicht unterschiedlich behandelt.
    Hat man bspw. sein Programm auf den Swissbit USB-Stick programmiert, kann später nicht einfach ein anderer Hersteller oder ein anderes Medium verwendet werden. Quasi: Einmal Epson-USB-Stick - immer Epson-USB-Stick. Es sein denn, man lässt den User auswählen und implementiert in sein Programm mehrere Versionen. Der Programmierer hat dann aber enorm viel Mehrarbeit und zudem wesentlich mehr Fehlerquellen, Updatearbeit etc...

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „RKCologne“ ()

    Hallo Leute,

    ich komme nicht umher hier auch meinen Senf abzugeben.

    Ich bin seit 15 Jarhen Kassensoftwarehersteller und habe 2015 mit der umsetzung der RKSV (Fiskallösung in Österreich) begonnen und Ende 2018 die Einbindung der TSE Funktionalitäten begonnen.

    Die österreichische Fiskal-Chipkartenlösung (RKSV) habe ich in 5 meiner Softwareprodukte integriert.
    Die deutsche TSE-Lösung laut KassenSichV habe ich in meine zwei "Zugpferde" BONit FlexX (Kassensoftware) und Simply Hotel 2 (Hotelsoftware) integriert.
    Die österreichische Lösung läuft seit Anfang 2017 und die deutsche Lösung wurde Anfang September 2020 bei allen unseren deutschen Kunden installiert.

    Bei der Umsetzung der Chiplösung 2015 für Österreich habe ich sehr viel programmiertechnisch dazugelernt.
    Speziell Webservice und so. Auch für mich war JSON damals ein unbeschriebenes Blatt - aber ist ja ähnlich wie XML, nur mit sehr viel unnötigen Zeichen ;-).

    Ich arbeite seit 2015 mit der Firma EFSTA zusammen (efsta.eu). Diese haben eine Middleware entwickelt die die Kommunikation mit der TSE und die Datenspeicherung übernimmt.
    Ich spreche diese Middleware einfach über ein Webservice an und übermittle alle relevanten Daten. Die Signatur, Verschlüsselung, revisionssichere Sicherung etc. muss ich mich nicht kümmern.

    Ich dachte Ende 2018 auch ich könnte die deutsche TSE-Einbindung mit dieser Vorerfahrung ohne EFSTA auf manuellen Wege machen.
    Dazu gab es von verschiedenen TSE-Hardwareanbietern diverse API´s die scheinbar "easy" waren.

    Bei diesen APIs muss man aber beachten, dass diese lediglich die Kommunikation mit der TSE sicherstellen. Die Ernüchterung kam also schnell.
    Die Bereitstellung der annähernd 20 CSV-Dateien für den revisionssicherne DSFinVK Export und die Datensicherung der TSE-Daten muss man sich selbst "basteln".
    Zudem ist die Beschaffung von Informationen von der deutschen Finanz mehr als mühsam und für "kleine" fast schon unmöglich.
    Daher habe ich mich auch hier wieder für die Middleware der Firma EFSTA entschieden, die haben sich mit dem BSI auch regelmäßig getroffen und haben so alle Infos aus erster Hand.

    Es werden im Prinzip alle Belegdaten zur Middleware geschickt und diese sammelt dann die erforderlichen Informationen und Daten um den DSFinVK Export so generieren zu können,
    dass dieser auch einer Finanzprüfung widersteht. Zudem ist egal welche TSE (also von welchem Hersteller) angeschlossen ist, da sich die Middleware um die Kommunikation kümmert.

    Also meine persönliche Meinung:
    Viele "kleine" Programmierer und Softwareschmieden werden zwar die TSE "scheinbar" eingebunden haben, aber bei einer der ersten Tiefenprüfungen und den ersten DSFinVK Exporten Probleme bekommen. Und das gibt dann richtig Ärger mit der Finanz und der Kunde wird sich natürlich am Softwarehersteller schadlos halten.
    Auf diversen Veranstaltungen der TSE-Hersteller und teils auch der Interessensvertretungen hat man am Anfang gehört "ja das setzen wir selbst um - ist easy". Aber die selben Leute haben ein paar Monate später gemeint "nein, das drumherum ist mir zu aufwändig, ich ziehe mich gleich ganz vom deutschen Markt zurück".

    In diesem Sinne hoffe ich, dass Ihr bei der Umsetzung nicht nur die technische Kommunikations zwischen Software und TSE Modul berücksichtigt, sondern auch die sehr umfangreichen rechtlichen Rahmenbedingungen bishin zum (m.M.n) sehr ausufernd definierten DSFinVK Export.
    Liebe Grüße
    Roland Berghöfer

    Meine aktuellen und kostenlos verwendbaren Tools (mit VB.NET erstellt): freeremarkabletools.com | priconman.com | SimpleCalendar | AudibleTouch | BOComponent.com | bonit.at
    @dive26
    Hallo Roland,

    du hast natürlich Recht. Ein paar Funktionen mit der TSE austauschen ist die eine Sache, aber der Rest (Export) ist eine andere Sache.
    Da aber sämtliche relevanten Daten auf der TSE und zudem in einer Anwendung bereits vorhanden sind, ist der Export auch kein wirklich riesiges Problem.
    In meiner vorliegenden DLL ist der Export bereits implementiert und erzeugt insgesamt 14 Dateien im XML, TAR und CSV Format.

    Sicher bist du ein guter Programmierer und die Unwahrheit hast du auch nicht gesagt. Aber es ist ein leichter Beigeschmack von Eigenwerbung in deinem Bericht - zumindest kommt es bei mir so an.
    Deine Erfahrungen sind im Übrigen von 2015 bis 2018. Wir haben quasi 2021 und in der Zwischenzeit hat sich reichlich getan.

    Cloudlösungen bei TSE´s haben nicht nur Vorteile wie du es schreibst. Es sind auch reichlich Nachteile damit verbunden. Gerade in Österreich kann man keine Buchungen tätigen wenn kein Internetzugang besteht. In Deutschland hingegen kann man Buchungen auch stapelweise nachbuchen in der TSE. Das heißt, ein Verkaufsvorgang im Laden ist in Deutschland auch ohne Internet möglich und erst recht wenn man keine Cloudlösung hat.

    Ich persönlich finde eine USB-TSE (Stick oder Drucker) letztlich die bessere Variante.
    Eine Cloudlösung hat ebenfalls seine gewissen Vorteile. Billig, oder billiger ist diese jedoch nicht. Ein USB-TSE-Stick kostet einmalig im Einkauf 187,00 EUR (VK 257,00 EUR) mit 5 Jahres-Lizenz. Was kostet eigentlich eine Cloudlösung in 5 Jahren?

    Gruß aus Deutschland nach Österreich

    RKCologne

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „RKCologne“ ()

    Hallo @RKCologne,

    ich wollte bei Weitem die Arbeit von anderen nicht schmälern, sondern lediglich auf die Fallstricke absweits der technischen Anbindung hinweisen.
    Die ursprüngliche Frage (von mgbig) lies vermuten, dass hier noch keine Vorinfos über die TSE vorhanden waren - das erinnerte mich an mich selbst noch vor ein paar Jahren.

    Ich bin bei weitem kein guter Programmierer. Habe es nie gelernt, sondern mir alles selbst beigebracht. Dieses Forum hier hat mir auch sehr viel beim Lernprozess geholfen.
    Mein Codestil ist auch garantiert nicht "schön wie aus dem Lehrbuch", aber er funktioniert einwandfrei;-).

    Das mit der Cloudlösung ist im Normalfall so wie sie es beschreiben. Nicht aber bei der EFSTA Cloud.
    Wir verwenden auch eine LOKALE TSE Hardware. Internetzugang ist während des Betriebs nicht unbedingt erforderlich.
    Das lokale EFSTA Webservice signiert und speichert die Daten lokal am Kundenrechner.
    Sobald Internetverbindung besteht, werden die gesammelten Daten (im Hintergrund automatisch) in die EFSTA Cloud gesendet.
    Dort werden Sie auf einem europäischen Server revisionssicher 10 Jahre lang gespeichert.
    Natürlich gäbe es auch die Möglichkeit damit eine Online-TSE zu verwenden. Das habe ich aber von vornherein abgelehnt (aus den selben Gründen wie Sie es formuliert haben).

    Der Vorteil der lokalen Webservice-Lösung von EFSTA ist, dass man auch bei mehreren Kassenterminals nur eine TSE-Hardware auf einem Rechner braucht - dort wo das lokale Webservice läuft. Die Terminals greifen bei der Signatur dann einfach auf das Webservice zu. Das finde ich einen großen Vorteil.

    Der einzige Nachteil der Cloud-Backuplösung ist m.M.n. nur der sehr hohe Preis der Backup-Cloud.

    Wir verwenden die TSE Hardware von Diebold Nixdorf.
    Die hat den Vorteil, dass diese vom Werk aus ein 7 Jahre gültiges Zertifikat hat.
    So können wir auch eine gewisse Stückzahl auf Lager halten und unsere Kunden sofort damit beliefern und immer mindestens 5 Jahre Laufzeit garantieren.

    PS: meine Erfahrungen sind von 2015 BIS heute. Noch Anfang September 2020 habe ich Änderungen/Verbesserung in die TSE-Anbindung implementiert.

    Fazit:
    Für Entwickler mit nur wenigen Installationen ist es nicht nur "rechtlich sicherer", sondern womöglich auch technisch einfacher auf Middleware von diversen Anbietern zurückzugreifen. Da gibt es ja neben EFSTA auch noch Fiscaltrust und Fiskally.
    Liebe Grüße
    Roland Berghöfer

    Meine aktuellen und kostenlos verwendbaren Tools (mit VB.NET erstellt): freeremarkabletools.com | priconman.com | SimpleCalendar | AudibleTouch | BOComponent.com | bonit.at

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „dive26“ ()

    @dive26
    Hallo Roland,
    ich dachte BIS 2018 hast du dich allgemein mit TSE beschäftigt und SEIT 2018 hast du dich für die Cloudlösung entschieden und den Rest liegen lassen. So verstand ich zumindest den Beitrag. Wenn dem nicht so ist, dann sorry.
    Ich rede die Cloudlösung bzw. die Webservice-Lösung nicht schlecht, die hat sicher Vorteile und 7 Jahre Lizenzen sind ungewöhnlich hoch. Ich dachte der BSI hat gesetzlich maximal 5 Jahre festgelegt - dann irre ich mich vielleicht - k.A.

    Aber was mich interessiert, was kostet solch eine TSE-Lösung ca. inkl. BON-Druckdienst, Backup-Lösung etc..?

    Danke für deine Antwort.

    Gruß nach Österreich

    RKCologne
    Aber was mich interessiert, was kostet solch eine TSE-Lösung ca. inkl. BON-Druckdienst, Backup-Lösung etc..?


    "Bon-Druckdienst" gibts da keinen. Das generieren wir aus unserer Software ;)

    Deutsches TSE-Paket
    Inkl. Diebold Nixdorf TSE-Hardware, Installation per Fernwartung, 5 Jahre Support und 5 Jahre Cloudbackup (also bis 15 Jahre revisionssichere Datenarchivierung) € 1.450,00. Dabei ist das aber schon ein Spezialpreis weil wir die 5 Jahre Cloud vorausbezahlen. Bei jährlicher Zahlung wärs noch um ein Hauseck teurer.

    Österreichisches TSE-Paket
    Mit A-Trust Chipkarte, Reader, Installation per Fernwartung, Support einmalig €149,00 und €84,00 pro Jahr direkt an EFSTA für die EFSTA Cloud.

    Softwarepreis (als Beispiel unsere Kassensoftware, die wir gemeinsam mit knapp 40 Partnern über 6000x in ganz Europa installiert haben) € 399,00 einmalig und 100,00 Nutzungsgebühr pro Jahr (wobei da Updates und Support bereits inklusive sind).
    Wie man sieht sind wir dort wo wir können - also bei der Software aus unserem hause - relativ preiswert.

    Diese Preise und Informationen findet man jederzeit öffentlich auch auf unserer Homepage - wir haben alles ausgepreist und kommunizieren alle Konditionen mit den Kunden vor dem Kauf. Ich mag es auch selbst nicht, wenn man wegen einer unverbindlichen Preisauskunft "Kontakt aufnehmen und Daten hergeben muss" ;-).
    Liebe Grüße
    Roland Berghöfer

    Meine aktuellen und kostenlos verwendbaren Tools (mit VB.NET erstellt): freeremarkabletools.com | priconman.com | SimpleCalendar | AudibleTouch | BOComponent.com | bonit.at
    @dive26
    Ich fragte nach der BON-Geschichte, weil EFSTA dies als Zusatzpaket anbietet.
    Klar, da hast du Recht, das Einfachste was man selber in seiner Software erstellen kann, ist der BON. Blödsinn dafür Geld auszugeben. Komisch nur, warum das als Zusatzpaket angeboten wird.

    Deutsches TSE Paket:
    Ich finde das sehr teuer. Und damit ein Todesstoß für weitere meiner (früheren) Überlegungen.

    Österreichisches TSE Paket:
    Sehr günstig, aber für mich als Deutscher nicht brauchbar denke ich, da andere Richtlinien in Deutschland herrschen.

    Meine Kassensoftware (seit 1999 in Betrieb) kostet 8,10 EUR monatlich. Keine Supportkosten, keine Updatekosten, keine versteckte Kosten, Änderungswünsche - soweit es für die Mehrheit einen Nutzen hat, sind ebenfalls kostenlos. Verwaltet werden Einnahmen, Ausgaben, Termine (auch Online-Buchungen), Mitarbeiter, Kunden, Lager, Gutscheine, ABOs, Artikel, Dienstleistungen, Räume, Newsletter, Rechnungen, BONs (auch Online-BONs), Kassenbuch, Kassenberichte, Tages- Monats- Jahresberichte, DATEV-Export...

    Eure Software ist ebenfalls sehr preis-wert und ich denke sehr fair mit 100,00 EUR Nutzungsgebühr. Da können sich die Kunden nicht beschweren. Die 6000 Installationen sprechen für sich. Gratulation. Hab mir die Seite eben mal angesehen - GUT GEMACHT ! Wie ich sehe, bist du richtig gut aufgestellt mit deiner Kassen- und Hotelsoftware. Respekt :thumbsup: . So wünscht man sich das :)

    Ich werde jetzt noch ein wenig weitertüfteln mit der TSE Geschichte und eine Tüte Gummibärchen dabei essen :)

    Gruß nach Österreich

    RKCologne
    Moin zusammen

    habe lange nicht mehr gelesen, was hier so passiert. Ich finde es sehr bezeichnend, dass noch längst nicht alle Bons mit einer TSE Signatur ausgegeben werden. Und da sind kleinere Betriebe eher mit dabei wie große. Ich lasse mir aktuell immer die Bons geben, auch wenn mich das früher nicht interessiert hat. Auch ist das was auf den Bons steht bei weitem nicht einheitlich.
    Und ja, ich beiße mich jetzt da durch. Ich glaube, dass ich mit meinem "Lieferanten" jemanden gefunden habe, der sich ganz gut auskennt. Die Anbindung mitteils VB.NET scheint eher exotisch zu sein....
    Ich bin Umsteiger: Früher VB 4.0 prof, heute VB NET unter Studio 2019 Community Edition (und da noch ein Greenhorn :D )
    @mgbig
    Eine Vorschrift bzw. eine Einheitlichkeit auf den BONs ist nicht vorgeschrieben und auch nicht vorgesehen. Manche Dinge/Details "MÜSSEN", andere "SOLLTEN", wieder andere "KÖNNEN" auf einem BON vermerkt sein.

    Warum manche noch nicht umgestellt haben:

    Die Umstellung ist erst für den 31.12.2022 vorgesehen. Nämlich für all jene, die zwischen 2010 bis 2019 ein Kassensystem gekauft haben welches sich nicht umrüsten lässt. Hat man aber 2020 ein Kassensystem gekauft, oder das alte kann man umrüsten, dann MUSS man ab 01.04.2021 umgestellt haben - ohne wenn und aber.

    Wer generell NICHT umstellen muss:

    All jene, die elektronisch nichts aufzeichnen. Die ganzen Bestimmungen gelten AUSSCHLIEßLICH für elektronische Aufzeichnungen. Wer noch immer Quittungsblöcke nutzt und seine Kunden in einem Büchlein führt, ist auch NICHT an die neuen Bestimmungen gebunden.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „RKCologne“ ()