# A titkár.ai számlázó program felhasználói dokumentációja > **Számlázó program:** „titkár.ai” (https://titkar.ai) > **Fejlesztő és üzemeltető:** BITNEX GROUP Kft. > **Hatályos:** 2026. augusztus 18. · **Verzió:** 1.8 Jelen dokumentum a számla és a nyugta adóigazgatási azonosításáról, valamint az elektronikus formában megőrzött számlák adóhatósági ellenőrzéséről szóló **23/2014. (VI. 30.) NGM rendelet 10. §-a** szerinti **magyar nyelvű felhasználói dokumentáció** a **titkar.ai** számlázó programhoz. A rendelet 10. §-a a számlázó program fejlesztőjétől megköveteli, hogy a programhoz magyar nyelvű felhasználói dokumentációt biztosítson, amely a program működését és használatát írja le; a dokumentációt az adózónak – tehát neked, a program használójának – adóhatósági ellenőrzéskor be kell tudnia mutatnia. A dokumentum ezért **nem marketinganyag**: minden állítása a program tényleges működését írja le, és ahol a program valamit nem tud, azt kimondottan, alternatívával együtt jelöli. A dokumentum a titkar.ai **saját, NAV-közvetlen számlázására** vonatkozik: arra a működésre, amelyben a számlát maga a titkar.ai állítja ki, és közvetlenül a NAV Online Számla rendszerébe szolgáltat adatot. A **2026. augusztus 8. előtt**, külső számlázó programon (szamlazz.hu, Billingo) keresztül kiállított számlákra ez a dokumentum **nem alkalmazandó** – az elhatárolást az 1. fejezet tartalmazza. A dokumentum végén **„Tisztázandó tételek az élesítés előtt”** címmel munkajellegű szakasz áll: ez a program jelenlegi állapotából fakadó, még eldöntendő kérdéseket gyűjti egy helyre. A tételek a saját fejezetükben is szerepelnek, `[TISZTÁZANDÓ · T-nn]` jelöléssel — a v1.7-es kiadással **minden tétel lezárult**, a 29. fejezet a lezárások nyilvántartásaként marad meg. ## Tartalom 1. Jogalap és a dokumentum hatálya 2. A szoftver neve és azonosítója 3. A működési modell: online szolgáltatás (SaaS) 4. A kezelt bizonylattípusok 5. Hozzáférés, felhasználók, jogosultságok 6. Üzembe helyezés: a NAV technikai felhasználó és a kulcsok 7. A számlakiállítás folyamata és állapotai 8. Sorszámozás 9. A számla adattartalma és kiállítása 10. Díjbekérő (proforma) 11. Nyugta 12. Ismétlődő és tömeges kiállítás 13. Módosítás és érvénytelenítés 14. Áfa, kerekítés, deviza 15. Számlakép és kézbesítés 16. NAV-adatszolgáltatás (13/A. §) 17. Adóhatósági ellenőrzési adatszolgáltatás (11/A. §) 18. Hibakezelés és üzemzavar 19. Nyilvántartás, listák, riportok 20. Fizetettség és fizetési emlékeztetők 21. A nem számlázási célú funkciók elhatárolása 22. Az AI-asszisztens szerepe és korlátai 23. Csomagkorlátok mint működési korlát 24. Biztonsági korlátok és az audit-napló 25. Megőrzés és archiválás 26. Nem támogatott esetek 27. Verziókövetés 28. Támogatás, felelősség, kapcsolat 29. Tisztázandó tételek az élesítés előtt --- ## 1. Jogalap és a dokumentum hatálya ### 1.1 Miért készült ez a dokumentum A számla- és nyugtaadási kötelezettség kapcsán a 23/2014. (VI. 30.) NGM rendelet **10. §-a** előírja, hogy a számlázó programhoz a **fejlesztőnek magyar nyelvű felhasználói dokumentációt kell biztosítania**, amely a program működését és használatát írja le. A dokumentációt az adózónak (neked, mint a program használójának) ellenőrzéskor be kell tudnia mutatni. Ez a dokumentum ezt a kötelezettséget teljesíti a **titkar.ai** számlázó programra. Ez a dokumentum egyben a 10. § (1) bekezdése szerinti **tájékoztatás a program nevéről és azonosítójáról** is; a pontos adatokat a 2. fejezet tartalmazza. A dokumentum **eredetileg is magyar nyelven** készült, ezért a 10. § (6)–(7) bekezdése szerinti fordítási kötelezettség nem merül fel; a Szolgáltató belföldön nyilvántartásba vett adóalanyként gondoskodik arról, hogy folyamatosan rendelkezésre álljon. **A te kötelezettséged.** A 10. § (4) szerint a dokumentációt az adó megállapításához való jog elévüléséig meg kell őrizned, és adóhatósági ellenőrzéskor be kell mutatnod; a megőrzés elektronikus úton is teljesíthető. Ezért töltsd le ezt a dokumentumot abban a verzióban, amely a számláid kiállításának napján hatályos volt, és őrizd meg a bizonylataid mellett (27.5). A dokumentum verziózott letöltési pontja: **https://titkar.ai/szamlazo-dokumentacio/letoltes** (a hatályos változat; korábbi kiadás a `?verzio=` paraméterrel, pl. `?verzio=1.6` — lásd 27.5). A tudomásulvétel tényét a program a regisztrációkor időbélyeggel és a dokumentum akkori verziószámával rögzíti a fiókhoz. ### 1.2 Mire terjed ki A dokumentum arra az útra vonatkozik, amelyen a **számlát maga a titkar.ai állítja ki**, és közvetlenül a NAV Online Számla rendszerébe szolgáltat adatot – külső számlázó program közbeiktatása nélkül. A rendszer ezt az utat belül **saját számlázásnak** (`invoiceProvider = nav`) nevezi; a felületen „titkár.ai · saját számlázás” néven jelenik meg. **Ebben a dokumentumban végig a „saját (NAV-közvetlen) út” – röviden „saját út” – megnevezést használjuk erre.** A 2026. augusztus 8. előtti, szamlazz.hu-n vagy Billingón keresztüli működésre a **„korábbi, külső számlázós bizonylatok”** megnevezést használjuk. ### 1.3 Mire NEM terjed ki – a korábbi, külső számlázós bizonylatok 2026. augusztus 8. előtt a titkar.ai a számlát a felhasználó saját, külső számlázó-fiókján (szamlazz.hu, Billingo) keresztül is ki tudta állítani. **Ez a lehetőség megszűnt**; a program azóta kizárólag saját, NAV-közvetlen úton állít ki bizonylatot. | Bizonylat | Ki állította ki | Erre a dokumentumra tartozik | |---|---|---| | **2026. augusztus 8. előtt, szamlazz.hu-n vagy Billingón** | a külső számlázó, a te fiókodban | nem | | **titkár.ai · saját számlázás** | a titkar.ai, közvetlenül a NAV felé | **igen** | Ha a számlád a szamlazz.hu-n vagy a Billingón keresztül készült, akkor **jogilag az a program a számlázó program**, és a 10. § szerinti dokumentáció is annak a fejlesztőjét terheli. Az ő dokumentációjukat kell bemutatnod azokra a számlákra. Ez a dokumentum azokra nem érvényes. ### 1.4 A hatály bizonylatonként dől el Minden számlasoron eltároljuk, hogy **melyik úton keletkezett** – és a későbbi műveletek (PDF, sztornó, fizetés jelölése, NAV-státusz lekérdezése, valamint a 11/A. § szerinti adóhatósági ellenőrzési adatszolgáltatás) ezt nézik. Ennek a gyakorlati következménye: a korábbi, külső számlázón át kiállított számláid **visszamenőleg nem kerülnek ennek a dokumentumnak a hatálya alá**, és a sztornójuk is abban a rendszerben (vagy a NAV Online Számla felületén) intézhető, amelyben keletkeztek – a titkar.ai ezeket nyilvántartja és megjeleníti, de nem érvényteleníti és számlaképet sem állít elő hozzájuk. **A dokumentum időbeli hatálya: 2026. augusztus 8.** — a saját (NAV-közvetlen) számlázási út élesedésének, egyben a külső számlázós utak megszűnésének napja. E naptól minden, a titkar.ai-ban kiállított számlára ez a dokumentum az irányadó; a korábbi, külső számlázón kiállított bizonylatokra az akkori szolgáltató programja a számlázó program (1.3). ### 1.5 Egy dolog akkor is a titkar.ai-tól megy, ha nem ő állítja ki a számlát A titkar.ai a NAV felé küldött **minden** kérésben megnevezi magát a 2. fejezet szerinti szoftver-azonosító blokkal – akkor is, ha az adott számlát nem ő bocsátotta ki. Ez a helyzet a számlatörténet-behúzásnál, az adószám-ellenőrzésnél, a számlaadat-lekérdezésnél és az eÁFA (M2M) kéréseknél. Ezek **lekérdezések és bevallás-műveletek**, nem számlakibocsátás: attól, hogy a NAV-naplóban ott a `titkar.ai` név, a külső számlázón kiállított számla kibocsátója változatlanul a külső számlázó marad. ### 1.6 Az adóhatósági ellenőrzési adatszolgáltatás hatálya A rendelet **11/A. §-a** szerinti adóhatósági ellenőrzési adatszolgáltatást a program csak azokra a számlákra adja ki, amelyeket **ez a program bocsátott ki**: kizárólag a saját úton, az alkalmazáson keresztül kiállított számlákra. Kimarad belőle a külső számlázón kiállított, a NAV-ból utólag importált számla és a díjbekérő. Ez nem hiányosság, hanem a hatály pontos követése – a részleteket, az indoklást és a beszerzés helyét a **17.3 pont** tartalmazza. ### 1.7 Minden fiókra ez vonatkozik 2026. augusztus 8. óta a saját, NAV-közvetlen kiállítás az **egyetlen** út: nincs fiókonként eltérő számlázási beállítás, és nincs mit választani. A felületen a kiállítás „titkár.ai · saját számlázás” néven jelenik meg. --- ## 2. A szoftver neve és azonosítója A 23/2014. (VI. 30.) NGM rendelet 10. § (1) bekezdése szerint a felhasználót tájékoztatni kell a **program nevéről és azonosítójáról** — ezt e fejezet teljesíti. A fejlesztő adatait és elérhetőségét a rendelet nem írja elő kötelező tartalomként; ezeket a dokumentum az átláthatóság kedvéért, önként közli. Az alábbi adatok **szó szerint azok**, amelyeket a program minden NAV-kérés `software` blokkjában elküld. ### 2.1 A NAV-nak beküldött szoftver-azonosító adatok | NAV-mező | Érték | |---|---| | `softwareId` | `13311908SZAMLAI001` | | `softwareName` | `titkar.ai` | | `softwareOperation` | `ONLINE_SERVICE` | | `softwareMainVersion` | `1.0` | | `softwareDevName` | `BITNEX GROUP Kft.` | | `softwareDevContact` | `info@titkar.ai` | | `softwareDevCountryCode` | `HU` | | `softwareDevTaxNumber` | `13311908` | Ezek az értékek a program forráskódjában egyetlen, központi helyen vannak rögzítve, és minden NAV-kérésbe azonos formában kerülnek bele. A pontos kimenetet automatikus teszt őrzi: ha bármelyik érték megváltozna, a változtatás nem tud észrevétlenül élesedni. A `softwareDevTaxNumber` a **8 jegyű törzsszám**, nem a teljes, 11 jegyű adószám – a NAV interfésze így kéri. Ugyanez vonatkozik a saját adószámodra is: a felületen a teljes adószámot adod meg, a NAV-nak az első 8 számjegy megy. **A `softwareId` és a `softwareName` szándékosan nem egyezik.** Az azonosító egy korábbi terméknév-tagot hordoz (`…SZAMLAI001`), a név viszont `titkar.ai`. Ez nem elírás: az azonosító a NAV-nál nyilvántartott előzmény miatt marad változatlan. Ez a páros a NAV felé következetesen ugyanígy megy ki; ellenőrzéskor mindkettőt ezen a néven kell keresni. **A program neve a rendelet 10. § (1) bekezdése értelmében: `titkar.ai`** – ékezet nélkül, pontosan úgy, ahogy a NAV-adatszolgáltatás `softwareName` mezőjében szerepel. A felületen és a kommunikációban használt „titkár.ai” írásmód ugyanennek a terméknek a megjelenítési alakja, nem külön program. Ellenőrzéskor a `titkar.ai` alakot kell keresni. ### 2.2 A fejlesztő és üzemeltető adatai (10. § (1)) > **Cégnév:** BITNEX GROUP Korlátolt Felelősségű Társaság (BITNEX GROUP Kft.) > **Székhely:** 4400 Nyíregyháza, Dózsa György utca 9. 3. emelet > **Cégjegyzékszám:** 15-09-069325 (Nyíregyházi Törvényszék Cégbírósága) > **Adószám:** 13311908-2-15 > **Közösségi (EU) adószám:** HU13311908 > **Képviselő:** Nánási Tamás Sándor > **E-mail:** info@titkar.ai > **Weboldal / szolgáltatás:** https://titkar.ai A fejlesztő és a szolgáltatás üzemeltetője **ugyanaz a társaság** – nincs külön forgalmazó. A támogatási és jogorvoslati csatornákat a 28. fejezet tartalmazza. ### 2.3 Melyik NAV-rendszerrel kommunikál a program | Környezet | Végpont | |---|---| | Éles | `https://api.onlineszamla.nav.gov.hu/invoiceService/v3` | | Teszt (NAV homokozó) | `https://api-test.onlineszamla.nav.gov.hu/invoiceService/v3` | **Éles használatban a környezet fixen az Éles** – a Teszt/Éles kapcsoló kizárólag a fejlesztői buildben jelenik meg, a nyilvános szolgáltatásban nem választható (lásd 6.5). Az adatszolgáltatás tehát nem tud véletlenül a NAV homokozójába menni. Az interfész az **Online Számla 3.0**: `requestVersion 3.0`, `headerVersion 1.0`, névtér `http://schemas.nav.gov.hu/OSA/3.0/api`. ### 2.4 Verziószám – a verziópolitika A NAV felé jelentett `softwareMainVersion` **e dokumentum verziószámát követi** (jelenleg `1.7`), egyetlen közös forrásból: a kettő EGYÜTT lép, amikor a program dokumentált viselkedése érdemben változik. A szabály részleteit a **27.3 pont** tartalmazza. --- ## 3. A működési modell: online szolgáltatás (SaaS) ### 3.1 Mit jelent az `ONLINE_SERVICE` üzemmód A program a NAV felé `softwareOperation = ONLINE_SERVICE` üzemmódot deklarál, és ez a valóságot írja le: a titkar.ai **kizárólag online szolgáltatásként (SaaS) érhető el**. Nincs letölthető, telepíthető változat, nincs helyi (on-premise) telepítés, és nincs olyan mód, amelyben a program a te gépeden vagy a saját szervereden futna. Neked böngésző és internetkapcsolat kell – semmi más. Telepítés, verziófrissítés, szerverüzemeltetés és adatbázis-karbantartás **nem terhel**: a frissítéseket és az adatbázis- migrációkat az üzemeltető futtatja, a szolgáltatás folyamatos működése mellett. ### 3.2 Hol fut és hol tárolódik az adat | Réteg | Szolgáltató | Régió | |---|---|---| | Alkalmazás (webes felület + szerveroldal) | Vercel Inc. | EU / Frankfurt (`fra1`) | | Adatbázis (PostgreSQL) | Neon Inc. | EU / Frankfurt (`aws-eu-central-1`) | | Gyorsítótár, munkamenet-tár (Redis) | Upstash | EU | | Tranzakciós e-mail | Resend | – | A NAV technikai felhasználód jelszava, XML aláírókulcsa és XML cserekulcsa – csakúgy, mint a külső számlázók kulcsai – **mindig titkosítva** (AES-256-GCM) tárolódnak az adatbázisban, és a kiszolgálót nem hagyják el: a felületre, a kérésekbe és a beépített AI-asszisztensnek sem kerülnek be. A visszafejtés kizárólag szerveroldalon, a NAV felé menő kérés összeállításakor történik (részletesen: 6.6 és 24.3). ### 3.3 A felület A titkar.ai kezelőfelülete egyetlen, folytonos chat: a bizonylatokat természetes nyelven kéred, és a rendszer kártyákon (előnézet, megerősítés, lista, PDF) válaszol. A beállítások nem külön oldalon, hanem a fiók-menüből nyíló ablakban élnek. A felület magyar és angol nyelven használható. ### 3.4 Háttérfolyamatok A saját számlázást két ütemezett folyamat szolgálja ki: | Folyamat | Gyakoriság | Mit csinál | |---|---|---| | NAV-beküldés | 15 percenként | a függőben lévő adatszolgáltatások státuszát lekérdezi, a sikertelen beküldéseket újrapróbálja (18.2) | | NAV-szinkron | óránként (vasárnap teljes) | a NAV-nál lévő számlaelőzményt szinkronizálja | ### 3.5 A kiállítás és az adatszolgáltatás két külön lépés – ezt tudnod kell A számla **nálunk, a lezáráskor jön létre**, egyetlen adatbázis-tranzakcióban. A NAV felé menő adatszolgáltatás viszont **nem része ennek a tranzakciónak**: a beküldés a számla létrejötte után indul, és ha a NAV éppen nem elérhető, az ütemezett folyamat viszi tovább. Ennek két következménye van, és mindkettő rád tartozik: 1. **A NAV kiesése nem akadályozza a számlázást.** Ki tudsz állítani számlát akkor is, ha a NAV rendszere nem elérhető. (Egy kivétel van: a legelső kiállítás előtt a kiállítói törzsadatot a NAV-tól kell megszerezni – lásd 16.6.) 2. **A kiállítás sikeréből nem következik, hogy az adatszolgáltatás is megtörtént.** Ezt külön kell ellenőrizned. A rendszer erre eszközt ad (16.8), és a beépített asszisztens is így válaszol. A jogszabály szerinti határidő kezelését a 18. fejezet írja le. ### 3.6 Korlátok - **Nincs offline működés.** Internetkapcsolat nélkül a program nem használható. - **Nincs „saját szerverre” telepíthető változat**, és nincs olyan funkció, amely a teljes adatbázisodat átadná egy másik rendszernek. Az adatkiadás a program által biztosított exportokon keresztül történik (adóhatósági ellenőrzési adatszolgáltatás, PDF, könyvelői csomag – lásd 25.3). - **A Szolgáltató rendelkezésre állási (SLA) vállalást nem tesz**, és telefonos ügyfélszolgálat nincs. A támogatás csatornáit és a nevesített határidőket a 28.2 pont tartalmazza. --- ## 4. A kezelt bizonylattípusok ### 4.1 Amit a saját út kiállít | Bizonylat | Sorszám-tartomány | NAV-adatszolgáltatás | Megjegyzés | |---|---|---|---| | **Számla** | `TITKAR-ÉÉÉÉ-N` (az előtag ma nem állítható át – lásd 8.8) | van | a teljes áfás számla | | **Díjbekérő** | `DIJB-ÉÉÉÉ-N`, az előtag **nem** módosítható | nincs | nem számla, fizetési felszólítás | | **Sztornó okirat** | a számlákkal **azonos** tartományból, saját sorszámmal | van | önálló bizonylat, negatív összegekkel | **Számla.** A sorszám a saját, elkülönített tartományból megy, kihagyás és ismétlés nélkül (23/2014. NGM 8. § (1) a)). A kiállítással együtt elkészül a NAV-nak szóló adatszolgáltatás (`CREATE` művelet), és a rendszer a bizonylatot a számlaláncba is beköti. **Díjbekérő.** A díjbekérő **nem számla**: nem megy a NAV-hoz, nincs hozzá számlalánc, és nem készül hozzá árfolyam-lekérdezés sem. A sorszáma fixen `DIJB` előtaggal megy – ez elkülönített, nem-számla tartomány, és **a felhasználó nem tudja átállítani**. Részletesen: 10. fejezet. **Sztornó okirat.** A sztornó **önálló bizonylat**, saját sorszámmal, a számlákkal azonos tartományból – nem az eredeti számla „törlése”. Az eredeti számla állapota `sztornózott`-ra vált, a sztornó okirat pedig negatív végösszegekkel, a NAV felé `STORNO` műveletként megy ki (13. fejezet). **Díjbekérőből végszámla.** Ez az út a saját számlázáson **működik**: a rendszer a mentett tételekből és vevőadatokból állítja össze a végszámlát, és belsőleg rögzíti, melyik díjbekérőhöz tartozik. A díjbekérő száma a végszámla számlaképére és a NAV-adatszolgáltatásba **nem kerül rá** (10.4). **Ismétlődő (havi) számla.** Az ismétlődő számlázás a saját úton is működik; a sikeres kiállítás után a rendszer a következő esedékességet is lépteti. Az **ütemezés létrehozása a Pro és az Ultra csomag funkciója**, az automatikus (megerősítés nélküli) kiállítás pedig Ultra csomagot kíván (12.1). **Számlakép (PDF).** A saját úton kiállított számlához a titkar.ai maga készíti a számlaképet, és azt **abból az adatból**, amit a NAV-nak jelentett – így a kép garantáltan a bevallott tartalmat mutatja (15. fejezet). **Előlegszámla és végszámla.** A saját úton **elérhető**: a beérkezett előlegről előlegszámla állítható ki, a teljesítés után pedig az azt beszámító végszámla. Mindkettő rendes számla, a számlák közös sorszám-tartományából, teljes NAV-adatszolgáltatással; a különbséget a tételekre kerülő előleg-jelölés, végszámlán pedig a beszámított előlegszámla hivatkozása adja. A feltételeket és a folyamatot a **9.13 pont** írja le. **Gyűjtőszámla és egyszerűsített számla.** Szintén **elérhető**, kifejezett kérésre: a gyűjtőszámla (Áfa tv. 164. §) több, külön napokon történt teljesítést fog egy bizonylatra, tételenkénti teljesítési dátummal; az egyszerűsített adattartalmú számla (Áfa tv. 176. §) azonnali készpénzes vagy bankkártyás fizetésnél a bruttó árat és az áfatartalmat közli, nettó-áfa bontás nélkül. A szabályokat és a korlátaikat a **9.13 pont** tartalmazza. ### 4.2 Amit a saját út NEM tud – ki kell mondani Az alábbiak a saját úton **jelenleg nem érhetők el**. A rendszer nem próbálja meg és nem hasal el félúton: a korlátot már akkor kimondja, amikor jelzed a szándékodat, és megmondja, mi a járható út helyette. A beépített asszisztens is előre közli ezeket, és nem ígéri meg őket. - **nyugta** (11. fejezet), - **időszakos elszámolású (folyamatos teljesítésű) számla**, - **kiállított díjbekérő törlése** (10.6). A teljes felsorolás az indoklással és a járható alternatívával a **26.1 pontban** áll. A **helyesbítő (módosító) számla** a saját úton **elérhető** (13.5): a hibás adat sztornó nélkül, módosító okirattal javítható, és ugyanaz a számla többször is helyesbíthető. ### 4.3 A sztornó feltétele Sztornózni csak azt a számlát lehet, amelynek a **NAV-adatszolgáltatása már lezárult (`done`)**, és egy számla **kétszer nem sztornózható**. Az előfeltételeket, a folyamatot és a korlátokat a **13. fejezet** írja le. ### 4.4 A te teendőid - **Hibás számlánál** válaszd meg a javítás útját: ha csak egy adat hibás, a helyesbítő számla a jobb út (a számla él tovább, a NAV a különbözetet kapja); ha az egész számla érvénytelen, sztornózd, és állítsd ki újra a helyes adatokkal. - **Készpénzes vevőnek** rendes számlát állíts ki, „készpénz” fizetési móddal. - **Előlegnél** díjbekérőt készíts, és abból csináld meg a végszámlát. - **Sztornó előtt** győződj meg róla, hogy az eredeti számla adatszolgáltatása lezárult. A nyugta **véglegesen nincs a programban**: a titkar.ai nem nyugtaadó program, és a fejlesztési terv sem irányoz elő nyugta-funkciót a saját úton (11.). --- ## 5. Hozzáférés, felhasználók, jogosultságok ### 5.1 Egy felhasználó – egy fiók A titkar.ai-ban **egy felhasználóhoz pontosan egy fiók (bérlő) tartozik**, és ezt az adatbázis egyedi indexszel is kikényszeríti. A regisztrációkor a fiók automatikusan létrejön; ha ez valamiért elakadna, a rendszer a következő kérésnél magától pótolja. **Nincs többfelhasználós hozzáférés.** Ezt egyértelműen ki kell mondani: - nincs meghívó-folyamat és nincs felhasználó-hozzáadó felület, - nincs „csak megtekintő”, „könyvelő” vagy más korlátozott hozzáférés, - az adatbázisban létezik ugyan `tulajdonos` / `tag` szerep-mező, de **viselkedésbeli különbsége nincs**: sem a kiállítás, sem a sztornó, sem a beállítások nem néznek szerepet. Ennek a gyakorlati következménye: a könyvelőd ma **nem tud külön hozzáférést kapni** a fiókodhoz. Az adatait a program exportjain keresztül kapja meg (adóhatósági ellenőrzési adatszolgáltatás, PDF-ek, könyvelői csomag), nem saját belépéssel. **Kimondva:** a fiókhoz **egyetlen természetes személy** fér hozzá, és **minden művelet az övé** — a fiókhoz hozzáférő felhasználó jogosult kiállítani, sztornózni és a beállításokat módosítani. Szerepkör-alapú jogosultsági rendszer nincs, és ez a dokumentum nem is ír le ilyet. ### 5.2 Belépési módok | Mód | Részletek | |---|---| | E-mail + jelszó | legalább 8 karakter; éles használatban **kötelező e-mail-megerősítés** | | Google-belépés | ha az üzemeltető konfigurálta | | Azonosítókulcs (passkey / WebAuthn) | jelszó nélküli, adathalászat-álló belépés | | Magic link | e-mailben küldött, 15 percig élő egyszer-használatos belépő link | | Kétlépcsős azonosítás | TOTP-alkalmazás, egyszer használatos kód, tartalék kódok | A munkamenet 7 napig él, aktív használat mellett naponta megújul. Jelszó-visszaállításkor a rendszer **minden korábbi munkamenetet megszüntet**, és a sikeres visszaállításról biztonsági értesítőt küld. A hitelesítés technikai védelmeit (kérés-korlátok, szerveroldali fiók-feloldás) a 24.1 pont írja le. ### 5.3 Platform-adminisztrátor Az üzemeltető oldalán létezik egy külön, **platform-admin** kategória (a szolgáltatás üzemeltetéséhez, például jutalék-elszámoláshoz). Ez szándékosan független a fiókok szerepköreitől, kizárólag előre rögzített, megerősített e-mail-címekhez köthető, és alapértelmezetten üres – beállítás nélkül senki nem admin. A **te számláid adataihoz ez a kategória nem ad automatikus hozzáférést**. ### 5.4 A saját számlázás bekapcsolásának feltételei A saját útra váltás **csak akkor engedélyezett**, ha a fiókodhoz be van kötve egy **NAV technikai felhasználó** (login név, adószám, jelszó, XML aláírókulcs), **és** meg van adva az **XML cserekulcs** is. A cserekulcs nélkül a számla kiállítása menne, az adatszolgáltatás viszont nem – ezért a rendszer a váltást ilyenkor elutasítja, és megmondja, mi hiányzik. **A NAV-oldali jogosultságok (legkisebb jogosultság elve):** | Amit használni akarsz | NAV-jogosultság | |---|---| | Számlatörténet behúzása | „Számlák lekérdezése” | | **Saját (NAV-közvetlen) számlázás** | „Számlák kezelése” **és** XML cserekulcs | | Áfabevallás gépi beadása (eÁFA) | külön bevallás-jogosultság az eÁFA felületén | A bekötés lépéseit, a kulcsok tárolását és a saját úthoz tartozó korlátokat a **6. fejezet** részletezi. A számlázás kártyáján **nincs „Kapcsolat bontása” gomb**: nincs külső számlázó-kulcs, amit bontani lehetne — a NAV-hozzáférés visszavonása a NAV oldalán, illetve a tárolt adatok törlésének kérésével történik (lásd 6. fejezet). ### 5.5 Biztonsági korlátok a kiállításra (választható) A beállítások Biztonság pontja alatt korlátokat kapcsolhatsz be: **megerősítés azonosítókulccsal** (step-up), **egy számla bruttó plafonja** és **napi darabszám-plafon**. **Alapértelmezetten egyik sincs bekapcsolva** – ilyenkor semmilyen extra korlát nem érvényes. A **két kemény korlát** – az egy számlára vonatkozó bruttó összegplafon és a napi darabszám-plafon – **minden kiállítási úton érvényesül**: az egyedi, a tömeges és az ütemezett (automatikus ismétlődő) kiállításon egyaránt; ezeket egyik út sem kerüli meg. A **megerősítés azonosítókulccsal (step-up) ezzel szemben csak az általad indított utakon fut**: az egyedi és a tömeges kiállításon. Az Ultra csomag automatikus ismétlődő kiállítása **nem kér kiállításonként azonosítókulcsos igazolást** – ott az igazolás egyszer, az automatikus mód bekapcsolásakor történik (12.1). Ha tehát „mindig” megerősítés-módot állítasz be, az az automatikus ütemezésekre nem terjed ki. A beállítások pontos jelentését, a döntési sorrendet és az atomi foglalást a **24.2 pont** írja le. > **Vállalt döntés (T-38 lezárva):** marad a bekapcsoláskori egyszeri igazolás, mert a > felhatalmazás **a konkrét ütemezés tartalmához kötött**: az ütemezés vevője, tételei és > összege utólag **nem módosítható** — tartalmi változtatás csak törlés + újrafelvétel útján > lehetséges, ami új azonosítókulcsos igazolást kíván; az automatikus mód kikapcsolása a > felhatalmazást törli; meglévő felhatalmazás alatt egyedül a hónap napja állítható át. Az > agent (és így egy esetleges prompt injection) az automatikus módot bekapcsolni nem tudja — > az kizárólag a megerősítő kártya védett, azonosítókulcsot kérő útján kapcsolható. ### 5.6 Csomaghoz kötött korlátok A csomagok számszerű keretei (Free havi 5 éles számla, mentett partnerek száma, napi AI-üzenetkeret) és a funkció-korlátok a **23. fejezetben** állnak. Két dolgot itt is érdemes tudni a havi keretről: - A számláló **minden számlát** beleszámol az adott naptári hónapban – beleértve a **sztornó okiratot** is (az önálló számla-bizonylat), valamint a NAV-ból importált számlákat. A díjbekérő és a nyugta nem számít bele. - A kereten belül a később sztornózott számla is „elhasznált” marad – a kiállítás ténye a metrika, így nincs „sztornózd és állítsd ki újra” kerülőút. ### 5.7 A blokkolt kiállítás nem oszt sorszámot Ez a sorszámozás folyamatossága (23/2014. NGM 8. § (1) a)) miatt fontos, ezért kimondjuk: **ha a kiállítás bármely okból elakad, sorszám nem használódik el, és lyuk nem keletkezik a sorszám-tartományban.** A rendszer ezt két, egymástól független módon biztosítja: a korlátok a sorszám-kiosztás **előtt** döntenek, a kiosztás pedig a mentés **tranzakcióján belül** történik. A teljes levezetés a **8.3 és 8.6 pontban**, a csomag-kapuk sorrendje a **23.3 pontban** áll. ### 5.8 Napló – és a naplózás korlátja A rendszer a bizonylat-műveletekről (vázlat, megerősítés, kiállítás, sztornó, hiba) naplót vezet a fiókodhoz, a bizonylatszámmal és a művelet adataival együtt (24.4). **Korlát, amit ki kell mondani:** a kiállítási és sztornó-naplóbejegyzések **nem rögzítik, hogy melyik felhasználó végezte a műveletet** – a napló a fiókhoz kötött, nem a személyhez. Mivel a fiókhoz jelenleg egyetlen felhasználó tartozhat (5.1), ez a gyakorlatban nem okoz kétértelműséget: minden művelet a fiók egyetlen felhasználójáé. A „ki állította ki” kérdésre azonban a napló önmagában nem válaszol. **Kimondva:** mivel a fiókhoz egyetlen felhasználó tartozik (5.1), **minden művelet ehhez a felhasználóhoz rendelhető** — a napló fiók-szintű bejegyzése így személyhez köthető. ### 5.9 A te teendőid - Hozz létre a NAV Online Számla felületén **technikai felhasználót „Számlák kezelése” joggal**, és add meg a beállításokban a login nevet, adószámot, jelszót, XML aláírókulcsot **és XML cserekulcsot**; ezután aktiváld a „titkár.ai · saját számlázás” kártyát. - Erősítsd meg az e-mail-címedet (ez kötelező), és kapcsold be az azonosítókulcsot vagy a kétlépcsős azonosítást. - Megfontolandó (nem kötelező): állíts be a Biztonság alatt összeg-plafont és napi darabszám-korlátot – ezek az elgépelt nagy összeg és a futótűz-szerű, hibás sorozat ellen védenek. --- ## 6. Üzembe helyezés: a NAV technikai felhasználó és a kulcsok Ez a fejezet azt írja le, mit kell egyszer beállítanod ahhoz, hogy a titkár.ai a saját útján – külső számlázó program nélkül, közvetlenül a NAV Online Számla rendszere felé – működjön. Amíg ez az üzembe helyezés nincs kész, a saját út nem kapcsolható be. ### 6.1 Mire van szükség A saját úthoz **egyetlen külső azonosító-készlet** kell, a NAV Online Számla rendszeréből: | Adat | Mire kell | Kötelező a saját úthoz | |---|---|---| | Technikai felhasználó **login neve** | azonosítás a NAV felé | igen | | Technikai felhasználó **jelszava** | azonosítás (SHA-512 lenyomatként megy ki) | igen | | A céged **8 jegyű törzsszáma** (az adószám első 8 jegye) | az adózó azonosítása | igen | | **XML aláírókulcs** (signing key) | minden NAV-kérés aláírása (SHA3-512) | igen | | **XML cserekulcs** (exchange key) | az adatszolgáltatási token dekódolása a beküldéshez (AES-128-ECB) | **igen** | Az aláírókulcsot és a cserekulcsot a NAV állítja elő a technikai felhasználóhoz; a titkár.ai egyiket sem generálja és nem is tudja kitalálni. A cserekulcs a NAV specifikációja szerint pontosan 16 karakter – a rendszer ezzel a kulccsal fejti vissza a NAV-tól kapott adatszolgáltatási tokent. ### 6.2 A NAV-oldali lépések 1. Lépj be a NAV Online Számla rendszerébe (Ügyfélkapuval), a céged adózói fiókjába. 2. Hozz létre egy **technikai felhasználót**. 3. Add meg neki a megfelelő jogosultságokat. A rendszer erről szó szerint ezt közli veled a bekötő űrlapon: a számlatörténet-importhoz csak lekérdező jog kell („Számlák lekérdezése”), **ha viszont a saját (titkár.ai-os) számlázást is használod, ahhoz a „Számlák kezelése” jog ÉS az XML cserekulcs is kell**. 4. Generáld és másold ki az **aláírókulcsot** és a **cserekulcsot**. **Ugyanezt a követelményt mondja ki a chatben megjelenő NAV-bekötő kártya és a nyilvános Biztonság-oldal is:** a bejövő számlák beolvasásához elég a lekérdező jog, a „Számlák kezelése” (beküldés, módosítás) jog viszont **kell**, ha a saját, NAV-közvetlen számlázást is használod – mert az adatszolgáltatást ilyenkor a titkár.ai küldi be a nevedben (24.6). A Beállítások NAV-szekciójában két külső hivatkozás segít: a NAV Online Számla megnyitása, illetve a NAV hivatalos regisztrációs útmutatója. > A NAV-oldali nyilvántartásba vétel (a technikai felhasználó létrehozása) a > 13/A. § (2) szerint az adatszolgáltatás megkezdésének **előfeltétele**. Ez a te > feladatod az adózói fiókodban; a titkár.ai ezt nem tudja helyetted elvégezni. ### 6.3 A bekötés a titkár.ai-ban A bekötő űrlap a **Beállítások → NAV-szekcióban** van. Mezők: login név, adószám, jelszó, XML aláírókulcs. A cserekulcs mezője **alapból rejtve van**, és „(opcionális)” címkével jelenik meg – a „**+ XML cserekulcs (opcionális, későbbi beküldéshez)**” gombra kattintva nyílik ki. **Ez a jelölés a számlatörténet-import szempontjából igaz, a saját számlázás szempontjából nem: a cserekulcs a saját úton kötelező.** Nélküle a rendszer nem enged át a saját számlázásra, és ha valahogy mégis oda kerülnél, a kiállítás menne, az adatszolgáltatás viszont nem. A jelszó mezőbe a technikai felhasználó **bejelentkezési jelszava** kell, nem valamelyik kulcs. Ha a NAV `INVALID_SECURITY_USER` hibával elutasít, a felület célzott terelő szöveget mutat: éles fiókban jött-e létre a felhasználó, a jelszó mezőben tényleg a bejelentkezési jelszó van-e, és pontos-e a login név. ### 6.4 Mit ellenőriz a rendszer mentés előtt – és mit nem **Amit ellenőriz:** - **Offline adószám-ellenőrzés.** A megadott törzsszámot ellenőrzőszámmal validáljuk; hibás számnál a NAV-ot meg sem hívjuk, azonnal szólunk. - **Élő hitelesítés-próba.** A mentés előtt a szerver egy rövid, egy oldalas `queryInvoiceDigest` lekérdezést futtat (kimenő irány, elmúlt 7 nap). Csak akkor mentünk, ha ez lefutott – így a rossz jelszó vagy rossz aláírókulcs azonnal kiderül. **Amit NEM ellenőriz – ezt fontos tudnod:** - A bekötési próba **csak a lekérdező utat igazolja**. A **cserekulcs helyességét** és a **„Számlák kezelése” jog** meglétét bekötéskor semmi nem ellenőrzi. - Ezek hibája **először az első számla beküldésénél derül ki**, tehát már azután, hogy a számla nálunk létrejött. A számla ilyenkor érvényes, csak az adatszolgáltatása akad el – a rendszer újrapróbálja, és a pénzügyi teendők között jelzi (18.4). ### 6.5 Teszt és éles környezet A NAV két végpontot üzemeltet, és a rendszer mindkettőt ismeri (a végpontok címét a 2.3 pont tartalmazza). **Az éles szolgáltatásban a teszt-mód nem választható.** A kapcsoló csak fejlesztői buildben látszik, és a szerver élesben mindig `live` módra kényszerít – így egy manipulált űrlap sem köthet be teszt-környezetet a valódi számláidhoz. ### 6.6 Hogyan tároljuk a kulcsokat Fiókonként (céged szerint) **egyetlen sor** tárolja a NAV-adatokat (`nav_credentials` tábla, egyedi index a bérlőre). Ami titkosítva van és ami nem: | Mező | Tárolás | |---|---| | Jelszó | **titkosítva** | | XML aláírókulcs | **titkosítva** | | XML cserekulcs | **titkosítva** | | Login név | nyíltan | | Adószám (törzsszám) | nyíltan | | Mód (teszt/éles), időbélyegek | nyíltan | | Kiállítói törzsadat pillanatképe (név, cím, áfakód, megyekód) | nyíltan | A titkosítás **AES-256-GCM**, `base64(iv):base64(tag):base64(ciphertext)` formátumban; a kulcs egy 32 bájtos, környezeti változóban tárolt alkalmazás-kulcs (`APP_ENCRYPTION_KEY`), ami nem az adatbázisban van. **A visszafejtés kizárólag szerver oldalon történik.** A böngészőbe, a chatbe és az AI-modellhez a jelszó és a kulcsok soha nem kerülnek ki. A felület állapot-lekérdezője egyetlen titkot sem fejt vissza – csak azt adja vissza, hogy van-e eltárolt cserekulcs. A NAV felé a kriptográfia a NAV specifikációja szerint megy: a jelszó SHA-512 lenyomata, a kérés-aláírás SHA3-512, a NAV-tól kapott token dekódolása a cserekulccsal AES-128-ECB. ### 6.7 A saját számlázás bekapcsolása A Beállítások „Számlázó” váltójában a harmadik szegmens neve **„titkár.ai · saját számlázás”**. A leírása szó szerint: > „A számlát maga a titkár.ai állítja ki, és közvetlenül a NAV Online Számla felé > szolgáltat adatot – nincs külön számlázó-előfizetés. A számlaszám saját, elkülönített > tartományból megy (TITKAR-ÉÉÉÉ-N), a számlaképet is mi adjuk.” A váltásnak **szerveroldali kapuja** van. Bekötött NAV technikai felhasználó **és** eltárolt cserekulcs nélkül a rendszer elutasít, ezzel az üzenettel: > „A saját számlázáshoz az XML cserekulcs is kell – add meg a NAV technikai > felhasználónál (és a NAV-fiókban a »Számlák kezelése« jog is legyen bepipálva).” A szegmens **fokozatos bevezetés alatt áll**: csak akkor jelenik meg, ha a céged már a saját úton van, vagy ha az üzemeltető a bevezetési kapcsolót kinyitotta. Ha nem látod, a saját út a te fiókodban még nem elérhető. **A teendők sorrendje:** 1. NAV Online Számla fiókban technikai felhasználó létrehozása, „Számlák kezelése” joggal. 2. Az aláírókulcs és a cserekulcs kimásolása. 3. Beállítások → NAV-szekció: login, adószám, jelszó, aláírókulcs, majd a „+ XML cserekulcs” gomb alatt a cserekulcs megadása. 4. Beállítások → Számlázó → „titkár.ai · saját számlázás” → „Számlázás ezzel”. ### 6.8 A kiállító (a te céged) adatai a számlán A számlára és a NAV-adatszolgáltatásba kerülő **kiállítói törzsadat nem a mi űrlapunkról jön**: a rendszer a saját adószámodra lekérdezi a NAV `queryTaxpayer` szolgáltatását, és onnan veszi a hivatalos nevet, a címet, az áfakódot és a megyekódot. Így garantáltan az az érték megy vissza a NAV-nak, amit a NAV maga tart nyilván. Minden sikeres lekérdezés eltárol egy **pillanatképet** (`supplier_snapshot`). Ha a NAV épp nem érhető el, a kiállító-blokk ebből épül fel – a NAV kiesése így nem akadályozza a számlakiállítást (13/B. §). **Kivétel:** ha pillanatkép sincs (például a legelső kiállításnál), a kiállítás meghiúsul – lásd 16.6. A törzsadatból **egyetlen mező a miénk: a bankszámlaszám**, amit a beállításaidnál adsz meg (ez kerül a számlaképre és az átutalási QR-kódba). ### 6.9 Korlátok – amit ezen az úton tudnod kell - **A NAV-adatok újbóli mentése a cserekulcsot megőrzi.** A mentés felülíró (upsert) művelet, de a cserekulcs mező üresen hagyása a korábban eltárolt cserekulcsot **nem törli** – az érintetlenül megmarad. A cserekulcs cseréje új érték megadásával történik; üres mezővel törölni nem lehet. - **A chatben megjelenő NAV-bekötő kártyán nincs cserekulcs mező** (csak login, adószám, jelszó, aláírókulcs). Onnan a saját számlázás nem hozható működésbe – a meglévő cserekulcsot azonban egy onnan indított frissítés nem bántja (lásd az előző pontot). A saját úthoz mindig a **Beállítások** NAV-szekcióját használd. - **A NAV-kapcsolat bontására a saját úton nincs felület.** A számlázó-kártyán nincs „Kapcsolat bontása” gomb, mert a saját útnak nincs külső számlázó-kulcsa; a NAV technikai felhasználó törlésére sincs külön UI. - **A NAV-nyilvántartott cégadat kézzel nem írható felül.** Név, cím, adószám, áfakód, megyekód: kizárólag a NAV `queryTaxpayer` válaszából származhatnak. Amit a NAV nem ad vissza, az fiók-szintű beállítás: a **közösségi adószám** és a **pénzforgalmi elszámolás** a számlázási alapértékek között adható meg, az alanyi adómentesség-jelölés a tételek AAM-jogcíméből származik (28.6). - **A pillanatkép nem tárol mindent.** A `supplier_snapshot` a nevet, a címet, az áfakódot és a megyekódot őrzi meg – a **közösségi adószámot és az alanyi adómentesség jelölését nem**. **Kimondva:** a NAV-kapcsolat megszüntetésére **nincs önkiszolgáló eljárás** — a bontást a Szolgáltatótól kell kérned (info@titkar.ai), aki a tárolt kulcsokat törli. A kulcsok cseréje rendezett: új érték megadása felülír, az üresen hagyott cserekulcs-mező a meglévőt megőrzi. --- ## 7. A számlakiállítás folyamata és állapotai ### 7.1 A három szakasz A saját úton a számla útja mindig ugyanaz a három szakasz: **vázlat → megerősítés → lezárás** A vázlat egy külön táblában él (`invoice_drafts`), és soha nem számla. A számla a lezáráskor születik meg. ### 7.2 A vázlat Amikor számlát kérsz, a rendszer **vázlatot** állít össze. Ez: - **nem állít ki semmit**, és nem oszt sorszámot; - a **szerver** számolja ki belőle a nettó, áfa és bruttó összegeket (nem az AI-modell); - kap egy **külső azonosítót**; - `awaiting_confirmation` (megerősítésre vár) állapotban mentődik. **A külső azonosító csak az egyik úton véd a duplikátum ellen.** A tömeges kiállításnál ez a köteghez kötött, **stabil** kulcs, ezért ott a köteg ismételt beküldése (dupla kattintás, oldal-újratöltés) nem hoz létre második bizonylatot (12.2). Az egyedi kiállításnál viszont az azonosító **véletlenszerű**: ott a duplikátum ellen a megerősítés atomi állapotváltása véd (egy vázlatból egy számla – 7.4), valamint a percenkénti 10-es kérés-korlát (7.9). **Ha ugyanazt a számlát kétszer kéred meg, két külön vázlat készül** – ezt a megerősítő kártyán neked kell észrevenned. ### 7.3 A megerősítő kártya A vázlat egy **interaktív kártyaként** jelenik meg a beszélgetésben. A kártya mutatja: a vevőt, a tételeket, a nettó/áfa/bruttó összeget, a pénznemet, a fizetési módot, a teljesítés dátumát, a fizetési határidőt, a kiállítási út jelét, és – ha van – figyelmeztetéseket (lásd 9.11). A kártyán két dolgot tehetsz: - **„Szerkesztem”** – a vázlat a kiállítás előtt módosítható (tételek, fejléc). A módosítás ugyanazon az ellenőrző kapun megy át, mint az eredeti vázlat, és **ugyanaz a vázlat-azonosító és idempotencia-kulcs marad** (nem keletkezik második bizonylat). Csak `awaiting_confirmation` állapotban lehetséges. - **„Kiállítom”** – ez a tudatos megerősítés. A gomb egy szerveroldali végpontot hív a vázlat azonosítójával. **Ez a kattintás indítja a lezárást.** Az AI-asszisztens önmagában nem tud számlát kiállítani: a kiállítás mindig a te kattintásodra indul (22.3). ### 7.4 A lezárás (a rendelet 8. § (6) bekezdése szerint) A rendelet szerint a számla akkor minősül kiállítottnak, amikor a program az adatait **lezárja**; az adatszolgáltatási kötelezettség is ehhez az időponthoz kötődik. A titkár.ai saját útján a lezárás **egyetlen adatbázis-tranzakció**. A folyamat: 1. A rendszer először **atomi állapotváltással** foglalja le a vázlatot (`awaiting_confirmation` → `issuing`). Csak ebből az egy állapotból enged – így egy dupla kattintásból sem lesz két számla. 2. Lefutnak a kiállítás előtti kapuk (csomagkeret, biztonsági korlátok, passkey-s megerősítés – lásd 8.6). 3. A tranzakción **kívül**, még előtte, a rendszer beszerzi a hálózatot igénylő adatokat: a kiállítói törzsadatot (élő NAV-lekérdezés vagy a tárolt pillanatkép) és devizás számlánál az MNB-árfolyamot. A tranzakcióban már csak adatbázis-írás és számítás van. 4. **Megnyílik a tranzakció**, és egyben megtörténik: 1. a **sorszám kiosztása**, 2. a NAV `InvoiceData` XML **felépítése és ellenőrzése** – még mielőtt bármi tartósan mentődne, 3. a **számla sorának** létrehozása (állapot: kiállítva), 4. a **tételsorok** létrehozása, lánc-tételindexszel, 5. a **számlalánc** magjának létrehozása (a későbbi sztornó/módosítás horgonya), 6. a **NAV-beküldés sorba állítása** `pending` állapotban, a beküldendő XML-lel és annak SHA3-512 lenyomatával együtt, 7. a vázlat `issued`-re állítása a számlaszámmal, és az **audit-napló** bejegyzés. 5. **A számla a tranzakció véglegesítésének (commit) pillanatában jön létre.** Ez a lezárás pillanata – nálunk, nem egy távoli rendszerben. **Ha a tranzakció bármely lépése elhasal, a visszagörgetés mindent visszavon**: nem marad se kiosztott sorszám, se félkész számla, se árva beküldési szándék. Ezért a hiba utáni újrapróbálkozás veszélytelen: nem keletkezhet duplikátum és nem keletkezhet sorszám-lyuk. ### 7.5 A vázlat állapotai | Állapot | Jelentése | |---|---| | `draft` | összeállítás alatt | | `awaiting_confirmation` | megerősítésre vár (ez a kártya állapota) | | `issuing` | a kiállítás fut (lefoglalt vázlat) | | `issued` | a számla létrejött, a vázlaton rajta a számlaszám | | `failed` | a kiállítás elakadt; semmi nem tartósult | **A `failed` vázlat nem indítható újra.** A kiállítás csak `awaiting_confirmation` állapotból enged, tehát ilyenkor új vázlatot kell kérned. Ez szándékos: az újraindítás elmosná, hogy melyik kísérlet melyik adattal futott. ### 7.6 A NAV-adatszolgáltatás nem része a lezárásnak **A kiállítás és a NAV-adatszolgáltatás két külön lépés.** A tényleges beküldés a tranzakció véglegesítése **után** indul, „legjobb szándék” alapon; ha nem sikerül, azt naplózzuk, és az újrapróbáló sor viszi tovább. A NAV kiesése így soha nem akadályozza a számla kiállítását (13/B. §). Ebből következik a legfontosabb szabály, amit a rendszer az AI-asszisztensre is rákényszerít: > **A kiállítás sikeréből soha nem következik, hogy az adatszolgáltatás is teljesült.** **Ezt mondja a megerősítő kártya szövege is:** a kiállítás előtti mondat úgy szól, hogy „A kiállítás végleges, és **a NAV-adatszolgáltatás azonnal indul**” – nem úgy, hogy „azonnal jelentjük a NAV-nak”. A különbség nem stilisztikai: a beküldés **megindul**, a teljesüléséhez viszont a NAV visszaigazolása kell (16.3). Ugyanez a megfogalmazás áll a sztornó megerősítő kártyáján is (13.7). > **Korlát, kimondva:** ez a megfogalmazás a **magyar felületen**, a **megerősítés előtti** mondatra > igaz. Az **angol** felületen a kártya változatlanul befejezett tényt állít („we report it to NAV > right away”), és a kiállítás közbeni, majd utáni jelzés is így fogalmaz: „Jelentem a NAV-nak…”, > utána a számlaszám mellett „· NAV-nak jelentve” (sztornónál „Sztornózom és jelentem a NAV-nak…”, > illetve „· érvénytelenítve, jelentve a NAV-nak”). Ezek a feliratok a bizonylat létrejöttét > jelzik, nem az adatszolgáltatás teljesülését. **A mérvadó mindig az adatszolgáltatás lekérdezett > állapota (16.4, 16.8), nem a kártya felirata.** > > Ugyanennek a kártyának a záró mondata a későbbi javításra „sztornó vagy helyesbítő számla” > lehetőséget kínál – mindkettő elérhető (13.4, 13.5). A beküldés önálló állapotgépen fut (`pending` → `submitted` → `done` / `aborted` / `failed`); az állapotok pontos jelentését, a „teljesült-e” és a „magától rendeződik-e” kérdést a **16.4 pont** táblázata adja meg. A NAV saját hibakódjait a rendszer magyar, cselekvésre hívó mondatokra fordítja; ismeretlen kódnál a NAV eredeti üzenete jelenik meg, hogy soha ne maradj puszta kóddal (18.5). ### 7.7 Automatikus utánkövetés **15 percenként** fut egy ütemezett feladat, amely lekérdezi a beküldött tételek feldolgozási állapotát, és újrapróbálja az elakadt beküldéseket. Amit a rendszer **soha nem küld újra**: a már beküldött (`submitted`) és a NAV által tartalmilag elutasított (`aborted`) tételt. A pontos szabályokat, a türelmi időt és az indoklást a **18.2 és 18.3 pont** tartalmazza. ### 7.8 Hogyan látod, mi történik a beküldéssel Három út van rá – rákérdezés a chatben, egy konkrét számla adatszolgáltatásának lekérdezése, és a pénzügyi teendők sávjában magától megjelenő jelzés. A három eszközt a **16.8 pont**, a jelzések küszöbeit a **18.4 pont** írja le. Kézi újraküldést `failed` és `pending` állapotnál kérhetsz; `aborted` esetén a rendszer **szándékosan megtagadja** (18.6). ### 7.9 Amit a kiállító végpont korlátoz - **Kérés-korlát**: percenként legfeljebb 10 kiállítási kérés cégenként. Ez a véletlen vagy hibás ismétlés ellen véd, és a korlátot vezérlő szolgáltatás kiesésekor is zárva marad (inkább elutasítunk, mint kockáztassuk a dupla kiállítást). - **Idempotencia**: ha egy már kiállított vázlatot erősítesz meg újra (például oldal-újratöltés után), a rendszer **a korábbi eredményt adja vissza**, nem állít ki másodszor. ### 7.10 Audit-napló A folyamat minden lépése naplóba kerül: `draft` (vázlat), `confirm` (megerősítés), `issue` (kiállítás), `fail` (sikertelen kiállítás), `storno` (érvénytelenítés). A napló felépítését, lekérdezését és korlátait a **24.4–24.5 pont** írja le. ### 7.11 Korlátok – amit ezen az úton tudnod kell - **A kiállítási hiba oka nem mindig jut el hozzád.** A NAV-leképező és a séma-ellenőrző részletes magyar hibaüzeneteit (pl. „a vevő adószámos, ezért a címét is meg kell adni”) a megerősítés utáni ágon a rendszer egy általános **„A kiállítás nem sikerült.”** mondatra cseréli, és ez kerül a vázlatra és eléd is. A vázlat összeállításakor keletkező hibák konkrét üzenete viszont eljut hozzád. - **Az elakadt beküldés nem szólal meg magától a beszélgetésben.** A `pending` és `failed` állapotról a pénzügyi teendők sávjából vagy kérdésre értesülsz. - **Technikai érvénytelenítés (ANNUL) ezen az úton nincs beküldve.** A rendszer ismeri az adatszerkezetét, de a beküldő kifejezetten elutasítja, és az ütemezett feladat is kihagyja. A NAV-hoz tévesen felküldött adatszolgáltatás technikai érvénytelenítését ma a NAV saját felületén kell intézni (18.9). - A `failed` vázlat nem indítható újra (lásd 7.5). **Kimondva:** a kiállítás lezárásának pillanata a **tranzakció véglegesítése** a szolgáltató rendszerében — nem a hálózati válasz megérkezése hozzád. Ez egyben a rendelet **8. § (6)** bekezdése szerinti kiállítási időpont is: a számla abban az időpontban minősül kiállítottnak, amellyel a program a számla adatait **lezárja**. Ritka esetben (a véglegesítés és a válasz között megszakadó kapcsolatnál) a számla létezik, miközben a felület hálózati hibát mutat; a tényleges állapotot ilyenkor a számla lekérdezése adja meg, és a sorszám-folytonosság mindkét esetben sértetlen. --- ## 8. Sorszámozás ### 8.1 A sorszám képe A saját úton kiállított bizonylat sorszáma: ``` ELŐTAG-ÉÉÉÉ-N ``` Például: **`TITKAR-2026-42`**. A sorszám **nincs nullákkal feltöltve**: a 9. után a 10. számla `…-10` lesz, nem `…-0010`. Az előtag a számláknál **`TITKAR`**, a díjbekérőknél **`DIJB`** – egyik sem állítható át a felületről (lásd 8.8). ### 8.2 A tartomány kulcsa Egy sorszámtartományt három adat határoz meg: **a céged + az előtag + az év**. Minden ilyen hármashoz külön számláló tartozik. ### 8.3 Kihagyás és ismétlés nélküli folyamatosság (8. § (1) a)) A rendelet 8. § (1) a) pontja folyamatos, kihagyás és ismétlés nélküli sorszámozást ír elő. Ezt a rendszer **két, egymást kiegészítő mechanizmussal** biztosítja: 1. **Atomi kiosztás.** A számláló léptetése egyetlen adatbázis-utasítás, amely zárolja a számláló sorát. Két párhuzamos kiállítás közül a második megvárja az elsőt – **két számla soha nem kaphatja ugyanazt a sorszámot**. 2. **A kiosztás a számla mentésének tranzakcióján belül fut.** Ha a kiállítás bármely későbbi lépése elhasal, a visszagörgetés a számláló léptetését is visszavonja – **lyuk sem keletkezik**. Ez a két szabály a kódban is kimondott kényszer: a sorszámot a tranzakción kívül kiosztani tilos. **Igazolás valós adatbázison** (2026-08-04, éles motorral azonos PostgreSQL-en): - 25 párhuzamos kiosztás → 25 egyedi, folytonos sorszám, duplikátum nélkül; - szimulált kiállítási hiba (visszagörgetés) után a következő sorszám a 26. → **nincs lyuk**; - évváltásnál a számláló 1-től indul. ### 8.4 Évváltás A számláló **évenként 1-től indul újra**. Az ismétlésmentesség évhatáron át azért áll fenn, mert a **sorszám maga tartalmazza az évet** (`TITKAR-2026-1` és `TITKAR-2027-1` két különböző sorszám). Az év forrása a **kiállítás dátumának éve**, nem önmagában a szerver órája. ### 8.5 Elkülönített tartományok (8. § (2) és (5)) Az elkülönítést az **előtag** adja: eltérő előtag = önálló, egymástól független számsor. Ezen az alapon a **számla** és a **díjbekérő** ma is két külön tartományon fut (`TITKAR-…` és `DIJB-…`). ### 8.6 A sikertelen kiállítás nem oszt sorszámot A rendszerben több, egymást követő kapu áll, és **mindegyik a sorszám kiosztása előtt dönt**. Ha bármelyik blokkol, sorszám nem keletkezik: | Kapu | Mikor fut | Mit tesz | |---|---|---| | Free havi keret (5 éles számla/hó) | a kiállítás megkezdése előtt | elutasít, és egykattintásos csomagváltást kínál | | Díjbekérő tiltása Free csomagon | a kiállítás megkezdése előtt | elutasít | | Biztonsági összegplafon és napi darabkorlát | a tranzakció megnyitása előtt | blokkol; a lefoglalt napi hely visszaadódik, a vázlat visszaáll megerősítésre várakozóra | | Passkey-s megerősítés (ha bekapcsoltad) | a kiállítás megkezdése előtt | megerősítést kér, enélkül elutasít | | Kiállítói törzsadat vagy árfolyam hiánya | a tranzakció előtt | hibával megáll | | NAV-leképezés és séma-ellenőrzés hibája | a tranzakción **belül**, de minden tartósítás előtt | teljes visszagörgetés – a kiosztott sorszám is visszavonódik | ### 8.7 A sorszám gépi feldolgozása A rendszer a számlaszámot az **utolsó két szegmens** alapján bontja vissza évre és sorszámra, így a kötőjelet tartalmazó előtag is helyesen kezelhető (`BIT-NEX-2026-7`). A sorszám-intervallumra kérdező adóhatósági ellenőrzési adatszolgáltatás (11/A. §) **soha nem szöveget hasonlít**: `TITKAR-2026-10` szövegként kisebb volna, mint `TITKAR-2026-9`, és az export csendben hiányos lenne. A rendezés és a tartomány-döntés mindig a kinyert (év, sorszám) páron megy. A NAV-oldali formai kapuk közül a sorszámot kettő érinti: a számlaszám elején és végén nem lehet szóköz vagy sortörés, és a módosító okirat sorszáma nem egyezhet a módosított számla sorszámával. A **sztornó okirat önálló számlaszámot kap**, ugyanabból a tartományból (tehát a sztornózás is fogyaszt egy sorszámot – ez így felel meg a folytonosságnak). ### 8.8 Korlátok – amit ezen az úton tudnod kell - **Az előtag ma a felületről nem állítható át.** A rendszer belül ismeri a „számlaszám-előtag” beállítást, és a saját út ezt olvassa, **de egyetlen felületi vagy asszisztens-funkció sem írja**: sem a beállítás-mentés, sem a titkár preferencia-eszköze nem küldi. **Következmény: az előtag közvetlen adatbázis-beavatkozás nélkül `TITKAR` marad.** - **Az előtagra semmilyen formai szabály nincs kikényszerítve** (hossz, engedélyezett karakterek) a saját úton. - **Az előtag év közbeni megváltoztatása új, 1-től induló tartományt nyitna** – a rendszer ezt nem tiltja és nem figyelmezteti a felhasználót. - **Nyugta nincs a saját úton**, ezért a 8. § (5) szerinti külön nyugta-tartomány sem létezik itt. Készpénzes vevőnek rendes számlát tudsz kiállítani, készpénz fizetési móddal (11. fejezet). - **A 8. § (2) esete ezen az úton nem áll fenn.** A rendelet akkor követel meg elkülönített sorszámtartományt, ha az adóalany a programmal a magyarországi adószáma **mellett más adószám alatt is** bocsát ki számlát. A titkár.ai saját útján a kiállító mindig a fiókodhoz bekötött magyar adószám, mert a kiállítói törzsadat kizárólag a NAV adóalany-lekérdezéséből származik (6.8) – más adószám alatti kibocsátás nem lehetséges. **Ha más tagállami adószámod alatt is számlázol, azt ezzel a programmal nem teheted.** A vevő honossága ezt a szabályt nem érinti. **Időzóna: a sorszám éve a magyar naptári évet követi.** A kiállítás dátumát (a **keltét**) a rendszer **magyar idő szerinti naptári napként** állapítja meg (`Europe/Budapest`), és a sorszám évét ebből a keltéből veszi. Ugyanebben az időzónában számol a napi darabkorlát számlálója is, így a kettő nem tud szétcsúszni. **Következmény: a magyar éjfél után kiállított számla a helyes – aznapi – dátumot kapja, és szilveszter éjjel sem kerülhet vissza az előző év sorszámtartományába.** **A sorszámozással kapcsolatban nincs teendőd:** a sorszámot a rendszer osztja, kézzel nem adható meg és nem írható felül. Ugyanez igaz a **kelte** (a kiállítás dátuma) mezőre is: azt a rendszer a kiállítás magyar idő szerinti napjából állapítja meg, **nem adható meg és nem írható felül** (9.2). **Az előtag nem választható a felületen:** a rendszer a beépített `TITKAR` előtagot használja; fiók-szintű saját előtagot kizárólag a Szolgáltató tud beállítani, kérésre. **Ha az előtag megváltozik** (év közben is), az új előtag alatt **új, 1-től induló tartomány** nyílik; a korábbi tartomány lezárul, és önmagában kihagyás- és ismétlésmentes marad — a 8. § (2) tartományonként követeli a folytonosságot, több párhuzamos vagy egymást váltó tartomány megengedett. --- ## 9. A számla adattartalma és kiállítása Ez a fejezet azt írja le, milyen adatokat követel meg a rendszer, mikor és mit utasít vissza, és mi az, amit ma nem tud a számlára tenni. ### 9.1 Amit a vázlat szintjén kötelezően megkövetelünk Ezek az ellenőrzések már a megerősítő kártya előtt lefutnak, és a hibaüzenetük konkrét, magyar mondat, ami hozzád is eljut: - **Legalább egy tétel** kell. - Minden tételnél kötelező: **megnevezés, mennyiség, mértékegység, nettó egységár, áfakulcs**. - A mennyiség és a nettó egységár **véges szám**; a mennyiség **pozitív**. - Negatív nettó egységár csak végszámlán és helyesbítő számlán megengedett (a végszámla a saját úton ma nem elérhető – lásd 26.1). Helyesbítő számlán a negatív sor csak akkor fogadható el, ha az eredeti számla hatályos állapotában is van negatív (engedmény-)sor – különben a rendszer különbözet-gyanús bemenetként elutasítja (13.5). - A megadott **magyar adószámot ellenőrzőszámmal validáljuk**; hibás számnál a rendszer elutasítja a kiállítást, magyarázó mondattal. - Adószámos magyar vevőnél az irányítószámnak **4 számjegyűnek** kell lennie. - A dátumok formátuma `ÉÉÉÉ-HH-NN`, és valódi naptári napot kell jelenteniük (a „2026-02-30” elbukik). - **A fizetési határidő nem előzheti meg a teljesítés napját.** - A pénznem, a számlanyelv és az áfakulcs zárt, ellenőrzött készletből jön. **A vevő címét a program minden vevőnél megköveteli – a magánszemélynél is.** Ez az ellenőrzés nem a vázlat szintjén, hanem a **kiállítási kapun** fut (ugyanott, ahol az adószámos vevő címe is – 9.3, 9.8): irányítószám vagy település nélkül a **számla nem jön létre**. A kiállítás a NAV-adatszerkezet felépítésekor áll meg, a tranzakció visszagörgetésével, tehát **sorszám sem fogy el** (7.4, 8.6). A kódba írt indoklás ugyanaz, mint a jogszabályé: a vevő neve és címe a **számla** kötelező eleme (Áfa tv. 169. § e)) – **akkor is, ha a NAV-adatszolgáltatásba nem kerül bele** (Áfa tv. 10. számú melléklet). A magánszemély vevőre a program saját, külön hibaüzenetet tart fenn: > „A(z) »X« vevő címe hiányzik (irányítószám, település, közterület). A vevő neve és címe a számla > kötelező eleme, ezért enélkül a számla nem állítható ki – még akkor sem, ha a vevő magánszemély, > és így a NAV-adatszolgáltatásba nem is kerül bele.” **Ennek a mondatnak a konkrét szövege a megerősítés utáni ágon nem jut el hozzád**: ott – a többi leképező-hibához hasonlóan – az általános „A kiállítás nem sikerült.” üzenet jelenik meg (7.11). Ami viszont biztos: a hiányos című számla **nem keletkezik meg**. **Következmény:** a saját úton kiállított számla képén a vevő címe **mindig ott van**, és a 11/A. § szerinti adóhatósági ellenőrzési adatszolgáltatásba is ezekből az adatokból kerül vissza (15.2, 17.4). A megkövetelt mezők az **irányítószám és a település**; ha a közterület (utca, házszám) hiányzik, a címbe egy `-` kerül a helyére. A teljes cím megadása ezért itt is erősen ajánlott. **A te teendőd:** a magánszemély vevőnél is rögzítsd az irányítószámot és a települést – akár a partner adatlapján, akár a számlakérésben. ### 9.2 Alapértelmezések Ha nem mondasz mást, a rendszer ezekkel dolgozik: | Adat | Alapértelmezés | |---|---| | Kelte (a kiállítás dátuma) | a kiállítás napja **magyar idő szerint** – **nem adható meg és nem írható felül** (8.8) | | Teljesítés dátuma | a mai nap (magyar idő szerint) | | Fizetési határidő | teljesítés + a beállított napszám (alap: 8 nap) | | Fizetési mód | a beállított, egyébként „átutalás” | | Pénznem | a beállított, egyébként HUF | | Számlanyelv | a beállított, egyébként magyar | A konkrét kérésed mindig erősebb a tartós beállításnál, a tartós beállítás pedig erősebb a fenti alapoknál. ### 9.3 A vevő és a vevő-adatok A rendszer a megadott adószám alapján sorolja be a vevőt, és ehhez igazítja, mit követel meg: | Vevő | Mikor | Mit követel meg | |---|---|---| | **Belföldi adóalany** | magyar adószám-mintára illeszkedő szám (8 jegyű törzsszám, opcionálisan áfa- és megyekóddal) | név **és** cím kötelező | | **Egyéb (közösségi)** | a vevőnek **közösségi adószáma** van megadva. A külföldi adószámot a **közösségi adószám** mezőben kell megadni: az „adószám” mezőbe írt külföldi szám érvénytelen magyar adószámként elutasítjuk | név **és** cím kötelező | | **Magánszemély** | nincs adószám | név **és** cím kötelező – a **számla** miatt (169. § e)); a NAV-adatszolgáltatásba viszont **sem a neve, sem a címe nem kerülhet bele** | **A cím megadása minden vevőnél kötelező**, csak az indoka más. Adószámos vevőnél a NAV követeli meg (`CUSTOMER_DATA_EXPECTED`), magánszemélynél a számla kötelező adattartalma – ezért a két hibaüzenet is más. Adószámos vevőnél a rendszer a beküldés előtt elutasít, ezzel a mondattal: > „A(z) »X« vevő adószámos, ezért a NAV-nak a címét is meg kell adni (irányítószám, > település, közterület). Egészítsd ki a vevő adatait.” Magánszemély vevőnél ugyanez a kapu a 9.1 pontban idézett, saját mondatával áll meg – a hibaüzenet ott nem az adószámra hivatkozik, hanem a számla kötelező adattartalmára. Mindkét ágon az **irányítószám és a település** hiánya buktatja meg a kiállítást; ha a közterület (utca, házszám) hiányzik, a címbe egy `-` kerül a helyére. A teljes cím megadása ezért erősen ajánlott. **Külföldi vevőnél fontos csapdát kerül el a rendszer**: egy külföldi adószámból (pl. `DE123456789`) a számjegyek kiszedésével hamis *magyar* adószám keletkezne – ez valótlan adatszolgáltatás lenne. Ezért a belföldi ág csak a magyar adószám-mintára nyílik meg; ha a szám nem illeszkedik és közösségi adószám sincs megadva, a rendszer megáll és pontosítást kér. **Magánszemély vevő neve és címe** a NAV-adatszolgáltatásból kimarad (Áfa tv. 10. sz. melléklet), és ezt egy külön ellenőrző kapu is őrzi. Ugyanakkor a **számlaképnek** és a hatósági ellenőrzési adatszolgáltatásnak (11/A. §) szüksége van rá, ezért a vevő címét a rendszer a **számla saját során is eltárolja** – a kiállításkori állapotában, nem a később átírható partner-nyilvántartásból. ### 9.4 Áfakulcsok és mentességi jogcímek Belföldi számlán a NAV csak a **0% · 5% · 7% · 12% · 18% · 27%** kulcsokat fogadja el; más numerikus kulcsnál (pl. külföldi 19% vagy 21%) a rendszer érthető magyar hibával megáll. A mentességi és hatályon kívüli jogcímek teljes, elfogadott listáját (AAM, TAM, KBAET, KBAUK, EAM, NAM, ATK **és a vele azonos jelentésű TAHK**, EUFAD37, EUFADE, EUE, HO, valamint a belföldi fordított adózás `F.AFA` jelölése) a **14.3 pont** tartalmazza. **Kétértelmű kódokat a rendszer nem találgat.** Az `EUT`, `EUKT`, `EU`, `EUK`, `MAA`, `K.AFA` és `AKK` kódoknál megtagadja a leképezést, és pontosítást kér – mert ezek nem mondják meg egyértelműen a helyes NAV-jogcímet (termék vagy szolgáltatás, 37. § vagy sem, illetve a különbözeti adózás fajtája). Ez szándékos: egy rossz áfa-jogcím valótlan adatszolgáltatás. ### 9.5 Mértékegység A mértékegység **kötelező adat**, és a rendszer **nem pótolja „darab”-bal**: üres mértékegységnél bekéri tőled, ezzel az indokkal, hogy „a számlán kötelező adat”. Az ismert magyar egységeket (db, kg, tonna, óra, perc, nap, hó, liter, km, m, fm, m³, kWh, karton, csomag) NAV-kódra képezzük le; ismeretlen egységnél saját megnevezésként megy ki, legfeljebb 50 karakterre vágva. ### 9.6 Fizetési mód | Amit megadsz | Ahogy a NAV-nak megy | |---|---| | átutalás | TRANSFER | | készpénz | CASH | | bankkártya | CARD | | utalvány | VOUCHER | | minden más | OTHER | A számla a NAV felé **elektronikus megjelenésű** bizonylatként megy. ### 9.7 Deviza és árfolyam Devizás számlánál az árfolyam **kötelező, és nem lehet nulla**; HUF-nál fixen 1. Az árfolyamot a rendszer **magától szerzi be** az MNB napi középárfolyamából. Ha az árfolyam-forrás nem elérhető, a rendszer **nem ír be némán 1-et**, hanem megáll – a hibás árfolyam hibás adatszolgáltatás volna. A pénznem-készletet, az áthidalási és a tizedesjegy-szabályokat a **14.6 pont** részletezi. Ehhez nincs teendőd. ### 9.8 A beküldés előtti ellenőrző kapu A NAV-nak küldendő adatszerkezetet a rendszer még a beküldés előtt ellenőrzi. Az elv a kódban is ki van mondva: **„inkább itt bukjon el, mint a NAV-nál”** – mert a NAV elutasításánál a beküldés meg sem történik, és a számla adatszolgáltatás nélkül maradna. A fontosabb, kikényszerített szabályok: - a pénznem kódja pontosan 3 nagybetű; - az árfolyam legfeljebb 6 tizedesjegy; HUF-nál csak 1 lehet; - a kiállító neve, a vevő neve és a tétel megnevezése legfeljebb 512 karakter, és nem lehet üres; - természetes mértékegységű tételnél a megnevezés, a mennyiség, a mértékegység és az egységár **mind** kötelező; saját mértékegységnél a megnevezés kötelező; - elszámolási időszak vége nem lehet a kezdete előtt; - a számlaszámra vonatkozó formai szabályok (lásd 8.7); - új számla nem hivatkozhat eredeti számlára; módosító és sztornó okirat viszont csak hivatkozással érvényes, és sztornónál a tételsorok nem hagyhatók el. Az áfa-specifikus, determinisztikus ellenőrzéseket (adómentes tételnél nulla áfa, fordított adózás vevő-feltétele, közösségi jogcímek vevő-státusza) a **14.4 pont** sorolja fel. ### 9.9 A kiállító adatai a számlán A kiállító neve, címe, adószáma, áfakódja és megyekódja a NAV saját nyilvántartásából származik (lásd 6.8); a bankszámlaszám a beállításaidból. Ezeket a számlán kézzel nem írod felül. ### 9.10 A számlakép (PDF) A számlaképet a rendszer **a NAV-nak beküldött adatszerkezetből** rendereli – így a kép bizonyíthatóan ugyanazt a tartalmat mutatja, amit a NAV-nak jelentettünk. Magánszemély vevőnél a név és a cím a kiállításkor eltárolt vevőadatból kerül vissza a képre. A számlakép felépítését, az ellenőrzött kötelező adattartalmat, a lenyomatot és a kézbesítést a **15. fejezet** írja le. ### 9.11 Figyelmeztetések, amelyek nem blokkolnak A megerősítő kártya kiemelten jelez, ha a vázlat a vevő korábbi bizonylataihoz képest szokatlan: **kiugró összeg**, **első bizonylat ennek a vevőnek**, **szokatlan áfakulcs**. Ezek tájékoztatnak, **soha nem blokkolnak** – a döntés a tiéd. (A tömeges és az automatikus ismétlődő úton ez az ellenőrzés nem fut – lásd 12.4.) ### 9.12 Korlátok – amit ezen az úton tudnod kell - **A vevő adószámának NAV-oldali érvényességét a kiállítás nem ellenőrzi.** Van külön adószám-ellenőrző funkció, amit kérésre lefuttat a titkár, de a kiállítási út magától nem futtatja le. - **Ma nem tölthető mezők a saját úton**: a tétel termékkódja (VTSZ/SZJ/KN), a tétel-szintű engedmény, a szállítólevél-hivatkozás, a számviteli teljesítés dátuma, az elszámolási időszak és a közmű-jelölés. A NAV-adatszerkezet ezeket ismeri, de a vázlat-bemenetben nincs mező hozzájuk. - **Nincs időszakos elszámolású (folyamatos teljesítésű) számla** a saját úton. A **gyűjtőszámla** viszont elérhető (9.13). - **A vevő e-mail címe a NAV-nak nem megy** – az csak a számla kiküldéséhez kell. - **A kiállító közösségi adószáma és a pénzforgalmi elszámolás fiók-szintű beállítás** (számlázási alapértékek): kitöltve a közösségi adószám a supplier-blokkba és a számlaképre, a pénzforgalmi jelölés az adatszolgáltatásba és a számlaképre kerül. Az **alanyi adómentesség-jelölést** a program a tételek jogcíméből származtatja: AAM-jogcímű tételt tartalmazó számlán a jelölés automatikusan kikerül a NAV-nak; AAM-tétel nélkül a mező kimarad. - **Hibás bemenetnél a megerősítés utáni ágon a konkrét ok elveszik** (lásd 7.11); a vázlat-szintű ellenőrzések üzenete viszont eljut hozzád. **A te teendőid a gyakorlatban:** - adószámos vevőnél add meg a **teljes címet** (irányítószám, település, közterület); - **külföldi vevőnél add meg az országot is** — kétbetűs (ISO 3166-1 alpha-2) kódként, pl. `DE`, `AT`. Ország nélkül a cím belföldinek (HU) számít. A rendszer a formátumot ellenőrzi (a nem kétbetűs érték hibával elbukik, még a kiállítás előtt), és a magyar adószámú vevőhöz külföldi országot nem enged (a kettő együtt valótlan adatszolgáltatás lenne). A mentett partner országa automatikusan a számlára kerül; - **mértékegység és áfakulcs nélkül nincs számla**; - kétértelmű áfakódnál (pl. „EU”) pontosítsd a jogcímet; - devizás számlához nincs teendőd: az árfolyamot a rendszer szerzi be. ### 9.13 Speciális számlafajták Az alábbi három fajta ugyanabból a **közös sorszám-tartományból** megy, mint a rendes számla, és mindegyikhez teljes NAV-adatszolgáltatás tartozik. A rendszer egyiket sem választja magától: **kifejezetten kérned kell**, és a szabályok megsértését már a vázlat szintjén, a megerősítő kártya ELŐTT elutasítja, magyar mondattal. #### Előlegszámla Az előlegszámla a **már beérkezett** előlegről szól (Áfa tv. 59. §). A teljesítés dátuma az **előleg kézhezvételének napja**, és a bizonylat minden tétele előleg-jelölést kap az adatszolgáltatásban. - **Ha a pénz még nem érkezett meg, nem előlegszámla kell, hanem díjbekérő** – a program a díjbekérőt előlegszámlaként megjelölni nem engedi, és ezt ki is mondja. - Előlegszámla nem lehet egyszerre végszámla, és nem lehet gyűjtő- vagy egyszerűsített számla. #### Végszámla (előleg beszámításával) A végszámla a teljes ügyletet számlázza, és **levonja** a korábban előlegszámlázott összeget. Ehhez két dolgot kell megadnod: a **beszámított előlegszámla számát**, és előlegszámlánként **pontosan egy negatív (levonó) tételt** – a kettőt a program sorrendben párosítja. Több előleg is beszámítható, de ugyanaz az előlegszámla csak egyszer. A beszámítás előtt a rendszer minden előlegszámlára ellenőrzi, hogy - **itt, ezen a fiókon állították-e ki** (más rendszer előlegszámláját nem tudjuk hitelesen visszaolvasni), - **él-e még** (sztornózott előleg nem számítható be), - **lezárult-e sikeresen a NAV-adatszolgáltatása** – ez a legfontosabb feltétel: amíg a NAV vissza nem igazolta, a végszámla egy nála még nem létező bizonylatra hivatkozna. Elutasított előlegszámlánál a járható út a javítás, nem a beszámítás, - **valóban előlegszámla-e** (van rajta előleg-jelölés), - **azonos-e a pénzneme** a végszámláéval. A NAV-nak menő beszámítási adatot (az előleg kézhezvételének napja, az előlegszámla árfolyama) **nem tőled kérjük be**: a program az előlegszámla eltárolt, hiteles adatszolgáltatásából és a számlalánc hatályos fejadatából olvassa vissza. Így az sem okoz eltérést, ha az előlegszámla dátumát közben egy fejadat-helyesbítő módosította. > **Két különböző „végszámla” – ne keverd össze.** Az itt leírt végszámla egy korábbi > **előlegszámlát** számít be, és a beszámítás a NAV-adatszolgáltatásba is bekerül. A > **10.4 pont** szerinti „díjbekérőből végszámla” ettől független út: a díjbekérő nem számla és > nincs adatszolgáltatása, ezért ott nincs mit beszámítani – a rendszer csak a díjbekérő > tételeit és vevőadatait veszi át egy rendes számlába. #### Gyűjtőszámla (Áfa tv. 164. §) Több, **külön napokon történt** teljesítés egy bizonylaton. Ilyenkor **minden tételhez kötelező a tétel saját teljesítési dátuma** – a NAV ezt 2025. szeptember 15. óta blokkoló hibaként kéri számon –, és a számlaképen tételenként meg is jelenik. A számla fej-szintű teljesítési dátuma nem lehet korábbi a legkésőbbi tétel-teljesítésnél; ha üresen hagyod, a rendszer a tételekből veszi. Gyűjtőszámla nem lehet díjbekérő, előleg-, vég- vagy egyszerűsített számla. #### Egyszerűsített adattartalmú számla (Áfa tv. 176. §) **Csak azonnali, készpénzes vagy bankkártyás fizetésnél** állítható ki. Itt a bruttó ár az irányadó, és az áfát nem kulcsként, hanem **áfatartalomként** közli a bizonylat: a számlaképen ezért a nettó és az áfa oszlop szándékosan **üresen marad** (a „0” hamis állítás lenne egy áfás bruttó összeg mellett), a bruttó és az áfatartalom viszont ott van. A tételek áfakulcsa csak 5%, 18% vagy 27% lehet (ezeknek van áfatartalom-alakjuk), vagy adómentességi jogcím (AAM, TAM, …). Egyszerűsített számla nem lehet díjbekérő, előleg-, vég- vagy gyűjtőszámla. #### Ami ezeknél a fajtáknál a javításra vonatkozik - **Egyszerűsített és gyűjtőszámla nem helyesbíthető** módosító okirattal: a helyesbítő más szerkezetű bizonylat lenne (bruttó + áfatartalom, illetve tétel-szintű teljesítési dátumok). A program ezt már a szándék jelzésekor kimondja – a járható út a **sztornó + új, helyes számla**. Sztornózni viszont mindkettőt lehet. - **Előlegszámla és végszámla tételei nem helyesbíthetők**: az újraközölt sorokról némán lemaradna az előleg-jelölés (végszámlánál a beszámított előlegszámla hivatkozása), ami valótlan adatszolgáltatás lenne. A **fejadat** (dátum, fizetési mód) helyesbítése ezeken a bizonylatokon is működik, tétel-hibánál pedig a sztornó + újra kiállítás az út. --- ## 10. Díjbekérő (proforma) ### 10.1 Mi a díjbekérő, és mi nem A díjbekérő **fizetési felszólítás, nem számla**. A rendszerben külön bizonylatfajtaként él, és a legfontosabb következménye: > **A díjbekérő nem megy a NAV-hoz – nem tartozik hozzá adatszolgáltatás.** Ezt a saját úton a kód is egyértelműen kizárja: díjbekérőnél nem készül NAV-adatszerkezet, nem jön létre számlalánc, és nem keletkezik beküldési sor. Sőt, díjbekérőnél a rendszer a kiállítói törzsadatot sem kérdezi le a NAV-tól, és devizás díjbekérőhöz árfolyamot sem szerez be. ### 10.2 Hogyan készül Pontosan ugyanazon az úton, mint a számla: **vázlat → megerősítő kártya → „Kiállítom”**. A bemeneti követelmények is azonosak a számláéval (lásd 9.1). ### 10.3 Saját sorszámtartomány A díjbekérő fixen a **`DIJB`** előtaggal megy, tehát `DIJB-ÉÉÉÉ-N` – a számlák tartományától teljesen elkülönítve, önálló, 1-től induló számsoron. Ezt az előtagot nem tudod megváltoztatni. ### 10.4 Díjbekérőből végszámla Fizetés után a díjbekérőből **egy lépésben** rendes számla készíthető: - a rendszer új vázlatot állít össze, **számlaként**, és **belsőleg** megjegyzi, melyik díjbekérőből készült; - a tételeket és a vevő adatait a **mentett adatból** tölti, nem az AI-modell szövegéből – így a számok és a vevő adatai pontosak maradnak; - a vázlatot ugyanúgy a megerősítő kártyán hagyod jóvá. > **Korlát, kimondva:** a saját (NAV-közvetlen) úton a díjbekérőre való hivatkozás **kizárólag a > program belső nyilvántartásában** él. Két dolgot szolgál: hogy egy díjbekérőből csak egy > végszámla készülhessen, és hogy a pénzügyi teendők között emlékeztetni tudjunk rá. **A díjbekérő > száma nem kerül rá a végszámla számlaképére, és nem kerül bele a NAV-adatszolgáltatásba sem.** Ha > a bizonylaton is látszódnia kell a hivatkozásnak, írd bele a tétel megnevezésébe. (A külső > számlázós úton ez másképp működik: ott valódi, bizonylat-szintű hivatkozás keletkezik.) **Egyszeri-végszámla őr.** Egy díjbekérőhöz **egy** végszámla tartozhat. Ha már készült, a rendszer elutasít, és megnevezi a meglévő végszámla számát: > „Ehhez a díjbekérőhöz (…) már készült végszámla (…) – egy díjbekérőből csak egy > végszámla állítható ki. Ha módosítani kell, sztornózd a meglévő végszámlát és állíts ki > újat.” **Emlékeztető.** Ha egy díjbekérőt kifizettek, de nincs hozzá végszámla, ez **kiemelt (magas) súlyú teendőként** jelenik meg a pénzügyi teendők között: „A(z) … díjbekérőt kifizették – a végszámla kiállítása kötelező.” – egy „Végszámla kiállítása” akcióval. A díjbekérő → végszámla út a saját úton **működik**; nem esik a saját út korlátai alá. ### 10.5 Csomag- és darabkorlátok | Korlát | Vonatkozik a díjbekérőre? | |---|---| | A díjbekérő **Pro és Ultra** csomag funkciója | igen – Free csomagon a rendszer már a vázlatnál elutasít, és a kiállító végpont is | | Free havi 5 éles számla keret | **nem** – a havi számláló csak a rendes számlákat nézi | | Az általad beállított **napi darabkorlát** | **igen** – a napi számláló az aznap keletkezett összes bizonylatot nézi | ### 10.6 Korlátok a saját úton – amit tudnod kell - **A díjbekérő PDF-je letölthető, és e-mailben is kiküldhető.** A kép a saját sablonnal készül, a sorszáma alatt kimondja, hogy nem számla, a záradéka pedig megadja a bankszámlát és a közleményt. Adatszolgáltatás továbbra sem tartozik hozzá. - **A díjbekérő nem törölhető.** A rendszer válasza: „A saját (NAV-közvetlen) számlázáson kiállított díjbekérő törlése még nem érhető el. A díjbekérő nem számla, adatszolgáltatás nem tartozik hozzá – ha mégsem lesz belőle üzlet, egyszerűen hagyd figyelmen kívül, vagy jelezd a vevőnek, hogy visszavontad.” **Következmény: a saját úton kiállított díjbekérő véglegesen „kiállítva” állapotban marad, a visszavonásának nincs rendszerbeli nyoma.** A díjbekérő megerősítő kártyájának lábszövege ezért törlést nem is ígér. - **A díjbekérő nem sztornózható és nem helyesbíthető.** A sztornó kifejezetten elutasítja („Ez egy díjbekérő – azt nem sztornózni, hanem törölni kell.”), a helyesbítő pedig csak kiállított számlára megy. - Technikai megjegyzés: a díjbekérő adatbázis-sorára is rákerül egy NAV-műveletjelölés (`CREATE`), holott NAV-művelet nem tartozik hozzá. Ez **tárolási melléktermék, nem funkció** – a díjbekérőről semmilyen adat nem megy a NAV-hoz. ### 10.7 A te teendőid - **Fizetés után a díjbekérőből végszámlát kell kiállítani.** Ez már NAV-adatszolgáltatással járó, kötelező lépés; a rendszer emlékeztet rá. - **Meghiúsult üzletnél nincs teendőd a rendszerben**: a díjbekérőt nem kell (és a saját úton nem is lehet) törölni; elég a vevőt értesíteni a visszavonásról. **Szabály:** a `DIJB` előtag **rögzített** – a felhasználó nem tudja megváltoztatni, és a díjbekérő-tartomány így mindig elkülönül a számla-tartománytól. --- ## 11. Nyugta **A saját (NAV-közvetlen) úton a titkár.ai nyugtát nem állít ki.** Ez nem átmeneti üzemzavar és nem beállítás kérdése: a nyugta-funkció a programban ezen az úton nincs kiépítve. ### 11.1 Miért nem A nyugta a számlától két ponton is elkülönül, és mindkettő önálló fejlesztést kíván: - **Elkülönített sorszámtartomány.** A 23/2014. (VI. 30.) NGM rendelet 8. § (5) bekezdése szerint a nyugta sorszámozásának a számláétól elkülönített, önmagában folyamatos tartományból kell kiosztódnia. A program sorszám-kiosztója elvben tud több tartományt kezelni – a tartományt a (felhasználó, előtag, év) hármas jelöli ki, és a kiosztás atomi, kihagyás és ismétlés nélküli (8. § (1) a)) –, de a saját úton ma **mindössze két előtag van kiosztva**: a számláé (`TITKAR`) és a díjbekérőé (`DIJB`) – egyik sem állítható át a felületről (8.8). Nyugta-tartomány nincs. - **Külön adatszolgáltatás.** A nyugta adatszolgáltatása nem az Online Számla `manageInvoice` útján megy. A programmal előállított (nem e-pénztárgépes) nyugta a papírnyugtával egyenértékű, adatszolgáltatása 2026. szeptember 1-jétől napi összesítésben, adómértékenkénti bontásban, 3 naptári napon belül teljesítendő (Áfa tv. 257/G. § és 11. számú melléklet B) rész). E-nyugtát kizárólag e-pénztárgéppel lehet kiállítani (8/2025. (III. 31.) NGM rendelet). A titkár.ai egyik csatornát sem szolgálja ki: a NAV-beküldő rétegben a művelet-készlet `CREATE | MODIFY | STORNO | ANNUL`, nyugta nem szerepel benne. ### 11.2 Mit tapasztalsz a felületen Ha nyugtát kérsz, az asszisztens nem készít vázlatot és nem kér megerősítést, hanem azonnal ezt válaszolja: > „A saját (NAV-közvetlen) számlázáson a nyugta még nem érhető el – a nyugta külön > sorszámtartományt és külön adatszolgáltatást kíván. Készpénzes vevőnek addig is > állíthatsz ki rendes számlát (fizetési mód: készpénz).” A korlát mind a négy nyugta-műveletnél ugyanígy, ugyanezzel a mondattal áll: | Művelet | Saját (NAV-közvetlen) út | Megjegyzés | | --- | --- | --- | | Nyugta kiállítása | Nem érhető el | Nincs kiosztott sorszámtartomány | | Nyugta lekérdezése | Nem érhető el | A korábbi, külső számlázós korszakból származó nyugta adatai sem jelennek meg | | Nyugta küldése e-mailben | Nem érhető el | – | | Nyugta sztornózása | Nem érhető el | – | A korlát a **szándék jelzésekor** lép életbe, nem a megerősítés után: nem fordulhat elő, hogy végigviszel egy nyugta-vázlatot, rákattintasz a kiállításra, és csak ott derül ki, hogy nem megy. ### 11.3 Nincs mire visszaesni A program szándékosan nem épít külső szolgáltató-kapcsolatot, és soha nem esik vissza rá: ha a nyugta itt nem érhető el, akkor sehol – a felület ezt mondja ki, nem kerülő utat ajánl. ### 11.4 Korlátok – kimondva - A saját úton nyugta **nem állítható ki, nem kérdezhető le, nem küldhető e-mailben és nem sztornózható**. - Ez akkor is így van, ha korábban, a külső szolgáltatós időszakban voltak nyugtáid: a lekérdezés is elakad a korlátnál, tehát a régi nyugták adatai a saját úton nem jelennek meg. - A programban **nincs nyugta-sorszámtartomány és nincs nyugta-adatszolgáltatás** – sem a NAV KOBAK-felületére, sem e-pénztárgép felé. ### 11.5 A te teendőd - **Készpénzes vevőnél állíts ki rendes számlát**, `készpénz` fizetési móddal. A program a „készpénz”, „keszpenz” és „cash” alakot egyaránt a NAV `CASH` fizetési módjára képezi. - Ha az adott ügylethez jogszabály szerint valóban nyugta kell (és nem számla), azt a titkár.ai-n kívül – pénztárgéppel vagy más nyugtaadási megoldással – kell megoldanod. - **Figyelem, 2026. szeptember 1-től:** a kézi (nyugtatömbös) és a számítógéppel előállított nyugtákról is **adatot kell szolgáltatni a NAV-nak** (a kibocsátást követő 3 naptári napon belül, napi összesítésben, adómértékenként – a NAV KOBAK-felületén vagy gépi úton). Ez a kötelezettség a titkár.ai-n kívül kiállított nyugtáidra vonatkozik, és **nem ennek a programnak a funkciója** – az online és e-pénztárgépek automatikusan teljesítik, a kézi nyugtatömbnél magadnak kell. **A titkár.ai nem nyugtaadási program** a 23/2014. NGM rendelet 2. §-a értelmében: nyugta kiállítására szolgáló funkciója nincs, és ilyen funkciót a fejlesztési terv sem irányoz elő. A 10. § (2) szerinti funkciólista (21. fejezet) ennek megfelelően nyugta- funkciót nem tartalmaz. --- ## 12. Ismétlődő és tömeges kiállítás Sem az ismétlődő, sem a tömeges kiállítás **nem külön kiállítási út**. Mindkettő ugyanazt a vázlat → megerősítés → kiállítás láncot használja, mint az egyedi számla, tehát ugyanazok a sorszám-kiosztási, NAV-adatszolgáltatási és tranzakciós szabályok vonatkoznak rájuk (7. fejezet). A különbség csak az, hogy mi indítja el a láncot: egy ütemezés vagy egy köteg. ### 12.1 Ismétlődő számlázás **Csomag-feltétel.** Az ismétlődő ütemezés **létrehozása és módosítása a Pro és az Ultra csomag funkciója** – Free csomagban a rendszer már az ütemezés felvételét elutasítja, magyar mondattal. Az esedékes bizonylat **automatikus** (megerősítés nélküli) kiállítása ezen felül **Ultra** csomagot kíván. Egy ismétlődő ütemezés a következőket rögzíti: címke, vevő, tételek, pénznem, bizonylattípus (számla vagy díjbekérő), és a **hónap napja**, amikor esedékessé válik. | Paraméter | Érték / szabály | | --- | --- | | A hónap napja | **1 és 28 között** – a hó vége minden hónapban más napra esne | | Esedékesség | aktív ütemezés + a hónap napja elérkezett + ebben a hónapban még nem állt ki | | Hónap-kulcs | `ÉÉÉÉ-HH`, a magyar naptári nap szerint | | Felvételkor | ha a felvétel napja már **túl van** a megadott napon, az adott hónap teljesítettnek számít – nem indul azonnali kiállítás | Két üzemmód van: - **Kézi megerősítéssel (alapértelmezés).** Az automatikus futás nem nyúl az ütemezéshez. Amikor esedékessé válik, a program jelzi neked, és te indítod el a kiállítást – a megerősítő kártyáról vagy külön kéréssel. - **Automatikus kiállítás.** Napi egyszeri automatikus futás állítja ki az esedékes bizonylatokat. Az automatikus mód **három, egymástól független feltételt** kíván. Bármelyik hiánya azt jelenti, hogy a kiállítás nem történik meg: | Feltétel | Mit jelent | Mi történik hiányában | | --- | --- | --- | | **Ultra csomag** | Az automatikus kiállítás az Ultra csomag funkciója | Az ütemezés kimarad a futásból, és hibaüzenetet kap | | **Azonosítókulcsos (passkey) megerősítés** | A bekapcsolás pillanatában igazolnod kell magad | A bekapcsolás nem történik meg | | **Rögzített felhatalmazás** | A bekapcsoláskor, azonosítókulccsal adott felhatalmazás. **Határideje nincs: amíg ki nem kapcsolod, addig érvényes** | Az automatikus futás nem állít ki, hanem hibát ír az ütemezés sorára | Az automatikus kapcsolót **az asszisztens nem tudja bekapcsolni.** Ha megkéred rá, a kérés az ütemezés módosításából kikerül: a kapcsolást kizárólag a felületen, a kártya gombjával, a védett útvonalon lehet elvégezni. Ez szándékos védelem – így egy beszélgetésbe csempészett utasítás sem tud automatikus, emberi jóváhagyás nélküli számlázást bekapcsolni. Kikapcsoláskor a felhatalmazás törlődik: újbóli bekapcsoláskor ismét azonosítókulcsos igazolás kell. > **Korlát, kimondva:** az azonosítókulcsos igazolás **egyszer, a bekapcsoláskor** történik. Az > automatikus futás **nem kér kiállításonként friss megerősítést**, és a felhatalmazás korát sem > vizsgálja: az egyszer megadott felhatalmazás határidő nélkül érvényes marad, amíg ki nem > kapcsolod. A Beállítások → Biztonság alatt bekapcsolt „megerősítés azonosítókulccsal” beállítás > **erre az útra nem terjed ki** (5.5). Ha egy automatikus kiállítás elhasal, **nincs néma bukás**: a hiba magyar mondatként az ütemezés sorára kerül (legfeljebb 500 karakter), és a kártyán olvasható. ### 12.2 Tömeges kiállítás Két, egymástól elkülönülő eset van: | Eset | Mit csinál | | --- | --- | | **Egy vevő, több bizonylat** | Ugyanannak a vevőnek több önálló, egysoros bizonylatot állít ki | | **Több vevő, vevőnként egy bizonylat** | Több vevőnek egy-egy önálló, egysoros bizonylatot állít ki | A folyamat mindkét esetben ugyanaz: először **előnézet** készül, ami kizárólag olvasás – semmit nem ír, semmit nem állít ki, tetszőleges alkalommal megismételhető. A tényleges kiállítást a kártya „Mind kiállítása” gombja indítja. A kötegre a következő korlátok és védelmek élnek: | Szabály | Érték | | --- | --- | | Kötegméret | Legfeljebb **50 tétel** kérésenként | | Gyakoriság | 5 kötegindítás / perc (a korlát-ellenőrzés kiesésekor is zár) | | Ismétlődés elleni védelem | Minden sor egyedi külső azonosítót kap (`bulk::`) – a köteg ismételt beküldése (dupla kattintás, oldal-újratöltés) nem hoz létre második éles bizonylatot | | Hibatűrés | Soronként: egy bizonylat hibája nem buktatja a többit. Az eredmény soronként vagy számlaszám, vagy magyar hibaüzenet, vagy „keret miatt kimaradt” jelzés | | Ingyenes csomag havi kerete | **5 éles számla / hó** – a kereten túllógó **számla**-tételek kimaradnak (a díjbekérőre ez a keret nem vonatkozik) | | Díjbekérő | Csak Pro és Ultra csomagban – a felületi korláton túl a szerveroldali útvonal is ellenőrzi | | Azonosítókulcsos megerősítés | Ha a fiókod biztonsági beállítása „mindig” vagy „értékhatár felett”, a tömeges kiállításhoz passkey-el kell igazolnod magad | ### 12.3 Közös biztonsági korlátok Minden kiállítási út – egyedi, tömeges és automatikus ismétlődő egyaránt – ugyanazon a két kemény korláton megy át: **egy számla bruttó összegplafonja** és a **napi darabszám-kvóta** (atomi számlálóval, tehát párhuzamos kérésekkel sem kerülhető meg). A beállítások leírása a 24.2 pontban. **Az azonosítókulcsos megerősítés (step-up) viszont nem közös:** az az egyedi és a tömeges kiállításon fut, az automatikus ismétlődő kiállításon nem (5.5 és 12.1). A blokkolt kiállítás magyar mondattal utasít el, és a Beállítások → Biztonság menüpontra utal. **A blokkolt kiállítás nem oszt sorszámot**, és nem hagy nyomot (8.6): a vázlat ilyenkor visszaáll megerősítésre váró (vagy hibás) állapotba, az újrapróbálkozás veszélytelen, és a napi kvótából lefoglalt hely is visszakerül. Tömeges kiállításnál a NAV-adatszolgáltatás **bizonylatonként külön** előjegyzés, és a beküldés a tranzakció lezárása után, bizonylatonként fut. ### 12.4 Korlátok – kimondva - Az ismétlődő ütemezés **a hónap 29., 30. és 31. napjára nem állítható be**. - Egy ütemezés = egy vevő + egy rögzített tétel-pillanatkép. A rendszer az összeget **nem indexálja, nem inflálja és nem arányosítja** (nincs időarányos részszámlázás): a mentett tételek és vevőadatok változatlanul mennek ki. - Tömeges kiállításnál **minden bizonylat egysoros**. Több tételsoros számlát a tömeges úton nem lehet készíteni – arra az egyedi kiállítás való. - A tömeges és az ismétlődő út a saját úton is **ugyanabból az egyetlen, folyamatos sorszámtartományból** oszt, mint az egyedi kiállítás. Köteg-külön tartomány nincs. - A tömeges és az automatikus ismétlődő úton **nem fut a szokatlan összegre figyelmeztető ellenőrzés** (9.11) – ezeken az utakon nincs emberi szem a kártyán, amelyik a figyelmeztetést elolvasná. - Automatikus módban a **NAV-beküldés** hibája nem jelenik meg az ütemezés hibamezőjében: a kiállítás ilyenkor sikeres volt, a beküldés pedig külön csatornán (újrapróbálkozó sor és külön jelzés) él tovább. ### 12.5 A te teendőd - Automatikus ismétlődő kiállításhoz: Ultra csomag, a kártyán az automatikus módra kapcsolás, és azonosítókulcsos igazolás. Ha kikapcsolod, újbóli bekapcsoláskor ismét igazolnod kell magad. - Ha egy köteg tételei a havi keret miatt maradtak ki: vagy csomagot váltasz, vagy a következő hónapban állítod ki őket. A kimaradt tételekről soronkénti visszajelzést kapsz. A napi automatikus futás 06:15 UTC-kor indul — magyar idő szerint reggel 7:15-kor (nyáron 8:15-kor) —, az esedékességet pedig a program a **magyar naptári nap** szerint számítja: a hónap választott napján reggel készül el a bizonylat. --- ## 13. Módosítás és érvénytelenítés **A saját (NAV-közvetlen) úton érvénytelenítés (sztornó) és helyesbítő (módosító) okirat is elérhető.** Ez a fejezet előbb a mögöttes lánc-modellt írja le, mert mindkét okirat helyessége ezen áll vagy bukik, majd a sztornó és a helyesbítés folyamatát, végül a korlátok pontos határát. ### 13.1 A lánc-modell A NAV-nál a bizonylatlánc **az adószámhoz kötődik, nem a programhoz**. Ezért a program a láncot a **gyökér-bizonylat sorszámával** azonosítja, nem belső azonosítóval – elvben így egy másik programmal kiállított számla is sztornózható lenne innen (a gyakorlati korlátról lásd a 13.6 pontot). Két lánc-szintű számlálót a **programnak** kell nyilvántartania, mert a NAV mindkettőt tőlünk várja: | Számláló | Szabály | Mi történik hiba esetén | | --- | --- | --- | | `modificationIndex` | Gyökerenként 1-től, hézagmentesen | Nem egyedi érték: blokkoló hiba; hézag: NAV-tájékoztatás (11250 INFO) | | `lineNumberReference` | A gyökér és minden korábbi okirat tételszámozását folytatja | Ütközés: `INVOICE_LINE_ALREADY_EXISTS` | A kiosztás egyetlen atomi adatbázis-művelet, a bizonylat rögzítésének **tranzakcióján belül**: a sorzár sorosítja a párhuzamos kéréseket, a visszagörgetés pedig a léptetést is visszavonja. A NAV ezen felül elvárja, hogy **egy gyökérre egyszerre csak egy okirat legyen úton**. Ezt a program **nem külön nyilvántartással** biztosítja – nincs „úton lévő okirat” jelölés a láncon –, hanem két, közvetett módon: (a) a lánc-számlálók kiosztása adatbázis-sorzárral sorosítja a párhuzamos kéréseket, és (b) az érvénytelenítés az eredeti számla állapotát atomi összehasonlítás-és-írással billenti át, tehát két egyidejű sztornó közül a második elakad („Ezt a számlát időközben már sztornózták”). **A program nem tippel.** Ha egy gyökérhez nincs felvett lánc, a kiosztó nem talál ki számlálókat, hanem elutasít: > „Ehhez a számlához (…) még nincs felvett számlalánc – külső gyökérnél előbb a NAV-ból > kell szinkronizálni, tippelni tilos.” Saját kiállításnál a lánc a számlával **egy tranzakcióban** jön létre: a következő módosítási index 1, a következő tételsor-hivatkozás pedig a számla tételszáma + 1. Az újbóli felvétel nem nullázza a számlálókat. Külső gyökér felvételekor a következő szabad tételsor-index a NAV lánc-kivonatából számolódik: a létrehozó (CREATE) elem legmagasabb tételszáma **és** az összes újonnan létrehozott tétel-intervallum végének maximuma + 1. A „legmagasabb tételszám” önmagában félrevezető lenne, mert az az adott dokumentum saját számozása (az interfész-specifikáció 1.8.3 pontja külön figyelmeztet erre). Sikeres sztornó után a lánc **lezárt** állapotba kerül. ### 13.2 A sztornó folyamata 1. **Kérés.** Megmondod, melyik számlát kell sztornózni. 2. **Megerősítő kártya.** A program megmutatja, mit fog tenni, és a te kattintásodra indul. (Gyakorisági korlát: 10 sztornó / perc; a korlát-ellenőrzés kiesésekor is zár.) 3. **Előfeltétel-ellenőrzés.** Lásd 13.3. 4. **Tükör felépítése.** A sztornó okirat tartalma a lánc jelenlegi állapotának teljes, ellentétes előjelű tükre. 5. **Rögzítés egy tranzakcióban.** Új, önálló sorszám a folyamatos tartományból; az eredeti számla `kiállított → sztornózott` állapotra vált; a lánc lezárul; a NAV-adatszolgáltatás előjegyződik; a művelet pedig bekerül az audit-naplóba. 6. **Beküldés.** A NAV-adatszolgáltatás a tranzakció lezárása **után** indul, és ha elakad, az újrapróbálkozó sor viszi tovább. ### 13.3 Előfeltételek - **Az eredeti számla adatszolgáltatásának le kell zárulnia (`done`).** Amíg nem, a program ezt mondja: „Az eredeti számla NAV-adatszolgáltatása még nem zárult le (DONE) – a sztornót csak utána lehet beküldeni. Próbáld pár perc múlva.” Ez a NAV sorrend-szabályából következik: lánc-okirat csak a gyökér elfogadása után mehet. - **Kell eltárolt, elfogadott adatszolgáltatás.** Ha nincs: „Ehhez a számlához nincs eltárolt NAV-adatszolgáltatás – a sztornóhoz előbb az eredeti beküldésének kell rendben lennie.” - **A számla nem lehet már sztornózott.** Az állapotváltás atomi összehasonlítás-és-írás, tehát két egyidejű sztornó közül a második ezt kapja: „Ezt a számlát időközben már sztornózták.” ### 13.4 Mi kerül a sztornóba, és mit lát a NAV A sztornó okirat forrása **nem a belső tételtábla, hanem a NAV által elfogadott, eltárolt számlaadat-XML**, visszaolvasva. Ennek oka gyakorlati: a belső tételtáblában nincs mentességi jogcím, nincs termékkód és nincs előlegbeszámítási adat – azokból hiánytalan tükör nem építhető. A tükör szabályai: - **A lánc nettó-hatásos tételsorai** szerepelnek benne negálva, folytatólagos lánc-indexszel. A nettó-hatásos halmaz a lánc tényleges, érvényben lévő tételsorait jelenti: ha egy korábbi helyesbítő okirat a lánc addigi sorait pontosan kioltotta és újraközölte, a kioltott párok nem szerepelnek újra – a sztornó így akkor is kicsi marad, ha a számlát többször helyesbítették. Idegen szerkezetű okiratnál a program a teljes tételtörténetet negálja (a régi, bizonyítottan összeg-helyes viselkedés). - **Az előjelfordítás szöveges** (a mínuszjel billentése), ezért a tükörben **semmilyen kerekítés nem történik**; fillérre pontos. A nulla előjeltelen marad. - **A mennyiség fordul, az egységár pozitív marad** (interfész-specifikáció 2.5.1). - A tételsor-művelet a 3.21-es interfész óta **kizárólag létrehozás (CREATE)** lehet – ezt a program típusszinten kényszeríti ki. - **A fejadat hatályosítva megy ki**: a lánc későbbi okirataiban közölt blokkok felülírják a gyökérét (teljes újraközlés szabálya). A **vevő adata a láncból öröklődik, nem a mai partnertörzsből** – így az utólag átírt partneradat nem ír felül egy már jelentett bizonylatot. - **A teljesítési dátum a lánc aktuális dátuma.** Nincs „a teljesítés nem eshet a kelte napjára” kényszer: az aznapi sztornó legitim. A NAV felé a következők mennek: | Mező | Érték | | --- | --- | | Művelet | `STORNO` (a `manageInvoice` borítékban, a számlaadat base64-elve) | | `originalInvoiceNumber` | A lánc **gyökerének** sorszáma | | `modificationIndex` | A láncból kiosztott, hézagmentes sorszám | | `modifyWithoutMaster` | A láncon nyilvántartott érték (nem tipp) | | `completenessIndicator` | `false` | | Tételsorok | Mindegyiken tételsor-hivatkozás (`lineNumberReference`) + `CREATE` művelet | A program **a beküldés előtt** elutasítja a hibás okiratot, magyar mondattal: létrehozó számlán nem lehet hivatkozás; módosító/sztornó okirat hivatkozás nélkül nem állítható ki; sztornó tételsor nélkül nem állítható ki; a módosító okirat sorszáma nem egyezhet a módosítottéval; a `modificationIndex` 1 és 1000 közötti egész szám; módosító okiratnál minden tételsornak hivatkoznia kell. A tükrözés maga is véd: a lánc első eleme nem lehet módosító okirat (módosító okiratot sztornózni tilos – a sztornó mindig a gyökérre hivatkozik), idegen gyökérre mutató láncelemet és tételsor nélküli láncot a program elutasít. A sztornó okirat a nyilvántartásban **önálló számlasor**: saját, a folyamatos tartományból kiosztott sorszámmal, negatív végösszegekkel, és a lánc-hivatkozás mezőivel. ### 13.5 Helyesbítő (módosító) okirat **A saját úton a helyesbítő számla elérhető.** A helyesbítő a hibás adatot sztornó nélkül javítja: a számla él tovább, a NAV pedig `MODIFY` műveletű módosító okiratot kap, amely a **különbözetet** rögzíti. Ugyanaz a számla **többször is helyesbíthető** – minden okirat a lánc mindenkori (a korábbi helyesbítésekkel együtt értett) állapotát javítja a kért végállapotra, hézagmentes `modificationIndex`-szel. A folyamat és a garanciák: - **Te a számla ÚJ, TELJES és HELYES tételsorát adod meg** (nem a különbözetet). A különbözetet a program képezi, a NAV által elfogadott, eltárolt számlaadat-XML-ekből – nem a te számításodból és nem a nyelvi modellből. - Az okirat szerkezete: a lánc **nettó-hatásos** tételsorai negálva + a helyes sorok pozitívan, egy okiratban. A nettó-hatásos redukció miatt az okirat mérete a sokadik helyesbítésnél is állandó marad (nem nő a lánc hosszával). - **Ha csak a fejadat változik** (teljesítési dátum, fizetési határidő, fizetési mód), a program tételsor nélküli, áfakulcsonként nullás összesítőjű fejadat-módosítót küld – a tételsorok érintetlenül maradnak. - **Ha a vázlat semmiben nem tér el** a számla mostani állapotától, a kiállítás megáll: „nincs mit helyesbíteni”. - A fejadat (vevő, teljesítés, fizetési adatok) a **láncból öröklődik**; csak az változik, amit kifejezetten módosítasz. - A pénznem nem helyesbíthető – ahhoz sztornó és új számla kell. Egyszerűsített vagy gyűjtő típusú gyökér-számlát a program nem helyesbít (a szerkezetük eltér), ott is a sztornó a járható út. - Helyesbítő vagy sztornó **okirat önmagában nem helyesbíthető** – a javítást mindig az eredeti (gyökér-)számlán kell kérni; a hibaüzenet meg is nevezi azt. - A megerősítés ugyanúgy a kártyán történik, mint a kiállításnál és a sztornónál; a NAV-adatszolgáltatás automatikus. A módosítás–érvénytelenítés körében ez a helyzet: | Funkció | Állapot | | --- | --- | | Sztornó | Elérhető | | Helyesbítő (módosító) okirat | Elérhető | | Előlegszámla és a hozzá tartozó végszámla | **Nem érhető el** | | Díjbekérőből végszámla | Elérhető | A nem elérhető funkciók teljes listája – az indoklással és a járható alternatívával – a **26.1 pontban** áll. ### 13.6 Korlátok – kimondva - **Technikai érvénytelenítést (`manageAnnulment`) a program nem küld be.** Az adatszolgáltatás-nyilvántartásban létezik ilyen művelettípus, de a beküldő ág szándékosan elutasítja, és az újrapróbálkozó sor is kihagyja (18.9). - **NAV-adatszolgáltatásból importált (nem itt kiállított) számla innen nem sztornózható és nem helyesbíthető** – ezekről csak a NAV összesítő adatai állnak rendelkezésre. - **Csak a saját úton kiállított számla sztornózható/helyesbíthető a saját úton.** Külső vagy migrált gyökér láncának NAV-ból való felvételére nincs eljárás a programban: a külső bizonylatot a kapuk már a szándék jelzésekor elutasítják, felvett lánc nélkül pedig a kiosztó is elutasít. - **Egy gyökéren egyszerre csak egy okirat lehet úton.** Amíg egy helyesbítő vagy sztornó NAV-visszaigazolása nem érkezett meg, a következő okirat (újabb helyesbítő vagy sztornó) nem indítható – a program ezt a szándék jelzésekor mondja meg. - **A sztornó nem vonható vissza.** A lánc állapota egyirányú: nyitott → lezárt. A lánc újranyitására nincs funkció. - **Egyszerűsített és gyűjtőszámla nem helyesbíthető** (a helyesbítő okirat más szerkezetű bizonylat lenne) – sztornó + új számla a járható út; a sztornójuk viszont működik (9.13). - **Előlegszámla és végszámla TÉTELEI nem helyesbíthetők** – az előleg-jelölés és a beszámítási hivatkozás veszne el az újraközölt sorokról. A fejadat-helyesbítés (dátum, fizetési mód) ezeken is elérhető (9.13). - **Ha az okirat NAV-beküldése elhasal, a helyi állapot már megváltozott** (sztornónál az eredeti számla sztornózott, a lánc lezárt; helyesbítőnél az okirat-sor létrejött). Ilyenkor nem a kiállítást kell megismételni, hanem a beküldést – ezt az újrapróbálkozó sor automatikusan viszi, illetve kézzel is indítható. - **A NAV által tartalmilag elutasított (`aborted`) adatszolgáltatás újraküldését a program szándékosan megtagadja**: az elutasított tartalom változatlan újraküldése ugyanazt az elutasítást hozná. Elutasított **lánc-okiratnál** (helyesbítő/sztornó) a program a helyi állapotot magától rendezi: az okirat számla-sora „törölt” állapotra vált, a lánc-számlálók visszaállnak (nem marad végleges hézag a `modificationIndex`-ben), sztornónál pedig az eredeti számla és a lánc is visszaáll élőre – a művelet a hiba javítása után újra kérhető. Elutasított **létrehozó** (CREATE) adatszolgáltatásnál a járható út változatlanul a sztornó + új, helyes számla. - A lánc-nyilvántartásban létezik egy összeg-állapot mező, de a program **sehol nem írja és nem olvassa**: a lánc pénzügyi állapotát mindig az eltárolt, NAV-nak jelentett XML-ekből számoljuk. ### 13.7 A te teendőd - **Hibás számlánál** válaszd meg a javítás útját: ha csak egy adat hibás (összeg, tétel, dátum), kérj helyesbítő számlát – a számla él tovább, a NAV a különbözetet kapja. Ha az egész számla érvénytelen, sztornózz, és állítsd ki újra a helyes adatokkal. - **Okirat (sztornó/helyesbítő) előtt** meg kell várni az eredeti számla NAV-visszaigazolását. A program szól, ha még nem érkezett meg. - **Elakadt beküldésnél** kérdezd le az adatszolgáltatás állapotát, és ha átmeneti hiba volt, indítsd újra. Ha a NAV elutasította (`aborted`): létrehozó számlánál sztornózz és állíts ki új, helyes bizonylatot; lánc-okiratnál a program a helyi állapotot magától rendezi, és a művelet a hiba javítása után újra kérhető (13.6). **A megerősítő kártya szövege pontosan ezt a sorrendet mondja.** A sztornó kártyáján ez áll: > „A sztornó végleges, és **a NAV-adatszolgáltatás azonnal indul**. A számla helyett egy > érvénytelenítő bizonylat keletkezik – ez a hibás számla javításának szabályos, NAV által > elfogadott folyamata.” A „megindul” és nem a „megtörtént” a helyes állítás: a beküldés a bizonylat létrejötte **után**, külön lépésben megy ki, és az adatszolgáltatás a NAV visszaigazolásával teljesül (7.6, 16.3). A kártya **ezen a ponton** tehát a folyamatban lévő lépést jelzi, nem befejezett tényt állít – a tényleges állapotot az adatszolgáltatás lekérdezésével látod (16.8). Ez a magyar felület megerősítés előtti mondatára igaz; a sztornózás közbeni és utáni feliratok, valamint az angol felület továbbra is befejezett tényként fogalmaznak – a korlátot a **7.6 pont** mondja ki. **Korlát, kimondva:** a **külső számlázós időszakból származó** számla a saját úton **nem sztornózható** – az érvénytelenítést abban a rendszerben (vagy a NAV Online Számla felületén) kell intézni, amelyben a számla keletkezett (1.4). --- ## 14. Áfa, kerekítés, deviza ### 14.1 Az áfa-elbánás nem puszta százalék A NAV adatszolgáltatásában az áfa-elbánás hét, egymást kizáró ág egyike. A program mindegyiket ismeri az adatszolgáltatás előállításánál: | Ág | Jelentés | | --- | --- | | Áfakulcs (`PERCENTAGE`) | Százalékos adómérték | | Áfatartalom (`CONTENT`) | Egyszerűsített számlán az áfatartalom | | Adómentes (`EXEMPT`) | Mentességi jogcímmel | | Áfa hatályán kívüli (`OUT_OF_SCOPE`) | Jogcímmel | | Belföldi fordított adózás (`DOMESTIC_REVERSE`) | – | | Különbözeti adózás (`MARGIN`) | Utazási iroda / használt cikk / műtárgy / régiség | | Áfa tárgyi hatályán kívüli (`NO_VAT`) | – | ### 14.2 Elfogadott áfakulcsok A NAV normál (és gyűjtő-) számlán a következő kulcsokat fogadja el: **0%, 5%, 7%, 12%, 18%, 27%**. Az adatszolgáltatásban a program mindig tizedes törtként adja meg őket (27 → `0.27`). Ha nem elfogadott kulcsot adsz meg, a program **a kiállítás előtt** elutasít: > „A ${százalék}%-os áfakulcsot a NAV nem fogadja el belföldi számlán. Elfogadott kulcsok: > 0%, 5%, 7%, 12%, 18%, 27% – vagy adómentes jogcím (pl. AAM, TAM).” A program belső áfa-modulja ennél sokkal több (36) numerikus kulcsot ismer (19, 20, 21, 23, 25,5, 5,5 stb.), **de azok külföldi áfakulcsok, és a NAV egyiket sem fogadja el.** Ezért a saját úton a szűkebb halmaz az irányadó. ### 14.3 Mentességi és hatályon kívüli jogcímek | Kód | NAV-besorolás | Jelentés | | --- | --- | --- | | AAM | Adómentes | Alanyi adómentes | | TAM | Adómentes | Tárgyi adómentes | | KBAET | Adómentes | Közösségen belüli adómentes termékértékesítés | | KBAUK | Adómentes | Közösségen belüli új közlekedési eszköz értékesítése | | EAM | Adómentes | Adómentes termékexport harmadik országba | | NAM | Adómentes | Egyéb nemzetközi ügylethez kapcsolódó adómentesség | | ATK, TAHK | Hatályon kívül | Áfa tárgyi hatályán kívül | | EUFAD37 | Hatályon kívül | Áfa tv. 37. § szerinti, másik tagállamban fordítottan adózó ügylet | | EUFADE | Hatályon kívül | Másik tagállamban teljesített, fordítottan adózó ügylet | | EUE | Hatályon kívül | Másik tagállamban teljesített, nem fordítottan adózó ügylet | | HO | Hatályon kívül | Harmadik országban teljesített ügylet | | F.AFA | Belföldi fordított adózás | – | **Kétértelmű kódot a program nem tippel meg, hanem visszakérdez.** Az `EUT`, `EUKT`, `EU`, `EUK`, `MAA`, `K.AFA` és `AKK` kódnál ezt kapod: > „A(z) „…” áfakód nem képezhető le egyértelmű NAV-jogcímre – pontosítsd a tétel jogcímét > (pl. EUFAD37 / EUE / KBAET / HO), vagy különbözeti adózásnál add meg a séma fajtáját.” ### 14.4 Determinisztikus áfa-ellenőrzések a beküldés előtt A 2025. szeptember 15-e óta szigorúbb NAV-validáció blokkoló hibáinak megelőzésére a program a beküldés előtt maga ellenőrzi, és magyar mondattal utasít el: - Mentes vagy hatályon kívüli tételnél az áfa összege csak nulla lehet. - Egyszerűsített számlán áfatartalom kell, normál számlán áfakulcs. - Belföldi fordított adózásnál a vevő csak belföldi adóalany lehet, magyar adószámmal. - `KBAET`, `EUFAD37` és `EUFADE` jogcímnél a vevő áfa-státusza csak „egyéb” (közösségi adószámos külföldi) lehet. - `KBAUK` jogcímnél a vevő nem lehet belföldi adóalany. **Az áfakulcsonkénti összesítőt a program számolja.** A külső számlázós időszakban ezt a szolgáltató végezte; a saját úton ez a mi felelősségünk, és a NAV blokkoló hibával utasítja el az adatszolgáltatást, ha az összesítő nem jön ki a tételekből. A csoportosítás kulcsa **nem a százalék, hanem a teljes áfa-elbánás**: a 0%-os mentesség és a 0%-os fordított adózás nem ugyanaz a csoport. ### 14.5 Kerekítés | Hol | Szabály | | --- | --- | | Vázlat, tétel-szinten | HUF: **0 tizedes (egész forint)**; minden más pénznem: **2 tizedes** | | NAV-adatszolgáltatás | **Nullától elfelé** (half-up away from zero) | | Összegzés | Egész fillérben (a lebegőpontos összegzés fillérrel elcsúszhatna) | | Sztornó | **Nincs kerekítés** – az előjelfordítás szöveges | | Számlakép (PDF) | Megjelenítésben legfeljebb 2 tizedes; **a jelentett érték változatlan** | A „nullától elfelé” nem elméleti finomság: a szokásos programnyelvi kerekítés a plusz végtelen felé kerekít, ezért negatív összegnél rossz eredményt ad (−12 713 464,5 esetén −12 713 464-et a helyes −12 713 465 helyett). Ez sztornó és módosító okiratoknál él, ahol az összegek negatívak – és a NAV által elfogadott referenciákkal való összevetés során ez a hiba 21 számlán okozott 1 filléres eltérést, mielőtt kijavítottuk. Ha a vázlatban kifejezetten megadsz nettó, áfa vagy bruttó értéket, a program azt tiszteletben tartja, és nem számolja újra. Az összegek végig szövegként utaznak; számolás csak ott történik, ahol elkerülhetetlen (forintosítás, áfakulcsonkénti összesítő). ### 14.6 Deviza és MNB-árfolyam A program **29 pénznemet** kezel: HUF, EUR, USD, GBP, CHF, AUD, AED, BGN, BRL, CAD, CNY, CZK, DKK, HKD, HRK, ISK, JPY, NOK, NZD, PLN, RON, RSD, RUB, SEK, SGD, THB, TRY, UAH, ZAR. A „Ft” és „FT” alak HUF-ra normalizálódik; ismeretlen kódnál magyar hibaüzenetet kapsz. Az árfolyam **az MNB napi középárfolyama**, közvetlenül az MNB webszolgáltatásából. Részletek: | Szempont | Szabály | | --- | --- | | Forrás | MNB árfolyam-webszolgáltatás (`GetExchangeRates`) | | Hétvége, ünnep | 7 nap visszatekintés: a kért napnál nem későbbi, legfrissebb publikált nap | | HUF | Mindig 1, hálózati hívás nélkül | | Forrás-hiba | **Nem adunk vissza némán 1,0-t** – a kiállítás elmarad, hibaüzenettel | | Józansági sáv | 0,01 – 100 000 HUF/egység (a nyilvános HTTP-csatorna miatt, védelem mélységben) | | Gyorsítótár | Egy (pénznem, nap) pár publikálás után nem változik, ezért folyamat-szinten gyorsítótárazott | | Melyik nap? | **A kelte (a mai) napja** – nem a teljesítés napja | | Kerekítés | Az egy egységre jutó árfolyam **6 tizedesjegyre kerekítve** (lásd alább) | **A 100-as és 1000-es egységre jegyzett devizák kezelve vannak.** Az MNB a kis értékű devizákat nem 1, hanem 100 vagy 1000 egységre jegyzi (pl. JPY, HUF-ban kifejezve). Az egy egységre jutó árfolyamot ezért osztással kell képezni, és az osztás kettes számrendszerű maradékot hagy: `99,99 / 100` a gépi számábrázolásban `0,9998999999999999`. A program ezért az **egy egységre jutó árfolyamot 6 tizedesjegyre kerekíti** – pontosan annyira, amennyit a NAV `InvoiceData` sémája elfogad. Így a 100/1000 egységre jegyzett devizák a saját úton **ugyanúgy számlázhatók**, mint a többi: a kerekítés minden valós középárfolyamot pontosan visszaad. Az árfolyam-lekérés a bizonylatot rögzítő tranzakción **kívül** fut: a tranzakcióban csak adatbázis-írás és számolás történik. A program a beküldés előtt ellenőrzi, hogy a pénznem pontosan három nagybetű, az árfolyam pozitív, HUF-nál az árfolyam kizárólag 1 lehet, és az árfolyamnak **legfeljebb 6 tizedesjegye** lehet (a NAV sémája ennyit enged). Ugyanez a 6 tizedes korlát él az előlegbeszámítás és a gyűjtőszámla-tétel árfolyamára is. Devizás számlán minden összeg **párban** megy ki: az eredeti pénznemben és forintban is. A számlaképen a pénznem mellett az árfolyam is szerepel, ha az nem HUF. ### 14.7 Korlátok – kimondva - **Az árfolyam a kelte napjára szól, nem a teljesítés napjára.** Ha visszamenőleges teljesítési dátumot adsz meg, az árfolyam akkor is az aznapi. (A kelte magyar idő szerinti naptári nap – lásd 8.8.) - **A kimenő számla árfolyama nem külön oszlopban él a számlasoron**, hanem az eltárolt NAV-adatszolgáltatás XML-jében és a lánc során – a számlaképre is onnan kerül. - **A saját kiállítási út alapból normál (`NORMAL`) számlát küld**, kifejezett kérésre pedig egyszerűsített (`SIMPLIFIED`, áfatartalom szerinti) vagy gyűjtőszámlát (`AGGREGATE`) is – a feltételeket a 9.13 pont írja le. Ebből következően a saját úton **nem érhető el a különbözeti adózás (`MARGIN`) és a `NO_VAT` besorolás.** - A `MARGIN` és a `NO_VAT` ághoz **nincs is leképezés** a tétel-áfakódról: ilyen kódnál a program elutasít. - A 0,2 és 0,25 áfakulcs (régi, 2013 előtti teljesítésű számlák sztornója) nincs az engedélylistán. Ez a sztornót nem akadályozza: a sztornó a tükrön át megy, ott az eredeti kulcs öröklődik, nem a leképező futásán. - A kiállítói **alanyi adómentesség jelölése** az adatszolgáltatásban technikailag létezik, de a program **nem tölti ki**: a kiállítói törzsadatot a NAV adószám-lekérdezése adja, ami áfakódot, megyekódot, nevet és címet ad, alanyi mentességi jelölést nem (lásd T-37). ### 14.8 A te teendőd - Belföldi számlán ne adj meg külföldi áfakulcsot – a program elutasítja. - Kétértelmű jogcím-kódnál (EUT, EU, MAA, K.AFA stb.) pontosítanod kell a jogcímet. - Devizás számlánál, ha az MNB árfolyam-szolgáltatása nem elérhető, a kiállítás nem történik meg. Ez szándékos: hibás (1,0-s) árfolyammal küldött adatszolgáltatás rosszabb, mint a késés. --- ## 15. Számlakép és kézbesítés ### 15.1 Hogyan készül a számlakép A saját úton a számlaképet a titkár.ai **saját, magyar nyelvű PDF-sablonja** állítja elő. A NAV saját megjelenítő sablonja **nem része a terméknek** – a NAV FO-sablonja a lábában kimondja magáról: „Ez a dokumentum a bizonylat adattartalmának standard képi megjelenítése. Ez az dokumentum nem a számla.” Vevőnek kiküldhető számlaképnek tehát alkalmatlan. **A számlakép forrása az eltárolt, NAV-nak jelentett és általa elfogadott számlaadat-XML**, visszaolvasva. Ez a legfontosabb tulajdonsága: a kép nem egy második, párhuzamos adatforrásból épül, hanem pontosan abból, amit a NAV-nak jelentettünk – **a kettő nem tud szétcsúszni**. Ha egy számlához nincs eltárolt adat, a program nem gyárt „valamilyen” képet, hanem elutasít: „Ehhez a számlához nincs eltárolt számla-adat, a PDF nem állítható elő.” Ha az adat nem olvasható vissza: „A számla eltárolt adata nem olvasható vissza.” A renderelés **determinisztikus**, és ez itt korrektségi követelmény, nem kényelmi szempont: nincs futásidejű hálózati letöltés, nincs böngésző-motor, a betűtípusok a programmal együtt szállítottak. (A magyar elválasztás kikapcsolt, mert az alapértelmezett angol mintakészlet hibásan törné a magyar szavakat.) ### 15.2 Mi látszik a számlaképen Az Áfa tv. 169. §-a szerinti kötelező adattartalom jelenlétét **automatikus ellenőrzőlista-teszt őrzi**, nem szemrevételezés: **12 teszt** fut a modellre (kelte és sorszám; a kiállító neve, címe, adószáma; a vevő adatai – külön eset a magánszemély vevő pillanatképére; tétel megnevezése, mennyisége, mértékegysége; teljesítés időpontja, adóalap és egységár; adómérték és áthárított adó kulcsonkénti bontásban; mentességi jogcím lábjegyzete; sztornó-hivatkozás; pénznem és árfolyam; sablon-verzió), továbbá **3 renderelési próba**: 1 tételes, 40 tételes (többoldalas) és sztornó-változat. A képen szerepel: a dokumentum címe („Számla”, sztornónál **„Sztornó számla”**), a sorszám, sztornónál az „Érvénytelenített számla: ” hivatkozás, a Kiállító és a Vevő blokk (adószám, közösségi adószám, bankszámla), a Kelt / Teljesítés / Fizetési határidő / Fizetési mód / Pénznem (és HUF-tól eltérő pénznemnél az árfolyam), a tételtáblázat (Megnevezés, Mennyiség, Egység, Egységár, Áfa, Nettó, Bruttó), az áfakulcsonkénti összesítő, a „Fizetendő” bruttó összeg, a mentességi jogcímek lábjegyzetei, valamint minden oldalon állandó lábléc (a kiállító neve és adószáma, illetve „ · N/M. oldal”). **A számlaképen NAV-címer és „NAV” felirat szándékosan nem szerepel** – a fejlécben a titkár.ai jelölés áll. A PDF metaadataiban a cím a bizonylat típusa és száma, a szerző a kiállító neve, az előállító pedig a titkár.ai a sablon-verzióval. **Magánszemély vevőnél** a NAV-nak küldött adatszolgáltatás szándékosan névtelen (Áfa tv. 10. számú melléklet), a számlán viszont a vevő neve és címe kötelező (169. § e)). Ezért ezeknél a bizonylatoknál a név és a cím a **számlasor kiállításkori pillanatképéből** kerül a képre – és csak akkor, ha az adatszolgáltatásban valóban nincs vevőadat. A pillanatkép azért kell, mert a partnertörzs utólag átírható, a kiállított bizonylat viszont nem. **A pillanatkép nem lehet üres:** a program magánszemély vevőnél is megköveteli az irányítószámot és a települést, és enélkül a kiállítás elbukik (9.1). Ezért **a saját úton kiállított számla képén a vevő címe mindig szerepel** – a 169. § e) szerinti kötelező adat nem hiányozhat róla. ### 15.3 Mi garantálja, hogy a kép a jelentett adattal azonos Három, egymást erősítő elem: 1. **Közös forrás.** A kép és a NAV-adatszolgáltatás ugyanabból az XML-ből származik. Nincs második adatút, amin eltérés keletkezhetne. 2. **Sablon-verzió.** A sablon verziószámmal azonosított (jelenleg `v1`), és a verzió ráíródik a bizonylatra. A régi sablon-verziók a programban maradnak, így utólag is előállítható az akkori kép. 3. **Lenyomat (`pdf_sha256`).** Az **első** renderelés SHA-256 lenyomata és a sablon verziója a számlasorra kerül, és későbbi rendereléskor **nem íródik felül**. Eltérés tehát csak a sablon-verzió tudatos léptetésével keletkezhet. Ellenőrzéskor ez a két adat (`pdf_sha256` és `pdf_template_version`) a bizonyíték arra, hogy az újragenerált számlakép azonos a kiküldöttel. ### 15.4 Hozzáférés és kézbesítés **Letöltés.** A számlakép a beszélgetésben kapott hivatkozással érhető el. A letöltés bejelentkezett munkamenethez kötött, és a program ellenőrzi, hogy a számla a te fiókodhoz tartozik-e. A fájl nem gyorsítótárazódik. **E-mail.** A kiküldés külön, megerősítés-köteles lépés: **a kiállítás nem küld ki automatikusan levelet.** Előbb előnézetet kapsz (kinek, milyen tárggyal, milyen kísérőszöveggel megy), és a te jóváhagyásodra indul. | Szempont | Szabály | | --- | --- | | Csatolt PDF | Ugyanabból az eltárolt, NAV-nak jelentett adatból készül, mint a letöltésé | | Címzett feloldása | Kifejezetten megadott cím > (saját másolatnál a fiók tulajdonosának címe) > a partnerhez mentett e-mail-cím | | Ha nincs cím | A küldés nem történik meg, magyar hibaüzenetet kapsz | | Csatolmány neve | `.pdf` | | Feladó | `titkár.ai ` | | Tárgy | „Számla – ”, saját másolatnál „Számla (másolat) – ” | | Napi keret | **200 kimenő levél / fiók / nap**; a keret felett a küldés nem történik meg | **Ismétlődés elleni védelem.** A levélnek idempotencia-kulcsa van (fiók, számlaszám, címzett és a levél tartalmi ujjlenyomata), így ugyanaz a levél ugyanannak a címzettnek kétszer nem megy ki. A **kifejezett újraküldésnél** szándékosan nincs kulcs – különben a levélküldő szolgáltatás 24 órán át kiszűrné, és az „Újraküldés” gomb hatástalan lenne. **Kézbesítés-követés.** A levélküldő szolgáltatás azonosítója eltárolódik, így a kézbesítés vagy a visszapattanás visszavezethető az adott számlára. E nélkül a küldés utáni lánc vak lenne: egy elgépelt vevői cím némán elnyelődne. Minden kiküldés az audit-naplóba kerül. **Átutalási QR-kód** csak a vevőnek szóló levélben, és csak akkor kerül a levélbe, ha minden feltétel teljesül (Pro vagy Ultra csomag, HUF, még nem fizetett számla, megadott bankszámla, engedélyezett szabvány). Bármelyik feltétel hiányában a levél QR nélkül, egyébként változatlanul kimegy. **A funkció jelenleg ki van kapcsolva**, mert a szabvány regisztrált aggregátort kíván (20.3). **Az adatszolgáltatás nem maga az e-számla.** A bizonylat elektronikus megjelenésű jelöléssel megy a NAV felé, és az adatszolgáltatás nem teljes adattartalmú – az adatszolgáltatás és a számla két külön dolog. ### 15.5 Korlátok – kimondva - **A díjbekérő képe MÁS forrásból épül, mint a számláé.** A díjbekérőhöz nem tartozik NAV-adatszolgáltatás, tehát eltárolt XML sincs, amiből a kép épülhetne: a bizonylat a saját nyilvántartás sorából és tételeiből áll össze, a kiállító neve, címe és adószáma pedig a megjelenítéskor, a NAV törzsadatából. A kép a sorszáma alatt ki is mondja: „Nem számla — áfa levonására nem jogosít.”, a záradéka pedig megadja, hova és milyen közleménnyel várjuk az utalást, és hogy a számla a fizetés beérkezése után készül el. - **Díjbekérőhöz nem tárolunk lenyomatot (SHA-256).** Az a SZÁMLA képének bizonyítéka — azé, hogy a kép a NAV-nak jelentett tartalommal azonos. A díjbekérő kiállítói blokkja két megjelenítés között jogszerűen is változhat (pl. cégnév-változás), így egy itt tárolt lenyomat csak hamis bizonyosságot adna. - **A PDF-fájlt nem tároljuk.** Minden letöltéskor és minden kiküldéskor újragenerálódik; tartósan csak a SHA-256 lenyomat és a sablon-verzió marad meg. A megőrzést tehát nem a fájl, hanem a determinizmus és a lenyomat biztosítja. - **A sablon kizárólag magyar nyelvű.** A számlakép minden felirata magyar; idegen nyelvű számlakép a saját úton nincs. A vázlaton beállított nyelv a saját PDF-re nincs hatással. - **A lenyomat írása „legjobb szándékú”**: ha az adatbázis-írás elhasal, a hiba elnyelődik, tehát előfordulhat, hogy egy számlához nincs eltárolt lenyomat anélkül, hogy erről értesülnél. - **A számlaképen nincs elektronikus aláírás és nincs időbélyeg.** A PDF önmagában nem minősül hitelesített elektronikus dokumentumnak (25.2). - **A számlakép nem jelenít meg**: fizetettségi állapotot, szabad szöveges megjegyzést, szállítólevél-hivatkozást és tétel-szintű megjegyzést. - **A NAV-adatszolgáltatásból importált (nem itt kiállított) számlának nincs PDF-je** – ezekhez csak a NAV összesítő adatai érhetők el. ### 15.6 A te teendőd - A számlaképet bejelentkezett munkamenetből, a beszélgetésben kapott hivatkozással nyisd meg vagy töltsd le. - A vevőnek küldéshez mentsd el a partner e-mail-címét, vagy add meg a címet a küldéskor. Az előnézeten látod, kinek megy a levél. - Ellenőrzéskor a `pdf_sha256` és a `pdf_template_version` a bizonyíték arra, hogy az újragenerált számlakép azonos a kiküldöttel. **Korlát, kimondva:** a dokumentáció **nem állítja, hogy az újragenerált PDF bitre azonos** a korábban kiadottal – a PDF-motor frissítése a sablonverzió változása nélkül is megváltoztathatja a bájtokat. Az azonosság bizonyítéka nem az újragenerálás, hanem az első generáláskor eltárolt **SHA-256 lenyomat és sablonverzió**: a kiküldött példány ezekkel vethető össze, a bizonylat adattartalma pedig a tárolt XML-ből mindenkor igazolható. *(A számlakép előállíthatósága az eltárolt XML megőrzésén múlik; a megőrzési idő kérdését a T-30 tétel tartalmazza – lásd 25.5.)* --- ## 16. NAV-adatszolgáltatás (13/A. §) Ez a fejezet a saját, NAV-közvetlen kiállításra vonatkozik: amikor a titkár.ai maga állítja ki a számlát, és maga szolgáltat adatot a NAV Online Számla rendszerébe. A 2026. augusztus 8. előtt, külső számlázón kiállított számlák adatszolgáltatását az a program végezte, és arról az ő dokumentációja szól – az alábbiak azokra nem alkalmazandók. ### 16.1 Az alapelv: a kiállítás és az adatszolgáltatás két külön lépés A számla a 8. § (6) szerinti **lezáráskor jön létre** – nálunk, a saját nyilvántartásban (7.4). A NAV felé menő adatszolgáltatás ettől **elváló, aszinkron lépés**, és szándékosan nem része a kiállítás adatbázis-tranzakciójának. A kiállítás egyetlen tranzakcióban rögzíti a sorszámot, a számlát, a tételsorokat, a számlaláncot és az adatszolgáltatási tételt `pending` (beküldésre vár) állapotban. A NAV-hívás csak ezután, a mentés véglegesítése **után** indul. > **Ez azt jelenti: a NAV kiesése sosem akadályozza meg, hogy számlát állíts ki.** A jogszabály > is így épül fel – a 13/B. § (3) épp azért ad 24 órát az adatszolgáltatásra az akadály > elhárultától, mert a NAV elérhetetlensége nem béníthatja meg a számlázást. Kiállításkor a NAV-nak szóló `InvoiceData` XML a tranzakción belül felépül (`CREATE` művelettel), és **szó szerint eltárolódik**, a hozzá tartozó **SHA3-512 lenyomattal** együtt. Ez a tárolt XML később három dolgot szolgál ki: az ismételt beküldést (13/A. § (4)), a számlaképet (PDF) és a 17. fejezet szerinti adóhatósági ellenőrzési adatszolgáltatást (11/A. §). **A díjbekérőhöz nincs adatszolgáltatás, és nem is kell** – a díjbekérő nem számla. Díjbekérő kiállításakor sem XML nem képződik, sem adatszolgáltatási tétel nem keletkezik. ### 16.2 Hogyan történik a beküldés A tényleges beküldés két NAV-hívásból áll: 1. **`tokenExchange`** – a rendszer egyszer használatos beküldési tokent kér a NAV-tól, az XML cserekulcsod segítségével; 2. **`manageInvoice`** – a számla adata egy kötegben kimegy a NAV-hoz. Sikeres átvételkor a tétel `submitted` állapotba kerül, és eltárolódik a NAV **tranzakció-azonosítója** (`transactionId`) és a beküldés időbélyege. A NAV-hívások időkorlátja **30 másodperc**. Hálózati vagy NAV-oldali hiba esetén a hívás nem próbálkozik újra azonnal – a tétel `failed` állapotba kerül, és a 18. fejezet szerinti újraküldési sor viszi tovább. ### 16.3 Mikor teljesült az adatszolgáltatás **A beküldés önmagában nem teljesítés.** A `submitted` állapot csak annyit jelent, hogy a NAV átvette a köteget. A 13/A. § (3) szerint az adatszolgáltatás **kizárólag a NAV sikeres visszaigazolásával teljesül** – ezért a rendszer a beküldött tételek feldolgozási állapotát végállapotig lekérdezi (`queryTransactionStatus`). A NAV válaszában: - `RECEIVED`, `PROCESSING`, `SAVED` – a feldolgozás még folyamatban van, ez nem végállapot; - **`DONE`** – a NAV feldolgozta és visszaigazolta: **ekkor teljesült az adatszolgáltatás**; - **`ABORTED`** – a NAV a feldolgozást megszakította: az adatszolgáltatás **nem teljesült**. A `DONE`-on belül a rendszer még egy megkülönböztetést tesz (a NAV interfész-specifikációjának megfelelően): teljesített az az adatszolgáltatás, amelyre `invoiceStatus = DONE`; **üzletileg helyes** pedig az, amelynél emellett a válasz nem tartalmaz üzleti validációs üzenetet. > A **`DONE` + figyelmeztetés** eset jogilag **teljesített** adatszolgáltatás, de a 13/A. § (5) > szerint javítandó tartalomra utal. Ezt a rendszer külön mezőben tartja nyilván (nem > hibaként), és megmutatja, ha rákérdezel. Érdemes komolyan venni: 2025. szeptember 15-én épp az > évekig figyelmen kívül hagyott figyelmeztetésekből lettek blokkoló hibák. Blokkoló szintnek a rendszer az `ERROR` és a `CRITICAL` üzeneteket tekinti (a technikai üzenetek `CRITICAL`/`ERROR`, az üzletiek `ERROR`/`WARN`/`INFO` szintűek lehetnek – mindkét blokkoló szintet kezeli). ### 16.4 Az adatszolgáltatás állapotai | Állapot | Mit jelent | Teljesült? | Magától rendeződik? | |---|---|---|---| | `pending` – „beküldésre vár” | A tétel létrejött, de még nem ment ki a NAV-hoz | nem | igen, az újraküldési sor viszi | | `sending` – „a beküldés épp fut” | A küldés elindult; a tétel foglalt, hogy kétszer ne mehessen ki | nem | igen (lásd alább) | | `submitted` – „beküldve, a NAV feldolgozza” | A NAV átvette, van tranzakció-azonosító | **még nem** | igen, a státusz-lekérdezés lezárja | | `done` – „a NAV visszaigazolta” | `invoiceStatus = DONE` | **igen** (13/A. § (3)) | – | | `aborted` – „a NAV ELUTASÍTOTTA” | Blokkoló tartalmi hiba, a NAV megszakította | **nem** | **NEM – cselekedned kell** | | `failed` – „a beküldés nem sikerült” | A küldés maga hasalt el (hálózat, üzemzavar) | nem | igen, az újraküldési sor viszi | **A `sending` a kétszeres beküldés elleni védelem.** A beküldést atomi foglalás előzi meg: a tétel `pending`/`failed` állapotból `sending`-be kerül, és onnantól sem a kiállítás utáni azonnali beküldés, sem az újraküldési sor nem nyúl hozzá. Enélkül ugyanaz a számla kétszer mehetne ki, a másodikra kapott `INVOICE_NUMBER_NOT_UNIQUE` pedig hamis „elutasítva” állapotot írna egy valójában teljesült adatszolgáltatásra. Ha a küldés úgy szakad félbe, hogy **nem tudjuk, eljutott-e a NAV-hoz** – a válasz időtúllépésbe fut vagy a kapcsolat megszakad, illetve a NAV már visszaigazolta, de a saját mentésünk hasal el –, a tétel `sending`-ben marad. **Ilyenkor újraküldeni tilos**: a beküldés lehet, hogy megtörtént, és a második ugyanarról a számláról duplikált adatszolgáltatás lenne. **30 perc után a rendszer a NAV-ot kérdezi meg** a bizonylat lánc-kivonatával, hogy bement-e: ha a NAV ismeri, a tétel `done` lesz (a nyugtát vesztettük el, nem az adatszolgáltatást), ha nem ismeri, `failed`, azaz vissza az újraküldési sorba. Ha maga a lekérdezés hibázik, a tétel **marad** `sending`-ben: bizonytalanságból nem írunk állapotot, és a 4 órás kontroll-sáv teendő (18.4) felszínre hozza. Bizonylatonként **egyetlen** adatszolgáltatási tétel keletkezik, a bizonylat létrejöttekor. Az ismételt beküldés (13/A. § (4)) **ugyanezt a tételt frissíti**: nő a kísérletszám, és felülíródik az állapot, a NAV tranzakció-azonosítója és a hibaüzenet. > **Korlát, kimondva:** a **korábbi kísérletek részletei – az időpontjuk, a saját > tranzakció-azonosítójuk és a hibaüzenetük – nem őrződnek meg.** A nyilvántartás a kísérletek > darabszámát és a **legutolsó** kísérlet eredményét tartja. A sztornó okirat ettől függetlenül > saját, önálló adatszolgáltatási tételt kap, mert önálló számlaként keletkezik. ### 16.5 Sztornó – ugyanez az út, egy sorrendi feltétellel A sztornó okirat **önálló számla, saját sorszámmal**, `STORNO` művelettel és saját adatszolgáltatási tétellel – ugyanazon az úton megy, mint egy rendes számla. **Sorrendi kényszer:** a rendszer csak akkor engedi a sztornót, ha az **eredeti számla adatszolgáltatása már `done`** állapotban van. Ha még nincs, ezt a mondatot kapod: > „Az eredeti számla NAV-adatszolgáltatása még nem zárult le (DONE) – a sztornót csak utána lehet > beküldeni. Próbáld pár perc múlva.” Ez nem kényelmetlenség, hanem a lánc-modell követelménye: a módosító okirat csak lezárt gyökérre hivatkozhat (13.1). ### 16.6 A kiállítói (eladó) törzsadat forrása A számlára és az adatszolgáltatásba kerülő **kiállítói adatokat – áfakód, megyekód, hivatalos név és cím – a rendszer a NAV saját nyilvántartásából kérdezi le** (`queryTaxpayer` a saját adószámodra), nem a mi adatbázisunkból. Így garantáltan az az érték megy vissza, amit a NAV elvár. Kizárólag a **bankszámlaszám** származik a te beállításodból (6.8). Sikeres lekérdezéskor a rendszer pillanatképet ment a törzsadatról, és NAV-kiesés esetén ebből építi fel a kiállítói blokkot. **A cím nem lehet hiányos.** A NAV sémája a kiállító irányítószámát és települését kötelezővé teszi, ezért ha a `queryTaxpayer` válaszában nincs használható székhelycím, a rendszer a korábbi pillanatképet használja; ha az sincs, a kiállítás **megáll, magyar üzenettel** – hiányos címmel ugyanis olyan adatszolgáltatás menne ki, amit a NAV már a beküldéskor visszautasít. Több cím (telephely, fióktelep) esetén a **székhely** kerül a számlára. > **Korlát, kimondva (vállalt döntés):** ha a törzsadat sem élőben nem érhető el, sem > pillanatkép nincs róla, a **számla kiállítása meghiúsul**. Ez kizárólag a **legelső** saját > kiállítást érintheti, ha épp NAV-üzemzavar van: az első sikeres lekérdezés után a > pillanatkép átveszi a szerepet, és a NAV kiesése a további kiállítást nem akadályozza > (13/B. §). A rendszer kézi cégadat-megadást szándékosan nem kínál – a kiállítói adatok > egyetlen forrása a NAV nyilvántartása, így hibás kézi törzsadat nem kerülhet számlára. ### 16.7 Előfeltételek – mi kell a saját úthoz A saját számlázásra váltás **megtagadott**, amíg a NAV technikai felhasználó nincs bekötve és az **XML cserekulcs** nincs megadva; a NAV-fiókban ezen felül a **„Számlák kezelése” jog** is kell, hiányában a beküldés `FORBIDDEN` hibával elakad. A bekötés lépéseit, a pontos hibaüzeneteket és a kulcsok titkosított tárolását a **6. fejezet** írja le. A technikai felhasználó adatai és a cserekulcs **titkosítva (AES-256-GCM)** tárolódnak, kizárólag szerveroldalon fejtődnek vissza, és **soha nem kerülnek az AI-modellhez** vagy a böngésződbe. ### 16.8 Hogyan ellenőrzöd, hogy rendben van-e minden Három eszközöd van, mindegyik **minden csomagban elérhető**, előfizetéstől függetlenül: 1. **Áttekintés** – kérdezd a chatben: *„Rendben elmentek-e a számláim a NAV-hoz?”* A válasz a saját úton kiállított számláidra megadja a visszaigazolt (`done`), az úton lévő, az elutasított és a sikertelen beküldések darabszámát, valamint a figyelmeztetéssel elfogadottakét – a problémás tételeknél magyar mondattal. **Az áttekintés adatai determinisztikusak:** a darabszámokat és a problémás tételek magyar mondatait a szerver számolja a saját nyilvántartásból, nem a nyelvi modell. **A modell erre a kimenetre kötelező szabályt kap** – elutasított vagy sikertelen beküldés mellett nem adhat megnyugtató választ –, de ez a szabály a modell viselkedését köti, nem egy kimenet-szűrő kapu. **Ezért mindig a számláló és a felsorolt számlaszám a döntő adat:** ha az „elutasított” vagy a „sikertelen” mezőben nem nulla áll, az adatszolgáltatás nincs rendben – függetlenül attól, mit mond a kísérőszöveg. 2. **Egy konkrét számla sorsa** – *„Mi történt a TITKAR-2026-12 számla NAV-adatszolgáltatásával?”* Megkapod az állapotot magyar címkével, a kísérletszámot, a NAV tranzakció-azonosítóját, a hibaüzenetet vagy figyelmeztetést, és azt, hogy a tétel újrapróbálható-e. 3. **A Pénzügyi teendők sáv (kontroll-sáv)** – az elakadt adatszolgáltatás magától megjelenik itt, **magas súllyal**, a legrégebbi érintett számla számával és egy „Megnézem, mi akadt el” gombbal. Részletek a 18.4 pontban. Ha olyan számláról kérdezel, amelyet nem a saját úton állítottunk ki, a rendszer nem hallgat és nem tagad: kimondja, hogy annak az adatszolgáltatását a külső számlázó végezte. ### 16.9 Amit ez a funkció nem tud – korlátok kimondva - **A kiállítás eredménye a számlaszám – az adatszolgáltatás státusza ettől elválik.** A kiállítás utáni kártyán a számlaszám alatt **élő státusz-sor** fut („adatszolgáltatás folyamatban” → „a NAV elfogadta”), amely a saját nyilvántartásunkat kérdezi 5 másodpercenként, legfeljebb 2 percen át; a NAV-ot közben a szerver kérdezi (utókövetés + a 15 perces futás). Éles NAV-nál a visszaigazolás jellemzően másodpercek, tehát a végállapot rendszerint még a kártyán megjelenik. **Ez a sor viszont nem garancia:** ha a feldolgozás elhúzódik (a teszt-környezetben ez a jellemző), a sor őszintén „folyamatban”-t mond, és a figyelést a szerver viszi tovább. A díjbekérőn nincs ilyen sor (nincs adatszolgáltatása). A tudomásszerzés további útja: rákérdezés (16.8), vagy a kontroll-sáv jelzése, ami **4 óra** elteltével jelenik meg. A 4 óra a rendszer **saját, vállalt jelzési küszöbe**, nem jogszabályi határidő – a kiállítás akkor is sikeres, ha a NAV nem elérhető, és a rendszer 4 órán belül szól, ha az adatszolgáltatás elakadt. - **Nincs nyugta a saját úton.** Készpénzes vevőnek rendes számlát tudsz kiállítani (fizetési mód: készpénz). - **Nincs technikai érvénytelenítés (`manageAnnulment`)** – lásd részletesen a 18.9 pontban. --- ## 17. Adóhatósági ellenőrzési adatszolgáltatás (11/A. §) Ez a funkció **nem azonos** a 16. fejezet szerinti NAV-adatszolgáltatással. A 13/A. § szerinti adatszolgáltatás a számla kiállításakor, automatikusan megy a NAV-hoz. Az **adóhatósági ellenőrzési adatszolgáltatás** (a rendelet 11/A. §-a) ezzel szemben az az adat-kiadás, amelyet **adóhatósági ellenőrzés esetén te kérsz le és adsz át** – a rendelet a számlázó programtól megköveteli, hogy erre képes legyen. ### 17.1 A funkció neve és indítása **A funkciót a jogszabályi nevén találod meg.** A 23/2014. (VI. 30.) NGM rendelet 8. § (1) c) pontja **„adóhatósági ellenőrzési adatszolgáltatás”** elnevezésű funkciót ír elő, és a program a felhasználói felületen végig ezen a néven hivatkozik rá: | Hol | Mit látsz | |---|---| | A chat-kártya címe | **„Adóhatósági ellenőrzési adatszolgáltatás”** | | A kártya alcíme | „A kibocsátott számlák adatai XML-ben, a 23/2014. (VI. 30.) NGM rendelet 11/A. §-a szerint.” | | A letöltött fájl neve | `adohatosagi-ellenorzesi-adatszolgaltatas_.xml` | | A titkár szóhasználata a chatben | ugyanez a megnevezés – az eszköz leírása kifejezetten előírja neki | | A hibaüzenetek | „Az adóhatósági ellenőrzési adatszolgáltatás elkészítése nem sikerült.” | A letöltés **technikai címe** (az az útvonal, amelyre a kártya gombja mutat) továbbra is `/api/adatexport`. Ez gépi cím, nem felhasználói megnevezés: a böngésző címsorában látszik, de a funkció neve a felületen mindenhol a fenti, jogszabályi megnevezés. **Ellenőrzéskor tehát ezen a néven kell keresned – és ezen a néven is találod meg.** Ugyanez a technikai szó **egyetlen hibaüzenetben** maradt meg: ha a két szűrőt egyszerre adod meg, a rendszer az „Az adatexport vagy DÁTUM-tartományra, vagy SORSZÁM-tartományra szól…” mondattal utasít el (17.2). Ez a szó egyébként maga is a rendelet fogalma (2. § 5. pont), és a funkció megnevezését nem érinti. A funkció **önállóan, bármikor indítható**, és **nincs rajta csomag-kapu** – sem a chatben, sem a letöltő útvonalon. Ez tudatos döntés: jogszabályi kötelezettség teljesítése nem függhet előfizetéstől. Free csomagban ugyanúgy elérhető, mint Ultrában. Két úton indítható: - **A chatben:** *„NAV-ellenőrzésre kell az adatszolgáltatás 2026-01-01 – 2026-06-30-ra.”* A rendszer előbb lefuttatja a szűrést (hány számla, mi maradt ki), és **csak utána** ad letöltési linket. - **Közvetlen letöltéssel:** a `/api/adatexport` útvonalon, bejelentkezve, ugyanazokkal a szűrő-paraméterekkel (`from`, `to`, `fromNumber`, `toNumber`). Maga az XML **soha nem megy át az AI-modellen** – a modell csak a szűrést futtatja le és a linket adja; a fájlt a szerver állítja elő közvetlenül a saját nyilvántartásból (NAV-hívás nélkül). **Az export a saját kibocsátású számlákra szól.** A 11/A. § szerinti kötelezettség a kibocsátáshoz tapad: az itt kiállított számlákra ez a program adja ki az adatszolgáltatást. A **2026. augusztus 8. előtt, külső számlázó programban** kibocsátott bizonylatok nincsenek benne az exportban – azokat a számláidat ténylegesen kibocsátó programból kell lekérned. ### 17.2 A két szűrő – dátum VAGY sorszám A rendelet két intervallum-típust nevesít, és a rendszer is ennek megfelelően **kizárólagosan** kezeli őket: | Szűrő | Paraméterek | Alap | Határok | |---|---|---|---| | **Dátum-tartomány** | `from`, `to` (ÉÉÉÉ-HH-NN) | a számla **kelte** (kiállítás napja) | **mindkét vég inkluzív** | | **Sorszám-tartomány** | `fromNumber`, `toNumber` | a számla sorszáma | **mindkét vég inkluzív** | | Szűrő nélkül | – | – | a **teljes saját számla-állomány** | **A kettő egyszerre nem adható meg.** Ha mégis megpróbálod: > „Az adatexport vagy DÁTUM-tartományra, vagy SORSZÁM-tartományra szól – a kettő egyszerre nem > adható meg.” **A dátum-szűrő a bizonylat KELTÉJÉRE megy**, és nem a rekord létrejöttének időbélyegére. A kelte a számla önálló adatmezőjében (`invoices.issue_date`) tárolódik, magyar idő szerinti naptári napként – ugyanaz az érték, ami a számlaképre és a NAV-nak jelentett `invoiceIssueDate` mezőbe kerül. Ez nem formaság: a rekord időbélyege UTC, és a kettő a nap két végén eltérhet; egy időzóna-eltolás miatt kimaradt számla az ellenőrzésre átadott adatszolgáltatást tenné hiányossá. **Mindkét nap benne van** az exportban: dátum-oszlopon a szűrés egyszerű, mindkét végén inkluzív összehasonlítás, tehát a kezdő és a záró napon kiállított számla is bekerül. **A sorszám-tartomány nem szöveges összehasonlítás.** A sorszám nincs nullákkal feltöltve (`TITKAR-2026-9`, `TITKAR-2026-10`), ezért a betűrendes összevetés hamis eredményt adna – egy ellenőrzésre átadott export csendben hiányos lenne. A rendszer a sorszámot `(év, sorszám)` párra bontja, és **numerikusan** dönt a tartományról, évhatáron át is (8.7). A sorszám-szűrő ellenőrzései és magyar üzenetei: | Eset | Üzenet | |---|---| | Ismeretlen alakú sorszám | „A(z) »X« nem a saját sorszámtartomány formátuma (PREFIX-ÉÉÉÉ-sorszám, pl. TITKAR-2026-12).” | | A két határ eltérő előtagú | „A két sorszám különböző tartományból való (… és …) – egy export egy sorszámtartományra szól.” | | Fordított sorrend | „A záró sorszám nem lehet korábbi a kezdőnél.” | | Rossz dátumformátum | „A(z) kezdő/záró dátum formátuma ÉÉÉÉ-HH-NN legyen (kaptam: …).” | | Fordított dátumok | „A záró dátum nem lehet korábbi a kezdőnél.” | ### 17.3 Mi kerül az exportba és mi nem **Bekerül:** kizárólag a **saját (NAV-közvetlen) úton, ezzel a programmal kibocsátott valódi számla** – a sztornó okirat is, mert az önálló számlaként keletkezik. **Nem kerül bele – és ezt fontos tudnod ellenőrzéskor:** | Kimarad | Miért | Hol szerezhető be | |---|---|---| | A **2026. augusztus 8. előtt, külső számlázón** kiállított számla | Nem ez a program bocsátotta ki; annak exportja a másik rendszer 11/A. § szerinti kötelezettsége | A másik számlázó programban | | A **NAV-ból importált előzmény** | Nem kibocsátás, hanem behúzott adat | A kibocsátó programból / a NAV Online Számla felületéről | | A **díjbekérő** | A díjbekérő nem számla | – | | A **NAV által elutasított lánc-okirat** (helyesbítő/sztornó, amelyet a NAV `ABORTED`-tel visszautasított, és a rendszer „törölt”-re állított – 13.6) | Az a bizonylat a NAV nyilvántartásában nem létezik; benne hagyva az export olyan tételt vinne az ellenőrzésre, amit a hatóság a saját rendszerében nem talál | – (a javítást új okirat viszi) | > **Az export hatálya tehát nem időbeli, hanem forrás-alapú:** azok a számlák kerülnek bele, > amelyeket ez a program bocsátott ki. Ha a NAV ellenőrzése a korábbi, külső számlázós időszakra is > kiterjed, azt az akkori programból kell beszerezned. > Ez a forrás-alapú hatály **végleges** – a program a saját kibocsátású számláiért felel, a > más rendszerben kibocsátottakért az a rendszer. ### 17.4 A dokumentum forrása és szerkezete **A forrás a beküldéskor eltárolt `InvoiceData` XML**, nem a számlasor összegei. Így az export bizonyíthatóan ugyanaz az adat, amelyet a NAV-nak jelentettünk. Egy kivétel van, és ez jogilag szükséges: **a magánszemély vevő nevét és címét a rendszer visszateszi**. A NAV-nak beküldött adatszolgáltatásból ezek tiltottak (Áfa tv. 10. számú melléklet), az adóhatósági ellenőrzési adatszolgáltatásból viszont kötelezők – a tárolt XML puszta újrajátszása tehát **jogilag hibás, hiányos exportot adna**. A pótlás a számlasor **kiállításkori pillanatképéből** történik (vevőnév, irányítószám, város, cím és a cím országkódja; a rögzített országkód nélküli, korábbi bizonylatoknál az országkód belföldi, `HU`), és a dokumentum export-célú jelölést kap. **A pótlás forrása garantáltan kitöltött:** a kiállítás magánszemély vevőnél is megköveteli az irányítószámot és a települést (9.1), ezért a pillanatkép nem lehet cím nélküli – **a vevő címe így az adatszolgáltatásban is ott van**. **Az adószámos vevő adataihoz a rendszer nem nyúl**: ott a tárolt, jelentett adat a hiteles, nem a később átírható partner-nyilvántartás. A dokumentum szerkezete: egy XML-prológ, egy csoportosító `` gyökérelem, alatta önálló, teljes `InvoiceData` elemek – az `invoiceData.xsd` szerkezetében (a rendelet 2. § 5. pontja szerint ez elfogadott adatexport-szerkezet). **Egy számla csak egyszer szerepelhet** az exportban – az ellenőrzésre adott exportban egy kétszer szereplő számla ugyanolyan hiba, mint egy hiányzó. Ez a mai működésből egyébként is következik: bizonylatonként egyetlen adatszolgáltatási tétel keletkezik (16.4). Az egyszeres szerepeltetést az export ezen felül, védelmi jelleggel is kikényszeríti. Letöltéskor a fájl `application/xml; charset=utf-8` típusú, **`adohatosagi-ellenorzesi-adatszolgaltatas_.xml`** néven, és nem kerül gyorsítótárba. A fájlnév maga is a jogszabályi funkció-megnevezést viszi: az ellenőrzésre átadott fájlnak magának is meg kell mondania, mi az. ### 17.5 A kimaradt számlák – a rendszer nem hallgat a hiányról Ha egy kibocsátott számlához nincs eltárolt adat, vagy az nem olvasható vissza, a számla **nem tűnik el csendben**: bekerül a „kimaradt” listába magyar mondattal: > „TITKAR-2026-12: nincs eltárolt számla-adat, ezért kimaradt az exportból.” > „TITKAR-2026-13: az eltárolt számla-adat nem olvasható vissza.” > „TITKAR-2026-14: az eltárolt számla-adatból nem állt össze érvényes export-dokumentum (…).” **Egy elakadt bizonylat nem viszi el az egész exportot:** a dokumentumok számlánként épülnek fel, és ha egyikük hibára fut, csak az kerül a kimaradt listába – a fájl a többi számlával elkészül. Az ellenőrzésre kért exportnak akkor is meg kell születnie, ha egy régi bizonylat adata hiányos. A kártya ezt **figyelmeztető sávban, nem elrejtve** mutatja, a darabszámmal együtt. A kártya akkor is megjelenik, ha egyetlen számla sem esik a szűrőre – az „egy számla sem esik ide” ugyanolyan érvényes válasz egy adóhatósági kérésre, mint maga a fájl. **A te teendőd:** ellenőrzés előtt **mindig nézd meg a kimaradt listát**, és a benne szereplő számlákat külön dokumentáld. ### 17.6 Korlátok – kimondva - **Nincs futásidejű XSD-validáció az export-úton.** Az XML-ek NAV-sémakészlet elleni ellenőrzése fejlesztői eszközben fut (ahol a 345 korpusz- és 29 példatár-XML mind érvényesnek bizonyult), de a letöltött fájl nem megy át séma-ellenőrzésen a kiadás pillanatában. - **Nincs darabszám- vagy méretkorlát és nincs lapozás.** A teljes találati halmaz egyetlen válaszban épül fel; nagyon nagy állománynál ez korlátot jelenthet. --- ## 18. Hibakezelés és üzemzavar (13/A. § (4)–(7), 13/B. § (3)) ### 18.1 Az elv Az adatszolgáltatás elmaradása **számlánként akár 1 millió forint** mulasztási bírsággal járhat, és ez a bírság **téged, az adózót** terheli. Ezért a rendszer két dolgot csinál következetesen: amit gépi úton meg lehet oldani, azt magától megoldja; amit nem, arról **kimondottan szól**, és soha nem nyugtat meg tévesen. ### 18.2 Amit a rendszer magától csinál **Automatikus futás 15 percenként** (`*/15 * * * *`), fiókonként elkülönített hibakezeléssel – egy fiók hibája nem állítja meg a többiét. A futás három dolgot tesz, ebben a sorrendben: | Lépés | Mit csinál | Jogalap | |---|---|---| | **Státusz-lekérdezés** | A `submitted` tételeket végállapotig (`DONE`/`ABORTED`) lekérdezi | 13/A. § (3) – az adatszolgáltatás csak a visszaigazolással teljesül | | **Félbeszakadt küldések tisztázása** | A 30 percnél régebb óta `sending` tételekről a NAV lánc-kivonatából dönti el, bement-e a beküldés (16.4) → `done` vagy `failed` | 13/A. § (3)–(4) – sem duplikálni, sem elhagyni nem szabad az adatszolgáltatást | | **Újraküldés** | A `pending` és `failed` tételeket újraküldi | 13/B. § (3) – 24 óra az akadály elhárultától | A sorrend nem véletlen: ami a tisztázásból `failed`-be kerül, azt még **ugyanabban a futásban** újraküldjük; ami `done`-ba, azt soha többé. **Türelmi idő: 2 perc.** A 2 percnél frissebb tételekhez a futás nem nyúl – azokat a kiállítás utáni azonnali beküldés még kézben tartja. **Napi egyeztetés a NAV nyilvántartásával** (`nav-digest`, minden hajnalban 4:40-kor): a rendszer visszakérdezi a NAV-tól, mely számlák szerepelnek NÁLUK az elmúlt 34 napból, és összeveti azzal, amit kiállítottunk. Ez a beküldési naplótól **független** ellenőrzés: a 15 perces futás a saját feljegyzésünket olvassa vissza, tehát vak arra az esetre, amikor beküldési tétel létre sem jött, vagy `done`-t mutat, de a bizonylat a NAV-nál mégsem szerepel. Az egyeztetés a 6 óránál frissebb számlákat nem kéri számon (a beküldés és a NAV indexelése is telik), az eltérést pedig kétfelé bontja: amit a saját naplónk is jelez, azt a meglévő teendő fedi, amit **csak** az egyeztetés talál meg, arról **külön, magas súlyú kontroll-sáv teendőt** kapsz („A NAV nem ismer egy kiállított számlát”). **Ha maga az egyeztetés marad el, arról is szólunk.** Ha az ellenőrzés két napja nem futott le, vagy hibára futott, a kontroll-sávban külön teendő jelenik meg – a hallgatás ugyanis nem bizonyíték: nem azt jelenti, hogy nincs eltérés, hanem hogy jelenleg nem ellenőrzi senki. ### 18.3 Amit a rendszer szándékosan nem próbál újra Ez nem hiányosság, hanem védelem: - **`submitted` tétel** – már van tranzakció-azonosítója, az adatszolgáltatás a NAV-nál van. Az újraküldés **duplikált adatszolgáltatás** lenne: a NAV vagy `INVOICE_NUMBER_NOT_UNIQUE` hibával utasítaná el, vagy – rosszabb esetben – kétszer venné nyilvántartásba. - **`aborted` tétel** – ez a NAV **tartalmi** elutasítása. Ugyanazt az adatot újraküldeni sosem vezet eredményre; javítani kell (lásd 18.6). - **`sending` tétel** – azt épp egy futó küldés foglalja. Vakon újraküldeni duplikált adatszolgáltatás lenne, vakon ott hagyni pedig elmaradt adatszolgáltatás – ezért itt sem tippel a rendszer, hanem a NAV-ot kérdezi meg (16.4). - **Technikai érvénytelenítési (`ANNUL`) tétel** – az nem ezen az úton megy (lásd 18.9). ### 18.4 A 24 órás határidő őrzése és a jelzések | Jelzés | Küszöb | Kinek szól | Hogyan | |---|---|---|---| | **Kontroll-sáv teendő** („NAV-adatszolgáltatás elakadt”) | **4 óra** | **neked** | A chat Pénzügyi teendők sávjában, magas súllyal, minden csomagban | | **Napi összefoglaló e-mail** | ugyanaz a teendő | neked (fiók-tulajdonos) | Hétköznap 7:30-kor, alapból bekapcsolva, **csak állapotváltozáskor** | | **Üzemeltetői riasztás** | **20 óra** | az üzemeltetőnek | Hibaszintű riasztás a monitorozó rendszerbe | A **4 órás küszöb tudatosan korán szól**, hogy maradjon időd intézkedni. Ez a rendszer saját küszöbe, **nem jogszabályi határidő**. A kontroll-sáv két, eltérő természetű esetet jelöl: > **Elutasított:** „N számla adatszolgáltatását a NAV elutasította (SZÁMLASZÁM) – ez magától nem > rendeződik, a hibás adatot javítani kell.” > > **Elakadt:** „N számla adatszolgáltatása még nem ért célba (SZÁMLASZÁM) – a rendszer > újrapróbálja, de ha az akadály nálad van (pl. a NAV-kulcsok), azt neked kell rendezni. Üzemzavar > esetén a jogszabály az akadály elhárultától 24 órát ad.” Mellette egy **„Megnézem, mi akadt el”** gomb, amely a legrégebbi érintett számlára kérdez rá. **A 24 óra nem általános türelmi idő.** Az adatszolgáltatást a 13/A. § (1) szerint a kiállításkor, **azonnal** kell teljesíteni. A 13/B. § (3) szerinti 24 óra **kizárólag akkor** él, ha a NAV rendszere üzemzavar, karbantartás vagy az internetszolgáltatás elégtelensége miatt nem érhető el. Ha a beküldés a **te NAV-beállításod** hibája miatt akadt el – hiányzó vagy rossz XML cserekulcs, hiányzó „Számlák kezelése” jog (`FORBIDDEN`), lejárt jelszó –, a késedelem **az első perctől mulasztásnak minősül**, és a 24 órára nem hivatkozhatsz. Ilyenkor a beállítást azonnal rendezned kell (18.6). **A kontroll-sáv üzenete ezt a két esetet szétválasztja.** Az „elakadt” mondat előbb a **saját oldali akadályt** nevezi meg (például a NAV-kulcsokat) mint olyat, amit **neked** kell rendezned, és a 13/B. § (3) szerinti 24 órát **kizárólag az üzemzavarhoz**, az akadály elhárultától köti. A felületi szöveg így nem sugallja azt, hogy egy saját beállítási hibánál is „van még 24 órád”. > **Korlát, kimondva:** a **20 órás riasztás az üzemeltetőnek szól, nem neked** – a felületen és > e-mailben a 20. óránál nem kapsz külön értesítést. A te jelzésed a 4 órás kontroll-sáv teendő és > a napi összefoglaló e-mail (ha az állapot változott). ### 18.5 A NAV hibakódjai magyarul **88 NAV validációs hibakódhoz** tartozik saját, cselekvésre hívó magyar mondat (forrás: a NAV interfész-specifikáció 3.0, 2026.02.12, 3.2–3.3 fejezet). Ismeretlen kódnál a rendszer a NAV hivatalos üzenetére, végső esetben magára a kódra esik vissza – **kitalált magyarázatot sosem ad**. A hibaüzenet két külön mezőben áll: - **hiba** (blokkoló): „A NAV elutasította az adatszolgáltatást: …” - **figyelmeztetés**: „A NAV elfogadta, de figyelmeztetéssel: …” Néhány jellemző eset: | Kód | Természete | Amit a rendszer mond | |---|---|---| | `MAINTENANCE_MODE` | NAV-üzemzavar | „A NAV rendszere éppen karbantartás alatt van… A számla kiállítva marad, mi pedig automatikusan újrapróbálkozunk – a jogszabály erre 24 órát ad, ezen belül teljesítjük.” | | `OPERATION_FAILED` | NAV-oldali hiba | „…Nem a számla adataival van baj – automatikusan újrapróbálkozunk…” | | `FORBIDDEN` | **a te beállításod** | „Az Online Számla felületén a technikai felhasználónál engedélyezni kell a »Számlák kezelése« jogot – a puszta »Számlák lekérdezése« ehhez kevés.” | | `INVALID_SECURITY_USER` | **a te beállításod** | „A NAV nem fogadta el a technikai felhasználó nevét vagy jelszavát… ha az Online Számla felületén jelszót cseréltél, itt is frissíteni kell.” | | `INVALID_USER_RELATION` | **a te beállításod** | A technikai felhasználó nem ehhez az adószámhoz tartozik, vagy le van tiltva. | | `NOT_REGISTERED_CUSTOMER` | **a te beállításod** | Az adószám nincs regisztrálva az Online Számla rendszerben. | | `SCHEMA_VIOLATION` | **a mi hibánk** | „…a számla adatait nem kell javítanod, mi hárítjuk el…” | > **Korlát, kimondva:** a `SCHEMA_VIOLATION` üzenete azt ígéri, hogy „a beküldés automatikusan > megismétlődik”. **Ez az ígéret a jelenlegi működéssel nem tartható:** a séma-sértés `aborted` > állapotot eredményez, azt viszont a rendszer szándékosan nem küldi újra. Ilyen esetben az > üzemeltető beavatkozása szükséges – jelezd az info@titkar.ai címen. ### 18.6 Mit kell tenned – állapotonként | Állapot | A te teendőd | |---|---| | `pending`, `failed` | **Semmi.** A rendszer 15 percenként újrapróbálja. Ha sürget az idő, a chatben kérheted az azonnali újraküldést: *„Küldd be újra a TITKAR-2026-12 számla adatszolgáltatását.”* | | `submitted` | **Semmi.** A NAV feldolgozza; az állapot magától frissül. | | `done` | Kész, teljesült adatszolgáltatás. | | `done` + **figyelmeztetés** | Az adatszolgáltatás teljesült, de a figyelmeztetést érdemes rendezni a következő számláknál – a figyelmen kívül hagyott figyelmeztetésekből lettek később blokkoló hibák. | | **`aborted`** | **Cselekedned kell – ez magától sosem rendeződik.** A magyar hibaüzenet megmondja, mi a baj (jellemzően vevő-adat, áfa-jogcím vagy adószám). A járható út: **a számlát sztornózni, és a helyes adatokkal újra kiállítani.** | | NAV-oldali beállítási hiba (`FORBIDDEN`, `INVALID_SECURITY_USER`, `INVALID_USER_RELATION`, `NOT_REGISTERED_CUSTOMER`) | Rendezd az onlineszamla.nav.gov.hu felületén (jogosultság, jelszó, technikai felhasználó), utána az újraküldés magától megy. | **Kézi újraküldés a chatből.** A rendszer determinisztikus kapukkal védi ezt a műveletet – nem az AI dönti el, mikor mehet: | Ha az állapot… | A válasz | |---|---| | `done` | „Ez az adatszolgáltatás már teljesült – a NAV visszaigazolta.” | | `submitted` | „Ez a beküldés már a NAV-nál van, a feldolgozására várunk…” | | **`aborted`** | **Megtagadva:** „A NAV ezt az adatszolgáltatást tartalmilag elutasította[: hiba]. Ugyanezt az adatot újraküldeni nem vezet eredményre – a számlát sztornózni kell, és a helyes adatokkal újra kiállítani.” | | `pending` / `failed`, de az újraküldés sem sikerül | „Az újraküldés most sem sikerült: … A rendszer automatikusan tovább próbálkozik.” | A művelet **fiókra szűrt**: más fiók adatszolgáltatását a nevedben elindítani nem lehet. ### 18.7 Ha a hiba 3 munkanapon belül nem hárul el – manuális teljesítés (13/A. § (6)–(7)) Ez a pont akkor lép életbe, amikor a programon belüli utak kimerültek: tartósan `failed` beküldés, `aborted` (a NAV tartalmilag elutasította) tétel, vagy olyan hiba, amelyet a program nem tud elhárítani (például a technikai érvénytelenítés hiánya – lásd 18.9). **A 13/A. § (7) nem lehetőség, hanem kötelezettség:** ha a hibát az észlelésétől számított **3 munkanapon belül** nem sikerül elhárítani, az adatszolgáltatást a hiba elhárultáig **manuálisan kell teljesítened** – az onlineszamla.nav.gov.hu felületén, a számla kézi rögzítésével, számlánként. Ez nem választható alternatíva, és **a programon belüli újraküldés nem váltja ki**. A titkár.ai ezt nem tudja helyetted elvégezni: a kézi rögzítés a te NAV-fiókodban, a te közreműködéseddel történik. **A megismételt adatszolgáltatást jóvá is kell hagynod.** A 13/A. § (5) szerint az ismételt adatszolgáltatást a NAV rendszerében jóvá kell hagyni; ez szintén a NAV Online Számla felületén, a te feladatod. **A te teendőd sorrendben:** 1. Nézd meg, mi az elakadás oka (16.8). Ha a saját NAV-beállításod hibás, rendezd – utána az újraküldés magától megy (18.6). 2. Ha a NAV tartalmilag utasította el (`aborted`), sztornózd a számlát, és állítsd ki újra a helyes adatokkal (13.7). 3. Ha a hiba az észleléstől számított 3 munkanapon belül **nem hárul el**, kezdd meg a manuális teljesítést a NAV felületén, és hagyd jóvá az ott rögzített adatszolgáltatást. 4. Jelezd nekünk az info@titkar.ai címen – a tartós elakadás üzemeltetői beavatkozást is igényelhet. > **Korlát, kimondva:** a programban **nincs külön felület** a 3 munkanapos határidő követésére: a > rendszer nem számolja a munkanapokat, és nem küld erről külön figyelmeztetést. A 4 órás > kontroll-sáv teendő és a napi összefoglaló e-mail jelzi, hogy egy adatszolgáltatás elakadt – a > határidő figyelése innentől rád tartozik. > Külön munkanap-számláló és figyelmeztetés **nem épül** – a kötelezettség kimondása és a > meglévő jelzések (kontroll-sáv, napi összefoglaló) adják a támogatást. ### 18.8 Ha a titkár.ai nem érhető el A 18.1–18.6 pont a **NAV** oldali kiesést kezeli. Ez a pont a **saját (szolgáltatói) kiesésről** szól: amikor a titkár.ai maga nem elérhető. A program **online szolgáltatás**: offline mód nincs, és a Szolgáltató **rendelkezésre állási (SLA) vállalást nem tesz** (3.6 és 28.2). Ezért ez nem elméleti kockázat. **Ha a szolgáltatás kiesése alatt számlaadási kötelezettséged keletkezik, azt a titkár.ai-n kívül kell teljesítened:** kézi (nyomtatvány) számlával, a saját, **elkülönített kézi sorszámtartományodból**. A kézi számla adatszolgáltatását **a NAV Online Számla felületén, kézzel** kell megtenned, a kézi számlára irányadó jogszabályi határidőn belül. A kézi számla adatszolgáltatási határideje az Áfa tv. 10. számú mellékletének 2–3. pontja szerint: a kibocsátást követő **négy naptári napon belül**; ha a számlában áthárított adó összege eléri vagy meghaladja az **500 000 forintot**, a kibocsátást követő **naptári napon belül**. (Forrás: Áfa tv. 10. melléklet; a NAV tájékoztatói ugyanezt mondják ki.) Ugyanez a határidő vonatkozik a kézi számlát módosító vagy érvénytelenítő okiratra is, az abban szereplő áthárított adó előjeltől független összege szerint. **A kiesés utáni visszatéréskor a kézi számlát NE rögzítsd újra a titkár.ai-ban.** Ez két dolgot okozna: **második adatszolgáltatást** ugyanarról az ügyletről, és **sorszám-ütközést** a program saját tartományával. A kézi számla a kézi tartományodban marad, és a NAV-nál is ott van. ### 18.9 További korlátok – kimondva - **Nincs technikai érvénytelenítés (`manageAnnulment`).** A rendszer ismeri az `ANNUL` műveletet, az érvénytelenítési kódot és indoklást, de **a NAV felé nem küldi be** – a beküldés ilyenkor hibával leáll („Technikai érvénytelenítést ez az út nem küld be”). Következmény: az `INVOICE_NUMBER_NOT_UNIQUE`, `MULTIPLE_INVOICES_FOUND` és `MULTIPLE_QUERY_RESULT_FOUND` hibáknál a hibaüzenet által javasolt út (érvénytelenítés + jóváhagyás) **a termékből nem indítható** – ezt a NAV Online Számla felületén, kézzel kell elvégezned. A NAV-felületi kézi érvénytelenítés lépésről lépésre leírása nem e dokumentum tárgya – a korlát kimondása és a NAV Online Számla felületére irányítás a vállalt tájékoztatás. - **Nincs növekvő várakozási idő és nincs kísérlet-plafon.** A `failed` tételt a rendszer 15 percenként, korlátlanul újrapróbálja, amíg sikerül, vagy amíg valaki kézzel el nem rendezi. - **A 13/A. § (7) szerinti 3 munkanapos határidőnek nincs külön felülete.** A programon belül a javítás útja a **helyesbítő számla** (13.5) vagy a **sztornó + újra kiállítás**; ha a hiba 3 munkanapon belül nem hárul el, a manuális teljesítés kötelezettségét a **18.7 pont** írja le. - **A `done` + figyelmeztetés esetnek nincs proaktív jelzése.** A figyelmeztetés eltárolódik, és megjelenik, ha rákérdezel az áttekintésre – de **nem generál kontroll-sáv teendőt**, és nem küld róla e-mailt. (A kiállított és a NAV által visszaigazolt számlák napi egyeztetése ettől függetlenül fut – lásd 18.2 –, de az a HIÁNYZÓ bizonylatot keresi, nem a figyelmeztetést.) - **A napi egyeztetés a NAV lekérdezésének korlátain belül dolgozik.** Az ablak 34 nap (a NAV egy lekérdezésben legfeljebb 35 napot enged), tehát az ennél régebbi eltérést nem találja meg, és a számlaszám azonosságán túl **nem veti össze a bizonylat tartalmát** a NAV-nál tárolttal. - **Az `INFO` szintű NAV-üzenet nem jelenik meg figyelmeztetésként.** A rendszer a blokkoló (`ERROR`, `CRITICAL`) és a figyelmeztető (`WARN`) szintet emeli ki; az `INFO` a beküldési naplóban eltárolódik, de nem kerül külön mezőbe. - **A státusz-lekérdezés hibái nem jutnak el hozzád**: azok a szerver naplójába kerülnek. A tétel ilyenkor `submitted` marad, és a 4 órás kontroll-sáv teendő fogja meg. --- ## 19. Nyilvántartás, listák, riportok ### 19.1 Mit tart nyilván a rendszer | Nyilvántartás | Mit tartalmaz | |---|---| | **Bizonylat-fej** (`invoices`) | Számlaszám, bizonylat-fajta (számla / díjbekérő / nyugta), állapot (kiállított / sztornózott / törölt), a kiállítás útja (saját NAV-út vagy külső számlázó), forrás (itt kiállított vagy NAV-ból importált), pénznem, nettó/áfa/bruttó végösszeg, a **kelte** (a kiállítás napja magyar idő szerint, önálló mezőben – erre szűr a 11/A. § szerinti dátum-tartomány, 17.2), teljesítés dátuma, fizetési határidő, a rekord létrejöttének időbélyege (UTC), fizetettség és fizetés napja, a **kiállításkori vevő-pillanatkép** (név, irányítószám, város, cím) és a lánc-mezők (művelet, eredeti számlaszám, módosítás-index) | | **Tételsorok** (`invoice_items`) | Soronként megnevezés, mennyiség, mennyiségi egység, nettó egységár, áfakulcs, nettó/áfa/bruttó érték, megjegyzés, lánc-tételindex | | **Adatszolgáltatási napló** (`nav_submissions`) | Bizonylatonként **egy** tétel (16.4): művelet, állapot, kísérletszám, NAV tranzakció-azonosító, **a beküldött XML szó szerint**, annak **SHA3-512 lenyomata**, a NAV üzenetei, a magyar hibaüzenet, a figyelmeztetés, a beküldés és a lezárás időbélyege. Az ismételt beküldés ugyanezt a sort frissíti – a korábbi kísérletek részletei nem őrződnek meg | | **Tevékenységnapló** (`audit_log`) | Csak hozzáfűzhető napló: vázlat, megerősítés, kiállítás, sztornó, hiba, import, törlés, fizetés, e-mail-küldés, előkontírozás, biztonsági esemény, eÁFA, kézi kiadás (24.4) | **A kiállításkori vevő-pillanatkép nem kényelmi másolat.** Két helyen ez az **egyetlen** forrás: a számlaképen (Áfa tv. 169. § e)) és a 11/A. § szerinti adóhatósági ellenőrzési adatszolgáltatásban – mert magánszemély vevőnél a NAV-nak beküldött XML-ből mindkettő tiltott, a partner-nyilvántartás pedig utólag átírható, ezért nem hiteles. **A pillanatkép ezért nem lehet hiányos: a kiállítás magánszemély vevőnél is megköveteli az irányítószámot és a települést (9.1).** **A beküldött XML megőrzésének három indoka:** a 13/A. § (4) szerinti ismételt beküldésnek ugyanazt az adatot kell vinnie; a normalizált soraiból a visszafejtés veszteséges lenne; és a 11/A. § szerinti adóhatósági ellenőrzési adatszolgáltatás is ebből szolgál ki. **A tevékenységnapló neked is elérhető** (*„Mi történt a fiókomban?”*), időszakra szűrhetően. Ez bizalmi funkció, ezért **szándékosan nincs csomag-kapuzva** – minden felhasználó teljes, ellenőrizhető választ kap. A napló sorait a szerver fordítja magyar mondatokra, nem az AI-modell. ### 19.2 Listák | Funkció | Mit ad | |---|---| | **Számlalista** | A számlák legutóbb kiállítottal kezdve, determinisztikus sorrendben. Szűrhető: darabszám (alap 20), partner, bizonylat-fajta, csak kifizetetlen, csak lejárt (határidő a múltban), kiállítási időszak (mindkét vég inkluzív), forrás (itt kiállított / NAV-ból importált) | | **Egy számla részletei** | A bizonylat-fej és a tételsorok, számlaszám alapján | | **Partnerenkénti összesítés** | Darabszám, bruttó forgalom, első és utolsó számla, nyitott kintlévőség | A vevő neve a mentett partner nevéből jön; ha nincs partner-kapcsolat, a kiállításkori vevőnév-pillanatképre esik vissza. ### 19.3 Riportok és csomagkorlátok | Riport | Csomag | |---|---| | Bevétel-összegzés pénznemenként | minden csomag | | Legnagyobb adósok rangsora | minden csomag | | Bevétel-idősor (hó / negyedév / év) | minden csomag | | Kintlévőség-öregedés és fizetési morál | minden csomag | | NAV-státusz áttekintés | minden csomag | | Alanyi mentes értékhatár figyelése | minden csomag | | Tevékenységnapló | minden csomag | | **Adóhatósági ellenőrzési adatszolgáltatás (11/A. §)** | **minden csomag – tudatosan** | | Áfa-pozíció (fizetendő − levonható) | Ultra | | Időszak-összevetés | Ultra | | Likviditás-előrejelzés | Ultra | | Költség-bontás, eredmény-gyorskép | Ultra | | Könyvelői CSV-export | Ultra | | Könyvelői csomag e-mailben | Ultra | Két elv minden riportra érvényes: - **A rendszer különböző pénznemeket soha nem ad össze** – minden összesítés pénznemenkénti bontásban áll. - **A NAV-ból importált számlák fizetettsége ismeretlen**, ezért a kintlévőség-összesítések csak az itt kiállított számlákat számolják. **Az áfa-összegzés kizárólag tájékoztató**: a hivatalos bevallás a könyvelőd és a NAV feladata, mert nem minden tétel áfája vonható le. ### 19.4 A számlakép megőrzése A saját úton a PDF forrása szintén az eltárolt, NAV-nak beküldött XML, és az első renderelés SHA-256 lenyomata a számlasorra kerül – a részleteket a **15.1–15.3 pont** írja le. > **Korlát:** a PDF **nem tárolódik el bináris formában** – minden letöltéskor újra készül. A > lenyomat az azonosság bizonyítéka, nem archívum. Ha archív példányra van szükséged, töltsd le és > őrizd meg (25.3). ### 19.5 További korlátok – kimondva - **A tevékenységnapló nem tartalmazza a NAV-adatszolgáltatás eseményeit.** A kiállítás és a sztornó bekerül, a beküldés és a NAV visszaigazolása **nem** – az adatszolgáltatás nyilvántartása kizárólag a beküldési napló (19.1), amelyet a 16.8 pont szerinti kérdésekkel érsz el. **Kimondva:** az adatszolgáltatás 13/A. § szerinti nyilvántartása a **beküldési napló** – a tevékenységnapló nem bővül beküldési eseményekkel. - **A számlalista nem mutatja az adatszolgáltatás állapotát.** A listaelemek a kiállítás útját és a forrást hordozzák, beküldés-státuszt nem – arra külön kell rákérdezni (16.8). - **A saját úton kiállított számlához nincs külső számlázó-felület**: a bizonylat kizárólag itt, a saját nyilvántartásban él (a felület ilyenkor a külső hivatkozást el is rejti). - A bevétel-idősor legfeljebb 60 időszak-pontot tölt fel hézagmentesen. - **Megőrzési idő:** a rendszerben jelenleg nincs adatmegőrzési vagy automatikus törlési szabály, a fiók törlésekor viszont a számlák és a beküldési napló is törlődik. A megőrzés teljes képét és a nyitott döntést a **25. fejezet** (és a T-30 tétel) tartalmazza. --- ## 20. Fizetettség és fizetési emlékeztetők > **Elhatárolás:** az e fejezetben leírtak **nem számlázási funkciók** a 23/2014. (VI. 30.) NGM > rendelet 10. § (2) bekezdése értelmében. A fizetettség nyilvántartása és a fizetési emlékeztetők > a saját üzletviteledet szolgálják: **nem érintik a számla tartalmát, nem kerülnek a > NAV-adatszolgáltatásba, és nem befolyásolják annak állapotát.** A teljesség kedvéért írjuk le, > hogy a dokumentáció a program teljes működését lefedje. ### 20.1 Fizetettség rögzítése **Mit lehet kifizetettnek jelölni:** kizárólag **élő (kiállított), valódi számlát**. A díjbekérő, a nyugta és a sztornózott vagy törölt bizonylat nem jelölhető kifizetettnek – ez inkonzisztens adatot eredményezne. **A fizetés napja.** Ahol a valódi napot megadod (befizetés rögzítése dátummal, vagy banki jóváírás), az kerül be; egyébként a rögzítés napja a közelítés. Visszavonáskor a dátum is törlődik, hogy egy tévesen bejelölt számla ne rontsa a vevő fizetési morál-statisztikáját. **Minden fizetettség-rögzítés naplózódik** a tevékenységnaplóban. **Megerősítés-kötelezettség.** A chatben az AI **nem rögzít fizetettséget magától**: csak előnézet-kártyát készít, amelyet a **„Rögzítem” gombbal** te véglegesítesz. Ez igaz a teljes kiegyenlítésre, a részösszeg rögzítésére és a tömeges jelölésre is. A **visszavonás** ezzel szemben kártya nélkül, azonnal megtörténik – befelé ható és visszafordítható művelet (22.3). **Nincs külső fizetési főkönyv:** a befizetés kizárólag a helyi nyilvántartásba kerül, és a napló ezt **őszintén rögzíti** is. A napló ellenőrzési nyom, nem marketingszöveg. A helyi „kifizetve” jelölés teljes kiegyenlítésnél billen át; a részfizetést az audit-napló őrzi. **Banki párosítás (Ultra):** banki jóváírás számlához párosítása után a rendszer fedezettségnél magától átbillenti a fizetettséget, és a tevékenységnaplóban „Banki utalás számlához párosítva” bejegyzésként jelenik meg. **Fizetési morál forrás-jelzéssel:** a kintlévőség-öregedés riport a lassan fizető vevőknél megjelöli, honnan van az adat – banki jóváírás napjából (**pontos**), vagy a saját rögzítésekből (**közelítés**: ha csak utólag jelölöd be a számlákat, a csúszás nagyobbnak látszik a valósnál). A rendszer előírja, hogy ezt a korlátot a válaszban is ki kell mondani. ### 20.2 Fizetési emlékeztetők – a behajtási létra | Fok | Hangnem | Mikor indul | Hogyan | |---|---|---|---| | **1.** | barátságos emlékeztető | a fizetési határidő után **3 nappal** | automatikus (ha bekapcsoltad) | | **2.** | határozott emlékeztető | a határidő után **15 nappal**, és az 1. fok óta legalább **7 nap** eltelt | automatikus (ha bekapcsoltad) | | – | **a 2. fok után az automata leáll** | – | a végtelen ismétlés a vevőt spammelné | | **3.** | fizetési **felszólítás** (késedelmi kamat + 40 EUR behajtási költségátalány) | **30+ nap** késedelemnél | **soha nem automatikus** – kizárólag a te kézi megerősítéseddel, megerősítő kártyán | A 7 napos minimum-szünet arra való, hogy ha későn kapcsolod be az automatát (a számla már régen lejárt), a vevő ne kapjon két levelet két nap alatt. Az automata **hétköznap 7:00-kor** fut. **Kiket céloz az automata:** kiállított, valódi, kifizetetlen számlát, amelynek van fizetési határideje, **és a vevőhöz van mentett e-mail-cím**. **Az automata kikapcsolt állapotból indul, és kétszeresen védett:** - **Csak Pro csomagtól felfelé** működik. A kapcsoló beállítása a fiókban marad csomag-visszaesésnél is, ezért az automata futása is ellenőrzi a csomagot – enélkül egy visszaesett fiók **nevében** menne tovább vevői levelezés. - **A bekapcsolás megerősítés-köteles:** az AI nem kapcsolja be, csak megerősítő kártyát mutat, és a „Bekapcsolom” gomb hívja a védett beállítási útvonalat. Így egy beszúrt utasítás (prompt injection) nem tudja csendben elindítani a kifelé menő levelezést. A **kikapcsolás azonnali**. **További védelmek:** - **Fizetési ígéret némítja az automatát.** Ha rögzítetted, melyik napon fizet a vevő, addig (az ígért napot is beleértve) nem megy levél. Ha az ígért nap fizetés nélkül telik el, a lánc ott folytatódik, ahol abbamaradt. - **Friss fizetettség-ellenőrzés közvetlenül a küldés előtt** – a futás kezdete óta lehet, hogy a vevő fizetett. - **Duplázás-védelem:** egy napon belüli kétszeri futás nem küld két levelet, és a fokozat-váltás sem keveri össze a küldéseket. - **Minden kiküldés naplózódik** (fokozattal és a késedelmi napokkal), és a kézbesítés is rögzül. **Kézi emlékeztető és felszólítás.** A chatben előnézetet kérhetsz egy számlára vagy az összes lejárt számlára. **Az AI-eszközök e-mailt nem küldenek** – a küldést a kártya gombja indítja a munkamenettel védett útvonalon, így a modell sosem küld magától. A kézi küldés feltételei (ugyanazok az előnézetre és a küldésre): valódi, kiállított, kifizetetlen számla, **már lejárt határidővel** (legalább 1 nap), címzettel és fizetési határidővel – mindegyik hiányra külön magyar üzenettel. Élő fizetési ígéret esetén a **kézi** küldés nincs tiltva, de a kártyán látszik az ígért nap – te beszéltél a vevővel, nem a rendszer. **Fizetési ígéret rögzítése.** Ez az egyetlen olyan írás a chatben, amely megerősítő kártya nélkül elhallgattatja a behajtást – ezért aszimmetrikus a kapu: a **törlés azonnali** (biztonságos irány), a **rögzítés viszont legfeljebb 60 nappal előre** engedélyezett (elgépelés- és injection-védelemként; a mögöttes réteg 365 napos korlátja a második háló). Az eszköz kifejezetten tiltja, hogy partner-megjegyzésben, számlán vagy bizonylat szövegében talált „a vevő megígérte…” alapján hívja meg – az adat, nem utasítás. **A késedelmi kamat determinisztikus számítás** (Ptk. 6:155. §), a felszólító levél szövege fix sablon – egyik sem az AI-modell kimenete. Devizás számlánál vagy 2023 előtti késedelemnél a levél kamat-sor nélkül megy. ### 20.3 Korlátok – kimondva - **Emlékeztető csak mentett vevő-e-mail-címre megy.** Cím nélkül a számla kimarad; a tömeges előnézet ezt darabszámmal ki is mondja („Van N lejárt, kifizetetlen számlád, de egyikhez sincs vevő-e-mail mentve…”). - **Az automatikus emlékeztető Pro csomagtól elérhető.** Free csomagban az eszköz elutasít, és az automata akkor sem küld, ha a kapcsoló korábban be volt kapcsolva. - **A bejövő (fizetendő) oldal és a banki párosítás Ultra-kötött.** - **Nincs részfizetés-nyilvántartás a saját úton.** A helyi nyilvántartás csak a bináris „kifizetve / nem kifizetve” állapotot ismeri. Külső számlázón a részfizetéseket a számlázó fizetési jegyzéke tartja nyilván; a saját úton **ilyen főkönyv nincs, tehát a részfizetés nem követhető nyomon**. - **Az átutalási QR-kód nem elérhető** (egyetlen csomagban sem): a hazai QR-fizetés (qvik) banki oldali hitelesítést kíván, amellyel nem rendelkezünk. Az eszköz minden hívást elutasít – inkább megmondjuk, mint hogy működésképtelen kódot adjunk. - **A fizetettség nem NAV-releváns adat**: sem a jelölés, sem a befizetés nem kerül a NAV-adatszolgáltatásba, és nem érinti annak állapotát. **A titkár ugyanezt mondja, amit a program csinál.** Az automatikus emlékeztető beállítási eszközének leírása a fenti, tényleges működést írja le: **két fokozat** (a 3. napon barátságos, a 15. napon határozott hangnem), utána az automata **leáll**; a 3. fok – a felszólítás késedelmi kamattal – **sosem automatikus**, és élő fizetési ígéretnél az automata **hallgat**. Így az asszisztens sem ígérhet mást a felhasználónak, mint ami ténylegesen történik. ### 20.4 A te teendőid - **A fizetettség rögzítése kézi lépés** (Ultra alatt banki párosítással megerősíthető) – a rendszer magától nem tudja, mi folyt be a bankszámládra. - **Az automatikus emlékeztetőt tudatosan kell bekapcsolnod** a kártya gombjával, és **vevői e-mail-címeket kell mentened a partnerekhez**, különben az automata nem tud kihez fordulni. - Ha megbeszélted a vevővel a fizetés napját, **rögzítsd fizetési ígéretként** – addig nem megy ki gépi sürgetés a nevedben. - **A 3. fok (felszólítás késedelmi kamattal) mindig a te tudatos döntésed**; a rendszer csak felkínálja a Pénzügyi teendők sávban. --- ## 21. A nem számlázási célú funkciók elhatárolása A 23/2014. (VI. 30.) NGM rendelet 10. § (2) bekezdése előírja, hogy a dokumentációnak tartalmaznia kell a program működésének részletes leírását és **valamennyi funkció ismertetését** – ha tehát a program a számlázáson kívül mást is ellát, a számlázási célú funkciókat **el kell határolni** a többitől. Ez a fejezet ezt az elhatárolást végzi el, teljes funkciólistával. A 10. § (2) második mondata azt is kimondja, hogy **„a számlázó program kizárólag a felhasználói dokumentációban szereplő funkciókat hajthatja végre”**. Ebből a Szolgáltatóra kötelezettség hárul: **új funkció csak akkor élesíthető, ha ebben a dokumentumban már szerepel.** Ez a szabály a környezeti kapcsolóval elérhetővé tehető funkciókra is kiterjed: az eÁFA gépi beadás két eszköze mindaddig nincs a készletben, amíg a kapcsoló ki van kapcsolva, és a bekapcsolása **csak e dokumentum előzetes kiegészítésével** történhet meg (26.4). Ugyanez érvényes minden jövőbeli eszköz-bővítésre. A titkár.ai egyetlen, folytonos chat-felület: nincs külön menürendszer, minden funkciót természetes nyelvű kéréssel indítasz. A felszín alatt viszont a funkciók **zárt, névvel azonosított eszközkészletet** alkotnak. A készlet **102 eszközből** áll, és minden felhasználónál, minden csomagban ugyanez a 102 kulcs (kontraktus-teszt rögzíti). Ehhez jön két további eszköz, ha az eÁFA gépi beadás környezeti kapcsolója be van kapcsolva – az éles környezetben 2026. augusztus 18. óta **be van kapcsolva**, tehát ez a két eszköz jelen van (26.4 és a 21.2 pont 6. blokkja). ### 21.1 Ami a számlázó program része (nem tartozik az elhatárolás alá) Az alábbi funkciók a rendelet értelmében vett **számlázási cél** körébe esnek: bizonylatot állítanak elő, módosítanak, olvasnak vissza, vagy a bizonylathoz kapcsolódó jogszabályi adatszolgáltatást teljesítik. | Funkció | Mit csinál | |---|---| | `create_invoice` | Számla-vázlat készítése, előnézettel (rendes, előleg-, vég-, gyűjtő- és egyszerűsített számla – 9.13) | | `create_proforma` | Díjbekérő-vázlat készítése | | `duplicate_invoice` | Korábbi számla megismétlése új bizonylatként | | `storno_invoice` | Sztornó (érvénytelenítő) számla előkészítése | | `create_corrective_invoice` | Helyesbítő (módosító) számla előkészítése (13.5) | | `prepare_bulk_issue`, `prepare_bulk_multi_issue` | Tömeges bizonylat-kiállítás előkészítése | | `set_recurring_invoice`, `list_recurring_invoices`, `update_recurring_invoice`, `delete_recurring_invoice`, `issue_recurring_now` | Ismétlődő számlázás ütemezése és kiállítása. Az **ütemezés létrehozása** (`set_recurring_invoice`) Pro és Ultra csomag funkciója (12.1) | | `ask_buyer_identity`, `ask_invoice_items`, `ask_invoice_recipient` | A hiányzó bizonylat-adatok bekérése űrlap-kártyán | | `get_invoice`, `list_invoices` | Kiállított bizonylatok visszaolvasása | | `get_invoice_pdf` | Számlakép (PDF) előállítása | | `prepare_send_invoice_email`, `prepare_bulk_email` | A számlakép kiküldése a vevőnek e-mailben | Ugyanígy a számlázó program része a **jogszabályi adatszolgáltatás-réteg** – ezek a funkciók egyetlen csomagban sincsenek korlátozva, mert jogszabályi kötelezettség teljesítését szolgálják: | Funkció | Mit csinál | Jogalap | |---|---|---| | `check_nav_status` | A NAV-kapcsolat és a beküldések állapota | 13/A. § | | `get_nav_submission_status` | Egy konkrét számla adatszolgáltatásának állapota | 13/A. § | | `retry_nav_submission` | Elakadt adatszolgáltatás ismételt beküldése | 13/A. § (4) | | `export_invoice_data` | Adóhatósági ellenőrzési adatszolgáltatás (XML) | 11/A. § | ### 21.2 A nem számlázási célú funkciók teljes listája Az alábbi funkciók **nem** a számlázási célt szolgálják. Nem állítanak elő és nem módosítanak bizonylatot, és nem vesznek részt a NAV-adatszolgáltatásban. Ezek kényelmi, nyilvántartási és elemző funkciók. **1. Partner- és cégadat-nyilvántartás** | Funkció | Mit csinál | Csomag | |---|---|---| | `find_partner`, `list_partners`, `get_partner` | Mentett vevők keresése, listázása, megnyitása | minden | | `save_partner`, `propose_partner` | Vevő mentése a saját nyilvántartásba | minden (Free: max. 3 mentett partner) | | `edit_partner`, `delete_partner` | Mentett vevő módosítása, törlése | minden | | `check_partner_tax_status` | Adószám ellenőrzése a NAV adóalany-nyilvántartásában | minden | | `search_company_by_name` | Cégkeresés név alapján, webes forrásból | minden | | `get_company_profile` | Nyilvános cégadatok lekérése (ceginformacio.hu) | minden | A `search_company_by_name` és a `get_company_profile` **külső, nyilvános forrásból** dolgozik. Az onnan kapott adat tájékoztató jellegű, késhet vagy pontatlan lehet – a számlára kerülő vevőadatért te felelsz. **2. Fizetettség és behajtás** | Funkció | Mit csinál | Csomag | |---|---|---| | `mark_invoice_paid`, `register_payment` | Már megtörtént befizetés utólagos rögzítése | minden | | `prepare_bulk_paid` | Több számla egyszerre kifizetettnek jelölése | minden | | `ask_payment_target` | A befizetéshez tartozó számla tisztázása | minden | | `set_payment_promise` | Vevői fizetési ígéret rögzítése | minden | | `prepare_payment_reminder`, `prepare_bulk_payment_reminder` | Fizetési emlékeztető szövegének előkészítése | minden | | `prepare_payment_demand` | Fizetési felszólítás előkészítése | minden | | `set_payment_reminders` | Automatikus emlékeztető-küldés be-/kikapcsolása | Pro, Ultra | | `calculate_late_interest` | Késedelmi kamat kiszámítása | Pro, Ultra | A fizetettség a program **saját nyilvántartásában** rögzül. **A rendszer fizetést vagy átutalást nem indít, és erre nincs is eszköze.** **3. Bejövő (szállítói) számlák és kiadás-nyilvántartás** – mind Ultra csomaghoz kötött | Funkció | Mit csinál | |---|---| | `list_supplier_invoices`, `get_supplier`, `summarize_payables` | Bejövő számlák és tartozások áttekintése | | `import_supplier_invoices_from_nav` | Bejövő számlák behúzása a NAV Online Számla adataiból | | `import_supplier_invoice_items`, `import_missing_supplier_invoice_items` | A behúzott számlák tételsorainak lekérése | | `mark_supplier_invoice_paid` | Bejövő számla kifizetettnek jelölése (utólagos rögzítés) | | `list_inbound_documents` | E-mailben érkezett bizonylatok listája | | `list_reverse_charge_suspects` | Fordított adózás gyanúja (tájékoztató) | | `record_expense` | Kézi kiadás-rögzítés | A bejövő számlákhoz a program **nem készít PDF-et és nem küld e-mailt** – ezek nem a titkár.ai által kibocsátott bizonylatok. **4. Kontírozás (előkönyvelés) és tanulás** – mind Ultra csomaghoz kötött | Funkció | Mit csinál | |---|---| | `precode_supplier_invoice`, `precode_inbound_invoices` | Bejövő számla javasolt előkönyvelése | | `get_learning_profile` | Mit tanult a rendszer a korábbi könyvelésekből | | `list_accountant_corrections`, `get_accountant_feedback` | A könyvelő visszajelzései, korrekciói | **Az előkönyvelés javaslat, nem könyvelés.** A számviteli és adójogi minősítés a könyvelődé; a rendszer által javasolt kontírozás nem helyettesíti azt. **5. Bank** – mind Ultra csomaghoz kötött | Funkció | Mit csinál | |---|---| | `connect_bank_account` | Bankszámla összekötése (**jelenleg kikapcsolva**) | | `list_bank_connections`, `list_bank_accounts` | Bekötött bankok, számlák | | `list_bank_transactions` | Banki tételek listája | | `list_bank_matches` | Banki tétel ↔ számla párosítás | **Az automatikus banki összekötés a programban kemény kapcsolóval ki van kapcsolva.** Ma kizárólag a **kézzel feltöltött CSV-bankkivonat** működik. A `connect_bank_account` erről magyar mondattal tájékoztat. A banki adat **kizárólag olvasásra** szolgál: a rendszer bankszámla-műveletet nem hajt végre. **6. Áfa-analitika és eÁFA-előkészítés** | Funkció | Mit csinál | Csomag | |---|---|---| | `build_vat_analytics_draft` | eÁFA áfa-analitika tervezet összeállítása (helyben) | Ultra | | `query_invoice_tax_code`, `suggest_tax_codes` | Áfakód-lekérdezés és -javaslat | Ultra | | `summarize_vat` | Áfa-becslés egy időszakra | Ultra | | `check_aam_limit` | Az alanyi adómentes értékhatár állása | minden | | `prepare_vat_declaration_submission` | eÁFA-bevallás beadásának ELŐKÉSZÍTÉSE: a tervezet feltöltése a NAV eÁFA-rendszerébe (feltöltés → partíció → véglegesítés), eredmény megerősítő kártyán | Ultra | | `check_vat_declaration_status` | Folyamatban lévő beadás NAV-oldali feldolgozási állapotának lekérdezése | Ultra | Az analitika-, adókód- és becslés-funkciók **nem küldenek adatot a NAV-hoz**, és **tájékoztató jellegűek**; az áfa minősítése a te (illetve a könyvelőd) feladata marad. A két beadás-előkészítő eszköz a NAV eÁFA-rendszerébe tölt, de **bevallást nem nyújt be**: a benyújtás kizárólag a megerősítő kártya „Beadom” gombjával, az asszisztenstől független, hitelesített végponton történik (26.4). **7. Kimutatások, riportok, könyvelői export** | Funkció | Mit csinál | Csomag | |---|---|---| | `summarize_revenue`, `revenue_breakdown` | Bevétel-összesítő és bontás | minden | | `top_debtors`, `aging_report` | Adós-rangsor, kintlévőség kora | minden | | `set_accountant_email` | A könyvelő e-mail-címének megadása | minden | | `compare_period` | Időszakok összevetése | Ultra | | `forecast_cashflow` | Pénzmozgás-előrejelzés | Ultra | | `expense_breakdown`, `profit_summary` | Kiadás-bontás, eredmény-összesítő | Ultra | | `export_for_accountant` | Könyvelői CSV-export (kimenő + bejövő) | Ultra | | `prepare_accountant_package` | Könyvelői csomag összeállítása és küldése | Ultra | | `set_accountant_auto_send` | Automatikus havi könyvelői küldés kapcsolója | Ultra | Az `export_for_accountant` **nem azonos** a 11/A. § szerinti adóhatósági ellenőrzési adatszolgáltatással – az utóbbi az `export_invoice_data` (lásd 21.1 és a 17. fejezet). **8. Kontroll, határidők, saját emlékeztetők** – mind minden csomagban | Funkció | Mit csinál | |---|---| | `get_control_overview` | Nyitott teendők áttekintése | | `get_upcoming_deadlines` | Közelgő adó- és bevallási határidők | | `set_control_digest` | Teendő-összefoglaló e-mail kapcsolója | | `set_reminder`, `list_reminders`, `complete_reminder` | Saját emlékeztetők | | `set_hipa_liability` | Iparűzési adó (HIPA) érintettség rögzítése | | `set_vat_filing_frequency` | Áfabevallási gyakoriság rögzítése | **Ezek a funkciók kizárólag emlékeztetnek** – maguk semmilyen bevallást nem adnak be és semmilyen adót nem fizetnek be. Bevallás benyújtására egyedül az eÁFA megerősítő kártyája ad utat (a 6. blokk és 26.4), ott is a te gombnyomásoddal; adót a rendszer semmilyen formában nem fizet be. **9. Beállítás, memória, előfizetés** | Funkció | Mit csinál | Csomag | |---|---|---| | `get_my_company` | A saját fiók áttekintése: a NAV adóalany-nyilvántartásából ismert cégnév, adószám és székhely, a NAV-kapcsolat állapota (teszt vagy éles), a csomag, a havi számlakeret állása és a számlázási alapértékek. Csak olvas. | minden | | `manage_plan` | Csomag-információ és -váltás kártyája | minden | | `set_invoice_preferences` | Alapértelmezett számlázási beállítások | Pro, Ultra | | `remember` | Tartós megjegyzés a felhasználóról | Pro, Ultra | | `list_item_templates`, `save_item_template` | Tétel-sablonok | Pro, Ultra | **10. Asszisztens-funkciók** – mind minden csomagban | Funkció | Mit csinál | |---|---| | `search_conversation` | Visszakeresés a saját beszélgetés szövegében | | `suggest_followups` | Folytatás-javaslatok (kattintható chipek) a felületen | | `contact_support` | Támogatási jegy előkészítése (28.2) | | `get_activity_log` | Tevékenységnapló lekérése (24.4) | | `get_exchange_rate` | MNB-árfolyam lekérdezése | **11. Korábbi kimenő számlák behúzása a NAV-ból** | Funkció | Mit csinál | Csomag | |---|---|---| | `import_invoices_from_nav` | Korábbi kimenő számlák behúzása a NAV adataiból | Pro, Ultra | **12. Kikapcsolt funkció** | Funkció | Állapot | |---|---| | `get_payment_qr` | Hazai QR-fizetés (qvik). **Minden csomagban elutasít**, mert az 57/2022. (XII. 22.) MNB rendelet szerinti hitelesítő kódhoz GIRO-tanúsítvány kell, amivel a titkár.ai nem rendelkezik. Ez nem csomag-, hanem funkció-korlát. | ### 21.3 Az elhatárolás lényege A fenti, 21.2 pont alatti funkciók egyike sem befolyásolja: - a bizonylat **sorszámozását** (8. § (1) a)), - a bizonylat **adattartalmát**, - a bizonylat **állapotát** (kiállított / sztornózott), - a **NAV-adatszolgáltatás** tényét, tartalmát vagy időpontját. A bizonylat-kibocsátó mag és a NAV-adatszolgáltatás a fenti kényelmi funkciók kikapcsolása vagy hibája esetén is változatlanul működik. --- ## 22. Az AI-asszisztens szerepe és korlátai A titkár.ai kezelőfelülete természetes nyelvű: a kérésedet nagy nyelvi modell (LLM) értelmezi. Mivel ez a rendelet 10. § (2) bekezdése szempontjából is magyarázatot igényel, ez a fejezet pontosan leírja, **mit tesz és mit nem tesz** a modell. ### 22.1 A modell zárt eszközkészletből dolgozik A modell nem fér hozzá a rendszerhez szabadon: kizárólag a 21. fejezetben felsorolt, **névvel azonosított 102 eszköz** valamelyikét hívhatja meg. Nem tud SQL-t futtatni, nem tud tetszőleges HTTP-kérést küldeni, nem tud fájlt írni, és nem tud a felsoroltakon kívüli műveletet végrehajtani. Az eszközök a felhasználói fiók (bérlő) azonosítóját **zárt környezetben (closure-ben) hordozzák**: az azonosító sosem kerül a modell elé, és a modell nem tudja átírni. Ennek következtében a modell nem tud más felhasználó adatához nyúlni, akkor sem, ha erre utasítást kap. **A NAV technikai felhasználó adatai – jelszó, aláírókulcs, XML cserekulcs – soha nem kerülnek a modellhez.** A NAV-hívások szerveroldalon, a modelltől elkülönítve futnak (6.6 és 24.3). ### 22.2 A NAV-adatszolgáltatás XML-jét nem a modell állítja elő Ez a fejezet legfontosabb állítása. **A NAV-nak küldött `InvoiceData` XML-t determinisztikus, tesztelt kód generálja, nem a nyelvi modell.** A lánc a következő, és minden lépése a kiállítási adatbázis-tranzakción belül, szerveroldalon fut: ``` jóváhagyott bizonylat-adat → NAV-leképező (mapper) → XML-előállító → NAV ``` Ebből következően: - **A számokat nem a modell számolja.** A nettó, áfa és bruttó értékeket, az áfa-összesítőt és a HUF-ra átszámított értékeket a számítási réteg állítja elő. - **A sorszámot nem a modell adja.** A sorszámot az allokátor osztja ki, a kiállítási tranzakción belül (8.3, 23.3). - **A NAV-XML-t nem a modell fogalmazza.** A modell természetes nyelvű mezőket ad át (vevő neve, tétel megnevezése, mennyiség, egységár); a leképezést az áfakódra, a mennyiségi egység kódjára és a vevő-státuszra a mapper végzi, kódba írt szabályokkal. - **Az adóhatósági ellenőrzési adatszolgáltatás XML-je sem megy át a modellen.** Az `export_invoice_data` eszköz csak a darabszámot, a tartományt és a letöltési hivatkozást adja vissza; a fájlt a szerver állítja elő (17.1). Ha a mapper egy adatot nem tud egyértelműen leképezni, **nem tippel, hanem megtagadja a műveletet** és pontosítást kér (a részletes listát a 26.3 pont tartalmazza). ### 22.3 Minden visszafordíthatatlan lépés megerősítő kártyán megy A bizonylat-eszközök **nem állítanak ki semmit**. Amit adnak, az egy **előnézeti kártya** a chatben. A tényleges kiállítás akkor és csak akkor indul el, amikor te a kártyán a gombra kattintasz – az a kattintás hív egy védett szerver-végpontot, amit a modell nem tud meghívni. **Ez nem egyetlen kapcsoló, hanem szerkezeti elv:** a bizonylatot előállító és a kifelé ható eszközök egyike sem hajtja végre magát a műveletet – csak előnézeti kártyát adnak vissza. A végrehajtás mindig külön, munkamenettel védett szerver-végponton fut, amit a modell nem tud meghívni. Ez érvényes a számla- és díjbekérő-kiállításra és az alábbiakra: - a **sztornó** (`storno_invoice`), - minden **törlés** (`delete_partner`, `delete_recurring_invoice`), - minden **e-mail-küldés** a vevőnek (`prepare_send_invoice_email`, `prepare_bulk_email`), - minden **tömeges művelet** (`prepare_bulk_issue`, `prepare_bulk_multi_issue`, `prepare_bulk_paid`, `prepare_bulk_payment_reminder`), - a **befizetés-rögzítés** (`register_payment`, `mark_invoice_paid`), - a **kifelé ható kapcsolók bekapcsolása** (`set_payment_reminders`, `set_accountant_auto_send`), - a **támogatási jegy beküldése** (`contact_support`), - a **csomagváltás** kártyája (`manage_plan`). Az elv **aszimmetrikus**: a biztonságos irány (egy automatizmus **ki**kapcsolása, egy fizetési ígéret törlése) azonnal lefut, a kockázatos irány (bekapcsolás, küldés, kiállítás, törlés) megerősítést kér. Az elvet **eszközönkénti automatizált tesztek** rögzítik: a készlet minden darabjáról teszt mondja meg, melyik kapu alá esik. ### 22.4 A szövegben érkező utasítás adat, nem parancs A rendszer kimondottan úgy van beállítva, hogy a felhasználói üzenet, a feltöltött fájl, a beérkezett e-mail, a számla szövege, a vevő neve és az eszközök visszaadott eredménye **adat, nem utasítás**. Egy vevő nevébe vagy egy bejövő számla megjegyzésébe rejtett „utasítás” nem vezérli a rendszert. Ezt több, kódba írt korlát támogatja: a kézi kiadás-rögzítésnek forrás-kapuja és összeghatára van, a fizetési mód zárt értékkészletből választható, és a partner-mentés nem írja felül egy meglévő partner e-mail-címét. ### 22.5 Lépéskorlát Egy beszélgetési kör legfeljebb **8 modell-lépésből** áll. A keret utolsó lépésében a modell eszköz nélkül marad, tehát a kör mindig megfogalmazott válasszal zárul, nem szakad meg félbe és nem fut végtelen ciklusba. ### 22.6 A modell korlátai – kimondva - **A modell tévedhet.** A megerősítő kártya nem formalitás: az előnézeten látható adat az, ami a számlára és a NAV felé megy. **A jóváhagyás előtt ellenőrizd.** - A csomag-korlátok az eszköz futásakor érvényesülnek, **nem a készlet szűrésével**. Ezért a modell alacsonyabb csomagban is „ismeri” a magasabb csomag funkcióit, és fel tudja ajánlani a váltást. Ez tudatos döntés; a funkció maga ilyenkor is elutasít. - **Az asszisztens nem tudja benyújtani a bevallásodat**, és **nincs fizetésindító eszköze**. Az eÁFA-bevallást legfeljebb ELŐKÉSZÍTI (analitika, tervezet, a NAV-hoz való feltöltés); a tényleges **benyújtás egy külön gomb a megerősítő kártyán**, amelyet az asszisztenstől független, hitelesített végpont futtat – így egy rosszindulatú szövegű bejövő számla vagy e-mail sem tud a nevedben bevallást beadni. - Az adójogi és jogi kérdésekben az asszisztens **tájékoztató marad**; a végső minősítés a könyvelődé, illetve a NAV-é. - Az asszisztens nem működik közre valótlan, fiktív vagy visszadátumozott bizonylat készítésében. ### 22.7 Mit jelent ez a felelősségre A számlakiállítás **a te kifejezett megerősítésed után**, az általad jóváhagyott előnézet alapján történik, és **visszafordíthatatlan** (sztornózható, de nem törölhető). Nincs kizárólag automatizált döntéshozatal: ember – te – van a hurokban. **A kiállított számla adattartalmáért az, aki az előnézetet jóváhagyta, tehát a felhasználó felel** ([ÁSZF](./aszf.md) 6.3. pont); a Szolgáltató az előnézettel és a NAV-adat visszaolvasásával segít. --- ## 23. Csomagkorlátok mint működési korlát A titkár.ai három előfizetési csomagban érhető el: **Free**, **Pro**, **Ultra**. A csomagok nemcsak árban különböznek: egyes funkciók magasabb csomaghoz kötöttek, a Free csomagnak pedig **havi darabszám-kerete** van a kiállított számlákra. Ez a fejezet a kereteket **működési korlátként** írja le – nem árlistaként. ### 23.1 Számszerű keretek | Keret | Free | Pro | Ultra | |---|---|---|---| | Éles számla / hó (`kind='invoice'`) | **5** (kemény korlát, blokkol) | fair-use 75 (**nem blokkol**) | fair-use 400 (**nem blokkol**) | | Mentett partner | **3** | korlátlan | korlátlan | | AI-üzenet / nap | 20 | 200 | 1000 | | Díjbekérő | nem érhető el | igen | igen | | Ismétlődő ütemezés létrehozása | nem érhető el | igen | igen | | Ismétlődő ütemezés **automatikus** kiállítása | nem érhető el | nem érhető el | igen | **A havi számla-keret értelmezése:** - Csak az **éles számla** számít bele. A **díjbekérő és a nyugta nem**. - **A sztornó okirat és a NAV-ból importált számla beleszámít**, mert mindkettő önálló számla-bizonylatként keletkezik. - **A később sztornózott számla is beleszámít**, mert a metrika a kiállítás ténye. Nincs „sztornózd és állítsd ki újra” kerülőút. - A hónaphatárt az adatbázis szerveridő szerinti naptári hónapja adja. **A fizetős csomagok fair-use szintje nem korlát:** a 75, illetve 400 darab felett a rendszer legfeljebb halkan jelez, de **soha nem blokkolja a számlázást**. Ezt az [ÁSZF](./aszf.md) 5.1 pontja is rögzíti. **A napi AI-üzenetkeret a beszélgetést korlátozza, nem a számlázást.** Ha a napi keret kimerül, az asszisztens a keret megújulásáig nem elérhető; ez nem érinti a már kiállított bizonylatokat és nem érinti a NAV-adatszolgáltatást. ### 23.2 Funkció-korlátok csomagonként - **Ultra csomaghoz kötött (31 funkció):** a teljes bejövő (szállítói) oldal, a kézi kiadás-rögzítés, a bank, az áfa-analitika és az eÁFA-előkészítés, a mély kimutatások (időszak-összevetés, előrejelzés, kiadás-bontás, eredmény), valamint a teljes könyvelői réteg (CSV-export, könyvelői csomag, automatikus küldés, könyvelői visszajelzés, tanult profil). - **Pro és Ultra csomaghoz kötött (10 funkció):** díjbekérő készítése, NAV-import, automatikus fizetési emlékeztető, alapértelmezett számlázási beállítások, tartós megjegyzés, tétel-sablonok, késedelmi kamat. A tömeges kiállítás **csak díjbekérő esetén** Pro-kötött: rendes számlára Free csomagban is működik. - **Minden csomagban elérhető (57 funkció):** az alap kimenő számlázás, a partner-kezelés, a befizetés-rögzítés, a kimenő oldali áttekintő kimutatások, az alanyi adómentes értékhatár figyelése, valamint – kifejezetten szándékosan – a **NAV-adatszolgáltatás állapota és újraküldése** (`get_nav_submission_status`, `retry_nav_submission`) és az **adóhatósági ellenőrzési adatszolgáltatás** (`export_invoice_data`). - **Egyéb, feltételesen kapuzott (4 funkció):** a vevő mentése és mentésre ajánlása (`save_partner`, `propose_partner`) minden csomagban elérhető, de Free csomagon legfeljebb **3 mentett partnerig**; az **ismétlődő ütemezés létrehozása** (`set_recurring_invoice`) **Pro és Ultra** csomag funkciója (12.1); az átutalási QR-kód (`get_payment_qr`) pedig **funkció-kapcsolóval, minden csomagban** ki van kapcsolva (21.2/12. pont). A négy felsorolás **együtt** adja ki a 21. fejezet szerinti 102 eszközt (31 + 10 + 57 + 4). A besorolás hiánytalanságát automatikus teszt kényszeríti ki. Ez utóbbi elvi döntés: **jogszabályi kötelezettség teljesítése nem függhet előfizetéstől.** A 13/A. § szerinti adatszolgáltatás és a 11/A. § szerinti adóhatósági ellenőrzési adatszolgáltatás ezért a Free csomagban is teljes körűen elérhető. Ha egy funkció a csomagodban nem érhető el, a rendszer **magyar mondattal, a szükséges szint megnevezésével** utasít el („…az Ultra csomag része”, „…a Pro és Ultra csomag része”). ### 23.3 A blokkolt kiállítás nem oszt sorszámot A kiállítás sorrendje: (1) **csomag- és kvótakapu** – a Free havi keret ellenőrzése és a díjbekérő-kapu a kiállítási végponton, **a kiállítási művelet meghívása előtt** fut; elutasításnál HTTP 402 a válasz, gépi hibakóddal (`free_limit`), hogy a felületen csomagváltási lehetőség jelenjen meg zsákutcás hiba helyett; (2) **biztonsági kapuk** (24.2); (3) **csak ezek után** indul a kiállítási adatbázis-tranzakció, és a sorszám kiosztása ezen belül történik. Ebből következik, hogy egy elutasított vagy elhasalt kiállítás **nem oszt sorszámot és nem hagy hézagot** – a levezetést és a párhuzamossági igazolást a **8.3 és 8.6 pont** tartalmazza. ### 23.4 Csomagváltás A csomagváltást a chatben kérheted; a rendszer a csomagkártyát nyitja meg. **A fizetés minden esetben a Stripe fizetési felületén történik** – az asszisztens fizetést sosem indít, és bankkártyaadatot nem lát. **Az előfizetés díjszámlája és az adószámod (9. § (2)).** A rendelet szerint a számlázó program csak adóalanynak értékesíthető, és a Szolgáltató köteles a díjszámlán feltüntetni a beszerző adószámát. Ezért a fizetési felület bekéri az adószámot; ha pedig a fiókodhoz **éles NAV technikai felhasználó** van bekötve, a rendszer a NAV adóalany-lekérdezésével igazolt adószámodat automatikusan ráteszi a számlázási adataidra – ez az adóalanyiságod legerősebb igazolása, és így a díjszámládra biztosan a helyes adószám kerül. ### 23.5 A Free csomag mentett-partner kerete A Free csomagban legfeljebb **3 mentett partner** (vevő-memória) tárolható; a Pro és az Ultra csomagban a mentett partnerek száma korlátlan. A keret az [ÁSZF](./aszf.md) 5. pontjának csomagtáblázatában is szerepel — a két dokumentum ugyanazt mondja. --- ## 24. Biztonsági korlátok és az audit-napló ### 24.1 Hitelesítés és hozzáférés A belépési módokat (e-mail + jelszó, Google-fiók, azonosítókulcs, magic link, kétlépcsős azonosítás) és a munkamenet szabályait az 5.2 pont sorolja fel. Az azonosítókulcs a domainhez van kötve, tehát más domainről nem használható fel. A kétlépcsős azonosítás ellenőrző végpontjai **percenként 5 kérésre** vannak korlátozva. A szerveroldali **JSON-végpontok** közös burkolón mennek át, amely egységesen kezeli a hozzáférést: **401** (nincs érvényes munkamenet) · **403** (a csomag nem jogosít) · **429** (túl sok kérés) · **500** (hiba; a részletek a hibakövető rendszerbe kerülnek, a felhasználó általános üzenetet lát). A két **fájl-letöltő** végpont – a számlakép PDF-je és a 11/A. § szerinti adóhatósági ellenőrzési adatszolgáltatás – a burkolón **kívül** él, mert nem JSON-t ad vissza. Ezeken is szerveroldali munkamenet-ellenőrzés és tenant-hatókör-ellenőrzés fut (bejelentkezés nélkül 401, idegen bizonylatra 404), **kérés-korlát (429) viszont nincs rajtuk**. **A felhasználóhoz tartozó bérlő azonosítását mindig a szerver végzi**, a kérésből érkező adat alapján soha. A kiállítás és a sztornó **percenként 10 kérésre** korlátozott fiókonként, és ez a korlát **zárt hibamódú**: ha a korlátozó szolgáltatás nem elérhető, a rendszer nem enged át kérést, hanem elutasít. ### 24.2 Opcionális kiállítás-védelem A Beállítások → Biztonság alatt négy, egymástól független korlátot állíthatsz be. **Ezek opcionálisak: ha nem állítasz be semmit, a rendszer a teljes ellenőrzést átugorja, és a kiállítás a szokásos módon megy.** | Beállítás | Mit csinál | |---|---| | **Összegplafon** (`maxInvoiceGrossHuf`) | Egy számla bruttó végösszegének kemény felső határa. Fölötte a kiállítás **blokkolt** (nem megerősítéssel feloldható). Az elgépelt nagy összeg ellen véd. | | **Napi darabszám-korlát** (`dailyInvoiceLimit`) | Naponta legfeljebb ennyi számla állítható ki. Fölötte a kiállítás **blokkolt**. A megfutó sorozat ellen véd. | | **Megerősítés-mód** (`stepUpMode`) | `off` / `threshold` (adott bruttó felett) / `always`. Bekapcsolva a kiállításhoz **friss azonosítókulcsos hitelesítés** kell. | | **Megerősítési küszöb** (`stepUpThresholdHuf`) | A `threshold` módhoz tartozó bruttó összeghatár. | A döntés sorrendje szándékos: **előbb a kemény blokkok** (napi darabszám, összegplafon), **csak utána a megerősítés-kérés** – egy blokkolt számlát a rendszer megerősítés után se küldjön ki. A friss hitelesítés bizonyítéka **5 percig érvényes és egyszer használható fel**; kizárólag a sikeres azonosítókulcsos hitelesítés hozza létre. A napi darabszám-korlát **atomi foglalással**, adatbázis-szintű sorzárolással működik, a ténylegesen kiállított darabszámmal szinkronban; ha a kiállítás mégis elhasal, a foglalás visszaadódik. Nem forint alapú számlánál a bruttó összeget a rendszer **napi MNB-középárfolyamon** váltja forintra az összehasonlításhoz. **A két kemény korlát** (összegplafon, napi darabszám) **központi ponton** érvényesül: a tömeges kiállítás és az ismétlődő számlázás ütemezett futása sem tudja megkerülni őket (12.3). **A megerősítés-mód hatóköre viszont szűkebb:** az az általad indított kiállítási utakon fut (az egyedi és a tömeges kiállításon), valamint az eÁFA-beadáson és az automatikus ismétlődő mód bekapcsolásán. **Az automatikus ismétlődő kiállítás maga nem kér kiállításonként friss hitelesítést** (5.5, 12.1). **Korlát:** az előnézeti szakaszban a napi darabszám **nem** kerül kiszámításra (ott nullának számít); az igazságforrás a kiállításkori atomi foglalás. Ennek oka, hogy egy előre számolt darabszám téves korai blokkoláshoz vezethetne. ### 24.3 Titokkezelés Minden integrációs kulcs – és a NAV technikai felhasználó jelszava, XML aláírókulcsa és XML cserekulcsa – **AES-256-GCM** titkosítással, kérésenként egyedi inicializáló vektorral és hitelesítő taggel tárolódik; a visszafejtés **kizárólag szerveroldalon** történik, és a kulcsok **soha nem kerülnek a kérésbe, a böngészőbe és a nyelvi modellhez**. A tárolás részleteit a 6.6 pont tartalmazza. A NAV felé irányuló hitelesítés a hivatalos Online Számla 3.0 előírás szerint **SHA-512** (jelszó-lenyomat) és **SHA3-512** (kérés-aláírás) algoritmussal készül; a számla-beküldés aláírása a művelet-indexek lenyomatait is tartalmazza. ### 24.4 Az audit-napló A rendszer **hozzáfűzéses (append-only) audit-naplót** vezet, fiókonként elkülönítve. A napló minden sora tartalmazza a cselekvő azonosítóját, a művelet típusát, az érintett bizonylatot és a művelet részleteit, időbélyeggel. (A kiállítási és sztornó-bejegyzések cselekvő-azonosító nélkül íródnak – lásd 5.8.) A naplózott műveletek típusai: `draft` (vázlat), `confirm` (megerősítés), `issue` (kiállítás), `storno` (sztornó), `fail` (hiba), `import` (import), `delete` (törlés), `payment` (befizetés), `email` (e-mail), `precode` (előkönyvelés), `security` (biztonsági beállítás), `evat` (eÁFA), `manual_expense` (kézi kiadás). A saját (NAV-közvetlen) úton a **kiállítás és a sztornó naplósora a kiállítási adatbázis-tranzakción belül** íródik: ha a bizonylat létrejött, a naplósor is létrejött, és fordítva. A megerősítés a biztonsági kapuk után, a hiba a hiba bekövetkezte után naplózódik. A **biztonsági beállítás módosítása külön naplósort** kap, amely a korábbi és az új értéket is tartalmazza, a módosítást végző felhasználó azonosítójával. **A napló neked is lekérhető**: a chatben bármikor kérheted („mi történt a fiókomban?”). A naplósorokat **a szerver fordítja emberi mondatokká a tárolt adatból – nem a nyelvi modell**, tehát a napló szövege nem a modell fogalmazása. Ez a funkció szándékosan nincs csomaghoz kötve. Ezen felül a rendszer két további naplót vezet: - **Platform-adminisztrátori napló**: fiók törlése, e-mail megerősítése, kétlépcsős azonosítás visszaállítása, csomag beállítása, munkamenetek visszavonása. Ez a napló a törölt fiók e-mail-címét pillanatképként is tárolja, hogy a törlés után is olvasható maradjon. - **Belépés-biztonsági eseménynapló**: munkamenet létrejötte, azonosítókulcs sikeres ellenőrzése, blokkolt varázs-hivatkozás, blokkolt azonosítókulcs-módosítás, blokkolt külső bejelentkezés. ### 24.5 Az audit-napló korlátai – kimondva - **Az audit-napló nem kriptográfiailag láncolt és nincs rajta minősített időbélyeg.** A „hozzáfűzéses” jelleg **alkalmazás-szintű konvenció**: a kódban nincs olyan útvonal, amely naplósort módosítana vagy törölne – de ezt adatbázis-szintű megszorítás nem kényszeríti ki. - **A fiók törlésével az audit-napló is törlődik** (kaszkádolt törlés). A napló nem éli túl a fiókot (25.2). - A kérés-korlátozás Redis-alapú. A kiállítás és a sztornó korlátja zárt hibamódú (elutasít), az egyéb helyeken nyitott hibamódú (átenged), hogy a korlátozó kiesése ne bénítsa meg a felületet. ### 24.6 A NAV-jogosultság kommunikációja – egységes A „legkisebb jogosultság” elve nem jelenti azt, hogy kevesebb jog is elég. A program minden felületen **ugyanazt** mondja: | Hol | Mit mond | |---|---| | Nyilvános **Biztonság-oldal** | A technikai felhasználóhoz **a „Számlák lekérdezése” és a „Számlák kezelése” jog is kell**: az elsőből dolgozik a bejövő-behúzás és az egyeztetés, a másodikkal küldjük be a nevedben a kiállított számlák adatszolgáltatását | | A chat **NAV-bekötő kártyája** | Ugyanez: a bejövő számlák beolvasásához a lekérdező jog kell, a kiállított számlák adatszolgáltatásához pedig a „Számlák kezelése” (beküldés, módosítás) jog | | Beállítások → NAV-szekció (bekötő űrlap) | Ugyanez, az XML cserekulcs követelményével együtt (6.3, 6.7) | | A NAV `FORBIDDEN` hibaüzenete | „…engedélyezni kell a »Számlák kezelése« jogot – a puszta »Számlák lekérdezése« ehhez kevés.” (18.5) | **Következmény:** a saját útra készülve a nyilvános oldalak alapján sem tudsz alul-jogosított technikai felhasználót létrehozni – a követelmény már az üzembe helyezés előtt kimondott (6.1). --- ## 25. Megőrzés és archiválás ### 25.1 Amit a program eltárol | Adat | Hol | Miért | |---|---|---| | A NAV-nak beküldött `InvoiceData` XML **szó szerint** | `nav_submissions.invoice_data_xml` | (a) a 13/A. § (4) szerinti ismételt beküldésnek ugyanazt az adatot kell vinnie; (b) a normalizált adatsorokból való visszafejtés veszteséges lenne; (c) a 11/A. § szerinti adóhatósági ellenőrzési adatszolgáltatás ebből szolgál ki | | Az XML **SHA3-512 lenyomata** | `nav_submissions.invoice_data_hash` | az egyezés olcsó, utólagos bizonyítása | | NAV tranzakció-azonosító, validációs üzenetek, magyar hibaüzenet, `done` melletti figyelmeztetés, beküldési és lezárási időbélyeg | `nav_submissions` | az adatszolgáltatás teljesítésének igazolása | | A számla tételsorai | `invoice_items` | a bizonylat adattartalma, a sztornó-tükör horgonyával | | A vevő címének pillanatképe a számlasoron | `invoices` | a partner-rekord utólag átírható, a NAV-nak küldött XML pedig magánszemély vevőnél nem tartalmaz nevet és címet | | A számlakép **SHA-256 lenyomata** és a **sablon verziója** | `invoices.pdf_sha256`, `invoices.pdf_template_version` | az újragenerált számlakép azonosságának igazolása | **A számlakép forrása maga az eltárolt XML.** A PDF-et a rendszer az adatbázisból visszaolvasott, beküldött XML-ből építi, tehát a számlakép **bizonyíthatóan ugyanazt mutatja, amit a NAV-nak jelentettünk** – a kettő nem tud szétcsúszni. A sablon determinisztikus, futásidejű külső betűtípus- vagy erőforrás-letöltés nélkül, és a régi sablonverziók a kódban maradnak (15.1–15.3). ### 25.2 Amit a program NEM tesz Ezt a pontot pontosan kell érteni, ezért kimondjuk: - **A titkár.ai nem nyújt jogszabályi értelemben vett számla-megőrzési (archiválási) szolgáltatást, és nem működtet hitelesség-biztosítási eljárást.** - **A tárolt XML-en és a számlaképen nincs minősített elektronikus időbélyeg és nincs elektronikus aláírás vagy záradékolás.** A rendszer lenyomatot tárol (XML: SHA3-512, PDF: SHA-256), ami az utólagos egyezés-ellenőrzést támogatja – de ez nem azonos a megőrzési szabályok szerinti hitelesség- és sértetlenség-biztosítással. - **Nincs automatikus archiváló vagy adattörlő háttérfolyamat.** Az ütemezett feladatok egyike sem takarít bizonylatadatot. A bizonylatok a fiók fennállása alatt megmaradnak. - **A fiók (bérlő) törlésével a hozzá tartozó bizonylatok, NAV-beküldések, tételsorok, audit-napló és NAV-adatok kaszkádolva törlődnek.** A rendszer a törlés után nem tartja fenn a nyolcéves megőrzést. - Fiók-törlés a kódban **kizárólag platform-adminisztrátori úton** létezik; önkiszolgáló törlő felület jelenleg nincs. - **A díjbekérőnek nincs eltárolt XML-forrása, és nem tárolunk hozzá SHA-256 lenyomatot** (a díjbekérő nem számla, adatszolgáltatás nem tartozik hozzá). A PDF-je letölthető, de az a saját nyilvántartásból épül, nem a NAV-nak beküldött adatból (15.5). ### 25.3 A te megőrzési kötelezettséged A számviteli bizonylat megőrzése **az adózó – tehát a te – kötelezettséged**, a számvitelről szóló 2000. évi C. törvény 169. §-a alapján **legalább 8 év**. A titkár.ai [Adatkezelési tájékoztatója](./adatkezelesi-tajekoztato.md) ugyanezt az időt rögzíti, és az [ÁSZF](./aszf.md) is fenntartja a nyolcéves megőrzést a szerződés megszűnése után. > **Mielőtt megszünteted az előfizetésedet vagy a fiókodat: futtasd le a 11/A. § szerinti > adóhatósági ellenőrzési adatszolgáltatást a teljes időszakra, és mentsd le a kapott XML-t, valamint minden számla > PDF-jét.** A 11/A. § szerinti adatszolgáltatási kötelezettség az elévülési idő végéig **téged** > terhel, a program viszont a fiók törlésével a bizonylatokat, a beküldési naplót és a tárolt > XML-eket **véglegesen, visszaállíthatatlanul törli** (25.2). A törlés után a titkár.ai ezt az > exportot **nem tudja újra előállítani**. Mivel a fenti korlátok fennállnak, **a bizonylataidat a saját archívumodba is le kell mentened.** A program három kimeneti utat ad ehhez: | Út | Mit ad | |---|---| | `export_invoice_data` | A 11/A. § szerinti adóhatósági ellenőrzési adatszolgáltatás, XML-ben, dátum- vagy sorszám-tartományra (17. fejezet) | | `get_invoice_pdf` | A számlakép PDF-ben (15. fejezet) | | `export_for_accountant` | Könyvelői CSV (kimenő + bejövő), Ultra csomagban | ### 25.4 Az adattárolás helye Az adatbázis a **Neon PostgreSQL** szolgáltatásán, az **EU / Frankfurt (AWS eu-central-1)** régióban fut. Az alkalmazás a **Vercel** platformján, az **EU / Frankfurt (fra1)** régióban. A részleteket az [Adatkezelési tájékoztató](./adatkezelesi-tajekoztato.md) 6. pontja tartalmazza. ### 25.5 A megőrzés szabálya — kimondva **A 8 éves megőrzés a te kötelezettséged, nem a programé.** A program a bizonylataid adatait (a beküldött számlaadat-XML-t, a PDF-lenyomatot és sablonverziót, a számlasorokat) **a fiókod fennállása alatt** korlátlanul őrzi, és bármikor exportálhatod (adóhatósági ellenőrzési adatszolgáltatás, PDF-letöltés, könyvelői csomag). **A fiók törlése végleges és mindenre kiterjed** — archiváló folyamat nincs, ezért a fiók törlése vagy az előfizetés megszűnése ELŐTT töltsd le a bizonylataidat és futtasd le a teljes időszakra az adatexportot; erre az [Adatkezelési tájékoztató](./adatkezelesi-tajekoztato.md) 10. és 12. pontja is kifejezetten figyelmeztet. A fiók törlése az [Adatkezelési tájékoztató](./adatkezelesi-tajekoztato.md) 12. pontja szerint **kérelemre, e-mailben** (info@titkar.ai) kezdeményezhető — önkiszolgáló törlő felület nincs, és a tájékoztató ezt így is mondja ki. A törlés végleges és kaszkádol; a bizonylatok megőrzése a Felhasználó kötelezettsége, ezért a törlés előtt a 25.3 szerinti exportokat le kell futtatni. --- ## 26. Nem támogatott esetek Ez a fejezet azt sorolja fel, amit a program **szándékosan nem tud**. A cél az, hogy ezt előre tudd, ne a művelet közepén derüljön ki. ### 26.1 A saját (NAV-közvetlen) úton jelenleg nem elérhető funkciók A rendszer ezeket **a szándék jelzésekor** utasítja el – tehát akkor, amikor a funkciót kéred, **nem a megerősítés után** –, és mindegyikhez megnevezi a járható alternatívát. | Nem elérhető | Miért | Járható alternatíva | |---|---|---| | **Nyugta** | Külön sorszámtartományt és külön adatszolgáltatást kíván | Készpénzes vevőnek rendes számla, készpénz fizetési móddal | | **Időszakos elszámolású (folyamatos teljesítésű) számla** | Még nem épült meg ezen az úton | Rendes számla az adott időszakról, vagy gyűjtőszámla (9.13) | | **Kiállított díjbekérő törlése** | Még nem épült meg ezen az úton | A díjbekérő nem számla, adatszolgáltatás nem tartozik hozzá – figyelmen kívül hagyható | **Ami viszont működik:** rendes számla, díjbekérő, **díjbekérőből végszámla**, **előlegszámla és az azt beszámító végszámla**, **gyűjtőszámla**, **egyszerűsített adattartalmú számla** (9.13), sztornó, **helyesbítő számla** (13.5), számlakép (PDF), e-mail-küldés, adószám-ellenőrzés a NAV-nál. A korlátokat a rendszer nemcsak a művelet elutasításakor mondja ki: az asszisztens a „mit tudsz csinálni?” típusú kérdésre sem sorolja fel a nem elérhető funkciókat, és nem ígéri meg őket. ### 26.2 Meg nem épített NAV-XML alrendszerek A számla-adatszolgáltatás XML-sémájának alábbi részei **tudatosan nincsenek megvalósítva**. Ha a tevékenységed ezeket igényli, **más számlázó programot kell használnod**: - **Környezetvédelmi termékdíj** (termékdíj-összesítő, tételszintű termékdíj-tartalom, termékdíj-kötelezettség jelzése, termékdíj-záradék). - **Új közlekedési eszköz** értékesítése (gyártmány/típus, alvázszám, motorszám, futott kilométer, üzemóra). - **Fej-szintű ERP-hivatkozások** (megrendelésszám, szállítólevél-szám, EKÁER-azonosító, szerződésszám, beszállítói kód, költséghely, főkönyvi számla, munkaszám, projektszám). - **Tételek közötti kereszthivatkozás.** - **Kötegelt módosítás** – egy okirat, amely több számlát módosít. Erre a rendszer magyar mondattal elutasít. - **Időszakos elszámolású számla** – a lefedettség-bővítés még hátra van. (A **gyűjtőszámla** megépült – 9.13.) - **Technikai érvénytelenítés** (`manageAnnulment`) beküldő ága még nem él. - Az adatszolgáltatás **nem minősül magának az elektronikus számlának** (`completenessIndicator` értéke minden esetben hamis). Ha a rendszer ezzel az értékkel próbálna beküldeni, a generátor elutasítaná. ### 26.3 Amit a rendszer szándékosan megtagad – nem tippel Az alábbi esetekben a leképező réteg **nem választ helyetted**, hanem megtagadja a műveletet és pontosítást kér. Az ok minden esetben ugyanaz: a rossz jogcím vagy a kitalált adat hibás adatszolgáltatáshoz vezetne, aminek számlánként jelentős szankciós tétje van. | Eset | Miért tagadja meg | |---|---| | **Kétértelmű, régi áfakód** (`EUT`, `EUKT`, `EU`, `EUK`, `MAA`, `K.AFA`, `AKK`) | Ezek több, egymást kizáró NAV-jogcímnek is megfelelhetnek | | **Nem magyar áfakulcs belföldi számlán** | Belföldön csak 0%, 5%, 7%, 12%, 18%, 27% fogadható el; a 19%, 20%, 21%, 23%, 25,5% stb. külföldi kulcsokat a NAV elutasítja | | **Üres mértékegység** | A mennyiségi egység kötelező tartalmi elem – a rendszer nem pótolja „darab”-bal | | **Nem magyar mintájú adószám magyar adószámként** | A nem-számjegyek eldobása hamis magyar adószámot gyártana; külföldi vevőnél a közösségi adószám mezőt kell tölteni | | **Devizás számla érvényes árfolyam nélkül** | Az árfolyam kötelező adat | | **Tétel nélküli számla** | Nincs mit jelenteni | A generátor további, szigorú kapukat tart fenn: az eredeti számlánál hivatkozás nem szerepelhet, a módosításnál és a sztornónál kötelező; a sztornó tételsor nélkül nem küldhető be; a számlaszámban nem lehet csak whitespace; forintos számlánál az árfolyam csak 1 lehet; az árfolyam hat tizedesnél nem lehet hosszabb; a szabad szöveges mezőkre a séma hosszkorlátjai érvényesek; magánszemély vevőnél a név és a cím nem kerülhet az adatszolgáltatásba. ### 26.4 Egyéb, szándékosan nem támogatott műveletek - **A NAV-ból importált számla ezen az alkalmazáson keresztül nem sztornózható és nem helyesbíthető.** Ezek valós, már bevallott bizonylatok, amelyeket nem a titkár.ai állított ki. - **A NAV által tartalmilag elutasított (`aborted`) beküldés újraküldése megtagadva.** A tartalmi hibát javítani kell, nem ismételni. (Elutasított lánc-okiratnál a helyi állapot rendezését a 13.6 pont írja le.) - **Kiállított számla nem törölhető, csak sztornózható.** (Díjbekérő törölhető – a saját úton jelenleg az sem, lásd 26.1.) - **A rendszer fizetést vagy átutalást nem indít.** - **Az automatikus banki összekötés ki van kapcsolva** – csak kézi CSV-bankkivonat. - **Bevallást az asszisztens önállóan nem nyújt be.** Az eÁFA gépi beadás-előkészítése 2026. augusztus 18. óta elérhető (Ultra): az asszisztens a tervezetet a NAV eÁFA-rendszerébe tölti és az állapotát lekérdezi, a **benyújtás** viszont kizárólag a megerősítő kártya gombjával, az asszisztenstől független, hitelesített végponton fut. A lánc környezeti kapcsoló mögött marad: hiba esetén a Szolgáltató kikapcsolja, ekkor az előkészítő eszközök kikerülnek a készletből, a benyújtó végpont elutasít (fail-closed), és az áfabevallást a NAV eÁFA-felületén kell beadnod. A helyi áfa-analitika, az adókód-javaslat és az áfakód-lekérdezés ettől független – azok nem küldenek adatot a NAV-hoz. - **A hazai QR-fizetés (qvik) egyik csomagban sem érhető el** (20.3). - **Egyszerűsített adattartalmú és gyűjtő számla HELYESBÍTÉSE** megtagadva (a sztornójuk működik) – 9.13, 13.6. - **Sztornó csak akkor indítható, ha az eredeti számla adatszolgáltatása lezárult (`done` állapot).** - **Migrált vagy külső eredetű gyökérszámlánál, lánc-előzmény nélkül a módosító művelet megtagadva** – a rendszer nem tippeli meg a lánc előzményét. --- ## 27. Verziókövetés A 23/2014. (VI. 30.) NGM rendelet 10. § (3) bekezdése alapján a dokumentációnak követnie kell a program változásait. ### 27.1 A NAV felé jelentett szoftver-azonosság A titkár.ai minden NAV-kérésbe beépíti a **2.1 pontban szó szerint közölt** azonosítót (`softwareId` = `13311908SZAMLAI001`, `softwareName` = `titkar.ai`, `softwareMainVersion` = e dokumentum verziószáma, jelenleg `1.7`). Az azonosító és a név eltérésének oka szintén ott olvasható: az azonosító a NAV-nál nyilvántartott előzmény miatt marad változatlan. ### 27.2 A számlakép sablonjának verziója A számlakép sablonja verziózott (`PDF_TEMPLATE_VERSION`, jelenlegi értéke `v1`), és a **verzió számlánként eltárolódik** az első számlakép-generáláskor, a PDF SHA-256 lenyomatával együtt. A régi sablonverziók a programkódban maradnak, így utólag igazolható, hogy egy újragenerált számlakép azonos a korábban kiadottal (15.3). ### 27.3 A dokumentum verziózása Ez a dokumentum a repóban bevett jogi-dokumentum mintát követi: a fejlécében szerepel a hatálybalépés dátuma és a verziószám. A mindenkor hatályos változat a https://titkar.ai oldalon érhető el; a módosításról a Szolgáltató az [ÁSZF](./aszf.md) 14. pontja szerint előzetesen tájékoztat a felületen vagy e-mailben. **Verzióléptetési szabály.** A Szolgáltató **minden olyan funkcióváltozáskor, amely e dokumentum tartalmát érinti** – új eszköz élesítése, meglévő funkció megszűnése, korlát változása –, az élesítést **megelőzően** kiadja a dokumentum új verzióját. Ez a 10. § (2) második mondatából következik: a program csak dokumentált funkciót hajthat végre (21. fejezet). A NAV felé jelentett `softwareMainVersion` ugyanezt a verziószámot viszi, egyetlen közös forrásból — a program verziója és a dokumentáció verziója nem tud széttartani (2.4). ### 27.4 A verziókövetés jelenlegi korlátai – kimondva - **A programban jelenleg nincs beépített változásnapló (changelog)** a számlázó program funkcióváltozásaihoz; a felhasználó a felületen nem látja, mi és mikor változott. A **dokumentum** saját verziótörténetét a 27.5 pont tartalmazza. - **Az átadás igazolása a regisztrációkor rögzül** (időbélyeg + a dokumentum akkori verziószáma a fiók adatai között). A rögzítés bevezetése **előtt** létrejött fiókoknál ilyen bejegyzés nincs — rájuk az átadás a nyilvános közzététellel és a letöltési ponttal teljesül. - **A korábbi verziók letöltése** a `?verzio=` paraméterrel érhető el (1.1, 1.5, 1.6 és a mindenkori újabb kiadások). Az 1.0, 1.2–1.4 kiadásokról nem őrződött önálló példány — ezeket a Szolgáltatótól kell kérned az info@titkar.ai címen. ### 27.5 Verziótörténet Az alábbi táblázat a dokumentum minden kiadott változatát felsorolja. **A számlád kiállításának napján hatályos verzió az irányadó rá** – a 10. § (4) szerinti megőrzéshez ezt a verziót töltsd le a letöltési pontról (1.1, 27.4). | Verzió | Hatálybalépés | Mit követ le | |---|---|---| | 1.0 | 2026. augusztus 4. | Első kiadás: a saját (NAV-közvetlen) számlázási út teljes leírása | | **1.1** | **2026. augusztus 4.** | A kód időközbeni javításainak átvezetése (9 tétel): a 11/A. § szerinti funkció jogszabályi elnevezése (17.1); a magánszemély vevő címének kikényszerítése (9.1, 9.3, 15.2, 17.4); a kelte magyar idő szerinti számítása és önálló tárolása (8.8, 9.2, 17.2); az MNB-árfolyam 6 tizedesre kerekítése (14.6); az adatszolgáltatás kapuja a számla kibocsátója szerint (17.1); a fizetési emlékeztető eszközleírásának pontosítása (20.3); a NAV-jogosultság egységes kommunikációja (6.2, 24.6); a megerősítő kártyák „az adatszolgáltatás azonnal indul” megfogalmazása a magyar felületen, a megmaradt korláttal együtt (7.6, 13.7); a kontroll-sáv „elakadt” üzenetének szétbontása ok szerint (18.4). Emellett kimondva: a megerősítő kártyák lábszövegének két, a saját útra nem érvényes ígérete (7.6, 10.6) | | **1.2** | **2026. augusztus 7.** | A díjbekérő PDF-je elkészült a saját úton: a bizonylat képe letölthető és e-mailben kiküldhető (10.6, 15.5, 26.1). A kép forrása – a számláétól eltérően – a saját nyilvántartás sora és tételei, mert a díjbekérőhöz nem tartozik NAV-adatszolgáltatás; a kép a sorszáma alatt kimondja, hogy nem számla, és SHA-256 lenyomatot nem tárolunk hozzá (15.5) | | **1.3** | **2026. augusztus 7.** | A NAV-adatok mentése cserekulcs-megőrzővé vált: az üresen hagyott mező a meglévő cserekulcsot nem törli (6.9; a T-06 kulcscsere-ága lezárva, a kapcsolat-bontás kérdése nyitva marad). A jogi dokumentumok összhangja rendeződött: az ÁSZF és az Adatkezelési tájékoztató a saját utat kifejezetten leírja – a T-34, T-35 és T-36 tétel lezárva (28.6). A jogszabály-szöveg ellenőrzésével lezárva továbbá: T-02 – a 10. § (1) csak a program nevéről és azonosítójáról kér tájékoztatást, a fejlesztő elérhetősége nem kötelező tartalom (2.) –, és T-42 – a kézi számla adatszolgáltatási határideje az Áfa tv. 10. melléklet 2–3. pontja szerint 4 naptári nap, 500 000 Ft áthárított adótól 1 naptári nap (18.8). Lezárva továbbá: T-28 – a Free csomag 3 mentett partneres kerete bekerült az ÁSZF csomagtáblázatába –, és T-31 – az Adatkezelési tájékoztató 12. pontja a fióktörlést a tényleges (kérelemre, e-mailben) útként írja le (25.5). Kódjavítással lezárva: T-11 – a vevő címének országa megadható (ISO alpha-2; alap: HU), formátum- és konzisztencia-ellenőrzéssel, a mentett partner országa automatikusan átvéve (9.12) | | **1.4** | **2026. augusztus 8.** | A külső számlázós út megszűnt: a szamlazz.hu- és Billingo-integráció kikerült a programból, a kiállítás azóta kizárólag saját, NAV-közvetlen úton történik (1.2, 1.3). Ezzel megszűnt a nyugta, az előlegszámla és a hozzá tartozó végszámla, a kiállított díjbekérő törlése, valamint a külső számlázó fiókjából történő számla-behúzás eszköze; a zárt eszközkészlet 107-ről **101 eszközre** csökkent, a csomag-bontással együtt (21., 23.2). Ezzel egyidejűleg új, csak olvasó eszköz került be a saját fiók áttekintésére (`get_my_company`: cégnév, adószám, székhely a NAV adóalany-nyilvántartásából, a NAV-kapcsolat teszt/éles állapota, a csomag és a számlázási alapértékek), így a készlet **102 eszköz** (21.2/9., 23.2). A 2026. augusztus 8. előtt, külső számlázón keletkezett bizonylatokra változatlanul az akkori program a számlázó program (1.3, 1.4). Pontosítva: a NAV-jogosultság egységes kommunikációja mindkét jogot kéri (24.6), a díjbekérő PDF-je a saját nyilvántartásból épül és lenyomat nem tartozik hozzá (25.2), a 11/A. § szerinti adatszolgáltatás a saját kibocsátású számlákra szól (17.1) | | **1.5** | **2026. augusztus 8.** | A **helyesbítő (módosító) számla elérhetővé vált a saját úton** (13.5; 4.2, 21.1, 26.1): a hibás adat sztornó nélkül, `MODIFY` műveletű okirattal javítható; a felhasználó a teljes, helyes tételsort adja meg, a különbözetet a program képezi a NAV által elfogadott XML-ekből; ugyanaz a számla többször is helyesbíthető. A lánc-okiratok a lánc **nettó-hatásos** tételsoraiból épülnek (13.4) – az okirat mérete a sokadik helyesbítésnél is állandó. Csak fejadat-változásnál tételsor nélküli fejadat-módosító megy; a „semmi nem változott” vázlatot a kiállítás elutasítja. Új védelmek: lánc-okirat (helyesbítő/sztornó) önmagában nem helyesbíthető és nem sztornózható – a hibaüzenet a gyökérre mutat (13.5, 13.6); a NAV által elutasított (`aborted`) lánc-okiratnál a helyi állapot magától rendeződik: az okirat-sor „törölt” lesz, a lánc-számlálók visszaállnak, sztornónál az eredeti számla és a lánc visszaáll élőre (13.6, 26.4); helyesbítőn negatív sor csak akkor fogadható el, ha az eredeti számlán is van engedmény-sor (9.1) | | **1.6** | **2026. augusztus 10.** | A kód és a dokumentáció eltéréseinek átvezetése, kódjavításokkal együtt. Új leírás: a **`sending` állapot** és a félbeszakadt küldés feloldása a NAV lánc-kivonatából (16.4, 18.3) – ide tartozik az az eset is, amikor a beküldésre nem érkezik válasz: a rendszer ilyenkor nem küld újra, hanem a NAV-ot kérdezi meg; a **napi NAV-egyeztetés** (18.2), amely a hatóság nyilvántartását veti össze a kiállított számlákkal, és külön, magas súlyú teendőt ad, ha a NAV nem ismer egy számlát – illetve ha maga az egyeztetés marad el; a kiállítás utáni kártya **élő adatszolgáltatás-státusza** (16.9). Kódjavítás: a kiállítói cím **hiányosan sem mehet ki** – a NAV sémája az irányítószámot és a települést kötelezővé teszi, a hiányt a program a korábbi pillanatképből pótolja, végső esetben megáll (16.6); több cím esetén a **székhely** kerül a számlára (16.6); az adóhatósági export dokumentumai **számlánként** épülnek, így egyetlen hibás bizonylat nem viszi el a teljes exportot (17.5), a NAV által **elutasított lánc-okirat** pedig nem kerül az exportba (17.3). Kimondott korlátok: az `INFO` szintű NAV-üzenet nem jelenik meg figyelmeztetésként, és a napi egyeztetés ablaka 34 nap (18.9) | | **1.7** | **2026. augusztus 14.** | **Verziópolitika és átadás-bizonyítás (T-32, T-33 lezárva):** a NAV felé jelentett `softwareMainVersion` a dokumentum verziószámát követi, közös forrásból (2.4, 27.3); a dokumentum verziózott letöltési pontot kapott a korábbi kiadások elérésével (1.1, 27.4), a tudomásulvétel pedig regisztrációkor időbélyeggel és verziószámmal rögzül (27.4). **Kódjavítások:** az ismétlődő számlázás esedékessége a magyar naptári nap szerint számít, a napi futás magyar idő szerint reggel 7:15/8:15 (12.4, 12.5; T-14 lezárva); az adóhatósági adatexport a magánszemély vevő címének országkódját a kiállításkori pillanatképből pótolja vissza a korábbi fix `HU` helyett (17.4). Pontosítva: az alanyi adómentesség-jelölés a tételek AAM-jogcíméből származik (9.12). **Lezárt döntések:** a dokumentum időbeli hatálya 2026. augusztus 8. (1.4; T-01 lezárva); a titkár.ai nem nyugtaadási program a 23/2014. NGM rendelet 2. §-a értelmében, és nyugta-funkciót a fejlesztési terv sem irányoz elő (4.4, 11.5; T-03, T-13 lezárva); a megőrzés szabálya: a 8 éves megőrzés a felhasználóé, a program a fiók fennállása alatt őriz, a fiók törlése végleges (25.5; T-30 lezárva); az első kiállítás NAV-függősége vállalt korlát, kézi cégadat-megadás szándékosan nincs (16.6; T-19 lezárva); egy fiók – egy személy, minden művelet hozzá rendelhető (5.1, 5.8; T-04, T-05 lezárva); a NAV-kapcsolat bontása kérelemre (6.9; T-06); a lezárás pillanata a tranzakció véglegesítése (7.11; T-07); az előtag nem választható, váltásnál új tartomány nyílik, a `DIJB` rögzített (8.8, 10.7; T-08, T-09, T-12); a külső korszak számlája a saját úton nem sztornózható (13.7; T-16); a számlakép-azonosság bizonyítéka a lenyomat + sablonverzió, nem a bitre-azonos újragenerálás (15.6; T-18); a 4 órás jelzési küszöb vállalt megfogalmazás (16.9; T-20); az export forrás-alapú hatálya végleges (17.3; T-21); kézi érvénytelenítéshez a NAV-felületre irányítás elegendő (18.9; T-23); munkanap-számláló nem épül (18.7; T-24); az adatszolgáltatás nyilvántartása a beküldési napló (19.5; T-25); a fizetettség-fejezet elhatárolásként marad (20.; T-26). **Új bizonylatfajták a saját úton (4.1, 9.13):** megépült az **előlegszámla** és az azt beszámító **végszámla** (a beszámítás feltétele az előlegszámla lezárult NAV-adatszolgáltatása; a beszámítási adatok az eltárolt XML-ből és a lánc fejadatából jönnek, nem a felhasználótól), a **gyűjtőszámla** (tételenkénti teljesítési dátummal) és az **egyszerűsített adattartalmú számla** (készpénz/bankkártya, áfatartalommal, a számlaképen nettó/áfa bontás nélkül). Ezzel az érintett korlátok kikerültek a 4.2, 9.12, 14.7, 16.9 és 26.1 pontból; új korlátként kimondva: egyszerűsített és gyűjtőszámla nem helyesbíthető (a sztornójuk igen), előleg- és végszámla tételei nem helyesbíthetők, a fejadatuk igen (13.6). **Fiók-szintű kiállítói törzsadat (T-37 lezárva):** a közösségi adószám és a pénzforgalmi elszámolás a számlázási alapértékek között adható meg — kitöltve a supplier-blokkba/detail-jelölésbe és a számlaképre kerül (6.9, 9.12, 28.6); a NAV-nyilvántartott cégadat továbbra sem írható felül kézzel. **Step-up (T-38 lezárva):** marad a bekapcsoláskori egyszeri igazolás — a felhatalmazás az ütemezés nem-módosítható tartalmához kötött, tartalmi változtatás törlés + újrafelvétel + új igazolás (5.5) | | **1.8** | **2026. augusztus 18.** | **Az eÁFA gépi beadása élesedett.** A beadás-ELŐKÉSZÍTŐ eszköz (feltöltés → partíció → véglegesítés) bekerült az asszisztens eszközkészletébe; a bevallás **benyújtása** változatlanul kizárólag a megerősítő kártya gombjával, az asszisztenstől független végponton fut. A 21., 22.6 és 26.4 pontok ennek megfelelően pontosítva: a korábbi „nincs beadási eszköz (a készletben sincsenek)" megfogalmazás helyett a dokumentum azt mondja ki, ami a kódban is így van – az asszisztens előkészít, benyújtani nem tud. A két eszköz (`prepare_vat_declaration_submission`, `check_vat_declaration_status`) a 21.2 pont 6. blokkjának funkciólistájába felvéve (Ultra). | ### 27.6 Nyitott kérdések E fejezet korábbi nyitott kérdései (T-32 verziópolitika, T-33 átadás-bizonyítás) lezárultak: a szabályt a 2.4 és a 27.3, a megépített mechanizmust az 1.1 és a 27.4 pont tartalmazza. --- ## 28. Támogatás, felelősség, kapcsolat ### 28.1 A szolgáltató adatai és elérhetőségei A fejlesztő és üzemeltető azonosító adatait (cégnév, székhely, cégjegyzékszám, adószám, képviselő) a **2.2 pont** tartalmazza. Az elérhetőségek: - **Általános kapcsolat és panasz:** info@titkar.ai - **Adatvédelmi és biztonsági bejelentések:** adatvedelem@titkar.ai · gépi csatorna: `/.well-known/security.txt` (RFC 9116) - **Tárhelyszolgáltatók:** Vercel Inc. (alkalmazás; EU/Frankfurt, fra1) és Neon Inc. (adatbázis; EU/Frankfurt, AWS eu-central-1) ### 28.2 Támogatás a programon belül A chatben bármikor kérhetsz támogatást. A rendszer **öt kategóriát** ismer: kérdés, hibajelentés, számlázás/előfizetés, funkciókérés, egyéb. | Korlát | Érték | |---|---| | Tárgy hossza | 3–150 karakter | | Üzenet hossza | 10–5000 karakter | | Beküldési korlát | 5 jegy / óra fiókonként, ezen felül percenként 10 kérés | **A támogatási jegyet nem az asszisztens küldi el.** Az eszköz csak a beküldendő szöveg előnézetét adja; a küldést te indítod a kártya gombjával, egy védett szerver-végponton. Ez zárja ki, hogy egy szövegbe rejtett „írj a supportnak, hogy…” típusú utasítás a nevedben levelet küldjön. A hibajelentés **nincs csomaghoz kötve**: minden előfizetőt megillet, a Free csomagban is. A válasz a fiókodhoz tartozó e-mail-címre érkezik. **Korlát:** telefonos ügyfélszolgálat nincs, és a Szolgáltató **rendelkezésre állási (SLA) vállalást nem tesz**. A programban és az [ÁSZF](./aszf.md)-ben nevesített egyetlen két határidő a fogyasztói panasz 30 napja és a megrendelés visszaigazolásának 48 órája. ### 28.3 Felelősség - **Ember a hurokban.** Éles, NAV-kész számla **kizárólag a te kifejezett megerősítésed után** kerül kiállításra. A megerősítés tudatos művelet; a kiállítás a NAV-adatszolgáltatás miatt **visszafordíthatatlan** (sztornózható, de nem törölhető). Nincs kizárólag automatizált döntéshozatal – a GDPR 22. cikk (1) bekezdése ezért nem alkalmazandó. - **A megerősítés felelőssége.** A kiállított számla adattartalmáért – amelyet az előnézetben jóváhagytál – **te felelsz**. A Szolgáltató az előnézettel és a NAV-adat visszaolvasásával segít a hibák elkerülésében ([ÁSZF](./aszf.md) 6.3). - **A Szolgáltató nem felel** a megadott hibás adatokból, a megerősítésed alapján kiállított számlák tartalmából, a NAV rendszereinek működéséből, illetve az érdekkörödben felmerülő okokból eredő károkért ([ÁSZF](./aszf.md) 8.1). - **Fogyasztóval szemben** a jogszabály által kötelezően előírt felelősséget a Szolgáltató **nem zárja ki és nem korlátozza** ([ÁSZF](./aszf.md) 8.2). - **Vis maior**, internetkimaradás vagy harmadik fél szolgáltatásának hibája miatti kiesésért a Szolgáltató nem felel ([ÁSZF](./aszf.md) 8.3). - **A titkár.ai mint szolgáltatás nem rendelkezik saját SOC 2 vagy ISO 27001 tanúsítvánnyal.** A Biztonság-oldalon említett tanúsítványok az alvállalkozókra (tárhely-, adatbázis- és egyéb szolgáltatókra) vonatkoznak. ### 28.4 Panasz és jogorvoslat **Panaszkezelés:** info@titkar.ai vagy postai levél a székhelyre. Írásbeli panaszra a Szolgáltató **30 napon belül** érdemi, indokolt választ ad; a panaszt és a választ **3 évig** megőrzi (a fogyasztóvédelemről szóló 1997. évi CLV. tv. 17/A. §). **Békéltető testület** (a Szolgáltató székhelye szerint): > **Hajdú-Bihar Vármegyei Békéltető Testület** > 4025 Debrecen, Vörösmarty u. 13–15. · +36 52 500 745 / +36 52 500 743 > bekelteto@hbkik.hu · www.hbmbekeltetes.hu **Fogyasztóvédelmi hatóság:** az illetékes fővárosi/vármegyei kormányhivatal. Az Európai Bizottság online vitarendezési (ODR) platformja 2025. július 20-tól megszűnt. **Adatvédelmi jogorvoslat:** > **Nemzeti Adatvédelmi és Információszabadság Hatóság (NAIH)** > 1055 Budapest, Falk Miksa u. 9–11. · ugyfelszolgalat@naih.hu · www.naih.hu Bírósági út a lakóhely vagy tartózkodási hely szerinti törvényszéken is kezdeményezhető. Adatvédelmi incidens esetén a Szolgáltató **72 órán belül** bejelentést tesz a NAIH-nak (GDPR 33. cikk), magas kockázat esetén az érintetteket is értesíti (GDPR 34. cikk). ### 28.5 Üzemmód A NAV-kapcsolat éles vagy teszt üzemmódban működhet; ez a beállítás a fiók NAV-adatai között tárolódik. **A felületen nincs felhasználó által szabadon váltható éles/teszt kapcsoló** – az éles üzem az alapértelmezés (2.3, 6.5). ### 28.6 A jogi dokumentumokkal való összhang A korábban itt jelzett ütközések (T-34, T-35, T-36) **rendeződtek**: a hatályos jogi dokumentumok a saját, NAV-közvetlen számlázást már kifejezetten leírják. Az [ÁSZF](./aszf.md) 3. pontja a kiállítás módját táblázatban rögzíti, 5. pontja kimondja, hogy nincs külső számlázó-fiók és nincs második díj, 8.2 pontja pedig a felelősségi határt a Szolgáltató saját funkcióira külön húzza meg (a saját beküldő lánc hibájáért nem hivatkozhat a külső-rendszer kizárásra). Az [Adatkezelési tájékoztató](./adatkezelesi-tajekoztato.md) 5.1 pontja mondja ki, ki állítja ki a számlát és ki szolgáltat adatot a NAV-nak. > **Kiállítói törzsadatok (T-37 lezárva).** A kiállítói adatoknak két forrása van, tudatos > munkamegosztásban: amit a NAV nyilvántart (név, cím, adószám, áfakód, megyekód), az > **kizárólag** a NAV adóalany-lekérdezéséből jön (6.8, 16.6) — kézzel nem írható felül, így > hibás kézi törzsadat nem kerülhet számlára. Amit a NAV nem ad vissza, az **fiók-szintű > beállítás**: a **közösségi adószám** és a **pénzforgalmi elszámolás** a számlázási > alapértékek között adható meg (9.12, 14.7), az **alanyi adómentesség-jelölést** pedig a > tételek AAM-jogcíme adja (9.12). --- ## 29. Tisztázandó tételek az élesítés előtt > **Ez a szakasz munkajellegű.** Nem a program működését írja le, hanem azokat a > kérdéseket gyűjti egy helyre, amelyeket a dokumentum élesítése (közzététele) előtt el kell > dönteni – vagy jogi/üzleti döntéssel, vagy kódjavítással. A tételek a saját fejezetükben is > szerepelnek, ugyanezzel az azonosítóval. **Amíg egy tétel nyitott, a hozzá tartozó állítás a > dokumentumban a jelenlegi, kódból igazolt működést írja le** – soha nem egy tervezett > állapotot. **A számozás hézagos, és ez így helyes.** A hiányzó azonosítók (**T-02, T-10, T-11, T-15, T-17, T-22, T-27, T-28, T-29, T-31, T-34, T-35, T-36, T-39, T-40, T-41, T-42**) **megoldott, lezárt tételek**: a programban (illetve a jogi dokumentumokban vagy a jogszabály szövegének ellenőrzésével) megtörtént a tisztázás, és a dokumentum érintett fejezetei már a javított, tényleges működést írják le (a tételenkénti helyeket a 27.5 pont verziótörténete sorolja fel). Ahol a javítás **részleges** – a T-15 a magyar felület megerősítés előtti mondatáig terjed –, ott a megmaradt korlátot az érintett fejezet mondja ki (7.6). A megmaradó tételek azonosítóját **nem számozzuk újra** – a T-számok hivatkozásként élnek a fejezetekben, a fejlesztési jegyzetekben és a korábbi verziókban. **A v1.7-es kiadással minden tétel lezárult** — nincs nyitott tisztázandó kérdés. A lezárások tételes listáját (mi zárta le: döntés, kódjavítás vagy szövegrögzítés, és melyik fejezetben) a 27.5 pont verziótörténete tartalmazza. *Hatálybalépés: 2026. augusztus 14. · Verzió: 1.7*