Ұлттық статистика бюросының деректері бойынша, 2025 жылы Қазақстандағы бөлшек электрондық сауданың көлемі 3,8 трлн теңгеге жуықтады — бұл бір жыл бұрынғыдан 19,4%-ға көп, ал онлайнның жалпы бөлшек саудадағы үлесі 14,3%-ға жетті. Сонымен бірге маркетплейстерге шамамен 3,2 трлн теңге, яғни нарықтың 86%-ы тиесілі болды, ал компаниялардың өз интернет-ресурстары арқылы 531,3 млрд теңге өтті. Бізді бірінші саннан гөрі осы екінші сан көбірек қызықтырады: жарты триллион теңге айналым біреу тауарлармен, бағалармен және қалдықтармен толтырып отыруы тиіс сайттар арқылы өтеді. Ал қазақстандық шағын және орта бизнесте көп жағдайда мұны 1С-тен алынған экспорт файлы мен Excel кестесі бар адам атқарады.
Біз West Star Ltd-те есеп жүйелерін сыртқы сервистермен интеграциялаумен айналысамыз және соңғы жылдары 1С пен сайт арасындағы мұндай ондаған «қолмен жасалған көпірді» талдадық. Бұл мақаланың тезисі қарапайым: 1С пен сайт арасында тауарлар мен бағаларды алмасу — әлдеқашан шешілген инженерлік міндет, бірақ ол түбегейлі әртүрлі үш тәсілмен шешіледі, әрі дұрыс таңдау әдетте әдепкі бойынша ұсынылатын нұсқа емес. Таңдаудағы қателік енгізуге жұмсалатын ақшамен емес, бірнеше жылғы ұсақ күнделікті шығындармен өлшенеді: өзекті емес бағалар, жоқ тауарға түскен тапсырыстар және күн сайын таңертең жарты сағат бойы «сайтты жаңартатын» менеджер.
НЕЛІКТЕН ҚОЛМЕН ЭКСПОРТТАУ СОНШАЛЫҚТЫ ҰЗАҚ САҚТАЛАДЫ
Қолмен алмасу жалқаулықтан емес, әрдайым «жеткілікті жақсы» жұмыс істейтіндіктен сақталып келеді. Схема таныс: бухгалтер немесе менеджер 1С-те номенклатура бойынша есеп қалыптастырады, оны Excel-ге экспорттайды, бағандарды түзетеді, контент-менеджерге береді, ал ол файлды сайттың әкімшілік бөліміне жүктейді. Цикл жиырма минуттан екі сағатқа дейін созылады және күніне бір рет, аптасына бір рет қайталанады, ал шынын айтсақ, кейде мүлде қайталанбайды.
Мәселе еңбек шығынында емес, кешігуде және байқалмайтын қателерде. Есеп жүйесінде баға өзгергеннен бастап оның сайтта пайда болуына дейін бірнеше сағаттан бірнеше аптаға дейін уақыт өтеді. Осы уақыт ішінде клиент ескі бағаны көреді, тапсырыс береді, менеджер қоңырау шалып, «баға өзгергенін» түсіндіреді. Біздің тәжірибемізде мұндай қоңыраулар — азық-түлік емес ассортименті бар компаниялардағы онлайн бас тартулардың басты себептерінің бірі. Екінші байқалмайтын шығын — қалдықтар. Тауар қоймадан сатылып кетті, бірақ сайтта ол тағы бір тәулік бойы қолда бар болып тұрады. Тапсырыс қабылданды, ақша кейде тіпті түсіп те қойды, ал жөнелтетін ештеңе жоқ.
Қателердің үшінші санаты — анықтамалықтардың сәйкес келмеуі. Қолмен экспорттау әрдайым дерлік идентификатор бойынша емес, тауардың атауы бойынша жүреді. Біреу 1С-те позицияның атауын өзгертті — сайтта телнұсқа пайда болады. Бір клиентте екі жыл ішінде нақты ассортимент 1 900 позиция болғанда біз карточкалардың 340 телнұсқасын санадық.
1С ПЕН САЙТТЫ БАЙЛАНЫСТЫРУДЫҢ ҮШ ТӘСІЛІ
Бірінші тәсіл — CommerceML стандарты бойынша типтік алмасу. Бұл 1С вендорының ресми алмасу форматы, өзекті нұсқасы — CommerceML 2.05. Техникалық тұрғыдан бәрі былай құрылған: 1С екі XML-файл қалыптастырады — каталог пен тауарлардың құрылымын сипаттайтын import.xml және бағалар мен қалдықтар бар offers.xml, ал сайт оларды қабылдап, талдайды. Алмасу конфигурацияның өзінде сайтпен алмасу бөлімінде бапталады, CMS тарапынан қолдау іс жүзінде барлық жерде бар — қорапты шешімдерден бастап плагиндері бар танымал қозғалтқыштарға дейін.
Бұл тәсілдің артықшылығы — бағдарламалауды қажет етпейді. Кемшілігі — бұл пакеттік, файлдық алмасу. Ол бүкіл каталогты немесе оның өзгерген бөлігін кесте бойынша, әдетте сағатына бір рет немесе одан да сирек береді. Бірнеше ондаған мың позициядан тұратын каталогта толық экспорттау ондаған минутқа созылуы және 1С серверіне де, сайтқа да айтарлықтай жүктеме түсіруі мүмкін. Суреттер — бөлек бас ауруы: суреттермен оңтайландырылған алмасу қосулы болғанда, вендор процестер бір-бірін жаппауы үшін бағалар мен қалдықтарды экспорттауды өшіруді тікелей ұсынады.
Екінші тәсіл — стандартты OData интерфейсі. Платформаның 8.3.5 нұсқасынан бастап 1С:Предприятие ақпараттық базаның барлық деректеріне OData 3.0 нұсқасы протоколы бойынша REST-интерфейсті автоматты түрде жариялай алады. Веб-серверде жариялау кезінде қолдауды қоссаңыз болғаны — анықтамалықтар, құжаттар мен регистрлер HTTP арқылы, Atom/XML немесе JSON форматындағы жауаптармен қолжетімді болады. Конфигурацияға ештеңе жазудың қажеті жоқ, база типтік жаңартуда қалады.
Бұл — ең жете бағаланбаған нұсқа. Сайт немесе аралық сервис 1С-тен өзіне дәл қажетті деректерді және дәл қажет кезде сұратады: карточканы ашқанда нақты позицияның бағасын, себетке қосқанда қалдықты, клиент хабарласқанда тапсырыстың мәртебесін. Каталогтың көшірмесін сақтаудың да, кезекті экспорттауды күтудің де қажеті жоқ.
Үшінші тәсіл — аралық қабат арқылы оқиғалық интеграция. Мұнда 1С пен сайттың арасына жеке сервис орнатылады, ол есеп жүйесінен деректерді алады (көбіне сол OData арқылы), оларды қажетті құрылымға келтіреді, кэштейді және сайтқа дайын күйінде береді, ал кері бағытта тапсырыстарды қабылдап, оларды 1С-ке салады. Бұл әзірлеуде қымбатырақ, бірақ алғашқы екі тәсілдің басты шектеулерін жояды: сайт 1С-ке тікелей сұраулармен жүктеме түсірмейді, ал деректерді түрлендірудің бизнес-логикасы есеп жүйесінен бөлек өмір сүреді және конфигурация жаңартылғанда бұзылмайды.
ҚАЛАЙ ТАҢДАУҒА БОЛАДЫ
Біз келген практикалық ереже: екі нәрсеге қараңыз — каталогтың көлеміне және деректердің талап етілетін жаңалығына.
Егер сізде бірер мың позицияға дейін болса, бағалар аптасына бір рет өзгерсе, қалдықтар шешуші емес болса (тапсырыс бойынша тауар, қызметтер, жобалық жеткізілімдер) — CommerceML бойынша типтік алмасуды алыңыз. Ол бір күнде бапталады, әзірлеушіні қажет етпейді және міндетті толық шешеді.
Егер позициялар көп болса, бағалар динамикалық немесе қалдықтар шешуші болса (бөлшек сауда, қосалқы бөлшектер, құрылыс материалдары) — деректерді нақты уақытта сұрату қажет, яғни OData тікелей немесе аралық қабат арқылы. Нұсқалардың айырмашылығы — сайтты 1С базасына жіберуге дайынсыз ба, жоқ па. Біз әрдайым дерлік аралық қабатты ұсынамыз: ол кэш, сұраулар жиілігін шектеу, журналдау және сайтқа тиіспей-ақ деректер көзін ауыстыру мүмкіндігін береді.
Бөлек сценарий — компанияның әрі сайты, әрі маркетплейстері болғанда. Елдегі онлайн-айналымның 86%-ы маркетплейстер арқылы өтетінін ескерсек, мұндай конфигурация ерекшелік емес, ереже деуге болады. Бұл жерде екі тәуелсіз алмасу құру — қателік. Ақиқат көзі біреу болуы керек, ал алаңдар бір ғана деректер ағынының тұтынушылары болуы тиіс, әйтпесе сайттағы баға мен маркетплейстегі баға сөзсіз алшақтайды.
БҰЛ УАҚЫТ ЖАҒЫНАН ҚАНШАҒА ТҮСЕДІ
Бюджет туралы әңгіме нақты болуы үшін біздің жобалардан алынған бағдарлар. Өзгертілмеген конфигурацияда және дайын модулі бар сайтта типтік файлдық алмасуды баптау — бірнеше сағаттан бір жұмыс күніне дейін, негізгі уақыт баптауға емес, анықтамалықтарды салыстыруға кетеді. Базаны веб-серверде жариялап, стандартты интерфейсті қосу және қызметтік пайдаланушының құқықтарын баптау — инфрақұрылым бұрыннан бар болса, әдетте жарты күн, ал база жаңадан орналастырылса, бірнеше күн.
Аралық сервиспен интеграция — мүлдем басқа ауқым: каталогқа, бағаларға, қалдықтарға және тапсырыстарды қабылдауға екі-төрт апта, оған қоса жүктеме астында тестілеуге уақыт. Бұл сметада әдетте ең көп орынды код емес, деректерді дайындау алады: телнұсқаларды тазалау, жетіспейтін деректемелерді толтыру, қай баға түрі витриналық болып саналатыны туралы шешім. Ассортименті шамамен екі мың позиция болатын жобада бұл дайындық бізде алмасуды әзірлеудің өзінен үш есе көп уақыт алды, және бұл ерекшелік емес, қалыпты арақатынас.
ӘДЕТТЕ НЕНІ ЕСКЕРУДІ ҰМЫТАДЫ
Идентификаторлар. 1С-тегі позиция мен сайттағы карточка арасындағы байланыс атау немесе артикул бойынша емес, объектінің бірегей идентификаторы бойынша жүруі керек. Артикулдар қайталанады және өзгереді, атаулар — одан бетер.
Кері ағын. Алмасу — тек «тауарлар сайтқа» ғана емес, сонымен бірге «тапсырыстар 1С-ке». Біз көрген енгізулердің жартысы тек бірінші бағытты жасайды, ал менеджер әкімшілік бөлімнен тапсырыстарды қолмен енгізуді жалғастыра береді.
Баға ережелері. 1С-те әдетте бірнеше баға түрі, контрагенттер бойынша жеңілдіктер, акциялар болады. Сайтқа қай баға түрі кететінін және өзіндік құнынан төмен немесе нөлдік бағалармен не болатынын алдын ала шешіңіз — олар витринаға мүлдем түспеуі тиіс.
Қателерді өңдеу. Алмасу істен шықса, бұл туралы кім біледі? Мониторинг пен хабарлама қажет, әйтпесе сайт екі апта бойы ескірген деректермен жұмыс істейді, мұны сіз емес, клиент байқайды.
ШЕКТЕУЛЕР МЕН ӘЛСІЗ ТҰСТАР
Бұл автоматтандыру қай жерде мінсіз емес екені туралы шынын айтайық.
— OData деректерді сайтқа ыңғайлы құрылымда емес, 1С құрылымында береді. Деректемелер орысша аталады, басқа объектілерге сілтемелер идентификаторлармен келеді, бағалар бөлек регистрлерде жатады. Түрлендіру қабаты болмаса, сайт әзірлеушісі әбден қиналады, ал логика фронтенд бойынша шашырап кетеді.
— Өнімділік 1С-ке тіреледі. Стандартты OData интерфейсі үлкен іріктемелерде жылдамдығымен ерекшеленбейді, ал сүзгілеу мен сұрыптау 1С серверінің тарапында орындалады. Трафик өскенде кэш болмаса, сіз баяу жұмыс істейтін сайт пен бухгалтерияның база баяулап кетті деген шағымдарын аласыз.
— Қауіпсіздік бөлек жұмысты талап етеді. OData-ны жариялау базаның барлық объектілеріне, соның ішінде сайтқа мүлдем қажетсіздеріне де қолжетімділік ашады. Құқықтары шектелген жеке қызметтік пайдаланушы, жарияланатын объектілер құрамын шектеу және интерфейсті сыртқы әлемнен жабу қажет.
— Конфигурация жаңартулары интеграцияларды бұзады. 1С-тегі кез келген пысықтау — алмасу тәуелді болатын объект құрылымының өзгеру тәуекелі. Толық типтік схемаларға бұл азырақ қатысты, бірақ пысықталған конфигурацияда регрессия сөзсіз дерлік және әр жаңартудан кейін регламенттік тестілеуді талап етеді.
— Деректердің жаңалығы тегін болмайды. Нақты уақыт базаға тұрақты жүктемені білдіреді. Өзектілік пен өнімділік арасындағы ымыраны саналы түрде таңдауға тура келеді: қалдықтарды лезде емес, бес минутта бір рет жаңартуға болады, және жағдайлардың 95%-ында бұл жеткілікті.
— Автоматтандыру есептегі ретсіздікті түзетпейді. Егер 1С-те номенклатура нашар жүргізілсе — телнұсқалар, бос деректемелер, бағасы жоқ тауарлар — сайтқа дәл сол ретсіздік, тек жылдамырақ әрі бірден барлық бағытқа кетеді. Анықтамалықтарды ретке келтіру интеграцияның өзінен әрдайым дерлік көп уақыт алады.
НЕ ІСТЕУ КЕРЕК
Маманға. Түгендеуден бастаңыз: қанша позиция, қандай баға түрлері, қоймалар қайда, конфигурацияда пысықтаулар бар ма. База веб-серверде жарияланған ба және OData қолдауы қосулы ма, тексеріңіз — инфрақұрылымның жартысы бұрыннан бар болып шығатыны жиі кездеседі. Код жазбас бұрын объектілерді байланыстыру кілті туралы және алмасу қателерімен не істеу керектігі туралы келісіп алыңыз.
Басшыға. Қолмен орындалатын процестің қазіргі құнын өлшеңіз: аптасына экспорттауға қанша сағат кетеді, қате баға немесе тауардың жоқтығы салдарынан айына қанша тапсырыс жойылады. Осы екі сан — бюджеттің негіздемесі. Мердігерден тек «каталогты экспорттауды» емес, екі жақты алмасу мен мониторингті талап етіңіз.
Меншік иесіне. Негізгі сұрақ «интеграциялау керек пе, жоқ па» емес, «ақиқат көзі қайда». Егер тауарлар, бағалар мен қалдықтар туралы деректер бір мезгілде 1С-те, сайтта және маркетплейстердің кабинеттерінде өмір сүріп, үш жерде түзетілсе — ешқандай интеграция мұны құтқармайды. Жалғыз деректер көзі туралы шешім әзірлеуші деңгейінде емес, компания деңгейінде қабылданады.
ЖИІ ҚОЙЫЛАТЫН СҰРАҚТАР
Сайтпен алмасу үшін 1С конфигурациясын пысықтау қажет пе?
CommerceML бойынша типтік алмасу және стандартты OData интерфейсі үшін — жоқ. Екі механизм де платформаға және типтік конфигурацияларға кірістірілген. Пысықтау стандартты емес логика қажет болғанда керек: витринаға арналған баға белгілеудің өз ережелері, тапсырыстар бойынша ерекше мәртебелік құжат айналымы, бірнеше қойманы бір қалдыққа біріктіру.
Нені тезірек енгізуге болады — файлдық алмасуды ма, әлде OData-ны ма?
CommerceML бойынша файлдық алмасу, егер сайт оны қосымша пысықтаусыз қолдаса, тезірек, көбіне бір жұмыс күнінде бапталады. OData арқылы интеграция сайт немесе аралық сервис тарапында әзірлеуді талап етеді және бір аптадан бастап уақыт алады. Бірақ ол пакеттік алмасу негізінен бере алмайтын деректер өзектілігін береді.
1С базасына интернет арқылы қолжетімділік ашу қауіпсіз бе?
Тек дұрыс бапталған жағдайда ғана. Ең аз жиынтық: тек қажетті объектілерге ғана құқығы бар жеке пайдаланушы, жарияланатын объектілердің шектеулі тізімі, қорғалған байланыс арқылы қолжетімділік және, жақсысы, интерфейстің интернетке тікелей шықпауы — сайт аралық сервиске жүгінеді, ал ол периметр ішіндегі базаға жүгінеді.
Тауарлар әрі сайтта, әрі маркетплейстерде сатылса, не істеу керек?
Әр алаңға жеке интеграция жасамай, есеп жүйесінен бір деректер ағынын құрып, оны алаңдарға тарату керек. Әйтпесе бағалар мен қалдықтар алшақтайды, ал айырмашылықты сіз клиенттің шағымынан немесе тапсырысты жойғаны үшін алаң салған айыппұлдан білесіз.