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

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

Что значит «заказы с сайта не попадают в 1С» и где границы задачи

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

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

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

Карта маршрута заказа: от оформления до документа в 1С

Карта маршрута — это рабочий артефакт, который помогает не гадать, а последовательно проверять этапы. Ниже — типовая последовательность для магазина на Битрикс с обменом с 1С; конкретные названия объектов зависят от конфигурации.

1. Покупатель оформляет заказ. На сайте создаётся запись заказа с номером и внутренним идентификатором. 2. Заказ попадает в очередь на выгрузку. Важно понимать, что именно считается событием для выгрузки: новый заказ, изменение заказа или изменение статуса. 3. Формируется пакет обмена. В него попадают данные заказа, состав, контрагент, параметры доставки и оплаты. 4. Пакет передаётся в учётную систему. Передача может идти по расписанию или по ручному запуску. 5. Учётная система принимает пакет и пытается создать или обновить документ. На этом шаге срабатывают проверки обязательных реквизитов. 6. Учётная система возвращает ответ: идентификатор созданного документа, статус, даты оплаты и отгрузки. 7. Сайт применяет ответ: связывает заказ с документом и обновляет статус.

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

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

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

Идентификатор заказа и подтверждение приёма

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

Подтверждение приёма — это не «обмен завершился без сообщений на экране», а конкретная запись: документ создан, идентификатор записан, ответ вернулся на сайт. Пока этой записи нет, заказ считается недоставленным, и повторная передача должна быть осознанным действием, а не серией нажатий. Разница принципиальная: в первом случае вы управляете процессом, во втором — создаёте дубли и разбираетесь с расхождениями в учёте.

Практический порядок проверки:

• найдите заказ на сайте и зафиксируйте его номер и идентификатор;
• проверьте, что заказ действительно попал в очередь выгрузки;
• найдите в журнале обменов запись о передаче этого заказа;
• проверьте журнал ошибок на стороне учётной системы;
• убедитесь, что в 1С появился документ и он связан с тем же идентификатором.

Если на каком-то шаге записи нет, дальнейший поиск по другим этапам неэффективен: сначала нужно восстановить именно этот этап. Такой порядок экономит время, потому что отсекает заведомо ложные версии — например, поиск ошибки в учётной системе, когда заказ вообще не покидал сайт.

Безопасный повтор передачи: как не получить дубли

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

Безопасный порядок действий при подозрении на потерю заказа:

• сначала сделайте копию базы и убедитесь, что есть точка возврата;
• проверьте, не создался ли документ в 1С, но не связался с сайтом;
• если документ есть, восстанавливайте связь, а не создавайте новый;
• если документа нет, повторяйте передачу на тестовом контуре и только потом на рабочем;
• после повтора сверьте количество документов по этому заказу.

Отдельно стоит договориться о регламенте: кто имеет право запускать повторную передачу, при каких условиях и что фиксируется после. Без этого повтор превращается в неуправляемый процесс, а расхождения в учёте обнаруживаются позже и обходятся дороже. Простое правило — повтор только с подтверждённой точкой возврата и только после проверки, что документа действительно нет.

Диагностика: где искать причину по журналам обмена

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

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

Типовые сообщения и их смысл:

• «Обмен заказами завершён с ошибками» — пакет дошёл, документ не создан. Причина: данные контрагента или обязательные реквизиты.
• «Не удалось найти/создать контрагента» — в переданных данных отсутствуют обязательные поля конфигурации.
• «Не удалось найти вид номенклатуры» — в учётной системе нет видов, критичных для обмена.
• «Изменения товаров не зарегистрированы» — сработал фильтр выгрузки или изменений с прошлого обмена не было.
• «Поле объекта не обнаружено» — расхождение структуры данных модуля и фактической структуры.

Важно: сообщение об ошибке — это точка входа, а не диагноз. Одно и то же сообщение может возникать по разным причинам, поэтому проверяют данные, а не только текст. И наоборот: отсутствие ошибок в журнале не означает, что заказ дошёл — он мог не попасть в очередь выгрузки.

Типичные причины и что они означают

Обязательные реквизиты контрагента

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

Виды номенклатуры

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

Фильтр выгрузки товаров

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

Обмен с копией базы

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

Расхождение после обновления

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

Статус не меняется

Отдельный сюжет — заказ дошёл, а статус на сайте не обновляется. Логика обмена такова: статус меняется, если из учётной системы передаются дата оплаты или дата отгрузки. Чтобы эти даты попали в файл обмена, в учётной системе нужно сформировать и провести соответствующие документы. Признаком оплаты служит состояние расчётов с контрагентом, признаком отгрузки — состояние по заказам покупателей. Сами статусы, в которые переводится заказ, задаются в настройках модуля интернет-магазина. Если оплата на сайте идёт через платёжный сервис, стоит отдельно проверить, как результат оплаты связан с учётной системой: об этом — материал Интеграция магазина с платёжными системами: онлайн-оплата и касса.

Таблица принятия решения

Таблица помогает выбрать направление, но не заменяет проверку данных. Если симптом не совпадает ни с одной строкой, начинайте с карты маршрута и ищите первый этап без подтверждения.

Учебный пример: заказ не дошёл до 1С на тестовом контуре

Учебный пример. Данные условны.

Входные условия. Интернет-магазин на Битрикс, обмен по расписанию. За сутки оформлены заказы, один — от нового покупателя. В 1С видны не все документы, по одному заказу — ошибка обмена.

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

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

Проверка. Сверяют количество документов по каждому заказу, состояние статусов, наличие ответных записей на сайте. Отдельно проверяют, что исправление не сломало передачу заказов от уже известных покупателей.

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

Как проверить результат и принять работу

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

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

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

Чек-лист перед запуском и после изменений

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

Типичные ошибки и ограничения

Первая ошибка — считать, что «обмен прошёл», если на экране не было сообщений. Без записи в журнале и без документа в учётной системе это не подтверждение.

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

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

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

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

Какие исходные данные подготовить для оценки

Чтобы оценить объём работ, нужны не общие слова, а факты о вашей системе.

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

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

Интеграция сайта с 1С