Väsyin etsimään laskupohjia, joten rakensin ohjelmointirajapinnan, joka luo viisi asiakirjatyyppiä

Haku "ilmainen laskupohja" on suoritettu niin monta kertaa niin monilla selaimilla, että se saisi todennäköisesti aseman pienen yrityksen omistajuuden diagnostisena indikaattorina. Kaava on aina sama. Uusi asiakas rekisteröityy tai uusi projekti alkaa, tai neljännesvuosittainen laskutusjakso saapuu, ja joku istuu alas tuottamaan laskun. Olemassa oleva pohja, jos sellainen on olemassa, on joko kadonnut kansiorakenteeseen, jonka organisoinnista kukaan ei muista, tai se rakennettiin Microsoft Wordin versioon, joka ei enää kuvaa oikein, tai se kuuluu eri liikeyksikköön ja vaatii merkittäviä muutoksia ennen kuin sitä voi käyttää nykyiseen tarkoitukseen. Joten haku alkaa uudelleen. "Ammattimainen laskupohja." "Ilmainen laskupohja PDF." "Laskupohja verojen laskelmalla." Sivu sitten sivu tuloksia, jotka tarjoavat pohjia, jotka ovat lähes oikein, mutta eivät ole koskaan aivan oikeita, kukin vaatii kaksikymmentä minuuttia säätämistä ennen kuin niitä voidaan tosiasiallisesti käyttää.

Kolmen eri yrityksen johtaminen kolmen eri laskutusvaatimuksen kanssa muutti tämän satunnaisen ärsytyksen toistuvaksi operatiiviseksi kuormaksi. Jokaisella yrityksellä oli eri brändäys, eri verovelvollisyydet, eri rivikohteen rakenteet ja eri asiakirjojen numeroinnin vaatimukset. Pohja, joka toimi yhden yrityksen palveluperusteisessa laskutuksessa, oli täysin väärä toiselle tuotepohjaiselle laskutukselle. Kolmen erillisen pohjajoukon ylläpito, kukin sanajenkäsittelijämuodossa, joka oli altis muotoilujen vioittumiselle ja kaavavirheille, kulutti joka kuussa tunteja, jotka olisivat voineet käyttää todelliseen tuottavaan työhön. Turhautuminen ei ollut mihinkään yksittäiseen laskuun. Se oli ymmärrys siitä, että koko laskutuspohjaisen lähestymistavan lähestymistapa oli perusteellisesti hauras eikä voinut skaalautua useiden yritysten yli muuttumatta ylläpidon taakaksi.

Vaihtoehto, joka lopulta ilmestyi, oli lopettaa laskujen ajatteleminen asiakirjoina, jotka on suunniteltava, ja alkaa ajattelemaan niitä tietoina, jotka on kuvattava. Data, eli kuka, mitä, milloin ja kuinka paljon jokaisesta laskutapahtumasta, on jo tiedossa, kun laskun on tuotettava. Puuttuva on vain kuvaus: kyseisen tiedon muuntaminen ammattimaiseksi asiakirjaksi oikealla asettelulla, laskelmilla ja muotoilulla. Tämä kuvaus on juuri se, mitä sovellusohjelmarajapinta voi tehdä, ja se voi tehdä sen johdonmukaisesti, oikein ja välittömästi jokaiselle laskulle, kaikissa liiketoiminnoissa, ilman pohjaa.

Viisi asiakirjatyyppiä ja miksi jokainen on olemassa

Sovellusohjelmarajapinta osoitteessa yeb.to tuottaa viisi erillistä asiakirjatyyppiä, kukin niistä palvelee tiettyä tarkoitusta laskutus- ja kirjanpitoprosessissa. Ymmärtäminen siitä, miksi viisi tyyppiä on välttämätöntä vain yhden sijasta, selittää paljon siitä, kuinka liiketoiminnan laskutus tosiasiallisesti toimii käytännössä.

Proforma lasku tulee ensimmäisenä useimmissa laskutussekvensseissä. Se on alustavaa asiakirja, joka lähetetään ennen tavaroiden lähettämistä tai palveluiden toimittamista, ja se määrittää mitä laskutetaan ja millä hinnalla. Proforma laskuja käytetään yleisesti kansainvälisessä kaupassa, jossa ostajan on järjestettävä maksu tai tuontidokumentaatio ennen kuin tavarat poistuivat myyjän varastosta. Niitä käytetään myös kotimaassa muodollisina tarjouksina, joilla on enemmän painoa kuin satunnaisella hintaarvioinnilla. Proforma sukupolven päätepiste tuottaa nämä asiakirjat kaikilla kentillä, joita proforma vaatii: myyjä ja ostaja tiedot, eritelyt tavarat tai palvelut, hinnoittelu ja ehdot, mutta selvästi merkitty proformaksi eikä verolaskuksi sekaannuksen välttämiseksi kirjanpitotietueissa.

