Интеграция интернет-магазина с 1С: что в неё входит и как её заказать

Что входит в интеграцию интернет-магазина с 1С

«Связать магазин с 1С» — формулировка, под которой у заказчика и исполнителя часто скрываются разные объёмы работ. Один имеет в виду только выгрузку товаров, другой — полный контур вплоть до взаиморасчётов. Поэтому первое, что делается на разборе, — раскладывается состав обмена по сущностям: что ездит, в какую сторону и какая система по этим данным главная.

Брать всю таблицу в первую очередь не обязательно и обычно не нужно. Рабочая первая очередь для магазина — каталог, цены, остатки и заказы: этого достаточно, чтобы витрина показывала правду, а менеджер перестал переносить заказы руками. Статусы, оплаты и взаиморасчёты добавляются следующим этапом, когда основной поток уже ездит стабильно.

Интеграция не улучшает данные — она их распространяет. Если в 1С дубли номенклатуры, пустые артикулы и цены, которые ведутся «в файле у менеджера», магазин покажет ровно тот же беспорядок, только быстрее и на витрине. Порядок в справочниках дешевле навести до обмена, а не после запуска.

Три способа сделать интеграцию 1С с сайтом — и где предел каждого

Прежде чем считать бюджет разработки, стоит честно проверить, нужна ли она вообще. Способов связать магазин с учётом три, и различаются они не «уровнем технологичности», а тем, насколько ваша модель данных совпадает со стандартной.

Выбор между первой строкой и третьей — это вопрос стоимости несоответствия: сколько бизнес платит за то, что модель данных приходится ломать под формат обмена. Пока платит немного — берите стандарт. Когда каждая новая доработка стандартного модуля стоит дороже предыдущей, дешевле построить свой слой обмена.

Типовой магазин на коробочной CMS, типовая конфигурация, один склад и одинаковые цены для всех покупателей — это случай, когда заказная интеграция не нужна. Работа сводится к настройке: включить модуль обмена, настроить узел и регламентное задание на стороне 1С, сверить справочники. Это работа 1С-специалиста, и стоит она в разы дешевле разработки — на разборе я говорю об этом прямо, а не продаю интеграционный слой.

Как подготовиться к интеграции: данные, доступы, люди

Большая часть задержек в таких проектах случается не в коде, а в подготовке: нет тестовой базы, некому ответить про типы цен, артикулы в 1С заполнены наполовину. Что полезно сделать до того, как обсуждать сроки и бюджет:

• Навести порядок в номенклатуре: единый ключ (обычно артикул или внутренний идентификатор), отсутствие дублей, заполненные обязательные реквизиты. От качества ключа зависит, будет ли обмен плодить дубли карточек.
• Определиться с ценами: какие типы цен существуют, какие из них должен видеть сайт, есть ли персональные цены и скидки по договорам, что делать с НДС и округлением.
• Определиться со складами: сколько их, показываем ли остаток по каждому или одну сумму, как учитываются резервы под уже принятые заказы.
• Назвать ответственного со стороны бизнеса — человека, который принимает решения об источнике правды. Это бизнес-решение, а не техническое, и разработчик за вас его не примет.
• Обеспечить тестовую копию базы 1С и тестовый контур магазина. Первые итерации сознательно идут без боевых токенов и реальных данных покупателей.
• Собрать доступы: хостинг и сайт, аккаунт эквайринга, кабинеты служб доставки — всё, с чем магазин уже связан или должен быть связан.

Отдельный пункт — 1С-специалист. Он отвечает за правила обмена внутри 1С, конфигурацию и формат выгрузки, за то, что база корректно отдаёт и принимает данные. Моя зона — сторона сайта: интеграционный слой и шлюз, преобразование форматов, очереди и повторные попытки, журнал обменов и мониторинг. Разделение зон полностью описано на странице интеграций и API.

Если 1С-специалиста нет, это нужно решить до старта, а не в середине проекта: либо подключить его, либо сознательно ограничить интеграцию форматами, которые ваша 1С уже умеет отдавать сама, — например регламентными выгрузками файлов. Без человека, отвечающего за сторону учёта, проект упирается в первую же доработку конфигурации.

