Почему после обновления 1С:Бухгалтерия 3.0 перестали проводиться кадровые документы и как это исправить?

Программист 1С v8.3 (Управляемые формы) 1C:Бухгалтерия Бухгалтерский учет
← На главную

После обновления конфигурации 1С:Бухгалтерия предприятия 3.0 до релиза 3.0.147.18 многие пользователи столкнулись с критической проблемой: документы Прием на работу и Кадровый перевод перестали проводиться. Система выдает характерную ошибку, связанную с механизмом проверки дат запрета изменения данных. В этой статье мы подробно разберем причины возникновения этой ситуации и рассмотрим все доступные способы её решения.

Анализируем причину ошибки

Давайте выясним, почему возникает эта ошибка. При попытке проведения документа программа выдает следующее сообщение:

«Для таблицы "РегистрСведений.ПлановыеАвансы" в процедуре ЗаполнитьИсточникиДанныхДляПроверкиЗапретаИзменения общего модуля ДатыЗапретаИзмененияПереопределяемый не указаны источники данных...»

Проанализируем ситуацию: начиная с релиза 3.0.147.18, в программе были значительно переработаны блоки зарплаты и воинского учета. В частности, кадровые документы теперь активно записывают данные в регистр сведений ПлановыеАвансы. Однако разработчики допустили программную недоработку — этот регистр не был включен в список объектов, которые система умеет проверять на соответствие «Дате запрета изменения». Это изменение также заставило многих задуматься о дополнительных мерах безопасности, таких как запрет на просмотр блока зарплаты для пользователей без соответствующих полномочий.

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

Вариант 1. Установка официального патча (рекомендуется)

Рассмотрим самый простой и правильный путь решения проблемы для типовых конфигураций. Фирма «1С» оперативно выпустила исправление в виде патча. Если у вас включена автоматическая загрузка исправлений, патч должен установиться сам. Если нет — выполним это вручную.

Пошаговая инструкция по установке патча:

  1. Перейдем в раздел АдминистрированиеОбслуживание.
  2. Развернем блок Обновление программы и выберем пункт Установленные исправления (патчи).
  3. Проверим наличие патча с номером EF_30180123.
  4. Если его нет, нажмем Установить исправление и найдем его в списке доступных (требуется подключение к интернет-поддержке) или загрузим файл патча, скачанный с портала техподдержки.

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

Вариант 2. Программное исправление в конфигураторе

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

Найдем в дереве метаданных общий модуль ДатыЗапретаИзмененияПереопределяемый и перейдем к процедуре ЗаполнитьИсточникиДанныхДляПроверкиЗапретаИзменения. В конец этой процедуры необходимо добавить описание для регистра плановых авансов.

Рассмотрим пример кода, который решает проблему:


Процедура ЗаполнитьИсточникиДанныхДляПроверкиЗапретаИзменения(ИсточникиДанных) Экспорт

    // ... существующий код модуля ...

    // Добавляем регистрацию регистра ПлановыеАвансы
    ОписаниеИсточника = ДатыЗапретаИзменения.ОписаниеИсточника(ИсточникиДанных, "РегистрСведений.ПлановыеАвансы");
    ОписаниеИсточника.ПолеДаты = "Период";
    ОписаниеИсточника.ПолеОбъекта = "Организация"; // Или "ГоловнаяОрганизация", если используется КОРП версия
    ОписаниеИсточника.Раздел = "Зарплата";

КонецПроцедуры

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


ДатыЗапретаИзменения.ДобавитьСтроку(ИсточникиДанных, "РегистрСведений.ПлановыеАвансы", "Период", "Зарплата", "Организация");

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

Вариант 3. Обновление до актуального релиза

Проанализируем состояние релизов. Ошибка была официально исправлена разработчиками в последующих версиях программы. Если вы используете 3.0.147.18, мы рекомендуем обновить конфигурацию до версии 3.0.147.25 или выше (например, переход на ветку 3.0.148 или 3.0.149).

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

Вариант 4. Временный обходной путь (без программирования)

Если проблему нужно решить «здесь и сейчас», а правка кода или установка патчей невозможна (например, нет прав доступа), разберем административный способ.

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

  1. Зайдем в раздел АдминистрированиеНастройки пользователей и прав.
  2. Перейдем в пункт Даты запрета изменения.
  3. Снимем флажок Установлена дата запрета (или временно удалим настройку для конкретного пользователя, хотя стандартный механизм можно расширить, чтобы реализовать запрет изменения выборочно по пользователям в документах).
  4. Проведем все необходимые кадровые документы.
  5. Вернем настройки даты запрета в исходное состояние.

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

Резюме

Мы выяснили, что ошибка проведения в БП 3.0.147.18 носит чисто технический характер и не связана с повреждением базы данных. Проведение ТИИ (Тестирование и исправление) или использование утилиты chdbfl.exe в данном случае бесполезно. Оптимальным решением является установка патча EF_30180123 или обновление программы до актуального релиза.

← На главную