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