EKÁER 2016-os deviza árfolyamok

Kevesen tudják, de az EKÁER jogszabály rendelkezik róla, hogy a külföldi, devizában nyilvántartott beszerzéseket és áruszállítások milyen rögzített árfolyamon kell Forintosítani.

Sokan azt gondolják, hogy az aktuális napi (szállítás indulási napja) MNB vagy banki árfolyam alkalmas arra, hogy a devizában beszerzett árut Forintosítsuk és bejelentsük az EKÁER rendszerbe. Pedig az EKÁER törvénytár pontosan leírja, hogy melyik évben milyen árfolyamot kell alkalmazni. A 5/2015. (II. 27.) NGM rendelet 17. § (5) alapján minden évben az előző év december 31-ig MNB középárfolyam az irányadó 365 napon keresztül.

Ez a 2016-os évben: 313,12 Ft/EUR árfolyamot jelent.

Felhívjuk ügyfeleink figyelmét, hogy a fenti jogszabály betartása és a jogszabályi változások követése az ügyfelek feladata.

Egyszerűsített díjfizetés

Rendszerünknek sok előfizetője van, ők az EKÁER megoldásunkat folyamatosan használják. Az első előfizetőknek már a 10. díjbekérőt állítjuk ki. Többen kérdezték, hogy hogyan lehetne egyszerűbb? Az EKÁER-feladás.hu rendszert folyamatosan használó ügyfeleink díjfizetését szeretnénk megkönnyíteni…

Nagy cégek használják rendszerünket, napi több száz szállítmányt adnak fel, öt-hat kolléga párhuzamosan dolgozik a rendszerben. Minden pontosan és gyorsan megy. Kivéve a számlázást. Cégünk, az ügyviteli rendszerek értékesítése kapcsán bevezette a díjbekérőn keresztüli pénzmozgást. Minden esetben díjbekérőt küldtünk, az összeg beérkezése után állítottuk ki a számlát. És mindezt minden hónap 22-én.

Az EKÁER felhasználók között azonban sok a külföldi céges partner. Ők nem értik, nem szívesen használják a díjbekérőt. Bizalmi elvek mentén gondolják a B2B együttműködést. Mostantól mi is bizalmat szavazunk nekik! Folyamatosan, legalább három hónapig rendben fizető ügyfeleinknek elérhetővé tesszük az azonnali számlázást és a több hónapos díj egyben rendezését. Mert partnereink is megbíznak bennünk!

Ezzel két problémára is megoldást nyújtunk:

  1. A díjbekérőt nem kell pénzügyileg a folyamatokba beilleszteni. Többen előleg számlaként rögzítik, költséghelyre könyvelik. Pedig ez nem is előlegszámla.
  2. A külföldi partner díjfizetési is gyorsan ideér. A külföldi anyavállalat “hetente egyszer tud” utalni, gyakran kicsúsztunk a heti utalásból a 8 napos fizetési határidővel.

Kérjük ügyfeleinket, hogy ha havidíjas előfizetésükkel kapcsolatban változtatnának a módszereken, azt jelezzék e-mailben ügyfélszolgálatunknak:

  • Díjfizetés gyakorisága: 1-3-6 hónap
  • Azonnali számlakiállítás igénye.

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.