В практике работы с конфигурацией 1С:Зарплата и управление персоналом, редакция 3.1 (особенно в релизе 3.1.15.139) бухгалтеры и системные администраторы могут столкнуться с аномальным поведением системы. Проблема заключается в следующем: при попытке сформировать выплату непосредственно из документа Начисление зарплаты и взносов с помощью кнопки Выплатить, итоговая сумма в созданной ведомости оказывается завышенной ровно в 10 раз. При этом, если создавать документ Ведомость в банк или Ведомость в кассу вручную через раздел «Выплаты», суммы подтягиваются корректно.
В этой статье мы подробно разберем, почему возникает такая ситуация, какие механизмы программы задействованы в этом процессе, и как поэтапно диагностировать и устранить данную ошибку.
Для начала проанализируем, в чем заключается принципиальная разница между ручным созданием ведомости и использованием кнопки «Выплатить» внутри документа начисления. Рассмотрим эти процессы подробнее:
ЗарплатаКВыплате. Она анализирует остатки по сотрудникам, учитывая разрезы подразделений, периодов и статей финансирования. Поскольку в регистре уже зафиксированы корректные движения после проведения документа начисления, ведомость заполняется правильно.Разберем, почему сумма увеличивается именно в 10 раз. Как показывают исследования подобных багов, это часто связано с ошибкой обработки разделителей дробной части в платформе 8.3 при передаче параметров между серверным и клиентским вызовами. Если программный код ожидает число с плавающей точкой, но получает его в формате, который интерпретируется некорректно, происходит смещение десятичного разряда.
Прежде чем приступать к исправлению кода, нам необходимо убедиться, что данные в регистрах накопления не повреждены. Проанализируем ситуацию с помощью инструмента «Универсальный отчет».
Выполним следующие действия:
Регистр накопления.Зарплата к выплате.Сотруднику и Документу-основанию.Если в универсальном отчете мы видим правильные суммы, значит, проблема локализована именно в программной обработке формы документа Начисление зарплаты и взносов. Если же в регистре суммы уже завышены, причину нужно искать в алгоритмах расчета самого документа начисления или в корректировках прошлых периодов.
Проанализируем еще один важный регистр — Бухгалтерские взаиморасчеты с сотрудниками. Именно из него механизм кнопки «Выплатить» зачастую черпает аналитику по статьям финансирования. Посмотрим на ситуацию под другим углом: если по сотруднику (особенно по договорнику ГПХ) существуют незакрытые остатки за прошлые годы с противоположными знаками, система может попытаться «схлопнуть» их при автоматическом формировании, что приводит к непредсказуемым математическим результатам.
Проверим отсутствие дублирующих записей в регистре КадроваяИсторияСотрудниковИнтервальный. Хотя для договорников ГПХ записей там может не быть, для штатных сотрудников ошибки в интервальных регистрах часто становятся причиной некорректного распределения сумм по подразделениям.
Иногда корень проблемы кроется не в коде конфигурации, а в окружении платформы. Выясним причину возможного сдвига разряда. Рассмотрим влияние региональных настроек ОС:
Если на сервере 1С или на рабочем месте пользователя в качестве разделителя дробной части установлена точка вместо запятой (или наоборот), а код 1С в конкретном релизе не учитывает это при парсинге строк, число 100,00 может превратиться в 1000. Это объясняет, почему сумма возрастает именно в 10 раз.
Рекомендуется выполнить очистку кэша:
%AppData%\1C\1Cv8\.Если вы имеете доступ к конфигуратору, стоит изучить общий модуль, отвечающий за логику заполнения ведомостей. В релизах линейки 3.1.15 это чаще всего модуль СозданиеНаОснованииЗарплатаКадры или ВыплатыЗарплатыПереопределяемый.
Найдем процедуру, которая вызывается при нажатии кнопки «Выплатить». Рассмотрим примерный фрагмент кода, где может скрываться ошибка:
// Пример упрощенного алгоритма подбора сумм
Процедура ЗаполнитьВедомостьПоОснованию(ПараметрыВыплаты) Экспорт
ДанныеНачисления = ПолучитьДанныеИзДокумента(ПараметрыВыплаты.ДокументОснование);
// Ошибка может быть в цикле обработки строк
Для Каждого Строка Из ДанныеНачисления Цикл
// Если здесь происходит повторное суммирование или неверное приведение типов
СуммаКВыплате = СуммаКВыплате + Строка.Результат;
КонецЦикла;
КонецПроцедуры
Проанализируем ситуацию: в проблемных релизах ошибка возникала из-за того, что система дважды или трижды обходила одни и те же временные таблицы, суммируя данные по разным разрезам (например, по НДФЛ и по сумме на руки), не очищая предыдущие значения в переменных. Чтобы исправить это в коде, необходимо убедиться, что выборка из временных таблиц строго ограничена уникальным идентификатором текущего сеанса расчета.
Поскольку внесение изменений в типовую конфигурацию может снять базу с поддержки, рассмотрим наиболее эффективные «народные» способы решения:
Заполнить внутри новой ведомости ошибка в 10-кратном размере не проявляется, так как используется другой программный путь (Query по регистрам накопления).Зарплата к выплате и может помочь алгоритму кнопки «Выплатить» отработать корректно.Мы выяснили, что десятикратное завышение суммы — это следствие программного сбоя в алгоритме формирования ведомости «на лету» из формы начисления. Это не связано с неправильным расчетом зарплаты как таковой, а является ошибкой интерфейсного механизма заполнения.
Краткий план действий при обнаружении проблемы:
Зарплата к выплате с помощью Универсального отчета.Используя данный подход, вы сможете оперативно решить проблему выплаты и избежать финансовых потерь организации из-за технических ошибок программного обеспечения.