Programfrissítések

2024.07.03 2.41-es változat

• Új rendszer paraméter lehetőség: RS_EK_CIKK_V X Ha beállítják, az ajánlat/rendelés tételek valamint a számla/szállítólevél kiadás tételek űrlapokban az R/S gombbal eddig is lekérhető választó ablakban a cikk raktárankénti/sorozatonkénti pillanatnyi készlete mellett látható a cikk adott raktárhoz tartozó értékesítési körzetében (minden sorozatra összesítve) a pillanatnyi vihető készlet. Ha nincs beállítva, akkor 0 érték van az oszlopban és talán valamivel gyorsabb a működés.
• Új nyomógomb az ajánlat/rendelés tételek űrlapon: 'Info' Az ajánlat/rendelés tételeiben előforduló cikkszámokra szűkítetten kéhető le a 'Készlet info', így utólag rálépve pl. egy vevő rendelés tételeire megnézhető, hogy azok (az adott értékesítési körzetben?) teljesíthetőek-e, van-e elég vihető készlet.
• A számla/szállítólevél kiadás tételek űrlapokban a 'Rend.sz' gomb megnyomásakor a teljesítetlen megrendelés sorok végén látszik, hogy a rendelés zárolt-e vagy sem (r_ny Z: zárolt)
• Új rendszer paraméter lehetőség: ERTEK_ELLMOZ mmm,mmm,mmm, Itt beállíthatóak azok a (jellemzően értékesítési, pl. 80 ,85 , ) mozgáskódok 3 karakteren vesszővel elválasztva és lezárva, amelyeknél nulla eladási érték esetén mentéskor a program kérdezzen rá, hogy biztos jó lesz-e így. (Hogy véletlenül ne lehessen valamit 0 értékkel eladni)
• Új mezők a cikktörzsben: második csomagolási mennyiségi egység és váltószám. A váltószám ennél is a fő mennyiségi egység előfordulásának számát jelenti a második (jellemzően az elsőnél még nagyobb) csomagolási egységben (pl. raklap). A bevét tételek, az ajánlat/rendelés tételek valamint a számla/szállítólevél kiadás tételek űrlapokban a mennyiség ebben a második csomagolási egységben is kiíródik illetve megadható. A Készletszint és Készlet info ablakokban a pillanatnyi mennyiség ezen másodig csomagolási egységben is látszik. Az adat a bizonylatok adatnézetébe is bekerült, így lehetőség van egyedi bizonylat riportokra (bevét, számla, szállítólevél, visszaigazolás,megrendelés stb.) kérésre rátenni további kis egyedi fejlesztés keretében.

2024.02.19 2.40-es változat

• A 2024-es áfa bevallás/xml sémát a NAV kismértékben változtatta a tavalyihoz képest, így a korábbi verziókkal készített ABEV_65.xml importálása során hibaüzenet jelenik meg (bár utána a betöltés helyesen megtörténik).  Az ezzel a verzióval készített áfa xml fogadása már nem ír ki hibát.
• EDI kimenő számla fogadás kismértékű javítása/bővítése úgy, hogy el nem készült számlák fogadásakor lehetőség van számlasor szöveg, számla egyéni hivatkozás, saját bank és bizonylat szöveg fogadására is.

2023.03.18 2.39-es változat

• Már érvénytelenített eredeti számlára történő újabb módosító számla esetén a NAV jelentés rossz volt, javítottuk. Jelenleg a NAV Warn (Sárga) figyelmeztetéssel jelzi az ilyen módosító számla esetén, hogy volt már érvénytelenítés. (Korábbi NAV dokumentációban, állásfoglalásokban ezt az esetet még helyesnek fogadták el.) A rendszer paraméterekben beállítható, ha azt szeretnék, hogy érvénytelenítő után már ne lehessen módosítót készíteni: ERV_NEMFOLYT   X        (Ez a beállítás a 2.38 változatban is működik, vagyis ha beállítják, nem kell csak ezért programot frissíteni 2.38-ról 2.39-re)

2023.03.20 2.38-as változat

• A NAV Online számla kommunikáció módosítása úgy, hogy a május 1-vel várhatóan életbe lépő változásokat zökkenőmentesen kezelje. Ahol nem frissítenek a 2.38-as változatra, ott az érvénytelenítő számlák NAV jelentése hibás (piros) lesz. Ha ezt észlelve csak ekkor frissítenek, akkor a NAVONLINETER  X beállítással egy alkalommal újra kérhető a hibás státuszú számlák jelentésének újraküldése, és a helyes küldés ekkor megtörténik.
• Kisebb módosítás az EKÁER kommunikációban
• Új egyedi lista: ~RLBKIME  kimenő számlák átadása RLB-nek.
• EDI adatátadás/fogadás kisebb fejlesztése (el nem készült számlák fogadása TAB-al határolt szövegfájlban)
• REND_SZOVNEM X   rendelés sor egyedi szövege ne jöjjön át számlára, szállítólevélre

2022.02.17 2.37-es változat

• Új mező a cikktörzsben (19 kar.), Egyéb 2 szabadon használható (A 'Számolt besz.ár' mező alatt). Lista képernyőn a mező nevének beállítása: CIKK_BD_SZOV
• Új mező a partnertörzsben (10 kar.) Egyéb 2 szabadon használható. A mező nevének beállítása: PART_BD_SZOV
• BauApp integráció (QR kódos okos szállítólevél) lehetősége

2021.03.19 2.36-os változat

• A NAV online számla jelentésben innentől a program a nullától eltérő (27%,18% és 5%-os) áfa kategóriákat a számla összesítésnél áfa %-onként összevontan jelenti. Azok a felhasználóink, akik a (sárga) Warn figyelmeztetések miatt az előleg 27% áfáját a sima 27% értékesítés áfára változtatták, de jobban tetszett ahogy régen volt, visszaállíthatják az eredetire, már nem fognak NAV (sárga) Warn figyelmeztetést kapni e miatt. Ha a (pl.) 27% előleg áfa kategória különbözik a sima 27% értékesítés áfa kategóriától, akkor az előleget beszámító végszámla áfa összesítése elkülönülve mutatja az ügylet áfa részt, és mínusszal a beszámított előleg áfa részt. Ezen kívül az áfa bevallásba is külön soron meg tud jelenni a kapott előleg. Az xml jelentésbe viszont %-onként egy soron, összevontan megy. (Megjegyezzük, hogy a NAV online számla dokumentációban a NAV által példaként hozott ilyen végszámla is egy soron, összevontan jeleníti meg %-onként, vagyis ott nem látszik külön az ügyletérték (tehát ha gondolják, maradhat egy áfa kategóriában is...).
• A program eddig is támogatta az előleg végszámlán történő beszámítását, de ez csak azon esetekben volt valódi segítség, amikor egy kapott előleget teljes összegben számítottak be egy végszámlába. Mivel egyes cégeknél gyakran előforduló eset, hogy több előleg is lehet, és ezeket akár kisebb részösszegekben számítják be, ezért a számlakészítésnél a tételek ablakban a korábbi forgalomból választási lehetőséget biztosító 'Kor.' gomb megnyomására megjelenő választó ablak kiegészült egy új 'Egy' (nettó egyenleg) oszloppal, amely megjeleníti azt, hogy mely korábban kiállított előlegszámlákon van még be nem számított nettó előleg. Egy ilyen sort előlegbeszámítás esetén végszámlán kiválasztva nem a teljes eredeti előleg ugrik be (mint eddig), hanem csak a még fennmaradó nettó előleg rész. A helyes működés feltétele, hogy a Kor. gombbal a korábbi előleg kiválasztásakor a 'Szöveg' mezőbe bekerülő eredeti számlaszámra hivatkozáshoz ne nyúljanak, ne szerkesszék (legfeljebb a végéhez fűzzenek további megjegyzéseket ha szükséges, de ne az elejére). Emlékeztető: az előlegeket vagy 'előleg' szöveggel kezdődő cikkszámmal vigyék fel, vagy ha nem így, akkor kezdődjön minden előleg cikkszám egységesen valamivel pl. xxxxx, és akkor azt be kell állítani: ELOLEGCIKKSZ    xxxxx        Innen tudja a program, hogy előlegről van szó, és a NAV online számla jelentésbe is ekkor kerül korrektül előlegként átadásra.
• Ha valamely cégnél a PDFCreator használatával nem boldogulnak (pl. Terminal szerver környezetben), alternatívaként használható a szintén ingyenes CutePDF Writer is, utána történő azonnal SMTP email küldésre pedig a Mailsend alkalmazás. Ha ezeket szeretnék használni, kérjük konzultáljanak velünk a részletekről. Az ezekkel kapcsolatos újabb beállítási lehetőségek:
• S0ffffffffff (ahol ffffffffff a felhasználó PROFIT belépési kódja)   M     :ha az SMTP paraméterek be vannak állítva, minden olyan (nyomtatási képen jobb egérgombos) PDF készítésnél is, ahol a címzett, fejléc és levél szöveg megvan, azonnali SMTP küldést kérnek. Ha nincs beállítva, akkor csak PDF számla készítésekor küldi azonnal SMTP-n (ott is csak akkor, ha a címzett mail címe ismert)
  Mailsend esetén további paraméterek megadása lehet szükséges, amelyeket az S5ffffffffff beálításban lehet megadni a port száma után. pl.: 587 -starttls -auth  -v  -cs "iso-8859-1"
• S1KOZPONTI_S  ha nem PROFIT felhasználókként külön-külön (saját küldő email címmel, saját hitelesítéssel), hanem központilag egységes küldő email címmel, hitelesítéssel akarják az SMTP paramétereket megadni, akkor KOZPONTI_S felhasználó névvel megadva a paramétereket nem kell felhasználókként külön-külön paraméterezni, és egységesen működik. (és persze: S2KOZPONTI_S S3KOZPONTI_S ...)
• Ha egy munkaállomáson/gépen  esetleg többféle PDF nyomtató (PDFCreator és CutePDF Writer) is fel van telepítve, akkor a Rendszer paraméterekben a munkaállomás (ha előtte ülünk, ennek NR... kódja kék) NR.. kódjának sorára rálépve !!! NEM a tartalom mezőbe!!! , hanem az alsó megjegyzés mezőben konkrétan meg lehet jelölni, melyik PDF nyomtatót akarják használni. Első karakter: C  CutePDF Writer-t akarják használni. Mivel a CutePDF Writer ingyenes verziója nem képes általunk meghatározott helyen/néven létrehozott PDF fájl után (ha nem SMTP-vel lett azonnal küldve) még az alapértelmezett levelező klienst is a PDF csatolmánnyal elindítani, ezért amennyiben nem SMTP van beállítva (vagy nincs meg minden adat a küldéshez) csak a PDF fájl jön létre. Hogy mégis valahogy segítsük az esetlegesen kért email küldést, a program megjelenítheti a mappát, ahol a PDF létrejött, vagy megjelenítheti magát a PDF-et az alapértelmezett PDF olvasóban. Ha itt második karakteren V van, akkor ezen esetekben a PDF olvasót(Viewert) indítja (Sumatra PDF-nél pl. Fájl/Küldés emailben csatolva-t választva elindul a levelező). Ha a második karakter nem V, akkor a mappa jelenik meg. A frissen létrejött PDF-en jobb egérgomb+küldés levélben: elindul a levelező. A harmadik karakter arra használható, ha ezen esetekben (nem SMTP-vel ment el) direkt nem szeretnénk, hogy a PDF elkészülése után bármi megjelenne/felugrana. Ha a harmadik karakter S akkor számla eredeti PDF-ek készítése után nem ugrik be semmi. Ha N  akkor soha nem ugrik fel semmi a PDF elkészülése után.

2021.02.25 2.35-ös változat

• új egyedi lista: ~NAV_KAP  NAV-től a NAV beolvasás során beolvasott, de még nem iktatott számlák lekérdezése. Lista és excelbe átadás lehetséges.
• Az új programváltozat már képes (működő internet kapcsolat esetén) jelezni a bal felső sarokban sárga színnel, ha elérhető frissebb PROFIT programverzió.
• A partnertörzsben El.sz. (elektronikus számlázás) csak akkor jelölhető (X-el vagy T-vel), ha van a partnernek (vagy a pénzügyesnek a személy törzsben) email címe megadva
• A PROFIT programban eddig kétféle számla készülhetett. Papír alapú, ahol a beállított számú számlapéldány a számla nyomtatásakor/elkészítésekor a beállított PROFIT nyomtatóra elküldésre került. Ha itt üzemzavar lépett fel (nem jött ki/begyűrte az eredetit), akkor nem volt nagy gond, egyszerűen kellett készíteni kívánt példányban számlamásolatot, és eredetiként leigazolni. Ha a vevő példánya a postán elkallódott, akkor pedig a saját példány lefénymásolásával és eredetiként leigazolásával újra lehetett eredetivel megegyező másolatot készíteni a vevő részére.
  Vagy a vevőnél a partnertörzsben X-el jelölhető volt, hogy neki elektronikus(vagy EDI) számla készül, és megfelelő beállításokkal (E_SZLA_UTVON) és egy ú.n. elektronikus számla szolgáltatóval (szamlakozpont.hu, 1stbp.eu) szerződve az elektronikus számla elkészítésének, elektronikus időpecséttel/aláírással ellátásának, továbbításának és archiválásának feladatát a szolgáltató (díjazásért) átvállalta. Ilyenkor papíros számlapéldány nem készült.
• A 2.28 verzióban leírt PDFCreator-os számla(másolat) PDF-be nyomtatás/azonnali email küldés továbbfejlesztésre került az alábbiak szerint (de az ott leírt működés továbbra is elérhető). Új beállítási lehetőség (csak akkor, ha nincs beállítva az eddigi E_SZLA_UTVON elektronikus számlázás):
• SZAMLAPDFnnn , ahol nnn egy K?? kimenő számla napló, amelyben S szigorú számadású számlázás van beállítva. A tartalmában első karakteren egy betűjel legyen, majd utána közvetlenül következhet egy meghajtóésútvonal. A beállításnak megfelelő számla elkészítésekor a program a számlát PDF állományként hozza létre (üres példányszöveggel), erre egy HASH-t (elektronikus aláírást) generál amit el is tárol a számla alsó NAV kommunikációs mezőjében SHA3-512: XXXX... formában, elkészít egy emailt a vevőnek, esetleg készít egy papíros számlapéldányt is és utána megtörténik a NAV online számla adatszolgáltatás, amelynek a képzett HASH is átadásra kerülhet. A beállítás első karaktere az alábbi lehetőségeket jelenti:
• E: csak azon vevőknél készül a fenti módon PDF(+HASH,+email...), akiknél a partnertörzsben az El. számlázás X -re (elektronikus számla) van állítva. (vagy T-re: teszt mód, minden ugyanúgy megy, de nem elektronikusként lesz a NAV jelentésben megjelölve). Az email szövege ekkor Xnnn (vagy Tnnn) bizonylat szöveggel adható meg.
  e: az előző működés, de még egy menetben készít egy papíros példányt is (nekünk)
  C: minden olyan vevőnél készül a fenti módon PDF, akiknek van email címe megadva. Az email szövege a Pnnn (vagy ha nincs megadva, akkor a Knnn) bizonylat szöveggel adható meg.
  c: az előző működés, de még egy menetben készít egy papíros példányt is  
  M: minden számla ezzel a módszerrel készül, akinek nem volt email címe, ott email nem készül, hanem helyette egy papíros példány készül
  m: az előző működés, de még egy menetben készít egy papíros példányt is (ha nem volt email, akkor összesen kettőt)
• A beállítás első betűjét követően megadható meghajtóésútvonal -tól függően különböző módon történhet a létrejött számla PDF tárolása. Ha üresen marad, akkor a PDF_MENT_MAP beállításban beállított útvonalon jön létre a PDF fájl, vagy ha az sem volt beállítva, akkor a kliens gépen a c:\PDF_MENT\ mappába. (a fájlnév végére azért odateszi: eredeti, hogy meg lehessen különböztetni a sima korábbi másolati pdf-ektől) Ha itt kitöltjük, akkor az itt definiált mappában jön létre a PDF fájl, nem keveredik más PDF-ekkel.
• Amennyiben a KEPERNYO_KEP beállítással be van állítva a PROFIT-ban az általános dokumentum tárolás, és a SZAMLAPDFnnn beállításban a második karaktertől kezdődően megadott útvonal a KEPERNYO_KEP második karakterétől kezdődően beállított dokumentum útvonalra vagy almappájára mutat, akkor a program a létrejött PDF fájlt a számla dokumentumaként állítja be, vagyis a számlához tárolja a hozzá tartozó számla eredeti PDF fájl elérési linkjét (meghatóésútvonalésfájlnevet). A felső eszköztár fényképezőgép ikonjával ekkor a számlakép fájl azonos másolata gombnyomásra megjeleníthető (ha a tárolt linken a fájl még mindig valóban ott van), nem kell intézőben, mappákban fájlnév, számlaszám alapján keresgélni. Fontos, hogy az így beállított meghajtóésútvonal MINDEN munkaállomáson azonos, elérhető mappaként legyen beállítva. Ha a két beállításban megadott útvonal különbözik (vagy a az általános dokumentum tárolás a KEPERNYO_KEP -el nincs is beállítva), akkor csak maga a PDF fájl tárolódik.
• Ha mindkét beállításban üres az útvonalnév (KEPERNYO_KEP  D     és pl. SZAMLAPDFKB   E      ), akkor a fájl - bár létrejön az előbb említett mappák valamelyikében - de nem a linkje, elérése tárolódik dokumentumként, hanem maga a fájl tárolódik el az SQL adatbázisban. Ekkor nem fontos, hogy legyen közös számla pdf és/vagy dokumentum mappa, mert az SQL szerveren tárolódik a dokumentum magában az adatbázisban. A felső eszköztár fényképezőgép ikonjával ekkor a számlakép fájl azonos másolata gombnyomásra megjeleníthető az adatbázisból (még akkor is, ha a készítéskor létrejött PDF fájlt valaki letörli).
• Figyelem!!! Az első módszer előnye, hogy nem terheli az adatbázist, de minden munkaállomásnak el kell tudni érnie a közös mappát, és a fájl sincs akkora biztonságban, valaki letörölheti, a második módszer előnye, hogy nem kell közös mappa, de hátránya, hogy az SQL adatbázisban tárolt dokumentumok nagyon hamar erősen megnövelhetik az adatbázis méretét, és minden adatbázis mentés egyben minden eltárolt dokumentum mentését is jelenti, vagyis az is lassulhat (a licensz szerinti adatállomány-méretet a tárolt dokumentumok nem növelik!). Egy egyszerű számla PDF kb. 36kB, lehet számolni... Ha megoldható a közös mappa, és annak a rendszeres, gyakori mentése, akkor inkább az előbbi módszert javasoljuk, kérdés esetén mindenképpen előzze meg ennek beállítását/átállítását velünk való konzultáció. További beállítási lehetőségek:
• SZAMLAPFNnnn   aa     ahol nnn a K?? kimenő számlázás napló, aa pedig azon fizetési típusok felsorolása, amelyeknél a PDF készítést (+hash,+email stb.) a fentiek szerint NEM kérjük.
• SZAMLAPMNnnn   (ahol nnn a K?? kimenő számlázás napló) tartalma lehet X  : email küldést egyáltalán nem kérnek (majd valahogy máshogy később küldik), 1 : email küldést nem kérnek, de kérnek helyette egy plusz papíros példányt
• SZAMLAPDFAPP  U     a NAV jelentésben az ilyen számlák megjelenésére nem PAPER hanem UNKNOWN megjelenést jelent, vagyis hogy a számla nyomtatásának pillanatában még nem lehet tudni, hogy végül most akkor papír alapú lesz a számla, vagy elektronikus. (Amelyik számla X elektronikus, ott mindenképpen elektronikusként jelenti az adatszolgáltatásban)
• SZAMLAPDFHEL  X  HASH kódot csak X elektronikus számlák esetén küldi a NAV jelentésbe. Akkor is, ha egyébként a számlához elkészül a PDF, annak HASH kódja, és az nálunk el is tárolódik, de esetleg nem szeretnék, ha ez az adat a NAV-nak továbbmenne. Így persze attól is elesik a számla befogadója és kibocsátója, hogy NAV-tól lekért HASH-el hitelesíthesse a nála levő PDF eredetiségét.
• Megjegyzések a használatba vételhez:
  Egész más megbízhatóságot, hibamentességet várunk egy PDF nyomtatástól akkor, ha az csak néha, utólag történik (mint eddig), mint akkor, ha ez beépül a legfontosabb számla kiállítási folyamatba. Akkor annak nagyon megbízhatóan kell működnie, ráadásul minden számlázó munkaállomáson. Sajnos a használt PDFCreator hosszú távú és széles körű megbízhatóságáról az éles üzemeltetése közben nem sokat tudunk, és voltak felhasználóink, akiknél időnként hibaüzeneteket is adott. A PDFCreator nem a mi termékünk, így ha kiderül, hogy nem használható egyes cégeknél az ottani gépeken megbízhatóan, úgy csak azt tudjuk ígérni, hogy akkor keresünk majd a jövőben más programokat erre a célra. A bevezetés, használatba vétel során kérjük, legyenek óvatosak, és vegyék ezt figyelembe. Ha a PDF fájl elkészítésének folyamatába hiba csúszik, nem jön létre a PDF fájl, úgy véleményünk szerint a számlát papír alapúnak kell tekinteni és ha egyetlen papíros példány sem készült, pontosan úgy kell eljárni, mint ha a sima papíros számláknál a nyomtató a számla eredetit begyűrte volna.
  A másik elég bizonytalan dolog a jogszabályi környezet, nem véletlenül adunk sok (és így bonyolult) beállítási lehetőséget, mert nem tudjuk, a jelen és az esetleges jövőbeni törvényi, ill. NAV jogértelmezési változások hogyan befolyásolják a témát. Annak eldöntése, hogy a fenti lehetőségek közül mit, hogyan és mikor vezetnek be, az Önök mindenkori adójogi hozzáállásától függ. Ha elhatározzák, hogy valamelyik konstrukciót alkalmazni kívánják, akkor - ha már tudják, hogy mit szeretnének - természetesen segítünk annak beállításában, illetve szaktanácsadásban.
• Bár az elektronikus számlákra vonatkozó hiteles aláírás/időpecsét témát az új NAV HASH beküldési lehetőség kiválthatja (a NAV online számla dokumentációja szerint), ha nem szerződnek elektronikus számla szolgáltatóval, feladatként akkor is megmarad és Önökre hárul az elektronikus számlákra vonatkozó archiválási kötelezettség. Ez papír alapú számla esetén mindkét félnek jóval egyszerűbb, viszont ebben a témában jól jönne egy - a jelen helyzethez igazodó - megengedőbb NAV álláspont a papír alapú számla vevőhöz való eljuttatása témájában. (Addig esetleg ügyesen megfogalmazott email kísérőszöveg vagy vevővel történő valamilyen külön megállapodás segíthet).
• Azok a számlák, amelyekhez az elkészítés során sikeresen (valahová) létrejött egy PDF fájl (és amelyekhez így a generált HASH - legalább nálunk - eltárolódott), a számlák áttekintő lista nézetében az El. oszlopban zöld háttérrel jelennek meg.
• A számláknál a NAV gomb megnyomásával lekérhető - a NAV-hoz beküldött adatokból összeállított - számlaképen fent látszik a HASH. (Kapott számláknál is, ha megadták)
• Egy PDF fájl HASH-je (mi az SHA3-512 HASH-t használjuk) bármikor ellenőrizhető pl. webes online módon: https://emn178.github.io/online-tools/sha3_512_checksum.html          (más programok esetleg még használhatják az SHA-256 -t is!)
• Haladó SMTP beállítások (ha SMTP szükséges, konzultáció itt is javasolt!):
• S1ffffffffff  (ahol ffffffffff a felhasználó PROFIT belépési kódja): SMTP küldés válasz email címe. Ha ez itt üres, a hagyományos, el nem küldött emailt készíti az alapértelmezett levelező programban, amit még el kell küldeni
• S2ffffffffff SMTP email fiók
• S3ffffffffff SMTP server ip vagy cím
• S4ffffffffff SMTP jelszó
• S5ffffffffff SMTP port száma
• S6ffffffffff SMTP SSL hitelesítés kell-e pl.: True

2021.02.08 2.34-es változat

• A program már a 2021-es 2165 áfa bevallás idei újdonságai szerint működik, az AFALEK05 5-ös áfa lista (M lapok) egyes mezői megváltoztak.
• Idéntől az M lapok kitöltése megváltozik, bonyolódik akkor, ha előleg beszámító (mínuszos) számlasort tartalmazó ú.n. végszámla kerül idei bevallási időszakba, amelynek kapcsán áfalevonási jogot gyakorlunk (A számlának van visszaigényelhető áfája. Ha a 100% előleg beszámítása miatt a végszámla nulla végösszegű (és áfájú), akkor nem kerül az M lapra.)
• Az ilyen számlákat két sorban kell az M lapokra felvinni úgy, hogy első sorban az előleg nélküli 'ügyletérték' adatai, a második sorban pedig a végszámla adatai kerülnek. Az ilyen számlákat a beérkezett számla rögzítő ablak jobb felső részén levő J. (jel) mezőben V -vel kell jelölni. (Ebbe a mezőbe kerül érvénytelenítő/sztorno számlánál E, módosítónál M) Ennek hatására a program az M lapra már két sorban teszi az ilyen számlát. A végszámlán levont előleg nettó és áfa értékét a számlarögzítő ablak jobb alsó sarkában levő 'Megj.' mezőbe lehet írni pontosvesszők közé       ;nettó_előleg_HUF_egész_számként_előjel_nélkül;előleg_áfa_HUF_egész_számként_előjel_nélkül;     A 'Megj.' mezőbe tehát a végszámlán levont teljes előleget valahogy így kell a mezőbe beírni  Pl.:    ;100000;27000;       A mezőbe az előleg adat elé vagy utána is lehet bármi mást is írni, csak akkor ne legyen előtte másik ; (pontosvessző karakter) 
• Ha a fenti adat beírása elmarad, akkor is két sorban megy át az M lapra a V-vel jelölt végszámla, az ügyletérték nettó, áfa adatot ekkor a bevallásban az xml importálás után a beküldés előtt kézzel lehet javítani
• Az M lapra az xml importálás során (és a nyomtatásban is) a program a rögzítéstől és a dátumoktól függetlenül a V-vel jelölt végszámlákat sorolja előre, a többi számla csak ezek után kerül rá.

2021.01.14 2.33-as változat

• A program már a 2021.01.04-től használható 3.0-s új NAV interfész verzió alapján végzi a kimenő számlázás jelentését, így küldi a nem ÁFA alany magánszemélyeknek és belföldi adószámmal nem rendelkező egyéb vevőknek kiállított számlák adatait is (előbbiekét név és cím adatok nélkül).
• Eddig a partnertörzsben alul a Ct. (cégtípus) mezőben M -el lehetett jelölni, ha egy vevőnek nem volt belföldi adószáma, innentől ezt tovább kell pontosítani (A NAV megfogalmazásában):
• Az M jelentése innentől: Nem ÁFA alany (belföldi vagy külföldi) természetes személy. A mi értelmezésünkkel: magánszemély, akinek nincs semmilyen adószáma, legalábbis a vásárláskor úgy nyilatkozik, hogy nincs/nem adja meg/nem arra kéri. NAV XML jelentésben küldött adat: PRIVATE_PERSON
• Az E jelentése innentől: Egyéb (belföldi nem ÁFA alany nem természetes személy, külföldi ÁFA alany és külföldi nem ÁFA alany nem természetes személy. A mi értelmezésünkkel: minden olyan vevő, akinek nincs belföldi adószáma és nem az előző kategória. NAV jelentésben küldött adat: OTHER
• A harmadik, leggyakoribb eset, hogy a vevő belföldi áfa alany.  NAV jelentésben küldött adat: DOMESTIC
• Fontos! a 2.33 verzióra való frissítéskor a program megpróbálja a partnertörzsben az eddig közösen M-el jelölteket valahogy szétválasztani. Ahol lát EU adószámot, vagy látja az országkód alapján, hogy külföldi, ott átírja E-re, de ezt nem biztos, hogy jól teszi, így ezt a számlázás előtt át kell nézni, és egyenként pontosítani kell.
• Új számla készítésekor a számlafej mentésekor a program tájékoztat, ha a partner M vagy E, és ha látjuk, hogy nem jó, még javítható.
• Egyéb esetben a számlafej mentésekor a program lekéri a NAV-tól a vevő adószáma alapján az adatait, és tájékoztató ablakban megmutatja. Már a rövidített nevet is mutatja! Ha ez sebességi okból (NAV rendszer lassú, akadozik stb.) nem kívánatos, akkor rendszer paraméterrel beállítható, hogy soha ne kérje le: ADOSZAMKINEM  X    A vevő neve feletti 'Vevő' feliraton jobb egérgombbal - ahogy eddig is - ez a tájékoztató adat (elkészült számlán is) bármikor lekérhető. Vagy: ADOSZAMKINEM   ?  Ekkor megkérdezi, hogy lekérje-e: Ok vagy Mégse.
• A NAV az új 3.0 verzióban a számla jelentésekor az eddigieknél pontosabban kéri az áfát nem tartalmazó értékesítések kategorizálását. Az ÁFA kategóriák törzsben megjelent egy új mező: NAV kategória. Az eddigi EU_ADOMENTES és AFA_HATALY_K beállítások érvényüket vesztik és minden egyes - számlázáskor használni kívánt - áfa mentes értékesítési áfa kategóriát a NAV által megadott kategóriák egyikébe be kell sorolniuk. (A FORD_AFA_ERT beállítás maradjon meg, de ettől még ezeket is be kell kategorizálni: FAD). Az űrlapon a jobb oldali 'NAV ketagória' mezőn kettős kattintásra a kategóriákat és azok NAV leírását tartalmazó súgó/help ablak jeleníthető meg, és onnan a kategóriát kijelölve kimásol/beilleszt módszerrel is be lehet írni. Figyelem!!! Ez a kiválasztás csak egyszer lehetséges, ha el is mentik, tehát kérjük, a választást jól gondolják meg. Elrontás esetén új áfa kategória hozható létre jó adatokkal.
• A kategóriák a NAV leírásával (Kérjük, áfa adójogi értelmezési kérdésekkel ne hozzánk forduljanak, hanem a NAV ügyfélszolgálatán kérjenek segítséget, támogatást.):
• FAD     142.§           Belföldi fordított adózás jelölése
• AAM     XIII. fejezet  A számla kibocsátója alanyi mentességet választott és a mentesség használatára jogosult(nem érte el a jogszabályi értékhatárt)
• TAM      85. §, 86. §  Az értékesítés a tevékenység közérdekű jellegére vagy egyéb sajátos jellegére tekintettel mentes az adó alól. (Például — adómentes oktatás, egészségügyi szolgáltatás).
• KBAET   89. §           A Közösség másik tagállamában regisztrált adóalany számára történt termékértékesítés,amennyiben a termék az adott tagállamba került elszállításra. Az új közlekedési eszköz értékesítése a KBAUK esethez tartozik. A vevő közösségi adószámát a számlán kötelező feltüntetni.
• EAM     98-109. §      Belföldön teljesített termékértékesítés, aminek a következményeként a terméket kiléptetik harmadik országba (termékexport). A jogszabály alapján olyan speciális esetek is idetartoznak, mint például a nemzetközi szerződés alapján érvényesülő adómentesség.
• NAM     110-118. §    A jogszabály felsorolja az ide tartozó eseteket. Ilyen lehet például az adómentes közvetítői tevékenység, termék nemzetközi forgalmához kapcsolódó egyes tevékenységek adómentessége.
• ATK     2-3. §            Kizárólag tárgyi hatályon kívüli ügyletről nem kell számlát kiállítani, de egy számla tartalmazhat tárgyi hatályon kívüli tételt is. Ide tartozik például a kártérítés, a közhatalmi tevékenység, ,a közcélú adomány stb.
• EUFAD37 37. § (1)     Adóalany számára nyújtott szolgáltatás, aminek a teljesítési helyét a vevő gazdasági célú letelepedése - (vagy lakóhelye, szokásos tartózkodási helye) határozza meg az Áfa tv. 37. §(1) bekezdése alapján és az másik tagállamban található. A számlán kötelező szerepeltetni a vevő közösségi adószámát. Ezen szolgáltatásokat az összesítő nyilatkozaton is szerepeltetni kell.
• EUFADE                    Másik tagállamban teljesített fordítottan adózó ügylet, amelynek teljesítési helyének megállapítása nem az EUFAD37 esete alapján történik. Ehhez az esethez tartozó ügyleteknél a magyar adózónak nincs bejelentkezési kötelezettsége a teljesítés helye szerinti tagállamban. Ilyen eset például a fel- vagy összeszerelés tárgyául szolgáló termék másik tagállami értékesítése.
• EUE                          Az EU másik tagállamában teljesített olyan ügylet, ami után nem a másik tagállami terméket beszerzőt, szolgáltatás igénybevevőt terheli az adófizetési kötelezettség (nem tartozik az EUFAD37 és EUFADE esetei közé).
• HO                     Olyan ügylet, aminek az Áfa tv. szerinti teljesítési helye EU-n kívül van. Például harmadik országban teljesített szolgáltatás, harmadik országban fekvő ingatlanhoz kapcsolódó szolgáltatás.
• TRAVEL   169§          "Különbözet szerinti szabályozás - utazási irodák" szöveg feltüntetése kötelező a számlán!
  SECOND   169§          "Különbözet szerinti szabályozás - használt cikkek" szöveg feltüntetése kötelező a számlán!
  ARTWORK  169§          "Különbözet szerinti szabályozás - műalkotások" szöveg feltüntetése kötelező a számlán!
  ANTIQUES 169§          "Különbözet szerinti szabályozás - gyűjteménydarabok és régiségek" szöveg feltüntetése kötelező a számlán!
• Az AFALEK_05 áfa lista és xml készítő módosult úgy, hogy nem név, hanem adószám sorrendben készül, és adószámra összevontan készíti az xml-t (csoportos áfa alanyoknál, vagy valamiért többször felvitt szállítónál)
• A rendszer alap számla riportok módosultak, és a vevő alatt M(agánszemély) és E(gyéb) esetben ezt a tényt kiírják pl.: Nem belföldi ÁFA alany (M). A számla alján levő áfa összesítő táblázatokban kiíródik a NAV kategória is.
• Mivel 2020.jan.4-től a kötelező számla adatszolgáltatásban a törvény devizás számlák esetén minden esetben, így akkor is előírja az árfolyam adat megadását, ha a számla áfát nem tartalmaz, így a NULLAAFAJAVI X beállítás az új verziónkban már nem teszi lehetővé az árfolyam utólagos módosítását a számlán még akkor sem ha a számlán az áfa nulla. Oda kell tehát figyelni, hogy a számla árfolyamát még az elkészítése előtt a törvényi előírásoknak megfelelően megadják.
• A NAV beolvasás (és a rögzítéskor használható választó ablak) I_CI oszlopban tájékoztatásként megjeleníti ha a kapott számla maga az elektronikus számla (completenessIndicator=true). Ekkor az oszlopban C látható (egyelőre valószínűleg kevesen élnek ezzel)
• A 'NAV' gombbal lekérhető számlamegjelenítő kiírja a számlának a jelentésben megadott megjelenési formáját (PAPER, ELECTRONIC, OTHER) és 3.0-val küldött számla esetén az új NAV kategóriákat, és a Vevő neve mellett a (DOM),(PRI) vagy (OTH) rövidített jelzést valamint azt, ha a kapott számla maga az elektronikus számla: NAV_EL_SZLA.

2020.11.17 2.32-es változat

• a NAV-tól köztes állományba lekért (nem a PROFIT programmal kiállított) kimenő számlák kimenő utórögzítéses naplóba való fogadása kiegészült azzal a lehetőséggel, hogy lehet fizetési típusra szűrni. Ez csak akkor működik, ha a számlázó program korrektül kezeli a nem kötelező fizetési típus xml adatot: TRANSFER, CASH, CARD (átutalásos, készpénzes, kártyás). A kimenő naplóban új felvitelt kell kérni, és az Er.biz.szám mezőben megadni: aaa##nfffffff ahol aaa: megadható leválogató kifejezés (lehet üres),##, n: megadható tömbazonosító, ha a számlaszámot át kell alakítani rövidebbé, hogy 10 karakteren elférjen (lehet üres) és fffffff megadható fizetési típus pl.: TRANSFER  (ha ezt nem adjuk meg: mindegyik)
• a 2.31 verzióban és a fentiekben leírt kötegelt kimenő számla fogadás lehetősége megjelent a pénztárban is, mert volt olyan felhasználónk, aki a készpénzes számlákat nem a kimenő naplóba akarta fogadni (311-re köönyvelve, és a pénztárban csak a kifizetését tenni még úgy sem, hogy azt is lehet automatikusan), hanem közvetlenül a pénztárban 3811-el szemben áfára, árbevételre könyvelve (311-et kihagyva) bevét bizonylaton áfásan. Használata: A megfelelő pénztár naplóban új felvitelt kell kérni, a dátumot ki kell tölteni/ellenőrizni, a bizonylatot 'B' bevétre át kell állítani, majd a Számlaszám mezőben megadni: aaa## fffffff ahol aaa: megadható leválogató kifejezés (lehet üres),##, (itt tömbazonosítónak nincs értelme, a kimenő számla száma a Számlaszám mezőbe kerül, így a ##-t egy szóköz követi) és a szóköz után fffffff megadható a fizetési típus pl.: CASH   Megerősítő áttekintés és kérdés után az egyes (a bizonylaton megadott dátummal kijelölt számla keltű) készpénzes kimenő számlák beolvasásra kerülnek egy összetett bevét bizonylatra.

2020.05.22 2.31-es változat

• kisebb hibajavítások miatt javasoljuk, hogy frissítsenek erre a verzióra július előtt, de ha számláznak a programmal, és 2.28-nál régebbi verzió fut, akkor a frissítés mindenképpen kötelező. A program csak júliustól jelent minden belföldi adóalany részére kibocsátott számlát.
• a 'NAV beolvasás' feldolgozó varázsló kiegészült további lehetőségekkel:  A lekért számlákat a feldolgozás előtt nem csak törlésre lehet megjelölni T-vel, hanem N-el törlés nélkül is meg lehet jelölni, hogy nem szeretnénk látni a kiválasztáskor.
• az első képernyő első új mezőjében alapértelmezetten 'B' van, vagyis a program (az előző verzió leírásában részletezett módon) a részünkre kibocsátott (bejövő) számlákat kéri le. Ha ide K-t írunk, akkor a program az általunk kibocsátott számlákat is be tudja olvasni. Ennek akkor lehet értelme, ha a számlázás nem (kizárólag) a PROFIT programmal történik, hanem más számlázó programot (is) használ a cég, és igény van ezek adatainak beolvasására is (pl. a könyvelőirodák jellemzően élhetnek majd ezzel). A beolvasás ekkor is csak a köztes állományba történik, és a feldolgozás során még csak a partner adatok bővülnek/szinkronizálódnak (viszont azok csak ekkor). 
• ha a a feldolgozást nem a G (gyors) módon kérjük, hanem az X-el jelölteknél lekérjük egyenként a számla xml-eket, akkor van lehetőség arra is, hogy ezeket az xml-eket a köztes állományba el is tároljuk. Így amikor később esetleg erre újra szükség van, akkor már nem kell ezt ismételten lekérni a NAV-tól. Másrészről egy-egy számla xml mérete nagy lehet, így  - amíg nem kerül törlésre a köztes állományból - növeli az adatbázist (tehát NEM a számlánál tárolódik, hanem a köztes állományban!). A beállítás: NAVXML_TAROL   Tartalma lehet üres: nem tárolódik, B  csak bejövőknél, K  csak kimenőknél, BK   mindkettőnél. A tárolás csak a feldolgozás során történik meg. Azt, hogy éppen hogyan van beállítva a rendszer, és lesz-e eltárolás, a program megjeleníti a feldolgozó varázsló második képernyőlapján hogy az indítás előtt lehessen látni, mi fog történni.
• Új gomb a beérkezett, kimenő számla és pénztár űrlap felső eszköztárán: [NAV] A már berögzített/iktatott (mentett) számlán állva lekérhető a számláról a NAV-nál található xml (amennyiben a számla NAV online jelentése már megtörtént) és ennek alapján egy külön - csak olvasható - ablakban ez alapján a program megjelenít egy virtuális jól áttekinthető számlaképet, amely tartalmazza a számla lényeges fej, sor és összesítő adatait. Ezáltal a számláról a könyveléshez sok információhoz jutunk anélkül, hogy a számlát kézbe kellene venni. FIGYELEM! Könnyen előfordulhat, hogy a különböző más programok által jelentett (vagy kézi számla esetén a NAV online felületen kézzel bevitt, megadott) adat nem felel meg a valódi számla megfelelő adatának!!! Jelenleg kevés tapasztalatunk van arról, hogy ez majd mennyire lesz megbízhatóan használható. Ha az előzőekben említett módon a NAVXML_TAROL beállításával a számla xml a köztes állományba eltárolásra került, akkor a NAV gomb nem kéri le az xml-t újból, hanem csak gyorsan megjeleníti azt. A számlakép ablakot a jobb felső sarokban x-el lehet becsukni, ha már nincs rá szükség.
• ha a NAV gombot megnyomjuk, és a számlán az áfa rögzítése még nem történt meg, a program kérésre berögzíti a jelentésben levő áfát. Kimenő számlánál ez általában hasznos, bejövő számla esetében csak akkor kérjük, ha az áfa visszaigényelhető, és akkor is szükség lehet korrekcióra. A program kerekíti az áfa értékeket. Fordított áfás bejövő számla esetén a FORD_AFA_KOD beállítás első két karaktere által meghatározott áfa kódot kínálja be. A többi áfa rögzítésének működéséhez szükséges egyszer beállítani az adott beszerzés áfa két karakteres kódját 27%: ALT_BESZ_AFA  xx   18%: ALT_BE18_AFA xx  5%: ALT_BE05_AFA xx   A kimenő számlák áfájának megfelelő automatikus rögzítéséhez pedig a következő beállításokat kell megadni: 27%:   ALT_ERTE_AFA xx   18: ALT_ER18_AFA xx  5%: ALT_ER05_AFA xx  FOA: ALT_ERFO_AFA xx  ha a többi nem áfást mindig ugyanoda akarjuk hogy tegye, akkor felvihető: ALT_ERTO_AFA xx 
• a részünkre kibocsátott számlák rögzítését továbbra is az előző verzióban leírt módon segíti a program, vagyis a megfelelő naplóban egyenkénti rögzítéssel, új felvitel közben a bizonylatszám mezőben kereső kifejezés+F9 után választással a köztes állományból a rendelkezésre álló adatokat a program bekínálja. Csak abban az esetben kínálja be az áfa bontást, ha a számla kizárólag 27% áfás és számára jól vannak megadva az adatok. 
• a (nem a PROFIT programban kiállított) kimenő számlák berögzítésére annak eltérő jellege miatt más - csoportos - megoldás készült. Egy kimenő utórögzítéses naplóba belépve új kimenő számla felvitelét kell kezdeni, majd az eredeti bizonylatszám mezőbe be kell írni: aaa##n      ahol  aaa: egy tetszőleges karakter hosszban megadható valami olyan karakterrész, ami az összes - a köztes állományban levő, abból még be nem rögzített - beolvasandó kimenő számlák közül az általunk kiválasztandókban pl. a számlaszámában előfordul. Ha pl. többféle program kimenő számlái kerültek be a köztes állományba: NO-00001, NO-00002, NO-00003  és FU2019/08544, FU2020/00015, FU2020/00016, FU2020/00017 akkor ha az előbbieket kérjük megjeleníteni, akkor a ## előtt legyen pl. NO-  ha az utóbbiakat, akkor a ## előtt legyen pl. FU vagy ha csak az ideieket, akkor a ## előtt legyen pl. FU2020/   vagyis pl. FU2020/##  -ot beviszünk az eredeti bizonylatszám mezőbe és enter után megjelenik egy táblázat, amiben látjuk a lekért számlákat, és mindegyik ' K' -val jelölt az első mezőben. Amelyek számlákat NEM akarjuk most majd bevinni a naplóba (mert nem ebbe a naplóba való, vagy teljesítés dátuma alapján látjuk, hogy más évbe tartozik stb.), azoknál szóköz billentyűvel vegyük ki a ' K'-t, mert a feldolgozás/berögzítés csak azokra a számlákra történik majd meg, amelyek ' K'-val jelöltek. Bezárva egy kérdésre a csoportos berögzítés elindul. Ennek során partner adat bővítés/szinkronizálás NEM történik, a pogram csak megpróbálja adószám alapján megtalálni a megfelelő vevő partnert és ha sikerül, akkor kitölti a rendelkezésre álló mezőket. Ha nem kapott pl. lejárati dátum adatot, akkor oda a számla kelte kerül. Ez a feldolgozás ki tudja használni, ha előzetesen le vannak tárolva a számla xml-ek. Ha nincsenek, akkor csak abban az esetben teszi be az áfa bontást, ha a számla kizárólag 27% áfás és számára jól vannak megadva az adatok. Ha viszont a számla xml-je a 'NAV beolvasás' előzetes beolvasás során tárolva lett, és az ALT_ER??_AFA beállítások megtörténtek, akkor az áfát részletesen rögzíti.
• Előfordulhat, hogy a más programmal kiállított kimenő számla száma hosszabb 10 karakternél (ennyi most a saját szám hossza). Ekkor lehet A automatikus saját iktatószám sorszámozást is beállítani (a számla eredeti számlaszáma pedig megy az eredeti bizonylatszám mezőbe) vagy ha a szám képzés módja üres (kézzel megadott saját szám), akkor gondoskodni kéne arról, hogy a 10 karakternél hosszabb számlaszám valahogy 10 karakterre rövidüljön. Ezt segítheti a ## után megadható egy karakteres n  tömb azonosító (pl. 1), amihez felvihető egy NAVKIBEOLVSn rendszer paraméter (pl. NAVKIBEOLVS1), aminek tartalmában megadható, hogy a kapott számlaszám mely pozíciójú karaktereit nyelje le a program a saját szám képzéséhez. Ezen pozíciókhoz kerüljön X, pl.:  XXX XX          ezzel a beállítással a 3.,4.,5. 7. és 8. karaktert nyeli le. E témában ha nem a kívánt eredmény jön, konzultációt javaslunk.
• 2020.júliustól a 2065 bevallásban azon számlák esetében, amelyekre vonatkozóan az adott időszakban áfa visszaigénylési jogunkkal élünk az M lapokon ezen számlákat értékhatártól függetlenül jelenteni kell, és az M lapokon akkor is a számla eredeti áfa tartalmát kell jelenteni, ha esetleg a számla áfáját csak részben igényeljük vissza. A részben visszaigényelt áfájú beérkezett számlák kezelésére azt javasoljuk, hogy az áfamentes 'vissza ne igényelhető áfa' használata helyett vigyenek fel egy új áfa kategóriát (pl. 17 27 Vissza.n.ig.27% áfa) a lényeg, hogy a százalék legyen 27, de a bevallás sora (plusz sora is) valamint az áfa főkönyv is maradjon üresen. A vissza nem igényelt áfa részt az áfa bontásba ennek használatával rögzítsék. (és hasonlóan, új kóddal lehet kezelni a 18% és 5% -os vissza nem igényelt áfát is). Ennek megfelelően módosult az 01-es áfa lista, amely megfelelő bevallást készít az így használt vissza nem igényelt áfa esetén is, és az összegfokozatoknál jelzi a bevallásba kerülő, a bevallásba nem kerülő (N) és az összes, a bevallásban szereplő áfát.

2020.05.22 2.30-as változat

• Új menüpont/feldolgozó program a Pénzügyben: NAV beolvasás. Használatának feltétele, hogy a NAV Online számla paraméterek be legyenek állítva. Ha a cégben már a számlázás használata miatt ez korábban be lett állítva, további teendő nincs. Itt lehetőség van a más cégek által részünkre kibocsátott számlák előzetes beolvasására úgy, hogy ezek az adatok nem a naplóba, könyvelésbe kerülnek, hanem csak egy köztes állományba, ahol segíthetik a beérkezett számla és pénztár rögzítést. A többi feldolgozó programtól eltérően a lekérés/feldolgozás itt két részben történik meg. Az első képernyőn megadhatjuk lekérendő időszakot (ezt fel is kínálja) Itt max.35 napnyi intervallum adható meg, valamint lehetőség van már aktualitását vesztett (mert időközben be lett rögzítve így azt nem kell segíteni) időszak törlésére is. A 'Következő' gombra kattintve először megtörténik a törlés (ha kérték), majd a beolvasás/tárolás a következő adatokkal: számlaszám, adó törzsszám(1-8), szállító név, kelt, teljesítés, lejárat, fizetés módja, számla nettó, áfa, nettó HUF, áfa HUF. Ha a partnertörzsben a szállítók adatait kézzel tervezik bővíteni, egyeztetni, ellenőrizni, akkor ez akár elég is lehet, ekkor egy esetleges áttekintés után akár a 'Mégse' gombbal is bezárhatják a feldolgozó programot. (A pénztár rögzítésekor van arra is lehetőség, hogy a partnertörzsbe való felvitel nélkül, a bizonylaton megadva/kiválasztva rögzüljön az adó törzsszám, név és ekkor az M lapokra így is rákerülhet.) Ha viszont jó lenne, ha az új szállítókat a program magától felvinné a partnertörzsbe, oda beírná a címet is, az adószámot kiegészítené a végével, valamint a számlán szereplő bankszámlaszámot is felvinné (ha új), akkor célszerű tovább folytatni. A további adatok lekéréséhez a programnak majd egyenkénti kommunikációval le kell kérnie a NAV-tól a számla xml-eket. Mielőtt ez elindulna, második lépésként lehetőségünk van meghatározni a részletesen lekérendő számlák körét. Az első lap egy mezőjében megadható, hogy az újonnan beolvasott számlák közül melyeknél kérjük, hogy előzetesen jelölje be partner bővítésre/feldolgozásra: (N) nem kérjük egyiknél sem, (A) csak az átutalásosoknál vagy (M) mindegyiknél. Az alatta levő mezőben pedig megadható a feldolgozás módja. Lehet kérni (G) gyors bővítést, ilyenkor nem kéri le a számla xml-ek részletes adatait, viszont ekkor csak az adó törzsszám és a név áll rendelkezésre, így új partnert csak ennyi adattal visz fel, vagy (I) igen, kérjük a részletes adatlekérést, és a bankszámlaszámokat is bővítse, vagy (N) részletes lekérés, de bank nem kell. A 'Következő' gombbal indított nyers lekérés/tárolás után tehát megjelenik egy táblázat, amelyben látjuk a korábban és most újonnan beolvasott számlákat, ahogy kértük további feldolgozásra bejelölve X-el (részletes számlánkénti xml lekérés) vagy G-vel (gyors bővítés lekérés nélkül)) és itt - ha akarjuk - akár egyenként lehet a bejelölésen változtatni, és - ha nagyon szükséges - akár egyenként is lehet T törlést kérni (ha egy számlát nem fogunk a könyvelésbe beállítani és nem is szeretnénk, ha a választó ablakban bárki lássa). Ezzel végezve harmadik lépésként a második képernyőlapon az 'Indít' gombbal lehet indítani a feldolgozást és az ennek során megtörténő partnertörzs (+banktörzs) bővítést/szinkronizálást. Részletes lekéréskor cím eltérés esetén egyenként van lehetőség választani, hogy a kapott cím felülírja-e az eddigi tárolt címet. A feldolgozás végén van lehetőség változási/hibalistát nyomtatni. Már most el lehet kezdeni a használatát, de igazán júliustól lesz hasznos, amikor a 100eFt-os áfa értékhatár megszűnik. 
• Változás/új lehetőség a pénztár rögzítő űrlapon. A bizonylatszám mezőn eddig is volt lehetőség már rögzített számla ki/befizetését választani (név kezdet és F9), mostantól lehetőség van egy szóköz után beírt szövegrészlet és F9 -el a NAV-tól (az előzőekben leírt módon előzetesen) lekért számlát kiválasztani. A kereső szövegrészlet lehet a kapott számla kibocsátója nevének, adó törzsszámának vagy a számla számának kezdete vagy egy részlete. Elég lehet 4,5 karakternyit megadni, pl.' euros'   és F9. A választásnál nem jelennek meg azok a számlák, amelyek adó törzsszáma és számlaszáma egyezik egy már a PROFIT-ban rögzített beérkezett vagy pénztári számla adó törzsszámával és számlaszámával (vagyis amiket már berögzítettünk, azokkal csökken a választólista, ehhez számlaszámnál pontos egyezés szükséges). A kiválasztás után a program a köztes állományból kitölti a bizonylat egyes mezőit, a számlaszámot, a számlaértéket, és kitölti a partnert, ha megtalálja a partnertörzsben. Ha nem találja meg ilyen adó törzsszámmal a partnertörzsben, akkor a megjegyzés mező második sorába beteszi az adó törzsszámot és nevet: #99999999 Partnerneve# (az első sorban maradhat a befizető átvevő neve, ha egyátalán kitöltött). Az ilyen módon megadott partner adat is átkerül az M lapokra. A BP_TELJ_IDOK rendszer paraméterben a tartalomba P-t írva beállítható, hogy látható és kezelhető legyen a teljesítési idő (ha esetleg ez fontos és eltérne a könyvelési/pénztár dátumtól)
• Változás/új lehetőség a beérkezett számla rögzítő űrlapon. A számlaszám mező után megjelent egy (...) választógomb. Mostantól lehetőség van egy beírt szövegrészlet (itt nem kell előtte a szóköz!) és F9 -el a NAV-tól (az előzőekben leírt módon előzetesen) lekért számlát kiválasztani. A kereső szövegrészlet lehet a kapott számla kibocsátója nevének, adó törzsszámának vagy a számla számának kezdete vagy részlete. Innen kiválasztva a számlát kitöltődik a három dátum (plusz ha a könyvelés dátuma üres, akkor oda a teljesítés ideje kerül), ha megtalálja a partnert az adó törzsszám alapján, akkor azt is kitölti, valamint kitöltődik a bankszámlaszám is (ha van). Kitöltődik a devizanem (ha a beérkezett naplóban ez változtatható) és a számlaérték.

2020.05.07 2.29 -es változat

• Az eredeti bizonylatszám (beérkezett számláknál a kibocsátó által adott számlaszám) 14-ről 30 karakteresre nőtt. Ezáltal az áfa bevallás értékhatár feletti M lapjaira a nagyon hosszú számlaszámok is hiánytalanul átkerülnek.
• Új menüpont/űrlap/adattábla a törzsek között: Műszaki berendezések.  Itt a cégnél használt műszaki berendezések (pl. mobiltelefonok) egyéb fontos adatait lehet rögzíteni, nyilvántartani, áttekinteni. (nincs kapcsolatban a tárgyi eszköz analitikával)
• Új beállítási lehetőség: PDF_M_JELSZO  X   ha beállítják, a Nyomtatási képen jobb egérgombbal készülő emailhez csatolt pdf nem módosítható, de a megnézéséhez/nyomtatásához nem kell jelszó. Ha a tartalma nem üres és nem X (hanem pl. 123), akkor a pdf megnézéséhez/nyomtatásához is kell az itt beállított jelszó: 123

2020.03.02 2.28 -as változat

• A NAV számla jelentés már a február 27-én megjelent új 2.0 interfész specifikáció és XSD séma szerint működik. (2020 áprilistól a régi interfész már nem is használható!)
• Az új adatszolgáltatási igények miatt az érvénytelenítő és módosító számlák egyéni hivatkozás szövegében a # ...# karakterek közötti információs rész kismértékben változik, új információként megjelenik, hogy az adott számla az eredetinek hányadik módosítása.
• A számla készítésekor a 'Vevő' feliraton jobb egérgombbal kérhető NAV adószám ellenőrzéskor a vevő NAV-nál szereplő nevén és címén kívül megjelenik az adószám nálunk és a NAV-nál szereplő vége is (sajnos tapasztalatunk szerint a visszakapott adatok sokszor nem teljes körűek)
• 2020.07.01-től minden magyar adóalanynak kibocsátott számla jelentésre kerül a NAV-nak értékhatártól függetlenül.
• Új beállítási lehetőség: ELH_FOK_ELOL  eeeeeeeehhhhhhhh     ahol eeeeeeee az előleg főkönyv pl. 453, hhhhhhhh az előleg áfa elhatárolás főkönyvi száma pl. 3682   Ez beállítva egyszerűbb esetekben az előleg könyvelése bruttó módon, mínusz előleg áfa elhatárolással valósul meg. (Beállítása előtt konzultáció javasolt)
• Új beállítási lehetőség: SZLEV_TELJNV számlára szállítólevelet választva a számla teljesítési idő nem változik.
• A hagyományos papír alapú számlapéldányok elkészítése után rövid időn belül a 'Nyomtatási kép' ikonon jobb egérgombbal kért számlamásolat PDF+email küldés esetén a számlapéldány szövege: dátum+idő. Ha a számla postai küldése jelen körülmények között nem egyszerű, akkor ezúton is el lehet a számlát (másolatát) a vevőnek küldeni. A használat teljes leírása a 2.16 verziónál található. Emlékeztetőül az ehhez szükséges teendők:
   1.,  A weblapunkon fent levő linkről (Felhasználóinknak/Egyéb/ legalul:) http://ftp.eurosoft.org/downloads/PDFCreator-2_4_1-Setup.exe fel kell telepíteni a PDFCreator programot. Ez egy szabadon használható freeware program, amelyet telepítve a nyomtatók közé egy új virtuális nyomtató kerül be, ami nyomtatás helyett .pdf fájlt készít. Minden olyan munkaállomásra egyenként telepíteni kell, ahol használni kívánják. Figyelem! Mivel nem mi készítettük, a használata során esetleg felmerülő problémákért felelősséget sem tudunk vállalni! Megjegyzés: Az asztalon a telepítés után a PDFCreator ikont egyszer elindítva az 'Application settings'-ben a 'Check for updates'-t célszerű 'Never'-re állítani, majd ezt a 'Save'-el menteni, így a felhasználóinknál egységes változat lesz. Már egy éve teszteljük, negatívumot nem találtunk, Live mail és Outlook levelezővel jól működik.
   2.,  A csatolt .pdf-eket a program le is tárolja (le kell, mert amíg nem küldik el a levelet, meg van nyitva a fájl). Ha nem állítják külön be, akkor C:\PDF_MENT  mappát próbál létrehozni, de be is állítható: PDF_MENT_MAP meghajtóésmappaútvonala  Ha ez hálózati mappa, akkor ennek az útvonalnak minden munkaállomáson ugyanoda kell mutatnia.
   3.,  A partnertörzsben mindenkinél a Kapcs. –ban legyen a Kapcsolattartó neve, ha üres, a program a #1 helyett beteszi: Partnerünk  A mail mezőben legyen az e-mail cím.(vagy másik lehetőség, hogy a Pénzügyes személy legyen kitöltve és akkor a személy törzsben legyen a név és e-mail cím, és akkor küldéskor ezt használja).  A levél szövege előre sémaként megadható ha felvisznek egy Knnn azonosítójú bizonylat szöveget, ahol nnn a napló azonosítója. A levél szövegben lehet a #1 -et (vevő kapcsolattartó neve) és #2 -t (mi nevünk) használni. pl KKB  Tisztelt #1, ezennel .... Tisztelettel: #2
   4.,  Használat: Az éppen elkészült számlán állva Nyomtatási kép gombon jobb egérgomb, választás: Számla. Elvileg a levelező megnyílik, és a csatolmányban ott a számla. Ha bármi még hiányzik, vagy módosításra szorul, az megtehető, és utána ha jó, el lehet küldeni.

2019.09.20 2.27 -es változat

• Új mező a Tárgyi eszköz űrlapon: Besorolás C(20)
• Áfa előre határolás működésének kiegészítése: EUR-ban könyvelő cégek is használhatják, fordított áfa, EU beszerzés áfa is elhatárolható
• Hibajavítás: Gazdasági évek törzsben 2020 év felvitelekor a dátumokat nem kínálta be, javítottuk

2019.08.23 2.26 -os változat

• Hibajavítás: egyes ritkán előforduló esetben devizás értékhatár feletti számla egyidejű árfolyam változtatása ÉS nyomtatása/elkészítésekor a számla NAV jelentése elmaradt (a program az adatbázisban tárolt, és nem az éppen javított árfolyammal számolta az áthárított áfa értékhatárt, míg a nyomtatott számlán már jó értékek szerepeltek).  Ha a számla a hagyományos, megszokott módon készült, vagyis a devizás számla fejadatainak (árfolyamának) kitöltése és mentése után vitték fel a számlasorokat, majd ezt követően ellenőrizték, nyomtatták, úgy a program helyesen működött. Javasoljuk a devizás értékhatár feletti számlák visszamenőleges ellenőrzését. 
• Kérjük, rendszeresen indítsák a Kész lekérdezések/Pénzügy/'Számlázás - NAV Online jelentés adatai' ellenőrző listát!
• Új egyedi listák: ~PARTNER   és ~TARGYIA   (ezek egyes memo mezők első 250 karakterét is átadják excel export esetén)

2019.02.17 2.25 -ös változat

• Az Egyenlegközlő lekérdezésnél is meg lehet adni egy lejárati dátumot (alapértelmezetten: 9999.12.31 ha nem használjuk), de ennek működése más, mint a Felszólító levélnél. Ott csak a megadott dátumnál régebbi lejáratú számlák maradnak, itt viszont csak azon partnerek számlái, amelyeknek van legalább egy, a megadott dátumnál régebbi lejáratú számlája. (Megjegyzés: felszólító levelet lehet az Egyenlegközlő levél lekérdezéssel is készíteni a fejléc, és a fej/lábszövegek átírásával és fordítva is, egyenlegközlőt is lehet a Felszólító levél lekérdezéssel.)
• A Felszólító/egyenlegközlő _05 (lejárat szerinti sorrend) listájába is beépült a .pdf -es emailküldés a _01-es listához hasonlóan.
• A ~PTGSZLH kiegészült, van lehetőség a jelentésbe kerülő tételeket üres adószám ill. országkód szerint szűkíteni
• Új törzs került be: Minimum készletek. A cikktörzsben eddig is megvolt a lehetőség minimum és optimum készletszintek megadására, és az ott megadható adatok továbbra is használhatóak (ha az pl. a fő raktárra vonatkozik), de az új törzzsel lehetőség nyílik más raktárakban is minimum és optimum készletszintet megadni. A cikktörzsben az űrlap eszköztárába bekerült egy új nyomógomb: Min.k., így egy cikken állva könnyen felrögzíthető a cikk egyes raktárakhoz tartozó minimum és optimum készletszintje.
• A Készlet info lekérdezés indító paraméter ablaka kiegészült egy (Rakt/M.) mezővel. Figyelem! Ennek tartalma nem befolyásolja a megjelenő készlet mennyiségeket, azt továbbra is az Ért.k. értékesítési körzet határozza meg! A mező csak a minimum készletszintek betöltését befolyásolja. Ha üresen marad, akkor a készlet info-ban megjelenő minimum és optimum készleteket a program az eddigiek szerint a cikktörzsből hozza. Ha viszont itt megadnak egy raktárat, akkor a minimum/optimum készletszintek az új törzsből jönnek úgy, hogy ha ott nincs az adott cikkhez (és a megadott raktárhoz) tétel, akkor a mezők üresen maradnak. 
• Az új Minimum készletek törzsben EDI feladás/fogadás lehetősége. Beállítása: EDI_M_FELADA  X  A törzsből főmenü/eszközök/EDI feladás-t indítva létrehoz egy  EDI_MIK.TXT  tabulátorral határolt szövegfájlt, amiben cikkszám, raktár, minimum készlet és optimum készlet oszlopok vannak. EDI_M_FOGADA  X     A törzsből főmenü/eszközök/EDI fogadás-t indítva ugyanolyan nevű, és struktúrájú EDI_MIK.TXT -ből beolvassa az adatokat. Újat visz fel, módosítja a mennyiségeket, ill. ahol a szövegfájlban a minimum készlet 0, és volt ilyen tétel, rákérdez és Igen-re törli.
• Az EDI_KONY 'egy bizonylat könyvelési tételeinek importálása' funkció kibővült egy oszloppal. Egy bizonylat 'könyvelési tételek' ablakában állva egy bizonylathoz plusz könyvelési tételsorokat lehet importálni előzőleg a \profit mappába EDI_KONY.TXT néven excelből 'tabulátorral tagolt szövegfájl' formátumban elmentett fájlból. A mezők kötelező sorrendje: főkönyvi szám, partner neve, T/K, érték, hivatkozási szám, devizanem, devizaérték, khely, munkaszám, ktgnem, szöveg (ami nem kell, legyen üres)

2019.02.04 2.24 -es változat

• A 2019-es évben változott a 1965 ált.forgami adó ABEV nyomtatvány struktúrája, így a 2019-es időszakra vonatkozóan a korábbi programváltozatokkal nem lehet az áfa bevallást átadni, csak ezzel az új verzióval. A saját lekédezések között megjelent a ~ MG_BE19 és ~VASBE19 idei évre vonatkozó lista/átadás is mg.termény illetve vas esetére.
• Áttértünk a NAV online számla rendszer január végén megjelent 1.1 verziójára. Figyelem!!! A régi (2.23 és korábbi) programverzióról legkésőbb 2019 ápr. végéig át kell térni a 2.24 vagy mindenkori legfrissebb programverzióra!
• A NAV 1.1 online számla verzióban új elemként a NAV által elvárt formátumban kötelező jelenteni a mennyiségi egységet. A NAV jelentés értékkészlete: PIECE,KILOGRAM,TON,KWH,DAY,HOUR,MINUTE,MONTH,LITER,KILOMETER,CUBIC_METER,METER,LINEAR_METER,CARTON,PACK és végül: OWN, ha az előbbiek egyikébe sem sorolható be a mennyiségi egység. Programunk a szokásosan előforduló mennyiségi egységek automatikus konverzióját elvégzi az alábbiak szerint jelentésköteles számla esetén:
• DB  ,DB. ,DRB ,DRB. mennyiségi egység esetén PIECE  (Darab) -ot jelent (a kisbetűket a mennyiségi egységben előtte nagybetűsíti, így azzal nem kell foglalkozni)
• KG  ,KG. esetén KILOGRAM (Kilogramm) -ot jelent
• T   ,T.  ,TON ,TON. esetén TON (Tonna) -t jelent
• KWH ,KWH.,KWÓ ,KWÓ. esetén KWH (Kilowatt óra) -t jelent
• NAP ,NAP.,N   ,N.  esetén DAY (Nap) -ot jelent
• ÓRA ,ORA ,Ó   ,Ó.  ,O   ,O.  ,ÓRA.,ORA. esetén HOUR (Óra) -t jelent
• PERC esetén MINUTE (Perc) -et jelent
• HÓ  ,HÓ. ,HO  ,HO. ,HÓN ,HÓN.,HON ,HON. esetén MONTH (Hónap) -ot jelent
• L   ,L.  ,LIT ,LIT. esetén LITER (Liter) -t jelent
• KM  ,KM.  esetén KILOMETER (Kilométer) -t jelent
• M3  ,M3. ,KÖBM,M 3  esetén CUBIC_METER (Köbméter) -t jelent
• M   ,M.  ,MÉT.,MÉT esetén METER (Méter) -t jelent
• FM  ,FM. ,F.M.  esetén LINEAR_METER (Folyóméter) -t jelent
• KAR ,KAR.,KART,#   esetén CARTON (Karton) -t jelent
• DOB ,DOB. esetén PACK (Doboz) -t jelent
• egyéb esetben OWN (Saját) -ot jelent és jelenti a számlán szereplő mennyiségi egységet is.
• Kérjük, egyszer ellenőrizzék le a mennyiségi egység törzset, húzzák jobbra az új verzióban megjelent új oszlopokat a vastag vonalon egér lenyomva tart+jobbra húz módszerrel, és ellenőrizzék a NAV mee oszlop tartalmát, hogy helyesen végzi-e el a PROFIT program a fenti konverziókat. Amennyiben találnak olyan mennyiségi egységet, ahol a program által konvertált érték nem megfelelő, pl. Önöknél van   ho    mennyiségi egység, aminek értelme, neve Hordó és az nem MONTH (Hónap), hanem OWN (Saját) kell, hogy legyen a jelentésben, akkor vigyenek fel egy rendszer paramétert: NAV_MEE_HO kóddal, és a tartalma legyen: OWN        Vagy ha Önöknél pl. Dr. a darab, akkor vigyenek fel egy rendszer paramétert: NAV_MEE_DR.   és a tartalma legyen   PIECE    Ezután újra ellenőrizzék a mennyiségi egység törzs NAV mee oszlopát, hogy a jelentés megfelelő legyen és biztosítsák, hogy illetéktelenek ezeket a NAV mennyiségi egység beállításokat később ne változtassák. Új mennyiségi egység felvitele után a fenti ellenőrzést újra el kell végezni a mennyiségi egység törzs újbóli megnyitásával!

2018.12.11 2.23 -as változat

• Új St. státusz (aktív/inaktív) mező a Gépjárművek törzsben. Az eladott gépjárművek szürkék lehetnek.
• Kimenő számláknál ha a HITELK_ELLEN be van állítva, és volt előleg számlázva, a program a vevő kiválasztásakor ezt a tényt a vevő nevét narancssárga színnel kiemelve jelzi. Az első számlasor felvitelekor az eddigi módon szintén figyelmeztet erre.
• A szállítólevél naplóban egy új mező jelent meg: szállítás dátuma. Csak infomációs mező, a készlet továbbra is a Mozg. dátuma dátummal mozog.
• A program bizonyos esetekben engedte a megvásárolt felhasználói (munkaállomás) licenszszám elérésén túli munkaállomásokról való belépést is, ennek ellenőrzése javítva lett. A régebbi verziókkal előállhatott az a helyzet, hogy egy cégnél (cégcsoportnál) valójában (jóhiszeműen) többen használták a PROFIT programot, mint amennyi licenszet vásároltak. Javasoljuk, hogy az új verzióra váltás előtt esetleg ellenőrizzék, hogy a rendszeresen használt munkaállomás szám nem haladja-e meg a megvásárolt munkaállomás licenszszámot. A megvásárolt licenszszám a Rendszer paraméterekben az ERVENYESITES sorban levő tartalomban látszik, annak a legvégén levő szám. Az éppen élő SQL kapcsolatokat pedig a saját lekérdezések/~KAPCSOL.FRX lekérdezés indításával láthaják, ott látszanak az SQL szerverhez éppen kapcsolódó munkaállomások névvel. Licensz kérdéssel, bővítéssel talán jobb, ha még a verzió váltás előtt megkeresnek minket.

2018.09.25 2.21 -es változat

• Új 2 karakteres adatmező a napló állományban a beérkezett és kimenő számlák esetén: Stat. Pénzügyi státusz / ill. fizetési felszólítás státusza. Beérkezett számlák esetén a számla befogadásának, igazolásának, fizethetőségének státusza kerülhet ide, kimenő számlák esetén pedig az, hogy az adott kimenő számlára vonatkozóan milyen (erősségű) fizetési felszólítás ment ki. Ez a mező látszik és így szűrhető a pénzügyi rendezetlen tételek lekérdezésben. Látszik a bank/pénztárban is a kiegyenlített/kiegyenlítendő számla választó listájában. A pü. státusz mező tartalma mögött nincs törzs, az szabadon megadható.
• A felszólító levél készítésekor a paramétereknél van lehetőség egy (új) státusz megadására, és a 01-es lista indításakor lehetőség van kérni, hogy ez a státusz automatikusan íródjon be a nyomtatásban érintett számlákhoz új státuszként.

2018.07.07 2.20 -as változat

• Mivel a 2.19-es verzió kibocsátása után a NAV a https://onlineszamla.nav.gov.hu/kerdesek_es_valaszok felületen új kérdés-válaszokkal a 32. pontban a bevezetés előtti utolsó pillanatokban tovább bonyolította annak eldöntését, hogy egy számla jelentés köteles-e vagy nem, így javasoljuk a 2.20 verzióra frissítést. Ebben a program az aktuális számlát jelentés kötelesnek ítéli akkor is, ha a számla összesített áfa tartalma az értékhatár alatt marad, de a számla pozitív értékű sorainak áfa tartalma az értékhatárt eléri ill. meghaladja. (Megjegyezzük, hogy korábban kaptunk ezzel ellentétes értelmű NAV állásfoglalást is.) Ha mégis úgy ítélik meg (vagy később a NAV változtat ezen az elváráson), akkor egy új NAVONLINETNN  X beállítással az eredeti működés (az értékhatár megállapítása a számla össz. áfája alapján történik) visszaállítható.
• Új beállítási lehetőség: NAVONLINETMI   Amennyiben úgy döntenek, hogy minden számla jelentését/online küldését szeretnék értékhatártól függetlenül, akkor állítsák be:  NAVONLINETMI  MINDET        A beállítás nem visszamenőleges hatályú! A beállítás tényéről, időpontjáról kérjük, vegyenek fel jegyzőkönyvet. Ekkor a program értékhatártól függetlenül jelentés kötelesnek vesz és beküld minden elkészült számlát. A partnertörzsben a Ct. cégtípusban M-el (magánszemély, vagy más, belföldi adószámmal nem rendelkező pl. külföldi cég) jelölt, belföldi adószámmal nem rendelkező számla befogadónak kibocsátott számlák továbbra sem kerülnek jelentésre. Figyelem! A program továbbra is csak az értékhatár feletti számlák esetén figyelmeztet, ha hiányzik az adószám, hogy vagy töltsék azt ki, vagy jelöljék a partnert M-el, így az értékhatár alatti, adószám nélküli, de M-el nem jelölt partnernek készülő számlák is elküldésre kerülnek. Mivel a NAV-nak jelenteni csak a belföldi adóalanyok felé kibocsátott számlák adatait kell/szabad, ezért - ha ezt a beállítást választják - minden esetben gondoskodjanak arról, hogy a belföldi adószámmal nem rendelkező partnereket (magánszemélyeket) M-el jelöljék! 
• Új ellenőrzési célú lista megadható számla kelte tól-ig időszak elkészült számláiről, amin a NAV online jelentés adatai (jelentés köteles-e, státusz, tranzakciós ID, token, NAV és saját szerver UTC idő, szöveges státusz, esetleges Error vagy Warn üzenetek) is látszanak. Kész lekérdezések / Pénzügy / Számlázás NAV online jelentés.
• Pénztárban a napi kp-s számlák egy bevéten való automatikus kiegyenlítése kibővült annak lehetőségével, hogy a 3 -tól eltérő fizetési típus is kezelhető (pl. bankkártyás). Használata: pénztárban új bevéten 5ft-al felvitt tételen a szöveg mezőbe: [KB ]6]  (ha pl. KB a napló, és 6 a használni kívánt fizetési típus)
• Az Áfa lista / AFALE_05 értékhatár feletti tételek listája és M lapok xml készítés módosult úgy, hogy 2018.07.01 utáni időszak lekérésekor már nem figyeli, hogy értékhatár alatti beérkezett számlák összesen elérik-e az értékhatárt

