В процессе разработки или модификации конфигураций на платформе 1С программисты часто сталкиваются с критической ошибкой: «Операция не может быть выполнена из-за несоответствия версии или отсутствия записи базы данных (возможно, запись была изменена или удалена)!». Эта проблема особенно характерна для сложных документов, таких как ЗаказНаПроизводство, где изменение одного реквизита может запускать целую цепочку внутренних механизмов системы.
В этой статье мы подробно разберем, почему возникает эта ошибка, проанализируем конкретный программный код и выясним, как найти и устранить причину конфликта версий данных.
Для начала выясним причину возникновения данного сообщения. Платформа 1С использует механизм оптимистической блокировки. У каждого объекта в базе данных есть скрытый реквизит — ВерсияДанных. Когда мы выполняем метод ПолучитьОбъект(), система считывает текущую версию документа из базы в оперативную память. В момент вызова метода Записать() платформа сравнивает версию объекта в памяти с версией, которая записана в базе на данный момент.
Если эти версии различаются, система делает вывод: «Кто-то другой изменил документ, пока мы с ним работали», и блокирует запись, чтобы не допустить потери данных или нарушения логики. Рассмотрим подробнее, как это проявляется в программном коде.
Проанализируем фрагмент кода, в котором происходит перенос заказа на другую дату в цикле:
Для Каждого строка_ТаблЗаказы Из _МСтрТаблЗаказы Цикл
// Получаем объект документа по ссылке
_ДокО_ЗаказНаПроизводство = строка_ТаблЗаказы.ДокЗаказ.ПолучитьОбъект();
// Вычисляем параметры через вспомогательную функцию
стру_ПараметрыТехОперации = глПолучитьПараметрыТехнологическойОперации(
_ДокО_ЗаказНаПроизводство.ТехнологическаяОперация,
_ДокО_ЗаказНаПроизводство.ТехнологическаяКарта
);
// Изменяем реквизиты объекта
_ДокО_ЗаказНаПроизводство.ДатаИсполнения = ?(глПустоеЗначение(ВхСтрокаПриемник.Окончание), ВхСтрокаПриемник.Period, ВхСтрокаПриемник.Окончание);
_ДокО_ЗаказНаПроизводство.РазмещенВПроизводственномРасписании = НЕ глПустоеЗначение(_ДокО_ЗаказНаПроизводство.ДатаИсполнения);
// Попытка записи
Попытка
Если _ДокО_ЗаказНаПроизводство.Проведен Тогда
_ДокО_ЗаказНаПроизводство.Записать(РежимЗаписиДокумента.Проведение, РежимПроведенияДокумента.Неоперативный);
Иначе
_ДокО_ЗаказНаПроизводство.Записать(РежимЗаписиДокумента.Запись);
КонецЕсли;
Исключение
Сообщить(ОписаниеОшибки());
Возврат;
КонецПопытки;
КонецЦикла;
В ходе отладки было замечено, что ошибка пропадает, если закомментировать строку изменения реквизита ДатаИсполнения. Это ключевой момент. Выясним причину, почему изменение конкретного поля приводит к конфликту версий.
Разберем ситуацию, когда внутри функции глПолучитьПараметрыТехнологическойОперации или при обращении к свойствам объекта вызываются другие механизмы. Если в этой функции происходит запись каких-то связанных данных или (что еще хуже) запись самого документа в фоновом режиме или через другой экземпляр объекта, версия в базе данных обновится.
Что нужно проверить: не используется ли в параметрах функций сам _ДокО_ЗаказНаПроизводство. Если функция принимает объект и где-то внутри вызывает Записать(), то основная процедура записи в цикле завершится ошибкой, так как версия объекта в переменной _ДокО_ЗаказНаПроизводство уже не будет соответствовать версии в БД.
В конфигурациях типа ERP, УПП или Комплексная автоматизация документ ЗаказНаПроизводство обвешан множеством Подписок на события. Рассмотрим по шагам, что происходит при изменении ДатаИсполнения:
ПередЗаписью.Особенно это актуально, если в системе включены механизмы автоматического планирования. При программном изменении ключевых дат срабатывают обработчики, которые «под капотом» обновляют записи в регистрах сведений или даже в самом документе.
Посмотрим на ситуацию со стороны модуля самого документа. Проверьте процедуры ПередЗаписью и ПриЗаписи. Если там встречается вызов метода ЭтотОбъект.Записать(), это гарантированно приведет к ошибке несоответствия версии, так как вторая попытка записи начнется до того, как завершилась первая, но после того, как первая уже «забронировала» новую версию.
Рассмотрим пошаговый алгоритм действий для решения этой проблемы:
Первым делом откройте Журнал регистрации и отфильтруйте события по данному документу. Посмотрите, нет ли там записей о проведении или изменении документа в ту же секунду, когда работает ваша обработка. Это поможет понять, какой именно механизм (фоновое задание, другой пользователь или подписка) меняет данные параллельно с вами.
В конфигураторе включите режим Остановка по ошибке. Когда система выбросит исключение, посмотрите стек вызовов. Это позволит увидеть, не проваливается ли программа в дебри типовых модулей перед самой ошибкой.
Проанализируем таблицу _МСтрТаблЗаказы. Если в этой таблице один и тот же ДокЗаказ встречается дважды, то на второй итерации цикла вы получите ошибку. Почему? Потому что на первой итерации вы уже успешно записали этот объект, изменив его версию в базе, а ссылка в таблице всё еще указывает на старую версию (хотя метод ПолучитьОбъект() должен возвращать актуальную версию, иногда кэширование на стороне сервера может сыграть злую шутку).
Если вы подозреваете, что документ мог быть изменен сторонним процессом сразу после того, как вы получили его объект, можно попробовать принудительно обновить данные перед записью. Однако помните, что метод ПолучитьОбъект() и так считывает данные из базы. Проблема обычно возникает между получением объекта и его записью.
Чтобы избежать подобных ошибок, придерживайтесь следующих правил:
ПолучитьОбъект() и Записать(). Все сложные расчеты (например, получение параметров тех. операций) лучше выполнять до того, как вы получили объект документа для редактирования.ДополнительныеСвойства). Иногда в них нужно передать специальные флаги (например, "ОтказОтОбновленияПланов"), чтобы типовые механизмы не пытались перезаписывать документ во время вашей обработки.Таким образом, ошибка несоответствия версий — это не сбой платформы, а защитный механизм. В случае с Заказом на производство наиболее вероятной причиной является автоматическое срабатывание логики пересчета дат, которая конфликтует с прямой программной модификацией реквизитов ДатаИсполнения и ДатаОбеспеченияПотребностей.