Túl a kötegen: valós idejű kincstár és adó ERP és bankok között

Húsz éven át a vállalati pénzügyek egy késleltetéssel éltek együtt. Az ERP (SAP S/4HANA, Oracle vagy Odoo) lezárta a napi könyvelést. Egy ütemezett feladat egyszerű CSV- vagy MT940-fájlokat küldött a banknak SFTP-n. A csapat másnap reggelig várta, hogy megtudja, mit fogadott el a bank, és mi nem sikerült.

Ez a munkamód egyre kevésbé működik a GCC-országokban, Európában, a Közel-Keleten és Afrikában. Két változás tette a kötegfájlokat közvetlen üzleti kockázattá.

Miért nem működnek tovább az éjszakai fájlok

• Az adót már valós időben ellenőrzik. Szaúd-Arábia ZATCA 2. fázisa, az Egyesült Arab Emírségek PINT-AE keretrendszere és az EU ViDA (VAT in the Digital Age) szabályozása szerint minden számlát XML-ként kell érvényesíteni és kriptográfiai bélyegzővel ellátni, valós időben vagy ahhoz közel, mielőtt jogilag kibocsátják vagy elszámolják.

• A fizetések már gazdag adatokat hordoznak. Az ISO 20022 a rövid hivatkozási mezőket teljesen strukturált közleményadatokkal váltja fel, a fizetési utasításokban (pain.001) és a készpénzkezelési üzenetekben (camt.053 és camt.054).

Amikor a vállalatok valós idejű adójóváhagyást és ISO 20022-t tesznek a régi kötegelt middleware fölé, az eredmény úton rekedt pénz, kézzel végzett egyeztetés és olyan számlázás, amely minden sikertelen ellenőrzésnél megáll.

Miért nem elegendőek a szabványos összekötők éles környezetben

A szabványos integrációs összekötők jól kezelik az egyszerű esetet. Arra nem épültek, hogy a pénzügyi nyilvántartásokat konzisztensek tartsák, amikor egyszerre több ezer tranzakció érkezik. Egy régóta működő vállalatnál három probléma jön elő újra és újra:

• Adatvesztés a leképezésben. Az egyedi ERP-táblák ritkán képezhetők le tisztán a szigorú ISO 20022-sémákra vagy az UBL 2.1 e-számlákra egy gondos, szabályalapú leképezési réteg nélkül.

• Duplikátumok újrapróbálkozáskor. Amikor egy bank vagy adóátjáró terhelés alatt időtúllépést ad, egy egyszerű újrapróbálkozás ugyanazt a fizetést kétszer küldheti el, vagy ugyanazt a számlát kétszer nyújthatja be.

• Két rendszer, két igazság. Az ERP könyveltként jelöli a számlát, miközben az adóhatóság elutasítja a bélyegzését. A pénzügyi csapat kézzel sztornózza a tételeket olyan rendszerek között, amelyek nem beszélnek egymással.

Hogyan építjük meg

Az XSIS-nél az integrációt mérnöki munkának tekintjük, nem konfigurációnak. Egy megbízható valós idejű kincstári és megfelelőségi motor négy részből áll.

1. Minden esemény egyszeri rögzítése

Nem kérdezzük le folyamatosan az ERP-adatbázist. Minden változást rögzítünk, amikor megtörténik, tranzakciós outboxon vagy az ERP saját eseményhálóján keresztül. Minden pénzügyi esemény stabil kulcsot kap aszerint, honnan érkezett a dokumentum, így pontosan egyszer dolgozzuk fel a banki és adórendszerek között.

2. Ellenőrzések, mielőtt bármi elhagyja a rendszert

Mielőtt egy üzenet elér egy bankot vagy adóportált, külön érvényesítő motor ellenőrzi az XML-t a sémája szerint, alkalmazza a kriptográfiai aláírást (CSID vagy X.509), és elkészíti a szükséges QR-kódot és hash-láncot. Mindez kevesebb mint 50 ezredmásodperc alatt megtörténik.

3. Egy belső formátum minden bankhoz

Az ERP és a külvilág között verziózott belső adatmodell áll. Egy új bank hozzáadása vagy az MT-ről MX-üzenetekre való áttérés nem jelenti ABAP- vagy PL/SQL-kód újraírását az ERP-ben.

4. Banki kivonatok automatikus egyeztetése

A banki kivonatokat (camt.053) és az azonnali fizetési értesítéseket (camt.054) világos szabályok alapján olvassuk be, és a nyitott követelésekhez egyeztetjük. A tételek több mint 99%-a kézi lépés nélkül egyeztethető, és csak a valódi kivételek kerülnek emberhez.

Hol kezdje

Nem kell lecserélnie az ERP-jét a kötegelt késések megszüntetéséhez. Kezdje a Brownfield Diagnostic Bridge nevű diagnosztikánkkal: 1 vagy 2 hét alatt feltérképezzük, hol vész el adat az ERP-je, a middleware és a bankjai között. Ezután először a legfájdalmasabb egyeztetési köröket állítja át valós idejűre.