Elegem lett a számlasablonok keresésétől, ezért egy API-t építettem, amely öt dokumentumtípust generál

A "ingyenes számlasablon" kifejezésre végzett keresések olyan gyakran fordulnak elő annyi böngészőben, hogy valószínűleg a kisvállalkozás-tulajdonosság diagnosztikai indikátoraként kellene számontartani. A minta mindig ugyanaz. Egy új kliens regisztrál, vagy egy új projekt kezdődik, vagy a negyedéves számlázási ciklus közeledik, és valaki letelepedik egy számla elkészítésére. A létező sablon, ha létezik, vagy elveszett egy mappasztruktúrában, amelyet senki sem emlékszik szervezni, vagy olyan Microsoft Word verzióban készült, amely már nem jól renderelődik, vagy egy másik üzleti entitáshoz tartozik, és jelentős módosításokra van szüksége ahhoz, hogy az aktuálishoz használható legyen. Tehát a keresés újra kezdődik. "Profi számlasablon." "Ingyenes számlasablon PDF." "Számlasablon adókalkulációval." Oldal után oldal olyan sablonokat kínál, amelyek szinte jók, de soha nem pontosan jók, mindegyikhez húsz perc beállítás szükséges, mielőtt ténylegesen használható lenne.

Három különböző vállalkozás működtetése három különböző számlázási követelménnyel ezt az alkalmi kellemetlenséget visszatérő működési terhelésé változtatta. Minden vállalkozásnak eltérő márkajelzése, eltérő adókötelezettségei, eltérő tételstruktúrái és eltérő dokumentumszámozási követelményei voltak. Egy sablon, amely az egyik vállalkozás szolgáltatáson alapuló számlázásához jól működött, teljesen hibás volt egy másik termékalapú számlázásához. Három különálló sablon halmazt kezelni, mindegyiket olyan szövegszerkesztő formátumban, amely formázáskorrumpálásra és formulahibákra volt hajlamos, havonta órákat fogyasztott el, amelyeket valódi produktív munkára lehetett volna fordítani. A frustráció nem egyetlen számla miatt volt. Ez annak a felismerésnek volt az eredménye, hogy az egész sablonalapú számlázási megközelítés alapvetően törékeny volt, és több vállalkozáson keresztül nem tudott skálázódni anélkül, hogy egy karbantartási terhelésé válna.

Az a megoldás, amely végül megjelent, az volt, hogy abbahagyjuk azzal, hogy a számlákra megtervezett dokumentumokként gondolunk, és ahelyett egy olyan adatként gondoljunk rájuk, amelyeket meg kell jeleníteni. Az adat, vagyis az minden számlázási eseménynek a ki, mi, mikor és mennyit része, már ismert abban az időpontban, amikor a számlát be kell produkálni. Ami hiányzik, csak a megjelenítés: az adat olyan professzionális dokumentummá való átalakítása, amely helyes elrendezéssel, számításokkal és formázással rendelkezik. Ez a megjelenítés pontosan az, amit egy API tud csinálni, és ezt következetesen, helyesen és azonnal tudja csinálni minden számlához, minden vállalkozáson keresztül, sablon nélkül.

Öt dokumentumtípus és miért létezik mindegyik

A számlázási API a yeb.to oldalon öt különböző dokumentumtípust generál, mindegyik a számlázási és könyvelési munkafolyamat egy konkrét céljára szolgál. Annak megértése, hogy miért szükséges öt típus ahelyett, hogy csak egy lenne, sok mindent megmagyaráz arról, hogy a vállalatfinanszírozás gyakorlatban valóban hogyan működik.

Az előszámla legtöbb számlázási szekvencia elején jelenik meg. Ez egy előzetes dokumentum, amelyet az áruk szállítása vagy a szolgáltatások nyújtása előtt küldtek el, megadva, hogy mit és milyen áron számláznak. Az előszámlákat általában nemzetközi kereskedelemben használják, ahol a vevőnek az áruk elhagyása előtt meg kell szerveznie a fizetést vagy az importdokumentációt az eladó raktárából. Gyakran használják belföldi szinten is formális árajánlatként, amely nagyobb súllyal rendelkezik, mint egy alkalmi árbecsülés. Az előszámla-generálási végpont ezeket a dokumentumokat minden szükséges mezővel gyártja: eladó és vevő adatai, itemizált áruk vagy szolgáltatások, árazás és feltételek, de világosan előszámlaként, nem pedig adószámlként jelölik meg, hogy elkerüljék a zavarost a könyvelési nyilvántartásban.

