1С и маркетплейсы: обмен заказами и остатками

Что обычно синхронизируют

• Заказы и их статусы — от «новый» до «доставлен» и возврата.
• Остатки и цены — чтобы товар не продавался, когда его нет.
• Номенклатуру и сопоставление с карточками маркетплейса.
• Отгрузки, передачи в доставку и возвраты.
• Взаиморасчёты: комиссии, удержания, выплаты.

Варианты обмена

• Прямая интеграция через API маркетплейса. Гибко и точно, но нужно писать обмен под каждую площадку.
• Через сервис-посредник. Быстрее на старте, меньше кода, но появляется третья сторона и её ограничения.
• Готовый модуль. Подходит для типовых сценариев, но требует проверки на вашем учёте — особенно по себестоимости и комиссиям.

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

Что важно для надёжности

• Идемпотентность. Повторная загрузка не должна создавать дубли заказов.
• Очередь и повторные попытки. Недоступность API площадки не должна терять данные.
• Журнал обмена. Видно, что и когда перенеслось, где ошибка.
• Уведомления. Если обмен встал — сообщение в Telegram или на почту, а не молчаливая ошибка.
• Лимиты API. Запросы нужно распределять, иначе площадка начнёт отклонять их.

Что учесть по учёту

Технически обмен сделать полдела. Важнее — корректно отразить в учёте реализацию и комиссию, не потерять себестоимость, правильно разнести возвраты и свести выплаты. Эти вопросы лучше решить до разработки: переделывать учётную схему после запуска дороже.

Сколько это занимает

Узкий обмен — например, только остатки и цены или только заказы по одной площадке — обычно 2–3 недели. Полноценный двусторонний обмен с несколькими маркетплейсами, возвратами и взаиморасчётами — от месяца: больше сущностей, больше сценариев и обязательные тесты на копии базы.