Vakiolaskuu on ensisijainen laskuasiakirja, sellainen jonka useimmat ihmiset mieltävät, kun he kuulevat sanan "lasku." Se kirjaa suoritetun tapahtuman, määrittää velan määrän ja toimii oikeudellisena perusteena maksujen pyytämiselle. Verolaskut sisältävät arvonlisäveron tai myyntiveron laskelmia, ja sovellusohjelmarajapinta käsittelee useita verokantoja yhdessä laskussa lainkäyttöalueilla, jotka soveltavat eri korkoja eri tuotekategorioihin. Tämä on asiakirjatyyppi, jota käytetään useimmin ja jonka useimmat pohjahaut yrittävät löytää.

Veloitusmuistiot ja hyvitysmuistiot käsittelevät oikaisuja alkuperäisen laskun antamisen jälkeen. Veloitusmuistio dokumentoi lisäkulut, ehkä koska alkuperäinen lasku alilaskutettiin toimituksesta, tai koska lisätyötä suoritettiin alkuperäisen laajuuden ulkopuolella. Hyvitysmuistio dokumentoi vähennykset, kuten palautetut tavarat, ylimaksut tai sovitut alennukset, jotka sovelletaan jälkikäteen. Molemmat viittaavat alkuperäiseen laskuun, jota he muuntavat, ja säilyttävät kirjanpidon asetuksiin vaadittavan tilintarkastuksen jäljen. Lopuksi kuitti vahvistaa, että maksu on vastaanotettu, ja sulkee tietyn tapahtuman laskutusjakson.

Pohjien etsimisestä JSON-kuormitukseen

Työnkulun ero pohjapohjaisen laskutuksen ja sovellusohjelmarajapintapohjaisen laskutuksen välillä on dramaattinen. Pohjojen kanssa laskun tuottaminen tarkoittaa asiakirjatiedoston avaamista, paikkamerkkien tekstin korvaamista todellisilla asiakas- ja laskutustiedoilla, tarkistusta, että kaavat toimivat edelleen rivien lisäämisen tai poistamisen jälkeen, muotoilun säätämistä, jos jotain siirtyi, tuloksen tallentamista PDF-tiedostona ja sekä muokattavan lähteen että PDF-tuloksen arkistointia. Sovellusohjelmarajapintaa käytettäessä laskun tuottaminen tarkoittaa JSON-kuormituksen kokoamista laskutustiedoilla ja sen toimittamista päätepisteelle. Vastaus on valmis PDF. Pohjaa ei ole avata, kaavaa tarkistaa, muotoilua säätää, tiedostojen hallintaa suorittaa.

JSON-kuormitus sisältää kaiken, mitä sovellusohjelmarajapinta tarvitsee asiakirjan tuottamiseen: liikkeeseenlaskijan tiedot (nimi, osoite, verotunniste, pankkitiedot), vastaanottajan tiedot, laskun numero tai automaattiset numerointikonfiguraatio, liikkeeseenlaskunpäivä ja eräpäivä, rivikohde kuvauksilla, määrillä, yksikköhinnoilla ja sovellettavilla verokannolla, mahdolliset alennusehdot, valuutta ja valinnaiset muistiinpanot tai maksutoiminnot. Sovellusohjelmarajapinta suorittaa kaikki laskelmat (rivikokonaissummat, osittaissummat, veromäärät, loppusumma), soveltaa muotoilua ja asettelua sekä kuvaa lopullisen asiakirjan. Koko prosessi kestää alle sekunnin.

Yrityksille, jotka antavat laskuja ohjelmallisesti, ehkä sähköisen kaupan alustasta, projektinhallintötyökalusta tai mukautetusta CRM-järjestelmästä, sovellusohjelmarajapinnan integraatio on yksinkertaista. Järjestelmä, joka tietää mitä laskutetaan, rakentaa JSON-kuormituksen omistaan tiedoistaan ja kutsuu sovellusohjelmarajapintaa. Ihmisen väliintuloa ei tarvita sillä hetkellä, kun laskutapahtuma tapahtuu, ja sillä hetkellä, kun ammattimainen laskuasiakirja on olemassa. Yrityksille, jotka antavat laskuja manuaalisesti, JSON voidaan koota yksinkertaisen lomakekäyttöliittymän kautta, joka kartoitetaan sovellusohjelmarajapinnan syötteen rakenteeseen, silti nopeammin ja luotettavammin kuin sanajenkäsittelijän pohjan muokkaaminen.

Ei pohjia löytää eikä lomakkeita täyttää

Sovellusohjelmarajapintapohjaisen laskutuksen syvempi etu ei ole vain nopeus vaan kokonaisen ylläpitotyöluokan poistaminen. Pohjat vanhenevat. Yrityksen osoite muuttuu, ja joku on päivitettävä jokainen pohja. Uusi verokanta tulee voimaan, ja jokainen kaava on tarkistettava. Yrityksen logo uudelleen suunnitellaan, ja jokainen pohja on lisättävä uusi kuva oikealle sijainnille. Nämä ovat pieniä tehtäviä yksittäin, mutta kolmen yrityksen poikki, joissa on useita pohjien muunnelmia, ne edustavat jatkuvaa taustalla olevaa aika- ja huomio aika.

