Rendszerintegráció: számlázó, CRM és ügyvitel összekötése

A rendszerintegráció azt jelenti, hogy a számlázó, a CRM, az ügyviteli rendszer és a bank adatai átgépelés nélkül jutnak el egymáshoz. Öt bevett minta közül választhatsz: közvetlen API-hívás, webhook, ütemezett szinkron, fájlcsere és köztes réteg. A döntés két kérdésen múlik: mennyire friss adat kell, és ki veszi észre, ha valami elakad.

Ez a cikk a cégen belüli rendszerek összekötéséről szól. A webshopos rendelés útját a számlázóig külön írtuk le: webshopautomatizáció rendeléstől a számlázásig.

API-hívás: amikor azonnal kell a válasz

Az egyik rendszer a másik programozói felületén (API) keresztül kérdez vagy ír, és azonnal választ kap. Így működik például a Számlázz.hu Számla Agent: a küldő rendszer HTTP POST kérésben XML-t küld a számla adataival, a szolgáltatás elkészíti a dokumentumot, és visszaküldi a PDF-et.

Az API-hívás akkor jó, ha a folyamat következő lépése a válaszra vár. Ha viszont a túloldal lassú vagy nem érhető el, a hívó félnek kell eldöntenie, mi legyen a kéréssel.

Webhook: amikor a másik rendszer szól

Webhooknál nem te kérdezel rendszeresen, hanem a forrásrendszer hív meg egy általad megadott címet, amikor valami történik. Egy CRM szólhat például, ha új ügyfél kerül be, egy fizetési szolgáltató pedig, ha egy fizetés sikerült.

A HubSpot dokumentációja szerint nem garantált, hogy az értesítések a bekövetkezés sorrendjében érkeznek, és az sem, hogy egy eseményről csak egyet kapsz. A Stripe ugyanezt írja, és azt kéri, hogy a végpont gyorsan válaszoljon, a lassú feldolgozás pedig csak utána fusson.

Mindkét szolgáltató aláírja az értesítést. Ellenőrzés nélkül bárki küldhet hamis eseményt a végpontra, és elindíthat vele egy folyamatot.

Ütemezett szinkron: amikor elég óránként vagy naponta

Itt egy időzített feladat adott időközönként lekérdezi a változásokat, és átvezeti őket. Egyszerűbb megépíteni és hibát keresni benne, cserébe az adat jellemzően egy ütemezési ciklusnyit késik.

Riportokhoz, törzsadat-egyeztetéshez és éjszakai zárásokhoz jó választás. A feladat csak a legutóbbi sikeres futás óta változott tételeket kérje le, és ha egy futás elhúzódik, a következő ne induljon el mellette.

Számolj a forgalomkorlátozással is. Sok API 429-es kóddal jelzi a túl sok kérést, és a Retry-After fejlécben megadhatja, mennyit várj a következő kérésig.

Fájlcsere: a bank és a régebbi rendszerek nyelve

Sok rendszer ma is fájlban adja ki és fogadja az adatot: CSV-export, XML, bankkivonat. A bankkivonatnak nemzetközi szabványa is van: a holland pénzforgalmi szövetség leírása szerint a camt.053 az ISO 20022 szabvány üzenetformátuma a napi bankkivonatok digitális cseréjére.

Fájlcserénél előre dönts arról, hogyan ismered fel, hogy egy fájlt már feldolgoztál. Ha ugyanaz a kivonat kétszer kerül be, az ügyviteli rendszerben duplán jelenhetnek meg a jóváírások.

Bankadat API-n: hozzájárulással és szűk körben

A bankszámla adatai harmadik félen keresztül is elérhetők lehetnek. A PSD2 irányelv 67. cikke szerint a számlainformációkat összesítő szolgáltató csak az ügyfél kifejezett jóváhagyásával nyújthat szolgáltatást, és csak a megjelölt fizetési számlák adataihoz férhet hozzá.

Ha egy integráció ezt az utat használja, a hozzájárulások nyilvántartása is a folyamat része, nem egyszeri beállítás.

Köztes réteg: amikor több rendszer beszél egymással

Három-négy rendszernél a pontról pontra húzott kötések gyorsan áttekinthetetlenné válnak. Köztes rétegnél minden rendszer csak egy központi szolgáltatással beszél, amely átalakítja, sorba állítja és továbbítja az adatot.

A Stripe is azt javasolja, hogy a beérkező eseményeket aszinkron sorból dolgozd fel, mert egy hirtelen csúcs túlterhelheti a végpontot. A köztes réteg előnye, hogy a naplózás, az újrapróbálás és a hibaértesítés egy helyen van. Hátránya, hogy maga is üzemeltetendő rendszer lesz.

Dupla futás elleni védelem

Hálózati hibánál a küldő nem tudja, megérkezett-e a kérése. Az RFC 9110 szerint a kliens egy nem idempotens kérést lehetőleg ne ismételjen automatikusan, hacsak nem tudja, hogy az ismétlés ugyanazt a hatást váltja ki, mint egyetlen futás, vagy hogy az eredeti kérés nem hajtódott végre.

Számlázásnál egy vakon ismételt kérés két számlát jelenthet. A Stripe ezt idempotenciakulccsal oldja meg: az azonos kulccsal ismételt kérés az első kérés eredményét kapja vissza, nem hoz létre új objektumot.

Webhooknál a Stripe azt javasolja, hogy naplózd a feldolgozott események azonosítóját, és ezeket ne dolgozd fel újra. Ugyanez a szabály minden integrációban működik: minden tételnek legyen egyedi azonosítója.

Példa: a NAV Online Számla

A NAV interfészleírása jól mutatja, mire kell felkészülni. A számlaadatok feldolgozása aszinkron: a beküldésre tranzakcióazonosító jön vissza, és az adatszolgáltatás addig nem teljesített, amíg a kliens meg nem kapta a számlához tartozó nyugtaüzenetet.

Ha 60 másodpercen belül nem jön válasz, az még nem jelent sikertelen beküldést. A leírás szerint ilyenkor elfogadott megoldás, hogy a számlázó 5 percet vár, lekérdezi az elmúlt időszak tranzakcióit, és csak akkor ismétel, ha nincs köztük ismeretlen.

A NAV szerint ez csak akkor jogszabályszerű, ha nincs benne emberi közreműködés, és az ütemezést szoftverlogika végzi. Minden kérésnek egyedi azonosítója (requestId) is van, és egy sikeresen feldolgozott kérés azonosítója az adott adózónál nem használható fel újra.

Hibakezelés: újrapróbálás és riasztás

Az átmeneti hiba, például időtúllépés vagy túlterhelés, mást kíván, mint a tartalmi hiba, például hiányzó adószám vagy rossz formátum. Az elsőt érdemes növekvő szünetekkel újrapróbálni, a másodikat embernek kell látnia.

A webhook-szolgáltatók maguk is így dolgoznak. A Stripe éles módban legfeljebb három napig próbálja újra a kézbesítést, exponenciálisan növekvő szünetekkel, a HubSpot 24 órán belül legfeljebb tízszer.

Ami az újrapróbálások után sem ment át, ne tűnjön el csendben. Kerüljön külön hibalistára, és menjen róla értesítés annak, aki dönteni tud.

Naplózás: mit írj fel, és mit ne

Minden futásról látszódjon, mikor, melyik rendszerben, ki indította, melyik tételre és milyen eredménnyel. Az OWASP naplózási útmutatója is erre a négy kérdésre épít: mikor, hol, ki, mi.

Ugyanez az útmutató felsorolja, mi ne kerüljön közvetlenül a naplóba: hozzáférési tokenek, jelszavak, adatbázis-kapcsolati adatok, titkosítási kulcsok, bankszámla- és kártyaadatok, érzékeny személyes adatok. Integrációnál ez gyakori hiba, mert a teljes kérést naplózni kényelmes.

Gazda: kié az integráció?

Az integráció két rendszer határán él, ezért könnyen gazdátlanná válik. A számlázó szolgáltatója a saját oldaláért felel, a CRM-é a sajátjáért, a köztük futó folyamatért viszont senki, amíg ki nem jelölitek.

Írásban rögzítsétek, ki kapja a hibaértesítést, ki fér hozzá a naplóhoz, ki cseréli a lejáró kulcsokat, és ki teszteli az összekötést, ha valamelyik rendszer frissül.

Hogyan kezdj hozzá

1. Folyamattérkép: melyik adat honnan hová megy, milyen gyakran, és ki használja.
2. Mintaválasztás: azonnali válaszhoz API vagy webhook, napi frissességhez ütemezett szinkron, ahol csak export van, ott fájlcsere.
3. Ismétlésvédelem: egyedi azonosító minden tételre, és ellenőrzés írás előtt.
4. Hibalista és napló: értesítéssel, titkok nélkül.
5. Gazda és teszt: kijelölt felelős, próba hibás és dupla adatokkal is.

Ha nem magad raknád össze

A Brauniq üzleti folyamatok automatizálásával és rendszerek összekötésével is foglalkozik, a tervezés, a fejlesztés, az üzemeltetés és a támogatás nálunk egy kézben marad. Ha érdekel, hogyan nézne ki ez nálad, nézd meg a folyamatautomatizálási szolgáltatásunkat.

Források

• NAV Online Számla: interfészleírás és fejlesztői dokumentáció, v3.0 (2026.02.12.), NAV GitHub-tároló
• Számlázz.hu: Hogyan működik a Számla Agent?
• HubSpot Developers: Webhooks API
• Stripe: Receive Stripe events in your webhook endpoint
• Stripe API: Idempotent requests
• RFC 9110, HTTP Semantics, 9.2.2 Idempotent Methods
• RFC 6585, 4. 429 Too Many Requests
• (EU) 2015/2366 irányelv (PSD2), 67. cikk
• Betaalvereniging Nederland: camt.053
• ISO 20022: Bank-to-Customer Cash Management üzenetcsalád
• OWASP Logging Cheat Sheet