Internetinės parduotuvės integracija su apskaita, sandėliu ir kurjeriais

Integruota internetinė parduotuvė turi vieną aiškų duomenų kelią: prekės ir likučiai atkeliauja iš patikimo šaltinio, užsakymai perduodami be rankinio kopijavimo, o sąskaitų bei siuntų būsenos grįžta klientui. Didžiausios problemos prasideda tada, kai neaišku, kuri sistema už ką atsakinga.

Trumpai, ką išsinešti

Integracijos projektas prasideda nuo duomenų žemėlapio, o ne nuo modulio pirkimo. Kiekvienam laukui reikia nustatyti šaltinį, kryptį, atnaujinimo dažnį, klaidos būseną ir atsakingą žmogų.

Viena sistema turi būti pagrindinis kiekvieno kritinio duomens šaltinis.
Užsakymo perdavimas laikomas baigtu tik gavus aiškų priėmimo atsakymą.
Klaidų žurnalas ir pranešimai yra integracijos dalis, o ne papildoma funkcija.

Pirmiausia nuspręskite, kuri sistema yra pagrindinė

Kai produktą, kainą ar likutį galima keisti keliose sistemose, anksčiau ar vėliau duomenys išsiskiria. Todėl kiekvienam laukui reikia pasirinkti pagrindinį šaltinį. ERP gali valdyti kodą, savikainą ir likutį, PIM – aprašymus bei atributus, o internetinė parduotuvė – SEO tekstus ir viešą produkto pateikimą.

Šis susitarimas turi būti užrašytas laukų lygiu. Bendras teiginys „produktai ateina iš apskaitos“ neatsako, kur kuriamas naujas produktas, kas valdo nuotraukas, ar galima redaguoti pavadinimą parduotuvėje ir kas nutinka kitą sinchronizaciją.

Duomenų savininkas taip pat yra žmogus arba komanda. Jei tiekėjo faile trūksta svorio, kažkas turi priimti sprendimą, ar prekė stabdoma, ar jai taikoma numatyta pristatymo taisyklė. Technika negali pati išspręsti neapibrėžto verslo proceso.

Produktų, kainų ir likučių srautas

Produktų integracija paprastai apima kodą, EAN, pavadinimą, kategoriją, gamintoją, atributus, variantus, kainą, mokesčius, likutį, svorį ir būseną. Kiekvienam laukui reikia formato, privalomumo ir validavimo taisyklės. Netinkamas skaičiaus skirtukas ar tuščias kategorijos kodas gali sustabdyti visą importą.

Kainoms svarbus prioritetas. Bazinė kaina, akcija, kliento kainoraštis ir kiekio nuolaida gali būti apskaičiuojami skirtingose sistemose. Jei parduotuvė gauna tik galutinę kainą, joje negalima savarankiškai atkartoti visų taisyklių. Jei gauna taisykles, reikia tiksliai suderinti jų eilę.

Likučių atnaujinimo dažnis priklauso nuo prekybos tempo. Vienam verslui pakanka kelių sinchronizacijų per dieną, kitam būtinas beveik realaus laiko rezervavimas. Reikia numatyti ir saugų scenarijų, kai šaltinis nepasiekiamas: rodyti paskutinį žinomą likutį, pristabdyti pirkimą ar pažymėti ilgesnį terminą.

Užsakymas turi būti perduotas kaip pilnas verslo dokumentas

Užsakymo integracija nėra vien numeris, prekės ir suma. Dažnai reikia kliento kodo, PVM mokėtojo duomenų, padalinio, vadybininko, pristatymo ir sąskaitos adresų, mokėjimo būdo, nuolaidų, kupono, pristatymo kainos, komentarų ir prekių variantų.

Prieš programavimą verta paimti kelis tikrus užsakymus: paprastą, su nuolaida, dalinai pristatomą, B2B su atidėtu mokėjimu ir užsienio klientą. Pagal juos sudaromas laukų žemėlapis ir patikrinama, ar priimanti sistema turi vietą visai informacijai.

Svarbus patvirtinimo atsakymas. Parduotuvė turi žinoti, ar užsakymas ERP sistemoje tikrai sukurtas ir kokį numerį gavo. HTTP atsakymas, kad užklausa pasiekė serverį, dar nereiškia, kad verslo dokumentas priimtas be klaidų.

Apskaita ir sąskaitos: kas ką sukuria

Prieš integruojant apskaitą reikia nuspręsti, kur sukuriama sąskaita. Jei ją formuoja ERP arba buhalterinė programa, parduotuvė perduoda užsakymą ir laukia dokumento numerio bei failo. Jei sąskaita kuriama parduotuvėje, apskaita turi priimti jos duomenis be dubliavimo.

Taip pat aprašykite kreditines sąskaitas, dalinius grąžinimus, atšaukimus ir apmokėjimo būsenas. Standartinis sėkmingas pirkimas yra tik viena proceso dalis. Daugiausia rankinio darbo atsiranda būtent išimtyse.

Klientui dokumentas turi būti pasiekiamas nuosekliai: el. laiške, paskyroje arba abiejose vietose. Jei dokumento generavimas vėluoja, sistema turi aiškiai parodyti būseną, o ne siųsti tuščią nuorodą.

Sandėlis, rezervacija ir kelių vietų logika

