Інтегрую 1С/BAS із вебсервісами так, щоб облікова система залишалася власником своїх даних, а зовнішній інтерфейс не залежав від швидкості товстого клієнта. Типовий контур охоплює HTTP-сервіс або OData на боці 1С/BAS, проміжний сервіс на TypeScript/Node.js, чергу для повторів і вебінтерфейс на React або Astro. Але стек другорядний: спершу потрібна карта сутностей і однозначне правило, яка система створює та змінює кожне поле.

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

Межі залежать від власника облікової логіки. Можу реалізувати HTTP-сервіси та регламентні завдання в 1С/BAS, проміжний API, кабінет, звіт або адаптер месенджера. Зміна бухгалтерських правил, оновлення конфігурації та цілодобове адміністрування сервера погоджуються окремо. Для приймання використовую тестові сутності й неприємні сценарії: повторне надсилання, пропущене поле, недоступна сторона, відновлення після збою.

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