В процессе разработки и сопровождения систем на платформе «1С:Предприятие» можно столкнуться с крайне нестандартным поведением системы: при записи документа (например, РеализацияТоваровУслуг в конфигурации «1С:Бухгалтерия 3.0») в пользовательском режиме система ведет себя так, будто выполняется перенос данных. При этом свойство ОбменДанными.Загрузка принимает значение Истина. Самое загадочное в этой ситуации — такое поведение проявляется только под одним конкретным пользователем системы.
Давайте подробно разберем, почему возникает эта проблема, какие механизмы платформы за это отвечают, и как быстро локализовать источник «аномалии» с помощью инструментов отладки.
Свойство ОбменДанными.Загрузка — это стандартный инструмент платформы «1С:Предприятие», предназначенный для оптимизации импорта данных из внешних источников. Когда этот флаг установлен в значение Истина, платформа сигнализирует коду конфигурации о том, что объект записывается «как есть».
При этом происходят следующие изменения в логике работы системы:
ПередЗаписью, ПриЗаписи, ОбработкаПроведения) содержат в самом начале условие, прерывающее выполнение проверок бизнес-логики.Стандартный шаблон написания кода в модулях документов выглядит следующим образом:
Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
Если ОбменДанными.Загрузка Тогда
Возврат;
КонецЕсли;
// Далее идет стандартная бизнес-логика и проверки
КонецПроцедуры
Если этот флаг взведен при интерактивной работе пользователя, это означает, что пользователь может провести документ «задним числом» в закрытом периоде, записать документ с незаполненными ключевыми реквизитами или нарушить ссылочную целостность базы данных. Это серьезная угроза для корректности ведения учета.
---
Если аномальное поведение наблюдается только у одного пользователя, мы можем сразу исключить глобальные сбои платформы. Проблема кроется в программном коде или настройках прав. Рассмотрим подробнее основные причины.
В современных конфигурациях обмен с внешними системами (CRM, личные кабинеты маркетплейсов, мобильные приложения, интернет-магазины) часто настраивается под выделенной служебной учетной записью.
Когда внешняя система подключается к 1С через REST API (OData) или HTTP-сервисы, она выполняет запросы от имени этого пользователя. В запросах может передаваться специальный заголовок, переводящий запись объектов в режим загрузки (например, заголовок 1C_OData-DataLoadMode: true). При этом в Журнале регистрации и при анализе измененного документа автором изменений будет числиться именно этот пользователь.
Некоторые регламентные задания (например, загрузка банковских выписок, распознавание первичных документов или автоматическое закрытие месяца) могут быть жестко привязаны к сеансу определенного пользователя (обычно администратора). При выполнении такого фонового процесса код конфигурации может принудительно устанавливать:
ДоговорОбъект = СсылкаНаДоговор.ПолучитьОбъект();
ДоговорОбъект.ОбменДанными.Загрузка = Истина;
ДоговорОбъект.Записать();
Для стороннего наблюдателя это выглядит так, будто пользователь вручную изменил объект в обход проверок.
Если данный пользователь обладает правами администратора, он мог использовать стандартную обработку «Групповое изменение реквизитов». В дополнительных настройках этой обработки (доступных под административными правами) есть специальный флаг: «Записывать объекты в режиме загрузки (ОбменДанными.Загрузка = Истина)».
Если администратор включил этот флаг один раз, система запоминает эту настройку для его сеанса. Все последующие групповые изменения, выполняемые им, будут перезаписывать объекты без проверок бизнес-логики.
Часто для конкретных менеджеров или бухгалтеров подключаются внешние печатные формы, обработки заполнения табличных частей или целые АРМ (автоматизированные рабочие места). Недобросовестные разработчики, чтобы обойти программные ограничения или ошибки заполнения данных, пишут код в обход правил, принудительно встраивая ОбменДанными.Загрузка = Истина перед вызовом метода Записать().
---
Для того чтобы быстро и точно определить, какой именно кусок кода или внешняя интеграция взводит этот флаг, выполним несколько последовательных шагов диагностики.
Прежде чем переходить к конфигуратору, проанализируем системный журнал. Это позволит сузить круг подозреваемых:
Фоновое задание, WS-соединение или HTTP-сервис — запись инициирована автоматической внешней системой или регламентным заданием.Тонкий клиент или Толстый клиент — действие выполнено интерактивно самим пользователем (возможно, через запущенную им обработку).Наиболее эффективным способом локализации программного кода является использование конфигуратора и механизма точек останова. Выполним следующие действия:
РеализацияТоваровУслуг (или тот документ, при записи которого возникает проблема).ПередЗаписью и установим точку останова на первой значимой строке кода.ОбменДанными.Загрузка = Истина (или просто ОбменДанными.Загрузка).Теперь запустим сеанс отладки под учетной записью проблемного пользователя и попробуем воспроизвести запись документа. Отладчик остановит выполнение программы именно в тот момент, когда объект будет записываться с признаком загрузки.
После того как сработала точка останова, нам не нужно вручную просматривать тысячи строк кода конфигурации. На помощь приходит инструмент Стек вызовов:
Ctrl + Alt + C).Записать() и где перед этим коварно установили свойство Загрузка = Истина.Пример «подозреваемого» участка кода, который мы можем обнаружить в стеке вызовов:
// Внешняя обработка заполнения цен
Процедура ЗаполнитьЦеныНаСервере(ДокументСсылка)
ДокументОбъект = ДокументСсылка.ПолучитьОбъект();
// Программное изменение реквизитов...
ДокументОбъект.ОбменДанными.Загрузка = Истина; // Вот он, виновник!
ДокументОбъект.Записать(РежимЗаписиДокумента.Запись);
КонецПроцедуры
Проанализировав стек вызовов, мы сможем принять решение: исправить некорректный код внешней обработки, скорректировать права пользователя или изменить настройки интеграции с внешними информационными системами.