Почему заказы с сайта не передаются в 1С: пошаговая диагностика

01

Сначала определите, на каком участке пропал заказ

Фраза «заказы не уходят в 1С» слишком общая для диагностики. Заказ мог не создаться на сайте, создаться, но не пройти отбор на экспорт, попасть в файл обмена и не быть обработанным 1С. Иногда документ в 1С создан, но менеджер ищет его не в том журнале, по неверному периоду или под другим видом документа. Пока не зафиксирована точка разрыва, разработчик будет проверять код сайта, а бухгалтерия — настройки 1С, и время уйдёт на параллельные догадки.

Начните с одного конкретного заказа. Запишите номер, дату и время оформления, сумму, состав корзины, способ оплаты, доставки, статус и e-mail покупателя. В административной части 1С-Битрикс откройте карточку: она должна существовать, содержать товары и иметь ожидаемый статус. Затем уточните у сотрудника 1С, какой документ должен появиться: заказ клиента, заказ покупателя, реализация или отдельный документ по внутреннему регламенту.

Интеграция 1С с Битрикс обычно работает не в момент нажатия кнопки «Оформить». Обмен выполняется по расписанию либо запускается из 1С. Поэтому важны время последнего успешного сеанса, интервал запуска и очередь необработанных заказов. Если заказ появился спустя 15 минут, это не ошибка передачи, а вопрос к согласованному SLA обмена. Если не появился после нескольких циклов, переходите к проверке отбора и журналов.

Не изменяйте статусы и состав проблемного заказа до завершения проверки. Такие действия могут скрыть исходную причину: например, менеджер вручную перевёл заказ в разрешённый статус, и он ушёл при следующем запуске. Для безопасного теста лучше создать новый заказ с заметным номером и тестовым товаром, который разрешён к продаже.

03

Проверьте правила отбора до поиска технической ошибки

В типовой схеме сайт не обязан передавать каждый оформленный заказ. Бизнес нередко исключает неоплаченные онлайн-заказы, отмены, черновики, заказы с оплатой при получении или заявки, которые ещё не подтвердил менеджер. Правило может быть задано на стороне модуля обмена, в обработке 1С или в индивидуальном обработчике. Поэтому сравните проблемный заказ с последним успешно переданным: не только по номеру, но и по значениям всех управляющих полей.

Особенно внимательно проверьте статус, флаги оплаты и отгрузки, тип плательщика, валюту, склад, службу доставки, платёжную систему и наличие позиций. Нетипичный способ доставки или товар без внешнего идентификатора способен остановить передачу всего документа либо исключить его из выгрузки. Если на сайте есть B2B-кабинет, отдельные правила могут действовать для юридических и физических лиц.

Маркетологу полезно запросить у разработчика не перечень настроек «на словах», а явную таблицу условий: какие заказы выгружаются, когда и с каким документом в 1С. Это помогает не путать технический сбой с предусмотренным процессом. Настройки типового обмена и его журналирование описаны в документации 1С-Битрикс; для проекта всё равно важнее фактическая конфигурация.

04

Сверьте время обмена и журналы с обеих сторон

После проверки условий отбора ответьте на следующий вопрос: сайт вообще пытался передать заказ? Для этого недостаточно увидеть дату последнего обмена в интерфейсе. Нужны записи с временем, идентификатором сессии, количеством переданных заказов и текстом ошибки. На стороне Битрикс журнал может находиться в настройках модуля, файлах логов или в отдельном кастомном разделе. На стороне 1С смотрят журнал регистрации и сообщения обработки обмена.

Сопоставляйте время по одному часовому поясу. Сервер сайта, сервер 1С и рабочее место оператора иногда настроены по-разному. В результате запись «10:05» в одном журнале соответствует «07:05» в другом, а команда ошибочно считает, что операции не связаны. Для тестового заказа зафиксируйте момент оформления и вручную запустите один обмен, если регламент и права это допускают.

Ошибка авторизации, тайм-аут, обрыв сессии или недостаток прав обычно видны в журнале. Но запись об успешной выгрузке ещё не подтверждает создание документа: она может означать только передачу пакета. Финальной точкой считается документ в 1С с номером заказа сайта или сохранённым внешним идентификатором.

05

Разберите данные заказа, которые не принимает 1С

Если обмен запускается, но останавливается на конкретном заказе, обычно проблема в данных. В заказе есть реквизиты, обязательные для 1С, но необязательные для формы на сайте: организация, ИНН, КПП, адрес, контактное лицо, склад, договор, вид цены. При добавлении нового способа доставки, оплаты или свойства заказа разработчики часто меняют сайт, но не карту соответствия в обработке обмена.

Отдельный риск — товарные позиции. В 1С может не существовать номенклатура с передаваемым XML_ID, быть отключён вариант характеристики, закрыт склад или не совпадать единица измерения. Заказ с обычным товаром проходит, а заказ с торговым предложением, комплектом, подарком или услугой — нет. Не удаляйте такую позицию ради быстрого решения: она указывает на участок, который нужно исправить.