2018.06.19 2.19 -es változat

• A 2.19-es az első olyan verzió, amely alkalmas a végleges éles NAV online számla adatszolgáltatásra. A verzióra való frissítéssel az esetleges korábbi NAV teszt kommunikációk adatait (státuszok, tokenek, tr id-k, üzenetek) a program törli, de természetesen a számlák megmaradnak (fehér színű sorral).
• Aki 06.18-a előtt regisztrált, az a TESZT NAV rendszerbe regisztrált, vagyis új regisztráció szükséges az éles rendszerbe https://onlineszamla.nav.gov.hu/
• Az elsődleges felhasználó regisztrációja után a cégbe belépve egy új technikai felhasználót kell felvinni egy jelszó megadásával. Utána kulcs generálást kell kérni. A PROFIT-ba a rendszer paraméterek törzsbe ennek a technikai felhasználónak a bevitt/kapott adatait kell berögzíteni. Egy cégnél egy technikai felhasználót lehet/kell megadni, másikra csak akkor lehet szükség, ha más számlázó programot is használnak. A kódokat jobb kimásol/beilleszt módszerrel bevinni, mert a kézi begépelés nem szokott sikerülni. (a Chrome böngészőben a mezőn kettős kattintásra jobb egérgombbal lehet megnyíló menüből a Másol-t kérni) A rendszer paraméterek törzsbe az Új (F4  vagy Ctrl N) gombbal fel kell vinni a következő kódokat, ha nem léteznek.
• NAVONLINEPWD    Ide a technikai felhasználó létrehozásakor megadott jelszót kell beírni. Az adat beírásakor ENTER-re egy kérdés jön, arra Igen után a tartalom elkódolódik.
• NAVONLINEUSR    A technikai felhasználónál a kulcsgenerálás során megjelenő felhasználónév.
• NAVONLINEKEY    XML aláírókulcs
• NAVONLINEEXK    Kapott cserekulcs 
• Az adatok beírása után az egyik ilyen soban a mentés után az alsó Megjegyzés mezőbe (nem a tartalomba!) a    teszt   -et írva ENTER-re lefut egy teszt kommunikáció, ha van internetelérés, és más technikai problma (tűzfal, Panda vírusirtó stb.) nem akadályozza és ha jók voltak a beírt adatok, akkor a program kiírja, hogy sikeres a tokenkérés. Ezt a tesztet a többi munkaállomáson is meg kell ismételni.
  További szükséges paraméter:  NAVONLINETSU    Azon PROFIT felhasználók nagybetűs belépési nevét kell ide beírni vesszővel elválasztva (és lezárva), akik jogosultak a számlakibocsátó cég érzékeny név, cím, stb. adatait módosítani és egyéb ritkán szükséges NAV kommunikációs műveletet indítani. A NAVONLINETEH beállítás érvényét veszti, törölhető.
