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:
- obchodný dokument k odberateľovi,
- 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:
| Objekt | Minimálne väzby |
|---|---|
| faktúra | interné ID, číslo dokladu, UUID obchodného dokumentu, hash XML, strany, čas odoslania |
| SK TDD | vlastné UUID, UUID reportovanej faktúry, funkcia Submit/Resubmit/Disregard, rola reportéra, verzia špecifikácie |
| transport | transmission ID, odosielajúci a prijímajúci endpoint, čas a výsledok |
| potvrdenie MLS | väzba na faktúru alebo TDD, pozitívny/negatívny výsledok, validačné chyby, čas |
| oprava | väzba na predchádzajúci TDD a dôvod Resubmit alebo Disregard |
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ú:
| Element | Povinná hodnota |
|---|---|
cbc:CustomizationID | urn:peppol:taxdata:sk-1 |
cbc:ProfileID | urn:peppol:taxreporting |
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:
| Funkcia | Použitie |
|---|---|
| Submit | prvé podanie daňových údajov k faktúre |
| Resubmit | nové TDD nahrádza skôr prijaté TDD |
| Disregard | skôr prijaté TDD sa má prestať považovať za aktuálne |
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:
| Faktúra C2 → C3 | TDD C2 → C5 | Interný výsledok |
|---|---|---|
| úspech | úspech | doručené a reportované |
| chyba | úspech | nedoručené, ale už reportované; treba postup podľa architektúry |
| úspech | chyba | doručené, ale nereportované; vyžaduje nápravu TDD |
| chyba | chyba | nedoručené a nereportované |
| timeout | úspech alebo chyba | nejasný transportný výsledok; nesmie sa slepo vytvoriť duplikát |
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:
- XSD a namespace,
- povinné identifikátory špecifikácie a procesu,
- sémantický model a kardinality,
- normatívne číselníky vrátane slovenských daňových kategórií,
- Schematron pravidlá,
- choreografické pravidlá a koreláciu s faktúrou,
- 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.