TSE nach 146a AO Schnittstelle

[noisy_master]

Hallo liebe Delphi Gemeinde,

ich habe gesehen, dass es hier scheinbar schon etliche Kollegen gibt, die sich mit den TSEs gemäß 146a AO auseinandersetzen.Dazu hätte ich mal ein paar generelle und ein paar spezielle Fragen:

- gibt es da inzwischen schon etwas zertifiziertes?
- wenn ja: wo?
- wenn nein: gibt es irgendwo was womit man mal "spielen" kann/ Demo Kit?

Jetzt ein paar speziellere Fragen zur API:
- short int authenticateUser( *userId, userIdLength, *pin, pinLength, *authenticationResult, *remainingRetries);
Wo kommen denn die UserIds und die dazugehörigen PINs her? vom Hersteller?
- startTransaction(*clientId, clientIdLength, *processData, processDataLength, *processType, processTypeLength, *additionalData, additionalDataLength, *transactionNumber, *logTime, **serialNumber, *serialNumberLength, *signatureCounter, **signatureValue, *signatureValueLength);
Die out Parameter ab transactionNumber sind klar, aber was kommt in die anderen Parameter rein? ClientID ist auch noch halbwegs klar, aber: legt man die selber fest?
- finishTransaction ist dann auch halbwegs klar: damit beendet man halt die Transaction, aber wozu sind da die Parameter processData und additonalData gut?
- und wozu ist dann die UpdateTransaction da?

wenn das zuviel an Fragen sein sollte : gibt es irgendwo eine Quelle die das VERSTÄNDLICH erklärt?

Danke schonmal vorab ....

[arnof]

Zitat:

Zitat von noisy_master (Beitrag 1446899)

Hallo liebe Delphi Gemeinde,

ich habe gesehen, dass es hier scheinbar schon etliche Kollegen gibt, die sich mit den TSEs gemäß 146a AO auseinandersetzen.Dazu hätte ich mal ein paar generelle und ein paar spezielle Fragen:

- gibt es da inzwischen schon etwas zertifiziertes?
- wenn ja: wo?
- wenn nein: gibt es irgendwo was womit man mal "spielen" kann/ Demo Kit?

Jetzt ein paar speziellere Fragen zur API:
- short int authenticateUser( *userId, userIdLength, *pin, pinLength, *authenticationResult, *remainingRetries);
Wo kommen denn die UserIds und die dazugehörigen PINs her? vom Hersteller?
- startTransaction(*clientId, clientIdLength, *processData, processDataLength, *processType, processTypeLength, *additionalData, additionalDataLength, *transactionNumber, *logTime, **serialNumber, *serialNumberLength, *signatureCounter, **signatureValue, *signatureValueLength);
Die out Parameter ab transactionNumber sind klar, aber was kommt in die anderen Parameter rein? ClientID ist auch noch halbwegs klar, aber: legt man die selber fest?
- finishTransaction ist dann auch halbwegs klar: damit beendet man halt die Transaction, aber wozu sind da die Parameter processData und additonalData gut?
- und wozu ist dann die UpdateTransaction da?

wenn das zuviel an Fragen sein sollte : gibt es irgendwo eine Quelle die das VERSTÄNDLICH erklärt?

Danke schonmal vorab ....

- Zertifiziert; Stand gestern : kein Hersteller hat ein Zertifikat .....
- also nein: Demokits gibt es von swissbit, crytovision und epson

Teilweise sind diese aber nicht mehr lieferbar; Epson z.B. (ich war gestern auf einer Veranstaltung von Epson; die hatten nur 50 Entwicklerpakete, eines konnte ich vor Wochen durch Vitamin B ergattern)

Swissbit hat mittlerweise schon die 2'te Version (Kosten der 1. nun für den Müll Version 800,- EUR; die 2'te kostet auch wieder 160,- EUR) ....

Crytovision habe ich auch ein Muster (Hand gelöteter USB Stick mit ein paar javadateien; Doku passt nicht zum Muster -> Kosten 400,- EUR)

Jeder Hersteller hat ähnliche Funktionen, da diese von dem BSI Vorgegeben sind, werden aber immer anders angesteuert.

Updatetransaction: spätestens 45 sec nach einer BON Änderung muss die Änderung zur TSE via UpdateTrasaction


Ablauf: 1. Position -> Starttrasaction ..... Kassieren .... (dauert das nun länger als 45 sec Update machen) -> nach Wahl der Zahlungsart und vor dem Bondruck CloseTransaction

[noisy_master]

Guten Morgen!

Das mit Swissbit hört sich ja mal nicht sooo schlecht an. Gibt es eine Link wo man die bestellen könnte? Gibt zwar viel Beschreibung dazu auf deren Seite, aber 'nen "Shop" habe ich nicht gefunden.

Kannst du mir noch ein bisschen was zu den Parametern sagen?

Muss man das Update nach jeden 45 Sekunden aufrufen? Wenn ich das richtig verstanden habe muss auf den Bon die TransactionNumber und der signaturValue drauf, oder? Heisst das wenn eine Bestellung mehrere Stunden dauert müssen da zig signaturValues drauf?

Gibt es dazu irgendwo eine Beispielimplementierung?

[mfoerste]

Hi,
es gibt noch a-trust.at, die bieten eine Cloudlösung. Die wollen aber noch kurzfristig eine Offline Lösung herausbringen. Dort bekommst Du eine vorläufige dll mit Beschreibung zum Testen, wenn Du Dich dort registriert hast.

Zu den Parametern:

processType = Kassenbeleg-V1
processData = consists of three values separated by ^

- Transaktionstyp^Brutto-Steuerumsätze^Zahlungen
-- Transaktionstyp = Beleg
-- Brutto-Steuerumsätze
--- The following values separated by _
---- Allgemeiner Steuersatz (19%)
---- Ermäßigter Steuersatz (7%)
---- Durchnittsatz (§24(1)Nr.3 UStG) (10.7%)
---- Durchnittsatz (§24(1)Nr.1 UStG) (5.5%)
---- 0%
--- eg.: €10 Allgemeiner Steuersatz -> 10.00_0.00_0.00_0.00_0.00
-- Zahlungen: three values separated by : zB.: 10:Bar:EUR
--- Betrag:Zahlungsart:Währung
---- Betrag: value
---- Zahlungsart: Bar or Unbar
---- Währung: Currency
---- ordered: Bar, then Unbar, EUR then foreign currencies alphabetically

Beispiel:
process_type = "Kassenbeleg-V1";
process_data = "Beleg^10.00_0.00_0.00_0.00_0.00^10:Bar:EUR";

[Frickler]

Diese Programmierung habe wir uns schon bei der Ösi-Lösung nicht angetan, sondern statt dessen mit EFSTA (www.efsta.eu bzw. Doku unter public.efsta.net/efr) gearbeitet. Die machen auch eine Lösung für TSE (und für etliche andere Länder-Einzellösungen). Die Schnittstelle in der Kasse ist dabei weitgehend dieselbe.

[arnof]

EFSTA haben wir auch für die Ö Lösung, die wollen auch eine middleware anbieten.

Laut EPSON Veranstaltung kann es kein Zertifikat für eine reine Cloudlösung geben ....

Swissbit bekommste hier:

https://tse.gastro-mis.de/tse/produk...ierungspaket2/

[noisy_master]

Ah, super!

Jetzt haben die Jungs von gastro-mis auch wieder welche.

Noch 2 weitere Fragen: Wenn man eine laufende Transaktion hat, und die lieben Kunden nicht so schnell sind(also länger als 45 Sekunden brauchen sich den nächsten Artikel auszusuchen): Was schreibt man dann ins Update rein, sofern sich nichts geändert hat?
Muss man die Transaktion dann zumachen(und später eine neue aufmachen), oder kann man auch irgendein "Dummy" Kram reinschreiben?
wie läuft das mit einem Zeilenstorno? Ich glaube irgendwo mal gelesen zu haben Menge dann mit negativer Anzahl. richtig?

[DeddyH]

https://www.bundesfinanzministerium....cationFile&v=1

Zitat:

Zitat von 3.6.6.1 Art des Vorgangs „Kassenbeleg“

Über diese Daten werden der Gesamtumsatz abgesichert und eine Kassensturzfähigkeit mit den Daten der zertifizierten technischen Sicherheitseinrichtung gewährleistet. Hierfür entfallen die nach 45 Sekunden anfallenden Updates der abzusichernden Daten innerhalb der zertifizierten technischen Sicherheitseinrichtung.
Nähere Erläuterungen zur technischen Abbildung der Daten sind in der DSFinV-K
definiert.

Es ist ein heilloses Durcheinander.

[Frickler]

Zitat:

Zitat von noisy_master (Beitrag 1447513)

Ah, super!
wie läuft das mit einem Zeilenstorno? Ich glaube irgendwo mal gelesen zu haben Menge dann mit negativer Anzahl. richtig?

Das steht implizit in der DSFinV-K; kann man hier:

https://dfka.net/dfka-praktische-ums...ungsverordnung

herunterladen. Hier heißt es zum Zeilenstorno:

Zitat:

4.2.5 Vorgänge mit Negativpositionen
Kommen in einem Bon Positionen mit negativem Vorzeichen durch z. B. Warenrücknahmen, Rabatte oder Positionsstornos vor, so erfolgt eine Darstellung wie bei einem normalen Verkauf. Lediglich das Vorzeichen für das Feld MENGE ändert sich.

[noisy_master]

Habe ich es doch richtig in Erinnerung gehabt...Danke!

Zitat:

Zitat von DeddyH;1447515
[QUOTE=3.6.6.1 Art des Vorgangs „Kassenbeleg“

Über diese Daten werden der Gesamtumsatz abgesichert und eine Kassensturzfähigkeit mit den Daten der zertifizierten technischen Sicherheitseinrichtung gewährleistet. Hierfür entfallen die nach 45 Sekunden anfallenden Updates der abzusichernden Daten innerhalb der zertifizierten technischen Sicherheitseinrichtung.
Nähere Erläuterungen zur technischen Abbildung der Daten sind in der DSFinV-K
definiert.

Es ist ein heilloses Durcheinander.[/QUOTE]

Aber das ist doch nur für die Eingaben relevant, an denen kein "Kunde" beteiligt ist, oder?

[Frickler]

Zitat:

Zitat von noisy_master (Beitrag 1447533)

Aber das ist doch nur für die Eingaben relevant, an denen kein "Kunde" beteiligt ist, oder?

Das trifft lang anhaltende Vorgänge, wie sie in der Gastronomie auftreten: anstatt einen Beleg ewig offen halten zu müssen (und alle 45 Sekunden alle Bondaten erneut abzusichern), wird der Vorgang "Bestellung" (3.6.6.2) verwendet für alles bis auf die abschließende Ausgabe des Bons. Dafür nimmt man dann "Kassenbeleg" (3.6.6.1).

Also:
Tisch A: ein Bier -> Bestellung
Tisch A: ein Bier -> Bestellung
Tisch A: ein Bier -> Bestellung
Tisch A: Bezahlen -> Kassenbeleg

[noisy_master]

Zitat:

Zitat von Frickler (Beitrag 1447539)

Tisch A: ein Bier -> Bestellung
Tisch A: ein Bier -> Bestellung
Tisch A: ein Bier -> Bestellung
Tisch A: Bezahlen -> Kassenbeleg

Wobei dann aber die die Daten ALLER "Transaktionen" auf dem Bon auftauchen müssen, oder?

[Frickler]

Zitat:

Zitat von noisy_master (Beitrag 1447573)

Zitat:

Zitat von Frickler (Beitrag 1447539)

Tisch A: ein Bier -> Bestellung
Tisch A: ein Bier -> Bestellung
Tisch A: ein Bier -> Bestellung
Tisch A: Bezahlen -> Kassenbeleg

Wobei dann aber die die Daten ALLER "Transaktionen" auf dem Bon auftauchen müssen, oder?

Davon gehe ich sehr stark aus.

Wichtig auch: in solchen Fällen muss es nach DSFinV-K eine sogenannte "Geschäftsvorfall-ID" geben, anhand der die Bestellungen und der Beleg einander zugeordnet werden können.

[Madjid]

[QUOTE=mfoerste;1447096]Hi,
es gibt noch a-trust.at, die bieten eine Cloudlösung. Die wollen aber noch kurzfristig eine Offline Lösung herausbringen. Dort bekommst Du eine vorläufige dll mit Beschreibung zum Testen, wenn Du Dich dort registriert hast.


Hallo
auf der Seite a-trust.at habe ich keine dll gefunden, außerdem wurde bei der API-Unterstützung folgende Sprachen genannt

C/C++, Java, .Net, COM und VB6 bis Cobol.

Kennt jemand eine Implementierung der TSE unter Delphi?

.

[Neumann]

Eine Com-dll kann man relativ einfach in Delphi verwenden (ActiveX). Was sagt Atrust über die Preise?

[Madjid]

Hallo Ralf,

ich habe bei Trust.de keine Preise gefunden, allerdigs haben sie am 06.11.2019 eine Infoveranstaltung in Düsseldorf.
ich werde versuchen teilzunehmen und etwas Information sammeln.

mein Problem ist, das ich die Kommunikation mit TSE noch nicht kenne, da ich noch keine gesehen habe,

funktioniert sie seriell?

[jaenicke]

Zitat:

Zitat von Madjid (Beitrag 1449985)

mein Problem ist, das ich die Kommunikation mit TSE noch nicht kenne, da ich noch keine gesehen habe,

funktioniert sie seriell?

Bisher kenne ich nur USB und Netzwerk als Kommunikationsschnittstellen.

Zitat:

Zitat von Frickler (Beitrag 1447825)

Zitat:

Zitat von noisy_master (Beitrag 1447573)

Wobei dann aber die die Daten ALLER "Transaktionen" auf dem Bon auftauchen müssen, oder?

Davon gehe ich sehr stark aus.

Das ist in keiner Dokumentation, die wir kennen, so erwähnt. Wir gehen aktuell davon aus, dass das nicht der Fall ist.

[Frickler]

Zitat:

Zitat von jaenicke (Beitrag 1449991)

Zitat:

Zitat von Frickler (Beitrag 1447825)

Zitat:

Zitat von noisy_master (Beitrag 1447573)

Wobei dann aber die die Daten ALLER "Transaktionen" auf dem Bon auftauchen müssen, oder?

Davon gehe ich sehr stark aus.

Das ist in keiner Dokumentation, die wir kennen, so erwähnt. Wir gehen aktuell davon aus, dass das nicht der Fall ist.

Vielleicht habe ich mich missverständlich ausgedrückt, aber ich gehe davon aus, dass alle Positionen aller Bestellungen am Ende auf dem Bon auftauchen müssen.

[Incocnito]

Zitat:

Zitat von Frickler (Beitrag 1450007)

Zitat:

Zitat von jaenicke (Beitrag 1449991)

Zitat:

Zitat von Frickler (Beitrag 1447825)

Zitat:

Zitat von noisy_master (Beitrag 1447573)

Wobei dann aber die die Daten ALLER "Transaktionen" auf dem Bon auftauchen müssen, oder?

Davon gehe ich sehr stark aus.

Das ist in keiner Dokumentation, die wir kennen, so erwähnt. Wir gehen aktuell davon aus, dass das nicht der Fall ist.

Vielleicht habe ich mich missverständlich ausgedrückt, aber ich gehe davon aus, dass alle Positionen aller Bestellungen am Ende auf dem Bon auftauchen müssen.

"Alle Positionen aller Bestellungen müssen auf irgendeinem Bon auftauchen!"? Also das einfach "nur" alles auch tatsächlich dokumentiert wird, oder muss es einen Abschlussbon geben, auf dem alles drauf ist.
Wäre das dann nicht ein Tagesabschluss? ... Die Verwirrung wird größer! :shock:

[jaenicke]

Zitat:

Zitat von Frickler (Beitrag 1450007)

Vielleicht habe ich mich missverständlich ausgedrückt, aber ich gehe davon aus, dass alle Positionen aller Bestellungen am Ende auf dem Bon auftauchen müssen.

Das ist klar, ja. Die Transaktionsdaten nicht, aber die Positionen der Rechnung natürlich schon.

[hhcm]

Zitat:

Zitat von Madjid (Beitrag 1447096)

Kennt jemand eine Implementierung der TSE unter Delphi?

Bei A-Trust muss man sich als Partner registrieren um an die Entwickler Doku bzw. die DLL zu kommen.
Die Implementation musst du selbst machen.

[wjjw]

Zitat:

Zitat von hhcm (Beitrag 1450199)

Zitat:

Zitat von Madjid (Beitrag 1447096)

Kennt jemand eine Implementierung der TSE unter Delphi?

Bei A-Trust muss man sich als Partner registrieren um an die Entwickler Doku bzw. die DLL zu kommen.
Die Implementation musst du selbst machen.

Wir benutzen auch A-Trust Services.
Jedoch verwenden wir für die lokale Ansteuerung zur TSE via USB-Stick das APDU Interface bzw. Webservices für die mobile Lösungen.

[hhcm]

Welches ADPU Interface? Mir ist nur eins für die RKSV bekannt.

[noisy_master]

Ich weiss: eigentlich ist dies kein spezielles Forum für das Verständnis rund um die DSFinV, aber da hier so viele "Auskenner" sind mag ich doch noch ein paar Fragen loswerden:

Zitat:

aus DSFinV :"Für alle Transaktionstypen gilt, dass processType und processData für die Start-Transaction-Operation immer leer sind. StartTransaction wird unmittelbar mit Beginn eines Vorgangs an der Kasse aufgerufen. Die UpdateTransaction-Operation wird nicht verwendet. Die folgende Beschreibung bezieht sich ausschließlich auf die FinishTransaction-Operation."

soll das heissen, dass man StartTransaction IMMER ohne processType und ProcessData aufrufen soll? Wenn ja, wozu dann die Parameter? Und Update soll man auch nicht benutzen?

Je mehr ich lese, desto verwirrter werde ich: Die DSFinV definiert ja - wenn ich das richtig verstanden habe - das Format, in dem die Kollegen vom FA die Auswertung der Kasse haben möchten.
Im Anhang G sprechen die die DFKA-Taxonomie an. Was hat das denn jetzt damit zu tun, bzw wozu ist die denn jetzt wieder gut?(verstehe ich nicht, weil in der DFKA ja irgendwas mit JSON beschrieben ist, die DSFinV aber doch einen Satz von .csv Dateien haben möchte)
Ausserdem finde ich die die angesprochene Datei Anhang_G_Uebersicht.xlsx nirgendwo...oder kann ich nur einfach nicht richtig gucken?

Nun die nächste Frage: im DSFinV sprechen die von Geschäftsvorfall. Dieser kommt aber nur in den .csv Dateien vor und nicht irgendwo in den Transaktionen. Das würde für mich heissen, dass die .cvs Dateien aus der Kasse und nicht aus dem Export der TSE erzeugt werden, oder habe ich da einen Denkfehler?
Wenn das so ist: wozu ist dann der Export aus der TSE da? Geht der auch in die csv Dateien ein? Wenn ja, wie? Wenn nicht: wollen die Kollegen vom FA dann einfach nur der .tar Ball haben?


ich weiss : viele Fragen, und wenn ich damit zu sehr auf die Nerven gehe stelle ich keine weiteren mehr, aber das Netz gibt dazu leider auch nichts brauchbares her...oder doch? Wenn ja: wo?

[hhcm]

Zitat:

Zitat von noisy_master (Beitrag 1450247)

soll das heissen, dass man StartTransaction IMMER ohne processType und ProcessData aufrufen soll? Wenn ja, wozu dann die Parameter? Und Update soll man auch nicht benutzen?

Bei lang anhaltenden Bestellvorgängen musst du processType und processData angeben. So verstehe ich zumindest die Seite 108 des DSFinV-K V2 PDF.

Zitat:

Zitat von noisy_master (Beitrag 1450247)

Je mehr ich lese, desto verwirrter werde ich: Die DSFinV definiert ja - wenn ich das richtig verstanden habe - das Format, in dem die Kollegen vom FA die Auswertung der Kasse haben möchten.
Im Anhang G sprechen die die DFKA-Taxonomie an. Was hat das denn jetzt damit zu tun, bzw wozu ist die denn jetzt wieder gut?(verstehe ich nicht, weil in der DFKA ja irgendwas mit JSON beschrieben ist, die DSFinV aber doch einen Satz von .csv Dateien haben möchte)

DFKA-Taxonomie soll wohl der Standard sein, welcher nachher über ein PHP Script in das benötigte Format umgewandelt werden kann. Ich finde das genau so sinnfrei, daher erstellen wir die benötigten csv Dateien selbst.

Zitat:

Zitat von noisy_master (Beitrag 1450247)

Ausserdem finde ich die die angesprochene Datei Anhang_G_Uebersicht.xlsx nirgendwo...oder kann ich nur einfach nicht richtig gucken?

Da ist ein ZIP File mit allen Anhängen
Ich würde da allerdings nicht reinsehen. Danach bist du komplett verwirrt.

Zitat:

Zitat von noisy_master (Beitrag 1450247)

Nun die nächste Frage: im DSFinV sprechen die von Geschäftsvorfall. Dieser kommt aber nur in den .csv Dateien vor und nicht irgendwo in den Transaktionen. Das würde für mich heissen, dass die .cvs Dateien aus der Kasse und nicht aus dem Export der TSE erzeugt werden, oder habe ich da einen Denkfehler?
Wenn das so ist: wozu ist dann der Export aus der TSE da? Geht der auch in die csv Dateien ein? Wenn ja, wie? Wenn nicht: wollen die Kollegen vom FA dann einfach nur der .tar Ball haben?

Du brauchst beides. Die Gesamtwerte der Transaktion (X € mit X€ 19% MwST etc.) wird bei finishTransaction an die TSE übergeben. In dem Kassenexport muss die Transaktionsnummer deinem Bon zugeordnet werden können. Die Datei transactions_tse.csv beinhalten dann Start Ende Vorgangsart etc. Und eben die Verknüpfung zum Bon.

Es wird in der EU viel reguliert, aber jedes Land darf unnötige Kassenrichtlinien entwerfen. EINE würde reichen.

[noisy_master]

Fangen wir doch mal von hinten an:

Zitat:

Zitat von hhcm (Beitrag 1450251)

Du brauchst beides. Die Gesamtwerte der Transaktion (X € mit X€ 19% MwST etc.) wird bei finishTransaction an die TSE übergeben. In dem Kassenexport muss die Transaktionsnummer deinem Bon zugeordnet werden können. Die Datei transactions_tse.csv beinhalten dann Start Ende Vorgangsart etc. Und eben die Verknüpfung zum Bon.

Wenn ich nun die einzelnen Transaktionsnummern, Signaturen und Zeiten gleich in der Datenbank mitspeichere(und den restlichen Kram der ggf noch nötig ist) kann ich daraus die csv Dateien generieren, richtig? Dann ist der tar Ball nur noch dreingabe und ich brauche damit nicht wirklich etwas machen, oder?

Zitat:

Zitat von hhcm (Beitrag 1450251)

Da ist ein ZIP File mit allen Anhängen
Ich würde da allerdings nicht reinsehen. Danach bist du komplett verwirrt.

Danke für den Hinweis... war also wirklich zu blind ;-)

