При переходе со старых версий программы (например, с 1С:ЗУП 2.5) на современную редакцию 1С:Зарплата и Управление Персоналом 3.1 расчетчики и внедренцы часто сталкиваются с изменением логики работы механизмов вытеснения и перерасчетов. Типичный сценарий: на предприятии выплачивается разовая или ежемесячная премия, которая рассчитывается как определенный процент от базовых начислений (оклада, отпуска, больничного листа). Однако по условиям коллективного договора или локальных нормативных актов, если в последующих периодах происходит сторнирование или уменьшение этих базовых начислений (например, из-за несвоевременно предоставленного больничного или отзыва из отпуска), ранее выплаченная премия не должна уменьшаться и сторнироваться.
В этой статье мы подробно разберем, почему в 1С:ЗУП 3.1 возникает автоматическое сторнирование таких премий, проанализируем неэффективные методы борьбы с этой проблемой и рассмотрим четыре работающих практических способа, позволяющих обойти это ограничение и настроить систему под ваши требования.
Давайте выясним первопричину такого поведения программы. В редакции 2.5 существовало четкое разделение в настройках видов расчета на две независимые вкладки: «Базовые виды расчета» (начисления, от которых рассчитывается сумма текущего начисления) и «Ведущие виды расчета» (начисления, изменение которых за прошлые периоды приводит к необходимости пересчитать текущее начисление). Расчетчик мог легко настроить премию так, чтобы оклад входил в базовые начисления, но не являлся ведущим. В этом случае премия рассчитывалась от оклада, но при его изменении в прошлых периодах перерасчет премии не регистрировался.
В 1С:ЗУП 3.1 разработчики упростили интерфейс и убрали явную настройку ведущих начислений. Теперь логика платформы 1С работает следующим образом: если в формуле начисления используется предопределенный показатель РасчетнаяБаза, программа автоматически делает все начисления, входящие в эту базу, ведущими для данного вида расчета. Изменить это поведение в пользовательском режиме напрямую невозможно. Как только в системе проводится сторнирующий документ (например, регистрируется больничный лист, который перекрывает период ранее проведенного отпуска или оклада), программа автоматически делает запись в регистр перерасчетов. При очередном расчете зарплаты или при увольнении сотрудника система обнаруживает эту запись и сторнирует часть премии пропорционально уменьшению базы.
Иногда расчетчики пытаются обойти проблему с помощью изменения формулы расчета. Рассмотрим популярную формулу, которую часто пытаются внедрить:
?(РасчетнаяБаза <= 0, 0, ПроцентПремии / 100 * РасчетнаяБаза)
Давайте проанализируем эту ситуацию. Данное условие отлично защищает расчетчика от получения отрицательного значения премии в текущем периоде (например, если база сотрудника в этом месяце ушла в минус). Однако оно абсолютно бессильно против механизма сторнирования за прошлые периоды. Когда программа выполняет перерасчет за прошлый месяц, она рассчитывает премию заново по формуле и сравнивает результат с уже начисленной суммой.
Пример: В январе сотруднику начислили оклад 50 000 руб. и премию 10% (5 000 руб.). В феврале выяснилось, что в конце января сотрудник болел, и ему сторнируют часть январского оклада в размере 10 000 руб. Новая база января составляет 40 000 руб. Программа рассчитывает премию за январь заново: 40 000 * 10% = 4 000 руб. Затем система сравнивает новый результат (4 000 руб.) со старым (5 000 руб.) и регистрирует сторно в размере -1 000 руб. Условие РасчетнаяБаза <= 0 здесь не сработает, так как новая база (40 000 руб.) больше нуля. Таким образом, изменение формулы не решает проблему сторнирования прошлых периодов.
Ниже приведены четыре эффективных способа настройки программы, которые помогут решить задачу.
Самый надежный и методологически верный способ запретить программе отслеживать изменения базы — это полностью исключить использование предопределенного показателя РасчетнаяБаза из формулы начисления. Если нет показателя РасчетнаяБаза, то для программы это начисление перестает быть зависимым, и автоматические перерасчеты не регистрируются.
Рассмотрим по шагам, как настроить этот вариант:
БазаПремииВручную. Укажем следующие свойства:
По отдельному документу (выберем документ Премия).ПроцентПремии / 100 * БазаПремииВручную. При этом показатель ПроцентПремии может быть постоянным для организации или также вводиться в документе.БазаПремииВручную.Результат: Так как база внесена как обычное числовое значение через независимый показатель, программа не связывает премию с начислениями оклада или отпуска. Никакие последующие корректировки и сторно базовых документов не вызовут перерасчет и сторнирование премии.
Если на предприятии работает большое количество сотрудников и ручной ввод базы через документ Данные для расчета зарплаты отнимает слишком много времени, процесс можно автоматизировать без создания системных зависимостей.
Разберем этот метод подробнее:
Результат вводится фиксированной суммой (или рассчитывается по формуле, где результатом является фиксированная сумма, вводимая вручную в документе).ОсновныеНачисления и получает реальную сумму базы за указанный период по каждому сотруднику, умножает ее на необходимый процент и подставляет итоговый результат непосредственно в колонку "Результат" документа "Премия".Результат: Для программы эта премия выглядит как начисление фиксированной суммой. В регистре расчета не фиксируется связь по расчетной базе, а значит, при увольнении или исправлении документов прошлых периодов сторнирование премии никогда не произойдет. Это идеальное решение для крупных организаций, сочетающее полную автоматизацию расчета и отсутствие нежелательных сторно-записей.
Если проблема сторнирования актуальна не только для премии, но и для других начислений, и расчетчики хотят полностью контролировать процесс возникновения сторно-строк в документах, можно изменить глобальное поведение системы.
Проанализируем этот вариант настройки:
Посмотрим, как изменится логика программы после включения этой настройки. По умолчанию программа пытается выполнить все перерасчеты «на лету» — прямо в текущем документе Начисление зарплаты и взносов на специальной вкладке "Доначисления, перерасчеты" или при расчете документа Увольнение.
После включения указанной опции программа перестанет автоматически добавлять сторно-строки в текущие расчетные документы. Все зарегистрированные перерасчеты (включая сторно премии при изменении оклада) будут аккумулироваться в специальном рабочем месте. Произвести эти перерасчеты можно будет только специализированным документом Доначисление, перерасчет (раздел Зарплата). Если расчетчик видит, что программа предлагает отсторнировать премию, которую трогать не нужно, он может просто не заполнять этот документ по данному сотруднику или удалить ненужные строки перерасчета перед проведением документа.
Если вам не подходят варианты с изменением формул и привлечением программистов, существует оперативный административный метод управления перерасчетами в пользовательском интерфейсе.
Рассмотрим по шагам этот алгоритм работы:
Ctrl + A для выделения нескольких строк) и нажмем кнопку «Отменить» (или клавишу Del).Результат: Записи о необходимости перерасчета премии будут удалены из системы. При последующем начислении зарплаты за текущий месяц или при расчете увольнения программа «забудет» о том, что премию нужно было скорректировать, и никакого сторно не возникнет.
Важное примечание: Этот способ требует высокой концентрации и внимательности от пользователей. Расчетчикам необходимо взять за правило: после проведения любых исправлений за прошлые периоды обязательно заходить в рабочее место "Перерасчеты" и очищать записи по тем видам начислений, сторнирование которых запрещено правилами внутреннего распорядка компании.
Мы подробно разобрали проблему автоматического сторнирования премий в программе 1С:ЗУП 3.1 и изучили способы её решения. Выбор конкретного метода зависит от особенностей учета в вашей компании: