A Billingo és a webshopod összekapcsolásakor azt kell ellenőrizni, hogy a megfelelő rendelési eseménynél, helyes adatokkal készül-e bizonylat, és mi történik sikertelen vagy megszakadt folyamat esetén. A Billingo webshopintegráció csak akkor tehermentesít, ha a hibákat is kezelni tudod. A számlázás automatizálása nem pusztán egy bővítmény bekapcsolásából áll.
Az alábbi útmutató azt mutatja meg, mit érdemes előre tisztázni WooCommerce vagy más webshoprendszer és a Billingo összekötése előtt.
Kész Billingo-modult használj, vagy egyedi integrációt?
Elsőként ellenőrizd a Billingo hivatalos fejlesztői és integrációs dokumentációját, valamint a választott webshopmotorhoz elérhető támogatott megoldásokat. Kész bővítménnyel gyorsabban megvalósítható lehet a kapcsolódás, de nem biztos, hogy minden speciális rendelési szabályt lefed.
Egyedi integráció akkor lehet indokolt, ha különleges jóváhagyási folyamat, több számlázási logika, saját rendeléskezelő vagy más, dokumentált API-n keresztül elérhető funkció szükséges. Mindkét esetben ellenőrizni kell a verziót, a frissítési felelőst, az API-előfizetés feltételeit és a hibák követhetőségét.
A számlázási eseményt pontosan határozd meg
Az a kérés, hogy „minden rendelés után készüljön számla”, még nem elég részletes. Más az előre fizetett rendelés, az utánvét, a banki átutalás, a sikertelen kártyás tranzakció és a részleges visszatérítés kezelése. A bizonylat típusát és kiállításának időzítését a könyvelővel és az adott működéssel összhangban kell meghatározni.
- Indító esemény: pontosan mely rendelési vagy fizetési státusznál történjen a művelet?
- Adatmezők: vevő, cím, adószám, pénznem, termékek, kedvezmények és szállítás.
- Visszajelzés: hogyan kerül vissza a bizonylatazonosító a rendeléshez?
- Hibakezelés: mi történik hiányos adat vagy elérhetetlen API esetén?
- Értesítés: a számlázó vagy a webshop küldje a vásárlói üzenetet?
Fontos, hogy egy megismételt esemény ne hozzon létre véletlenül második számlát ugyanarról a műveletről. Ehhez érdemes nyilvántartani a rendelés és a bizonylat közti kapcsolatot, és előre megtervezni az ismétlések kezelését.
Billingo és WooCommerce: hol szokott elcsúszni az összekötés?
WooCommerce esetén ne csak az API-kulcs meglétét ellenőrizd. Nézd meg, hogyan alakul a rendelés státusza sikeres és sikertelen fizetésnél, melyik modul kezeli a visszatérítést, és milyen adatokból számolja a rendszer a végösszeget.
A kuponok és a szállítási díjak különös figyelmet érdemelnek. Egy teljesen megfelelőnek tűnő normál rendelés mellett a kedvezményes kosár már eltérést eredményezhet. A számlázási tesztet ezért többféle rendelési típussal futtasd le.
Indulás előtti számlázási ellenőrzőlista
- Alaprendelés: ellenőrizd az adatokat és az összegeket.
- Kuponos rendelés: egyezzen a kedvezmény, a szállítás és a végösszeg.
- Sikertelen fizetés: ne induljon el téves, sikeres fizetéshez kötött bizonylatolás.
- Ismételt visszajelzés: ne keletkezzen indokolatlan duplikáció.
- API-hiba: legyen napló, jelzés és biztonságos újrapróbálás.
- Módosítás és visszatérítés: a jóváhagyott bizonylati folyamat szerint történjen.
Ha a próba valós bizonylat kiállításával járna, még a teszt előtt egyeztesd annak kezelését. A technikai ellenőrzés nem helyettesíti a számviteli és adózási szabályok szakmai felülvizsgálatát.
Mit ellenőrizz a számla adataiban?
Az automatikus bizonylatkészítés nem csak annyiból áll, hogy a webshop elküldi a vásárló nevét és a végösszeget. Dönteni kell arról is, hogy a szállítási költség, a kedvezmény, a különböző adózási tételek, a cégadatok és az egyedi fizetési módok milyen mezőkbe kerülnek. Érdemes a rendelési adatokból és a kiállított bizonylatból ugyanazokat a mintavásárlásokat egymás mellett ellenőrizni.
Külön figyelmet igényel a magánszemély és a vállalkozás nevében vásárló ügyfél. Egy céges megrendelésnél például szükség lehet adószámra, de a kötelező mezők és az adózási szabályok nem minden vásárlási helyzetben azonosak. A megfelelő bizonylat típusát és tartalmát könyvelővel vagy adótanácsadóval is érdemes egyeztetni. A technikai összekötés csak a jóváhagyott üzleti és számviteli szabályok végrehajtására alkalmas.
Ha digitális terméket vagy külföldre is értékesítesz, a rendelésből kiinduló bizonylatolás újabb eseteket hoz. Ezeket nem szabad egy általános „áfakulcs” beállítással elintézni. Előbb rögzíteni kell, milyen országokba, milyen ügyféltípusoknak és milyen termékeket értékesítesz; utána lehet a számlázó kapcsolatát ennek megfelelően megtervezni.
Hogyan kezeld a megszakadt kapcsolatot és a dupla eseményeket?
Tegyük fel, hogy a vásárló sikeresen fizet, de a webshop a Billingo API válaszát hálózati hiba miatt már nem kapja meg. Ha a rendszer ilyenkor azonnal újra elküldi ugyanazt a számlázási kérést, fennállhat az ismételt bizonylatkészítés veszélye. Az integrációnak ezért naplóznia kell a rendeléshez tartozó kérést, az ismert bizonylatazonosítót és a feldolgozás állapotát. Az újrapróbálást csak a ténylegesen támogatott API-működés és a megtervezett duplikációvédelem alapján szabad megoldani.
Az is gyakori, hogy a fizetési szolgáltató ugyanarról az eseményről több értesítést küld, vagy a webshopban egy adminisztrátor kézzel állít státuszt. Ezek üzletileg ugyanahhoz az egy rendeléshez tartozhatnak. A fejlesztés során tisztázni kell, melyik esemény jogosult számlát létrehozni, és melyik csak a már feldolgozott folyamatot ellenőrzi. A tesztelésnek ki kell terjednie az ismételt értesítésre és az időben eltérő sorrendben megérkező adatokra is.
Érdemes külön adminisztrációs nézetet kialakítani a sikertelen bizonylatkészítésekhez, vagy legalább olyan értesítést beállítani, amelyből a munkatárs látja a hibát és az érintett rendelést. A naplóban ne jelenjen meg feleslegesen teljes ügyféladat vagy API-kulcs. Így a rendszerhiba javítható marad anélkül, hogy személyes adatok szükségtelenül több helyre kerülnének.
Ki viseli a felelősséget, ha egy számla hibásan készül el?
Az integráció technikai működését és a számlázási folyamat üzleti ellenőrzését érdemes külön kezelni. Az összekötésnek helyesen kell átadnia a rendelések adatait, de a vállalkozásnak azt is meg kell határoznia, melyik bizonylat mikor állítható ki, és ki dönt a helyesbítésről vagy a visszatérítéssel kapcsolatos teendőkről. Az adózási szabályok értelmezéséhez szükség esetén könyvelővel egyeztess; egy API-kapcsolat nem helyettesíti a számviteli döntést.
Indulás előtt érdemes leírni a rendelések és a bizonylatok közötti kapcsolatot. Legyen visszakereshető a webshop rendelésazonosítója és a Billingóban létrejött bizonylat azonosítója, valamint az, hogy egy hibás kérésből történt-e később sikeres újrapróbálkozás. Így egy ügyfélszolgálati megkeresésnél nem kell találgatni, melyik rendszerben keletkezett az eltérés.
Ha egy rendelés részlegesen teljesül, módosul vagy visszatérítést kap, az ilyen kivételeket külön is próbáld ki. Nem elég egyszer sikeresen kiállítani egy tesztszámlát: a valódi üzemeltetésben a szokatlan esetek kezelése a lényeg.
Az automatizálást utána is felügyelni kell
A megbízható integrációból nem hiányozhat a hibanapló, a jogosultságkezelés és a karbantartási felelős. A titkos API-kulcs ne kerüljön böngészőbe, nyilvános kódtárba vagy ügyfélszolgálati hibajegybe. Az adatokhoz csak a szükséges szerepkörök férjenek hozzá.
Új fizetési szolgáltató, rendelési státusz vagy kuponszabály bevezetése után ismételd meg az érintett teszteket. A számlázási kapcsolat a webshop működésének része, nem egyszeri telepítési feladat.
Ha az integráció egyedi fejlesztést igényel, a KovaBuild plugin- és bővítményfejlesztési szolgáltatása megfelelő kiindulópont lehet. A felméréshez add meg a webshopmotor nevét, a szükséges számlázási eseményeket és a kivételeket is.