Zitat:

Zitat von hhcm (Beitrag 1450251)

Bei lang anhaltenden Bestellvorgängen musst du processType und processData angeben. So verstehe ich zumindest die Seite 108 des DSFinV-K V2 PDF.

Wenn man den Diagrammen in der DSFin glauben darf soll das mit dem "umgebenden Kassenbeleg" ja ausser beim Durchbedienen wohl immer so sein. Was wäre dann eigentlich ProcessData beim StartTransaction mit ProcessType Kassenbeleg?
Und dann noch eine Frage zu Seite 108: Hätte man dann bei Bestellung Start/Finish nicht jedesmal eine neue Transaktionsnummer?(muss die mit auf den Bon?) und wo würde man denn dann die ProcessData reinpacken? ins Start oder ins Finish?

Danke schon mal wieder im voraus!

[hhcm]

[QUOTE=noisy_master;1450259]
Wenn ich nun die einzelnen Transaktionsnummern, Signaturen und Zeiten gleich in der Datenbank mitspeichere(und den restlichen Kram der ggf noch nötig ist) kann ich daraus die csv Dateien generieren, richtig? Dann ist der tar Ball nur noch dreingabe und ich brauche damit nicht wirklich etwas machen, oder?
[QUOTE]

So machen wir das. Beim abschliessen eines Bons wird die Transaktionsnummer und der andere Rummel mit zum Bon gespeichert. Wenn dann mal ein Export gemacht wird - CSV Erstellen - Tar ziehen fertig. (So die Theorie)

