← На главную

Часто при интеграции 1С с интернет-магазином возникает неприятная ситуация: в базу загружается документ Заказ покупателя, менеджер меняет его статус и дату, но через некоторое время эти реквизиты самопроизвольно возвращаются к старым значениям. Мы понимаем, что это делает какое-то фоновое или регламентное задание. Разберем по шагам, как выследить "виновника" и устранить проблему на примере конфигурации 1С:УНФ (Управление нашей фирмой).

Возможные причины: кто и почему меняет данные?

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

1. Повторная выгрузка с сайта. Сайт не получает ответ об успешном приеме или синхронизация статусов из 1С на сайт не настроена. При следующем сеансе обмена (который запускается регламентным заданием) сайт заново отправляет свои, уже неактуальные для 1С, данные.
2. Ассистент управления нашей фирмой. В УНФ встроен механизм автоматизации — ассистенты Даша или Рита. Если настроены правила (например, отмена неоплаченных заказов), физически их выполняет фоновое задание ассистента, которое может менять статусы.
3. Отложенное проведение или расчет. Фоновые задания могут выполнять отложенное проведение документов, и если в конфигурации есть нетиповая логика (например, в расширениях), она может перезаписывать реквизиты.

Базовые методы диагностики

Рассмотрим штатные инструменты, которые помогут нам сузить круг поисков без программирования.

1. Анализ Журнала регистрации (ЖР)
Откроем Журнал регистрации и посмотрим, кто и когда менял проблемный заказ. Журнал зафиксирует событие изменения данных. Если изменение делает регламентное задание, в качестве пользователя часто выступает служебная учетная запись, под которой выполняется фоновый процесс.

2. Включение штатного версионирования
Журнал регистрации показывает только сам факт изменения. Чтобы увидеть, какие именно поля (статус, дата) поменялись и на какие значения, включим в базе встроенное версионирование объектов для документа ЗаказПокупателя. Это позволит наглядно сравнивать версии документа и точно определять момент "отката".

3. Назначение уникальных пользователей для заданий
Отличной практикой является разделение прав. Назначим каждому регламентному заданию (или хотя бы самым подозрительным, таким как обмен с WEB-сайтом) своего уникального служебного пользователя. Тогда в Журнале регистрации мы сразу увидим имя конкретного задания, которое изменило заказ.

Расширенный поиск и отладка

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

1. Сопоставление расписания фоновых заданий
Перейдем в раздел настроек обслуживания и откроем историю выполнения фоновых заданий. Отсортируем их по времени завершения. Сопоставим это время с точным временем изменения документа из Журнала регистрации. Обычно таким образом круг подозреваемых сужается до 1-2 заданий.

2. Отладка фоновых заданий в Конфигураторе
Это самый точный способ найти источник. Разберем его подробнее:

1. В настройках отладки конфигуратора включим автоматическое подключение к фоновым заданиям.
2. Откроем модуль объекта документа ЗаказПокупателя.
3. Найдем обработчик события ПередЗаписью и установим там точку останова.
4. Для удобства можно задать условие точки останова, чтобы отладчик срабатывал, только если статус документа меняется на конкретный "старый".

Когда фоновое задание попытается изменить документ, отладчик остановится. В стеке вызовов мы точно увидим, какая процедура, обработка или расширение инициировала запись документа.

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

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

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

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

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