ТЗ на интеграцию 1С с интернет-магазином: что должно быть в документе

ТЗ пишут в двух ситуациях: перед сравнением исполнителей или как результат оплаченного разбора. В обоих случаях ценность документа не в объёме, а в том, на сколько вопросов из списка ниже в нём есть ответы. Документ, где написано «настроить обмен товарами и заказами», сравнить предложения не поможет — каждый исполнитель посчитает свой объём работ.

1. 1Системы и их состояние: какая конфигурация 1С и как развёрнута (локально или в облаке), на чём сделан магазин, какие ещё системы участвуют — эквайринг, доставка, маркетплейсы, CRM.
2. 2Состав данных по каждой сущности: какие именно поля каталога, цен, остатков, заказов и статусов передаются. Не «товары», а перечень реквизитов.
3. 3Направление и источник правды по каждому типу данных: где значение можно менять, а где оно только отображается.
4. 4Ключи сопоставления: по какому полю системы узнают один и тот же товар, одного и того же покупателя, один и тот же заказ.
5. 5Частота обмена и допустимая задержка — отдельно по каждой сущности. Каталог и остатки живут в разных ритмах, и требовать от них одинакового расписания дорого и бессмысленно.
6. 6Способ обмена и формат: файловые выгрузки, HTTP-сервисы, готовый протокол; JSON, XML, CSV, EnterpriseData. Этот пункт лучше фиксировать после проверки того, что 1С реально умеет отдавать.
7. 7Правила преобразования: единицы измерения, кратность отгрузки, округление цен, НДС, валюты, поведение при пустом или некорректном значении.
8. 8Поведение при ошибке: что происходит с заказом, который в 1С принять нельзя; кто и где видит непрошедшие записи; кто получает уведомление о том, что обмен не идёт.
9. 9Объёмы и рост: сколько позиций в каталоге, сколько заказов в сутки, есть ли сезонные пики. Каталог на тысячу позиций и на сто тысяч — это разные проекты при одинаковом описании.
10. 10Безопасность и доступы: где хранятся токены, кто имеет доступ к боевым данным, есть ли тестовый контур.
11. 11Критерии приёмки: конкретные сценарии, на которых интеграция считается принятой. Например: заказ с двумя позициями и новым покупателем доезжает до учёта и возвращает статус.

Если ТЗ пишете сами — не фиксируйте в нём способ обмена и формат до того, как ваш 1С-специалист подтвердил, что база это умеет. Иначе документ описывает не проект, а пожелание, и первая же техническая проверка отправляет его на переписывание вместе со сметой.

Из каких этапов состоит работа

Проект интеграции идёт по шагам, и каждый заканчивается понятным результатом — это защищает от ситуации «деньги потрачены, а показать нечего»:

1. 1Разбор систем и данных: что нужно связать, какие данные ходят, как часто, кто источник правды.
2. 2Проверка API: есть ли у систем нормальный интерфейс, какие лимиты и ограничения, что реально умеет ваша 1С.
3. 3Карта обмена: схема — что, куда, в какую сторону и что делать при ошибке. Именно она превращается в приложение к договору и в основу ТЗ.
4. 4Разработка: интеграционный слой, очереди, обработка ошибок, журнал обменов.
5. 5Тестирование на тестовых данных — без работы с боевыми токенами в первых итерациях.
6. 6Запуск и сопровождение: мониторинг, реакция на изменения внешних API, доработки.

Большая часть бюджета уходит не на «передать файл», а на устойчивость: очереди, повторные попытки, защиту от дублей, порционную передачу большого каталога и журнал, по которому видно конкретную непрошедшую запись и причину отказа. Что именно ломается в обменах и как эта обвязка устроена технически — разобрано отдельно: обмен 1С с сайтом: что ломается и как сделать надёжно.

1С:УНФ: интеграция с интернет-магазином в небольшой компании

«Управление нашей фирмой» — частая учётная система у небольших производств, оптовиков и магазинов: в ней ведутся номенклатура, цены, склад и заказы покупателей одновременно. Для интеграции это удобно — почти все нужные данные лежат в одной базе, и отдельного контура складского учёта заводить не приходится.

