В практике работы с программой 1С:Зарплата и Управление Персоналом 2.5 (ЗУП 2.5) бухгалтеры и расчетчики иногда сталкиваются с ситуацией, когда одному сотруднику в течение одного месяца необходимо назначить более 6 различных видов времени. Это актуально для предприятий со сложными графиками, где есть ночные, вечерние смены, дежурства, сверхурочные, работа в выходные и различные виды специфических явок. При использовании режима Сводно за месяц в документе ТабельУчетаРабочегоВремени пользователь обнаруживает, что количество колонок для видов времени ограничено шестью позициями.
В рамках данной статьи мы подробно проанализируем, почему существует это ограничение, разберем технические причины его возникновения и рассмотрим наиболее эффективные способы решения задачи без критического вмешательства в программный код.
Разберем ситуацию с точки зрения разработчика конфигурации. Если мы откроем конфигуратор ЗУП 2.5 и изучим структуру документа ТабельУчетаРабочегоВремени, то увидим, что табличная часть Состав при выбранном режиме «Сводно за месяц» не использует динамическое добавление строк для видов времени. Вместо этого в структуре метаданных жестко прописаны реквизиты:
ВидВремени1, ВидВремени2 ... ВидВремени6Дней1, Дней2 ... Дней6Часов1, Часов2 ... Часов6Проанализируем программный код модулей документа. В десятках мест (обработка проведения, заполнение, печатные формы) используется прямой перебор этих реквизитов. Пример типичного фрагмента кода выглядит следующим образом:
Для Номер = 1 По 6 Цикл
ТекВидВремени = СтрокаТабличнойЧасти["ВидВремени" + Номер];
ТекЧасов = СтрокаТабличнойЧасти["Часов" + Номер];
// Дальнейшая логика обработки данных
КонецЦикла;
Попытка простого добавления реквизита ВидВремени7 в табличную часть не решит проблему автоматически. Потребуется внести изменения во все модули, где встречается ограничение цикла или прямое обращение к шестому реквизиту. Кроме того, данные из табеля должны корректно транслироваться в регистр расчета ОсновныеНачисленияСотрудниковОрганизаций, структура которого также оптимизирована под типовую логику.
Рассмотрим методологический аспект. Сводный табель в ЗУП 2.5 часто критикуется экспертами по следующим причинам:
Самый правильный и стабильный способ обойти ограничение — это использование режима По дням в документе ТабельУчетаРабочегоВремени. Разберем по шагам, почему это решает нашу задачу:
Проанализируем ситуацию: если у сотрудника действительно так много видов времени, что они не умещаются в 6 колонок, значит, его график работы достаточно сложен. Поденный учет обеспечит прозрачность контроля для бухгалтера и минимизирует ошибки в расчете среднего заработка.
Рассмотрим альтернативную методику, которую часто игнорируют начинающие пользователи. В 1С:ЗУП 2.5 табель не является единственным источником данных о времени. Программа построена на принципе вытеснения.
Если мы зарегистрируем отсутствие сотрудника специализированными документами, такими как:
Начисление по больничному листуНачисление отпуска сотрудникам организацийКомандировки организацийНевыходы в организацияхто эти виды времени автоматически «вытеснят» основное рабочее время (Явку). В этом случае в сводном табеле их указывать вообще не нужно. Табель должен фиксировать только те отклонения, которые не вводятся отдельными расчетными документами (например, Ночные или Сверхурочные). Таким образом, количество колонок в табеле существенно сокращается, и лимит в 6 штук перестает быть препятствием.
Если бизнес-процесс компании категорически требует использования именно сводного табеля с 10-15 видами времени, нам придется прибегнуть к кастомизации. Однако, вместо добавления реквизитов ВидВремени7...20, проанализируем более изящный путь, реализованный в современных версиях (ЗУП 3.1).
Мы можем изменить структуру хранения данных в документе, отказавшись от «горизонтальной» модели (колонки) в пользу «вертикальной» (подчиненная табличная часть). В этом случае для каждой строки сотрудника в основной ТЧ будет существовать связь с набором строк в дополнительной ТЧ, где количество видов времени будет неограниченным.
Важно: Такое изменение потребует полной переписки механизмов:
ДвиженияПоРегистрам (запись в ОсновныеНачисления).Учитывая трудозатраты и риски при обновлении, данный метод крайне не рекомендуется. Проанализировав опыт внедрений, можно уверенно сказать: проще переучить пользователей работать с поденным табелем или документами-отклонениями.
Для понимания того, к чему пришла эволюция платформы, посмотрим на ЗУП версии 3.1. Разработчики полностью отказались от архитектуры «фикс-колонок». В новом «Табеле» данные хранятся динамически. Это подтверждает, что ограничение в версии 2.5 было связано именно с жесткостью реляционной модели данных того времени и отсутствием возможности хранить «таблицу в таблице» без серьезных потерь производительности.
Выясним окончательно: можно ли ввести более 6 видов времени в сводном табеле ЗУП 2.5 «из коробки»? Нет, нельзя. Это платформенное и конфигурационное ограничение архитектуры обычных форм десятилетней давности.
Рекомендованный алгоритм действий:
Помните, что любое «силовое» расширение колонок в ЗУП 2.5 приведет к проблемам при расчете среднего заработка и формировании регламентированной отчетности (например, формы П-4), так как типовые запросы этих отчетов «не знают» о ваших новых реквизитах ВидВремени7.