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