A kimenő számlák migrációjánál szerencsés helyzetben voltunk, mert rendelkezésünkre állt egy olyan adatforrás, amelyet hitelesnek és teljesnek tekinthettünk: a NAV Online Számla rendszer.
Ha egy számla szerepel a NAV adatbázisában, akkor az a gyakorlatban azt jelenti, hogy azt a vállalkozás valóban kiállította és beküldte. Éppen ezért nem a régi Odoo 12 adatbázis-exportot tekintettük elsődleges forrásnak, hanem közvetlenül a NAV adataiból építettük fel az importot.
Első ránézésre ez egyszerű feladatnak tűnhet. Valójában azonban nem a számlák beolvasása jelentette a kihívást, hanem azok a kivételes esetek, amelyekkel egy több éve működő rendszerben elkerülhetetlenül találkozik az ember.
Sztornó- és módosító számlák
A NAV természetesen tartalmazza a sztornó- és módosító számlákat is.
Ezek azonban önmagukban nem értelmezhetők. Egy sztornó számla csak akkor "jó", ha automatikusan megtalálja az eredeti számláját, és a két bizonylat együtt alkot egységet.
Ha ez a kapcsolat hibás vagy hiányzik, akkor a partner egyenlege is hibás lesz, ezért az importernek automatikusan fel kellett ismernie és össze kellett kapcsolnia ezeket a dokumentumokat.
Nulla összegű számlák
Ritkán fordulnak elő, de léteznek.
Sok importáló egyszerűen figyelmen kívül hagyja őket, vagy hibával leáll. Mi azt szerettük volna, hogy minden, a NAV-ban szereplő bizonylat bekerüljön az Odoo-ba, ezért ezek kezelésére is külön logikát kellett készítenünk.
Kerekítési eltérések
A fejlesztés során találkoztunk néhány olyan számlával, ahol a NAV-ból érkező adatok és az Odoo által számított összegek között néhány filléres eltérés jelentkezett.
Elsőre azt gondoltuk, hogy ezt egyedi programlogikával kell majd kezelnünk, ezért több lehetséges megoldást is kipróbáltunk.
Végül kiderült, hogy erre nincs szükség.
Az Odoo megfelelő kerekítési beállításainak alkalmazásával, valamint a magyar NAV-konnektor működésének pontos megértésével sikerült teljesen megszüntetni ezeket az eltéréseket. Az import így már külön fejlesztés nélkül is megbízhatóan működött.
Ez jó példája annak, hogy egy migráció során nem minden problémára egyedi fejlesztés a legjobb válasz. Sokszor fontosabb a rendszer működésének alapos megismerése és a meglévő lehetőségek megfelelő alkalmazása.
Időszaki elszámolású számlák (Áfa tv. 58. §)
Ez jelentette számunkra a legösszetettebb feladatot.
Nyomtatóbérlési üzletágunkban egyetlen számlán egyszerre szerepel a havi bérleti díj és az előző időszakban mért nyomatszám alapján számított üzemeltetési díj.
A két tétel ugyanazon a számlán jelenik meg, mégis eltérő üzleti logikát követ. A bérleti díj mindig az aktuális időszakra vonatkozik, míg a fogyasztás jellemzően az előző hónap teljesítése alapján kerül elszámolásra.
Szerencsére az Odoo ezt a működést alapvetően támogatja. A feladat inkább az volt, hogy az import során a NAV-ból érkező adatokból helyesen építsük fel a számlát, úgy, hogy a teljesítési dátumok, az időszakok és a számlasorok az új rendszerben is ugyanazt a pénzügyi és üzleti jelentést hordozzák, mint az eredeti rendszerben.
Ez különösen fontos, mert ezekre a számlákra épülnek a bérleti szerződések, a fogyasztási kimutatások és a későbbi vezetői riportok is.
Nem csak egy importáló program készült
A fejlesztés végére az importer már nem csupán adatokat töltött át, hanem képes volt kezelni azokat a valós üzleti helyzeteket is, amelyek egy több éve működő vállalkozás számlázásában természetes módon előfordulnak.
Számunkra ez volt a projekt egyik legfontosabb tanulsága: egy jó migráció nem attól lesz sikeres, hogy "átmásolja" az adatokat, hanem attól, hogy azok az új rendszerben is ugyanúgy viselkednek, mint korábban.
Eredmény
Importált számlák: [55] db
Feldolgozási idő: [1] perc
Kézi javítást igénylő esetek: [0] db
Nem a hibamentes statisztikára törekedtünk.
Sokkal fontosabbnak tartottuk, hogy minden rendellenesség látható legyen, és csak az kerüljön automatikusan importálásra, amiben valóban biztosak lehetünk. Egy migráció során a csendben elrejtett hiba sokkal veszélyesebb, mint egy jól dokumentált figyelmeztetés.
Az importer futásának összesítő képernyője. Jól látszik az importált bizonylatok száma, a feldolgozás eredménye és a hibalista. A hibák szándékosan nincsenek eltüntetve: egy valós migráció ritkán zajlik teljesen hibamentesen, és éppen ezek a kivételek segítenek abban, hogy a végeredmény valóban megbízható legyen.