Adóhatósági ellenőrzési adatszolgáltatás (online számla)
2015-10-14T14:05:27+02:00
2022-09-10T22:10:39+02:00
2022-09-11T18:30:25+02:00
  • Ja, okés,
    mindig igy szokták a programozók, 
    megállnak, segítséget kérnek, aztán 
    úgy is rájönnek maguktól 10 perc múlva.
    csak kell egy kávé szünet :)
    Magamra ismerek.
    Üdv.
    Mutasd a teljes hozzászólást!
  • Megvan. Rossz helyre küldtem :D
    Bocsi.
    Mutasd a teljes hozzászólást!
  • Szia, 

    az egészet még a  QueryInvoiceDigestRequest tagbe kell rakni,
    meg a header stb-t kitölteni.
    nálam igy jó.
    <QueryInvoiceDigestRequest xmlns:common="http://schemas.nav.gov.hu/NTCA/1.0/common" xmlns="http://schemas.nav.gov.hu/OSA/3.0/api"> <common:header> </common:header> <common:user> </common:user> <software> </software> <page>1</page> <invoiceDirection>INBOUND</invoiceDirection> <invoiceQueryParams> <mandatoryQueryParams> <invoiceIssueDate> <dateFrom>2022-01-27</dateFrom> <dateTo>2022-02-01</dateTo> </invoiceIssueDate> </mandatoryQueryParams> </invoiceQueryParams> </QueryInvoiceDigestRequest>
    Mutasd a teljes hozzászólást!
  • Üdv!

    Elég "hülye" kérdés:
    Melyik operációval tudom lekérdezni egy adott időpontban kiállított bejövő számlák listáját?
    Azaz, hogy milyen számlákat állítottak ki a cégnek.
    A QueryInvoiceDigestRequest operációt néztem ki.
    Ennyit adtam meg paraméterbe:

    <invoiceDirection>INBOUND</invoiceDirection> <invoiceQueryParams> <mandatoryQueryParams> <invoiceIssueDate> <dateFrom>2021-03-01</dateFrom> <dateTo>2021-04-01</dateTo> </invoiceIssueDate> </mandatoryQueryParams> </invoiceQueryParams>
    Viszont ezt a hibát kapom:

    Érvénytelen kérés!
    Köszönöm!
    Mutasd a teljes hozzászólást!
  • Találkoztatok ilyen üzenettel?
    Utóbbi napokban jön ilyen vissza néha. Persze később aztán bemegy a számla.

    V3 nem elérhető: HttpRequestException: Hiba történt a kérelem elküldésekor.
     WebException: Nem lehet csatlakozni a távoli kiszolgálóhoz.
      SocketException: errorCode=10055 (NoBufferSpaceAvailable) - A szoftvercsatorna-művelet nem hajtható végre, mert a rendszerpufferben nincs elég hely, vagy mert egy várólista megtelt
    Mutasd a teljes hozzászólást!
  • hát igen.
     
    módosítón/sztornón áfatörvény szerint nem kötelező a teljesítési dátum, persze, ha pont azt módosítom, akkor nyilván tartalmazza.

    nav-online szerint a teljesítési dátum, vagyis  az invoiceDetail alá tartozó invoiceDeliveryDate nem maradhat üresen.
    tök mindegy, hogy számla, módosító, vagy sztornó.
     
    alapesetben a módosított számla teljesítési dátumát kell beleírni, tök feleslegesen, hiszen benne van a már beküldött számlában.
     
    de ha már annyira ragaszkodnak az értelmetlen duplikált adatközléshez,
    akkor pl. miért nem az invoiceReference-ben kell megadni, ahogy te is felvetetted.
     
    vagyis, a nav-online szerint módosító/sztornó xml-jében mindig szerepelnie kell egy tényleges, valódi teljesítési dátumnak (invoiceDeliveryDate),
    miközben az áfatörvény szerint a bizonylaton nem, ráadásul ide nav-online szerint az eredeti számla teljesítési dátumát kell megismételni,
    az attól eltérő dátumot pedig automatikusan teljesítési dátum módosításnak veszi.
     
    ha nem kellene kötelezően teljesítési dátumot megadni a módosító/sztornó xml-jében, a teljesítési dátum megadására szolgáló mezőben  (invoiceDeliveryDate),
    akkor msot nem lenne miről beszélni.
     
    de nav-online szerint meg kell adni, és mostanára nyilván feltűnt ott valakinek,
    hogy nagyon sok számlázó program módosító/sztornó esetén beírja a napi dátumot teljesítési dátumnak.
     
    UNINTENDED_MODIFICATION_DELIVERY_DATE:
    Jelez, ha a beküldött módosítás vagy érvénytelenítés az alapszámla teljesítési
    dátumát a módosító számla keltére módosítja. Ez egy többször előforduló hiba
    a számlázó programokban.
     
    persze, erre fel lehet vetni, hogy pl. ár módosításnál vagy sztornónál minek ad meg a program teljesítési dátumot,
    amire természetesen fel lehet vetni, hogy mért nem előzte meg a nav-online bevezetését széleskörű
    egyeztetés, konzultáció, mert ha ilyen lett volna, akkor ilyen hibaüzenetek, meg hozzájuk kapcsolódó
    posztok nem is léteznének.
    3 évvel a rendszer bevezetése után !!! amire nyilván az válasz érkezne, hogy hatalmas nagy konzultáció volt.
    Mutasd a teljes hozzászólást!
  • Nekem nincs gondom az adatszolgáltatással, meg a technikai kivitelezésével sem.
    1. Számlaadat-szolgáltatás esetén minden esetben meg kell adni a teljesítési dátumot
    (invoiceDeliveryDate). Ha nem szerepel a számlán a teljesítési dátumra vonatkozó explicit adat, akkor az Áfa törvény alapján a teljesítés dátuma a számla kelte (invoiceIssueDate), tehát az
    invoiceDeliveryDate elemben ugyanazt a dátumot kell szerepeltetni, ami az invoiceIssueDate elemben
    szerepel.
    2. Pl. én IT-s vagyok. Egy irodát építek. A megmaradt anyagot hogyan számlázom vissza. Az nem egy program, nincs építőanyag kereskedelmem, vagy magánszemély is lehetek. A kereskedő vevő és a kereskedő szállító oda-vissza számlázhat egymásnak.
    3.Komoly felhasználóknál ezt is csinálják, de pl egy nagy építkezés évekig mehet, 8 napon belül számlázni kell.
    Mutasd a teljes hozzászólást!
  • és ha nem írsz teljesítési dátumot a módosítóra ? végül is nem kötelező.
    a könyvelő meg majd kiszámoolja a neki megfelelő Tdátumot az alapbizonylat meg a módosító alapján.
     
    nincs ilyen ügyfelem, kíváncsiságból kérdezem, nem lehet ezt úgy csinálni, hogy kiszámlázom az egészet,
    ő kifizeti, innentől az ő tulajdona, amit nem használ fel, ő adja el nekem ? ő állít ki számlát, én nem módosítok semmit.
     
    vagy csak arról állítok ki számlát, amit tuti felhasznál, a többiről szállító készül,
    majd a felhasználás fügvényében számla.
    Mutasd a teljes hozzászólást!
  • Ott már pénteken teszteltem... Azt írták, hogy a 3.18.2-es verzióban kiveszik, a kint lévő verzió a fejlesztői infók szerint 3.18.1, mégsem jöttek az üzik :)
    Mutasd a teljes hozzászólást!
  • Még jó, hogy a teszt felületen nincs ilyen hír...
    Mutasd a teljes hozzászólást!
  • Győzelem!

    Most néztem néhány ügyfelemnél, hogy nemcsak az aznapi hibás üzenetet vették ki, hanem a korábbi módosítás esetén küldött üzenetet is.
    Mutasd a teljes hozzászólást!
  • Szia!

    Most olvasom:
    Online Számla 3.18 verzió

    2. INFO üzenetek kikapcsolása

    Az
    Online Számla rendszer 3.18.2-es verziójában, a GitHub-on érkezett
    jelzések alapján, a javításig megtörtént az
    UNINTENDED_MODIFICATION_DELIVERY_DATE és az
    INCORRECT_HEAD_DATA_SUPPLIER_BANKACCOUNT_MISSING info üzenetek
    kikapcsolása.

    Ez lehet, hogy csak az aznapi problémákat rendezi, mert hiba volt, aznapi számla és módosítása esetén is jött a hibás üzenet.
    Mutasd a teljes hozzászólást!
  • Igazából én nem tudok törvényi hivatkozást, és nem is akarok a sok zavaros törvényben keresgélni.
    A sok hülye zavaros dátum. Ha rajtam múlna, egyetlen dátum lenne, az pedig a kibocsátás dátuma. Hosszú távon tök mindegy, hogy milyen dátumokhoz mérjük a dolgokat.
    A visszaadott válasz miatt dobtam be a témát.
    Több könyvelőt kérdeztem, azt mondják így kellene, de ők sem így várják.
    Ott van egy link az előző levelemben, ahol fejtegetik a témát.
    Mindössze egy ügyfelem jelzett vissza, hogy így kéri. Azóta nem jönnek az INFO üzenetek.
    A többieknél jönnek, de most már az ő dolguk.
    Fura, hogy pl egy kp-s visszavételnél mondjuk az egy évvel ezelőtti dátum a teljesítés, viszont ma, de mégis tavaly kapná vissza a pénzt a vevő.
    Mennyivel egyszerűbb lenne, ha az invoiceHead az éppen beküldött számlára vonatkozna (mint a többi adat is az invoiceDetail részben), és adott esetben a refrenciában lenne az eredeti számla teljesítés dátuma, ami mondjuk már ott van.
    Mutasd a teljes hozzászólást!
  • Szia,

    Erre esetleg tudsz valami törvényi hivatkozást? "Hatalmas viták folynak erről a háttérben. A NAV azt szeretné (és valójában úgy is kellene), hogy a módosító számlák teljesítési dátuma megegyezzen az
    eredeti számla teljesítési dátumával."

    Sztornó számlánál teljesen rendben van az elmélet. Viszont én nem igazán találtam olyan jogszabályt, miszerint módosító okirat kiállításnál ne változhatna a teljesítési dátum. Sőt! Millió olyan oldal található, ahol olyan leírás van, ami arról szól, hogy a teljesítési dátum módosulhat helyesbítő számlán. Ez persze nem jelenti azt, hogy jó a módszertanuk. 4 könyvelőt sikerült megkérdeznem a témában, ők is mind alátámasztották, hogy módosulhat a teljesítés.
    Sőt! Visszáru kérdése... A NAV azt mondta, hogy nem létezik olyan, hogy visszáru, negatív számla. Ehelyett számlával egy tekintet alá eső okiraton kell visszavételezni. Na most ha ez meg is történik egy módosító okiraton, a göngyöleg nem az akkori teljesítési dátumon kerül vissza.
    Mutasd a teljes hozzászólást!
  • Ez módosító számla esetén van.

    <invoiceDeliveryDate>2022-05-20</invoiceDeliveryDate> Ha itt nem az a dátum van, ami a refrencia számla teljesítés dátuma, akkor jön az infó
    Hiba van benne, írták itt többen, hogy aznapi számlák esetén is jön, amikor viszont a dátumok megegyeznek.
    UNINTENDED_MODIFICATION_DELIVERY_DATE figyelmeztetés azonos napon készült alapbizonylat és módosítás
    Eddig egy ügyfelem írta vissza, hogy fixáljam le a teljesítés dátumot.
    A többiek rugalmasak.
    Mutasd a teljes hozzászólást!
  • Az szép.

    Két lízingcég ügyfelem van. Ott a napi ügymenet része, hogy 3-4-5 évvel ezelőtt kiállított számlákat helyesbítenek. Pl. mert felmondják a szerződést és ilyenkor az ügylet létrejöttekor kiállított úgynevezett birtokba adási számlát kell jelenértékkel vagy jelenkori piaci értékkel helyesbíteni.

    Nyilván őrültség lenne ma kiállítani egy helyesbítő számlát, amelynek teszem azt, 2018 lenne a teljesítés dátuma.

    Egyébiránt mi még nem találkoztunk ezzel a NAV figyelmeztetéssel.
    Mutasd a teljes hozzászólást!
  • Ezt írtam ügyfeleimnek:

    Kedves Ügyfelem!

    2022.08.09 óta a NAVhoz beküldött módosító számlák (jóváíró, érték módosító, stornó) esetén. ha a teljesítés dátum nem egyezik az eredeti számla
    teljesítés dátumával, akkor az alábbi üzenet jön vissza.
    OK 3V7GO07NULUOBWR1
    Validációs üzenet: INFO: UNINTENDED_MODIFICATION_DELIVERY_DATE A módosítás az eredeti számla teljesítési dátumát a módosító számla
    keltére módosítja.; tag: InvoiceData/invoiceMain/invoice/invoiceHead/invoiceDetail/invoiceDeliveryDate; value: 2022-08-09; line: NULL; originalInvoiceNumber: NULL

    UNINTENDED_MODIFICATION_DELIVERY_DATE: A teljesítés dátum nem szándékos módosítása
    Ez INFO és nem ERROR.
    Tehát úgy tekinti, mintha meg akarnánk változtatni az eredeti számla teljesítés dátumát.

    Hatalmas viták folynak erről a háttérben. A NAV azt szeretné (és valójában úgy is kellene), hogy a módosító számlák teljesítési dátuma megegyezzen az
    eredeti számla teljesítési dátumával.
    Én ezt adott esetben néhány perc, vagy egy-két napon belül meg tudnám oldani (nem engedném módosítani a módosító számla teljesítési dátumát),
    viszont akikkel beszéltem nem tetszene nekik.
    Azt nem tehetem, hogy a NAV-nak beküldött számla az ő ízlésük szerint legyen, a papíron meg más szerepeljen. (Ez sem okozna problémát nekem.)
    Az alábbiakat tehetem.
    1. Lefixálom a teljesítés dátumot, és nem engedem módosítani. (Ezt szeretné a NAV)
    2.Alapértelmezésben az eredeti teljesítés dátum jönne fel, amit a kezelő módosíthat.
    3. Minden marad a régiben, és fizetési módtól függően jönne fel a teljesítés dátum és módosítható lenne.
    4.A papíron a beírt teljesítés dátum jelenne meg, de a NAVhoz az megy, amit elvár. (????)

    Várom a visszajelzéseket.
    ****
    Ezért bátorkodtam azt írni korábban, hogy az invoiceHead közti részek az éppen beküldött számlára vonatkozzanak, és az eredeti számla teljesítés dátuma pedig a invoiceReference-ben legyen
    Mutasd a teljes hozzászólást!
  • Nekem is lenne egy kérdésem.
    Most írtam az "ANNUL" operációt, de "érvénytelen aláírás" hibával jön minden próbálkozásom vissza!
    Mind eközben a cseretokennél simán bemegy a kérés, és visszajön a responsében a token.
    Azután egy ezred másodperccel később ugyan ez rutin már össze is rakta a ManageAnnulmentRequest -et, beküldi és az meg elszáll...
    Három napja kínlódom vele, lépésről lépésre mindent kiírattam már, folyvást ellenőrzöm, de semmi hibát nem látok.
    Viszont gyanúsan régi, 2020-08-31. havi "OSA Schemas_v3" minta alapján és 21-12.havi utoljára módosított pdf leírás alapján dolgozom, nem találtam azóta újabbat.
    Van valakinek tapasztalata e téren?
    köszönöm.
    Mutasd a teljes hozzászólást!
  • Azt én sem értem, hogy sokan miért keverik az áfa-teljesítést a tényleges (fizikai) történés időpontjával.
    Az áfa-teljesítés időpontja egy törvényi fikció, kalkuláció, ami esetenként egyezik a tényleges esemény időpontjával, de nem feltétlenül.
    A lényeg az egész belinkelt beszélgetésből:
    "..Abban az esetben, ha az eredeti eladó és az eredeti vevő között olyan tartalmú szerződés jön létre, amelyben külön kikötik, hogy bizonyos feltételek megvalósulása esetén az eredeti vevő kérésére az eredeti eladó köteles lesz a dolgot átvenni és a szerződésben meghatározott vételárat megfizetni, akkor új ügyletről van szó."
    Az új ügylet pedig új számla, hiszen az előző ügylet már teljesült, lezárult (a vevő az árut átvette és a számlát befogadta lehetséges, hogy már ki is fizette).
    A visszáru ilyen esetben egy új ügylet.
    Nem értek egyet abban az adószakértővel, hogy ilyenkor feltétlenül a vevőnek kellene a számlát kiállítania, mert a szállító - aki visszavásárolta - a következő számlájában jóvá is írhatná és a gyakorlatban szinte minden kereskedelmi ügyletben így is működik.
    Mi több százezer számlát küldtünk már be, jellemzően ilyen ügyfeleink vannak.
    És egy sincs, aki másként tenné.
    Azaz a visszáru minden esetben a következő számlán egy következő teljesítési időponttal és egy következő áfa-teljesítési időponttal fog szerepelni.
    Abban viszont igaza van a szakértőnek, hogy a két időpontnak vajmi köze van egymáshoz és az analitikát nem a számlákból kellene vezetni!
    Nekünk egy ERP rendszerünk van és tudom, hogy sok ERP rendszer számviteli alapon közelít meg (véleményem szerint hibásan!) mindent - ebből ez a félreértés is -, nem pedig a gyakorlati vonatkozásokban.
    A miénk természetesen nem a számvitelt preferálja, nem arra épít, hanem a gyakorlati, üzleti folyamatokra és így a számvitel egy eredmény-oldalág, egy nyilvántartási rendszer, amely gazdálkodást segítő vonal.
    A számlázás is oldalág és nem a nyilvántartások alapja.
    Az alapokat készletek jelentik és erre jön rá a megrendelés állomány, ezek pedig együtt generálják az üzelti folyamatokat.
    Mutasd a teljes hozzászólást!
  • UNINTENDED_MODIFICATION_DELIVERY_DATE
    Emiatt robbant ki ez az egész részemről.

    Akkor viszont itt csak az "invoiceDeliveryDate" vonatkozik az alapszámlára?
    Vagyis annak a teljesítés dátumával kell, hogy egyezzen?
    Miért csak ez az egy van kiemelve?
    Ha azzal kell, hogy egyezzen, akkor ezt sort simán ki lehetne hagyni, hiszen az alapszámla már ott van.
    Ha pedig simán változtatni akarok az alapszámla teljesítés dátumán, akkor van arra más módszer is.
    Pl az alapszámla tétel nélküli számlafej módosítása
    <invoiceDetail> <invoiceCategory>NORMAL</invoiceCategory> <invoiceDeliveryDate>2022-05-20</invoiceDeliveryDate> // ez megváltoztatná az alapszámla teljesítési dátumát <smallBusinessIndicator>false</smallBusinessIndicator> <currencyCode>HUF</currencyCode> // pl ez miért nem? alap EUR, módosító HUF <exchangeRate>1</exchangeRate> <utilitySettlementIndicator>false</utilitySettlementIndicator> <paymentMethod>CASH</paymentMethod> // vagy ez? TRANSFER/CASH <paymentDate>2022-08-10</paymentDate> <invoiceAppearance>PAPER</invoiceAppearance> // vagy ez? ELECTRONIC/PAPER </invoiceDetail>
    Nem látom a logikát.
    Mutasd a teljes hozzászólást!
  • igen. az a baj a sok adózással és számvitellel kapcsolatos rendelettel, jogszabállyal, hogy gyakran öncélúak és a társ intézményekkel (amely jogszabályi gyűjtemény, törvény is lehet) csak később szeretnék harmonizálni, de akkorra kiderül, hogy számos ellentmondást nem, vagy csak nehezen, körmönfontan lehet feloldani.
    Jó példa erre épp a NAV és pü minisztérium által szorgalmazott - és elért - online számla adatszolgáltatás kontra már meglévő jogszabályok, amelyek sok esetben nem voltak (és máig most sincsenek) releváns kapcsolatban. Számos ellentmondás van az áfa tv.-el, vagy a számviteli törvénnyel ütközően.
    Mutasd a teljes hozzászólást!
  • Természetesen én is úgy tudom, ahogy írod.
    Én is megengedem a módosítást, de a default az alapszámla.
    Ma reggel beszéltem egyik ügyfelem könyvelőjével, aki megmondta, nehogy véletlenül hozzányúljak a módosító számla teljesítés dátumához, mert ő nem fog esetleg évekre visszamenően önellenőrzést csinálni. (ő is tudja, amit írtál)
    Akkor mit csináljak? Az xml-be írjam, amit a NAV elvár, a papírra meg, amit a kibocsátó akar?
    (Végül is a kibocsátó a felelős)
    Képzelj el egy építőanyag forgalmazót, ahonnan nagy építkezésre számtalan anyagot kivisznek, majd évek múlva a maradékot visszaviszik. Ez nagyon gyakori dolog.
    Megőrül az a könyvelő, aki ezt normálisan végig akarja csinálni.
    A számla fej a számla számát, kibocsátó, vevő adatait, dátum adatokat, fizetési módot, stb tartalmazza. Ez, mint referencia van a módosító számla esetén a számlaláncban, de nem soroljuk fel az adatokat, csak a számla számát.
    Tehát, ha módosító számla esetén az eredeti teljesítés dátumot a referenciában helyeznénk el, minden megoldódna egy csapásra. (A másik dátum meg egy másik infó lenne)
    Különben sem értem ezt a sok dátumot. (számviteli törvény, áfa törvény, stb)
    Csak arra jó, hogy lehetőleg kevesen értsék.
    Mutasd a teljes hozzászólást!
  • ... szerintem ezzel kapcsolatban ez a helyzet:
    De előre mondom, hogy az én számlázó rendszerem megengedi a helyesbítő számlánál a dátum adatok módosítását (a sztornónál nem), és a legtöbb ügyfelem a korrekciós számlánál új fizetési határidőt - ennek megfelelően - új áfa-teljesítési időt határoz meg és lehetséges, hogy nekik van igazuk, de ettől függetlenül én így értelmezem a jogszabályi környezetet:
    Módosító számlák az alábbiak lehet:
    - adóalapot, illetve az áfát érintő változások (tételekben, árak, mennyiség, áfakulcs, stb.) 
    - egyéb számla adatok, szöveges információk, nyilatkozatok, stb módosítása.
    Ha a teljesítés időpontja jó, akkor azt nem módosítjuk.
    Ha a fentiek okán kell egy helyesbítő számla, az semmiképpen sem érintheti a teljesítés időpontját, mivel az eleve már (a tényleges szállítási teljesítés és megállapodás - folyamatos, stb.) figyelembevételével, az Áfa trv. szerint lett meghatározva.
    Tehát a helyesbítő számlában a teljesítés időpontja nem módosítható, meg kell egyeznie az eredeti számlán szereplő teljesítési időponttal.
    Ha a helyesbítő számla az eredetileg számlázott összeget módosítja, elvileg az sem érinti a teljesítés időpontját, és így a teljesítés időpontja ekkor sem módosulhat. 
    A számlakorrekció helyesbítő, vagy érvénytelenítő okirattal (sztornóval):
    - ha az ügylet létrejött akkor a helyesbítő számla kiállítására van szükség, amely csak, a módosítandó tételeket tartalmazza (eredeti, meg annak lemínuszolása + a korrekció).
    - akkor viszont, ha az ügylet (az eredeti számlán "ábrázolt módon") nem jött létre a számlát érvényteleníteni kell!
    Én úgy tudom, hogy az áfa törvény szerint elvben csak ilyen esetben lehetne érvényteleníteni, más kérdés, hogy ezt aztán senki sem veszi kőbevésett dolognak, mindenki sztorníroz és másik számlát állít ki és nyilván ekkor az érvénytelenítő okiratban majd pedig az új számlában is ugyanaz lesz a teljesítés időpontja, mint az eredeti számlában volt.
    Nem tudom pontosan itt Ti mit értetek a "számlalánc feje" alatt - gondolom ugyan ezt -, de minden számlának önálló, egyedi sorszáma van amely hivatkozik arra a sorszámra amely az eredeti volt - helyesbítőt nem helyesbítünk(!) -, és nyilván a teljesítési időt, illetve a kiszállítási (tényleges teljesítési ) időpont és a sallang szövegek azonosak, hiszen egy ügyletről van szó...
    At áfa-időszakok eltérhetnek:
    Ha a helyesbítő számlában az ÁFA-időszak eltér (visszamenőleges) akkor önellenőrzéssel kell azt a könyvelésnek helyretennie.
    ...de lehet, hogy nincs igazam.
    Mutasd a teljes hozzászólást!
  • Itt valójában nem a negatív számláról van szó.

    Egy számlát akárhányszor módosíthatsz, de a számla láncnak csak egy feje van, de a számla tételek az alapszámla után -a módosítás miatt- időben elcsúszva képződnek.
    A közbenső módosítások persze lehetnek negatívak.
    Papíron minden számlának ugyanaz a feje egy-két adattól eltekintve, de a számlaláncban csak egy fej van. (úgy gondolom)

    Akkor viszont itt csak az "invoiceDeliveryDate" vonatkozik az alapszámlára?
    <invoiceDetail> <invoiceCategory>NORMAL</invoiceCategory> <invoiceDeliveryDate>2022-05-20</invoiceDeliveryDate> <smallBusinessIndicator>false</smallBusinessIndicator> <currencyCode>HUF</currencyCode> <exchangeRate>1</exchangeRate> <utilitySettlementIndicator>false</utilitySettlementIndicator> <paymentMethod>CASH</paymentMethod> <paymentDate>2022-08-10</paymentDate> <invoiceAppearance>PAPER</invoiceAppearance> </invoiceDetail>
    Mutasd a teljes hozzászólást!
  • Kösz.
    Nem is lenne ezzel gond. Mi is így gondoljuk.
    Nem nagy ügy ennek megfelelően küldeni a számlákat.
    A napon belüli módosításra viszont még mindig a hibás üzenet jön.
    Könyvelővel beszéltünk, azt mondta, hogy módosító számla esetén nincs szerepe a teljesítésnek, és szerinte -ha mégis- a teljesítés a módosító számla dátuma. (valószínűleg ezt az áfara értette)
    6 könyvelő rendszerrel dolgozunk együtt, s ha az eredeti teljesítés dátumot adnánk át meghülyülne a rendszer. Akár a korábbi év(ek)re visszamenőleg gyűrűzne a dolog.
    A módosító számla dátumát átadva pedig minden rendben lenne. Az áfát kapok vissza most, ezt nem tudom visszakapni tavaly.
    Tehát külön kell(ene) választani a számla teljesítés dátumát és az áfa teljesítés dátumát könyvelésileg. Van ahol mindkét dátumot kéri a könyvelő rendszer, van ahol csak a számla teljesítés dátumát.

    A referencia azért van, hogy ott intézzük el az előzményt.
    Az invoiceHead pedig az éppen beküldött számlára vonatkozik.
    Oda miért kell belekeverni referencia dolgokat?

    Véleményünk szerint itt az lett volna logikusabb, ha a referenciába tesszük az alapszámla teljesítés dátumot, és a ...invoiceDetail/invoiceDeliveryDate csak az éppen beküldött számlára vonatkozna, így nem lenne kavarás.
    <invoiceReference> <originalInvoiceNumber>056366</originalInvoiceNumber> <invoiceDeliveryDate>2022-06-15</invoiceDeliveryDate> <modifyWithoutMaster>false</modifyWithoutMaster> <modificationIndex>1</modificationIndex> </invoiceReference>
    Mutasd a teljes hozzászólást!
  • Ez megint a negatívos számla kiállítása témakör.
    Ha a teljesítést visszateszed, akkor az azt jelenti, hogy az értékesítés akkor meghiúsult. Vagyis ha a két időpont között pl. volt egy leltározásod (karácsonyi ajándék visszahozása) akkor az hiány vagy töblet?! Az év végével leadott készletértéked sem fog stimmelni,... Pedig fizikailag a termék nem volt nálad és előre nem tudhatod, hogy visszahozzák. Valójában ennek szerintem két külön gazdasági eseménynek kellene lennie, amiről a vevő általában nem tud számlát adni, így maradna a negatívos számla, ami viszont nem jó a NAV szerint. De ezt már többször megfutottuk...
    Mutasd a teljes hozzászólást!
  • Szerintem nem.
    A teljesítése akkor volt mikor az eredeti számlát kiállítottad, hiszen a rajta szereplő tételeket akkor értékesítetted. Most csak módosítottad.
    Mutasd a teljes hozzászólást!
  • UNINTENDED_MODIFICATION_DELIVERY_DATE
    Ez az INFO üzenet jelenik meg, ha pl  egy  korábbi számlát módosítok.
    Eredeti számla teljesítés dátuma egy korábbi nap.
    Egy áru visszahozása miatt módosítás kell.
    Mi a módosító száma teljesítés dátuma, ha az árut ma hozzák vissza?
    Ma "teljesítődik".
    Mutasd a teljes hozzászólást!
  • Nem tudja valaki, az új kATA törvény mikor kerül a jelentésbe?
    Gondolom a taxis kivétel miatt lesz változás:((
    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