Корректный интеграционный проект начинается не с выбора API, а с документа, который может составить только бизнес: какие системы участвуют, какая из них главная по каждой сущности — товар, цена, остаток, клиент, заказ, оплата, — что должно происходить при сбое и кто отвечает за обмен после запуска. Разработчику дополнительно нужны тестовые доступы, обезличенные примеры данных и критерии приёмки. С таким брифом оценка опирается на факты, а не на допущения подрядчика.
Содержание
Почему интеграции дорожают по ходу проекта
Интеграция связывает системы, у которых разные владельцы, разные правила и разная скорость изменений. Технически это часто понятная задача: у 1С, Kaspi Магазина, CRM и мессенджеров есть документированные способы обмена. Объём растёт по другой причине — вопросы, которые должен решить бизнес, всплывают уже во время разработки.
- Выясняется, что цену правят и в 1С, и в кабинете маркетплейса, и неясно, какая главная.
- Номенклатура в учётной системе и на площадке не сопоставлена, и сопоставлять её приходится вручную.
- Исключения — возвраты, частичные отгрузки, отменённые после оплаты заказы — не описаны, и разработчик придумывает правила сам.
- Доступ к тестовой базе 1С или к кабинету выдают неделями, потому что не определено, кто за это отвечает.
- После запуска непонятно, кто разбирает ошибки обмена: подрядчик, ваш программист 1С или менеджер.
Карта систем и потоков данных
Начните с перечня систем: название и версия конфигурации 1С и кто её сопровождает (штатный программист или внешняя компания), Kaspi Магазин, платёжный провайдер, CRM, мессенджеры, сайт. Затем опишите потоки — каждое движение данных между двумя системами.
- 01Сайт и Kaspi
- 02Заказы и оплаты
- 03CRM
- 041С
Остатки
- Откуда → куда
- 1С → сайт, Kaspi
- Что запускает
- Изменение остатка или расписание
- Допустимая задержка
- Сколько бизнес готов продавать отсутствующий товар
- Объём в обычный день и в пик
- Число товарных позиций
Цены
- Откуда → куда
- 1С → сайт, Kaspi
- Что запускает
- Изменение прайса
- Допустимая задержка
- Укажите сами
- Объём в обычный день и в пик
- Число позиций и частота изменений
Заказы
- Откуда → куда
- Сайт, Kaspi → CRM, 1С
- Что запускает
- Новый заказ
- Допустимая задержка
- Укажите сами
- Объём в обычный день и в пик
- Заказов в день, в акционные дни
Оплаты
- Откуда → куда
- Платёжный провайдер → заказ
- Что запускает
- Событие провайдера
- Допустимая задержка
- Укажите сами
- Объём в обычный день и в пик
- Платежей в день
Уведомления
- Откуда → куда
- CRM → мессенджер клиента
- Что запускает
- Смена статуса заказа
- Допустимая задержка
- Укажите сами
- Объём в обычный день и в пик
- Сообщений в день
Колонки «Допустимая задержка» и «Объём» намеренно не заполнены: это ваши данные, и именно они определяют способ обмена. Остатки, которые нужны «почти сразу», и взаиморасчёты «раз в сутки» — разные технические решения с разной ценой.
Источник правды и правила конфликтов
Для каждой сущности назначьте одну главную систему. Это не технический вопрос: только бизнес знает, где правят цену и кто отвечает за карточку клиента.
Товар и характеристики
- Главная система
- Например, 1С
- Кто вносит изменения
- Товаровед
- Что делать при расхождении
- Площадки перезаписываются из главной системы
Цена
- Главная система
- Например, 1С
- Кто вносит изменения
- Коммерческий отдел
- Что делать при расхождении
- Решите, допустима ли отдельная цена на маркетплейсе
Остаток
- Главная система
- Учётная система склада
- Кто вносит изменения
- Склад
- Что делать при расхождении
- Площадки обновляются из учёта; ручная правка на площадке запрещена или журналируется
Клиент
- Главная система
- Например, CRM
- Кто вносит изменения
- Менеджеры
- Что делать при расхождении
- Правило поиска дублей: по телефону, email или их сочетанию
Заказ и его статус
- Главная система
- Определите для каждого этапа
- Кто вносит изменения
- Менеджер, склад, бухгалтерия
- Что делать при расхождении
- Кто может отменить заказ после оплаты
Оплата
- Главная система
- Платёжный провайдер
- Кто вносит изменения
- Никто вручную
- Что делать при расхождении
- Статус оплаты подтверждается запросом к провайдеру, а не только уведомлением
Что известно о платформах заранее
Часть ограничений задают сами платформы. Их полезно знать до брифа, чтобы заранее определить, кто на вашей стороне выдаёт доступы и кто отвечает за доработки.
1С:Предприятие
- Что говорит официальная документация
- Платформа может автоматически сформировать REST-интерфейс по протоколу OData 3.0 для основных объектов конфигурации после публикации на веб-сервере. Собственные HTTP-сервисы программист описывает в конфигурации и сам формирует ответ на встроенном языке
- Что подготовить
- Контакт программиста 1С, копию базы для тестов, решение о публикации интерфейса
Kaspi Магазин
- Что говорит официальная документация
- Токен API продавец формирует сам в веб-версии кабинета: «Настройки → Токен API». API используется для добавления товаров и обработки заказов
- Что подготовить
- Ответственного за токен в компании и порядок его замены
CRM (пример — Битрикс24)
- Что говорит официальная документация
- Подключение через входящий вебхук, локальное или тиражное приложение; действуют лимиты на интенсивность запросов
- Что подготовить
- Права пользователя для интеграции, список воронок и полей
WhatsApp Business Platform
- Что говорит официальная документация
- Для Cloud API нужны бизнес-портфолио и номер телефона компании; вне окна обслуживания клиента можно отправлять только шаблоны сообщений, которые обычно проходят одобрение
- Что подготовить
- Список уведомлений и их тексты как шаблоны
Telegram-бот
- Что говорит официальная документация
- Обновления приходят одним из двух взаимоисключающих способов — getUpdates или вебхук; для вебхука можно задать секрет, который Telegram передаёт в заголовке
X-Telegram-Bot-Api-Secret-Token - Что подготовить
- Кто создаёт бота и хранит его токен
Платёжный провайдер
- Что говорит официальная документация
- Зависит от провайдера: запросите у него документацию, тестовую среду и описание уведомлений об оплате
- Что подготовить
- Договор с провайдером, тестовые реквизиты, список сценариев возврата
Сбои, исключения и жизнь после запуска
Интеграция обязательно столкнётся с недоступной системой, повторным сообщением и данными, которые не сходятся. Решите заранее, что должно произойти в каждом случае, — иначе это решит разработчик, и не обязательно так, как удобно вашему бизнесу.
- 1С недоступна во время обновления или ночного регламента: заказы копятся в очереди или менеджер получает уведомление?
- Заказ пришёл дважды: система должна распознать повтор и не создать второй документ.
- Товар с площадки не сопоставлен с учётом: заказ останавливается или создаётся с пометкой для ручной проверки?
- Оплата прошла, а заказ отменён: кто инициирует возврат и в какой системе это видно?
- Частичная отгрузка или замена товара: как это отражается в заказе на площадке и в CRM?
- Кому и куда приходят уведомления об ошибках обмена — и кто обязан на них реагировать?
- Как часто сверяются контрольные показатели систем: количество заказов, суммы, остатки?
- Кто сопровождает интеграцию после запуска и что происходит, когда одна из платформ меняет API?
Если интеграция передаёт телефоны и имена клиентов в CRM или мессенджеры, учтите требования к персональным данным — например, к месту их хранения. О том, как это влияет на выбор систем, — в материале о корпоративных LMS; детали стоит согласовать с юристом.
Шаблон брифа и порядок работы
Бриф не обязан быть длинным. Достаточно, чтобы в нём были ответы на следующие разделы:
- Цель: какую ручную работу или ошибки должна убрать интеграция, и как вы поймёте, что она работает.
- Системы: перечень, версии, владельцы, контакты ответственных с вашей стороны.
- Потоки: таблица «откуда — куда — что запускает — допустимая задержка — объём».
- Источник правды и правила конфликтов по каждой сущности.
- Исключения и сбои: что делать в каждом случае из списка выше.
- Доступы и тестовые среды: что есть, кто выдаёт, сроки получения.
- Примеры данных: обезличенные заказы, товары, клиенты в реальном формате.
- Критерии приёмки: сценарии, которые должны пройти на тестовых данных до перевода боевого потока.
- Эксплуатация: кто получает уведомления, кто сопровождает, как часто сверка.
Бриф
Заполняете разделы выше, насколько можете; пробелы — тоже информация.
Рабочая сессия
Разработчик, ваш программист 1С и ответственный за процесс разбирают потоки и исключения.
Контракт данных
Поля, форматы, идентификаторы и статусы фиксируются письменно до первой строки кода.
Пилот одного потока
Сначала один поток — например, заказы — на тестовых данных, с журналом и уведомлениями.
Перевод и сверка
Боевой поток включается после обкатки, первые недели — с ежедневной сверкой.
Объём работ складывается из числа потоков, сложности сопоставления справочников, количества исключений, состояния конфигурации 1С и наличия тестовых сред. Стоимость определяется после брифа и согласования объёма.