Попросите выгрузить фактический состав проблемного заказа: внешний ID заказа, ID товара или предложения, количество, цену, скидку, НДС, доставку, оплату и пользовательские свойства. Сравните набор с успешным заказом. Проверять нужно не только видимые названия в админке, но и системные идентификаторы, по которым системы сопоставляют сущности.

06

Проведите тест так, чтобы результат можно было принять

Диагностика часто заканчивается сообщением «исправили», но через неделю проблема возвращается после изменения статуса, обновления 1С или появления нового товара. Чтобы этого не произошло, тестируйте не случайный заказ из реального потока, а контролируемый сценарий. Он должен повторять проблему и оставлять следы в обеих системах: номер, время, статус и документ-результат.

Назначьте роли заранее. Менеджер сайта создаёт заказ и фиксирует параметры. Специалист 1С запускает либо ожидает регламентный обмен и проверяет журнал. Разработчик при необходимости смотрит логи и карту полей. Один ответственный собирает результаты в задаче: скриншоты допустимы как подтверждение, но ключевыми доказательствами остаются номера заказов, документов и записи журнала.

Если изменения затрагивают обработчик обмена, сначала применяйте их на тестовом контуре. В рабочей базе нельзя без резервной копии многократно перезапускать старые пакеты: это может создать дубли заказов, оплат или контрагентов. Для примеров реальных процессов и интерфейсов используйте подтверждённые материалы из портфолио ICONICA, а не условные скриншоты.

1. 1

   Выберите контрольный заказ. Укажите уникальный номер, допустимый товар, способ оплаты и статус, который должен быть выгружен.

2. 2

   Зафиксируйте исходные данные. Сохраните время создания, сумму, состав корзины и системные идентификаторы позиций.

3. 3

   Запустите один цикл. Дождитесь расписания либо выполните разрешённый ручной обмен без параллельных запусков.

4. 4

   Проверьте документ в 1С. Найдите его по внешнему номеру и сверьте реквизиты, товары, цены и скидки.

5. 5

   Повторите безопасно. Убедитесь, что следующий обмен не создаёт дубль и не меняет подтверждённые данные непредсказуемо.

07

Не путайте разовый сбой с неисправным процессом

Один пропавший заказ может быть следствием краткого сбоя сети или блокировки базы 1С во время обмена. Однако несколько заказов с одинаковым признаком — например, все заказы с новой доставкой или все юридические лица — говорят о дефекте настройки. Для руководителя важно не только восстановить потерянные документы, но и оценить масштаб: какие даты затронуты, сколько заказов не дошло, не было ли повторной передачи.

Соберите выборку хотя бы за период между последним подтверждённо успешным и текущим обменом. Сравните количество заказов, которые должны были пройти отбор на сайте, с количеством документов в 1С. Не сравнивайте только общую выручку: разные статусы, отмены и частичные оплаты сделают такой вывод неточным. Нужна сверка по внешнему номеру заказа.

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

08

Когда исправление требует доработки, а не настройки

Стандартный обмен подходит, пока бизнес-процесс укладывается в его модель: заказ создаётся в одном типе документа, товары сопоставляются по устойчивому идентификатору, а статусы и реквизиты не требуют сложных преобразований. Если сайт передаёт разный набор данных для B2B и розницы, резервирует товар по нескольким складам, создаёт связанные документы или получает статусы из нескольких систем, правила часто выходят за пределы типовой настройки.

Признак необходимости доработки — не сама ошибка, а повторяющееся ручное действие. Например, менеджер ежедневно дописывает договор, бухгалтер вручную исправляет НДС, а оператор переносит заказы с определённой доставкой. Такие исключения стоит описать как бизнес-правила, а не закреплять инструкцией «не забыть поправить».

В задаче на доработку отделите обязательные поля от желательных, укажите источник каждого значения и поведение при ошибке. Если поле не заполнено, система может не создавать документ, ставить заказ в очередь ошибок или передавать его с предупреждением — решение зависит от процесса продаж и должно быть согласовано владельцем 1С.

09

Рабочее решение начинается с точки разрыва

Чтобы восстановить обмен заказами, не нужно одновременно менять статусы, перезапускать обработку и просить 1С «перезалить всё». Выберите один проблемный заказ, подтвердите его состояние на сайте, проверьте условия экспорта, затем последовательно найдите его в журнале передачи и в 1С. Такая цепочка быстро показывает владельца проблемы: сайт, инфраструктура, обработка 1С или бизнес-правило.

Если причина в настройке, зафиксируйте её в регламенте: какие статусы выгружаются, какой документ создаётся, кто отвечает за контроль и в какой срок заказ должен быть виден в 1С. Если причина в данных или кастомной логике, подготовьте доработку с картой полей и сценарием ошибки. Не ограничивайтесь исправлением одного номера: проверьте период, в который дефект мог затронуть другие заказы.

Подрядчика стоит подключать, когда нет доступа к логам и обработке, ошибка повторяется после штатных действий, требуется изменить сопоставление товаров и реквизитов или есть риск дублей в рабочей базе. Для передачи задачи достаточно контрольного заказа, времени, ожидаемого документа и результатов проверок. Это позволяет оценить работу по фактам, а не по формулировке «обмен иногда не работает».