1С не видит новые заказы сайта: как восстановить обмен без дублей

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

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

Что проверить в первую очередь

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

• Проверьте, создается ли событие или запись очереди сразу после оформления заказа.
• Сравните внешний ID заказа на сайте и в 1С, включая регистр, префиксы и тип поля.
• Уточните, какие статусы разрешены для выгрузки и не изменились ли они после обновления.
• Проверьте дату последнего успешного обмена, расписание задания и свободное место для временных файлов.

Почему возникает проблема

Внешний симптом часто появляется не в том компоненте, где возникла первичная ошибка. Интерфейс может показывать неверное состояние из-за backend, очереди, кеша, прав доступа или внешнего API. Полезно проследить данные от источника до результата и найти первую точку расхождения. Это надежнее, чем исправлять последнее сообщение об ошибке или бесконечно перезапускать сервис.

• Фоновое задание завершилось ошибкой и больше не запускается по расписанию.
• Сайт выгружает только оплаченные заказы, а новый способ оплаты оставляет другой статус.
• Файл обмена формируется, но содержит кодировку, обязательное поле или товар, который не сопоставлен в 1С.
• HTTP-запрос завершился по таймауту после приема данных, поэтому стороны по-разному считают операцию выполненной.
• Уникальный индекс или правило поиска связывает новый заказ со старым документом.

Пошаговая диагностика

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

• Создайте тестовый заказ с одной известной позицией и проследите его ID во всех журналах.
• Сохраните исходный XML или JSON до преобразования и проверьте его валидатором.
• Сопоставьте время сервера сайта, сервера 1С и планировщика, учитывая часовой пояс.
• Проверьте ответ endpoint, HTTP-код, тело ошибки и количество повторных попыток.
• Сравните правила сопоставления товаров, покупателей, складов, типов цен и способов доставки.

Как восстановить пропущенные заказы без повторного создания

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

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

Как исправить проблему

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

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

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

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

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

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

• Новый тестовый заказ появляется в 1С один раз и получает корректную связь с сайтом.
• Повторная доставка того же заказа не создает второй документ.
• Заказ с неизвестным товаром попадает в понятный статус ошибки и может быть обработан после сопоставления.
• После временного отключения 1С накопленные заказы догружаются в правильном порядке.

Типичные ошибки при исправлении

• Удалять очередь и запускать обмен с нуля без списка уже обработанных ID.
• Считать HTTP 200 доказательством создания документа, не проверяя бизнес-результат.
• Менять номера заказов вручную для обхода уникальности.
• Игнорировать частично обработанные заказы, у которых создалась шапка, но не загрузились позиции.

Как предотвратить повторение

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

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

Что подготовить для технического разбора

• Описание ожидаемого и фактического поведения с точной последовательностью действий.
• Время проблемы, идентификатор тестового объекта и версии затронутых компонентов.
• Фрагменты журналов до и после ошибки без секретов и персональных данных.
• Перечень последних изменений и уже выполненных проверок.
• Безопасный доступ к тестовой среде либо способ воспроизвести сбой без влияния на клиентов.

Частые вопросы

Можно ли просто повторно выгрузить все заказы?

Можно только при доказанной идемпотентности. Иначе повторная выгрузка создаст дубли документов, резервов или уведомлений. Безопаснее выбрать отсутствующие внешние ID.

Почему обмен работает вручную, но не по расписанию?

Обычно отличаются пользователь запуска, права, окружение, рабочая папка или доступ к сети. Сравните контекст ручного и фонового выполнения.

Когда нужна помощь специалиста

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