После обновления конфигурации 1С:Бухгалтерия предприятия 3.0 до релиза 3.0.147.18 многие пользователи столкнулись с критической проблемой: документы Прием на работу и Кадровый перевод перестали проводиться. Система выдает характерную ошибку, связанную с механизмом проверки дат запрета изменения данных. В этой статье мы подробно разберем причины возникновения этой ситуации и рассмотрим все доступные способы её решения.
Давайте выясним, почему возникает эта ошибка. При попытке проведения документа программа выдает следующее сообщение:
«Для таблицы "РегистрСведений.ПлановыеАвансы" в процедуре ЗаполнитьИсточникиДанныхДляПроверкиЗапретаИзменения общего модуля ДатыЗапретаИзмененияПереопределяемый не указаны источники данных...»
Проанализируем ситуацию: начиная с релиза 3.0.147.18, в программе были значительно переработаны блоки зарплаты и воинского учета. В частности, кадровые документы теперь активно записывают данные в регистр сведений ПлановыеАвансы. Однако разработчики допустили программную недоработку — этот регистр не был включен в список объектов, которые система умеет проверять на соответствие «Дате запрета изменения». Это изменение также заставило многих задуматься о дополнительных мерах безопасности, таких как запрет на просмотр блока зарплаты для пользователей без соответствующих полномочий.
В результате, если в вашей информационной базе установлена любая дата запрета редактирования (даже в далеком прошлом), механизм Библиотеки Стандартных Подсистем (БСП) блокирует запись в этот регистр, так как не знает, по каким правилам его проверять. Это классическая логическая ошибка в коде типового решения.
Рассмотрим самый простой и правильный путь решения проблемы для типовых конфигураций. Фирма «1С» оперативно выпустила исправление в виде патча. Если у вас включена автоматическая загрузка исправлений, патч должен установиться сам. Если нет — выполним это вручную.
Пошаговая инструкция по установке патча:
EF_30180123.После установки патча перезагружать сервер 1С обычно не требуется, достаточно перезапустить сеанс пользователя. Проблема должна исчезнуть мгновенно.
Если ваша конфигурация находится на поддержке с возможностью изменения (кастомизирована) и вы предпочитаете внести правки самостоятельно, либо патч по каким-то причинам не устанавливается, разберем технический способ решения. Нам необходимо вручную зарегистрировать источник данных для проверки дат запрета.
Найдем в дереве метаданных общий модуль ДатыЗапретаИзмененияПереопределяемый и перейдем к процедуре ЗаполнитьИсточникиДанныхДляПроверкиЗапретаИзменения. В конец этой процедуры необходимо добавить описание для регистра плановых авансов.
Рассмотрим пример кода, который решает проблему:
Процедура ЗаполнитьИсточникиДанныхДляПроверкиЗапретаИзменения(ИсточникиДанных) Экспорт
// ... существующий код модуля ...
// Добавляем регистрацию регистра ПлановыеАвансы
ОписаниеИсточника = ДатыЗапретаИзменения.ОписаниеИсточника(ИсточникиДанных, "РегистрСведений.ПлановыеАвансы");
ОписаниеИсточника.ПолеДаты = "Период";
ОписаниеИсточника.ПолеОбъекта = "Организация"; // Или "ГоловнаяОрганизация", если используется КОРП версия
ОписаниеИсточника.Раздел = "Зарплата";
КонецПроцедуры
В некоторых случаях можно использовать более упрощенный синтаксис добавления строки, как советуют опытные разработчики на форумах:
ДатыЗапретаИзменения.ДобавитьСтроку(ИсточникиДанных, "РегистрСведений.ПлановыеАвансы", "Период", "Зарплата", "Организация");
После внесения этих изменений и сохранения конфигурации проверка дат запрета начнет работать корректно, и документы Прием на работу будут проводиться без ошибок.
Проанализируем состояние релизов. Ошибка была официально исправлена разработчиками в последующих версиях программы. Если вы используете 3.0.147.18, мы рекомендуем обновить конфигурацию до версии 3.0.147.25 или выше (например, переход на ветку 3.0.148 или 3.0.149).
Важно: При обновлении программным способом все временные патчи будут удалены автоматически, а исправленный код уже будет содержаться в основной конфигурации поставщика.
Если проблему нужно решить «здесь и сейчас», а правка кода или установка патчей невозможна (например, нет прав доступа), разберем административный способ.
Выясним опытным путем: ошибка проявляется только при включенной дате запрета изменения. Следовательно, для проведения срочного документа можно выполнить следующие действия:
Внимание: Помните, что этот метод является «костылем». Работа с отключенной датой запрета в многопользовательской базе опасна тем, что коллеги могут случайно изменить данные прошлых периодов, что приведет к расхождениям в учете. Для усиления контроля можно внедрить дополнительный запрет изменения проведенных документов или даже настроить запрет изменения самой даты запрета для определенных пользователей.
Мы выяснили, что ошибка проведения в БП 3.0.147.18 носит чисто технический характер и не связана с повреждением базы данных. Проведение ТИИ (Тестирование и исправление) или использование утилиты chdbfl.exe в данном случае бесполезно. Оптимальным решением является установка патча EF_30180123 или обновление программы до актуального релиза.