• Rendszergazdáknak: Amennyiben a teszt során (vagy a normál számla készítés utáni azonnali adatszolgáltatás során) a jobb felső sarokban megjelenik egy 1 mp-ig megjelenő üzenet, hogy telepítsenek egy MSXML parsert, az azt jelenti, hogy az adott munkaállomáson hiányzik egy olyan szoftver komponens, amely lehetővé tenné a NAV adatszolgáltatás küldés előtti megelőző XSD validálását, egy plusz ellenőrzést, amely egyes ritka esetekben kiszűrhet olyan adathibákat még a küldés előtt, amelyek majd a küldés során ERROR visszautasítást eredményeznek. Ha ezt látják kiírni, kérjük indítsák el \PROFIT mappában levő (a 2.19 programfrissítés során bekerült) msxml.msi telepítőt, ami indítja a Microsoft (R) MSXML 4.00 SP3 XML parser telepítését. A telepítéshez esetleg rendszergazdai jogosultság (belépési név, jelszó) kellhet. A telepítés nem feltétele a hibátlan adatszolgáltatásnak, csak egy plusz biztonsági - a valódi adatküldést megelőző - ellenőrzést tesz a PROFIT program számára lehetővé.
• Rendszergazdáknak: A PROFIT főmappába bekerült egy OPENSSL.EXE alkalmazás. Ha a fent említett teszt során ennek futtatásakor 'ismeretlen forrásból származó...' Futtat/Mégse  kérdések jelennek meg, vagy SHA, AES hibaüzeneteket kapnak, úgy a rendszergazdának gondoskodnia kell, arról, hogy ezt az alkalmazást a munkaállomásról futtatni lehessen, azt megbízhatónak tekintve ne jöjjenek fel a kérdések és működjön. Ha ezt nem sikerül megoldani (pl. pdedit.msc futtatásával, Panda vírusirtó kikapcsolásával) akkor kérjük, keressenek minket.
• Jogi nyilatkozat (a számlázó indításakor megjelenik, Ok-ra tovább lehet lépni):  Jelen számlázó program a 2/2018. (VI.1.) PM rendelettel módosított 23/2014. (VI.30.) NGM rendelet előírásai alapján az alábbi feltételek szerint a dokumentációban leírt módon alkalmas a rendelet 13/A.§ (1) pontjában előírt gép-gép adatszolgáltatásra:
  - a számlázás 2018.07.01-i megkezdése előtt a https://onlineszamla.nav.gov.hu/ oldalon minden olyan céget, amelyben gépi számlázás lesz, regisztrálni kell, és a felvitt technikai felhasználó ott kapott adatait a Rendszer paraméterek-ben a programdokumentációalapján be kell vinni.
  - minden számlázó munkaállomáson egyszer a dokumentációban leírt teszt segítségével ellenőrizni kell a munkaállomás alkalmasságát a NAV kommunikációra (ez egyben a bevitt kulcsok helyességét is ellenőrzi)
  A PROFIT számlázó moduljának felhasználója tudomásul veszi és elfogadja, hogy a Szoftver - a Szoftver fent említett NAV online adatküldési funkciója - az adatszolgáltatási folyamat során csak és kizárólag segédeszköze, de semmilyen módon, semmilyen esemény és körülmény bekövetkezése esetén nem felelőse a rendelet által előírt kötelezettség szerinti megfelelésnek.
  Felhasználó a sikertelen és sikeres beküldések eredményéről is értesül akár a NAV webes felületén keresztül, akár a program segítségével.
  Amennyiben a program felhasználója úgy észleli, hogy a program bármilyen okból a rendeletben előírt értékhatár meghatározásában, a küldött adattartalom helyességében vagy a kommunikáció során hibát vét, úgy elfogadja, hogy ekkor a rendelet 13A.§ (6.) bekezdése illetve a 13B.§ (5.) bekezdése szerint az előírt határidőn belül - ha szükséges, a hiba bejelentésével és - az adatszolgáltatásnak az adatok manuális rögzítésével tesz eleget. Amennyiben ennek elmaradása miatt mulasztási bírság kiszabására kerül sor, úgy ezt semmilyen okból nem hárítja át az Eurosoft Kft-re.
