SK TDD pre ERP a CPDS: architektúra, dokumenty, stavy a testy

Krátka odpoveď

SK TDD je samostatný štruktúrovaný daňový dátový dokument, ktorý sa pri slovenskom modeli vytvára z údajov o vystavenej alebo prijatej faktúre a odosiela daňovej autorite. Nie je to PDF, vizualizácia ani druhý názov pre UBL faktúru.

ERP a poskytovateľ musia viesť dva korelované, ale samostatné toky:

1. obchodný dokument k odberateľovi,
2. daňový dátový dokument k daňovej autorite.

Každý tok má vlastný identifikátor, validáciu, potvrdenie a chybový stav.

Architektúra C1 až C6

eFaktúra:
C1 dodávateľ → C2 odosielajúci AP → C3 prijímajúci AP → C4 odberateľ

SK TDD za vystavenú faktúru:
C2 odosielajúci AP → C5 AP daňovej autority → C6 daňová autorita

SK TDD za prijatú faktúru:
C3 prijímajúci AP → C5 AP daňovej autority → C6 daňová autorita

Slovenská referenčná architektúra v1.2 používa decentralizovaný 5/6-rohový model. C2 a C3 sú funkčné roly poskytovateľov na oboch stranách faktúry. C5 je Peppol koncový bod a validačná vrstva daňovej autority; C6 predstavuje autoritu, ktorá daňové údaje konsoliduje.

Z toho vyplýva dôležitý návrhový princíp: k faktúre nemá patriť jeden spoločný stav sent. Potrebujete najmenej stav obchodného doručenia a stav daňového reportu.

Minimálny dátový model

Pre každú faktúru evidujte oddelene:

UUID faktúry a UUID TDD nie sú zameniteľné. TDD musí vedieť jednoznačne odkázať na reportovaný obchodný dokument.

Štruktúra SK TDD

SK TDD 1.0.0 má vlastný koreňový namespace urn:peppol:schema:sk-taxdata:1.0 a znovu používa spoločné komponenty UBL 2.1. Základné identifikátory sú:

Dokument obsahuje metadáta TDD, daňovú autoritu, reportujúcu a prijímajúcu stranu, prípadného zástupcu a jeden alebo viac blokov reportovaných transakcií podľa povoleného scenára.

Submit, Resubmit a Disregard

Funkcia TDD je nezávislá od typu obchodnej faktúry:

Nevytvárajte Resubmit pri obyčajnom sieťovom retry, ak neviete, či pôvodný dokument C5 prijal. Najprv vyhodnoťte potvrdenie, timeout a korelačné identifikátory podľa choreografie. Technické opakovanie prenosu a nové logické podanie nie sú tá istá operácia.

Paralelné toky a ich výsledky

Referenčná architektúra pripúšťa súbežné odoslanie faktúry C3 a TDD C5. Integračná vrstva preto musí zvládnuť všetky kombinácie:

Negatívne MLS pri faktúre môže viesť aj k potrebe Resubmit alebo Disregard na reportingovej vetve. Presné správanie implementujte podľa aktuálnej choreografie a nie iba podľa textu chybovej správy v dashboarde.

Kto má TDD vytvoriť

Podľa referenčnej architektúry:

• C2 musí vedieť vytvoriť SK TDD z odosielanej faktúry,
• C3 musí vedieť vytvoriť SK TDD z prijatej faktúry,
• C2 alebo C3 môže podľa svojho rozhrania prijať TDD pripravený koncovým systémom a doplniť požadované údaje,
• poskytovateľ má používateľovi sprístupniť faktúry, TDD a súvisiace potvrdenia v rozsahu architektúry a zmluvy.

Zákazník preto nemusí automaticky generovať SK TDD priamo v ERP. Musí však vedieť, či ho vytvára ERP, middleware alebo poskytovateľ, ako sa kontroluje správnosť mapovania a kto rieši odmietnutie C5.

Validácia

SK TDD nie je validný iba preto, že je to dobre formované XML. Kontrolujte:

