Kāds no mūsu ilggadējiem klientiem pagājušajā gadā piezvanīja ar vienu konkrētu problēmu: viņa grāmatveži katru rītu pavadīja apmēram stundu, pārrakstot WooCommerce pasūtījumus Jumis programmā. Pats par sevi tas nav nekas neparasts — tā strādā ļoti daudzi Latvijas e-komercijas uzņēmumi. Bet, kad apjoms sasniedz 80–100 pasūtījumus dienā, rokasdarbs kļūst par nopietnu kļūdu avotu un laika zuduša.
Šajā rakstā aprakstu, kā mēs šādu integrāciju veidojam praksē: ko var automatizēt, kur slēpjas sarežģītākās vietas, un ko vērts zināt pirms darba sākšanas.
Kāpēc Jumis un WooCommerce nerunā savā starpā “no kastes”
Jumis ir ļoti izplatīts grāmatvedības rīks Latvijā, bet tas tika veidots citā laikmetā un ar citiem mērķiem — galvenokārt darbam ar manuāli ievadītiem dokumentiem. WooCommerce savukārt ir dinamisks e-komercijas risinājums ar savu datu modeli, pasūtījumu statusiem un klientu loģiku.
Starp tiem nav standarta sinhronizācijas moduļa, ko varētu vienkārši instalēt un sākt lietot. Jumis piedāvā datu apmaiņu caur saviem XML un CSV formātiem, bet WooCommerce eksportē datus savā struktūrā. Vidū vajadzīgs slānis, kas saprot abas puses.
Mēs šādu slāni esam veidojuši vairākkārt — kā daļu no lielākām e-komercijas sistēmām un kā atsevišķu integrācijas moduli. Katrā gadījumā arhitektūra ir nedaudz atšķirīga, taču pamatprincipi paliek tie paši.
Kā izskatās tipiskā datu plūsma
Pirms runāt par tehniskajām detaļām, ir svarīgi saprast, ko tieši jūs vēlaties sinhronizēt un kurā virzienā. Praksē visbiežāk redzam trīs datu plūsmas:
No WooCommerce uz Jumis — pasūtījumi, klienti, maksājumi. Šis ir galvenais virziens: WooCommerce ir darījumu avots, Jumis — grāmatvedības sistēma. Kad klients veic pirkumu, šī informācija jāpārsūta uz Jumis, lai izveidotu rēķinu vai PVN dokumentu.
No Jumis uz WooCommerce — preces, krājumu daudzumi, cenas. Ja jūsu preču katalogs tiek uzturēts Jumis, tad izmaiņas tur jāatspoguļo veikalā. Tas ir sarežģītāks virziens, jo Jumis struktūra ne vienmēr iekļaujas WooCommerce loģikā bez tulkošanas.
Divvirzienu sinhronizācija — visgrūtākais scenārijs, kur mainās abu pušu dati. Te jādomā par konfliktiem un par to, kura sistēma ir “patiesības avots” konkrētam datu laukam.
Lielākajā daļā projektu mēs sākam ar vienu virzienu un paplašinām tikai tad, ja bizness to patiešām prasa.
Rēķinu ģenerēšana: automātiski pēc pasūtījuma
Viena no biežāk pieprasītajām funkcijām — automātisks rēķins Jumis pēc katras WooCommerce pārdošanas. Tas ir tehniski iespējams, un mēs to esam ieviesti vairākos projektos.
Praktisks piemērs: WooCommerce pasūtījumam ir statuss processing (maksājums saņemts). Šajā brīdī webhook vai fona process nodod pasūtījuma datus mūsu integrācijas slānim. Slānis pārveido tos Jumis atpazīstamā formātā (parasti XML vai strukturētā CSV) un ievieto failu Jumis importa mapē vai izsauc API, ja jūsu Jumis versija to atbalsta.
Kam jāpievērš uzmanība:
- Klienta dati: Jumis strādā ar klienta kartītēm. Ja klients jau pastāv, vēlaties to saistīt, nevis radīt dublikātu. Tas nozīmē unikālu identifikatoru — parasti e-pasta adrese vai reģistrācijas numurs.
- Maksājuma metode: skaidra nauda, kartes maksājums, rēķins ar atliktu termiņu — Jumis šos variantus apstrādā atšķirīgi.
- Pasūtījuma atcelšana vai labošana: ja klients atceļ pasūtījumu vai maina daudzumu, Jumis pusē jāveido kredītrēķins. Šo loģiku bieži aizmirst projektēšanas posmā, bet tā ir kritiska.
Mēs parasti veidojam šo procesu asinhroni — pasūtījums vispirms nonāk rindā, tad tiek apstrādāts. Tas nozīmē, ka nelielas kavēšanās ir pieļaujamas, bet nekas nepazūd pat tad, ja Jumis sistēma īslaicīgi nav pieejama.
PVN un Latvijas nodokļu loģika
Šis ir punkts, kur daudzi projekti apstājas ilgāk, nekā plānots. Latvijā PVN aprēķins WooCommerce pusē un Jumis dokumentos ne vienmēr sakrīt automātiski, īpaši ja jums ir:
- B2B un B2C klienti ar atšķirīgu PVN režīmu
- ES klienti no citām valstīm (OSS shēma)
- Atbrīvojumi no PVN atsevišķām preču grupām
- Importa darījumi vai īpaši nodokļu kodi
WooCommerce PVN iestatījumi ir diezgan elastīgi, bet tie jākonfigurē precīzi atbilstoši tam, kā jūsu grāmatvedis to sagaida Jumis pusē. Es parasti pirmo integrācijas sesiju vadu kopā ar grāmatvedi — nevis tāpēc, ka nevaru iztikt bez tā, bet tāpēc, ka pirmajā brīdī vienmēr iznāk detaļas, kuras neviens nav minējis tehniskajā uzdevumā.
Konkrēts piemērs no prakses: viens no mūsu klientiem izmantoja atšķirīgus PVN procentus dažādiem preču veidiem (standarta 21% un samazinātais 12% dažiem produktiem). WooCommerce to apstrādāja pareizi, bet CSV eksports sapludināja kopsummas tā, ka Jumis importēja visu ar vienu PVN likmi. Šādu kļūdu grāmatveidis pamana pirmajā dienā, bet tā var radīt diezgan nopietnas problēmas, ja paliek nepamanīta.
Krājumu sinhronizācija: kas jāzina pirms sākšanas
Krājumu daudzumu sinhronizācija ir tehniski vienkāršāka konceptuāli, bet praksē — bieži sarežģītāka organizatoriski. Problēmas rodas nevis kodā, bet procesos.
Pirmais jautājums: cik bieži sinhronizēt? Reāllaikā? Ik stundu? Nakts laikā?
Ja jūsu veikalā ir preces ar mazu krājumu (piemēram, 3–5 vienības), tad reāllaika vai bieža sinhronizācija ir būtiska — citādi klients var nopirkt preci, kuras vairs nav. Ja krājumi ir lieli un kustība lēna, nakts atjauninājums bieži ir pietiekams un daudz vienkāršāk uzturams.
Otrais jautājums: kurā virzienā krājumi mainās?
Ja preces noliktavā tiek koriģētas manuāli Jumis pusē (piemēram, inventarizācijas rezultātā), šīs izmaiņas jāatspoguļo WooCommerce. Ja preces tiek pārdotas arī citā veidā ārpus e-komercijas — klātienē, pa telefonu — tad WooCommerce krājums bez sinhronizācijas ātri vien kļūst neprecīzs.
Treš jautājums: kas notiek ar krājuma rezervāciju?
WooCommerce var rezervēt krājumu brīdī, kad klients pievieno preci grozam vai kad uzsāk maksājumu. Ja Jumis to nezina, var rasties situācija, kad viens un tas pats vienums tiek pārdots divreiz.
Mēs šos scenārijus izspēlējam ar klientu kā “kas notiks, ja…” pirms tehniskās īstenošanas. Parasti tieši šajā posmā noskaidrojas, ka uzņēmuma iekšējais process ir jāprecizē, nevis tikai jāautomatizē esošais.
Tehniskā arhitektūra: kā mēs to veidojam
Konkrēts risinājums ir atkarīgs no vairākiem faktoriem: Jumis versija (jo vecāks, jo mazāk integrācijas iespēju), servera vide, prasītā sinhronizācijas biežuma, kā arī no tā, vai uzņēmumam ir kāda iekšējā IT komanda, kas uzturēs sistēmu.
Parasti mēs veidojam atsevišķu web izstrāde komponentu — nelielu PHP vai Node.js pakalpojumu — kas darbojas kā starpnieks. Tas klausās WooCommerce webhookus, apstrādā datus un ieraksta tos Jumis importa formātā. Jumis puse parasti nolasa failus no noteiktas mapes — tā ir vienkāršākā un uzticamākā integrācijas metode vecākām Jumis versijām.
Jaunākās Jumis versijās ir pieejams REST API, kas ļauj datus nodot tieši. Tas ir tīrāks risinājums, bet prasa papildu autentifikāciju un rūpīgāku kļūdu apstrādi.
Mēs vienmēr veidojam:
- Kļūdu žurnālu ar iespēju atkārtoti apstrādāt neizdevušos darījumus
- Brīdinājumus (e-pasts vai Slack), ja integrācija pārstāj darboties
- Manuālu palaišanas iespēju konkrētam pasūtījumam vai datumu diapazonam — tas nenovērtējami palīdz tad, kad vajag atkārtoti importēt datus pēc grāmatvedības korekcijām
Šādi risinājumi mums parasti aizņem 40–80 stundu darbu atkarībā no sarežģītības. Tas nav lēts, bet tas arī nav vienreizējs projekts — mēs parasti paliekam pieejami ilgtermiņā, kā arī pie visiem pārējiem pakalpojumi, ko uzturams.
Kā mēs varam palīdzēt
FSM Studio ir strādājusi ar Latvijas e-komercijas projektiem kopš 2006. gada. Es personīgi esmu vadījis integrācijas ar Jumis, 1C un Moneo — un zinu, ka katrs projekts atšķiras. Nav universāla risinājuma, ko var vienkārši instalēt.
Ja jūsu situācija ir līdzīga — pasūtījumi tiek ievadīti manuāli, krājumi netiek sinhronizēti vai rēķini rodas ar aizkavēšanos — rakstiet mums un apspriedīsim, kas jūsu gadījumā ir saprātīgākais solis. Nav nepieciešams uzreiz runāt par pilnu integrāciju — dažkārt pietiek ar vienu konkrētu automatizāciju, kas atrisina 80% no problēmas.
Varat arī apskatīt, kā mēs strādājam pie e-komercijas projektiem kopumā, vai uzzināt vairāk par SEO iespējām jūsu veikalam.
