Заказ с сайта не уходит в 1С, когда обмен каталога при этом может работать нормально. Обратный поток — отдельный договор: в какой момент документ выгружается, какой статус это разрешает, какие поля обязательны и что считать тем же заказом при повторе. Сначала находят заказ на сайте, затем запись в журнале выгрузки, затем приём в 1С. Если журнала нет, чинить «1С» ещё нечего.
Как проектировать обмен целиком — в чек-листе до запуска. Здесь только ситуация «оплата или оформление прошло, в учёте пусто».
Сначала докажите, что сайт вообще отправил документ
Откройте заказ в админке Битрикс и ответьте письменно:
- заказ создан, оплачен, отменён или ещё «ожидает оплату»;
- внешний идентификатор для 1С заполнен или пуст;
- время создания и время последней выгрузки, если поле есть;
- способ оплаты и доставки, юрлицо или физлицо.
Типовой обмен часто не выгружает заказ в момент нажатия «оформить». Он ждёт статус, оплату, агента по cron или ручной запуск. Если правило — «только после оплаты», неоплаченный заказ в 1С не появится, и это ожидаемое поведение.
Проверьте расписание: агент Битрикс, cron, выгрузка из 1С, которая забирает файлы. Заказ может лежать в очереди, пока не сработал следующий прогон. «Прошло пять минут, в 1С нет» при интервале обмена 30 минут — не инцидент.
Три развилки, не одна «ошибка обмена»
- Сайт не ставил заказ в очередь. Статус не тот, модуль обмена выключен, заказ тестовый в группе, которая не выгружается, свойство «не выгружать в 1С».
- Сайт выгрузил, 1С не приняла. Файл или сообщение ушло, в 1С отказ по контрагенту, номенклатуре, организации, договору, пустому ИНН, неизвестному складу.
- 1С приняла, вы ищете не там. Другая организация, другой журнал документов, заказ как черновик, поиск по номеру сайта вместо номера 1С.
Пока не ясно, какая из трёх, переписывать модуль рано.
Статусы и момент отправки
Согласуйте таблицу: статус сайта → действие обмена → статус в 1С. Без неё исполнитель и учёт спорят на каждом заказе.
Типичные разрывы:
- сайт считает заказ «выполнен», 1С ждёт «к обеспечению»;
- онлайн-оплата меняет статус через webhook позже, чем сработал обмен;
- отмена на сайте не должна создавать документ в 1С, но правило не записано;
- менеджер меняет статус руками, обмен воспринимает это как новый документ или наоборот игнорирует.
Если оплата приходит отдельным уведомлением, заказ может уехать в 1С до оплаты или после — это должно быть явным правилом, не догадкой. Про идемпотентность платёжных webhook на стороне сайта — отдельно, в разборе webhook оплаты.
Поля, из‑за которых 1С молча отказывает
1С часто не создаёт документ, если не с чем работать: контрагент, договор, организация, склад, ставка НДС, номенклатура без XML_ID. На сайте при этом заказ выглядит нормально: ФИО, телефон, состав корзины.
Проверьте на проблемном заказе:
- у всех позиций есть внешний идентификатор, тот же, что в справочнике 1С;
- юрлицо заполнило обязательные реквизиты;
- доставка и оплата сопоставлены со справочниками учёта, а не только с названиями на витрине;
- скидка и бонусы выгружаются в понятном 1С виде.
Отказ может быть в журнале 1С как предупреждение при «успешном» сеансе обмена. Зелёный статус транспорта не равен проведённому заказу.
Повторная отправка и дубли
Исправление «не ушёл» часто превращается в «ушёл дважды». Повторная выгрузка того же заказа не должна создавать второй документ. Нужен устойчивый внешний номер и правило обновления существующего.
Если дубли уже появились, сначала останавливают повторный прогон, сверяют идентификаторы, только потом чистят лишние документы в 1С по согласованному регламенту. Не удаляйте заказы на сайте, чтобы «выгрузить заново», пока не понятен ключ сопоставления.
Журналы и агенты
На сайте: время агента или cron, идентификатор заказа, имя файла или сообщения, ошибка с текстом 1С, если она вернулась. В 1С: журнал обмена, непроведённые документы, сообщения пользователю.
Проверьте, что агент обмена активен, NEXT_EXEC не в прошлом на часы, cron реально бьёт в PHP. Как смотреть агентов — в заметке про cron и b_agent. Если агент жив, а заказов в логе нет, снова вернитесь к статусу и отбору, а не к серверу.
Сбой обмена каталога (цены, остатки) и сбой заказов часто независимы. Каталог может быть свежим, а заказы стоять. Разбор витрины — в ценах и остатках, которые не совпадают с 1С.
Как проверить одним тестовым заказом
На копии или в согласованное окно на проде:
- Оформить заказ с одной простой позицией, без скидки, с заполненными реквизитами.
- Довести его до статуса, с которого по регламенту идёт выгрузка.
- Дождаться прогона или запустить выгрузку вручную.
- Найти запись в журнале сайта и документ либо отказ в 1С.
- Повторить отправку того же заказа: второго документа быть не должно.
- Отдельно проверить заказ с SKU, скидкой, доставкой и юрлицом.
«Один заказ когда-то прошёл» недостаточен, если ломаются только оплаченные или только оптовые.
Не перезапускайте полный обмен каталога, чтобы «подтолкнуть заказы». Это другая очередь и лишняя нагрузка. Формат разбора живого обмена — на странице интеграции с 1С.
Итог
Заказ не появляется в 1С, пока не ясно: сайт его не отдал, 1С отказала по данным или документ лежит не в том журнале. Это читается из статуса, очереди и двух логов. Когда три развилки названы, правка точечная. Когда не названы, любой «перезапуск обмена» либо ничего не делает, либо создаёт дубли.
