В практике работы крупных предприятий, особенно в регионах Крайнего Севера и Дальнего Востока, часто возникает ситуация, когда кадровые приказы на отпуск оформляются за несколько месяцев до самого события. Это необходимо сотрудникам для заблаговременной покупки билетов и планирования проезда, стоимость которого компенсирует работодатель. Однако в программе 1С:Зарплата и Управление Персоналом 3.1 такая практика наталкивается на технический барьер: если документ Отпуск был создан в феврале с датой документа от 1 февраля, а сам отпуск начинается в июне, то к моменту расчета отпускных (в конце мая или начале июня) первый квартал уже будет закрыт датой запрета редактирования. Бухгалтер-расчетчик просто не сможет «рассчитать» такой документ, так как он станет доступен только для чтения.
Проанализируем ситуацию и разберем несколько вариантов решения этой проблемы: от изменения методики ведения учета до внесения правок в программный код через механизм расширений.
Рассмотрим наиболее «чистый» с точки зрения методологии 1С способ. Проблема автора заключается в том, что документ Отпуск в ЗУП 3.1 является «сквозным» — он одновременно содержит и кадровые данные (даты, основание), и расчетные (средний заработок, начисления, НДФЛ). Чтобы избежать блокировки, мы можем разделить эти процессы.
Для этого в программе предусмотрен документ Отпуск сотрудников (в разделе Кадры). В отличие от одиночного документа Отпуск, списочный документ Отпуск сотрудников (форма Т-6а) является чисто кадровым. Рассмотрим алгоритм работы с ним:
Отпуск сотрудников. Указывает в нем реальную дату приказа (февраль) и периоды отпуска (июнь).Отпуск (расчетный), дата которого будет текущей (июньской).Таким образом, дата приказа (для печатной формы) остается февральской, а расчетный период и дата регистрации финансового документа попадают в июнь, что полностью снимает конфликт с датой запрета изменений.
Выясним причину, по которой документ становится недоступен. По умолчанию дата запрета действует на все разделы учета. Однако в системе 1С (Библиотека Стандартных Подсистем) предусмотрена возможность тонкой настройки. Проанализируем настройки в разделе Администрирование — Обслуживание — Даты запрета изменения:
Это позволит кадровикам вносить изменения в кадровые данные документов, даже если период для расчета зарплаты уже закрыт. Но стоит учитывать, что в документе Отпуск поля тесно связаны, и полное редактирование расчетной части все равно может быть ограничено.
Если бизнес-процесс компании невозможно изменить и кадровикам принципиально важно работать в одном документе Отпуск, созданном заранее, мы можем воспользоваться программным механизмом обхода проверки даты запрета. В БСП предусмотрено специальное свойство ОтключитьПроверкуДатыЗапретаИзменения.
Рассмотрим, как реализовать это в расширении. Нам необходимо перехватить процедуру ПередПроверкойЗапретаИзменения в общем модуле ДатыЗапретаИзмененияПереопределяемый. Посмотрим на пример кода:
Процедура ПередПроверкойЗапретаИзменения(Объект, ПроверкаЗапретаИзменения, УзелПроверкиЗапретаЗагрузки, ВерсияОбъекта) Экспорт
// Если это документ Отпуск, мы можем программно разрешить его изменение
Если ТипЗнч(Объект) = Тип("ДокументОбъект.Отпуск") Тогда
// Проверяем, нужно ли нам отключать проверку.
// Например, можно проверять наличие определенного флага или роли пользователя.
Объект.ДополнительныеСвойства.Вставить("ОтключитьПроверкуДатыЗапретаИзменения", Истина);
ПроверкаЗапретаИзменения = Ложь; // Отключаем стандартную проверку БСП
УзелПроверкиЗапретаЗагрузки = Неопределено;
КонецЕсли;
КонецПроцедуры
Важный нюанс: Просто вставить это свойство недостаточно. Чтобы форма документа стала доступна для редактирования (не «Read-only»), необходимо также передать это свойство в процедурах формы ПриСозданииНаСервере или ПередЗаписьюНаСервере.
&НаСервере
Процедура ИмяРасширения_ПередЗаписьюНаСервере(Отказ, ТекущийОбъект, ПараметрыЗаписи)
ТекущийОбъект.ДополнительныеСвойства.Вставить("ОтключитьПроверкуДатыЗапретаИзменения", Истина);
КонецПроцедуры
Проанализируем ситуацию: почему документ блокируется? Потому что БСП проверяет реквизит Дата. Но в зарплатных решениях фактическим периодом совершения операции является ПериодРегистрации (Месяц, указанный в шапке документа).
Мы можем изменить логику проверки так, чтобы для документов типа Отпуск система смотрела не на дату документа (февраль), а на месяц начисления (июнь). Если июнь еще не закрыт датой запрета, то документ должен быть доступен, несмотря на «старую» дату самого документа.
Для реализации этого подхода в общем модуле ДатыЗапретаИзмененияПереопределяемый необходимо переопределить получение полей даты для проверки:
Процедура ПриОпределенииПолейДатыЗапретаИзменения(ПоляДаты) Экспорт
// Указываем, что для документа Отпуск проверку нужно делать по реквизиту Месяц (ПериодРегистрации)
ПоляДаты.Вставить(Метаданные.Документы.Отпуск, "Месяц");
КонецПроцедуры
Этот способ является наиболее логичным с точки зрения учета в 1С:ЗУП, так как он не «пробивает дыру» в безопасности (как полное отключение проверки), а заставляет систему проверять именно тот период, в который падают расходы по данному документу.
Разберем, почему бухгалтеры часто против таких манипуляций. Основная причина — НДФЛ и страховые взносы. В 1С:ЗУП 3.1 «Дата выплаты» в документе Отпуск определяет дату получения дохода для целей НДФЛ.
Если документ создан 1 февраля, а выплата реально происходит в июне, крайне важно, чтобы в документе была указана актуальная Дата выплаты. Если оставить там февральскую дату, то при проведении документа в июне программа попытается «закинуть» доход и налог в февраль, что приведет к искажению отчетности 6-НДФЛ и необходимости подавать уточняющие расчеты за 1 квартал.
Рекомендации при использовании технических решений:
Дата выплаты.Месяц начисления соответствовал текущему открытому периоду.Таким образом, мы рассмотрели как методический подход (использование кадровых списочных документов), так и программный (через ДополнительныеСвойства или изменение полей проверки даты запрета). Выбор зависит от готовности менять бизнес-процессы в вашей организации.