← На главную

При переходе на новые релизы программы 1С:Зарплата и управление персоналом (редакция 3) многие бухгалтеры и расчетчики сталкиваются с изменением визуального представления расчетных листков. Ранее при наличии сторнируемых записей удержаний (например, при перерасчете алиментов за прошлые периоды) в расчетном листке выводилась итоговая свернутая сумма. Теперь же программа детально показывает каждую операцию: отдельно сумму с минусом за прошлый период и отдельно начисление с плюсом за текущий.

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

Суть изменений в расчетных листках

Начиная с релизов ветки 1С:ЗУП 3.1.10 и выше, разработчики изменили подход к детализации данных в отчетах по анализу зарплаты. Если у сотрудника происходит перерасчет ранее зарегистрированных удержаний (чаще всего это касается исполнительных листов, алиментов или удержаний за неотработанный отпуск), программа больше не схлопывает эти суммы в одну строку.

Рассмотрим стандартную ситуацию. У сотрудника в июле был изменен (уменьшен) размер удержания по исполнительному листу задним числом за июнь. Программа делает сторнирование. В результате в расчетном листке за июль мы видим следующую картину:

• Удержание по исполнительному документу (июнь): -1 000,00 руб.
• Удержание по исполнительному документу (июль): 5 273,66 руб.

На первый взгляд кажется, что это ошибка программы, ведь ранее выводился свернутый итог. Однако это поведение является абсолютно корректным и заложенным разработчиками.

Почему происходит детализация: анализируем регистры накопления

Чтобы понять логику программы, заглянем во внутренние механизмы 1С:ЗУП. Вся информация для расчетного листка и отчета «Анализ начислений и удержаний» собирается из регистра накопления НачисленияУдержанияПоСотрудникам.

Группировка (сворачивание) строк в расчетном листке происходит через СКД (систему компоновки данных) по определенным правилам. Строки объединяются в одну итоговую сумму исключительно в том случае, если у них совпадают все ключевые измерения и реквизиты:

1. Физическое лицо и Сотрудник — данные должны относиться к одному человеку.
2. Вид удержания — например, конкретный вид расчета (алименты, профвзносы).
3. Период действия (период, за который производится расчет) — это ключевой фактор. Месяц, за который сторнируется сумма (июнь), и месяц, за который она начисляется (июль), — это разные периоды.
4. Период регистрации (месяц, в котором проводится документ).
5. Документ-основание — конкретный исполнительный лист или соглашение.

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

Проводим практический эксперимент

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

Ситуация 1. Сторно и начисление относятся к разным периодам действия

Вносим документ исправления. Сторнируем удержание по исполнительному листу за прошлый месяц на сумму -1 000 рублей. В текущем месяце рассчитываем новое удержание в размере 5 273,66 рублей. Периоды действия записей разные (июнь и июль соответственно).

Результат в расчетном листке: Программа выведет две отдельные детальные строки. Сотрудник четко увидит, за какой именно месяц с него удержали излишне и сколько доначислили в текущем.

Ситуация 2. Искусственное совмещение периодов действия

В тестовых целях скорректируем записи регистра так, чтобы у сторнируемой суммы (-1 000 рублей) и у новой начисленной суммы (5 273,66 рублей) совпадали все аналитики, включая период действия (например, установим для обеих строк июль) и документ-основание.

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

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

Зачем это было сделано? (Методологическая ценность)

Разработчики фирмы 1С пошли на усиление детализации отчетов не просто так. В последних версиях ЗУП 3.1 был кардинально переработан механизм ограничения взысканий в соответствии со статьей 138 ТК РФ.

Для корректного ведения взаиморасчетов с сотрудниками и получателями удержаний программе крайне важно разделять долги и сторно-записи по периодам их возникновения. Если бы программа принудительно сворачивала сторно прошлых периодов с начислениями текущего, возникали бы следующие проблемы:

• Становилось невозможно отследить предельную величину удержаний в разрезе каждого конкретного месяца.
• Искажалась бы аналитика по задолженности перед получателями (истцами) в исполнительном производстве.
• Бухгалтеру было бы крайне сложно объяснить сотруднику структуру его удержаний, особенно при наличии нескольких исполнительных листов разной очередности.

Рекомендации для работы

Если ваши сотрудники удивлены новым детальным видом расчетных листков, рекомендуем действовать по следующему алгоритму:

1. Объясните сотрудникам логику расчета. Разъясните, что детальный вывод минусовых сумм — это гарантия того, что излишне удержанные ранее средства были учтены программой и возвращены (уменьшили общую сумму удержаний текущего месяца).
2. Проверяйте документы-основания. Если вы видите, что суммы не свернулись там, где должны были, проверьте, указан ли один и тот же исполнительный лист в исходном расчете и в документе перерасчета.
3. Используйте типовые настройки. Не пытайтесь переписать отчеты или принудительно объединять записи в регистрах. Текущая детализация полностью соответствует требованиям законодательства по ведению детального учета удержаний по исполнительному производству.