Sovellusohjelmarajapintaa käytettäessä tämän ylläpidon mikään ei ole olemassa. Liikkeeseenlaskijan tiedot tallennetaan tietoina ja sisällytetään JSON-kuormitukseen. Kun osoite muuttuu, tieto muuttuu yhdessä paikassa, ja jokainen seuraava lasku heijastaa päivitystä automaattisesti. Kun verokanta muuttuu, hinnan parametri kuormituksessa muuttuu, ja sovellusohjelmarajapinta laskee oikein ensimmäisestä laskusta uuden koron mukaisesti. Kun logo muuttuu, kuvan URL-osoite konfiguraatiossa muuttuu, ja jokainen tuleva asiakirja kuljettaa uuden tuotemerkkiä. Pohjakirjaa ei ole löytää, muokata, testata ja jakaa. On vain tietoja, ja tiedot on helppo päivittää.

Lomakkeiden täyttämisen puuttuminen on yhtä merkitsevä. Verkkolaskutuspalvelut, jotka korvautuivat pohjilla verkkolomakkeilla, ratkaisivat muotoilun ongelman, mutta loivat uuden kitkan: saman liikkeeseenlaskijan tiedot, saman pankkitiedon, samat verotunnusnumerot ja samat maksuehdot oli kirjoitettava verkkolomakkeille jokaisen laskun osalta. Sovellusohjelmarajapinta hyväksyy kaiken tämän rakenteellisina tietoina, mikä tarkoittaa, että se voidaan tallentaa kerran ja käyttää loputtomasti uudelleen. Liiketoiminta, joka antaa viisikymmentä laskua kuukaudessa kymmenen säännöllisen asiakkaan osalta, voi tallentaa kymmenen asiakasprofiilia ja rakentaa jokaisen laskun kuormituksen yhdistämällä tallennetun asiakasprofiilin tietyn laskutuskauden spesifisillä rivikohteilla. Laskua kohti kohdistettava ponnistus vähenee vain tämän tietyn tapahtuman ainutlaatuisten asioiden määrittämiseen.

Miksi tämä alkoi kolmella yrityksellä eikä yhdellä

Yksi yritys yksinkertaisilla laskutusvaatimuksilla voi pärjätä pohjilla. Turhautuminen on hallittavissa, kun on vain yksi pohjaryhmä ylläpidettävä, yksi tuotemerkin standardi noudattaa ja yksi verojärjestelymä käsitellä. Pohjametodi hajoaa, kun monimutkaisuus lisääntyy, ja kolmen erillisen yrityksen johtaminen tarjosi juuri sen monimutkaisuuden, joka tarvittiin koko perinteisen lähestymistavan jokaisen heikkouden paljastamiseen.

Jokaisella yrityksellä oli hieman erilainen konteksti. Yksi antoi palvelulaskuja kansainvälisille asiakkaille useissa valuutoissa, vaatien joustavia valuuttojen käsittelyä ja kansainvälisiä pankkitietoja jokaisessa asiakirjassa. Toinen antoi tuotelaskuja kotimaassa Bulgarian arvonlisäveron laskelmilla, joiden oli noudattaa paikallisen veroviranomaiset muotoilun vaatimuksissa. Kolmas toimi hybridimallissa, antaen sekä palvelun että tuotelaskuja sekä kotimaassa että kansainvälisille asiakkaille. Kolme eri pohjaa, kolme eri laskentavaatimusta, kolme eri sääntelyssä määriteltävää muotoilustandardia. Kaikkien näiden ylläpitäminen sanajenkäsittelijän tiedostoissa ei ollut vain tehotonta; se oli virhealtista tavoin, jolla oli todellisia kirjanpidon seurauksia.

Sovellusohjelmarajapinta ratkaisi kaikki kolme tapausta yhdellä integraatiolla. JSON-kuormitusrakenne on sama riippumatta liikkeeseenlaskijasta, valuutasta tai verojärjestelmästä. Ainoat muuttuvat asiat ovat datatarviot: erilaiset liikkeeseenlaskijan tiedot, erilaiset verokannot, erilaiset valuutat, erilaiset rivikohteen kuvaukset. Kuvamoottori käsittelee vaihtelua ketterästi, koska se rakennettiin monenlaisuuden huomioon ottamiseksi pikemmin kuin staattisena pohjana, joka oli suunniteltu yhdelle spesifiselle tapaukselle. Kolme yritystä, kolme täysin erilaista laskuprofiilia ja yksi sovellusohjelmarajapinta, joka palvelee kaikkia ilman minkään yrityskohtaista pohjien ylläpitoa.