A szokásos számla az elsődleges számlázási dokumentum, az, amelyre az emberek gondolnak, amikor a "számla" szót hallják. Egy befejezett tranzakciót rögzít, megadja a fennálló összeget, és a fizetési kérelem jogi alapjául szolgál. Az adószámlák tartalmazzák az ÁFA vagy a forgalmi adó számításait, és az API több adókulcsot is kezel egy számlán belül azokra a joghatóságokra, amelyek eltérő kulcsokat alkalmaznak a különböző termékkategóriákra. Ez az a dokumentumtípus, amelyet leggyakrabban használnak, és amelyet a legtöbb sablon keresés megpróbál megtalálni.

A terhelési jegyzékek és jóváírási jegyzékek az eredeti számla kibocsátása utáni módosításokat kezelik. Egy terhelési jegyzék további költségeket dokumentál, talán azért, mert az eredeti számla alulszámlázta a szállítást, vagy mert az eredeti hatályon túl további munka végeztünk el. Egy jóváírási jegyzék csökkentéseket dokumentál, például visszaküldött áruk, túlfizetések vagy utólagosan alkalmazott kedvezmények. Mindkettő az eredeti számlára hivatkozik, amelyet módosítanak, és fenntartja a nyomvonalat, amely a könyvelési előírások megkövetelik. Végül a nyugta megerősíti, hogy a fizetést megkapták, bezárva az adott tranzakció számlázási ciklusát.

A sablon keresésétől a JSON terhelésig

A sablonnalapú számlázás és az API-alapú számlázás közötti munkafolyamat különbség drámai. Sablonokkal a számla előállítása azt jelenti, hogy megnyitnak egy dokumentumfájlt, helyére teszik az aktuális kliens- és számlázási adatokat, ellenőrzik, hogy a képletek még működnek-e az aposztrófok hozzáadása vagy eltávolítása után, módosítják a formázást, ha valami eltolódott, elmentik az eredményt PDF-ként, és archiválják az szerkeszthető forrásfájlt és a PDF kimenetet is. Az API-val az számla előállítása azt jelenti, hogy összeállítunk egy JSON terhelést a számlázási adatokkal, és elküldjük azt a végpontnak. A válasz egy kész PDF. Nincs sablon a megnyitáshoz, nincs képlet az ellenőrzéshez, nincs formázás az igazításhoz, nincs fájlkezelés az elvégzéshez.

A JSON terhelés tartalmazza az összes információt, amely az API-nak szükséges a dokumentum előállításához: a kibocsátó adatai (név, cím, adóazonosító szám, banki adatok), a címzett adatai, a számlaszám vagy az autonumozási konfiguráció, a kibocsátási és esedékesség dátumai, a sorok részletei leírásokkal, mennyiségekkel, egységáraikkal és alkalmazható adókulcsokkal, az esetleges kedvezmények feltételei, a pénznem és az opcionális megjegyzések vagy fizetési utasítások. Az API az összes számítást elvégzi (soros összegek, részösszegek, adóösszegek, végösszeg), alkalmazza a formázást és az elrendezést, és megjelenít a végső dokumentumot. Az egész folyamat kevesebb mint egy másodpercet vesz igénybe.

Azon vállalkozások számára, amelyek programozottan állítanak elő számlákat, talán egy e-kereskedelmi platformból, egy projektmenedzsment eszközből vagy egy egyéni CRM-ből, az API-integráció egyszerű. Az a rendszer, amely tudja, hogy mit kell számlázni, összeállítja a JSON terhelést a saját adataiból, és meghívja az API-t. A számlázási esemény pillanata és a professzionális számlázási dokumentum pillanata között nem szükséges emberi beavatkozás. A számlázást kézzel végző vállalkozások számára a JSON összeállítható egy egyszerű formanyomtatvány felületen keresztül, amely az API bemenetstruktúrájához szól, még mindig gyorsabb és megbízhatóbb, mint egy szövegszerkesztő sablon szerkesztése.

Nincsenek sablonok, amelyeket meg kell találni, és nincsenek űrlapok, amelyeket ki kell tölteni