1. XSD a namespace,
2. povinné identifikátory špecifikácie a procesu,
3. sémantický model a kardinality,
4. normatívne číselníky vrátane slovenských daňových kategórií,
5. Schematron pravidlá,
6. choreografické pravidlá a koreláciu s faktúrou,
7. aktuálnu verziu artefaktov používanú testbedom a C5.

Release notes označujú SK TDD 1.0.0 ako finálne prvé vydanie z 14. apríla 2026. Údaj PDK 1.4.4-preview, ktorý sa zobrazuje na vygenerovanom dokumentačnom webe, označuje nástrojový balík, nie novú verziu SK TDD.

Compliance a outsourcing

OpenPeppol compliance stránka posudzuje odosielajúcu aj prijímajúcu stranu. Technické roly možno outsourcovať poskytovateľovi, nie však automaticky právnu zodpovednosť reportujúcej strany.

Zmluva a prevádzková dokumentácia majú presne určiť:

• z akého dokumentu sa TDD vytvára,
• kto zodpovedá za mapovanie,
• ktorá strana dopĺňa UUID a identifikátory,
• kde sa zobrazí negatívne MLS,
• kto a v akej lehote vykoná Resubmit alebo Disregard,
• čo si firma môže exportovať pri audite alebo zmene poskytovateľa.

Testovací plán pre ERP a poskytovateľa

Testujte iba v určenom testovacom prostredí so syntetickými údajmi.

Základné dokumenty

• bežná faktúra s TDD Submit na strane C2,
• prijatá faktúra s TDD Submit na strane C3,
• faktúra s viacerými sadzbami alebo kategóriami DPH,
• faktúra k prijatej platbe,
• opravný doklad s referenciou,
• podporované self-billing scenáre.

Opravy a korelácia

• Resubmit, ktorý nahrádza konkrétne skoršie TDD,
• Disregard po nedoručení obchodnej faktúry,
• opakovaný transport toho istého TDD bez vytvorenia druhého logického reportu,
• nesprávne UUID faktúry,
• TDD bez predchádzajúceho Submit.

Chybové stavy

• faktúra prijatá C3, TDD odmietnutý C5,
• TDD prijatý C5, faktúra nedoručená C4,
• negatívne MLS z validačnej chyby,
• timeout MLS z C3,
• timeout MLS z C5,
• dočasná nedostupnosť interného úložiska alebo fronty,
• obnovenie spracovania bez duplikácie.

Audit

• export pôvodnej faktúry, TDD a oboch potvrdení,
• dohľadanie použitej verzie pravidiel,
• dôkaz oddelenia viacerých zastupovaných firiem,
• reprodukcia stavu po zmene poskytovateľa.

Čo zatiaľ nemožno tvrdiť iba z dokumentácie

Finálna špecifikácia, referenčná architektúra a dostupný testbed dokazujú, že pravidlá a testovacie artefakty existujú. Samy osebe nedokazujú, že konkrétny C2, C3, C5 a C6 tok je v produkcii aktívny pre všetky scenáre.

Aktuálne FAQ Finančnej správy pri dobrovoľnom roku 2026 naďalej viaže spustenie reportovania na pripravenosť C2 a C5 a uvádza plán Q3/2026. Produkčnú pripravenosť preto preukazujte aktuálnym potvrdením poskytovateľa a výsledkom konkrétneho produkčného rozhrania, nie iba absolvovaným testbedom.

Kontrolný zoznam

• Vieme, kto vytvára SK TDD na C2 aj C3 strane.
• Ukladáme samostatné UUID faktúry, TDD a prenosu.
• Rozlišujeme MLS pre faktúru a MLS pre TDD.
• Implementujeme Submit, Resubmit a Disregard ako logické funkcie, nie obyčajný retry.
• Poznáme verziu SK TDD aj validačných artefaktov.
• Stav „doručené“ neprepisuje stav „reportované“.
• Máme testy pre čiastočný úspech oboch paralelných vetiev.
• Firma vie exportovať faktúru, TDD a potvrdenia.

Pokračujte cez slovníkové heslo SK TDD, slovenský testbed a rozdiel medzi EUSR/TSR a SK TDD.