• Az áfa 05-ös értékhatár feletti tételek XML abev feladásánál kikerülnek a júl.1 utáni keltű kimenő számlák, az értékhatár 100000 Ft-ra változik.
• Az áfa trv.159 §(3) szerint az előlegről szóló számla 'annak a termék értékesítésének, szolgáltatás nyújtásának az adatait tartalmazza, amelynek teljesítése fejében járó ellenértékbe az előleg beszámítható'. Az ennek való megfelelést segítheti, hogy ha egy rendelés alapján történik előlegszámla készítés, akkor a rendelés tételek űrlapon az űrlap eszköztárának 'Másol' gombján jobb egérgombbal a rendelés tételeinek adatai vágólapra másolódnak abból a célból, hogy az előlegszámla előleg tételsorának szöveg mezőjébe könnyen beilleszthessék.
• Az Online számla rendszerbe jelentett sárga (WARN) státuszú számlák esetében az adatszolgáltatás megtörtént. Kérjük, elsőként ne hozzánk forduljanak azzal, hogy mi a hiba, és mit kell vele csinálni. A NAV hibaüzenete a jobb alsó mezőben található, az XML tagek között magyar nyellven is.  A beküldött adatszolgáltatás a NAV webes felületen lekérdezhető (Számlák/Kimenő számlák,kelt tól és kelt ig dátum kitöltése után a szűrés gombbal, majd a kívánt beküldött számlán kattintva. (A megjelenés néha hibás, a NAV jelenleg még fejleszti.) A beküldött adatszolgáltatás a PROFIT-ban is lekérdezhető: alul a St. státusz mezőn kettős kattintásra és a kérdésre Igen-t adva a beküldött XML-t látják, annak minden adatával. Amennyiben úgy érzik, hogy a számla jó, a beküldött adat is jó és a NAV WARN üzenete felesleges, úgy hagyják figyelmen kívül vagy forduljanak a NAV ügyfélszolgálatához. Ha a kinyomtatott számla és a beküldött adatszolgáltatás között látnak eltérést, úgy keressenek minket. Dönthetnek úgy is, hogy ha jogosnak találják a NAV figyelmeztetését, és a hiba súlyos, akkor érvényteleníthetik a számlát és kiállíthatnak újat (vagy az érvénytelenítés után egy módosító számlát/módosító okiratot a hibás eredeti számláról)
• Új beállítás: NAVONLINETER     ide X-et írva a program az ERROR(Aborted) piros státuszú számlák adatait egyszer változatlan adattartalommal elküldi, utána az X-el kiveszi. Akkor lehet hasznos, ha módosító vagy érvénytelenítő számla státusza lett ERROR (Aborted) a NAV feldolgozás hibája miatt.

2018.05.28 2.18 -as változat

• A 2.18-es verzió még mindig nem alkalmas a végleges NAV online számla adatszolgáltatásra, kifejezetten ennek tesztelésére alkalmas. Mivel a NAV az online számla teszt rendszerben május 26-án a 0.13 verzióra váltott és ennek során változott a jelentési séma, így a 2.17-es változatunk a továbbiakban nem tudja az adatszolgáltatást elküldeni, így a 2.18-ra váltás javasolt. Az előző verzióval készített, jelentésköteles, de el nem küldött jelentések a 2.18 verzióra váltás után elvileg hibamentesen elküldésre kerülnek. Július 1-e előtt még mindenképpen programcsere szükséges.
• A NAVONLINETSU -ban beállított arra jogosult felhasználók a St. NAV státusz mezőn kettős kattintással további lehetőségeket indíthatnak: 1) Ha a státusz E és a hibaüzenet: 'erre a sorszámra már volt adatszolgáltatás', és nem számlaszám ütközés történt, akkor  - nagyon ritkán - előfordulhatott az a helyzet, hogy a jelentés elment, de a tr.id-t valamiért nem kaptuk vissza, és megismételt jelentés miatt jön a hibaüzenet. Ez esetben a program egy számlaszám alapú NAV lekérdezéssel lekéri ez eredetileg kiadott (de meg nem kapott) tr id-t, és eltárolja. Ezután a státusz lekérdezése már normál módon történik.  2) ha a valamilyen okból meg nem valósult adatszolgáltatást időközben kézzel a NAV webes felületén kézzel berögzítették, akkor ezt a program a számlaszám alapján történő lekérdezés során észleli és a számlát kérésre K (kézzel rögzítve) státusszal jelöli. 3) egyéb esetekben pedig egyszerűen megjeleníti a NAV adatszolgáltatás során bekerült számla xml-t ellenőrzési célból.
• A program kiegészült a partnerek adószámának NAV ellenőrzésével. A partnertörzsben az adószám elhagyásakor, vagy az Adószám mező feliraton való jobbegérgombra a program a NAV szerverrel kommunikálva lekéri és értesítő ablakban megjeleníti az adószámhoz tartozó nevet és címet, vagy felkiáltójelekkel azt, ha érvénytelen az adószám. Kimenő számla készítésekor a vevő szürke cím mezőjén jobbegér gombra vagy a Vevő mező feliraton jobb egérgombra (ez utóbbi elkészült számla esetén is működik) hasonlóan lekéri és megjeleníti az adószám érvényességét, illetve az ahhoz tartozó cég nevét, címét. (A NAV szerint csak az éles rendszerben fog 100%-ban pontos adatot szolgáltatni!)

2018.04.15 2.17 -es változat

