Tömeges bejelentés v2.0

A felhasználói igények minél magasabb szintű kiszolgálása elemi érdekünk. Ennek köszönhetően kollégáink a meglévő rendszer stabilitását és felhasználói ergonómiáját folyamatosan javítják. Elkészítették a tömeges bejelentés funkció v2.0-s változatát.

Sok ügyfelünk van, aki nem csak szállítmányonként 40-100 tételt jelent be, de napi 40-100 szállítmánya van. Ők remekül tudták használni Excel betöltőinket illetve egyedi fejlesztésben elkészült tömeges Excel feldolgozóinkat. Az előkészített vagy egy későbbi dátumra ütemezett szállítmányokat azonban csak lassan tudták a NAV felé elküldeni.

 

blockcommand

126 szállítmány bejelentése

A korábbi betöltő maximum 5 (azaz öt) szállítmány kijelölését engedte, amikor a NAV felé zajlott kommunikáció. Ennek egyik oka a NAV szerver kis sebessége volt, a másik pedig a visszajelzés hiánya. Kollégáink ez utóbbit kiküszöbölték: elkészítették a korlátlan szállítmány bejelentésére alkalmas felületet. Ötnél több szállítmányt is kijelölhetünk, amelyeket egy folyamatjelző csíkon kísérhetünk figyelemmel. A NAV szervere nem lett gyorsabb, de a folyamat automatizálhatóvá vált.

Teljesítmény-teszt és sebesség növekedés

Az elmúlt hét péntekén elkezdődtek a teljesítmény-tesztek. Elég felhasználónk gyűlt össze ahhoz, hogy érdemi terhelési teszteket tudjunk végezni. Több, mint 580 ezer áru haladt át eddig a rendszereinken.

Attól, hogy egy rendszer látszólag működik, még nem biztos, hogy minden rendben van a motorháztető alatt (terminus technicus: “under the hood”). Komoly terhelési teszteket végeztünk el, hogy pontosan lássuk, hol vannak a rendszer határai és az automatikus skálázási mechanizmusok valóban valós számok alapján működnek. Sok tesztet futtattunk le, voltak köztük belső rendszeren végzett, több órás folyamatok, de a legvégső tesztet az éles környezeten próbáltuk ki.

Le is térdelt a rendszer…

Server performance

Kevés felhasználónk vehette csak észre, pár másodpercig tartott, de ki kellett próbálni. A rendszer határaink is túlmentünk és megnéztük, mi történik ha… Ha másodpercenként például 500 művelet indul el. Jó hír, hogy a bejövő kapcsolatok nem álltak tömött sorokban, a kiszolgálás lelassult, de csak pár másodpercre állt le teljesen. Ami a legfontosabb: a szerver felett nem vesztettük el az irányítást.

AWS (Amazon Web Services) irányból 200 különböző IP címről érkező kérések közel álltak a valósághoz. A sikerhez szükség volt a hétvégén 80 mérnöki órára, de megérte: a szervereink jól teljesítettek.

Update! Elkezdtük az átállást az 1.9-es NAV verzióra

A NAV pár hete közzétette a programozói interfészének (API) 1.9-es verzióját. Ez pár módosítást, változtatást tartalmaz ugyan, de ez az ekáer-feladas.hu-t nem érinti.

Ugyanakkor a korábbi API-k működését a NAV beszünteti, csak az 1.9-es módszerrel lesz megvalósítható a kommunikáció. Emiatt elkezdtük az új API-ra való átállást, amelyet augusztus 15-ig be is fogunk fejezni. Ügyfeleinket rendszeresen tájékoztatjuk arról, hogy hol állunk, milyen változásokat vehetnek észre a működésben.

A működésbeli változások nem lesznek jelentősek, itt a NAV-val való kommunikáció formátuma változik.

Update!

A változásokat 3 munkanap alatt átvezettük a rendszerünkben, hiba nélkül tudtuk telepíteni az új változatot, ügyfeleink eddig nem jeleztek hibát.

EKÁER: A NÉBIH megnehezíti az EKÁER felhasználók dolgát