Zitat:

Zitat von noisy_master (Beitrag 1450259)

Wenn man den Diagrammen in der DSFin glauben darf soll das mit dem "umgebenden Kassenbeleg" ja ausser beim Durchbedienen wohl immer so sein. Was wäre dann eigentlich ProcessData beim StartTransaction mit ProcessType Kassenbeleg?
Und dann noch eine Frage zu Seite 108: Hätte man dann bei Bestellung Start/Finish nicht jedesmal eine neue Transaktionsnummer?(muss die mit auf den Bon?) und wo würde man denn dann die ProcessData reinpacken? ins Start oder ins Finish?

Da muss ich derzeit noch passen. Alles was uns im moment unklar ist, stellen wir zur Seite.

[DeddyH]

Da ich ja das Zitat eingebracht habe: nach erneutem mehrmaligen Lesen kann es nur so sein, dass der zitierte Text nur für Kassenbelege gilt, da es auch nur dort Transaktionstypen gibt. Heißt, beim Kassenbeleg (und nur dort) werden Processtype und ProcessData leer gelassen und erst beim Abschließen der Transaktion belegt. UpdateTransaction wird bei Kassenbelegen nicht benutzt. Bei Bestellungen oder sonstigen Vorgängen gilt dies nicht. Zumindest ich habe das jetzt so wie gerade beschrieben umgesetzt, zumindest solange, bis mir jemand zweifelsfrei (*LOL*) nachweisen kann, dass ich den Text fehlinterpretiert habe.

