NTAK adatbeküldés éttermeknek

NTAK adatbeküldés éttermeknek
2022-04-06T09:56:43+02:00
2022-11-26T15:05:58+01:00
2022-11-26T15:42:05+01:00
  • Sziasztok,

    hátha segít valakinek, Delphi 10.4-el készült, az NTAK-os kommunikációt megvalósító soztályok, aláírás generálás, küldés működik ntak
    A "Delphi JOSE and JWT Library"-t használom, a https://jwt.io szerint ez egy jó referencia kliens.

    üdv
    Rada
    Mutasd a teljes hozzászólást!
  • Az NTAK oldalán már az szerepel, hogy csak jövő júliusban indul el...

    Ez így nagyon hosszú lesz

    A hatályos jogszabályok alapján az NTAK-ba minden hazai szálláshely-szolgáltató összes szálláshelyét regisztrálni kell. A regisztrációs kötelezettség 2021. november 1-jétől már kiterjed a vendéglátó üzletekre és a turisztikai attrakciókra is, adatszolgáltatási kötelezettségük 2023. július 1-jétől indul. Ezzel az NTAK rendelkezni fog a turisztikai szektor minden meghatározó szereplőjének teljesítményére vonatkozó adattal.


    Mutasd a teljes hozzászólást!
  • Delphi -seknek egy Tipp az RFC3339 timeStamp formátum kapcsán:

    Az OverbyteICSUtils.pas fájlban az 1676 sornál cseréljétek ki a függvényt erre:

    {* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *} { V8.62 Get time zone bias as string, ie -0730 } { V8.71 Get time zone bias as RFC3339 compatible string, ie -07:30 } function IcsGetLocalTZBiasStr: String; var Bias: Integer; Sign: String; begin Bias := IcsGetLocalTimeZoneBias; if Bias > 0 then Sign := '-' else Sign := '+'; Bias := Abs(Bias); Result := Format('%s%.2u%s%.2u', [Sign, Bias div 60, ':', Bias mod 60]); end;


    És onnantól simán lehet az ISuperObject .DT függvényét használni:

    var o : ISuperObject; begin o := SO(); o.DT['uzenetKuldesIdeje'] := Now - egyMasodperc;
    Megkértem a fejlesztőt, hogy javítsa a forráskódjában is.
    Amúgy ez a függvény levágja a másodperc utáni tizedeseket.
    Mutasd a teljes hozzászólást!
  • Tipp a kerekítés kapcsán:
     - én azt csinálom, hogy az összesen-ből osztom mindig vissza az egységárat a tételszám alapján.
     - így a feltéteket is hozzá tudom adni / kivonni előtte.
    Pl.: 3 x 1033.33333333333333 Ft = 3100 Ft

    De ha valaki eredetileg tört tétel-darabbal számol (pl. 1.13 Kiló pogácsa) akkor lehet azt is csinálni, hogy azt hagyjuk meg pontosabb törtnek, azaz a végösszeg mindig PONTOSAN kerek legyen !
    1.13 x 520 = 587,6 helyett:
    1,1307692307692307692307692307692 x 520Ft = 588 Ft
    Mutasd a teljes hozzászólást!
  • Sziasztok!

    Azt vettem észre hogyha a bruttoEgysegar mezőben 1290-et küldök tök jó.
    ha 1290.50-et az is tök jó
    ha "1290.00"-át az is jó

    viszont ha 1290.00-et az megáll egy ilyen hibával hogy a tizedes pont után nem szerepel digit.

    Azt hittem az ntak szervere kezel valamit rosszul de magamban nem tudtam olyan algoritmust írni ami az 1290.50-et validnak veszi a 1290.00-át meg. (vagyik eléggé meg kellett volna erőszakolnom a parser algoritmust hogy ilyet tudjak produkálni)

    Igy megosztom a tapasztralatokat.

    Akik Delphi-ben csinálják az ntak integrációt és ICS komponensekkel dolgoznak ISuperObject-el
    azoknak mondom, hogy az SO függvény (ami lérehozza a json-t egy stringből) az rontja el a konvertálást. 1290.00-ból csinál egy 1290. -ot. ez meg nyilvány nem jó.
    Majd átnézem a forráésát az ISuperObject-nek és megpróbálom kijavítani. Addig is óvatosan az olyan double értékkel ami amúgy int.

    Üdv,
    Mocsa
    Mutasd a teljes hozzászólást!
  • Szia!

    Ha +1 és 2 forint borravaló és számla/nyugta tételként rajta van, akkor "EGYEB/BORRAVALO", mert tételen is jelented (?) és rendelesVegosszegeHUF-ot növel, így fizetési módba nem raknék borravalót.

    Ha - 1 és 2 forint borravaló és számla/nyugta tételként rajta van, akkor "EGYEB/EGYEB", mert tételen is jelented (?) és rendelesVegosszegeHUF-ot csökkent, így fizetési módba nem raknék borravalót.

    Ha +/- 1 és 2 forint kerekítés és számla/nyugta tételként rajta van, akkor "EGYEB/EGYEB", mert tételen is jelented (?) és rendelesVegosszegeHUF-ot növel, így fizetési módba nem kell kerekítést (kivéve előző szépkártyás példám).

    Ha +/- 1 és 2 forint kerekítés és számla/nyugta tételként nincs rajta, akkor fizetési módba kerekítés.

    100 forint borravaló hasonlóképpen, azaz ha számla/nyugta tételként rajta van és jelented (?), akkor rendelesVegosszegeHUF-ot növel, így EGYEB tétel, ha viszont nem, akkor fizetési mód BORRAVALO.

    Meg ezek együttes kombinációja... :)
    Mutasd a teljes hozzászólást!
  • Pont ez a bajom:
     - ha már le van zárva egy számla, ki van nyomtatva, és a fizetés történik,
     - akkor a gép NEM fogja tudni semmilyen módon eldönteni, hogy azt a +-2 forintot borravalónak szánták-e vagy kerekítésnek.

    Főleg, hogy nem "fizetési módként" kell beküldeni, hanem "rendelési tételként", ami ugye addigra már ZÁROLVA van az adatbázisban, ha már kinyomtatták a számlát!

    Egyetlen esetben találkoztam olyannal, hogy "árutételként" kezelték a borravalót:
     - Internetes rendelésnél előre "fel lehet ütni" olyan tételeket, hogy "Borravaló a futárnak" = x * 10Ft, vagy = x * 100Ft
    ha tudja az illető, hogy kártyával fog fizetni, vagy eleve online előre kifizeti.

    Mivel a programba a felszolgáló a valós kapott összeget, azaz a 15 forintot fogja beütni
    (vagy 50-et, vagy 100-at, mert rálegyint az ügyfél, hogy nincs 15 forintja és pofátlannak tartaná...) és a programtól várja, hogy nap végén kiszámolja a kapott borravalót.
    Amit ugye nem ütnek be a pénztárgépbe, mert nem hitelkártya alapú, ergo az NTAK-nak sem kellene ezt a részt elküldeni.

    Az odáig rendben van, hogy tudok egy olyat csinálni, hogy megnézem:
    if (abs(fizetettOsszeg - midösszesen) < 5) and (kpHUF > 0) then
      >> kerekítésként kezelem, nem pedig borravalóként az NTAK felé

    De az a legritkább eset. Szóval hogyan kezeljem, ha többet adnak?
    Mutasd a teljes hozzászólást!
  • A kerekítést csak akkor kell külön jelölni (fizetesiMod=KEREKITES) jelölni, ha a végösszeg (rendelesVegosszegeHUF) és az öt forintra "kötelezően" kerekített fizetett készpénz (fizetesiMod=KESZPENZHUF) eltér! Ha te külön tételben kezeled azt, hogy kihozd a végösszeget öt forintra, akkor a végösszeged és az öt forintra "kötelezően" kerekített fizetett készpénz megegyezik, így és téged nem érint kerekítés. Kivéve akkor, ha a vevő azt mondja és a rendszered megengedi azt, hogy a végösszeg 1000 forint, húzzuk le a szépkártya vendéglátás zsebéből az összeset, ami 987 forint és készpénzben kifizeti a maradékot, ami 13 forint, ami készpénzben kifizetve 15 forint, és a kerekítés -2 forint. (Az enyém ezt megengedi.)
    Mutasd a teljes hozzászólást!
  • Szaktanácsot kérnék mindenkitől:

    Hogyan kezeljem az 5 Ft-ra kötelező kerekítést?
     - Nálam eddig a számlából adott % alapú [kedvezményként / "szervízdíjként"] volt megoldva.

    Pl.:
    1003 Ft-nál >> +0.2% = 1005 Ft
    1003 Ft -10% kedvezménynél: 902,7 Ft >> -9,7706879% = 905 Ft
    1003 Ft +10% szervíz díj :  1103,3 Ft >> +10,16949% = 1105 Ft
    ... és % alapon ugyanígy szétszedve külön ÁFA csoportokra.

    Ennek köszönhetően még napi 1MFt forgalomnál sem voltak "kerekítési eltérések" az elszámoltatáskor + szupergyorsak voltak a statisztikai számítások.

    De az NTAK külön kéri a kerekítést. Akkor mostantól küldjek "hamisított adatokat" az NTAK felé?
    És mi történjen, ha még borravalót is adnak? Az eleve üti a kerekítést. Nem?
    Mutasd a teljes hozzászólást!
  • Szia!

    Akkor ha mondjuk valakinek Palo Alto-ban van az AWS szervere amin keresztül web-en küldi be az adatokat és az a szerver a csendes-óceániai közép időt adja vissza (ami GMT -8) akkor az uzenetKuldesIdeje = '2022-11-15T03:45:16.00-08:00'?
    a rendelesKezdete meg '2022-11-15T00:10:00.00+01:00'


    u.i
    Megette. Mondjuk jó lenne ha lenne valami webes felület, ahova be lehetne jelentkezni és megnézni hogy az NTAK a küldött adatokból pontosan mit tárol. Lehetne ellenőrizni a dátumokat a tételeket, az utf-8 kódolást (mint az OSA-ban).

    Üdv,
    Mocsa
    Mutasd a teljes hozzászólást!
  • Szia!

    Köszi.
    Csak azért gondoltam az UTC időt mivel az NTAK a PAST és FUTURE hibakódok esetén is UTC-t ad vissza.

    A+01:00 meg a logok nézegetése közben tök irreleváns mivel ilyenkor az időt a mindenkori helyi időben kell megadni. a +01:00 (vagy nyári esetén +02:00) csak azt mondja meg az adott idő az UTC-hez képes mennyi eltolódást mutat.
    Tehát a 2022-11-15T00:10:00.00+01:00 az ténylegesen 0 óra 10 percet jelent és semmit nem befolyásol ezen a +01:00

    Üdv,
    Mocsa
    Mutasd a teljes hozzászólást!
  • Kedves Péter!

     Most látom, hogy a doksiban már nem ISO 8601 dátumformátum a kötelező, hanem az arra épülő RFC 3339.
    RFC3339 - RFC-Wiki
    Azt javaslom, hogy (ahogy a PDF-ben látható példákban is szerepel,) egységesen:
    '2022-11-15T00:10:00.00+01:00'
    '2022-11-15' > targynap
    formátumban küldd nekik az időt.

    Bár az RFC szabvány hivatalosan ELFOGADJA a Z végződésű UTC formátumot is,
    és a végeredmény szempontjából (azaz, hogy mindet egy belső linux-timestamp formátumra konvertálják) teljesen mindegy,
    attól még szerintem sokkal olvashatóbb a +01:00 végű, mert nem kell fejben számolgatni az aktuális óraátállítás hónapjait, ha vissza kell nézni később egyes LOG-okat.
    Mutasd a teljes hozzászólást!
  • Sziasztok!

    Adott egy eset.
    2022-11-15-én hajnali 00:10 perckor iszok egy sört.
    majd 00.25 perckor fizetek

    Ti pontosan milyen időpontot küldtök be a targynap, rendelesKezdete és rendelesVege mezőkben?

    Mivel az NTAK megeszti az UTC idő is és a rfc-ben definiált időformátumot is nem mindegy milyen formátumban küldöm az adatot.

    igy a targynap szerintem = '2022-11-15'
    a rendelesKezdete lehet '2022-11-15T00:10:00.00+01:00' vagy '2022-11-14T23:10:00.000Z'
    a rendelesVege hasonló a rendelesKezedet-vel.

    Vélemény?

    Üdv,
    Mocsa
    Mutasd a teljes hozzászólást!
  • Igen, tisztelet,
    Régen mi is, és sokan igy csináltuk,
    de jó pár éve már az előfizetéses modell játszik,
    akkor is, ha megveszi a szoftvert, nem engedhetjük el a kezét.
    Az ügyfél kapja a változást ingyen, mert mindig van valami,
    amiért bele kell nyúlni a kódba. Vagy csak frissitést, új funkciót kap,
    aminek lehet hogy örül, mert más ügyfél miatt belekerült.
    Kiszámítható költség az ügyfeleknek is, nem egy egyszeri valami nagyobb díj.
    Nem szokott ezzel semmi probléma lenni, az ügyfelek elfogadják
    és neked is még nagyobb stabilitás lesz a havi díjakkból.
    Mutasd a teljes hozzászólást!
  • Mindig büszke voltam rá, hogy nálunk nem volt soha kötelező havidíj.
    Sőt, a jótállásból eredő frissítéseket 1 éven belül jelképes 10.000.- forintért biztosítottuk 1 hónapon át.
    (Azaz ha valaki hibát talált a programban, vagy pl. 1x az ÁFA változás miatt.)

    3x volt rá példa 20 év alatt, hogy ezzel élt volna valaki.

    A rekord az 13 év, azaz ennyi idő után hívott valaki pár hónapja, hogy még mindig használják az eredetileg megvett programot, ami kifogástalanul működött azóta is.

    Ennek most így vége.
    Mutasd a teljes hozzászólást!
  • maximálisan egyetértek amiket írtál.
    tényleg egy elköteleződés, egy bebetonozás egy szoftver használat.
    a havi díj alap, szerintem senki se árul dobozos szoftvert ma már.
    Ha meg váltani akar, akkor az új szoftverbe felvisz minden tételt egyesével,
    nyilván mi mint szoftver gyártó nem fogunk, egy egyetemista adatbázisát egy az egyben
    importálni.
    vagy csak minimiálisan, az alap adatokat, ha ő tudja a cikkeket pl. egy csv-be exportálni.
    Semmi több kb. szóba se jön.
    Mutasd a teljes hozzászólást!
  • Az a baj, hogy ha most feltennék azoknak a listáját, akik már beadták a vizsgafeladatokat, azzal még nagyobb pánikot keltenének.

    A free program valóban meg kellene ELŐZZE a fizetős programok listáját.
    Legalább 1 hónappal.

    És nem, az sem jobb, ha "majd kiadnak v2.0 v3.0 ... specifikációt", főleg úgy nem, hogy közben mondjuk ellehetetlenítik a meglévőt.
    (Pl.: Átírnak egy változónevet, vagy Áfát, vagy megváltoztatnak valamit a struktúrán. Mint az hallottam, ilyen megtörtént a NAV-os beadásnál, hogy az XML-ben egy kis/nagybetűt felcseréltek!)

    A folytonos változtatás azoknak a cégeknek kedvez, akik:
     - beszednek kötelező havidíjat,
     - holott nem csinálnak semmi fejlesztést.

    A piac és az ország akkor fejlődne igazán, ha a minőségi fejlesztés nyerne, tehát a jobb programot vennék, nem az olcsóbbat bérelnék, vagy amelyiknek jobb a marketingje.

    Most pontosan a másik végletet fogják most bebetonozni.

    Nem tudok elképzelni olyan esetet, hogy ezek után bárki egyszerűen váltson majd programot.
    Ha pedig mégis megteszi valaki, mert annyira elege van a meglévőből, akkor nekünk, gyártóknak kell majd 10x-es munkával "zökkenőmentes átállást" biztosítani, amit aztán könnyen lehet, hogy mind elbukunk anyagilag, mert kifizet 1 havi díjat, majd megy a következőt "próbálgatni".
    (Holott, ha valaki profi rendszert rak össze, és optimalizálni = segíteni akarja az étterem munkáját, akkor például egy pizzázó full IT beüzemése min. 2 hét, és a finomhangolás min 2-3 hónap!)

    Emiatt majd újabb havidíj-emelést kell a cégeknek eszközölniük, mire megjelenik egy 163. "Gipsz Jakab" egyetemista, aki 3 soros diplomamunkáját elnevezi "éttermi szoftvernek" és féláron a piacra  dobja. És így tovább ...
    Mutasd a teljes hozzászólást!
  • Nekem nem az a bajom, hogy nem tökéletes, onlineszámlából is már v3.0 van.
    De indítsák el, legyen élesben telepíthető, aztán majd adnak ki új verziót.
    Rájuk várunk, hogy kapjunk minősítést, engedélyt, mert addig egy szoftvert se lehet
    eladni.
    Persze el lehet, de az ügyfelek se, és senki se vett még egy új szoftvert se szerintem, akinek nem volt  korábban.
    mert ők is kivárnak, nézik a ntak weboldalt, az engedélyezetttek listája üres, nulla,  még semmi, hát akkor ők se  mozdulnak.
    igy aztán nehéz jan 1-re kész lenni.
    Az lenne a korrekt, hogy ha náluk van gebasz, akkor mondják hogy halasztás lesz.
    hol van a Vendégem free szoftver?  
    Az is egy fontos tényező. arra is várnak az ügyfelek, hogy megnézzék, hátha elég neki.
    és megannyi kérdés.
    Mutasd a teljes hozzászólást!
  • Hát, pedig számlázás terén az adóhatósági 2016 előtt meg online számla adatszolgáltatás 2018 előtt sem volt piskóta. (Adóhatóságinál a címbontás volt központi téma, online számla esetén meg még durvábban ment a fejlesztők meg szakértők meg ki tudja kik közötti adok kapok, hogy vagy előlegszámla végszámlája módosító okirat vagy sem!)
    Mutasd a teljes hozzászólást!
  • Szerintem ez nincs kitalálva még. Ilyet én még nem láttam, hogy ennyi kérdés merül fel!
    Pedig már minden állami rendszert illesztettünk. Ezt a dadogást még nem láttuk. 
    Én ezt nem értem.
    Mutasd a teljes hozzászólást!
  • Ja, értem, precizz vagy, de engem csak a teszt feladat érdekel, hisz az a minősités tétje.
    Ha hiba van, majd javitjuk. 
    De még a teszt feladara se reagáltak senkinek.
    Értem amit irsz, ès tök igaz.
    Mutasd a teljes hozzászólást!
  • Ennek mi értelme van, milyen statisztikát lát ebből az NTAK?
    Utólag felütögetni, összeadogatni áfa-nként a cetliket, tudom a pénztárgépbe is be kell ütni…
    Nincs áram a konyha egy része sem működik, inkább zárjon be, nem hiszem, hogy megéri vagy tud így nyitva tartani. (a pincérek manapság már nem vagy alig tudnak működni gép nélkül…)
    Talán, ha fajtánkként összesítve ütnék fel egy rendelésként, akkor a készlet is rendben lenne és statisztikát is nyerhetne belőle az NTAK. (persze ez + munka és idő a pincéreknek)
    Mutasd a teljes hozzászólást!
  • {"osszesitett" : true}
    Nekem fél év kellett, mire végre megértettem ezt a funkciót, ezért inkább megosztom, mire jutottam. Ennek az adatszolgáltatási formának a "magyarra fordított" neve helyesen:

    {"rendszerKiesesAdatpotlasa": true}
    Amit gyakorlatilag a felhasználók manuálisan kellene, hogy felvigyenek egyben olyankor, ha:
    - az RMS rendszerbe nem tudják rögzíteni a tételes adatokat a kiesés ideje alatt,
    - de attól még folytatják az üzlet tevékenységét pénztárgéppel vagy kézi blokkal.

    Azaz két eset lehetséges, amikor ilyesmi előfordul:
    1.) ha lokálisan futó rendszerről van szó, akkor ha :
     - tönkremegy a PC és nem tudnak adatokat felütni, vagy
     - megsérül az adatbázis, vagy
     - nincs áram és nem bírja a szünetmentes.

    2.) ha felhő alapú rendszerről van szó, (amilyen az NTAK ingyenese is lesz) akkor:
     - ... minden korábbi,
     - plusz akkor is, ha nincs internet!

    Szerintem a "lejárt tanúsítvány" logikailag soha nem fordulhat elő
    , hiszen ha utólag pótolják >>adatok bemennek, KÉSZ.
    Ha nem pótolják, akkor nem tudjuk beküldeni az "osszesitett"-et sem.

    A "természeti katasztrófa" pedig csak olyan extrém helyzetekben, ha valaki egy romokban heverő épületből hideg szendvicset árul kézi blokkal vagy akkus pénztárgéppel.
    Illetve talán ide sorolhatjuk az NTAK szerver teljes összeomlását is.

    Tehát ha lokális PC-re rögzítődnek az adatok, és elmegy az internet, de közben tudnak dolgozni, akkor:
     - NEM KELL használni ezt a funkciót,
    mert amint visszajön az internet, be tudnak küldődni az adatok.
    (Ezt válaszolták meg végre a legutóbbi konferencián.)

    Összefoglalva:
     Amit nem tudnak tételesen beküldeni, azt 3 vagy 6 sorban, egyetlen rendelésként összesítve megtehetik. (Persze külön-külön napokra bontva, nap végi zárással megtoldva.) Pl.:

    { ... "elvitel" : false, "osszesitett": true, "osszesitettIndoklasa": "UZEMZAVAR_ARAMSZOLGALTATAS_ATMENETI_KIMARADASA_MIATT" }, { "megnevezes":"Kiesett időszak éttermi fogyasztása 5%", "fokategoria": "EGYEB", "alkategoria": "EGYEB", "afaKategoria": "A_5", "bruttoEgysegar": 388100, "mennyisegiEgyseg": "EGYSEG", "mennyiseg": 1, "tetelszam": 1, "rendelesIdopontja": "2022-04-19T11:30:26.09+02:00", "tetelOsszesito": 388100 }
    Elvileg nagyon kicsi az esély arra, hogy ezt ne kellene mindünknek megcsinálnia, mert kizárt, hogy valami soha ne romoljon el.
    Mutasd a teljes hozzászólást!
  • Jól látod a helyzetet:
     - káosz, esélytelen.

    Én még nem küldtem be, mert készen sem vagyok.
    Hogyan is lehetnék, ha április óta máig sem kaptunk választ egy tucat fontos kérdésre?
    Eddig tartok 4500 sornyi kódnál, és még kell kb 1000-1500. (Delphi 7 alatt.)
    Olyan "extrákat" nem is fogok tudni idén megcsinálni, mint sztornó, helyesbítő, összesített ...

    Mostanra már régen fent kellene lennie a neten az ingyenesen kipróbálható NTAK-os változatnak!
    Amíg azt nem látják az éttermek, addig kizárt, hogy megvegyenek egy fizetőset.

    Előző hét péntekre (28-ra) ígérték a két nappal korábbi konferencián, hogy kiteszik az 1.03 PDF verziót...

    Engem már 2 ügyfél felhívott, hogy amit kiszámláztam nekik KATA időszakban, azt egyszerűen NEM fogják elutalni, sztornózzam le. (Nem tudom megtenni, mert a KATA időszak már le lett könyvelve, be lett adva.)

    Ha marad a 27% kiszállításos ÁFA, mindenki be fog zárni, max 1 szakáccsal a tulaj maga beáll a pultba pincérkedni (csak a helyben fogyasztást lekezelve,) és mindenki mást kirúg.
    Van olyan, akiről tudom, hogy már most megtette, amikor megkapta az első milliós villanyszámlát.
    Mutasd a teljes hozzászólást!
  • Reagálok magamra,
    Irták mások is, de tény, hogy még senkinél egy  új ügyfél se vett meg egy új szoftvert se,
    kivárnak az ügyfelek, nem hülyék.
    bennünk se bíznak, mert még nincs engedélyünk, azaz minősítésünk.
    van érdeklődés, kinél hogy, de szerintem az elenyésző.

    ha nov 15-re estleg kész lenne az ntak, mert ők még nincsenek készen,
    akkor 1 hónap alatt ez megoldható??,
    több 10 ezer ÚJ ügyfél-nél telepíteni programot,
    betanítani, és eszközöket kiszállítani?
    esélytelen.
    Júli 1 volt a határidő, és halasztották, azt hittem  júli 15-re kész vannak!
    November van az isten szerelmére és nincsenek készen. 
    És dec 20 után senki se dolgozik, ja, komolyan.
    Vagy szent este is betanítunk?
    1 hónap van reálisan, ha jövő hét végéig kész a rendszerük,
    és elbírálják a szoftvereket, az összeset.
    Mert mindenki beküldte, az tuti.
    Mutasd a teljes hozzászólást!
  • Az NTAK bővítésének halasztását kéri a Magyar Kereskedelmi és Iparkamara

    ide kommenteljeteek.

    mert az ntak belsős fórumra nyilván senki se mer, nyiltabban, ezek jönnek át nekem.
    mert az ntak moderálja.   név-cég szerint tudnak mindenkiről.
    Persze , ez nem jelent semmit,
    de, itt szabadabb.
    Mutasd a teljes hozzászólást!
  • Kocahozzáértőként

    Az előleget a végtermékkel azonos áfa kategóriával kell kiszámlázni.
    A kupon nem termékértékesítés, hanem pénzforgalom (mondom, szigorúan az én értelmezésemben), így nulla áfá-s.

    A törvény az áfafizetési kötelezettséget a gazdasági eseményhez köti, a pénzforgalom önmagában (én kölcsönadok neked vagy kupont adok) még nem gazdasági esemény.
    Mutasd a teljes hozzászólást!
  • Olvastam ugyanezt a kérdést az NTAK fórumán is, de nem tudom a választ.
    Emailben tedd fel nekik, háááátha válaszolnak rá.
    Ha megtették, kérlek másold be az NTAK fórumra is !

    Amúgy én már kértem tőlük emailben hivatalos válaszokat 9 kérdésre április óta, de egyikre sem válaszoltak.
    Mutasd a teljes hozzászólást!
  • Köszönöm a választ!

    A kupont amit az ügyfél vesz, nem kell küldeni az NTAK felé?

    Milyen áfa-val adom a kupont, 27% vagy mentes, mert nem tudom mit fog fizetni vele?

    Ha kuponnal fizet, akkor a fizetési módnál mit kell küldeni VOUCHER vagy EGYEB?
    Mutasd a teljes hozzászólást!
  • Szerintem az a megnevezéstől függ:
    1. Ha fel van sorolva a megnevezésben, akkor a magasabb ÁFA kulcshoz kell besorolni.

    2. Ha nem tünteti fel külön a dobozt, akkor a jogszabály szerint a csomagolást ilyenkor nem kell figyelembe venni, tehát elválaszthatatlan részét képezi a terméknek.

    Szóval nem éri meg az étteremnek "külön plusz csomagolás díjat" felszámolni, két okból:
    - amennyiben a szórólapján + honlapján nem írta ki minden egyes termékhez külön külön, mennyi plusz pénz a csomagolás, úgy jogszabályt sért !
    - több ÁFÁt fizet így.

    Egy időben keményen rászálltak az ilyen trükközőkre, akik az étlap vagy szórólap aljára írták csak rá kisbetűkkel, hogy "elvitel vagy kiszállítás esetén +150 Ft csomagolási díjat számítunk fel termékenként." Kár, hogy mostanában már nem büntetik eléggé az ilyen csalókat.

    A Hamburger amúgy NEM 18%-os elvitelre és kiszállításra, hanem 27%. Logikát ne keress benne, szimplán azért csinálták így, hogy a nagy nemzetközi hamburgerláncokat továbbra is fullra skalpolhassák.
    (Ami jó dolog, de a kis-hambis micro vállalkozások is szívnak vele.)
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd