По данным Бюро национальной статистики, в 2025 году объём розничной электронной торговли в Казахстане составил почти 3,8 трлн тенге — на 19,4% больше, чем годом ранее, а доля онлайна в общей рознице достигла 14,3%. При этом на маркетплейсы пришлось около 3,2 трлн тенге, то есть 86% рынка, а через собственные интернет-ресурсы компаний прошло 531,3 млрд тенге. Эта вторая цифра интересует нас больше первой: полтриллиона тенге оборота идёт через сайты, которые кто-то должен наполнять товарами, ценами и остатками. И в большинстве случаев на казахстанском малом и среднем бизнесе это делает человек с выгрузкой из 1С и таблицей Excel.
Мы в West Star Ltd занимаемся интеграциями учётных систем с внешними сервисами и за последние годы разобрали десятки таких «ручных мостов» между 1С и сайтом. Тезис этой статьи простой: обмен товарами и ценами между 1С и сайтом — давно решённая инженерная задача, но решается она тремя принципиально разными способами, и выбор не тот, который обычно предлагают по умолчанию. Ошибка в выборе стоит не денег на внедрение, а нескольких лет мелких ежедневных потерь: неактуальные цены, заказы на отсутствующий товар и менеджер, который каждое утро полчаса «обновляет сайт».
ПОЧЕМУ РУЧНАЯ ВЫГРУЗКА ДЕРЖИТСЯ ТАК ДОЛГО
Ручной обмен выживает не из-за лени, а потому что он всегда работает «достаточно хорошо». Схема знакома: бухгалтер или менеджер формирует в 1С отчёт по номенклатуре, выгружает в Excel, правит колонки, отдаёт контент-менеджеру, тот загружает файл в админку сайта. Цикл занимает от двадцати минут до двух часов и повторяется раз в день, раз в неделю или, честно говоря, раз в никогда.
Проблема не в трудозатратах, а в задержке и в тихих ошибках. Между изменением цены в учётной системе и её появлением на сайте проходит от нескольких часов до нескольких недель. За это время клиент видит старую цену, оформляет заказ, менеджер звонит и объясняет, что «цена изменилась». В нашей практике такие звонки — одна из главных причин отказов в онлайне у компаний с непродуктовым ассортиментом. Вторая тихая потеря — остатки. Товар продан со склада, но на сайте он висит в наличии ещё сутки. Заказ принят, деньги иногда уже прошли, а отгружать нечего.
Третья категория ошибок — расхождение справочников. Ручная выгрузка почти всегда идёт по наименованию товара, а не по идентификатору. Кто-то переименовал позицию в 1С — на сайте появляется дубль. За два года у одного клиента мы насчитали 340 дублей карточек при реальном ассортименте в 1900 позиций.
ТРИ СПОСОБА СВЯЗАТЬ 1С И САЙТ
Способ первый — типовой обмен по стандарту CommerceML. Это официальный формат обмена от вендора 1С, актуальная версия — CommerceML 2.05. Технически всё устроено так: 1С формирует два XML-файла, import.xml с описанием структуры каталога и товаров и offers.xml с ценами и остатками, а сайт их принимает и разбирает. Обмен настраивается в самой конфигурации в разделе обмена с сайтом, поддержка со стороны CMS есть практически везде — от коробочных решений до популярных движков с плагинами.
Плюс подхода — он не требует программирования. Минус — это пакетный, файловый обмен. Он передаёт весь каталог или его изменённую часть по расписанию, обычно раз в час или реже. На каталоге в несколько десятков тысяч позиций полная выгрузка может занимать десятки минут и заметно нагружать и сервер 1С, и сайт. Отдельная боль — картинки: при включённом оптимизированном обмене изображениями вендор прямо рекомендует отключать выгрузку цен и остатков, чтобы процессы не перекрывались.
Способ второй — стандартный интерфейс OData. Начиная с версии платформы 8.3.5 1С:Предприятие умеет автоматически публиковать REST-интерфейс ко всем данным информационной базы по протоколу OData версии 3.0. Достаточно включить поддержку при публикации на веб-сервере — и справочники, документы и регистры становятся доступны по 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С через интернет?
Только при правильной настройке. Минимальный набор: отдельный пользователь с правами лишь на нужные объекты, ограниченный список публикуемых объектов, доступ через защищённое соединение и, желательно, отсутствие прямого выхода интерфейса в интернет — сайт обращается к промежуточному сервису, а тот уже к базе внутри периметра.
Как быть, если товары продаются и на сайте, и на маркетплейсах?
Строить один поток данных из учётной системы и раздавать его площадкам, а не делать отдельную интеграцию под каждую. Иначе цены и остатки разъедутся, а расхождение вы обнаружите по жалобе клиента или по штрафу площадки за отмену заказа.