[noisy_master]

Zitat:

Zitat von DeddyH (Beitrag 1450270)

Da ich ja das Zitat eingebracht habe: nach erneutem mehrmaligen Lesen kann es nur so sein, dass der zitierte Text nur für Kassenbelege gilt, da es auch nur dort Transaktionstypen gibt. Heißt, beim Kassenbeleg (und nur dort) werden Processtype und ProcessData leer gelassen und erst beim Abschließen der Transaktion belegt. UpdateTransaction wird bei Kassenbelegen nicht benutzt. Bei Bestellungen oder sonstigen Vorgängen gilt dies nicht. Zumindest ich habe das jetzt so wie gerade beschrieben umgesetzt, zumindest solange, bis mir jemand zweifelsfrei (*LOL*) nachweisen kann, dass ich den Text fehlinterpretiert habe.

Na das hört sich ja mal gut an, aber: wenn man den Darstellungen folgt müsste man beim Transaktionstyp Kassenbeleg zumindest beim StartTransaction doch zumindest den ProzessTyp Kassenbeleg angeben, da ja sonst nicht klar ist, dass es "Kassenbeleg" ist.

Hast du dann auch noch eine Antwort zu meiner 2. Frage:

Zitat:

Und dann noch eine Frage zu Seite 108: Hätte man dann bei Bestellung Start/Finish nicht jedesmal eine neue Transaktionsnummer?(muss die mit auf den Bon?) und wo würde man denn dann die ProcessData reinpacken? ins Start oder ins Finish?

