Что подготовить до выбора интеграции

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

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

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

Какие данные передавать и где их изменять

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

Каталог и остатки. Уточните, что считается товаром: отдельная позиция, характеристика, комплект или услуга. Согласуйте единицы измерения и связь складов. Название товара не подходит как единственный идентификатор: оно может измениться. Уточните и смысл показанного наличия: это справочный остаток или количество, доступное для подтверждённого заказа.

Цены и условия клиента. Опишите типы цен, валюту, округление и персональные условия. Если цена изменилась между просмотром карточки и оформлением заказа, заранее решите, какое значение применяется и что увидит покупатель.

Заказы и документы. Разделите создание заявки, подтверждение заказа, резервирование и учётную операцию. Не каждое изменение статуса на сайте должно автоматически создавать или проводить документ в 1С. Для изменения и отмены нужен собственный порядок, включая уже обработанные заказы.

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

Готовый модуль, HTTP-сервис или REST-интерфейс

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

Когда готового механизма недостаточно, можно рассматривать собственный программный интерфейс — API. Платформа «1С:Предприятие» позволяет создавать HTTP-сервисы, в которых разработчик определяет обработку запроса и ответ. Это возможность платформы, а не гарантия готового подключения в любой базе. Описание механизма приведено в официальной документации 1С об HTTP-сервисах.

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

HTTP-сервис и REST-интерфейс не следует сравнивать только по скорости разработки первого запроса. Проверьте, где будет выполняться проверка реквизитов, как возвращается ошибка и кто отвечает за совместимость после изменений. Для облачного размещения дополнительно выясните, какие способы публикации и подключения разрешает конкретная среда.

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

Что меняется, когда в обмене участвует CRM

В связке сайта, CRM и 1С важно не создавать три независимые копии заказа. Назначьте место создания каждого объекта и момент передачи ответственности. Например, CRM может хранить обращение и действия менеджера, а 1С — подтверждённый заказ и учётные документы. Это лишь один из возможных вариантов; его нужно сверить с работой компании.

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

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

Как обрабатывать повторы и потерянные ответы

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

В требованиях закрепите устойчивый ключ операции и правило обработки повтора. Принимающая сторона должна находить ранее обработанную операцию и возвращать её результат, а не создавать новый документ. Такое поведение называют идемпотентностью. Его необходимо реализовать в обработчике; отключение кнопки после нажатия не защищает от повторной доставки сообщения.

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

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

Что делать с ошибками обмена

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

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

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

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

Как проверить интеграцию перед запуском

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

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

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

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

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

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

Результаты удобно фиксировать рядом с чек-листом запуска интеграции. В перечне приёмки укажите не просто «обмен работает», а конкретные сценарии и подтверждающие материалы.

Первый запуск, стоимость и дальнейшая поддержка

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

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

На стоимость интеграции влияют состав объектов, направления передачи, качество данных, нестандартные правила, доступность тестовой среды и требования к сопровождению. Отдельно учитываются лицензии модулей и инфраструктура, когда они нужны. Сравнивать предложения полезно по одинаковому составу обмена и проверок, а не только по итоговой сумме.

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

Частые вопросы

Можно ли связать сайт с 1С без замены учётной системы?

Такой вариант стоит проверить первым. Потребуется выяснить доступные механизмы обмена и ограничения действующей конфигурации. Замена системы не должна быть исходным условием только ради подключения сайта.

Достаточно ли установить готовый модуль?

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

Нужно ли обновлять все данные мгновенно?

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

Можно ли назвать цену по названию конфигурации?

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

Обсудить свою схему обмена

Укажите используемые конфигурацию и версию 1С, платформу сайта и CRM. Опишите, какие данные нужно передавать и где возникают затруднения. Обсудить интеграцию с АИС Сокол.