← На главную

При работе с конфигурацией Зарплата и управление персоналом 3.1 (ЗУП) многие разработчики, привыкшие к архитектуре УПП или ЗУП 2.5, сталкиваются с трудностями при попытке найти прямой запрос, формирующий итоговую сумму «К выплате» в расчетном листке. В современных редакциях на управляемых формах отчет строится динамически, и данные собираются из множества источников.

В этой статье мы подробно разберем, где именно в программном коде скрыт алгоритм формирования данных для расчетного листка, какие регистры накопления задействованы в процессе и на какие настройки стоит обратить внимание, чтобы понять логику вычислений.

Основные регистры и их роль в формировании отчета

Прежде чем погружаться в чтение кода, проанализируем архитектуру хранения данных. В ЗУП 3.1 сумма в расчетном листке не является простым ресурсом одного регистра. Она вычисляется «на лету» на основании данных нескольких регистров накопления:

1. Начисления удержания по сотрудникам: этот регистр является основным источником данных о том, что было начислено сотруднику и что было удержано (включая исчисленный НДФЛ) в конкретном месяце.
2. Взаиморасчеты с сотрудниками: по этому регистру система отслеживает входящее и исходящее сальдо (долги организации перед сотрудником или наоборот). Именно остатки по этому регистру определяют итоговую сумму в нижней части листка.
3. Зарплата к выплате: вопреки названию, в расчетном листке данные этого регистра используются преимущественно для отображения сумм, которые уже включены в ведомости (подготовлены к выплате), но, возможно, еще не выплачены фактически (в зависимости от настроек отчета).

Где искать программный код формирования данных

Разберем по шагам, как добраться до текста запроса и алгоритмов обработки. Большинство механизмов формирования отчетов в ЗУП 3.1 вынесено в общие модули для обеспечения универсальности. Рассмотрим основные точки входа:

Для поиска механизмов заполнения расчетного листка нам необходимо обратиться к общему модулю ЗарплатаКадрыОтчеты. Внутри этого модуля следует найти специализированную область:

#Область РасчетныйЛисток

Именно здесь сосредоточены функции, которые подготавливают временные таблицы для системы компоновки данных (СКД). Важно понимать, что текст запроса в 1С:ЗУП 3.1 часто собирается динамически из различных фрагментов в зависимости от установленных пользователем настроек и параметров учета.

Проанализируем структуру работы отчета. В модуле менеджера отчета РасчетныйЛисток или в указанном выше общем модуле система инициализирует построение данных. Ищите создание временных таблиц с именами ВТДанныеДляПечати или ВТРасчеты. Система сначала собирает все обороты и остатки по регистрам во временные таблицы, а затем объединяет их сложным соединением.

Алгоритм и логическая формула расчета

Рассмотрим, по какой логике вычисляется итоговый показатель. В отличие от простых оборотных регистров, «К выплате» (конечное сальдо) в листке считается по следующей формуле:

Сальдо начальное + Начислено — Удержано — Выплачено = Сальдо конечное (К выплате)

Посмотрим подробнее на нюансы:

• Начислено: берется из регистра НачисленияУдержанияПоСотрудникам с видом движения «Приход».
• Удержано: включает в себя не только прочие удержания (алименты, профвзносы), но и исчисленный НДФЛ. Это часто путает разработчиков, так как в интерфейсе НДФЛ может стоять отдельным блоком, но математически он уменьшает сумму к получению.
• Выплачено: здесь логика зависит от настроек отчета. Если в настройках указано «Выводить выплаченную зарплату в периоде ее начисления», то запрос будет «подтягивать» ведомости, оформленные в следующем месяце, но относящиеся к текущему расчетному периоду.

Почему суммы в регистрах и в отчете могут не сходиться?

Выясним причину возможных расхождений, которые часто встречаются при отладке кода:

1. Влияние учетной политики. Проанализируем настройку «Выполнять расчет зарплаты без учета задолженности». Если она включена, логика формирования запроса в ЗарплатаКадрыОтчеты существенно меняется, и начальное сальдо может игнорироваться.

2. Корректировки выплаты. Если в документах ВедомостьНаВыплатуЗарплаты проводились ручные правки сумм без перезаполнения документа, данные в регистре ЗарплатаКВыплате могут разойтись с регистром ВзаиморасчетыССотрудниками. Расчетный листок в первую очередь ориентируется на состояние взаиморасчетов.

3. Разрез по статьям финансирования. В коде запроса часто присутствует группировка по аналитике (статьи финансирования, статьи расходов). Если у сотрудника возник перекос (долг по одной статье и переплата по другой), в общем итоге «К выплате» сумма может выглядеть корректно, но внутри запроса это будут две разные строки, которые схлопываются только на этапе вывода в макет.

Рекомендации по отладке для разработчика

Поскольку отчет строится на СКД с динамическим формированием текста запроса, обычный просмотр кода в конфигураторе может быть малоэффективен. Рассмотрим наиболее результативный способ анализа:

1. Используйте консоль запросов с функцией перехвата запроса из СКД.
2. Установите точку останова в общем модуле ЗарплатаКадрыОтчеты в момент вызова процедуры СкомпоноватьРезультат или аналогичной.
3. Вычислите значение схемы компоновки и макета компоновки. Извлеките итоговый текст запроса, который 1С сгенерировала «под капотом».

Только так вы увидите финальный текст с учетом всех временных таблиц и соединений, что позволит вам точно определить, из какого ресурса какого регистра попала та или иная цифра в ваш конкретный расчетный листок.

Таким образом, мы выяснили, что для понимания алгоритма «К выплате» недостаточно одного регистра. Необходимо анализировать комплексную работу модулей отчетности и учитывать настройки учетной политики организации, которые динамически меняют текст исполняемого запроса.