Pagājušā gada sākumā mums zvanīja klients no Rīgas — ražošanas uzņēmums ar aptuveni 2000 preču nosaukumu savā 1C. Viņi bija noslēguši līgumu ar kādu izstrādes komandu, kas solīja automātisku produktu sinhronizāciju ar jauno WooCommerce veikalu. Pēc četriem mēnešiem izrādījās, ka produkti sinhronizējas, bet cenas — tikai dažreiz. Atlikumi nāk ar 3–4 stundu nokavēšanos. Pasūtījumu statusi atgriežas atpakaļ uz 1C tikai ar manuālu pieskārienu. Viss izskatījās strādājošs demonstrācijā, bet reālas noslodzes apstākļos sāka plīst.
Tas nav retums. Pēdējo 20 gadu laikā, strādājot ar Latvijas uzņēmumiem, esmu redzējis šo scenāriju atkal un atkal. 1C ir fundamentāls rīks daudziem uzņēmumiem šeit, un mājaslapas vai e-komercijas risinājumi joprojām ir jāintegrē ar to. Problēma nav pašā 1C — problēma ir integrācijas pieeja.
Kāpēc 1C integrācija ir sarežģītāka nekā izskatās
1C versiju bāze Latvijā ir raiba. Jums var būt 1C:Предприятие 8.2, 8.3, vai kāda lokalizēta konfigurācija, ko uzturēja vietējais 1C partneris pirms 10 gadiem. Katrai no tām ir atšķirīga datu struktūra, atšķirīgs API pieejamības līmenis, un ne visās ir iespējots web-serviss pēc noklusējuma.
Vēl lielāka problēma — 1C dati bieži nav tīri. Klients ar 1500 precēm var izrādīties ar 300 dublikātiem, 50 precēm bez SKU, un cenu sarakstu, kur vienas un tās pašas preces cena mainās atkarībā no pircēja kategorijas. Ja integrācijas kods ir naivi uzrakstīts, tas vai nu neizdodas klusēdams, vai ielādē katrā sinhronizācijā visu no jauna, vai — sliktākajā gadījumā — sāk rakstīt nepareizas cenas publiski redzamajā veikalā.
Mēs esam redzējuši visus trīs scenārijus. Trešais ir visvairāk stresainais gan klientam, gan mums.
Biežākie punkti, kur integrācija salūst
Atlikumu desinhronizācija. Šis ir klasiskais gadījums. Noliktava atjaunina 1C, bet mājaslapa to uzzina ar kavēšanos. Tikmēr klients ir nopircis preci, kas patiesībā ir izpārdota. Labojums nav tikai ātrāks sinhronizācijas intervāls — tas ir arī rezervācijas mehānisms: kad pasūtījums ienāk mājaslapā, atlikums jāieraksta kā rezervēts uzreiz, neatkarīgi no tā, vai 1C jau ir atjaunots.
Cenu grupu loģika. Lielākajai daļai 1C konfigurāciju ir vairākas cenu grupas — vairumtirdzniecība, mazumtirdzniecība, pastāvīgie klienti. Mājaslapas puse bieži tiek integrēta tikai ar vienu no tām. Tas strādā, kamēr klients nevēlas, lai autentificētiem lietotājiem rādītu vairumcenas. Tad pēkšņi izrādās, ka integrācija šo loģiku nemaz neatbalsta.
Produktu hierarhija. 1C var glabāt preces ar sarežģītu grupu struktūru — kategorijas, apakškategorijas, nomenklatūras grupas. Mājaslapas katalogam šī struktūra bieži jāattēlo citādāk. Ja integrācija to neatrisina sākotnēji, kategorizācija mājaslap pusē kļūst par manuālu darbu pie katra kataloga atjauninājuma.
Pasūtījumu atgriešana. Sūtīt pasūtījumu no mājaslapas uz 1C ir viena lieta. Saņemt atpakaļ statusa maiņas — ka prece nosūtīta, ka rēķins ir apmaksāts — ir pavisam cita. Daudzas integrācijas ir vienpusējas: mājaslapa sūta uz 1C, bet 1C nekad neatbild.
Kļūdu apstrāde. 1C web-serviss var neatbildēt. Var mainīties datu formāts pēc konfigurācijas atjauninājuma. Var beigties atļaujas. Ja integrācijas kods nav rakstīts ar skaidru kļūdu žurnālu un retry loģiku, jūs uzzināsiet par problēmu nevis no sistēmas, bet no klientiem, kas zvana un saka: “Mana prece vēl joprojām rāda kā pieejama, bet mani neinformēja par saņemto pasūtījumu.”
Kā mēs pieejam 1C integrācijai
Mūsu pieeja attīstījusies gadu gaitā, strādājot ar konkrētiem Latvijas uzņēmumiem un viņu 1C konfigurācijām. Nav universāla risinājuma, bet ir principi, kas strādā.
Pirms koda rakstīšanas mēs veicam datu auditu. Pieprasām 1C eksportu un skatāmies, kas tajā ir. Cik ir dublikātu? Kādas cenu grupas ir aktīvas? Kā izskatās produktu hierarhija? Šis solis atklāj lielāko daļu problēmu, ko citādi atklātu tikai ražošanā.
Sinhronizācija tiek veidota ar žurnālu. Katrs sinhronizācijas skrējiens ieraksta, kas tika saņemts, kas mainīts, kas bija kļūdā. Ja kaut kas izjūk pēc 1C atjauninājuma, mums ir precīzs izmeklēšanas punkts, nevis minēšana.
Mēs neatbalstām tiešu savienojumu ar 1C no mājaslapas servera. Starp abiem sistēmām parasti ir buferis — vai nu queue, vai starppakalpojums. Tas nozīmē, ka 1C restarts vai lēna atbilde neaptur pasūtījumu pieņemšanu mājaslapā.
Pasūtījumu statusi tiek sinhronizēti abos virzienos. Tas prasa vairāk darba, bet bez tā pārdošanas nodaļa strādā ar divām sistēmām vienlaikus, manuāli pārsūtot informāciju.
Ko nozīmē “strādājoša” integrācija
Viena lieta ir panākt, lai dati nāktu cauri. Cita — lai sistēma uzvedas pareizi, kad kaut kas notiek nepareizi.
Piemēram: ko dara jūsu mājaslapa, ja 1C nav pieejams 20 minūtes? Vai tā parāda kļūdu katram apmeklētājam? Vai aptur pasūtījumu pieņemšanu? Vai darbojas pēc pēdējo saglabāto datu pēkšņas? Šis lēmums jāpieņem izstrādē, nevis krīzes brīdī.
Vēl viens jautājums — sinhronizācijas biežums. Ne vienmēr “biežāk = labāk”. Ja 1C konfigurācija ir lēna un jums ir 3000 preču, ik minūtes pilna sinhronizācija var radīt lielāku slodzi nekā ieguvumu. Labāk ir delta sinhronizācija — tikai mainīto ierakstu pārsūtīšana — kombinācijā ar webhook notifikācijām kritiski svarīgiem notikumiem, piemēram, atlikuma nullei.
Tehniskie varianti 2026. gadā
1C piedāvā vairākus savienojuma veidus, un izvēle atkarīga no jūsu konkrētās konfigurācijas.
HTTP web-servisi (OData vai pašrakstīti) ir biežāk izmantotais variants mājaslapa-puse. Ja jūsu 1C konfigurācija atbalsta šo un ir pareizi konfigurēta, tas ir stabils pamats. Problēma — ne visas konfigurācijas to atbalsta pēc noklusējuma, un dažos gadījumos jāpieaicina 1C speciālists, lai to iespējotu.
CommerceML / XML apmaiņa ir vecāks, bet joprojām izplatīts variants, īpaši 1C:Tirdzniecība konfigurācijās. Daudzi Latvijas WooCommerce izstrādātāji izmanto tieši šo ceļu. Tas darbojas, bet formāts ir neveikls un mazāk elastīgs nekā REST pieeja.
Starpprogrammatūra jeb middleware — piemēram, atsevišķs sinhronizācijas serviss — ir labākā izvēle, ja jums ir sarežģīta biznesa loģika vai vairākas sistēmas, kas jāsinhronizē ar 1C vienlaikus. Mēs izmantojam šo pieeju projektiem, kur ir gan mājaslapa, gan CRM, gan varbūt Moneo grāmatvedības modulis.
Mūsu komanda ir strādājusi ar visiem trim variantiem dažādos e-komercijas projektos. Nav vienatā pareizā varianta — ir pareizais variants konkrētam uzņēmumam un konkrētai 1C versijai.
Jautājumi, ko uzdot pirms projekta sākšanas
Ja jūs domājat par 1C integrāciju vai esat neapmierināts ar esošo, šeit ir jautājumi, kas palīdz saprast realitāti.
Kāda ir jūsu 1C versija un konfigurācija? Tas nosaka, kādas integrācijas iespējas vispār pastāv. Vai ir pieejams 1C speciālists, kas var veikt konfigurācijas izmaiņas 1C pusē, ja nepieciešams? Mājaslapa puse var būt ideāli uzrakstīta, bet, ja 1C web-serviss nav iespējots, tas nepalīdz.
Kāds ir pieļaujamais sinhronizācijas aizkavējums? Atlikumiem reāllaikā vajadzīga cita pieeja nekā cenu sinhronizācijai, kur pietiek ar vienu reizi dienā. Vai pasūtījumiem jānonāk 1C automātiski? Un kā jūs vēlaties apstrādāt gadījumu, kad integrācija ir uz laiku nepieejama?
Šie jautājumi nav formāli. Tie nosaka, cik sarežģīta un attiecīgi — cik dārga būs integrācija.
Kā mēs varam palīdzēt
FSM Studio kopš 2006. gada ir strādājis ar Latvijas uzņēmumiem, kam nepieciešama web izstrāde ar reālām integrācijām — ne tikai mājaslapas, kas izskatās labi, bet sistēmas, kas strādā ar jūsu esošajiem procesiem. 1C integrācija ir viens no mūsu regulārajiem uzdevumiem, un mēs zinām, kādas kļūdas sagaida ceļā.
Ja jūsu situācija ir līdzīga tam, ko esmu aprakstījis — vai jau esat iesprūdis vidū ar integrāciju, kas nedarbojas stabili — rakstiet mums un apspriedīsim konkrētus soļus. Pirms piedāvājuma mēs parasti uzdodam 3–4 konkrētus jautājumus par jūsu 1C konfigurāciju, lai saprastu, ar ko strādājam. Tas ietaupa laiku abiem.
Varat apskatīt arī mūsu pakalpojumus — tur ir plašāks apraksts par to, kādos projektos mēs specializējamies.