?

Und: Was ist mit Bestellung, sofern man die Transaktion offen hält mit dem Update, sofern bis dahin keine neuen Daten angefallen sind? lässt man dann ProcessData einfach "leer"?

Danke für die vielen anregenden Kommentare und Hinweise....

[hhcm]

Es ist einfach nur Krank, dass Entwickler sagen müssen :"So hab ich das jetzt interpretiert und umgesetzt."
Bei der RKSV gab es wenigstens ein Test-Tool und viel mehr Informationen für Entwickler. Den BSI Krempel, also die Vorgabe, versteht auch nur das BSI selbst.

Ich warte jetzt schon auf die ersten Anrufe der Kunden. HILFE ich habe eine Kassennachschau und der Export ist falsch.
In Österreich hatten wir das auch. Der Export konnte von der Finanz nicht gelesen werden. Lag daran, dass eine .json Datei erwartet wurde - wir aber "NUR" eine .txt geliefert hatten. (Was steht da wohl drin?) Einfach nur Krank.

[Frickler]

Zitat:

Zitat von hhcm (Beitrag 1450277)

Es ist einfach nur Krank, dass Entwickler sagen müssen :"So hab ich das jetzt interpretiert und umgesetzt."
Bei der RKSV gab es wenigstens ein Test-Tool und viel mehr Informationen für Entwickler. Den BSI Krempel, also die Vorgabe, versteht auch nur das BSI selbst.

Der deutsche Kassenverband DFKA bietet Schulungen zum Thema, auch für Nichtmitglieder.

Wir arbeiten bei der Anbindung der TSE mit einer Middleware, weil es jetzt schon stark danach aussieht, dass jeder Anbieter einer TSE sein eigenes (natürlich inkompatibles) API haben wird. Die Middleware erzeugt auch den DSFinV-K Export, so dass wir die Kassensoftware nicht völlig verbiegen müssen.

Das wird sowieso noch lustig mit den TSEs, weil es bis Ende 2019 keine vollständig zertifizierte TSE geben wird. Statt dessen gibt es eine sog. vorläufige Zertifizierung. "Vorläufig zertifizierte" TSEs müssen jedes Jahr ausgetauscht werden, weil die Zertifizierung nur 1 Jahr gilt.

[hhcm]

Die angesprochene Middleware kenn ich. Das dürfte die gleiche wie bei der RKSV sein.

Ich will hier echt niemandem auf die Knochen treten, aber wozu eine Middleware, wenn doch die Gesetzeslage eindeutig ist.
Das Finanzamt ist ausschlaggebend (steht auch so in der DSFinV-K)

Zitat:

Sofern der Standard „DFKA-Taxonomie Kassendaten“ (Datensatzbeschreibung im json-Format, der u. a. vom Deutschen Fachverband für Kassen- und Abrechnungssystem-technik e.V. entwickelt wurde) zur Übermittlung der Kassendaten an die Finanzbuchhal-tung genutzt wird, ist eine Konvertierung der Daten für Zwecke der Außenprüfung oder der Kassen-Nachschau zwingend erforderlich (vom originären json-Format in csv-Dateien mit beschreibender index.xml; vgl. Anhang G).

Egal wer WAS - WO und WIE entwickelt hat, es muss wieder umgewandelt werden um konform zu sein.:wall:

Frage: Was mache ich mit dem Konverter wenn ich die KassSichV umsetze nach DFKA (json)?
Soll jeder meiner Kunden einen Webserver aufsetzen oder PHP installieren, damit die Taxonomie in das gewünschte Format gebracht werden kann?

Zitat:

Das wird sowieso noch lustig mit den TSEs, weil es bis Ende 2019 keine vollständig zertifizierte TSE geben wird.

Was ist daran so lustig? Es gibt bis 30.09.2020 eine Nichtbeanstandungsregelung für TSE. Also ist das erstmal hinfällig.

[noisy_master]

Zitat:

Zitat von Frickler (Beitrag 1450284)