• A 2.17-es verzió még nem alkalmas a végleges NAV online számla adatszolgáltatásra, de a fejlesztések jórészt az ezzel kapcsolatban már megjelent dokumentációban leírt követelmények teljesítése érdekében történtek. A NAV online jelentés tesztelése elkezdhető, sőt javasolt, hogy jelentkezzenek az esetleges informatikai, ügyviteli problémák. Július 1-e előtt még mindenképpen programcsere szükséges!!! További információk és teszt regisztráció: https://onlineszamla-test.nav.gov.hu/
• Figyelem!!! A NAV jelenleg még folyamatosan fejleszti a rendszert, az közel sincsen kész. A verzió kibocsátásakor még csak kevés validáció működik, nem működnek a WARN üzenetek és alig működik a webes felület.
• A Naplófajták beállítása törzs kezelése szigorúbb lett. 'S' szám képzésű kimenő napló (szigorú számadású számlázás) esetén utólag már nem változtathatóak meg a következő adatok: szám képzés módja, szám képzés formátuma, devizanem, biztonsági mód. 'S' szám képzésre csak új napló felvitelekor lehet állítani a kimenő naplót tehát nem lehet A vagy üres szám képzésű kimenő naplót S szigorúvá tenni. Ha nincs még tétel az ilyen naplóban, akkor persze törölhető, és fel lehet újra vinni.
• Új ellenőrző törzsek kerültek be a rendszerbe: irányítószám/helység(település), ISO 3166 alpha 2 országkód, országon belüli régió kód, ISO 4217 devizanem kódok. Ezek a felhasználó által nem módosítható háttér törzsek. Megpróbáljuk ezeket a programfrissítések során frissen tartani. Ha hibát találnak benne, kérjük, jelezzék nekünk.
• A Partnerek űrlap több ellenőrzéssel bővült. Nem enged partner adatváltoztatást menteni, ha az országkód ki van töltve (ha üres, az megfelel a HU országkódnak) de nem egyezik az ISO 3166 országkódok egyikével.
• Amennyiben az országkódba érvényes külföldi országkódot írnak és a cég adószáma üres, a program rákérdez, hogy beírja-e az M jelet a cégtípusba (M: magánszemély vagy belföldi adószámmal nem rendelkező külföldi partner).
• Belföldi partner esetén (országkód üres vagy HU ) az irányítószám beírására a program kitölti a helység nevét és a HU országkódot. Ha egy irányítószámhoz több helységnév is tartozik, akkor rákérdez, hogy megfelelő-e, és nem válaszra kínálja a következőt. Hibás irányítószám esetén hibát jelez, de a mentést engedi.
• Belföldi partner esetén, ha az irányítószám üres, de a helységnév (a nagyvárosok kivételével) beírásra kerül és a program megtalálja, akkor beírja az irányítószámot és HU-t az országkódhoz. Ha az irányítószám-helységnév páros nem jó, hibát jelez, de a mentést engedi. A hibát a mező elhagyásakor és a mentéskor is jelzi. A kisbetű/nagybetű eltérés nem gond, de az ékezet eltérés igen. Nem jelez hibát, ha nincs megvéve a számlázás modul vagy nincs szigorú számadású számlázás napló, hogy a csak könyvelő cégeket a plusz ellenőrzés ne zavarja.
• Külföldi partner esetén a helység mezőben lehetőség van régiókód elhelyezésére az ISO 3166-2 szerint a mező elején, / sima perjellel elválasztva a helységnévtől. Pl. US-NY/Bristol. A program ennek helyességét ellenőrzi, és nem enged hibás kódot rögzíteni.
• A saját partner (-1 azonosítójú partner) neve a lista képernyőn szürke háttérszínnel jelenik meg. Lekérdezés üzemmódban ezen (saját) partneren állva az űrlap eszköztárán levő ? gomb megnyomására nem a partner info jelenik meg, hanem a program végrehajt egy ellenőrzést a teljes partnertörzsön végigfutva, és azon belföldi partnereknél, amelyeknél országkód vagy irányítószám-helység hibát talál, a lista képernyőn a megfelelő oszlopokat halványpiros háttérszínnel jelöli. Ahol az adószám üres, de nincs a partner cégtípusánál M-el jelölve (magánszemély vagy belföldi adószámmal nem rendelkező külföldi partner) ott az adószám oszlop háttérszínét halvány pirossal jelöli. Ennek segítségével könnyebb átfésülni és szükség esetén javítani a hibákat. Szállítók esetén, vagy ha nem használják a számlázást erre nincs feltétlenül szükség. Az ellenőrzés elején a program lehetőséget ad arra, hogy ha előfordul három karakter hosszú vagy kisbetűs országkód, kérésre átkonvertálja (levágja) két karakteresre és nagybetűsre az összes ilyen partnernél (pl. HUN -> HU )
• A partnertörzsben az Adószám mező felirat kék színű lett. A feliraton kettős kattintásra bejön az alapértelmezett böngésző és megjeleníti a http://nav.gov.hu/nav/adatbazisok/adatbleker/afaalanyok/afaalanyok_egyszeru weblapot, ahol ellenőrizni lehet egy adószám meglétét és a hozzá tartozó cég adatait vagy a partner neve alapján is lehet keresni.
• Kimenő számlázás esetén további ellenőrzések/szigorítások kerültek a rendszerbe: a számlafej mentésekor a program figyelmeztet, és nem enged menteni, ha a vevő vagy szállító országkódja ISO 3166 alpha 2 hibás és nem is enged menteni. Figyelmeztet ha a vevő vagy szállító régió kódja ISO 3166-2 hibás és nem is enged menteni. Figyelmeztet, ha a devizanem ISO 4217 hibás és nem is engedi menteni. Figyelmeztet, ha a szállító vagy vevő belföldi és az irányítószám-helység hibás, de engedi menteni. Ha az adott számla NAV online jelentésköteles lesz, akkor ez esetben a NAV erre - bár befogadja az adatszolgáltatást - üzleti hibát fog jelezni. Jelentésköteles számla esetén a felhasználó döntése (hogy mégis engedte a számlát elkészíteni) rögzítésre kerül.
• Új beállítási lehetőség: IRSZ_SZIGORU       X Ha beállítják, akkor az előbbi esetben nem is engedi 2018.július 1-től az irsz-helység hibás számla mentését.
• A program figyelmeztet és nem is engedi a számlafej mentését ha a munkaállomáson beállított rendszerdátum nem egyezik az SQL adatbázisszerver rendszerdátumával.
• Kimenő számlán eddig a 'Jel' nevű mezőben lehetett G -vel jelölni a gyűjtőszámlát, illetve ide tette a program a számla elkészítésekor a partner e-szla mezőjét: X: elektronikus számla, T: tesztidőszak elektronikus számlája. A napló állomány kibővült új mezőkkel, és innentől egy új 'G' mezőben lehet jelölni a gyűjtőszámlát, És egy új 'E' mezőbe kerül az elektronikus számla jele (X,T). A 'Jel' mező innentől semmilyen más célra nem használható, mint az érvénytelenítő E és módosító M dokumentum jelölésére.
• Új beállítási lehetőség: EU_ADOMENTES       ebben a beállításban kell felsorolni azon értékesítés áfa kategóriákat amelyeknek a számlán való előfordulása esetén a számlán kötelező a szállító és a vevő közösségi (EU) adószámának feltüntetése. Az áfa kódokat két karakter hosszban, vesszővel elválasztva és vesszővel lezárva kell megadni: aa,aa, Be kell állítani, ha használják a számlázást, és akkor a program számla készítésekor a közösségi adószám hiányára figyelmeztet.
• Új beállítási lehetőség: AFA_HATALY_K       ebben a beállításban kell felsorolni azon értékesítés áfa kategóriákat amelyek az ÁFA trv. hatályán kívül esnek. Az áfa kódokat két karakter hosszban, vesszővel elválasztva és vesszővel lezárva kell megadni: aa,aa,  Kötelező beállítani, ha használják a számlázást, és előfordul ilyen, mert a NAV online jelentésben ezeket külön kell jelenteni. Ugyanígy kötelező a már korábbi jelentés kapcsán megjelent FORD_AFA_ERT beállítása is, mert a fordított adózás hatálya alá eső értékesítéseket is külön kell jelenteni!
• Változtak, szigorodtak az érvénytelenítő és módosító okirat (számlával egy tekintet alá eső okmány) készítésének szabályai is. Kimenő számlázás naplóban a 'Jel' mező többé már nem a felhasználó által is beírható adat, hanem a program maga állítja. Érvénytelenítő és módosító okirat csak (eredeti) számláról készíthető, csak olyan számlára hivatkozhat (aminek a 'Jel' mezője üres).
• Jellemzően úgy készíthetjük, hogy rálépünk az eredeti számlára és azon állva a 'tétel másolása' (F5) gombbal indítjuk a számlakészítést, és a feljövő kérdésre a 'számla érvénytelenítése' vagy 'számla módosítása' -t választjuk. Eddig nehézkes volt előző gazdasági év számláját tárgyévi naplóban érvényteleníteni vagy módosítani, ezért erre az a megoldás született, hogy el kell menni az előző évi naplóba, és rá kell lépni az eredeti számlára. A 'tétel másolása' (F5) gombbal a feljövő kérdésben lehet az 'eredeti számla megjegyzése' -t is választani. Ezután át kell menni a tárgyévi számlázás naplóba és ott bármelyik számlán állva a kimenő számla űrlapon (nem a tételeknél) a 'tétel másolása' (F5) gombbal a feljövő kérdésben a korábban megjegyzett számla számát írja ki, és ekkor az érvénytelenítést vagy módosítást választva a megjegyzett számla lesz a hivatkozott (eredeti) számla. Csak azonos napló más évébe belépve használható.
• Csak olyan számláról készíthető érvénytelenítő és/vagy módosító okirat, amely az aktuális cégadatbázisban megtalálható, a régi gazdasági év adatainak törlésével megszűnik annak lehetősége is, hogy erről a programmal készítsünk érvénytelenítő vagy módosító okiratot. Kézi számlatömbbel persze továbbra is meg lehet ezt oldani.
• Az érvénytelenítő okiratnak (jele:E)       csak a könyvelési dátuma és - bár ennek módosítását nem javasoljuk - teljesítési dátuma módosítható. A számlasorok nem módosíthatóak. Elkészítése előtt közvetlenül a program leellenőrzi, hogy az eredeti számlának ez lesz-e az első 'számlával egy tekintet alá eső okirata'. Ha nem (mert pl. készült azóta egy másik módosító okirat, ami az eredeti számlára hivatkozott), akkor nem engedi elkészíteni. Az érvénytelenítés csak az első okiratnál lehetséges.
• Számla módosítása is csak eredeti számlára történhet. Az eredeti számla viszont több módosító okirattal is módosítható és érvénytelenítés után is van lehetőség - akár több, az eredeti számlát módosító - okiratot készíteni. Új módosító okirat első mentésekor a program megkérdezi, hogy az eredeti számla sorait hogyan másolja a módosító okiratra. (ne másoljon, mínusszal majd plusszal vagy csak plusszal, ha volt érvénytelenítő) (A korábbi SZHELYESBITO beállítás érvényét veszti). Módosító okiraton megengedett a számla fejadatainak szükség szerinti módosítása a vevőt kivéve (de a vevő adatai a partner törzsben változtathatóak). Módosító okirat tételsorai is szabadon módosíthatóak, a bekínált sorokból lehet törölni is és lehet újat is felvinni, de lehet a pluszos (helyes) sorokban akár csak az eladási egységáron változtatni. A számlafej megjegyzés mezőjébe szabadon lehet megjegyzéseket írni, de a program nem engedi a mező elejére beírt, az eredeti számlára való hivatkozást módosítani. A mentéskor egy ellenőrzés után a megjegyzés mező végére #...# karakterek között egyéb belső megjegyzéseket tesz, pl. kiírja a legutolsó módosító okirat sorszámát, vagy hogy az eredeti számla jelentés köteles volt-e.
• Eddig a számlasor tételek űrlapon a ’Kor.’ gombbal csak azután lehetett választani korábbi értékesítéskor, ha a cikk már ki lett választva. Az új verzióban üres cikk esetén is lehet választani. Módosító okirat sorainál a ’Kor.’ gomb csak az eredeti (hivatkozott) számla (plusz az arra hivatkozó módosító okiratok) soraiból enged választani. Így - ha egyáltalán nem kértünk tétel másolást a módosító okirat mentésekor - a ’Kor.’ gombbal egyes számlasorokat is könnyen mínuszolhatunk, majd megírhatjuk egy új sorban helyesen.
• A program a normál számlán mínusszal írt sorokat (visszáru, göngyöleg visszáru, előleg beszámítás) normál számla adatszolgáltatással jelenti akkor is, ha van a számlasorban automatikusan bekerült vagy kézzel valahova beírt korábbi számlára való hivatkozás. Ha (pl. a visszárut) számlát helyettesítő okmányként akarják kezelni, akkor ne egy normál számlára kerüljön, hanem külön módosító okiratként kezeljék. Ekkor a NAV online számla adatszolgáltatásba is módosító okiratként kerül.
• A számla kelte egy még készítés alatt levő számlán eltérhet ugyan a mai (rendszer) dátumtól de ha a program a számla elkészítésekor nem a mai dátumot találja a számla kelt mezőben, akkor azt mai napi rendszerdátumra javítja, hibaüzenetet ír erről és nem készíti el a számlát lehetőséget adva arra, hogy a lejárati dátumot a felhasználó esetleg még javíthassa a számla elkészítése előtt. (a korábbi SZ_KELTE_MAI beállítás érvényét veszti)
• A számla kibocsátójának (a szállítónak) és befogadónak (vevőnek) az adószáma nem lehet azonos.
• Miután a 2018. július 1-től várhatóan hatályos NGM rendelettervezet 2.§.(6) szerint: 'A számlázó programmal előállított számla, számlával egy tekintet alá eső okirat ... abban az időpontban minősül kiállítottnak, amely időponttal a számlázó program az előállított számla, számlával egy tekintet alá eső okirat adatait lezárja', valamint a NAV online számla adatszolgáltatás dokumentációja is érvénytelenítő dokumentumot ír elő, így a továbbiakban a programban eddig benne levő 'Rontott bizonylattá minősítés' (ha a kiállítás megtörtént, de nem történt számla kibocsátás) lehetősége megszűnik a szigorú számadású kimenő számlanaplókban. Vagyis függetlenül attól, hogy a számla befogadója rendelkezésére bocsátottuk-e a számlát vagy nem, a kiállított számla csak érvénytelenítő okirat kiállításával érvényteleníthető. A korábbi verziókkal R 'Rontott' (ki ne bocsátott bizonylattá) minősített rontott számlák természetesen továbbra is R rontottként látszanak és a kezelésük sem változik (nem látszanak a rendszerben, csak a számla naplóban/iktatókönyvben).
• A nem szigorú számadású kimenő naplókban (szám képzés módja üres vagy A) megmarad a rontás lehetősége. A mező a képerny jobb oldalára középre kerül. Ahol eddig proforma számlát esetleg szigorú számadású naplóban készítettek lerontással, ott javasoljuk, hogy még a 2.17 verzióra váltás előtt állítsák át a naplóban a szám képzés módját A-ra (mert a verziócsere után ez már nem lesz lehetséges). Eddig nem szigorú számadású kimenő naplóban számla nyomtatás kérésekor a program nyomtatott egy számlához hasonlító bizonylatot, de nem írta rá: SZÁMLA. Ezután HUF és devizás esetben is ezt írja rá a fejlécben: PROFORMA
• Az új verzóban a program - a munkaállomás internet elérése esetén - a bizonylat rögzítő űrlapokon üres árfolyam mezőn megkísérli az aktuális napi (könyvelési dátum alapján) MNB árfolyamnak az MNB honlapjáról történő lekérdezését és ennek eredményéről üzenetben tájékoztat, beírja az árfolyamot, valamint ha szükséges, felkínálja az új árfolyam akár azonnali felvitelét a devizaárfolyamok törzsbe.
• Ha nem MNB árfolyamot használnak, akkor az ARF_MNBNEMKE * beállítással lehet azt minden naplóban letiltani. Ha csak néhány naplóban nem kell az MNB árfolyam használata, akkor azt az ARF_MNBNEMKE       nnn,nnn,nnn,   beállítással lehet elérni, ahol nnn a napló, amelyben nem kell az MNB árfolyam. A naplókat 3 karakterre kell szükség esetén szóközzel kiegészíteni és (az utolsót is) vesszővel kell lezárni.
• Új beállítási lehetőség. Be lehet állítani, hogy mely felhasználók jogosultak a saját (-1 –es azonosítójú) partner legfontosabb (a jelentésben szereplő) cím, adószám, stb. adatainak, és a NAV online számla jelentés során egyes speciális műveletek indítására. NAVONLINETSU felhaszn,felhaszn2,   ahol az erre jogosított felhasználókat kell vesszővel elválasztva és a végén lezárva felvinni.
• Tesztelési célú további beállítási lehetőségek a NAV online számla jelentéssel kapcsolatban: NAVONLINEADO az online számla teszt rendszerbe regisztrálás során használt (saját) adó törzsszám (8 kar.), NAVONLINEUSR technikai felhasználó kapott neve, NAVONLINEPWD a technikai felhasználó megadott jelszava, NAVONLINEKEY kapott XML aláíró kulcs, NAVONLINEEXK kapott cserekulcs. Ezeket az értékeket lehetőleg a regisztrációs weblapról kijelöl/kimásol, ide bemásol módszerrel végezzék. Ezek a beállítások a rendszer paraméterek törzsben a beírás után adatvédelmi okból kódolásra kerülnek, vagyis ha nem a beírt (bemásolt) értéket látják, az normális. Ugyanezen beállításokat kell majd az éles indulás előtt az éles online számla rendszerbe való regisztrálás után ott felvitt technikai felhasználó éles adatainak rögzítésére.
• A fenti sorok egyikén állva ha Megjegyzés mezőbe (nem a tartalomba!) beírják: teszt  akkor ENTER-re a program leellenőrzi a NAV kommunikációt, a felvitt kódok helyességét, és ennek eredményét a mezőbe visszateszi. Az itt kiírt adatban szereplő ABORT és ERROR csak azt jelenti, hogy az üres sorokkal beküldött szándékosan hibás számla nem került befogadásra, de a sor végén ’a NAV teszt sikeres’ üzenet a kommunikáció sikerességét jelenti.
• NAVONLINETEH tesztidőszakban a jelentendő számla áfa értékhatára (M: magánszemély vagy belföldi adószámmal nem rendelkező külföldi vevő esetét kivéve, mert ezen értékesítéseket nem szabad jelenteni). 2018.06.30 után, illetve majd a tesztidőszak után megjelenő ’éles’ online jelentésre alkalmas programverzióban a beállításnak nincs hatása. Csak az előző pontban leírt beállítások után kell beállítani. Ha a teszt adatküldések során esetleg fellépő hibaüzenetek zavarják a munkát, akkor az értékhatár növelhető vagy akár a beállítás törölhető. Ha éppen fordítva, teljes tesztelést szeretnének, az értékhatár csökkenthető akár -9999999999 -ig (hogy minden érvénytelenítő számla is menjen).
• Új (csak kiírási) mezők a kimenő számla űrlapon alul : ’J.’ NAV online jelentésbe tartozó, jelentendő számla: X       (tesztidőszakban: T). Ha üres: nem tartozik a jelentésbe.
• ’S.’ NAV online jelentés státusza. Üres: nem jelentett (még) (a lista képernyőn a számlaszám kék, ha jelentendő, de a jelentés még nem sikerült, a beküldött számla adatszolgáltatás státusza még nem érkezett vissza), O: Ok(DONE), a számla adatszolgáltatás hibaüzenet nélkül megtörtént (a lista képernyőn: zöld), W: Warn(DONE), a számla adatszolgáltatás megtörtént, a NAV rendszer üzleti validációs hibát jelzett (sárga). E: Error(ABORTED), bár az adatok jelentése megtörtént, de a számla adatszolgáltatás nem valósult meg valamilyen validációs hiba miatt(piros). K: kézi adatszolgáltatással lett megoldva a hiba (szürke)
• E két mezőtől jobbra egy (kiírási) memo (naplózási célú) mező tárolja a NAV kommunikációval kapcsolatos fontosabb dolgokat, esetleges Warn/Error hibaüzeneteket.
• Ha a fenti beállítások tesztelési célból megtörténtek, akkor a program jelentésköteles számla esetén még a számla elkészítés előtt egy ú.n. tokent kér a NAV (teszt) szervertől, és az elkészítés előtt további ellenőrzéseket végez. Ha technikai hiba, internetelérés hiánya, NAV üzemszünet stb. miatt nem kap tokent, jelzi, hogy a jelentés várhatóan nem tud rögtön elmenni, de engedi a számla elkészítését a választ feljegyezve. Ha a NAV szerver UTC idő eltér a helyi SQL szerver UTC idejétő 6 óránál többel, figyelmeztet de engedi a számla elkészítését a választ feljegyezve. A küldendő XML fájlon előzetes XSD ellenőrzést végez, és hiba esetén figyelmeztet de engedi a számla elkészítését a választ feljegyezve. A program minden jelentendő számla adatait a számla elkészítésekor a nyomtatási feladat kiadása után azonnal megkísérli elküldeni, és ha ez a szinkron kommunikáció sikeres, az adatküldést igazoló tranzakciós ID-t eltárolja. Ha nem sikerült a küldés, akkor erről figyelmeztetést ad, és enged tovább dolgozni. Még a sikeres adatküldés esetén sem vagyunk készen az adatszolgáltatással, mert ezután a NAV-nál egy aszinkron feldolgozás lefutása után (ígéreteik szerint éles rendszerben kb. 4-5 perc lesz) lehet csak megtudni a feldolgozás eredményét. A program a következő esetekben végez összetett kommunikációt a NAV szerverrel: 1,) a számlázó programba való belépéskor 2,) a lista képernyőre egérrel való minden átváltáskor 3.) a számlázóból való kilépéskor   Egyszer lefut, és minden számlán, amelynél szükséges, végrehajtja a szükséges lépést (akkor is, ha az másik naplóban van, vagy kívül esik a napló megnyitásakor megadott tól-ig időszakon, vagyis nem csak azokon a számlákon, amelyeket a felhasználó lát, hanem mindegyiken, amelyiken szükséges. De csak ebben a cégben! Másik (könyvelt) cég adatait ez nem érinti! Ha tehát a felhasználó az utolsó jelentés köteles számla kiállítása után még a számlázóban marad addig, amíg annak státuszát is le tudja ellenőrizni (úgy, hogy egérrel átlép a lista képernyőre) és meggyőződik az adatszolgáltatás megtörténtéről, akkor már nyugodtan kiléphet a számlázóból.
• Ha a kilépéskor a program úgy látja, hogy vannak még NAV feldolgozandó számlák, akkor ezt jelzi, és lehetőséget biztosít arra, hogy kilépés helyett a felhasználó a számlázót egy időzítetten állandóan futó állapotban hagyja abból a célból, hogy ha később elhárul a NAV kommunikációt akadályozó technikai probléma (nálunk, vagy a NAV-nál), akkor a jelentés/adatszolgáltatás késedelem nélkül megtörténhessen. Nem gondoskodik más folyamat a küldésről, vagyis ha a szerver vagy munkaállomás kikapcsolásával fejeződik be a munka, az adatszolgáltatás nem fog megtörténni. Az E (Error) státuszú számlák létét a program be/kilépéskor jelzi, de ezeket csak jelzi, ezekkel nem tud mit tenni, ezek esetében felhasználói beavatkozásra vár.
• Ha a NAVONLINETSU -nál beállított jogosult felhasználó E (error) státuszú számlán a Részletek képernyőn a ’S.’ státusz mezőn kettőset kattint, azzal (mentés után) átállíthatja azt K státuszúra jelezvén, hogy ennek kézi adatszolgáltatása a NAV erre szolgáló webes felületén a programtól függetlenül megtörtént.
• A rendszer (alap) számlariportok kiegészültek egy felirattal. Ha a vevőnek nincs kitöltve az adószáma, és a partner törzsben (nem a számla űrlapon alul!) a ’Ct.’ Cégtípus mezőben M szerepel (magánszemély vagy belföldi adószámmal nem rendelkező külföldi cég), akkor a nyomtatott számla jobb oldalán a vevő adatoknál az adószám helye közelében a program kiírja: ’belföldi adószámmal nem rendelkezik’. Ezzel egyértelműen megkülönböztetve attól az esettől, amikor a számla befogadójának (vevőnek) egyszerűen csak nincs kitöltve az adószáma a partnertörzsben.
• A programban lehetőség van kihasználni a gazdasági év 5. karakterét. Eltérő üzleti évre váltás, előtársaság, átalakulás, felszámolási eljárás indulása esetén a ’Gazdasági évek’ törzsben új gazdasági év vihető fel az előzőnél nagyobb 5. karakterrel azonos évvel. Pl. Kft.-ből Zrt-vé váláskor 2018   (Kft.) után: 2018Z       (Zrt) Ilyen esetekben eddig – folytatva a naplókat - számlaszám ütközés fordulhatott elő, hiszen minden új gazdasági évben a sorszámozás 1-től indul. Mostantól a program a nem üres 5. karakterű évekbe való rögzítéskor az E?? és K?? naplókban megpróbálja automatikusan biztosítani, hogy szám ütközés ne forduljon elő, így nem kell új naplókat nyitni, vagy hozzányúlni a szám képzés formátumához (amihez szigorú számadású kimenő naplóban már nem is lehet). Ha a naplófajtáknál tárolt szám képzés formátuma rövidebb volt 10 karakternél, akkor a program a szám képzés formátumában az első # karakter elé beteszi a gazdasági év 5. karakterét, vagyis pl. B??-##### ->       B??-Z#####. Ha a szám képzés formátuma kihasználta a max. 10 karaktert, akkor a program az első # karakter helyére teszi be a gazd. év 5. karakterét, vagyis pl. KH/??-#### ->       KH/??-Z###   (a kiállítható bizonylatok száma így csökken!)
• A Naplófajták beállítása törzsből való kilépéskor a program ellenőrzést végez, és figyelmeztet, ha az       S szám képzésű K?? kimenő naplókban számlaszám ütközésre lát lehetőséget.
• A program szigorú számadású számlázás naplóban nem állít ki a beállított pl.:#### karakterek által meghatározott maximális számot: 9999, hanem figyelmeztet, hogy elértük a maximumot. Új naplót lehet nyitni ilyenkor.
• Rendelés/ajánlat naplókban a felső és lenti fix bekínált bizonylat szöveg fajta beállítható: REND_SZ_Fnnn és REND_SZ_Lnnn ahol nnn a napló kódja.
• Új beállítási lehetőség. Ahol az elektronikus számlák EDI módszerrel készülnek kötelező beállítani: EDI_SZAMLAZA  X
• Figyelem! Az új (kötelezően beépített) NAV online jelentés adatmezők a frissítés során az adatbázis(ok) méretét 5-10%-al növelhetik. Frissítés előtt kérjük, olvassák el, amit a Telepítési útmutatóban ezzel kapcsolatban javaslunk.

• A Gépjárművek törzs kibővült újabb mezőkkel: munkaszám, használja 50kar., vétel dátuma, eladás dátuma, matrica 60kar.
• R/S gomb megnyomásakor a cikkek/sorozatok raktárankénti mennyisége mellett plusz oszlopként a program mutatja a legutolsó sikeresen számított (S) kiadás dátumát, számolt átlag egységárát, valamint a legutolsó beszerzés dátumát, beszerzési egységárát. Így lehetőség van - akár különböző raktárcsoportok használata esetén is - pontosabb adatot látni értékesítéskor, vagy ajánlat/rendelés sor rögzítésekor a cikk aktuális utolsó ismert átlagáráról. Letiltható, ha azt szeretnék, hogy ezt az adatot ne lehessen látni: RS_ARNEMKELL   X
• Késedelmi-kamat terhelő levélen a számlaértékek összege is megjelenik
• Értékesítés 2 időszakra lekérdezésben a vevő adószáma is megjelenik
• Beállíható, hogy új partner felvitele (vagy meglevő partner módosítása) esetén csak akkor engedje azt rögzíteni, ha a partner adószáma ki van töltve, vagy a cégtípusba (Ct.) M kerül(=magánszemély). Beállítása: ADOSZAM_KELL    X
• Új beállítási lehetőség. Ha azt szeretnék, hogy számla, szállítólevél tételsor írásakor a mennyiség változtatásakor a Kedvezmények törzs alapján történő pillanatnyi alap egységár, kedvezmény% és végső egységár mezők számítása csak abban az esetben történjen meg, ha a végső egységár mező nem üres (vagyis jellemzően csak elsőként, a mennyiség később történő változtatásakor már nem), akkor állítsák be: ENG_SZAZ_ELS   X
• Új funkció: A felszólító/egyenlegközlő levél készítésekor eddig is volt lehetőség azt közvetlenül e-mailben elküldeni, de csak szöveges üzenetként és ennek formátuma különbözött a nyomtatott formátumtól, nem volt túl szép, és a 2048 karakteres limit is okozhatott gondot. A PROFIT fejlesztő környezete nem tartalmaz ilyen lehetőségeket, de más gyártó termékével megoldható, hogy PDF csatolmánnyal ellátott e-mailt küldjenek. Az e-mail csak elkészül, de a Küldés-t Önöknek kell megnyomni/indítani. A küldött e-mail az Elküldött elemek mappába kerül. Az ehhez szükséges teendők:
   1.,  A weblapunkon fent levő linkről (Felhasználóinknak/Egyéb/ legalul: http://ftp.eurosoft.org/downloads/PDFCreator-2_4_1-Setup.exe fel kell telepíteni a PDFCreator programot. Ez egy szabadon használható freeware program, amelyet telepítve a nyomtatók közé egy új virtuális nyomtató kerül be, ami nyomtatás helyett .pdf fájlt készít. Minden olyan munkaállomásra egyenként telepíteni kell, ahol használni kívánják. Figyelem! Mivel nem mi készítettük, a használata során esetleg felmerülő problémákért felelősséget sem tudunk vállalni! Megjegyzés: Az asztalon a telepítés után a PDFCreator ikont egyszer elindítva az 'Application settings'-ben a 'Check for updates'-t célszerű 'Never'-re állítani, majd ezt a 'Save'-el menteni, így a felhasználóinknál egységes változat lesz. Már egy éve teszteljük, negatívumot nem találtunk, Live mail és Outlook levelezővel jól működik.
   2.,  A Bizonylat szövegek–be fel kell vinni egy EMAF azonosítójú szöveget, és a tartalma legyen az, amit a e-mail szövegébe szeretnének tenni valahogy így: Tisztelt #1! Ezennel megküldjük Önöknek csatolva a ... Tisztelettel: #2  (A #1 helyére a program írja be a vevő pénzügyese nevét (a #2 helyett a program írja be a felhasználó nevét, de ennek használata nem kötelező, lehet fixen is beírni a küldő nevét.)
   3.,  A csatolt .pdf-eket a program le is tárolja (le kell, mert amíg nem küldik el a levelet, meg van nyitva a fájl). Ha nem állítják külön be, akkor C:\PDF_MENT  mappát próbál létrehozni, de be is állítható: PDF_MENT_MAP meghajtóésmappaútvonala  Ha ez hálózati mappa, akkor ennek az útvonalnak minden munkaállomáson ugyanoda kell mutatnia. A létrejött .pdf fájlok a levelek elküldése után akár törölhetőek is.
   4.,  A partnertörzsben mindenkinél a Kapcs. –ban legyen a Kapcsolattartó neve, ha üres: a program beteszi: Partnerünk  A mail mezőben legyen az e-mail cím.( vagy másik lehetőség, hogy a Pénzügyes személy legyen kitöltve és akkor a személy törzsben legyen a név és e-mail cím, és akkor küldéskor ezt használja). Ezek az adatok a lekérdezés indítása után megjelenő táblázatban még nyomtatás/nyomtatási kép indítása előtt le is ellenőrizhetők.
   5.,  Használat: El kell indítani a szokásos módon a felszólító/egyenlegközlő lekérdezést. Először egyet ki kéne próbálni: Nyomtatási kép / 01-es (első) lista. A kérdésekre: Csak ezt az egyet     PDFCreator email     Elvileg a levelező megnyílik, és a csatolmányban ott a felszólító/egyenlegközlő levél ugyanúgy, mintha nyomtatták volna. Ha törlik a levél kezdeményt, akkor megismételhető. Ha ez működik, akkor óvatosan megpróbálhatják, hogy a távcső/szűrés ikonnal kisebb vevő csoportokat válogatnak le, pl. p_nev   =     A  (‘A’ betűs partnerek), majd ezeket egyszerre e-mailen elküldik (és egyenként a Küldés gombbal el is küldik).
• Új általános funkció: Az aktuális űrlap Nyomtatási kép ikonját jobb egérgombbal indítva egy kérdés jelenik meg: Kér e-mail készítést...? , és minden beépített listánál van lehetőség az adott listát pdf-be nyomtatni, és azt csatolmányként e-mailben elküldeni. (az egyedi, kész ill. saját lekérdezéseknél nem). Számla (másolat) esetében, ill. ajánlat/ajánlatkérés,szállítói rendelés, vevő visszaigazolás esetében a program megpróbálja a küldendő e-mail címzett adatait kitölteni az előzőekben leírt módon, ill. utóbbiak esetében a partner ügyintézője alapján. A levél szövege itt is előre sémaként megadható ha felvisznek egy ?nnn azonosítójú bizonylat szöveget, ahol K: magyar, N:német, A:angol esetben, nnn pedig a napló azonosítója. Itt is lehet a levél szövegben a #1 és #2-t használni.

• A 100000-es ÁFA értékhatár 2018.07.01-re halasztása miatt visszaállítottuk az 1000000 Ft-os értékhatárt
• A személytörzsben a Mobil mező hossza 20 karakterre nőtt 

• Hibajavítás a Könyvelési zárás/nyitás feldolgozásban. Javasoljuk, hogy a 2016-os év zárása/2017 nyitása előtt lehetőleg frissítsenek erre a programváltozatra.

• Új egyedi (saját) lista: ~MAXKESZ Adott időintervallumban készleten levő maximális készletszint listázása (ADR-hez)
• Új banki utalási formátum: S Raiffeisen EUR SEPA xml formátum
• A számlázás (ellenőrzés) módosítása úgy, hogy 2017.07.01 utáni könyvelési dátumú számlák esetén (az eddigi 1 000 000,- helyett) 100 000.- Ft (és azt meghaladó) áfa tartalmú számlát ne engedjen kibocsátani akkor, ha hiányzik a vevő adószáma. Az AFALE_05-ös áfa lista/abev átadás módosítása ugyanúgy, hogy 2017.07.01 utáni könyvelési dátumú számlák esetén (az eddigi 1 000 000,- helyett) 100 000.- Ft legyen az összeghatár.
• Adószám nélküli magánszemélyek esetén a partnertörzsben alul a Ct. mezőbe írjanak M-et (magánszemély), így a program még 100 000,- Ft-ot meghaladó áfa esetén is enged adószám nélkül számlázni, és az ilyen számlák kimaradnak az értékhatárt meghaladó áfa részből is (M lapok)
• Az EDI forgalmi adatfeladás/fogadás módosítása úgy, hogy alkalmas legyen partner adószám feladás/fogadásra is. Új beállítási lehetőség: EDI_*_FOGADA A Ha üres a p_kod (küldő rendszerbeli partnerkód), akkor adószámmal azonosít, ha az üres, névvel

• Új importálási lehetőség: egy bizonylat 'kiadás tételek' ablakában állva egy bizonylathoz plusz készlet kiadás tételsorokat lehet importálni előzőleg a \profit mappába EDI_TETEL.TXT néven excelből 'tabulátorral tagolt szövegfájl' formátumban elmentett fájlból. A mezők kötelező sorrendje: cikkszám, sorozat, raktár, mennyiség, bevét érték(ez itt üres),eladási érték, főkönyv,költséghely, munkaszám, költségnem Előkészítés: a rendszer paraméterekhez egyszer fel kell vinni : EDI_B_FOGADA X A beállítás azonos a bevét tételek EDI beállítással, vagyis a kettőt egyszerre lehet beállítani, és az EDI_TETEL.TXT fájl is azonos. Használat, a kiadás tételek ablakban állva a főmenü/eszközök/EDI fogadása -t kell indítani.
• A tárgyi eszköz modul kiegészült egy új lehetőséggel: Terven felüli értékcsökkenés kezelése. Eddig: nettó=bruttó-eddig elsz.écs volt. Mostantól: nettó=bruttó-eddig elsz. écs-eddig elsz. terven felüli écs. Mivel a frissítés után minden analitikában minden eszköznél a terven felüli écs 0 (üres) értékkel bővül, így az analitika állapota a frissítéstől nem változik meg. Terven felüli értékcsökkenést (annak változását) az Új/'Módosítás' ágon lehet felvinni. Ennek nyilvántartó főkönyvét elegendő akkor megadni, ha a terven felüli értékcsökkenés változik (de ekkor kötelező). A program a rendszer listákon (változási jegyzőkönyv, állapot listák, mozgás lista, t.e. karton) is mutatja már ennek változását illetve kumulált értékét, állapotát is. A program a terven felüli értékcsökkenést a főkönyvi feladásban is feladja a főkönyvnek. Amennyiben a meglevő tárgyi eszköz állományban előfordult már terven felüli écs, és ez a főkönyvben is külön főkönyvön (pl. 148) szerepelt, de kényszerűségből az analitikában az eddig elszámolt écs-ben szerepelt az összege, akkor úgy lehet az analitikát szinkronba hozni a főkönyvvel, hogy az ilyen eszközöknél egy écs elszámolási dátummal - de még az écs elszámolása előtt - Új/'Módosítás'-t kell kérni, és az eddig elszámolt écs-t az eddigi terven felüli écs összegével csökkenteni kell (mínusszal beírni), a terven felüli écs értékét pedig növelni (plusszal beírni). A nettó ettől nem változik. Mivel a program az időszak főkönyvi feladásában ezt a változást is szerepelteti ezért célszerű a TE_M_ééhh vegyes feladási tételben a könyvelési ablakban az F hivatkozási számú sorokat törölni (ezek a terven felüli écs változásának könyvelési sorai, és azért célszerű törölni, hogy ne legyen duplán a pl. 148 -on a terven felüli écs a főkönyvben ha már eleve ott volt). Új/'Áthelyezés' mozgásnál lehetőség van a terven felüli écs nyilvántartó főkönyvének változtatására is, ha volt terven felüli értékcsökkenés és ezt is kezeli a program a főkönyvi feladásban.
• A tárgyi eszközökhöz is lehet dokumentumokat csatolni a Tárgyi eszközök űrlapon.

• A Rendezetlen tételek ablakban a 'deviza egyenleg' oszlop is megjelenik
• A Rendezetlen tételek lekérdezésben a devizás és devizában rendezett számláknál a devizanem és Deviza egyenleg (itt 0 van) oszlopok halvány zöld háttérszínnel jelennek meg.
• A Rendezetlen tételek lekérdezésben (ha M: mindegyiket kérik) a HUF-ban rendezett számláknál a főkönyv, partner, hivatkozás és az Egyenleg (itt 0 van) oszlopok halvány zöld háttérszínnel jelennek meg.
• A T.e.áttekintése (tárgyi eszköz állapot) lekérdezésben a lekért időpontban már nem meglevő (kivezetett) eszközök szürke háttérszínnel jelennek meg
• A Tárgyi eszközök kezelése űrlap lista képernyőjén a legfrisebb állapot szerint már nem meglevő (kivezetett) eszközök szürke háttérszínnel jelennek meg
• A Készlet info/Rendelések ablakban egy új nyomógomb jelent meg: R.kezelés (rendelés kezelés). Ezt megnyomva új ablakban megjelenik az a rendelés, amelynek egy során álltunk. Már csak a Tételek-et kell megnyomni, és a rendelés szükség szerint módosítható vagy akár teljesen új rendelést is lehet rögzíteni.
• A rendelés (ajánlat) tételek űrlapon ha egy tételsoron a rendelés határidejét (vagy ajánlatnál az érvényességet) módosítják, a mentéskor a program megkérdezi, hogy az új határidőt a rendelés többi soránál is módosítsa-e.
• Az alap (1-es) cikk választó listán a jobb oldalon új oszlopként látszik a vámtarifaszám, nettó súly, bruttó súly és a liter (így pl. bevétnél ellenőrizhető, hogy nem hiányos-e)
• Új beállítási lehetőség a Rendszer paraméterekben: TKxxxxxx yyy ahol xxxxx a felhasználó belépési neve (nem a megadható hosszú név) és a tartalomban yyy egy területkód. Ha egy felhasználóhoz ez be van állítva, akkor partner választólistán csak az ilyen trületkódú partnerek jelennek meg számára választásra. A partnertörzset megnyitva is csak ezen területkódú partnereket látja, és új partner felvitelekor is ez lesz a területkód. (A funkció beállításakor a felhasználó számára a partner ? -es keresés /pl. ?euro/ lehetősége megszűnik) Amelyik felhasználóhoz nincs ez beállítva (nincs ilyen sor, vagy a tartalom üres) annál minden partner megjelenik.
• A 'Könyvelési tételek' űrlapon egy új nyomógomb jelent meg: Oszt. Ezt megnyomva az esetleg még fennálló könyvelési eltérést a program ráosztja a tételekre. Az első (fő) sort és az áfa könyvelési sort nem módosítja, csak a többit. Egy pár filléres eltérés így gombnyomásra eltüntethető pl. egy devizás kimenő számlánál, amelynél az automatikus kontírozás után maradhat egy kis eltérés.
• A program alapesetben a készletérték-számítást cikk/sorozat/raktárcsoport bontásban végzi. Megjelent annak a lehetősége, hogy ez cikk/raktárcsoportra történjen, vagyis ne súlyozza, értékelje külön egy cikk egyes sorozatait. Igény esetén erről konzultációt javaslunk.
• A program alapértelmezetten csak a készleteket hozza a készlet listákon, lekérdezéseknél (azon cikkeket, amelyeknél a cikktörzsben a Kk mező üres.) Ha szükséges, ez átállítható úgy, hogy a szolgáltatások is jöjjenek, és ne kelljen mindig a lekérdezésnél átírni a Kk. mezőnél a szóközt %-ra: KK_L_DEFAULT % Ez eddig egy karakteres beállításra működött, mostantól viszont be lehet állítani hosszabban is (pl. [ K]% ennek hatására a készlet listákon a valódi cikkeket hozza (üres) és azokat, ahol a K.k.-ban K van, vagyis a közvetített szolgáltatásokat)
• Könyvelőirodáknak érdekes lehet, hogy - miután 2016-tól minden számlázó program köteles NAV .XML formátumban kiadni a számlákat - a más számlázó programmal készült számlák könyvelési célú beolvasására megnyílt egy olyan új lehetőség, ami talán nem igényel minden esetben egyedi illesztőprogram fejlesztést. Írtunk egy olyan beolvasót, ami a NAV .XML formátumot a PROFIT EDI formátumra konvertálja. Sajnos a beolvasás ettől még nem egyszerű, gond lehet a partnerek azonosítása is. Nagy tételszámú cég könyvelése esetén azért érdemes lehet foglalkozni vele. A letöltésről, az egyszeri beállításról és a használat módjáról kérésre tájékoztatót küldünk mailben.
• Ha a BACKUP_PATH_ beállítás tartalmába ? kerül, akkor a program programindításkor ugyanúgy rákérdez a mentésre, mintha itt egy konkrét mentés útvonal lenne beállítva, csak ekkor az alapértelmezett BACKUP mappába megy a mentés

• A partnertörzsben a mail mező 50 karakterre nőtt.

• http://www.nav.gov.hu/data/cms382357/GYIK_szamlazo_program.pdf A NAV a honlapján megjelent - a számlázással kapcsolatos 'adóhatósági ellenőrzési adatszolgáltatás'-ra vonatkozó közleményben nov. 11-én egyértelművé tette, hogy a jelentésben a cím adatokat megbontva kell jelenteni: kerület,közterület neve, közterület jellege, épület, lépcsőház, szint(emelet), ajtó. Nem tudjuk megítélni ennek fontosságát, a PROFIT programba mindenesetre beillesztettük ezek megadásának lehetőségét olymódon, hogy a lehető legkevésbé érintse a jelenlegi adatbázist, programműködést, egyedi számlaképeket, egyedi fejlesztéseket stb. A partnertörzsben a cím mező változatlan maradt, tartalmában viszont a fenti elemek - már amelyek előfordulnak - a fenti sorrendben kell hogy szerepeljenek. Azon címek esetében, amelyekben egyszer előfordul a következő szövegdarab (kis vagy nagybetűvel): utca,u.,u ,ú.,ú ,ut,út,tér (és nincs Sszint(emelet/Ajtó) a programban nem kell semmmit tenni, a jelentésben az ilyen címeknél (vagyis az előforduló esetek túlnyomó részében) semmi teendő nincs, a program a megtalált szöveg elemet köztér jellegeként és az előtte, mögötte levő részt is a megfelelő helyen jelenti. Ettől eltérő esetben, ill. bármikor, ha Önök úgy gondolják, hogy a köztér jellegének pontos megadása (a jelentés miatt) fontos, akkor a partnertörzsben a cím mezőben a megfelelő részt bal egérgombbal ki kell jelölni (a kijelölt köztér jelleg ekkor kék színű), a jobb egégombbal a mezőn kattintva legördül egy kis menü és ott a bal egérgombbal a 'Kijelölt rész -> Közterület jellege' választással a kijelölés rögzíthető. A mezőt elhagyva a cím megbontás ellenőrizhető. A köztér jellege előtti rész kezelése: A köztér jellege előtti részt (közterület neve) a program ellenőrzi, és amennyiben talál benne ker. szöveg darabot, úgy az ez előtti részt kerület adatként értelmezi. Rendkívül ritka esetben van kerület adat a címben, ha ez (ill. ennek elkülönült lejelentése) fontos Önöknek, akkor kötelezően ezzel kell a címet kezdeni, majd ker. szöveggel lezárni és ezután következhet a közterület neve. A közterület jellege utáni rész kezelése: A közterület jellege utáni részben a házszám következik, majd a program ép. szöveg darabot keres, és ha talál, akkor az előtte levő, szóköz utáni részt épület megjelölésként értelmezi. Amennyiben tehát van épület megjelölés a címben, akkor azt a házszámtól szóközzel kell elválasztani és ép. szöveggel kell kötelezően lezárni. Ezután a program lh. szöveg darabot keres, és ha talál, akkor az előtte levő részt lépcsőház megjelölésként értelmezi. Amennyiben tehát van lépcsőház megjelölés a címben, akkor azt az lh. szöveggel kell kötelezően lezárni. A cím utolsó két eleme a szint(emelet) és ajtó. Amennyiben szint(emelet) és/vagy ajtó előfordul a címben és Önök úgy gondolják, hogy a szint(emelet) ajtó pontos megadása (a jelentés miatt) fontos, akkor a partnertörzsben a cím mezőben a megfelelő szint és ajtó részt bal egérgombbal ki kell jelölni (a kijelölt rész ekkor kék színű), a jobb egégombbal a mezőn kattintva legördül egy kis menü és ott a bal egérgombbal a 'Kijelölt rész -> Szint Ajtó' választással a kijelölés rögzíthető (valójában a program itt csak a kijelölés kezdetét tárolja, az ettől jobbra levő tartalom lesz a Szint Ajtó). A Szint és Ajtó adat egymástól akár szóközzel, akár / (perjel) karakterrel elválasztható, és értelemszerűen az első adat lesz a Szint, az utána levő pedig az Ajtó. A mezőt elhagyva (vagy bármikor később rákattintva és elhagyva) a cím megbontás ellenőrizhető, a program kiírja a pontos megbontást. A Lista képernyőn (a jobb oldalon) a kijelölt közterület jellege valamint Szint Ajtó külön oszlopban látszik, és az olyan címek, amelyeknél van kijelölt adat világosszürke háttérrel jelöltek (így lehet látni, hogy a megbontás már meg lett adva). Számlázáskor a partner kiválasztó ablakban is látszik jobb oldalon külön oszlopokban a kijelölt közterület jellege és a Szint Ajtó. A cím mező fenti korrekcióját, ill. megjelölését a számla elkészítése előtt kell megtenni, a program a számlakészítés pillanatában meglevő állapot szerint jelenti majd a címet, megbontását.
• A Törzsek/Egyéb programok megnyitása/Lekérdezések között (vagy egyszerűbben a jobboldali ábra alatti sárga 'Lekérdezések' -re kattintva) bekerült a 2016-os keltű számlázás esetén a számlázó programba kötelezően beépített 'Adóhatósági ellenőrzési adatszolgáltatás' funkció, jelentő program. A neve a programban: 'Adóhat.ellenőrzési adatszolg'. A feldolgozás varázslót indítva először bekéri a jelentés kötelező indító paramétereit (számla kelte tól/ig és/vagy számlaszám tól/ig). A 'Következő' -re kattintva a program kiírja, hogy hány számlát talált: a jelentésbe a szigorú számadású kimenő számlázás során a 2.08 vagy magasabb programváltozattal készült számlák kerülnek be (a rontottak is, ha használják ezt a funkciót). A számlák egy áttekintő táblázatban kérésre megnézhetők, majd az 'Indít' gombbal a jelentés fájl a programmappába elkészül.A fájl neve: ADOH_cégnév_dátum_idő.XML
• Formai változás: az új rendszer számlariportok alul a riportfájl nevét kiírják.
• Új (kötelező) beállítás: ADOMENTE_HIV tartalmába fel kell sorolni azon adómentes értékesítés áfa kategóriákat, amelyeknél a számlán adómentességre való hivatkozés szerepel 2-2 karakter hosszban vesszővel elválasztva és az utolsó kategóriánál vesszővel lezárva. Az így megjelölt adómentes értékesítések számláinál a jelentésben az Adómentes hivatkozás: true. A beállítást ne változtassa meg, legfeljebb bővítse, ha szükséges!
• Új Elektronikus banki feladás formátum: Deutche Bank HUF formátum.

Kattintson a címre a részletekhez!

• Új mező a cikktörzsben: EKÁER kockázatos: K Ha ezt a mezőt K-val jelölik, ezen cikkek kiadás tételsorai (számlán, szállítólevélen) a képernyőn sötétpiros színnel jelölődnek.
• A közvetített szolgáltatásokat a cikktörzs K.k. mezőjében N helyett kérjük K-val jelölni! (jövő évi jelentéshez)

Kattintson a címre a részletekhez!

• Új beállítási lehetőség: ELOZO_EV_FOR X     Ha beállítják, akkor új szállítói rendelés tételsorsor felvitelekor a cikk kiválasztása után a program a jobb felső sarokban kiírja, hogy az adott cikkből mennyi fogyott az előző évben ugyanezen hónap alatt, és az utána következő hónap alatt.
• A programban lehetőség nyílik 'csomagok' (több kölönböző cikkből álló értékesítési egység) kezelésére úgy, hogy a valódi raktárakban a csomagot kezeljük (vételezzük be, adjuk el), de egy másik beállítható (jellemzően idegenáru) raktárban a program a rész (a csomagot alkotó) cikkek virtuális készletét is vezeti. Előtte a beépülési darabjegyzék (recept) törzsbe az összetételt fel kell vinni. Valódi raktárak: CSO_V_RAKTAR  ???,???,        Virtuális rész raktár: CSO_R_RAKTAR ??? A csomag cikkeknél a cikktörzsben az ADR kat. mezőbe C-t kell írni. A müködés/leltározás ellenőrzését segítő új saját lekérdezés: ~CSOMAGE.FRX
• Különböző hibajavítások (al-ablakok kezelésének javítása, régi adatok törlésénak javítása)
• A Tételes készletforgalom ablakba új oszlopként bekerült a készlet (bevét vagy kiadás) tételsor 'Szöveg' mezőjének első 50 karaktere (kereshetően).
• A korábban a CSO_V_RAKTAR  ???,???,    és  CSO_R_RAKTAR ???  -al beállítható csomag kezelés kiegészítése úgy, hogy az a vevő és szállítói ajánlat/rendelés űrlapok tétel ablakában is működjön. Ezen kívül a szállítói rendelés bevét bizonylaton való teljesítése/bevételezése ill. vevő rendelés szállítólevélen való teljesítése/kiszállítása esetén nem csak a 'csomag' cikk rendelése lesz teljesített, hanem a beépülő 'rész' cikkek rendelés tétele is, automatikusan.

• Cikk kategóriák törzsében a kategória megnevezés hossza 50 karakterre nőtt