В практике работы с 1С:Зарплата и управление персоналом 3.1 иногда возникают критические ситуации, когда данные в справочниках меняются «сами собой». Одной из таких проблем является внезапная установка даты рождения у части сотрудников на значение 01.01.2020. Рассмотрим подробнее, почему это происходит, как найти виновного и какими способами можно восстановить корректные данные.
Первое, что нам необходимо проверить — не запускал ли кто-то из пользователей обработку Групповое изменение реквизитов. Это мощный инструмент, который при неправильной настройке отборов может привести к катастрофическим последствиям. Разберем по шагам, как это могло произойти.
Пользователь (часто из HR-отдела) мог пытаться изменить какой-то другой реквизит, например, дату приема или подразделение, но случайно установил галочку напротив поля Дата рождения в справочнике Физические лица. Если при этом не был установлен жесткий отбор по конкретным сотрудникам, система применит изменения ко всем записям, до которых сможет «дотянуться» в рамках прав пользователя.
Выясним причину выбора именно даты 01.01.2020. Эта дата является знаковой для 1С:ЗУП, так как именно с этого момента начался массовый переход на электронные трудовые книжки (ЭТК). Она часто фигурирует в алгоритмах заполнения сведений о трудовой деятельности и может подставляться некоторыми внешними обработками как «технический дефолт», если поле в исходном файле было пустым.
Проанализируем ситуацию через основной инструмент администратора 1С — Журнал регистрации. Нам нужно понять, кто и когда внес изменения. Посмотрим на алгоритм поиска:
Данные.Изменение.Справочник.ФизЛица (или Физические лица).Как отмечают эксперты, в журнале регистрации записи будут выглядеть обобщенно. Мы увидим событие «Изменение», объект «Физическое лицо» и имя пользователя. Если мы видим, что в течение одной-двух минут один и тот же пользователь изменил десятки или сотни карточек физлиц, значит, имело место использование групповой обработки или выполнение фонового задания под этим пользователем.
Если в вашей базе включена опция Хранить историю изменений, то задача упрощается в разы. Проверим, ведется ли версионирование для справочника Физические лица. Для этого перейдем в Администрирование — Общие настройки — История изменений.
Если версионирование активно, мы можем:
История изменений (обычно находится в меню «Еще»).Дата рождения, старое значение (например, 15.05.1985), новое значение (01.01.2020), автор изменения и точное время.Преимущество этого метода перед журналом регистрации в том, что он показывает именно измененные значения, а не просто факт записи объекта.
Рассмотрим ситуацию, когда в журнале регистрации изменения проходят под системным пользователем (например, ExchangeUser). Это сигнализирует о том, что данные «прилетели» извне. Проанализируем возможные каналы:
1. Синхронизация с 1С:Бухгалтерией или 1С:ERP. Если настроен двусторонний обмен, и в бухгалтерской базе кто-то некорректно заполнил данные или выполнил загрузку из сторонней программы, то при синхронизации справочник Физические лица в ЗУП может быть перезаписан. В 1С:ЗУП справочник физлиц является ведущим для расчетов, но механизмы синхронизации могут иметь приоритет на стороне «Бухгалтерии», если это настроено в правилах обмена.
2. Обмен с СФР через СЭДО. При получении входящих сообщений от фонда (например, входящие запросы для расчета пособий) программа пытается сопоставить данные фонда с данными в базе. В редких случаях из-за технических ошибок в релизах или некорректных данных в файлах фонда, пустые значения дат могут интерпретироваться как начало текущего отчетного цикла или системные заглушки, что приводит к обновлению локальных данных.
Если база клиент-серверная, нельзя исключать прямое вмешательство на уровне СУБД. Если администратор выполнял SQL-запросы к таблице _ReferenceXX (где XX — внутренний номер справочника физлиц), такие изменения не будут зафиксированы в журнале регистрации 1С. Это крайне маловероятно для рядовой ошибки, но стоит иметь в виду, если в 1С нет никаких следов активности.
Также разберем влияние расширений конфигурации. Проанализируем список установленных расширений в разделе Администрирование — Печатные формы, отчеты и обработки — Расширения. Если в расширении есть код, перехватывающий событие ПередЗаписью или ПриЗаписи справочника Физические лица, ошибка в логике этого кода может приводить к затиранию реквизитов.
Рассмотрим три основных способа восстановления, если проблема уже случилась:
Физические лица (используя обработку Выгрузка загрузка данных XML) и загрузить в рабочую базу. При загрузке важно сопоставлять объекты по GUID (Уникальному идентификатору), чтобы не создать дублей.Перейти на версию. Однако для массового восстановления это придется делать программно, перебирая историю через код.
// Пример программного исправления даты рождения
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ФизическиеЛица.Ссылка КАК Ссылка
|ИЗ
| Справочник.ФизическиеЛица КАК ФизическиеЛица
|ГДЕ
| ФизическиеЛица.ДатаРождения = &ТехническаяДата";
Запрос.УстановитьПараметр("ТехническаяДата", '20200101');
РезультатЗапроса = Запрос.Выполнить();
Выборка = РезультатЗапроса.Выбрать();
Пока Выборка.Следующий() Цикл
ОбъектФизЛицо = Выборка.Ссылка.ПолучитьОбъект();
// Здесь должна быть логика получения правильной даты, например из бэкапа или файла
// ОбъектФизЛицо.ДатаРождения = НужнаяДата;
// ОбъектФизЛицо.Записать();
КонецЦикла;
Чтобы ситуация не повторилась, проанализируем настройки прав доступа. Для сотрудников HR-отдела рекомендуется ограничить возможность использования групповых изменений. В идеале, стоит настроить RLS (Record Level Security) или создать профиль групп доступа, где право на интерактивное удаление и массовое изменение реквизитов будет отключено.
Также важно донести до пользователей, что справочники Сотрудники и Физические лица в ЗУП 3.1 — это разные объекты. Дата рождения хранится именно в Физических лицах. При поиске и удалении дублей встроенной обработкой нужно быть внимательным, чтобы «правильным» не оказался дубль с ошибочной датой 01.01.2020.