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

Бухгалтер 1С v8.3 (Управляемые формы) 1С:Зарплата и Управление Персоналом Бухгалтерский учет
← На главную

Расчет среднего заработка за периоды 2020 года стал настоящим испытанием для практикующих бухгалтеров и расчетчиков заработной платы. Изменения в законодательстве, введение понятий «оплачиваемые нерабочие дни» (код «ОН» в табеле), а также проведение Парада Победы 24 июня 2020 года породили множество технических сложностей в программе 1С:Зарплата и управление персоналом 3.1. Очень часто пользователи сталкиваются с ситуацией, когда программа некорректно выбрасывает или добавляет лишний день в расчете среднего заработка, искажая итоговые суммы отпускных, командировочных или пособий при увольнении.

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

Законодательный контекст: почему «поплыл» расчет среднего заработка?

Для того чтобы понять логику работы программы 1С, необходимо обратиться к нормативной базе. Основной причиной изменения алгоритмов расчета среднего заработка стало письмо Минтруда России от 18 мая 2020 года № 14-1/В-585.

Согласно разъяснениям ведомства, если сотрудник освобождался от работы в нерабочие оплачиваемые дни, объявленные Указами Президента РФ (включая нерабочие периоды марта–мая, а также праздничный день проведения Парада Победы 24 июня 2020 года по Указу № 345), и за ним сохранялась заработная плата, то:

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

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

Изменение логики в 1С:ЗУП 3.1 и настройка программы

Начиная с релизов 3.1.14.60 / 3.1.14.61 (а также в ветке 3.1.10.491), в программе появилась возможность гибкой настройки учета этих периодов. Проанализируем, где находятся ключевые переключатели, влияющие на расчет.

Перейдем в раздел Настройка -> Расчет зарплаты. Здесь расположена специальная таблица настроек, в которой можно установить или снять флажки для учета периодов нерабочих дней (в том числе для даты 24 июня 2020 года). Если в вашей компании принято решение рассчитывать средний заработок «по-старому» (то есть включать эти дни и суммы в расчет вопреки рекомендациям Минтруда), вам потребуется установить флажок «Учитывать оплачиваемое нерабочее время и суммы в среднем заработке».

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

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

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

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

Влияние зарегистрированной программной ошибки (Баг № 10223517)

Многие пользователи столкнулись со странным поведением системы: сотрудник фактически работал 24 июня (в табеле стоит код «Явка»), но программа все равно упорно уменьшала количество отработанных календарных дней на единицу. Это было вызвано официальным багом конфигурации под номером 10223517.

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

Почему «лихорадит» регистр накопления и как это исправить?

Причиной того, что после обновления программы или изменения настроек расчет среднего заработка продолжает выдавать неверные данные (например, вместо 17 дней берется 16, или вместо 10 берется 11), является рассинхронизация данных в специализированном регистре накопления. Данные о времени для расчета среднего заработка хранятся в регистре РегистрНакопления.ДанныеОВремениДляРасчетаСреднегоЗаработкаОбщий.

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

Разберем по шагам универсальный алгоритм исправления этой проблемы:

Шаг 1. Проверка исходных кадровых документов

Прежде всего необходимо тщательно проверить первичные документы. Как показывает практика (и в частности, решение проблемы участниками форума), очень часто виновником сдвига дней является неправильно или некорректно оформленный документ Отпуск, Больничный лист или Командировка, границы которых накладывались на спорные периоды июня 2020 года.

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

Шаг 2. Корректировка табеля и начислений

Если для сотрудника вводился документ Табель или Индивидуальный график, убедитесь, что в них правильно отражен день 24 июня:

После проверки кадровых документов обязательно перепроведите документ Начисление зарплаты и взносов за июнь 2020 года по данному сотруднику, чтобы зафиксировать верные расчетные суммы.

Шаг 3. Использование обработки обновления данных для расчета среднего

Для того чтобы принудительно перезаписать информацию в регистре накопления и заставить программу пересчитать дни по новым правилам, выполним следующие действия:

  1. Перейдем в раздел Зарплата -> Сервис.
  2. Найдем и запустим обработку «Обновить данные для расчета среднего заработка».
  3. В открывшемся окне укажем период (обязательно захватывая июнь 2020 года) и выберем организацию или конкретного сотрудника, по которому наблюдаются расхождения.
  4. Нажмем кнопку «Выполнить». Программа проанализирует все первичные начисления и заново сформирует записи в регистре накопления времени.

Шаг 4. Пересчет среднего заработка в целевом документе

После того как регистры были успешно обновлены, нам необходимо обновить расчет в том документе, где мы изначально обнаружили ошибку (это может быть документ Увольнение, Отпуск или Командировка):

  1. Откроем проблемный документ.
  2. Нажмем на кнопку с зелеными стрелками (пересчитать сотрудника) или зайдем в форму ввода данных о среднем заработке (нажав на карандаш рядом с полем «Средний заработок»).
  3. Нажмем кнопку «Пересчитать».
  4. Проверим количество дней в колонках расчета. Дни должны прийти в строгое соответствие с табелем и настройками программы.
  5. Проведем документ.

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

← На главную