Weboldalad összekötése a SmartBill vagy Oblio rendszerrel: automatikus számlák a rendelésekből

Ha online értékesítesz, és még mindig kézzel állítasz ki minden számlát, pontosan ott veszítesz időt, ahol a rendelések száma nő. Kimásolod a vevő nevét, a termékeket, az áfát, megkeresed a megfelelő sorozatot, elmented a PDF-et, elküldöd e-mailben. Napi néhány rendelésnél ez még rendben van. Napi tucatnyinál már beszivárognak a hibák és a késések.

A jó hír: mind a SmartBill, mind az Oblio kínál API-t, amely lehetővé teszi, hogy a weboldalad magától állítsa ki a számlát, a fizetés után másodperceken belül. A vevő automatikusan megkapja a PDF-et, minden már ott van a könyvelésedben, és az e-számla úgy jut el az adóhatósághoz, hogy egy ujjal sem kell hozzányúlnod. Ebben a cikkben konkrétan elmagyarázom, hogyan működik az integráció, mit kell előre előkészíteni, és hol szokott a leggyakrabban elakadni a dolog.

Mit is jelent valójában egy SmartBill vagy Oblio integráció

Az integráció egy híd a webáruházad és a számlázó szoftvered között. Amikor egy vevő leadja a rendelést és fizet, a weboldalad automatikusan elküldi az API-n keresztül a SmartBillnek vagy az Oblio-nak mindazt, amire a számlához szükség van: a vevőt, a termékeket, az árakat, az áfakulcsot és cég esetén az adószámot.

A számlázó szoftver elkészíti a számlát a beállított sorozatodon, kioszt egy számot, és visszaküldi a PDF-et. Innentől, attól függően, hogyan állítjuk be a folyamatot:

• a számla automatikusan a vevő postaládájába kerül;
• elmentődik a számlázó fiókodban;
• továbbítódik az e-számlázásba (az adóhatóság felé).

Mindez másodpercek alatt megtörténik, semmit nem kell megnyitni. A gyakorlatban a rendelés a weboldaladon és az adóügyi számla egyetlen mozdulattá válik, nem pedig két külön feladattá, amit este kézzel elvégzel.

SmartBill vagy Oblio — számít, melyik?

Technikailag mindkettő szolid román megoldás API-val és a kötelező e-számlázás támogatásával. Nincs egyértelmű győztes; a helyes döntés a lehető legunalmasabb: válaszd azt, amit a könyvelőd már használ vagy preferál, hogy az adatok egyenesen a könyvelésbe folyjanak.

Néhány gyakorlati szempont az összehasonlításhoz:

• a kész pluginek ökoszisztémája (például WooCommerce-hez) — az egyiknek érettebb integrációja lehet a te platformodhoz;
• az árazási modell és a számlakorlát a csomagodban;
• hogy milyen e-számlázási és jóváíró (storno) funkciókat kínál az API.

Ha a nulláról indulsz, először kérdezd meg a könyvelődet. Ha már az egyiket használod, a váltás pusztán az integráció kedvéért szinte soha nem éri meg.

Mit készítünk elő az integráció megkezdése előtt

A legtöbb probléma nem a kódból, hanem a kapkodva elvégzett beállításokból ered. Az integráció előtt néhány dolgot lerögzítünk:

• A fiók és az API-kulcs (token/e-mail) a SmartBilltől vagy az Oblio-tól.
• Egy dedikált számlasorozat az online rendelésekhez, elkülönítve a kézzel kiállított számláktól — különben ütközik a számozás.
• Helyes áfakulcsok minden terméken (nem mindegyik osztozik ugyanazon a kulcson).
• Egy adószám-mező a pénztárnál a céges vevők számára, hogy a számla a cégre legyen kiállítva.
• A döntés: proformát vagy közvetlenül adóügyi számlát állítunk ki?
• A kiváltó pillanat: a rendelés leadásakor, a fizetéskor vagy a szállításkor.

Ezeket a döntéseket egyszer hozzuk meg, az elején. Most jól elkészítve az integráció hónapokig fut beavatkozás nélkül.

E-számlázás: miért nem áll meg többé az integráció a PDF-nél

Romániában az adóhatóság rendszerén keresztüli elektronikus számlázás kötelezővé vált, először a vállalkozások közötti (business-to-business) ügyletekre, majd kiterjesztve a magánszemélyekre is. A gyakorlatban már nem elég, ha a weboldalad kiköp egy szép PDF-et — a számlának el kell jutnia az adórendszerbe is, XML formátumban.

Itt jön a jó hír: mind a SmartBill, mind az Oblio továbbítani tudja a számlát a hivatalos rendszerbe. Egy megfelelően felépített integráció ezt a lépést is automatikusan kiváltja, nemcsak a PDF-et.

Ahhoz, hogy elutasítás nélkül átmenjen, a részletek számítanak:

• érvényes, helyesen formázott adószám a céges vevőknél;
• teljes azonosító adatok;
• a rendelés végösszegével egyező áfakulcsok.

Ez a különbség egy olyan integráció között, amely pusztán számlákat állít elő, és egy olyan között, amely ténylegesen fenntartja a megfelelőségedet.

Mi szokott a leggyakrabban elromlani (és hogyan kerüld el)

Tapasztalatból: szinte az összes fejfájás itt lakik:

• Duplikált számlák: ha a fizetés kétszer indítja el a jelet, egy rendelésre két számlát is kaphatsz. Ezt egy olyan ellenőrzéssel oldjuk meg, amely a számlát a rendelésazonosítóhoz köti.
• Ellenőrizetlen adószám: a cég elutasítja a számlát, mert az adatok nem egyeznek. A pénztárnál validáljuk az adószámot.
• Áfakerekítés: a weboldal végösszege nem egyezik a számla végösszegével fillérre pontosan. Összehangoljuk a számítási módszert.
• Kimerült sorozat: elfogynak a számok, és a számlázás megáll. Figyeljük.
• Visszaküldések és sztornók: a jóváíró számla (storno) nem készül el magától, hacsak nem tervezzük be.

Az aranyszabály: teszt sorozaton tesztelünk, soha nem közvetlenül valódi számlákon.

Hogyan közelítjük meg az integrációt az MPO Web Studio-nál

Helyi vállalkozásoknak építünk weboldalakat, és teljesen távolról szállítunk, bárhol az országban — így nem számít, hol vagy. A számlázás oldalán a valós folyamatodból indulunk ki: mit adsz el, kinek (cégeknek, magánszemélyeknek vagy mindkettőnek) és milyen szoftvered van már meg.

Bármilyen elköteleződés előtt előkészíthetünk egy kész demót, hogy ténylegesen lásd a rendelés-számla-e-számla útvonalat, ne csak ígéretként halld tőlünk. Az árazás átlátható, előre megállapodott, meglepetések nélkül.

Ha azt szeretnéd, hogy a számlák maguktól elkészüljenek a rendelésekből, és ne veszíts több estét adatok másolgatásával, írj nekünk WhatsAppon, és őszintén megmondjuk, mi lehetséges a te webáruházadban, és mennyi időt vesz igénybe. Semmi rámenős értékesítés — először megnézzük, hogy megéri-e.