Что учесть при интеграции 1С:УНФ с сайтом

• Как развёрнута база. У локальной установки можно опубликовать интерфейсы на веб-сервере и строить обмен по запросу. У облачной публикация наружу ограничена, и обмен чаще идёт штатными механизмами или регламентными выгрузками файлов — это влияет и на архитектуру, и на бюджет.
• Типы цен и сегменты покупателей. Если магазин обслуживает и розницу, и опт, заранее решите, какие типы цен уезжают на сайт и как они соотносятся с сегментами покупателей.
• Склады и резервы. В небольшой компании остаток на витрине обычно один, а складов в учёте несколько — правило свёртки нужно зафиксировать словами до разработки.
• Заказы покупателей как документ учёта. Заказ с сайта должен превращаться в документ УНФ с корректным контрагентом и номенклатурой; несопоставленные позиции должны попадать в разбор, а не создавать мусор в справочниках.
• Доработки конфигурации. Любое изменение состава реквизитов или правил обмена внутри УНФ — работа вашего 1С-специалиста. После обновления конфигурации обмен стоит перепроверять на тестовом контуре.

Если магазин при этом сделан на коробочной CMS и модель данных типовая, начните со штатного обмена — это дешевле. Заказная интеграция с УНФ оправдана, когда сайт самописный, каталог сложнее типового или обмен нужен не только каталогом и заказами.

Сколько стоит интеграция интернет-магазина с 1С

Цена зависит от количества систем, доступности их API, объёма данных и требований к надёжности обмена. Ориентиры по форматам работы — те же, что на странице услуги:

В эти ориентиры не входят две вещи, которые заказчик часто считает частью интеграции. Первая — работы на стороне 1С: их отдельно оценивает ваш 1С-специалист. Вторая — доработки самого магазина: если витрина не умеет показывать персональные цены или остатки по нескольким складам, обмен эти данные привезёт, а показать их будет негде.

Если выясняется, что магазин уже перерос шаблон и его придётся строить заново, это отдельный проект с другим порядком цифр: первая рабочая версия — от 700 тыс. ₽, сложный магазин с интеграциями — от 1,5 млн ₽. Подробнее — интернет-магазины и каталоги.

Это ориентиры, а не смета: точная цифра появляется после разбора систем и данных. Сопровождение стоит закладывать сразу — конфигурации обновляются, внешние API меняются, каталог растёт, и это нормальная часть жизни интеграции, а не поломка.

Кому заказывать интеграцию и что спросить у исполнителя

Задачу берут исполнители трёх разных профилей, и путать их зоны — главный источник разочарований:

• Специалист или подрядчик по 1С. Сильная сторона — всё, что внутри учётной системы: конфигурация, правила обмена, регламентные задания. Слабая — бэкенд сайта: очереди, устойчивость, журнал и мониторинг обычно остаются за пределами их зоны.
• Веб-студия, работающая на коробочной CMS. Хороший вариант, когда магазин типовой и задача сводится к настройке штатного модуля. Как только модель данных выходит за стандарт, начинаются доработки поверх чужого модуля.
• Бэкенд-разработчик интеграций. Это моя зона: приём и отправка данных, преобразование форматов, очереди и повторные попытки, идемпотентность, журнал обменов и мониторинг. Сторона 1С при этом всё равно остаётся за вашим специалистом — это разделение честнее, чем обещание закрыть обе стороны одним человеком.

Независимо от выбора, есть четыре вопроса, ответы на которые стоит услышать до подписания: что произойдёт с заказом, если 1С в этот момент недоступна; как система защищена от повторной отправки одного и того же заказа; где сотрудник увидит, что обмен не прошёл, и по какой причине; кто отвечает за сторону 1С. Если на них отвечают «всё будет работать», интеграция спроектирована как «должно сработать» — а для обменов сбой не исключение, а абсолютно штатная ситуация: 1С периодически недоступна, запросы приходят повторно.

И встречное честное ограничение с моей стороны: я не обещаю связать что угодно с чем угодно мгновенно. У части систем API ограничен или отсутствует — тогда на разборе прямо проговаривается, что возможно, что возможно только через файловые выгрузки, а что не имеет смысла делать вообще.