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