Der deutsche Kassenverband DFKA bietet Schulungen zum Thema, auch für Nichtmitglieder.

Ja, das ist schön, aber auch schön teuer ~900 Taler....

Und ich möchte eigentlich keine Schulung haben müssen, sondern eine eineindeutige Beschreibung, wie etwas umzusetzen ist!

Zitat:

Zitat von Frickler (Beitrag 1450284)

"Vorläufig zertifizierte" TSEs müssen jedes Jahr ausgetauscht werden, weil die Zertifizierung nur 1 Jahr gilt.

Das würde ja nicht stören, sofern die Schnittstelle sich nicht ändert!

[noisy_master]

Zitat:

Zitat von hhcm (Beitrag 1450286)

wenn doch die Gesetzeslage eindeutig ist.

Gesetzeslage mag eindeutig sein, aber die Umsetzuung garantiert nicht....

Zitat:

Zitat von hhcm (Beitrag 1450286)

Was ist daran so lustig? Es gibt bis 30.09.2020 eine Nichtbeanstandungsregelung für TSE. Also ist das erstmal hinfällig.

Echt? Woher hast du das? Meine bisherigen Infos(zumindest alles was ich bisher gefunden habe) deuten darauf hin, dass es eine NichtBeanstandungsregel geben wird. Aber was offizielles?

[hhcm]

Zitat:

Echt? Woher hast du das? Meine bisherigen Infos(zumindest alles was ich bisher gefunden habe) deuten darauf hin, dass es eine NichtBeanstandungsregel geben wird. Aber was offizielles?

z.b von hier https://www.essen.ihk24.de/recht_und...gleung/4539256

PS

Zitat:

Quelle: DIHK Berlin, 26.09.2019
Anmerkung:
Zeitnah soll dazu ein BMF-Schreiben veröffentlicht werden!

Einfach nur lächerlich

[noisy_master]

Ja, aber es gibt halt noch kein Schreiben, und solange ist es nicht offiziell!

[noisy_master]

Na gut, wie dem auch sei...scheint ja doch in Summe etwas weniger kritisch zu werden als erwartet.

Dann mal wieder zurück zum Technischen: hat irgendwer Antworten für mich auf die Fragen aus #29?

[arnof]

Zitat:

Zitat von noisy_master (Beitrag 1450287)

Zitat:

Zitat von Frickler (Beitrag 1450284)

Der deutsche Kassenverband DFKA bietet Schulungen zum Thema, auch für Nichtmitglieder.

Ja, das ist schön, aber auch schön teuer ~900 Taler....

Und ich möchte eigentlich keine Schulung haben müssen, sondern eine eineindeutige Beschreibung, wie etwas umzusetzen ist!

Zitat:

Zitat von Frickler (Beitrag 1450284)

"Vorläufig zertifizierte" TSEs müssen jedes Jahr ausgetauscht werden, weil die Zertifizierung nur 1 Jahr gilt.

Das würde ja nicht stören, sofern die Schnittstelle sich nicht ändert!

Von den Schulungsgebern kann man halten was man so denkt (meine Meinung); Ich sehe diese teils sehr kritisch, da ich auch hier teil schon Kontakte der 3'ten Art hatte; Support pro Quartal 2.500 EUR +x ; neue Firmaware; wieder kaufen ... (von anderen kam die neue Version einfach per Post ....); versprochene Gutschriften gab es nie ...

TSE ist ein schönes Geschäftsmodell ....

[Frickler]

Zitat:

Zitat von noisy_master (Beitrag 1450292)

Ja, aber es gibt halt noch kein Schreiben, und solange ist es nicht offiziell!

Genau so ist es. Was aber durchgesickert ist, ist, dass die "Nichtaufgriffsregelung" nur für die Kassenanwender gilt, nicht für die Kassenanbieter! Die dürfen Punkt 1.1.2020 keine Kassen mehr in Verkehr bringen, die keine Sicherheitseinrichtung haben. Und jede vorhandene Kasse muss ab dem 1.1.2020 den DSFinV-K Export können, und zwar unabhängig davon, ob eine TSE angeschlossen ist oder nicht.

[jaenicke]

Zitat:

Zitat von Frickler (Beitrag 1450366)

Die dürfen Punkt 1.1.2020 keine Kassen mehr in Verkehr bringen, die keine Sicherheitseinrichtung haben.

Die Frage ist ja was das genau heißt. Das kann heißen, dass man die Schnittstelle haben muss, das kann auch heißen, dass man eine Lösung nutzen muss, auch wenn sie nicht zertifiziert ist und es könnte theoretisch auch heißen, dass die Kasse eine zertifizierte TSE-Lösung mitgeliefert haben muss.