EKÁER felhasználóink jelezték, hogy a NÉBIH köteles (Élelmiszerlánc-felügyelet alá vont) termékek szállítása és első lerakodása nem lehetséges, a rendszer nem fogadja el a szabványos EKÁER feladásokat. A hiba előfordul szállítmány létrehozásakor, módosításakor, de akár a véglegesítéskor is, amikor már azt hihetnénk, hogy nem érhet meglepetése, mert a szállítmány indulását az EKÁER még elfogadta.

A felhasználói bejelentések során minden esetben a TC_UNLOAD_ADDR_MUST_BE_REG_IN_NEBIH hibaüzenetre panaszkodtak. Felvettük a NAV-val a kapcsolatot a hibajelentés pontos értelmezése céljából és az alábbi választ kaptuk:

Egy tegnapi frissítést követően változott a Nébih címadatok ellenőrzése, sajnos tájékoztatás híján egyelőre mi sem tudunk pontosat mondani.
A regisztrált Nébih címadatokra ezen a linken tudnak rákeresni: https://portal.nebih.gov.hu/elso-betarolasi-hely-kereso

Az itt szereplő címeket kell 1:1-ben megadni a bejelentésekben, viszont sajnos nem ugyan azokkal az elnevezésekkel operál a Nébih, mint amikkel az EKÁER (egyelőre), így amennyiben elsőre nem sikerül megtenni egy bejelentést, úgy azt tudjuk javasolni, hogy próbáljanak ki minden lehetséges variációt a beviteli mezőkben megadott adatok szempontjából.

A kellemetlenségekért elnézésüket kérjük!

A NÉBIH rendszer az államigazgatás része, de nem a cég/telephely adószáma alapján dolgozik. Ehelyett címadatokat használ, amelyeket – mint az köztudott – sokféle írásmóddal lehet írni (u. vagy utca, stb.)

Kollégáink a hozzánk beérkezett bejelentéseket egyenként megvizsgálták és megpróbálták kitalálni, hogy a címadatok milyen formában adnak találatot a https://portal.nebih.gov.hu/elso-betarolasi-hely-kereso oldalon. Ezek után a címadatokat megpróbálták az EKÁER rendszerbe is hasonló módon berögzíteni. Sikerrel!

Ma reggelre ügyfeleink nagy része sikeresen bejelentette, módosította NÉBIH köteles termékeket is tartalmazó szállítmányait. Akik nem jártak sikerrel, azok számára pedig szintén egyértelmű információ áll rendelkezésre arról, hogy a lerakodási telephely egyáltalán nem rendelkezik NÉBIH engedéllyel.

Angol nyelvű felület

Egyre több külföldi érdekeltségű és/vagy külföldi tulajdonú EKÁER-feladas.hu felhasználó csatlakozik hozzánk. Többen jelezték, hogy nem csak magyar nyelven szeretnék használni a felületet.

Több partnerünk jelezte, hogy az itt dolgozó, külföldi kollégák szeretnének belelátni az EKÁER rendszerbe. Nem minden esetben szeretnének adatot rögzíteni, de a fontosabb riportokat szeretnék látni. Ugyanez igaz a külföldi tulajdonú, magyar leányvállalatokra: az anya cég a webes felületre be tud lépni, de a piktogramokkal tűzdelt felületen nem minden adat egyértelmű azonnal.

Erre kínálunk mostantól megoldást! A felhasználói felületet angol nyelven is elkészítettük. Minden felhasználó beállíthatja magának a kedvenc nyelvét, de amíg ezt nem teszi meg, addig a böngésző/operációs rendszer beállításai lesznek az irányadók. Angol nyelvű Windows-os azonnal az angol felület jelenik meg.

Apróbb hibák

Apróbb hibák előfordulhatnak, ezért elnézésüket kérjük. A nyelvesítés folyamatban van…

Gyűjtőfuvar a gyakorlatban

A 15. § számú rendelet (4)-(6) bekezdésének 2015. június 1-jével történő hatályba lépése lehetővé teszi, hogy egy EKÁER szám alatt, egy szállítmány berkein belül több fel- és lerakodási helyet is érintsünk. A gyakorlatban ennek kezelése és adminisztrációja azonban problémás.

