Как разделить сдельные наряды, оплату сверхурочных и праздничных в расчетном листке 1С:ЗУП 3.1?

← На главную

В типовой конфигурации 1С:Зарплата и управление персоналом 3.1 пользователи часто сталкиваются с ситуацией, когда все сдельные работы, включая оплату в выходные и сверхурочные, «схлопываются» в одну строку Сдельный заработок в расчетном листке. Это затрудняет проверку правильности начислений как для расчетчика, так и для самого сотрудника. В данной статье мы проанализируем причины такого поведения системы и разберем по шагам, как добиться детального разделения записей по документам-основаниям и видам времени.

Почему начисления объединяются в одну строку?

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

Способ 1: Настройка разных видов начислений

Самый простой путь без программирования — разделить начисления на уровне методологии. Рассмотрим этот вариант подробнее:

Создадим отдельные виды начислений: Сдельный заработок (основной), Сдельный заработок (выходные) и Сдельный заработок (сверхурочно).
Для каждого вида начисления настроим свой Шаблон ввода исходных данных.
В настройках начисления на вкладке Учет времени укажем соответствующие виды времени: Явка, Праздники или Сверхурочные.

Разделив эти потоки, мы добьемся того, что в расчетном листке появятся разные строки, так как это разные объекты справочника Начисления. Однако, если нарядов одного типа (например, основных) много, они все равно будут сгруппированы. Чтобы видеть каждый наряд отдельно, нам потребуется техническая доработка отчета.

Способ 2: Технический анализ структуры документа «Начисление зарплаты»

Выясним причину сложности получения данных. Информация о том, какой наряд (документ Данные для расчета зарплаты) лег в основу суммы, не хранится в регистре расчета напрямую. Эти данные находятся внутри документа Начисление зарплаты и взносов. Разберем внутреннюю структуру:

Табличная часть Начисления содержит итоговые суммы по сотруднику и виду начисления.
Табличная часть Показатели содержит значения всех показателей (выработка, тарифная ставка и т.д.) и ссылки на документы-основания.
Связь между этими таблицами осуществляется через техническое поле КлючСвязи.

Рассмотрим пример запроса, который позволяет вытащить связь начисления с конкретным документом наряда:


ВЫБРАТЬ
    Начисления.Сотрудник КАК Сотрудник,
    Начисления.Результат КАК Сумма,
    Показатели.Показатель КАК Показатель,
    Показатели.Значение КАК ЗначениеПоказателя,
    Показатели.ДокументОснование КАК ДокументНаряд
ИЗ
    Документ.НачислениеЗарплатыИВзносов.Начисления КАК Начисления
    ВНУТРЕННЕЕ СОЕДИНЕНИЕ Документ.НачислениеЗарплатыИВзносов.Показатели КАК Показатели
        ПО Начисления.Ссылка = Показатели.Ссылка
        И Начисления.КлючСвязи = Показатели.КлючСвязи
ГДЕ
    Начисления.Ссылка = &СсылкаНаДокументНачисления

Способ 3: Доработка расчетного листка через расширение

Чтобы не изменять типовую конфигурацию, рекомендуется использовать механизм расширений. Проанализируем, что именно нужно изменить в схеме компоновки данных (СКД) отчета РасчетныйЛисток:

Нам необходимо изменить основной запрос отчета, добавив в него данные из регистра накопления Значения оперативных показателей расчета зарплаты сотрудников. Именно в этом регистре 1С хранит сведения о введенной сделке до момента ее окончательного расчета.

Алгоритм доработки:

Добавляем в запрос поле Регистратор (это будет наш документ Данные для расчета зарплаты).
Связываем таблицу начислений с таблицей показателей по полям Сотрудник, Начисление и ПериодРегистрации.
В настройках варианта отчета добавляем новую группировку. Вместо простой группировки по начислению, делаем иерархию: Начисление -> Документ-основание.

Проблема учета времени для сдельщиков

Часто после обновлений пользователи замечают, что время в сделке перестает суммироваться или отображается некорректно. Выясним причину. В ЗУП 3.1 приоритет всегда отдается документу Табель, если он введен. Если же табеля нет, время берется из начислений.

Для корректного отражения времени в настройках сдельного начисления проверьте следующее:

На вкладке Учет времени должен быть выбран пункт Сдельная выработка или Явка.
Если вы хотите, чтобы часы из наряда попадали в расчетный листок, в формуле начисления обязательно должен присутствовать показатель времени, например: СдельныйЗаработок + 0 * ВремяВЧасах.
Использование конструкции 0 * ВремяВЧасах — это небольшая хитрость, которая заставляет программу «замечать» отработанное время и фиксировать его в регистре расчета, даже если сумма зависит только от выработки.

Важные нюансы при работе с праздничными и сверхурочными

Рассмотрим ситуацию, когда сделка выполняется в выходной день. Согласно ТК РФ, она должна быть оплачена в двойном размере. Проанализируем два способа настройки:

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

Вариант Б: В самом шаблоне наряда предусмотрен коэффициент (например, 2.0). В этом случае вся сумма будет в одной строке Сдельный заработок. Для разделения таких записей используйте группировку по полю Показатель.Коэффициент в настройках отчета.

Подводя итог, можно сказать, что типовой расчетный листок в ЗУП 3.1 ориентирован на итоговые суммы. Для получения детальной расшифровки по нарядам наиболее эффективным методом является использование внешнего отчета или расширения, которое обращается к табличной части Показатели документа начисления. Это гарантирует точность данных, так как именно эти цифры были утверждены при окончательном расчете зарплаты, в отличие от оперативных данных нарядов, которые могли быть изменены после ввода.