Keli sandėliai kelia klausimą, kokį likutį rodyti klientui. Galima sumuoti visus kiekius, rodyti konkrečią vietą arba apskaičiuoti pristatymo terminą pagal artimiausią sandėlį. Sprendimas priklauso nuo komplektavimo ir transporto proceso.

Rezervacija turi aiškų pradžios ir pabaigos momentą. Ar prekė rezervuojama pridėjus į krepšelį, pradėjus mokėjimą, gavus banko patvirtinimą, ar tik ERP priėmus užsakymą? Per ankstyva rezervacija užrakina prekes, per vėlyva gali sukelti perpardavimą.

Jeigu užsakymas komplektuojamas dalimis, reikia būsenų kiekvienai siuntai. Klientas turi suprasti, kurios prekės išsiųstos, kurios laukia ir ar gaus kelis sekimo numerius.

Mokėjimų ir kurjerių integracijos

Mokėjimo integracijoje svarbus ne tik nukreipimas į banką. Parduotuvė turi patikimai priimti serverio patvirtinimą, susieti jį su užsakymu ir apsisaugoti nuo pakartotinio pranešimo. Kliento grįžimo puslapis negali būti vienintelis apmokėjimo įrodymas, nes žmogus gali uždaryti langą.

Kurjerių integracija gali skaičiuoti pristatymo kainą, rodyti paštomatų sąrašą, registruoti siuntą, generuoti etiketę, grąžinti sekimo numerį ir perduoti būsenas. Kiekviena iš šių funkcijų turi būti aiškiai įtraukta į apimtį.

Testuojant reikia naudoti skirtingus adresus, paštomatų tipus, svorius, kelių pakuočių užsakymus ir grąžinimus. Vienas sėkmingas bandomasis užsakymas neparodo, kaip integracija elgsis realiame sezone.

Klaidos, pakartotiniai bandymai ir stebėjimas

Patikima integracija numato, kad ryšys kartais nutrūks, duomenys bus neteisingi arba kita sistema atsakys lėtai. Kiekviena operacija turi turėti unikalų identifikatorių, būseną, bandymų skaičių ir suprantamą klaidos tekstą.

Automatinis pakartojimas tinka laikiniems sutrikimams, bet ne duomenų klaidoms. Jei trūksta kliento kodo, šimtą kartų kartojama užklausa nieko neišspręs. Tokia klaida turi pasiekti atsakingą žmogų su nuoroda į konkretų užsakymą.

Stebėjimo lange svarbu matyti ne tik techninius pranešimus, bet ir verslo rodiklius: kiek užsakymų laukia perdavimo, kada paskutinį kartą atnaujinti likučiai, kiek produktų atmesta ir kodėl. Tai sutrumpina incidento paiešką nuo valandų iki minučių.

Testavimo planas prieš paleidimą

Integraciją testuokite atskiroje aplinkoje su realistiškais, bet ne produkciniais duomenimis. Paruoškite kontrolinį produktų rinkinį: paprastą prekę, variantą, akciją, nulį likučio, kelis mokesčių tarifus ir produktą su netinkamu lauku. Taip pat sukurkite skirtingų tipų klientus bei užsakymus.

Sutikrinkite sumas abiejose sistemose: prekių eilutes, nuolaidas, PVM, pristatymą ir galutinę sumą. Patikrinkite laiko zonas, valiutų apvalinimą, lietuviškus simbolius ir ilgus adresus. Smulki neatitiktis apskaitoje gali tapti kasdiene rankine korekcija.

Po paleidimo pirmąsias dienas verta stebėti kiekvieną kritinį srautą ir turėti aiškų grįžimo planą. Partner1 programavimo bei integracijų darbus planuoja kartu su verslo procesu, nes geriausias API kodas nepadės, jei nėra sutarta, ką jis turi perduoti.

Kontrolinis sąrašas

Duomenų žemėlapio kontrolinis sąrašas

Duomens pavadinimas ir verslo reikšmė
Pagrindinė sistema ir atsakingas žmogus
Perdavimo kryptis bei dažnis
Formatas, privalomumas ir validavimo taisyklė
Sukūrimo, atnaujinimo ir ištrynimo elgesys
Atsakymas, patvirtinantis sėkmingą priėmimą
Klaidos būsena ir automatinio pakartojimo taisyklė
Pranešimo gavėjas bei rankinio taisymo kelias
Testinis pavyzdys ir priėmimo kriterijus
Asmens duomenų bei prieigų apsauga

DUK

Dažniausi klausimai

Kiek kainuoja internetinės parduotuvės integracija?

Kainą lemia sistemų skaičius, API galimybės, laukų kiekis, verslo taisyklės ir klaidų valdymas. Tiksliai įvertinti galima gavus dokumentaciją bei sudarius duomenų žemėlapį.

Ar pakanka nusipirkti standartinį integracijos modulį?

Standartinis modulis tinka, kai procesas atitinka jo numatytą scenarijų. Prieš diegiant būtina patikrinti laukus, būsenas, kainodaros ir grąžinimų logiką.

Kaip dažnai reikia sinchronizuoti likučius?

Dažnis priklauso nuo pardavimų tempo, sandėlių ir perpardavimo rizikos. Sprendimas gali svyruoti nuo kelių kartų per dieną iki įvykių realiu laiku.