При переходе на новые релизы конфигурации «1С:Зарплата и управление персоналом 3.1» (особенно при обновлении устаревших веток, таких как 3.1.4 или 3.1.5, на более актуальные версии) многие специалисты сталкиваются с критической ошибкой, которая полностью блокирует процесс обновления базы данных. Система выдает сообщение об ошибке в общем модуле УчетСтажаПФР.Модуль на строке выполнения метода Набор.Записать() с пояснением: «Запись с такими ключевыми полями существует! : ПараметрыПериодовСтажаПФР».
В этой статье мы подробно разберем, почему возникает этот конфликт в базе данных, проанализируем внутреннее устройство регистров СФР (ранее ПФР) и рассмотрим пошаговые практические методы устранения проблемы как вручную, так и программными средствами.
Для того чтобы понять природу сбоя, обратимся к структуре регистра сведений ПараметрыПериодовСтажаПФР (в современных версиях программы он называется ПараметрыПериодовСтажаСФР). Этот регистр предназначен для хранения сведений о периодах стажа сотрудников, которые впоследствии используются для корректного заполнения отчетности по персонифицированному учету.
Ключевая особенность структуры этого регистра заключается в следующем:
ГоловнаяОрганизация, ФизическоеЛицо и ДатаНачала (или ДатаНачалаСобытия).Сотрудник вынесено разработчиками 1С в состав ресурсов, а не измерений. Это логично с точки зрения учета ПФР, поскольку для контролирующих органов важен стаж конкретного физического лица (застрахованного лица), а не его внутренние трудовые договоры в рамках одной организации.ПростойСотрудников, ОтпускБезСохраненияОплаты или технический документ ПереносДанных), в котором одновременно фигурируют две строки по одному и тому же человеку — как по основному сотруднику, так и по его внутреннему совместителю.При попытке провести такой документ или обработать его в процессе обновления (когда запускаются фоновые процедуры обновления информационной базы), система пытается записать в регистр две записи в рамках одного регистратора:
Для СУБД (будь то файловая база, MS SQL Server или PostgreSQL) уникальный ключ записи формируется по связке Регистратор + Измерения. Поскольку и регистратор, и физическое лицо, и дата начала у этих двух записей абсолютно идентичны, платформа 1С пытается записать дублирующие ключи, что вызывает закономерный отказ базы данных на уровне СУБД.
---
Прежде чем приступать к исправлению данных, нам необходимо точно определить, какие именно документы или записи вызывают сбой. Если база данных работает в режиме отладки, мы можем увидеть конкретный документ в стеке вызовов. Однако на больших базах данных гораздо эффективнее использовать специальный запрос.
Рассмотрим пример программного поиска записей-дублей. Откроем консоль запросов или создадим внешнюю обработку и выполним следующий запрос к базе данных:
ВЫБРАТЬ
ПараметрыСтажа.Регистратор КАК ДокументРегистратор,
ПараметрыСтажа.ФизическоеЛицо КАК ФизическоеЛицо,
ПараметрыСтажа.ДатаНачала КАК ДатаНачала,
КОЛИЧЕСТВО(РАЗЛИЧНЫЕ ПараметрыСтажа.Сотрудник) КАК КоличествоСотрудников
ИЗ
РегистрСведений.ПараметрыПериодовСтажаПФР КАК ПараметрыСтажа
СГРУППИРОВАТЬ ПО
ПараметрыСтажа.Регистратор,
ПараметрыСтажа.ФизическоеЛицо,
ПараметрыСтажа.ДатаНачала
ИМЕЮЩИЕ
КОЛИЧЕСТВО(РАЗЛИЧНЫЕ ПараметрыСтажа.Сотрудник) > 1
Этот запрос выведет список всех регистраторов и физических лиц, по которым в регистре образовалось более одного сотрудника на одну дату начала события. Именно эти документы блокируют обновление конфигурации.
---
В зависимости от периода возникновения ошибки (текущий открытый период или давно закрытый исторический год) выберем наиболее подходящий метод решения.
Если запрос указал на стандартный расчетный документ (например, ПростойСотрудников, Отпуск, БольничныйЛист):
Благодаря этому действию у каждой записи в регистре стажа появится свой уникальный Регистратор (первый документ для основной позиции, второй — для совместительства). Уникальность ключа восстановится, и ошибка при обновлении исчезнет.
Очень часто дублирующиеся записи «мигрируют» из старых баз данных (например, при переносе данных из конфигурации «Зарплата и управление персоналом 2.5» в редакцию 3.1). В этом случае они хранятся в технических документах типа Перенос данных (с кодами таблиц НЗП, ТРАНШ и другими).
Перепроводить такие документы за прошлые годы крайне опасно, так как это может повлечь за собой нежелательные перерасчеты и искажение исторической отчетности. Действуем следующим образом:
Перенос данных, определенный с помощью нашего запроса.Параметры периодов стажа ПФР.Если документов с ошибками слишком много, а сроки сдачи отчетности поджимают, применим метод очистки регистра на время обновления:
ПараметрыПериодовСтажаПФР по проблемным периодам во внешний файл.Предприятие. Все процедуры обновления метаданных пройдут успешно и без ошибок.---
Рассмотрев причины возникновения этой ошибки, отметим, что фирма «1С» в последующих минорных релизах ЗУП (начиная с ветки 3.1.6 и выше) скорректировала алгоритмы обновления. В код процедур обновления были добавлены обработчики, которые автоматически группируют (сворачивают) записи по физическим лицам перед непосредственной попыткой записи набора в базу данных.
Для предотвращения подобных ситуаций в будущем рекомендуется своевременно устанавливать официальные патчи (исправления) от вендора и не задерживать переход на стабильные и поддерживаемые релизы конфигурации.