При переносе данных между базами 1С:Зарплата и управление персоналом (ЗУП) с помощью универсальной обработки «Выгрузка и загрузка данных XML» часто возникает специфическая проблема. Документы физически присутствуют в базе, администратор их видит, но рядовые пользователи (кадровики, расчетчики) обнаруживают пустые журналы или отсутствие конкретных документов, таких как ПриемНаРаботу или Отпуска. При этом через поиск или «Все функции» документы могут быть доступны.
В этой статье мы подробно проанализируем, почему так происходит, разберем механизмы ограничения доступа на уровне записей (RLS) и выясним, как правильно переносить данные, чтобы не нарушить работу системы прав доступа.
В современных версиях ЗУП 3.1 на базе Библиотеки стандартных подсистем (БСП) реализован так называемый производительный RLS. Рассмотрим подробнее, как он работает. В старых версиях системы 1С условия ограничения доступа (например, «Где Организация = &ДоступныеОрганизации») добавлялись платформой непосредственно в каждый SQL-запрос. Это замедляло работу системы при больших объемах данных.
Теперь механизм работает иначе: при записи любого объекта (документа или справочника) система заранее рассчитывает права доступа и записывает их в специальные служебные таблицы — Ключи доступа. Когда пользователь открывает список документов, система делает быстрое соединение с этими таблицами.
Проанализируем ситуацию загрузки данных через XML. Если вы выгружаете только документы, но игнорируете служебные регистры или переносите их некорректно, связи между документами и их ключами доступа обрываются. В результате:
КлючиДоступаКОбъектам запись для него отсутствует или ссылается на идентификаторы из старой базы.Выясним причину, по которой документы могут быть видны в списках самих документов, но отсутствовать в общих журналах (например, в «Журнале кадровых документов»). В 1С:ЗУП работа журналов тесно завязана на Функциональные опции (ФО). Многие из них хранятся не только в константах, но и в регистрах сведений.
Рассмотрим пример: если в базе-источнике велся учет по штатному расписанию, а в базе-приемнике соответствующий регистр сведений или константа не настроены (или затерты при загрузке), интерфейс может просто скрывать колонки или целые типы документов, считая, что данная подсистема не используется. Это объясняет, почему через «Все функции», где отображается «сырой» список без фильтров ФО, данные видны.
Посмотрим на типичную ошибку: попытка перенести «все документы и все регистры». Это приводит к конфликтам идентификаторов (GUID) и затиранию системных настроек базы-приемника. Проанализируем правильный подход к выбору регистров сведений для выгрузки:
КлючиДоступаКОбъектам, ТаблицыГруппДоступа или ОбновлениеКлючейДоступа содержат данные, специфичные для конкретной информационной базы. Их перенос «в лоб» из другой базы гарантированно сломает права доступа.Если вы уже загрузили данные и столкнулись с проблемой «невидимости», разберем, что нужно сделать для восстановления корректной работы.
Шаг 1. Пересчет ключей доступа
Вместо того чтобы пытаться вручную переносить служебные регистры, заставим систему пересчитать их заново. Для этого в типовых конфигурациях предусмотрены штатные процедуры. Можно воспользоваться консолью кода и запустить обновление программно:
ПараметрыОбновления = УправлениеДоступомСлужебный.ПараметрыОбновленияДоступа();
ПараметрыОбновления.ОбновитьДанныеЗаполненияГруппДоступа = Истина;
УправлениеДоступомСлужебный.ОбновитьДоступ(ПараметрыОбновления);
Также полезно проверить состояние очереди обновления в регистре сведений ОчередьОбновленияКлючейДоступа. Если он заполнен, значит, система еще обрабатывает ваши новые данные.
Шаг 2. Проверка функциональных опций
Проанализируем регистр ИспользованиеФункциональныхОпцийЗарплатаКадры. Если после загрузки данных он оказался пустым или некорректным, многие документы «исчезнут» из интерфейса. Убедитесь, что настройки кадрового учета и расчета зарплаты в новой базе идентичны исходной. Проверьте константы, отвечающие за ведение штатного расписания, использование отпусков и т.д.
Шаг 3. Обработка дублей в служебных справочниках
При загрузке через XML часто возникают дубли в справочниках ФизическиеЛица, Сотрудники, а также в служебных справочниках типа ГруппыДоступа. Рассмотрим алгоритм действий:
Чтобы избежать подобных проблем, рекомендуем придерживаться следующей стратегии при использовании обработки «Выгрузка и загрузка данных XML»:
1. Выгружайте только те РегистрыСведений, которые не имеют регистратора и содержат значимую бизнес-информацию (ФИО, паспортные данные, сведения об образовании).
2. Исключайте из выгрузки регистры, названия которых начинаются с:
КлючиДоступа...ОбновлениеДоступа...ПраваПользователей...ДанныеОбъектовДляРегистрацииВОчереди...3. При загрузке в базу-приемник всегда проверяйте регистр Параметры работы программы. Если загрузка затерла в нем признак завершения обновления информационной базы, система может работать в «ограниченном» режиме, скрывая часть данных от пользователей до выполнения всех процедур обновления.
Проанализировав ситуацию, мы видим, что «исчезновение» документов — это не ошибка базы данных, а защитный механизм RLS, который скрывает объекты, для которых не созданы актуальные записи в таблицах прав. Следуя приведенным инструкциям по обновлению ключей доступа и проверке функциональных опций, вы сможете восстановить полную видимость данных для всех пользователей.