Az API-alapú számlázás mélyebb előnye nem csak a sebesség, hanem egy teljes karbantartási munka kategóriájának kiküszöbölése. A sablonok öregednek. A vállalat címe megváltozik, és valakinek frissítenie kell az összes sablont. Egy új adókulcs lép érvénybe, és minden képletet fel kell vizsgálni. A vállalati logó újradesign alatt áll, és minden sablonnak az új képet kell beilleszteni a helyes pozícióba. Ez egyenként kis feladatok, de három vállalkozáson keresztül több sablonváltozattal, állandó háttérkimerültségnek az idő és figyelem képviselnek.

Az API megközelítéssel semmi ilyen karbantartás nem létezik. A kibocsátó adatai adatok formájában tárolódnak, és a JSON terhelésben szerepelnek. Amikor a cím megváltozik, az adat egy helyen változik meg, és a későbbi összes számla automatikusan tükrözi a frissítést. Amikor egy adókulcs megváltozik, a terhelésben az arányparaméter változik, és az API helyesen számít az új arány alatt az első számlától. Amikor a logó megváltozik, a konfigurációban az képURL-je megváltozik, és minden jövőbeli dokumentum az új márkajelzést hordozza. Nincs sablon fájl a megtalálásához, szerkesztéséhez, teszteléséhez és terjesztéséhez. Csak adat van, és az adat könnyű frissíteni.

Az űrlap kitöltés hiánya egyaránt jelentős. Az online számlázási szolgáltatások, amelyek helyettesítették a sablonokat webes formanyomtatvány ú, megoldották a formázási problémát, de új súrlódást hoztak létre: ugyanaz a kibocsátó adatok, ugyanaz a banki adatok, ugyanaz az adóregisztrációs számok és ugyanazok a fizetési feltételek manuális bevitele webes formanyomtatványokban minden számlához. Az API ezeket az összes strukturált adatként fogadja, ami azt jelenti, hogy ezt egyszer lehet tárolni és korlátlanul lehet újrahasználni. Egy vállalkozás, amely havonta ötven számlát állít elő tíz rendszeres ügyfélnek, tárolhat tíz ügyfél profilt, és minden számlázási időszakhez minden számlaterhelést összeállíthat egy tárolt ügyfél profil és az adott számlázási időszakra jellemző sorok kombinációjával. A számlánkénti munkavégzés csak annak megadására redukálódik, ami egyedi az adott tranzakcióhoz.

Miért ez három vállalkozással kezdődött, és nem egy

Az egy vállalkozás egyszerű számlázási igénnyel megoldhatja a sablonokkal. A frustráció kezelhetõ, ha csak egy sablon halmazt kell fenntartani, egy márkajelzési standardot kell követni, és egy adójurisdikciót kell kezelni. A sablonok megközelítése összeomlik, amikor az összetettség nő, és három külön vállalkozás működtetése pontosan azt az összetettséget biztosította, amely szükséges volt a tradicionális megközelítés minden gyengeségének felfejtésére.

Minden vállalkozás egy kicsit más kontextusban működött. Az egyik nemzetközi ügyfeleknek több pénznemben számlázott szolgáltatási számlákat, rugalmas pénznem-kezelést és nemzetközi banki adatokat igénylő minden dokumentumon. A másik hazai természszámlázást végzett bolgár ÁFA számításokkal, amelyeknek meg kellett felelniük a helyi adóhatóság formázási követelményeinek. A harmadik hibrid modellben működött, szolgáltatási és természszámlázást is végezve hazai és nemzetközi ügyfelek keverékéhez. Három különböző sablon, három különböző számítási követelmény, három különböző szabályozási formázási standard. Az összes fenntartása szövegszerkesztő fájlokban nem volt csak nem hatékony; ez hibára volt hajlamos olyan módon, amely valódi könyvelési következménnyel járt.

Az API megoldotta mind a három esetet egy integrációval. A JSON terhelés struktúrája ugyanaz, függetlenül attól, hogy a kibocsátó, a pénznem vagy az adójurisdikció. Az egyetlen dolog, amely megváltozik, az az adatok értéke: eltérő kibocsátó adatai, eltérő adókulcsai, eltérő pénznemei, eltérő tételleírásai. A megjelenítési motor kecsesen kezeli a variációt, mert azért építették, hogy befogadja a sokféleséget, ahelyett, hogy egy olyan statikus sablon lenne, amely egy konkrét esetre lett megtervezve. Három vállalkozás, három teljesen eltérő számlázási profil, és egy API, amely mindegyiket szolgálja anélkül, hogy bármilyen vállalkozásonkénti sablon karbantartásra lenne szükség.