Интеграция 1С с маркетплейсами: как построить общий контур
Общий контур не означает одну одинаковую схему для всех площадок. Внутри компании полезно унифицировать товары, SKU, цены, остатки, заказы и журнал, а на границе оставить отдельные адаптеры под API, кабинеты, модели работы и статусы каждой площадки.
Так изменения внешнего API локализуются в одном адаптере, а 1С работает с устойчивой внутренней моделью. Актуальные методы, лимиты и правила авторизации всегда проверяются в официальной документации перед разработкой.
Проверено: 10.09.2026
Общая модель данных и различия площадок
Внутренняя модель описывает товар, предложение, склад, заказ, отгрузку, возврат и финансовый документ. Адаптер переводит её в термины площадки и обратно.
Не пытайтесь свести разные статусы в один без потерь. Храните исходный код статуса рядом с нормализованным состоянием и версией адаптера.
Сопоставление SKU и кабинетов
Ключ соответствия включает площадку, кабинет и SKU продавца. Один артикул может иметь разные карточки, баркоды и правила поставки.
Справочник соответствий должен быть доступен операционной команде. Неизвестный SKU уходит в исключения, а не создаётся автоматически без правил.
Цены, остатки и резервы
Передавайте цену с основанием и проверяйте подтверждённое площадкой значение. Остаток рассчитывайте по складу и модели работы, учитывая резерв и защитный буфер.
Частота зависит от лимитов API и риска перепродажи. Очередь объединяет частые изменения одного SKU, чтобы не отправлять заведомо устаревшие значения.
Заказы FBO/FBS/DBS без обещания одинаковой схемы
FBO, FBS и DBS различаются ответственностью за хранение, сборку и доставку; даже одинаковые сокращения не гарантируют одинаковых событий у площадок. Для каждой комбинации фиксируют документы, сроки и переходы.
В 1С может быть единый заказ клиента, но исходные идентификаторы, кабинет, модель и статусы площадки сохраняются без потери.
Лимиты API, очереди и повторы
Ограничение запросов читается из актуальной документации конкретного метода. Клиент учитывает ответ сервера, делает ограниченный retry с паузой и не запускает лавину параллельных повторов.
Токены хранятся вне кода и журнала. Ротация ключа и отзыв доступа проверяются как эксплуатационный сценарий.
Ежедневная сверка исключений
Ежедневно сравнивайте непривязанные SKU, отклонённые цены, расхождения остатков, необработанные заказы и зависшие статусы. У каждой строки есть ответственный и безопасное действие.
Отчёт по исключениям важнее «процента успешных запросов»: единичная ошибка может относиться к дорогому заказу или всему складу.
Готовый модуль или общий коннектор
Готовый модуль разумен для одной площадки и типового процесса. Общий коннектор оправдан при нескольких кабинетах, едином журнале, нестандартных маршрутах и необходимости изолировать 1С от внешних изменений.
Решение принимают после проверки поддерживаемых функций, релиза 1С и стоимости сопровождения, а не только стоимости лицензии.
Критерии приёмки
Проверьте публикацию товара, цену, остаток, новый заказ, отмену, возврат, недоступность API и повтор. Для каждой модели работы нужен свой набор.
Сверьте итог в кабинете и 1С, журнал, уведомление и восстановление после ошибки. Успешный HTTP-ответ без итоговой сверки недостаточен.
Проверочный сценарий
Остаток SKU demo-sku-77 меняется пять раз за минуту. Очередь сохраняет последнее актуальное значение для каждого кабинета, соблюдает лимиты API, а ночная сверка подтверждает итог или создаёт исключение.
| Область | Общее ядро | Адаптер площадки |
|---|---|---|
| SKU | Внутренний ID и соответствия | Карточка и кабинет |
| Заказ | Позиции, сумма, состояние | Модель и исходные статусы |
| Надёжность | Очередь, журнал, сверка | Лимиты и авторизация |
Чек-лист самостоятельной проверки
- Разделены внутренняя модель и адаптеры площадок.
- Соответствие включает SKU, кабинет и склад.
- Учтены лимиты, ротация токена и повтор.
- FBO/FBS/DBS принимаются отдельными сценариями.
- Есть ежедневная очередь исключений и полная сверка.