Võidetud tehing ei ole veel arve. Pipedrive teab summat ja Merit Aktiva peab vormistama dokumendi.
AlusLabs ehitab liidestusi CRM-i ja raamatupidamistarkvara vahele: me liidame Pipedrive'i Merit Aktivaga nii, et võidetuks märgitud tehing muutub müügiarveks koos tuvastatud kliendi ja ridadega ning kirjutame laekumise staatuse tagasi tehingule, et müügitiim näeks seda ilma küsimata.
Müügiinimene sulgeb tehingu ja keegi teine sisestab selle käsitsi uuesti arveks. Hiljem küsib sama müügiinimene raamatupidajalt kirjalikult, kas arve on tasutud. Mõlemad on ühe ja sama puuduva liidestuse tagajärg, mis avaldub eri suundades.
Kes ühendab CRM-i raamatupidamisega?
Liidestus ise on lühike, kuid selle sees tehtavad otsused mitte. CRM hoiab müügitoru ja majandustarkvara hoiab pearaamatut ning nende ühendamine taandub mõnele põhiküsimusele: kes on see klient mõlemas süsteemis, mis saab tehingu reast arvel ja millal arve makstähtaeg saabub. AlusLabs ehitab Pipedrive'i ja Merit Aktiva liidestused nende vastuste põhjal, mitte vaikimisi seadistuste peale.
Pipedrive'i API on ehitatud tehingute, toodete, isikute ja organisatsioonide, mitte arvete ümber, ja selline tööjaotus ongi õige. Tehing on päästik ja Merit Aktiva on koht, kus dokument tegelikult luuakse. Pipedrive teeb päringu sinu aadressile, kui tehingul midagi muutub, ja arve kirjutatakse Merit Aktiva v2 API kaudu, mistõttu ei toimu andmete perioodilist kontrollimist ega käsitsi ümberkirjutamist.
Mida me ühendame
Müük ja raamatupidamine hoiavad kumbki eri poolt ühest ja samast kliendist. Suur osa tööst seisneb otsustamises, kummal poolel on mille suhtes õigus.
Võidetud tehingust müügiarveks
Kui tehing jõuab sinu määratud faasi, kirjutatakse Merit Aktivas arve koos kliendi ja ridadega. Milline faas loetakse võidetuks, on otsuse koht, ja sageli ei ole see müügitoru viimane faas, sest viimases faasis on raha tavaliselt juba kohal.
Üks klient, kaks identiteeti
Pipedrive'i organisatsioon ja Merit Aktiva klient on kaks eri kirjet, millel puudub tavaliselt ühine võti. Neid ühendab registrikood või käibemaksukohustuslase number, ja kui seda välja müügipoolel veel ei ole, on selle lisamine ja täitmise nõudmine osa tööst, mitte eeltingimus, mille keegi teine peab lahendama.
Tehingu read arveridadeks
Tehingu toode kannab hinda ja kogust. Arverida kannab artiklit ja käibemaksukoodi, millega see artikkel on Merit Aktivas seadistatud. Mis milliseks muutub, kirjutatakse iga toote kohta üks kord mällu, et arvet ei pandaks kunagi kokku kellegi mälestuse järgi sellest, mis tehingus kirjas oli.
Laekumise staatus tagasi tehingule
Merit Aktiva teab, kas arve on tasutud, aga müügiinimene mitte. Selle info tagasikirjutamine tehingule lõpetab iganädalased küsimused raamatupidajale ja säästab ka raamatupidaja aega.
Püsitasud ja etapiviisilised projektid
Mitte iga tehing ei tekita täpselt ühte arvet. Püsitasu tekitab ühe arve kuus ja projekt tekitab neid etappide kaupa, mistõttu lepitakse reegel, mis otsustab, mitu dokumenti tehing väärt on, kokku enne koodi kirjutamist, mitte pärast selle avastamist.
Kuidas see tehniliselt käib
Kahel poolel on vastandlik iseloom ja see kujundab ka lahenduse. Pipedrive'ile pääseb ligi API võtmega või OAuth 2.0 kaudu ja sellest on olemas kaks versiooni, v1 ja uuem v2, mille lõpp-punktid on jõudluse suhtes optimeeritud ja päringute mõttes odavamad kui v1 analoogid. Merit Aktiva seevastu allkirjastab iga päringu. Mõlemad pooled tõrguvad täiesti erinevalt, mistõttu ehitatakse ja testitakse neid eraldi ning liidetakse alles siis, kui kumbki pool eraldi töötab.
Pipedrive mõõdab kasutust, mitte päringute arvu, ja see muudab disaini rohkem kui miski muu sellel lehel. Igal kontol on igapäevane limiit 30 000 baasühikut, mis on korrutatud paketitaseme ja kasutajakohtade arvuga, ning iga lõpp-punkt kulutab seda limiiti erinevalt, mistõttu kirje otsimine maksab oluliselt rohkem kui kirje pärimine identifikaatori järgi. Kui limiit on täis, vastab API koodiga 429 ja lõpetab vastamise. Seetõttu kuulab selline liidestus muutusi, mitte ei loe müügitoru taimeri alusel uuesti üle, ning salvestab identifikaatori, mida läheb uuesti vaja, selle asemel et seda kaks korda otsida.
Kuulamise pooleks on Pipedrive'i veebikonksud (webhooks), mis on nüüd oma teises versioonis ja mida tellitakse objekti ja tegevuse põhiselt: tehing muudetud, isik lisatud, organisatsioon liidetud. Liitmine on see, mis sageli unustatakse. Kahe organisatsiooni ühinemine on täpselt see hetk, mil salvestatud link hakkab viitama kirjele, mida pole enam olemas, ja liidestus, mis seda eirab, jätkab arvete kirjutamist kliendile, keda keegi enam ei kasuta.
Viimane otsus on see, kummal süsteemil on õigus, kui andmed on vastuolus. Müügiinimese parandatud aadress ja raamatupidaja parandatud käibemaksukood on mõlemad õiged seal, kus nad on, ning kõige sünkroonimine mõlemas suunas muudab selle vaidluseks, mida keegi ei suuda lahendada. Seetõttu otsustatakse suund iga välja kohta eraldi ja kirjutatakse üles ning enamik välju liigub ainult ühes suunas.
Avatud lähtekood
github.com/arturl95/merit-aktiva-skillsHMAC-SHA256 päringute allkirjastamine, Merit Aktiva v2 lõpp-punktide kate, MIT-litsents, dokumentatsioon eesti ja inglise keeles. Loetav ja kasutatav ka ilma meieta.
- checkKlient seotakse registrikoodi või käibemaksukohustuslase numbri, mitte kunagi ettevõtte nime järgi.
- checkFaas, mis loob arve, nimetatakse täpselt, mitte ei eeldata, et see on viimane.
- checkMuutusi kuulatakse, mitte ei pärita perioodiliselt, et igapäevane limiit kuluks tööle, mitte küsimustele.
Millal tasub liidestada
CRM ja raamatupidamine triivivad teineteisest vaikselt lahku ning selle hind saabub küsimuste näol. Kui need kõlavad tuttavalt, siis nende eest juba makstakse:
Keegi ei oska öelda, millisele tehingule arve kuulub
Arve on raamatupidamises, tehing on müügitorus ja miski neid ei seo. Kliendi tegeliku väärtuse arvutamiseks tuleb mõlemad andmed eksportida ja käsitsi kokku viia.
Müük küsib raamatupidamiselt, kas arve on laekunud
Iga kliendiga ühenduse võtmine algab küsimusega raamatupidajale. Vastus saabub järgmisel päeval, mil kliendile on igal juhul juba helistatud, vahel ka arve teemal, mille nad tasusid nädal aega tagasi.
Arveid kopeeritakse tehingu ekraanilt
Keegi loeb ridu CRM-ist ja sisestab need käsitsi raamatupidamisprogrammi. Need kaks süsteemi lõpetavad ühtimise esimest korda siis, kui allahindlus lepitakse kokku pärast tehingu võidetuks märkimist.
Prognoos ja pearaamat räägivad eri keelt
Müügitoru näitab kuu kohta ühte numbrit ja raamatupidamine teist. Mõlemat kaitstakse samal koosolekul ja kumbagi ei saa kontrollida ilma terve päeva kestva andmete võrdlemiseta.
KKK
Kas Pipedrive ise arveid ei tee?
Selle API on ehitatud tehingute, toodete, isikute ja organisatsioonide, mitte arvete ümber, ja see ongi õige tööjaotus. Arve on raamatupidamisdokument, millel on oma numbriseeria, käibemaksukood ja juriidiline elu, ning selle koht on programmis, mis peab pearaamatut. CRM-i ülesanne on öelda, et müük toimus ja mis seal sees oli.
Milline müügitoru faas peaks arve looma?
Selle valid sina ja seda tasub hoolikalt valida. Hilisem faas müügitorus tekitab vähem valesid arveid, varasem aga saadab dokumendi kiiremini välja. Ükskõik millise sa valid, tagasipööratav juhtum vajab reeglit: tehingul, mis liigub sellest faasist tagasi, on arve juba maailmas olemas, seega peab keegi otsustama, kas sellest saab kreeditarve või vestlus.
Mis saab siis, kui registrikoodi ei sisestatud müügipoolel?
Siis lisatakse see väljana ja täidetakse ka tegelikult, sest klientide nime järgi kokkuviimine on viis, kuidas tekivad dubleerivad kliendikaardid. Müügiinimesed ei täida välja, mille mõttest nad aru ei saa, mistõttu muudetakse see kohustuslikuks faasis, kus see on oluline, mitte müügitoru alguses, kus see ainult aeglustab tööd.
Kas müügiinimene näeb, kas arve on tasutud?
Jah, tehingu enda peal. Laekumise staatus kirjutatakse Merit Aktivast tagasi ja müük seda muuta ei saa, sest raamatupidamislik fakt, millele keegi saab peale kirjutada, lakkab olemast fakt. Müük saab vastuse ja raamatupidamine saab rahu küsimustest.
Kas see on kahesuunaline sünkroonimine?
Osaliselt ja teadlikult mitte tervikuna. Täielik kahesuunaline sünkroonimine CRM-i ja raamatupidamise vahel tähendab, et iga välja saab muuta kahes kohas ja viimane kirjutaja võidab, mis on sobilik kuni esimese tõrkeni. Igale väljale määratakse suund, enamik neist liigub ühes suunas ja need vähesed, mis tagasi tulevad, on need, mille puhul raamatupidamine on algallikas.
Seotud liidestused
Merit Aktiva integratsioon ja API-liidestus
Merit Aktiva API-liidestus e-poe, CRM-i, tabelite ja sisemiste töövoogudega. AlusLabs ehitab liidestuse olemasoleva programmi peale, ilma et peaksid Merit Aktivast loobuma.
E-arve saatmine: operaatorid, formaadid ja Finbite liidestus
E-arve liigub sinu tarkvarast välja andmetena, ostjale sobivas formaadis ja kanalit pidi, mis on kirjas tema äriregistri kaardil. Sageli on selleks kanaliks e-arve operaator nagu Finbite. AlusLabs ehitab sinna vahele liidestuse, mis teeb ka registripäringu ja otsustab, kuhu iga arve saata.
SimplBooksi liidestus ja API-integratsioon
SimplBooksi avalik API võimaldab lugeda ja kirjutada arveid, kliente ning laekumisi, liigutades e-arveid tervikliku XML-failina. AlusLabs ehitab selle peale liidestuse sinu e-poe, CRM-i või tabelitega.
Anna teada, milline faas peaks looma arve
Kirjuta paari lausega, millised süsteemid on kasutuses ja mis liigub praegu käsitsi. Ütleme ausalt, kas liidestust tasub ehitada ja millest alustada.