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

← На главную

При переходе с 1С:ЗУП 2.5 на версию 3.1 многие разработчики сталкиваются с серьезным барьером: механизмы, которые раньше реализовывались простым копированием документов, теперь требуют глубокого понимания внутреннего «движка» программы. Одной из типичных задач является создание инструмента для ввода основного начисления и нескольких зависимых от него доплат. Разберем, почему копирование типовых объектов — это тупиковый путь, и как правильно реализовать задачу с использованием расширений и механизмов расчетной базы.

Проблема «типовой функциональности» при копировании документов

Рассмотрим ситуацию: разработчик копирует документ ИзменениеОплатыТруда, надеясь сохранить его логику. Однако в ЗУП 3.1 расчеты в формах документов жестко завязаны на общие модули и менеджеры временных таблиц. Проанализируем основные причины, по которым копия документа часто оказывается неработоспособной:

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

Метод 1: Использование показателей и штатных формул (Low-code подход)

Прежде чем приступать к кодингу, выясним, нельзя ли решить задачу настройками. В ЗУП 3.1 расчетная база — это динамический механизм. Если вам нужно добавить 3–4 зависимых вида расчета, оптимальнее использовать **Показатели расчета зарплаты**.

Рассмотрим алгоритм действий:

Создадим произвольные показатели (например, ДоплатаЗаСложность, ПедНагрузка).
В настройках вида расчета укажем формулу, использующую эти показатели и РасчетнаяБаза.
Добавим эти начисления сотруднику через типовой документ ИзменениеОплатыТруда. Программа сама выведет колонки для ввода показателей в табличную часть Начисления.

Этот способ гарантирует прозрачность для бухгалтера и корректное отражение в отчетах без вмешательства в код.

Метод 2: Программная доработка через расширение конфигурации

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

Проанализируем шаги реализации в расширении:

Заимствуем форму документа ИзменениеОплатыТруда.
Добавляем в расширение необходимые реквизиты или элементы формы (например, группу полей «Педагогическая нагрузка»).
Используем обработчики &После для процедур ПриСозданииНаСервере и ПриИзменении данных в наших полях.

Пример программного добавления строк в табличную часть начислений:


&НаСервере
Процедура ПослеДобавленияМоихНачислений(ДанныеФормы)
    НоваяСтрока = Объект.Начисления.Добавить();
    НоваяСтрока.Начисление = Справочники.Начисления.НайтиПоНаименованию("Доплата за стаж");
    НоваяСтрока.Размер = ПолучитьРазмерДоплаты(Объект.Сотрудник);
    // Вызов типового механизма пересчета
    ОбновитьПоказателиНачисления(НоваяСтрока);
КонецПроцедуры

Как получить расчетную базу «на лету» в форме документа

Один из самых сложных вопросов — как получить сумму базы (например, сумму оклада и других доплат) для расчета процента прямо в форме, до проведения документа. В ЗУП 3.1 для этого используется менеджер временных таблиц.

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

Для получения актуальной базы в коде формы необходимо обращаться к функции РассчитатьЗарплату или специализированным API-методам модуля РасчетЗарплатыРасширенный. Программа анализирует настройки вида расчета (вкладка «Расчет базы»), собирает все начисления сотрудника, действующие в этом периоде, и суммирует их.

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

Работа с регистрами плановых начислений

Чтобы ваше «дополнение» корректно заработало как плановое начисление (т.е. действовало из месяца в месяц), документ должен правильно заполнить регистр сведений ПлановыеНачисления. Проанализируем ситуацию: если просто записать данные в ТЧ документа, но не прописать логику в ОбработкаПроведения, начисления не попадут в документ Начисление зарплаты и взносов в конце месяца.

При использовании расширения к типовому документу эта проблема снимается автоматически, так как типовой код проведения сам «подхватит» ваши строки из таблицы Начисления. Если же вы все-таки создаете свой документ, вам придется вручную формировать движения по регистру:


Движение = Движения.ПлановыеНачисления.Добавить();
Движение.Сотрудник = СтрокаТЧ.Сотрудник;
Движение.Начисление = СтрокаТЧ.Начисление;
Движение.ДатаНачала = Объект.ДатаИзменения;
Движение.Используется = Истина;
// Важно: нужно также записать показатели в ЗначенияПериодическихПоказателей...