Интегрирую 1С с веб-сервисами так, чтобы учётная система оставалась владельцем своих данных, а внешний интерфейс не зависел от скорости толстого клиента. Типичный контур включает HTTP-сервис или OData на стороне 1С, промежуточный сервис на TypeScript/Node.js, очередь для повторов и веб-интерфейс на React либо Astro. Но стек вторичен: сначала нужна карта сущностей и однозначное правило, какая система создаёт и меняет каждое поле.

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

Границы зависят от владельца учётной логики. Могу реализовать HTTP-сервисы и регламентные задания в 1С, промежуточный API, кабинет, отчёт или адаптер мессенджера. Изменение бухгалтерских правил, обновление конфигурации и круглосуточное администрирование сервера оговариваются отдельно. Для приёмки использую тестовые сущности и неприятные сценарии: повторная отправка, пропущенное поле, недоступная сторона, восстановление после сбоя.

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