При работе с устаревающими, но все еще актуальными конфигурациями, такими как 1С:Зарплата и Управление Персоналом 2.5 (особенно редакциями КОРП), специалисты иногда сталкиваются с аномальным поведением системы после обновления или технических работ на сервере. Одной из наиболее пугающих проблем является внезапное завышение сумм районного коэффициента (РК). Система начинает игнорировать установленный период расчета и «подтягивает» в базу начисления за все годы ведения учета в программе. Давайте подробно разберем, почему это происходит и как вернуть расчеты в нормальное русло.
Ситуация обычно выглядит следующим образом: пользователь обновляет конфигурацию до одного из финальных релизов (например, 2.5.130.2) или переносит базу данных на новый SQL-сервер. При первой же попытке рассчитать документ «Начисление зарплаты сотрудникам организаций» расчетчик обнаруживает, что сумма районного коэффициента исчисляется сотнями тысяч или миллионами рублей. Проанализируем ситуацию: если мы заглянем в расчетный листок или расшифровку расчета, то увидим, что программа в качестве базы для РК взяла не текущий месяц, а накопленный итог по всем базовым начислениям сотрудника за весь период его работы в базе.
Важно понимать, что это не программная ошибка в коде самого релиза, так как на чистых копиях или других базах данных тот же релиз ведет себя корректно. Мы имеем дело с техническим сбоем механизма виртуальных таблиц регистров расчета.
Чтобы понять причину сбоя, рассмотрим, как система получает данные для расчета районного коэффициента. В типовом механизме ЗУП 2.5 используется программный интерфейс и запросы к виртуальным таблицам. Основная логика сосредоточена в функции ПолучитьДанныеДляРасчета. Проанализируем фрагмент запроса, который система выполняет «под капотом»:
ВЫБРАТЬ
СУММА(База.РезультатБаза) КАК РезультатБаза,
База.ВидРасчетаРазрез КАК ВидРасчетаРазрез,
База.Регистратор КАК Регистратор,
База.НомерСтроки КАК НомерСтроки
ПОМЕСТИТЬ ВТБаза
ИЗ
(ВЫБРАТЬ
База1.РезультатБаза КАК РезультатБаза,
База1.ВидРасчетаРазрез КАК ВидРасчетаРазрез,
База1.Регистратор КАК Регистратор,
База1.НомерСтроки КАК НомерСтроки
ИЗ
РегистрРасчета.ОсновныеНачисленияРаботниковОрганизаций.БазаОсновныеНачисленияРаботниковОрганизаций(
&парамИзмеренияОсновного,
&парамИзмеренияБазового,
&парамРазрезы,
ВидРасчета.КатегорияРасчета = &парамКатегорияНачисления
И Регистратор = &парамРегистратор
И Авторасчет) КАК База1
ГДЕ
(НЕ База1.Сторно ИЛИ База1.ПериодРегистрацииРазрез < База1.ПериодРегистрации)) КАК База
СГРУППИРОВАТЬ ПО
База.ВидРасчетаРазрез,
База.Регистратор,
База.НомерСтроки
В нормальных условиях виртуальная таблица БазаОсновныеНачисленияРаботниковОрганизаций должна ограничивать выборку периодом регистрации текущего документа. Однако, если нарушена целостность базы данных или индексов, параметры фильтрации внутри виртуальной таблицы перестают отрабатывать корректно. Система «забывает» о границах периода и выдает все записи из физической таблицы _CalculationReg, соответствующие измерениям (сотруднику и организации). Выясним причину такого поведения: чаще всего это происходит из-за «разъехавшихся» итогов или поврежденных индексов на уровне СУБД (MS SQL или PostgreSQL).
Это самый эффективный и рекомендуемый способ устранения данной проблемы. Поскольку корень зла лежит в нарушении структуры индексов и таблиц итогов, нам необходимо принудительно заставить платформу 1С пересчитать эти данные. Рассмотрим по шагам, как правильно выполнить процедуру:
После завершения процесса ТИИ система восстановит правильные связи в таблицах итогов. Посмотрим на результат: в большинстве случаев после выполнения этих действий расчет районного коэффициента возвращается к нормальным показателям, так как виртуальная таблица снова начинает видеть границы периода.
Если ТИИ в режиме клиент-сервера не помогло (что бывает редко, но случается при специфических сбоях самого SQL-сервера), применим метод «тотальной перезаписи». Выгрузим информационную базу в файл .dt и загрузим ее обратно. Разберем, почему это работает: при выгрузке в .dt 1С собирает только логически значимые данные, отбрасывая физические индексы. При обратной загрузке платформа создает таблицы и индексы с нуля. Это гарантирует очистку от любого «мусора» на уровне физических таблиц СУБД.
Также стоит попробовать загрузить базу в файловый вариант и запустить расчет там. Если в файловой версии расчет идет верно, значит, проблема однозначно в кэше или индексах конкретного инстанса SQL-сервера.
Хотя проблема чаще носит технический характер, не лишним будет проверить настройки самого начисления «Районный коэффициент». Проанализируем вкладку «Прочее» в настройках этого вида расчета в плане видов расчета Основные начисления организаций:
Чтобы подобные ситуации не повторялись, особенно после переноса базы между серверами, проанализируем регламентные операции на уровне SQL. Рекомендуется регулярно выполнять обновление статистик (Update Statistics) и дефрагментацию индексов средствами СУБД. Регистры расчета — это одни из самых тяжелых таблиц в 1С, и их некорректная работа часто является первым сигналом о том, что база данных нуждается в техническом обслуживании.
В заключение отметим: если вы используете ЗУП 2.5 в «каменном веке» (как выразились участники обсуждения), будьте готовы к тому, что новые платформы 8.3 могут иногда некорректно интерпретировать старые механизмы запросов в режиме совместимости. Своевременное проведение ТИИ и обновление платформы до актуальных стабильных релизов — залог спокойствия бухгалтерии в отчетный период.