Приветствуем вас, коллеги! Сегодня мы детально разберем одну из самых «классических» и изнуряющих проблем устаревшей, но все еще встречающейся редакции 1С:Зарплата и управление персоналом 2.5. Речь пойдет о ситуации, когда сотрудник приносит постановление о снижении процента удержания по алиментам или иным обязательствам (например, с 30% до 15%), бухгалтер регистрирует в системе документ Изменение условий исполнительного листа, но при расчете заработной платы программа упорно продолжает удерживать прежний процент.
Давайте вместе проанализируем, почему возникает это поведение, заглянем «под капот» программных механизмов и рассмотрим по шагам все возможные варианты решения этой проблемы — от простых пользовательских обходов до программного исправления запросов.
Чтобы понять природу этой ошибки, нам необходимо разобраться в архитектуре хранения данных по исполнительным листам в ЗУП 2.5. Программа опирается на два ключевых регистра сведений:
Когда мы проводим документ Изменение условий исполнительного листа, система делает новые записи в оба этих регистра, устанавливая период действия новых условий (например, с 01.10.2018). На уровне записей регистров всё выглядит абсолютно корректно. Однако сбой происходит на этапе сбора данных для расчета в общем модуле ПроведениеРасчетов.
Внутри алгоритма расчета удержаний разработчиками собран сложный многоэтапный запрос с использованием объекта МенеджерВременныхТаблиц. Из-за архитектурной неточности в коде этого запроса соединение таблиц плановых удержаний и их условий происходит не по дате актуальности (срез последних), а жестко привязывается к дате первоначального документа-основания — самого первого документа Исполнительный лист. В результате расчетный механизм игнорирует более свежие записи в регистре условий и продолжает рассчитывать удержание по историческим данным.
Также важно помнить, что редакция 2.5 крайне чувствительна к датам:
Начисление зарплаты был создан или заполнен раньше, чем проведен документ изменения условий, кэшированные данные расчета не обновятся автоматически при простом пересчете.Перейдем к практическим методам решения этой проблемы.
Поскольку рассматриваемый релиз 2.5.114.1 является достаточно старым, самым правильным и надежным решением будет обновление программы. Разработчики фирмы 1С признали данную ошибку и исправили логику пакета запросов в последующих релизах.
Для устранения проблемы без вмешательства в код программы необходимо обновить базу до финальных релизов ветки 2.5:
После обновления алгоритмы расчета удержаний начнут корректно обрабатывать историю изменений параметров из регистра Условия удержания по исполнительному документу.
Если по каким-то причинам оперативно обновить конфигурацию невозможно (например, база сильно кастомизирована или находится на поддержке у сторонней организации), воспользуемся проверенным практикой методом «закрытия-открытия».
Рассмотрим пошагово, как правильно это сделать:
Исполнительный лист, по которому необходимо изменить условия.Исполнительный лист на этого же сотрудника.Этот способ гарантирует стопроцентный результат при расчете, так как программа будет видеть два последовательных, не пересекающихся во времени удержания, и запросу не придется обращаться к истории изменений внутри одного документа-основания.
Иногда новые условия не применяются банально из-за того, что расчет заработной платы за октябрь уже был частично произведен или сохранен в памяти программы. Для исключения влияния кэша выполните следующие действия:
Начисление зарплаты за расчетный месяц.Изменение условий исполнительного листа установлена корректно (желательно началом дня изменения, например, 01.10.2018 00:00:00). Перепроведите его.Начисление зарплаты, перейдите на вкладку «Прочие удержания».Для опытных пользователей существует вариант обхода логики документа через корректировку записей. Если вы не хотите плодить новые документы исполнительных листов, можно принудительно изменить записи в регистрах сведений:
Корректировка записей регистров.Плановые удержания и Условия удержания по исполнительному документу.Важно: Этот метод требует повышенного внимания, так как ручные корректировки могут усложнить последующую отчетность или аудит базы данных.
Если вы располагаете ресурсами разработчика и база находится на конфигурации с возможностью изменения, найдите в общем модуле расчета удержаний (обычно это ПроведениеРасчетов или специализированные модули расчета удержаний) пакет запросов, формирующих временные таблицы по исполнительным листам.
Проанализируем проблемный участок связи временных таблиц. В типовом ошибочном коде связь выглядит примерно так:
// Ошибочный вариант связи таблиц в запросе ЗУП 2.5
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.УсловияУдержанияПоИсполнительномуДокументу КАК УсловияУдержания
ПО ВтПлановыеУдержания.ДокументОснование = УсловияУдержания.ИсполнительныйДокумент
В данном случае связь идет без учета временного среза. Чтобы запрос выбирал актуальные условия на дату расчета, необходимо скорректировать связь, добавив условие по периоду действия записи:
// Корректный вариант связи с учетом актуальности периода действия условий
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.УсловияУдержанияПоИсполнительномуДокументу КАК УсловияУдержания
ПО ВтПлановыеУдержания.ДокументОснование = УсловияУдержания.ИсполнительныйДокумент
И УсловияУдержания.Период В
(ВЫБРАТЬ
МАКСИМУМ(УсловияМакс.Период)
ИЗ
РегистрСведений.УсловияУдержанияПоИсполнительномуДокументу КАК УсловияМакс
ГДЕ
УсловияМакс.ИсполнительныйДокумент = ВтПлановыеУдержания.ДокументОснование
И УсловияМакс.Период <= &КонецПериодаРасчета)
Такое изменение заставит систему всегда выбирать наиболее «свежую» запись из истории условий исполнительного листа, предшествующую дате окончания расчетного периода или равную ей. После внесения изменений в код обязательно перепроведите документы начисления и убедитесь, что расчет выполняется корректно.
Надеемся, эти подробные инструкции помогут вам успешно справиться с капризами расчета исполнительных листов в ЗУП 2.5!