Интеграция с 1С: как связать учётную систему с сайтом, приложением и CRM

Формулировка «нужно связать сайт с 1С» на первой встрече обычно скрывает пять-шесть разных обменов с разными требованиями. Их полезно выписать по отдельности сразу: дальше по каждому принимаются свои решения.

У платформы есть несколько штатных механизмов плюс два «внешних» подхода. Выбор определяет и сроки разработки, и стоимость поддержки на годы вперёд.

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

Обмен, который отлично работал на тысяче позиций, начинает вести себя иначе после десяти тысяч. Проблемы повторяются от проекта к проекту.

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

Пики при массовых изменениях. Переоценка каталога или пересчёт остатков после инвентаризации создают волну изменений, которую внешняя система пытается принять синхронно. Нормальное поведение — складывать такие изменения в очередь и разбирать её в своём темпе.

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

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

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

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

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

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

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

Когда систем становится больше четырёх-пяти, точечные обмены превращаются в паутину, и разговор переходит к общей интеграционной шине. Для двух-трёх систем шина избыточна: витрины и одной очереди достаточно.

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

Для номенклатуры это внутренний идентификатор записи или артикул, если он действительно уникален и не переиспользуется. Для контрагентов — ИНН плюс КПП, с оговоркой на филиалы. Для заказов — номер с префиксом источника, чтобы заказ с сайта и заказ из розницы не столкнулись.

Отдельно фиксируется ведущая система по каждому справочнику: где заводят новую позицию, кто имеет право её менять, что делать с записями, созданными на другой стороне. Это уже дисциплина управления мастер-данными, и без неё обмен превращается в перенос расхождений.

Практический приём: таблица соответствия идентификаторов на стороне внешней системы. Она позволяет пережить переименования, объединение дублей и даже смену учётной системы без переписывания всей интеграции.

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

Учётная база содержит всё: цены закупки, контрагентов, зарплаты, персональные данные сотрудников. Поэтому публиковать её в интернет напрямую нельзя, даже если это быстрее.

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

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

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

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

Обмен ломается всегда — вопрос в том, как быстро об этом узнают. Минимальный набор, который стоит требовать от подрядчика на приёмке:

• Журнал обмена с человекочитаемой ошибкой: что за документ, куда шёл, на чём упал.
• Алерт в почту или мессенджер при накоплении ошибок или остановке обмена дольше согласованного времени.
• Повторная отправка — руками из интерфейса и автоматически по расписанию, без участия разработчика.
• Ключ операции, по которому повтор не создаёт дубль.
• Сверка — регулярное сравнение количества документов и сумм на обеих сторонах.

Последний пункт часто считают избыточным, пока не выясняется, что за месяц на сайт не доехали двести карточек, а в 1С не приехали сорок заказов — и никакой ошибки при этом в журнале не было.

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

Диапазон между простой выгрузкой и двусторонним обменом с очередью — примерно десятикратный, поэтому цена всегда считается по списку объектов. Что двигает смету:

Документ на одну-две страницы по каждому обмену снимает большую часть будущих споров. Что в нём должно быть:

• 1. Объекты и поля. Что передаём, с точным перечнем полей и указанием обязательных.
• 2. Направление и инициатор. Кто кому отправляет и по какому событию.
• 3. Ключ сопоставления. Чем сшиваются записи и что делать, если ключа нет.
• 4. Режим и частота. Онлайн, по расписанию, по кнопке; допустимая задержка.
• 5. Объёмы. Сколько записей сейчас и сколько ожидается через год; пиковые сценарии.
• 6. Поведение при ошибке. Повтор, откладывание, ручной разбор; кто получает уведомление.
• 7. Окна недоступности. Когда обмен приостанавливается и что происходит с данными в это время.
• 8. Тестовый контур. Копия базы, на которой можно проверять, не трогая боевую.
• 9. Ответственные. Кто отвечает за 1С, кто за внешнюю систему, кто принимает результат.

Сначала пишут код, потом ищут ключ. Обмен запускают на наименованиях, а через месяц разбирают дубли вручную.

Тестируют на боевой базе. Экономия недели на разворачивании копии оборачивается испорченными документами и разговором с бухгалтерией.

Считают, что обмен настраивают один раз. Меняются конфигурация, структура каталога, требования маркетплейсов — интеграция требует сопровождения так же, как и любой другой код.

Никто не отвечает за обмен. Подрядчик сделал и ушёл, внутренний специалист по 1С считает это зоной веб-студии, веб-студия — зоной 1С. Обмен встал в пятницу, узнали в понедельник от клиента.

Открывают базу наружу «на время запуска». Временное решение живёт годами и однажды становится историей про утечку прайсов и контрагентов.

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

Второе — по каждому объекту назвать ключ и ведущую систему. Если ответа нет ни у кого, начинать надо с порядка в справочниках, иначе любая интеграция будет разъезжаться.

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