Jogszabályilag a korábbi gyakorlat az volt, hogy az egy járművel szállított, több helyre (fel-/lerakodás) vonatkozó áruszállítás annyi EKÁER számot igényelt, amennyi fel/lerakodási hely szerepelt a fuvarkörben. Ezzel szépen lehetett kezelni a szállítmányokat, több EKÁER szám tartozott egy rendszámhoz, a fuvarozó tudta, hogy mit és hol kell lerakni és mit, mikor kell érkezettnek tekinteni. A való életben nem fordult elő olyan, hogy 4-5 EKÁER számnál több tartozott egy járműhöz egyidejűleg.

3D_truck_graphics

Az új szabályozás lehetővé teszi, hogy EKÁER tételenként adjuk meg a rakodási helyet és egy EKÁER számot kérjünk csak. Filozófiailag jó ötletnek tűnik, a gyakorlatban nehézkes! Pont annyira, mintha egy 100 soros számlát kellene tételenként raktárhoz kötni. Szép megoldás, de használhatatlan, a számla kiállítása alatt a termékek garancia ideje lejárhat. További nehezítő tényező, ha például a felrakodás három helyen, a lerakodás négy helyen történik, minden egyes árutételről meg kellene mondani, hogy honnan-hova tart.

Ügyfeleinknek továbbra is azt javasoljuk és egyedi fejlesztéseink is ezt támogatják: fel/lerakodási helyenként készítsenek egy-egy szállítmányt, azokhoz írják be ugyanazt a rendszámot és egy helyett (akár!) négy-öt EKÁER bizonylatot adjanak a gépjármű vezetőnek. Pontosabb lesz a nyilvántartás és gyorsabb lesz az adminisztráció. Precízebben kezelhető, hogy melyik “szállítmány-rész” ért már oda, mi nincs már a járművön.

Sikeres egyedi fejlesztések

A héten átadtuk a 25. egyedi fejlesztésünket az ekaer-feladas.hu rendszerhez. Több szempontból is a várakozásainkat felülmúló eredmény.

A múlt héten jelent meg a sajtóban, hogy túlléptük a 10Mrd Ft-ot (és majdnem 19e tonnánál jártunk súlyban), amely az automatikus rendszerünk egyik statisztikájából “esett ki” az egyik ellenőrzéskor. Felhasználóinkkal nem kell értékesítési kapcsolatot építenünk, automatikusan épül az ügyfélbázis.

25

átadott egyedi fejlesztés

Előfizetői díjcsomagjaink kialakításakor már figyelembe vettük az egyedi fejlesztések lehetőségét, de havi egy egyedi fejlesztésre számítottunk. A márciusi éles EKÁER indulás óta 25 egyedi Excel betöltőt valósítottunk meg. És ezeket üzemeltetjük azóta is. Összeszámoltuk a programozók által előállított egyedi programsorok számát is:

8540

egyedi programsor

Nézzünk pár példát arra, hogy miket lehet megoldani egyediben. Ezek nagy részére az átlag felhasználó nem is gondol, nem mer ilyenről álmodni:

  • A szállítmány azonosító alapján az Excel adatai alapján több (20-50-100) szállítmány jön létre.
  • A szállítmányok EDT-je (Estimated Delivery Time) beállításra kerül, ez alapján a jövőbe rögzítünk szállítmányokat. A rendszer jelzi a jövőbeni szállítmányokat a beállított napon.
  • Partnerek automatikus létrehozása, frissítése. Akár alábontott telephelyek létrehozása, kezelése.
  • Nem HUF-os áruértékek Forintosítása MNB árfolyamok alapján.
  • Egyedi VTSZ konverzió/korrekció termékkód alapján.
  • Cég-specifikus UN számok kezelése termék információk alapján.

Továbbra is várjuk azokat a megoldási igényeket, amelyeket alaprendszerünkkel (általános Excel feltöltés, szoftveres API) most nem tud megoldani.

Biztonsági előny az automatikus fiók

