Primer povezave trgovine z računovodstvom
8 min branja
Ko spletna trgovina vsak dan prejema naročila, računovodstvo pa podatke prepisuje v ločen program, se napake ne pojavijo zato, ker bi nekdo delal slabo. Pojavijo se, ker je proces zasnovan ročno. Dober primer povezave trgovine z računovodstvom pokaže, kako lahko naročilo, plačilo, račun in zaloga potujejo skozi podjetje brez dvojnega vnosa in brez usklajevanja ob koncu meseca.
Predstavljajmo si specializiranega trgovca, ki prek spletne trgovine prodaja izdelke končnim kupcem in poslovnim strankam. Ima več sto artiklov, različne davčne obravnave, zalogo v skladišču ter računovodski program, v katerem nastajajo računi, dobropisi in evidence prihodkov. Dokler je naročil nekaj na dan, je ročno delo še obvladljivo. Ko prodaja zraste, pa ista rutina začne jemati ure časa in ustvarjati tveganje: napačen znesek, podvojen kupec, nepravilen DDV ali izdelek, ki je na spletu še vedno prikazan kot dobavljiv.
Povezava ni zgolj tehnični dodatek. Je del prodajnega procesa, ki mora biti usklajen s tem, kako podjetje dejansko posluje.
Kako izgleda primer povezave trgovine z računovodstvom
Kupec v spletni trgovini izbere izdelek, vnese podatke za dostavo in plača s kartico ali po predračunu. Trgovina takoj ustvari naročilo. Pri dobro zasnovani povezavi se ključni podatki prenesejo v računovodski sistem: podatki kupca, izdelki, količine, popusti, stroški dostave, davčna stopnja, način plačila in skupna vrednost naročila.
Računovodski program iz teh podatkov pripravi račun po pravilih podjetja. Če sistem to podpira, se številka računa vrne v spletno trgovino, kupec pa prejme dokument po e-pošti oziroma ga vidi v svojem uporabniškem računu. Hkrati se ustrezno znižajo zaloge. Prodajna ekipa ne išče naročil po e-pošti, računovodstvo ne prepisuje postavk, skladišče pa dela z aktualnimi podatki.
Pomembna podrobnost: povezava ne pomeni nujno, da se račun izda v isti sekundi, ko kupec odda naročilo. Pri določenih podjetjih je smiselno račun ustvariti šele, ko je naročilo potrjeno, odpremljeno ali plačano. Pri plačilu po predračunu je proces drugačen kot pri takojšnjem kartičnem plačilu. Prava rešitev sledi internemu postopku podjetja, ne obratno.
Primer iz prakse: trgovina z B2B in B2C prodajo
Recimo, da trgovina prodaja tehnično opremo tako posameznikom kot podjetjem. Poslovne stranke imajo dogovorjene cene, možnost plačila po ponudbi in posebne pogoje dostave. Končni kupci plačujejo takoj, podjetja pa lahko naročajo z naročilnico.
Ob naročilu fizične osebe se v računovodstvo prenese plačano naročilo in pripravi račun. Ob naročilu podjetja se lahko najprej ustvari ponudba oziroma predračun. Ko podjetje plača ali prodajnik potrdi naročilnico, se dokument spremeni v račun. Če kupec vrne del naročila, povezava ustvari podlago za dobropis, zaloga vrnjenega izdelka pa se uskladi po pravilih skladišča.
To je bistvo dobre integracije: ne prenaša le podatkov, temveč upošteva poslovne statuse in izjeme, ki so za podjetje normalne.
Kateri podatki morajo biti usklajeni
Najpogostejša napaka je zahteva, da se poveže »vse«. To je drago, nepregledno in pogosto nepotrebno. Najprej je treba določiti, kateri podatki so res ključni za prodajo, računovodstvo in skladišče.
Običajno so to artikli s šiframi, cenami, davčnimi stopnjami in zalogami; kupci z naslovom in davčnimi podatki; naročila z vsemi postavkami; računi, dobropisi in statusi plačil. Če podjetje uporablja več skladišč, serijske številke, pakete izdelkov ali več valut, mora povezava upoštevati tudi te posebnosti.
Posebno pozornost zahtevajo popusti. Popust na celotno košarico, kupon, brezplačna dostava in pogodbeno dogovorjena B2B cena se lahko v računovodskem programu obravnavajo različno. Če tega ne določimo na začetku, se lahko skupni znesek naročila in računa ujemata, analitika prodaje pa ne. Pri integraciji zato ni dovolj preveriti, ali se podatki prenesejo. Preveriti je treba, ali imajo po prenosu enak poslovni pomen.
Povezava v realnem času ali periodični prenos
Ni vsaka trgovina odvisna od prenosa v realnem času. Če ima podjetje malo naročil in zaloga ni kritična, je lahko dovolj samodejni prenos na vsakih 15 ali 30 minut. Takšna rešitev je pogosto preprostejša za nadzor in manj občutljiva na kratkotrajne prekinitve zunanjih sistemov.
Pri hitro prodajanih izdelkih, omejenih zalogah ali prodaji prek več kanalov pa je realni čas velika prednost. Zaloga se po prodaji posodobi takoj, zato je manj možnosti, da bi dva kupca kupila zadnji kos hkrati. Podjetje, ki prodaja tudi prek fizične poslovalnice, B2B portala ali spletnih tržnic, potrebuje jasen odgovor na vprašanje, kateri sistem je glavni vir podatkov o zalogi.
Včasih je to računovodski oziroma ERP sistem, drugič spletna trgovina, pri večjih procesih pa ločen skladiščni sistem. Če tega ne določimo, lahko dva sistema hkrati popravljata iste podatke. Rezultat so razlike, ki jih ekipa opazi šele takrat, ko kupec prejme obvestilo, da izdelka ni mogoče dobaviti.
Kaj je treba dogovoriti pred razvojem
Kakovost povezave se ne začne s kodo, ampak z jasnim procesom. Pred izvedbo je smiselno skupaj pregledati pot naročila od oddaje do izdaje računa, odpreme in morebitnega vračila. Pri tem hitro odkrijemo odločitve, ki jih generične platforme pogosto ne rešijo dovolj dobro.
Dogovoriti je treba, kdaj nastane kupec v računovodskem sistemu, kako se obravnavajo gostujoči nakupi, kaj se zgodi ob neuspelem plačilu in kako se beležijo delne dobave. Pomembno je tudi, kdo prejme opozorilo, če prenos ne uspe. Samodejen proces brez nadzora ni zanesljiv proces.
Dobro je preveriti še zmogljivosti računovodskega programa. Nekateri sistemi imajo urejen programski vmesnik in omogočajo neposredno komunikacijo. Drugi podpirajo uvoz in izvoz datotek. Tudi slednja možnost je lahko smiselna, vendar zahteva natančno strukturo podatkov, urnik prenosa in jasen postopek za obravnavo napak.
Štiri napake, ki podražijo integracijo
- Povezovanje brez usklajenih šifer artiklov. Če spletna trgovina in računovodstvo za isti izdelek uporabljata različne oznake, se prenos hitro zaplete ali napačno razvrsti.
- Nejasna pravila za račune in dobropise. Vračilo izdelka, preklic naročila in delna dobava niso ista stvar. Vsak primer potrebuje pravilno dokumentacijo.
- Ignoriranje izjem. Napačen naslov, manjkajoča davčna številka ali zavrnjeno plačilo niso redki dogodki, ampak običajen del spletne prodaje.
- Brez testnih scenarijev. Integracija ni pripravljena, ko uspešno prenese eno naročilo. Preveriti je treba popuste, več davčnih stopenj, dostavo, vračila, poslovne kupce in neuspešne prenose.
Prilagojena rešitev ima prednost tam, kjer je proces poseben
Vtičnik je lahko dobra izbira, kadar podjetje uporablja standarden proces in je računovodski program že podprt. Težava nastane, ko trgovina potrebuje drugačna cenovna pravila, več načinov izdaje dokumentov, povezavo s skladiščem ali lastno logiko potrjevanja naročil. Takrat kompromisi hitro postanejo stalno ročno delo.
Prilagojena povezava omogoča, da se podatki prenašajo tako, kot jih vaše podjetje potrebuje. Ne pomeni, da je treba vsakič graditi vse od začetka. Pomeni pa, da se arhitektura, administrativni vmesnik in integracije načrtujejo okoli dejanskih potreb, ne omejitev predpripravljene rešitve. Pri projektih Moxy Web je to ključno izhodišče: spletna trgovina mora dobro izgledati, vendar mora predvsem zanesljivo podpirati poslovanje v ozadju.
Zagon ni zadnji korak
Pred objavo je treba povezavo preizkusiti na realnih primerih. Ekipa naj odda testno kartično naročilo, naročilo po predračunu, B2B naročilo s popustom, naročilo z več artikli in primer vračila. Nato naj preveri, kaj se je zgodilo v trgovini, računovodskem programu, skladišču in e-poštnih obvestilih.
Po zagonu je smiselno prvih nekaj dni spremljati prenose in primerjati vzorec naročil z izdanimi dokumenti. Ko proces enkrat deluje, ga je vredno tudi dokumentirati. Novi sodelavec mora vedeti, kje preveri status prenosa in kako ukrepa, če se naročilo ustavi.
Najboljša povezava med trgovino in računovodstvom ni tista z največ funkcijami. Je tista, pri kateri prodaja teče hitro, računovodstvo zaupa podatkom, kupci pravočasno dobijo pravilne dokumente, ekipa pa lahko čas nameni rasti podjetja namesto popravljanju podatkov.