При работе в программе 1С:Зарплата и Управление Персоналом (редакции 3.1.4, 3.1.5 и выше) многие пользователи сталкиваются с парадоксальной ситуацией: стаж сотрудника, который должен ежедневно расти, внезапно уменьшается на один день или ведет себя нестабильно. Например, на 1-е число месяца стаж составляет 10 лет, 2 месяца и 5 дней, а на 2-е число программа показывает 10 лет, 2 месяца и 4 дня. Рассмотрим детально причины такого поведения программы и разберем по шагам, как правильно настроить учет, чтобы избежать ошибок.
Проанализируем самую частую ошибку, связанную с человеческим фактором и логикой программы. В 1С:ЗУП начальный стаж вводится в карточке сотрудника по ссылке Трудовая деятельность. Проблема возникает, когда кадровик вводит стаж «на дату приема».
Разберем ситуацию на примере. Сотрудник принимается на работу 01.03.2018. Кадровик рассчитывает стаж по трудовой книжке на утро этого дня и вводит его в программу, указывая дату 01.03.2018. Выясним, что происходит внутри системы:
Как исправить: Для корректного расчета всегда вводите стаж на дату, предшествующую дню приема на работу. Если сотрудник принят 1 марта, стаж по трудовой книжке должен быть рассчитан и введен на 28 февраля. В этом случае 1 марта станет первым днем «нового» стажа, и цепочка периодов не прервется.
Посмотрим на проблему с точки зрения законодательства. В 1С:ЗУП для расчета страхового стажа используется алгоритм, описанный в п. 47 Постановления Правительства РФ от 02.10.2014 № 1015. Этот документ устанавливает специфические правила перевода дней в месяцы и годы.
Согласно правилам:
Проанализируем ситуацию: в календаре месяцы имеют разную длительность (28, 29, 30 или 31 день). Если стаж в трудовой книжке считался кадровиком «календарно» (например, февраль — это один месяц), а программа пересчитывает его по правилу «30 дней», возникает погрешность. В феврале 28 дней, и программе «не хватает» 2 дней до полного месяца. В итоге итоговое значение стажа может «просесть» на 1-2 дня, пока сотрудник не отработает эти недостающие дни в текущем месяце.
Выясним, как именно программный код 1С вычисляет стаж. В системе не хранится числовое значение лет и месяцев. Вместо этого при вводе начальных данных программа вычисляет условную дату начала стажа (так называемый «анкор» или точку отсчета).
Рассмотрим примерную логику кода, которая используется для определения этой даты:
// Упрощенная логика определения точки начала стажа
УсловнаяДатаНачала = ДатаВводаСтажа - (ВведенныхЛет * 365 + ВведенныхМесяцев * 30 + ВведенныхДней);
// При расчете на текущую дату программа выполняет обратную операцию:
ТекущийСтаж = РазностьДат(УсловнаяДатаНачала, ТекущаяДата, "Дни");
Из-за того, что количество дней в реальных месяцах не совпадает с константой 30, эта «условная дата» может плавать. Особенно остро это проявляется при переходе через границы месяцев разной длины (например, с 31 августа на 1 сентября или после 28 февраля). В эти моменты математический остаток дней меняется, что визуально выглядит как уменьшение стажа на один день.
Разберем специфику конкретных релизов, упомянутых в теме. В версиях 3.1.4.169 и 3.1.5.129 был зафиксирован программный дефект, связанный с функцией РазностьДат в языке запросов.
Проблема заключалась в учете времени (границы суток). Если стаж рассчитывался «на дату», программа могла не учитывать текущие сутки до их полного завершения (до 23:59:59). В результате в отчетах или формах расчета на определенное число стаж оказывался на 1 день меньше ожидаемого.
Решение: Если вы используете эти старые релизы, настоятельно рекомендуем обновиться до актуальных версий (начиная с 3.1.7 и выше), где алгоритмы вычисления были оптимизированы и приведены в большее соответствие с календарной логикой при сохранении требований Постановления №1015.
Проанализировав все причины, составим пошаговый алгоритм действий для исправления «прыгающего» стажа:
Трудовая деятельность. Убедитесь, что начальный стаж введен на дату, предшествующую дню приема. Если прием 01.04.2018, стаж должен стоять на 31.03.2018.Таким образом, «уменьшение» стажа чаще всего является не критической ошибкой, а следствием наложения календарной нелинейности на жесткий математический алгоритм. Использование правила «дата ввода = дата приема минус 1 день» решает 90% подобных проблем.