Több ismerősünktől, partnerünktől kaptunk visszajelzést, hogy a hasznalt****.hu portál múlt heti jelszólopási eseménye komolyan érintette őket. A kellemetlen végeredményhez a csillagok együttállása kellett. Az ekaer-feladas.hu portál biztonsági szintje megvédte volna az áldozatokat?

Mi történt?

Történt ugyanis, hogy a hasznalt****.hu portálon – amelynek majdnem biztos, hogy mindenki a regisztrált felhasználója, aki adott el már hazánkban gépjárművet – biztonsági incidens történt. A felhasználónevek (pontosabban email címek) és a hozzájuk tartozó jelszavak letöltésre kerültek, illetéktelenek kezekben landoltak.

A támadóknak/adathalászoknak nem volt nehéz dolguk, az emberek általában egy jelszót használnak. Ugyanazzal lépnek be a fent említett portálra és a gmail-es postafiókjukba is. A gmail-es email címük pedig adott volt… A támadók a gmail-es fiókok felett “átvették a hatalmat” (sic), jelszót cseréltek és gyakran a nyelvet is átállították, a felhasználói felületet valamilyen nem európai betűkészletre.

Mi lehet a védelem?

Egyrészről cégünk kiemelt figyelmet fordít arra, hogy a jelszavakat ne szövegként, hanem valamilyen hash-elt változatban tárolja. Ám ami ennél fontosabb az az automatikus fiók létrehozás. Felhasználói szempontból nagyon kényelmes, hogy új céges regisztrációkor és új felhasználó meghívásakor sem kell fiókot regisztrálni (email + jelszó + jelszó emlékeztető szöveg + stb.), elég ha egy email címet megadunk. A kényelem mellett fontosabb a biztonság: a mi rendszerünk generálja a 8-12 karakteres, véletlen jelszót, amelyet kiküld az email címre. Így még véletlenül sem lesz a jelszó “ancsa”, “buksi” vagy éppen “1234”. És nem is lesz a postafiókunk webes jelszava sem.

Áprilisi jogszabálymódosítások

Az EKÁER-feladás.hu rendszert a jogszabályváltozásokhoz igazítottuk. Itt a tavasz, a föld napja és az április 1-i EKÁER módosítások is. Hiába az április 1, ezeket komolyan kell venni!

Az elmúlt hónapok teszt- és éles üzeme számos gyakorlati kérdésben felnyitotta a döntéshozók szemét. Több ponton módosítottak és életszerűvé tették a bejelentendő adatok körét és a bejelentés gyakorlatát.

Rájöttek például arra, hogy nem mindig ismert a rendszám, amikor az EKÁER számot igényeljük. Ugyanígy a felrakodás ideje nem mondható meg 100%-osan, mert a szállítmányok (főleg az Import oldal) kezelése nem a mi felügyeletünk alatt zajlik, nincs állandóan rálátásunk a kamionra.

Cégünk az ekaer-feladas.hu-n megpróbálja a NAV-os “hibákra”, hiányosságokra már akkor felhívni az ügyfelek figyelmét, amikor a szállítmány még nem került bejelentésre. Az elő-ellenőrző rendszerünk már a szállítmány kiállítása során figyelmeztet, ha valami nincs rendben, nem logikus vagy kötelező.

Ahogy eddig is, a jövőben is folyamatos fejlesztésekkel követjük a NAV-os jogszabályokat, hogy egy gyorsan és kényelmesen használható rendszerrel szolgálhassuk ki ügyfeleinket.

Ezúton köszönjük ügyfeleinknek a megtisztelő bizalmat és a sok esetben a jogszabályok közös értelmezését!

Jelentős tartalmi változások az EKÁER-ben

2015. április 1-ével a következő változások álltak be a NAV EKÁER bejelentő rendszerében:

Egyszerűsített bejelentés

Hatályba lép az egyszerűsített adattartalmú bejelentési lehetőség, amely kizárólag nem kockázatos termékek szállítása esetén alkalmazható. Egyszerűsített bejelentésre azok a gazdálkodók jogosultak,

  • akik szerepelnek köztartozásmentes adózói adatbázisban;
  • bejelentés időpontjában nem állnak adószám felfüggesztés hatálya alatt;
  • az árbevételre vonatkozó feltételeknek

A fenti árbevételi feltételek vonatkozásában új felület („Ügyfél” menüpont) kerül kialakításra, amelyen (a kapcsolattartási adatok karbantartása mellett) a bejelentésre kötelezett adózó elsődleges felhasználó megjelölheti, hogy mely jogszabályi feltételnek felel meg. Az utolsó két – 6. § (2) bekezdés ab) pontja és a 6. § (3) bekezdés – árbevételi feltétel választása esetén a további belföldi adószámok megadása is szükséges. Legalább egy adószám megadása kötelező, hiányában hibaüzenetet ad a felület. Egyszerűsített bejelentés rögzítésére az adott ügyfélre alkalmazható jogszabályi hivatkozás kiválasztását követően kerülhet sor.

EKAER-feladas.hu-t nem befolyásolja. Eddig is, ezután is a nagy mennyiségben, tömegesen feladott, szabályosan kitöltött szállítmányokra koncentrálunk. Az egyszerűsített bejelentés tételeket nem is tartalmaz. Várhatóan rövid időn belül megszűnik.

Címadatok megadása

  1. Kötelezővé válik a Feladó és a Címzett adószámának és nevének megadása.
  2. Amennyiben a Feladó vagy a Címzett belföldi gazdálkodó, akkor a Feladó/Címzett címadatainak kitöltése is kötelező. Felületen az adószám megadásával az adatok automatikusan töltődnek, interfész kommunikáció esetén kötelező az érintett rovatok megadása.
  3. A Feladó és a Címzett adatai esetén is lehetőség van „kedvenc cím” listából történő kiválasztására.

Kockázatos termék – élelmiszer – Európai Unió tagállamból történő behozatala esetén kizárólag az 3/2010 (VII. 5.) VM rendelet alapján bejelentett első magyarországi tárolási hely adható meg a kirakodás címeként. Kirakodás címadatoknál meg fog jelenni egy új keresőmező, melynek segítségével a cím kereshető a NÉBIH adatok között.

Az eddigi egyszerűsítés most ismét bonyolulttá válik. Nehezen beszerezhető külföldi adószámok okozhatnak problémát.

Címzetti bejelentés

Kizárólag nem kockázatos termék belföldi viszonylatú szállítása esetén lehetővé válik a Címzett általi bejelentés. „Belföld–belföld” viszonylat választásakor megjelenik egy „Igen/Nem” kérdés, hogy címzettként kíván-e bejelentést tenni a felhasználó. „Igen” választása esetén a címzett adatok automatikusan feltöltésre kerülnek a bejelentkezett ügyfél adataival. Interfész kommunikációban külön mező szolgál a címzetti bejelentés jelölésére, amit belföld-belföld esetében kötelező megadni.

Ismét egy pont, amely a rendszert alapjaiban “rengeti meg”. Senki nem fogja érteni, hogy akkor honnan hova megy a szállítmány, ki a felelőse annak, hogy a bejelentés megtörténjen. Lassan eljutunk odáig, hogy a feladónak és a címzettnek is egyöntetűen kell bejelentenie egy szállítmányt.

Módosítás indoklása

A bejelentőknek minden egyes adatmódosítás (pl. súly, érték, rendszám változása) alkalmával kötelezően meg kell adni a módosítás indokát egy módosítás megjelenéskor felugró szabad szöveges mezőkben. Az adott tételhez tartozó módosítások időrendben – dátum óra, perc jelölésével – megjelennek egy módosítási listában, amely a felületről menthető.

Várható volt a módosítás, mert a közigazgatás minden információt szeretne tudni (ki, mit, miért). Az ezzel járó adminisztratív terhet pedig figyelmen kívül hagyják. Az EKÁER-feladas.hu rendszer tételeket nem módosít, azokat minden esetben törli és új tételként küldi be. Így a módosításokat nálunk NEM KELL indokolni.

A fenti módosítások a mai napon életbe léptek, az EKÁER-feladás.hu informatikai rendszer illesztése folyamatban van.