1С-Битрикс и Prom.ua: где рвётся обмен заказами и остатками
Обмен заказами 1С-Битрикс и Prom.ua редко ломается целиком — чаще он «почти работает»: часть данных доезжает, часть висит в журнале, а расхождения копятся молча. Через несколько недель бухгалтерия видит заказы, которых нет на складе, а менеджер площадки — остатки, которых нет в учётной системе. Цена такого «почти» — ручная сверка по вечерам, отмены после оплаты и покупатель, который получил отказ по товару, стоявшему в наличии.
Первый разрыв — заказы. Если выгрузка идёт по расписанию, повторный запуск после сбоя заново отправляет те же позиции, и появляются дубли заказов при выгрузке. Лечится это не «повторной отправкой», а внешним идентификатором: каждая запись связывается с документом в учётной системе, и повторный приём распознаётся как уже обработанный. Тогда сбой задания не превращается в два отгруженных комплекта.
Второй разрыв — остатки. Расхождение остатков маркетплейс и склад накапливается, когда в выгрузку не попадают резервы, товары «под заказ» и позиции в сборке. Площадка продолжает продавать по последнему срезу, склад — по факту, и разрыв растёт с каждой отгрузкой. Здесь важна не частота обмена, а правило расчёта доступного количества и единая точка, которая его считает.
Третий разрыв — статусы. Заказ живёт в двух независимых списках: на площадке свой набор состояний, в учётной системе свой, и связь между ними держится на ручных пометках менеджера. Стоит пропустить смену — и оплаченный заказ числится новым, а отгруженный висит в ожидании.
Дальше разбираем, как это закрывается: где ставить идемпотентный приём, как считать доступный остаток и как свести статусы к одному источнику правды.
Что даёт выстроенный обмен: эффект в сроках и отказах
Пока обмен держится на ручном переносе, каждый заказ и каждая правка остатка — это операция человека, а значит задержка и риск ошибки. Выстроенный обмен переводит эти действия в регламент: номенклатура, цены, остатки и заказы ходят между учётной системой и площадкой Prom.ua без участия оператора. Проверить эффект можно по чек-листу ниже — каждый пункт измерим.
- Автоматический обмен остатками. Количество на витрине совпадает со складским учётом в пределах цикла выгрузки: товар не продаётся дважды и не висит «в наличии» без запаса.
- Скорость обновления статусов заказа. Смена состояния в учёте доходит до кабинета площадки за минуты — покупатель видит движение по заказу, менеджер работает с актуальной картиной без уточняющих звонков.
- Снижение ручных операций. Выгрузка каталога, пересчёт цен и перенос заказов уходят в регламент: там, где было несколько десятков действий в день, остаётся контроль исключений.
- Устранение рассинхронизации данных. Одна карточка — один артикул: сопоставление по коду, а не по названию, снимает дубли и расхождения остатков между системами.
- Устойчивость к обрывам. Недоступность площадки или учётной системы не роняет выгрузку: очередь дозабирает пропущенные события после восстановления связи.
- Возвраты и отмены. Обратные движения попадают в учёт автоматически, остаток возвращается на склад без ручной правки.
- Прозрачность. Журнал показывает, что и когда ушло, где встало и почему — разбор занимает минуты вместо часов поиска.
Если пункт не выполняется — значит обмен настроен частично, и именно этот участок дорабатывается первым.
Способы обмена между 1С-Битрикс и Prom.ua: сравнение подходов
«1С-Битрикс» и Prom.ua по-разному хранят одно и то же: у площадки своя структура категорий и обязательный набор атрибутов, у сайта — своя модель разделов и свойств. Поэтому обмен строят не «в лоб», а через один из контуров связи, и выбранный контур определяет, как быстро площадка увидит новую цену или остаток и что произойдёт при сбое на любой из сторон.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Прямой обмен через программный интерфейс маркетплейса | Небольшой каталог, важна постоянная актуальность цен и остатков, заказы нужно забирать сразу | Зависимость от доступности чужой площадки, лимиты на число обращений, ошибка видна только в момент вызова |
| Обмен по расписанию пакетами | Каталог от сотен позиций, остатки меняются несколько раз в день, допустима задержка | Отставание между выгрузкой и публикацией, при сбое задача молча пропускает цикл — нужен контроль отчётов |
| Промежуточное хранилище данных | Несколько площадок или каналов продаж, сложные правила наценок и сопоставления категорий | Требует отдельной базы и регламента сверки, дороже в сопровождении |
| Ручная выгрузка прайса файлом | Разовые акции, пробный запуск на части ассортимента | Человеческий фактор, расхождения в остатках, не масштабируется |
На практике устойчивее всего комбинация: обмен по расписанию тянет каталог, цены и остатки, программный интерфейс забирает заказы и статусы, а промежуточное хранилище сглаживает несовпадение структур и хранит журнал сопоставления товаров. Контур подбираем под нагрузку — объём каталога, частоту изменения цен и то, какая система считается источником истины по остатку.
Этапы настройки обмена: от аудита данных до передачи регламентов
Обмен между каталогом на 1С-Битрикс и маркетплейсом Prom.ua ломается не в момент настройки, а на расхождениях в данных: справочники рассинхронизированы, единицы измерения не совпадают, остатки уезжают быстрее, чем площадка их принимает. Поэтому внедрение интеграции поэтапно идёт от аудита данных к регламенту — иначе после запуска каждой выгрузки приходится разбирать, почему позиция есть в кабинете, но не продаётся.
- Обследование. Фиксируем, какие справочники участвуют в обмене: номенклатура, категории, цены, склады, статусы заказов. Считаем объём — сколько позиций уходит в Prom.ua, как часто меняются цены и остатки.
- Аудит справочников и номенклатуры. Ищем дубли, позиции без категории, нулевые и отрицательные остатки, разъезд единиц измерения. Без этого сопоставление придётся переделывать после первых выгрузок.
- Схема сопоставления. Определяем, какое поле связывает товар в 1С с карточкой на площадке: внешний идентификатор, артикул или код. Прописываем правила для новых позиций и для тех, что уже опубликованы.
- Настройка обмена. Задаём направление потоков (товары, цены, остатки в одну сторону, заказы — в обратную), расписание выгрузок и приоритет источника данных при конфликте.
- Тестовый прогон. Гоняем обмен на небольшом срезе каталога и разбираем ответ площадки: отказы, битые ссылки, позиции без цены. Правки вносим в правила, а не в отдельные карточки.
- Проверка на боевых объёмах. Выгружаем полный каталог, сверяем контрольные суммы по количеству и ценам, проверяем, что заказ с площадки корректно попадает в учётную систему.
- Передача и регламент сопровождения. Отдаём карту сопоставления, порядок ручного запуска, перечень типовых ошибок с причиной и действием, а также ответственных с обеих сторон.
Что остаётся у заказчика: конфигурации, схемы, регламенты
Результат работ — не факт запущенного обмена, а комплект артефактов, по которому ваша команда дальше ведёт связку с маркетплейсом без нас. Ниже — что именно передаётся и какую задачу закрывает каждый документ.
- Настроенные профили обмена: выгрузка каталога, остатков и цен, приём заказов и синхронизация статусов — каждый профиль со своим расписанием, фильтром по разделу и правилами сопоставления номенклатуры.
- Схема потоков данных: карта «источник → приёмник», перечень передаваемых полей, справочники соответствия товаров, складов, единиц измерения и статусов заказов.
- Регламент обработки расхождений: что делать при отказе выгрузки, конфликте остатков, дубле заказа или ненайденной позиции — и какой случай требует ручного вмешательства.
- Политики доступа: отдельные учётные записи для обмена, минимально необходимые права, порядок ротации ключей и журнал изменений настроек.
- Инструкция для оператора: как проверить состояние обмена, где смотреть журнал, как запустить повторную синхронизацию и к кому эскалировать сбой.
- Тестовый контур: копия связки на тестовых данных, где правки в правилах сопоставления проверяются до выката в рабочий контур.
После запуска вы меняете ассортимент и подключаете новые разделы, не заказывая доработку под каждое изменение. Схема и регламенты описывают, как это делать самостоятельно; мы подключаемся там, где нужна доработка логики.
Кейс: обмен заказами и остатками для розничной сети
Розничная сеть с четырьмя складами и несколькими тысячами товарных позиций торговала через Prom.ua, а учёт вела в учётной системе. Заказы менеджеры забирали из личного кабинета вручную, остатки выгружали дважды в сутки — при активных продажах наличие расходилось с реальным уже к обеду.
До: ручная обработка и расхождения
Без участия человека проходило не больше 12% заказов. Остаток на складе догонял маркетплейс за 3-4 часа, а по итогам месяца около 7% заказов сходились с расхождениями по составу или количеству: их разбирали вручную, сверяя переписку с покупателем и движения по складу.
После: обмен без оператора
Собрали двусторонний обмен: заказы забираются по событию, остатки пересчитываются при каждом движении по складу, а не по расписанию. Каждая операция получает идентификатор, поэтому повторная выгрузка не создаёт дублей, а неудачные вызовы уходят в очередь с повторами и журналом, который виден в админке.
Доля заказов без ручного вмешательства выросла до 96%, реакция на изменение склада сократилась до пары минут, расхождения — меньше половины процента за месяц. Менеджеры переключились на возвраты, замены и нестандартные доставки, а журнал обмена стал основным инструментом сверки.
Чем отличается обмен по событию от обмена по расписанию?
Разница в том, что запускает выгрузку. Обмен по расписанию — задание планировщика: раз в заданный интервал оно собирает накопленные изменения и отправляет их пачкой. Обмен по событию стартует сразу после правки — изменилась цена, остаток или статус заказа, выгрузка ушла, не дожидаясь следующего цикла.
Для каталога в Prom.ua это вопрос цены ошибки: пока данные ждут своего часа, покупатель оформляет заказ по старой цене, а менеджер потом разбирает расхождение вручную. Событийная схема сокращает окно расхождения с десятков минут до секунд.
| Режим запуска | Когда подходит | Ограничения |
|---|---|---|
| По событию | Цены, остатки, статусы заказов — там, где расхождение сразу бьёт по продаже | Массовая правка каталога даёт пик коротких обращений к площадке |
| По расписанию | Справочники, описания, фото, характеристики — меняются редко, к задержке некритичны | Окно расхождения равно интервалу между запусками |
| Смешанный | Крупный каталог с активными продажами | Нужна очередь и правило, какая сущность идёт по какому каналу |
Нагрузка на сервер при обмене в событийной схеме выше и неравномернее: переоценка каталога на десятки тысяч позиций превращается в поток одиночных выгрузок. Поэтому события ставят в очередь, склеивают изменения за короткое окно в один пакет и ограничивают число одновременных обработчиков — пик гасится, а свежесть данных остаётся. Отказ площадки обрабатывается повтором, иначе часть изменений теряется молча.
На практике берут смешанный контур: заказы, цены и остатки — по событию, описания и медиа — по расписанию в ночное окно. Частота синхронизации данных и размер пакета подбираются по замерам, а не по умолчанию.
Частые технические сомнения при настройке обмена
Обмен между каталогом 1С-Битрикс и Prom.ua — не разовое включение, а постоянный режим: сбой связи, правки каталога или подключение нового поставщика проверяют его на прочность. Собрали то, что чаще всего уточняют до старта.
Что будет, если выгрузка оборвётся на середине?
Обмен идёт порциями, и результат каждой фиксируется в журнале. Повторный запуск после обрыва продолжается с последней подтверждённой позиции, а не с начала: принятые карточки и заказы не дублируются, а в журнале видно, на каком шаге пропала связь.
Как исключить задвоение заказов?
Заказ сопоставляется по внешнему идентификатору: повторно пришедшая запись обновляет статус, а не создаёт вторую. Если заказ изменили и на площадке, и в учётной системе, спор решается по времени последнего изменения, а расхождение уходит в отчёт.
Почему номенклатура выгрузилась частично?
Причина почти всегда в данных: товар без привязки к категории площадки, пустые обязательные атрибуты, дубли артикулов, нулевой остаток или отсутствующая цена. По каждой отсеянной позиции в отчёте указана причина, и после правки её догружают отдельным запуском.
Магазин будет простаивать во время настройки?
Нет. Первичная синхронизация и отладка идут на копии каталога, а боевой обмен включается в согласованное окно. Если что-то пойдёт не так, возврат к прежнему режиму — одна операция, витрина продолжает принимать заказы.
Обсудим задачу: как мы снимем риски обмена данными
Чтобы обсудить интеграцию сайта, не нужно готовить техническое задание — достаточно рассказать, что уже работает и какой результат нужен. Мы разберём текущую схему обмена 1С-Битрикс и Prom.ua, уточним источники данных и вернёмся с оценкой и планом работ: этапами, сроками и зонами ответственности.
Вводные для старта проекта обычно собираются за один разговор. Полезно иметь под рукой:
- перечень сущностей в обмене: товары, категории, характеристики, поставщики, контрагенты;
- что уходит на площадку, а что возвращается обратно — заказы, статусы оплаты и доставки, остатки;
- требуемую частоту синхронизации и поведение системы при расхождении цен или снятии позиции с продажи;
- доступы к тестовой копии базы и к кабинету продавца — схему проверяем без риска для живых заказов;
- кто со стороны заказчика принимает результат и подтверждает корректность сопоставления позиций;
- доработки в учётной системе, которые нельзя менять, и правила, которые обязаны сохраниться.
По итогам вы получаете карту обмена с перечнем полей и правил сопоставления, оценку трудозатрат по этапам и план работ с точками проверки.
Отдельным пунктом идёт поддержка обмена после запуска: журнал ошибок, оповещения о сбоях и регламент, по которому расхождения разбираются раньше, чем их заметит покупатель. Опишите задачу в свободной форме — вернёмся с оценкой и планом и предложим, с чего начать.