TSE nach 146a AO Schnittstelle

[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.