🎯 Что это и зачем

Статья 95 Трудового кодекса РК обязывает работодателя составлять и утверждать график отпусков не позднее чем за месяц до начала каждого года. Документ «Сбор графиков отпусков» — инструмент этой подготовки: он запускает кампанию сбора, фиксирует её жизненный цикл (запущена → заполнена → завершена / аннулирована) и накапливает результат в табличной части Сотрудники с периодами планируемых отпусков (даты начала, окончания, количество дней) для каждого работника.

Казахстанской расчётной специфики (ИПН, ОПВ, ОПВР, СО, ВОСМС/ООСМС, единый платёж) этот документ не содержит — он не делает движений по регистрам и не начисляет никаких сумм. Его роль — носитель состояния процесса и собранных кадровых данных. Механизм унаследован из российской типовой ЗУП 3.1, но применяется в РК без изменений, поскольку обязательность графика отпусков закреплена казахстанским ТК.

Кто работает: инспектор по кадрам / HR-специалист, как правило один раз в год — в октябре–ноябре при подготовке графика на следующий год.

🧭 Где найти в программе

Раздел «Кадры» → пункт «Сбор графиков отпусков». Откроется журнал документов; новый создаём кнопкой «Создать».

👤 Часть 1. Для пользователя

Проходим по шагам: от пустой кампании до завершённого графика отпусков.

Урок 1. Запуск кампании сбора графиков на год

Когда: конец текущего года; HR-служба начинает готовить график отпусков на следующий год. Это корневой документ кампании.

1. Создаём новый документ «Сбор графиков отпусков» кнопкой «Создать».
2. Указываем Год — год, на который собираются отпуска (например, 2027). Это ключевое поле кампании; без него документ лишён смысла.
3. Если сбор ведётся по всей организации сразу (без разбивки по подразделениям) — поле Подразделение оставляем пустым; если по конкретному подразделению — выбираем его.
4. Заполняем ИнициаторСбора — физлицо, запустившее кампанию (обычно сотрудник кадровой службы).
5. Заполняем ОтветственныйЗаСбор — физлицо, отвечающее за сбор данных.
6. Записываем документ; далее командой формы (точный вид команды зависит от UI) запускаем сбор — флаг СборЗапущен должен принять значение Истина, Состояние перейдёт в начальную стадию.

Урок 2. Каскадный сбор по подразделениям

Когда: крупная организация; корневая кампания разбивается на отдельные сборы для каждого подразделения, где за каждый отвечает свой ответственный.

1. Создаём корневой документ по инструкции Урока 1; поле Подразделение оставляем пустым, КорневойСборГрафиков — тоже пустым.
2. Запускаем корневой сбор командой формы.
3. Для каждого подразделения создаём дочерний документ: указываем Год (тот же), заполняем Подразделение, а в поле КорневойСборГрафиков ссылаемся на корневой документ — это и есть признак дочернего сбора.
4. Назначаем ОтветственныйЗаСбор — руководителя или кадровика подразделения.
5. Запускаем дочерний сбор; ответственный за подразделение наполняет ТЧ Сотрудники.
6. После завершения всех дочерних сборов корневой документ агрегирует итог (точная механика агрегации в карте не определена).

Урок 3. Внесение планируемых отпусков сотрудников

Когда: кампания запущена (СборЗапущен = Истина, СборЗавершен = Ложь); ответственный за подразделение заполняет периоды отпусков.

1. Открываем документ сбора своего подразделения.
2. Переходим на вкладку / в табличную часть «Сотрудники».
3. Для каждого работника добавляем строку: заполняем ФизическоеЛицо (актуальная колонка идентификации), ДатаНачала, ДатаОкончания и КоличествоДней.
4. Если у сотрудника несколько частей отпуска (по ст. 95 ТК РК отпуск может делиться) — добавляем несколько строк с одним и тем же ФизическоеЛицо.
5. Записываем документ; поле КоличествоСотрудников в шапке отражает охват (порядок его пересчёта в карте не определён).

Урок 4. Завершение и аннулирование сбора

Сценарий А — Завершение: все подразделения внесли данные, кампания закрывается.

1. Ответственный за сбор проверяет полноту ТЧ Сотрудники — охвачены ли все работники.
2. Командой формы завершает кампанию; флаг СборЗавершен становится Истина, Состояние переходит в финальную стадию (конкретные значения перечисления в карте не приведены).
3. Собранные данные используются кадровой службой для формирования и утверждения графика отпусков организации.

Сценарий Б — Аннулирование: кампания запущена ошибочно или отменена решением руководства.

1. Уполномоченный пользователь аннулирует сбор командой формы.
2. Автоматически устанавливаются: СборАннулирован = Истина, ДатаАннулирования (момент отмены) и ОтветственныйЗаАннулирование (пользователь ИБ).
3. История кампании сохраняется — документ не удаляется.

🛠 Часть 2. Для программиста

Состав объекта и логика работы. Конфигурация ЗУП для Казахстана 3.1, релиз 3.1.2.24.

Структура объекта

Тип объекта — документ. Нумерация: тип номера String, длина 11, периодичность Nonperiodical (сквозная, не сбрасывается по году). В шапке 16 реквизитов, 2 табличные части; BSL-модули и формы в выгрузке отсутствуют (bsl_static=[], forms=[]).

Реквизиты шапки

Табличные части

ТЧ Сотрудники — основной результат сбора: список работников и планируемые периоды отпусков.

ТЧ ДополнительныеРеквизиты — стандартный механизм доп. реквизитов (подсистема «Свойства» БСП).

Движения по регистрам

По данным карты (metadata.register_records пуст) документ не делает движений ни по одному регистру. Проведение меняет только флаги и поле Состояние в самом документе — никаких записей в регистры расчёта, накопления или сведений не создаётся.

Как формируется проведение — реальный код (3.1.2.24)

На уровне метаданных ни у одного реквизита нет fill_value_required: ShowError — платформенная проверка заполнения не назначена ни для одного поля. Все проверки — исключительно прикладные (в модуле объекта, который в выгрузке отсутствует).

// Реконструкция по metadata. НЕ цитата кода.
// Документ не является регистратором ни одного регистра (register_records=[]).
// Проведение управляет только состоянием самого документа.

Процедура ОбработкаПроведения(Отказ, РежимПроведения)

    // 1. Управление флагами жизненного цикла:
    //    СборЗапущен / СборЗавершен / СборАннулирован
    //    и перечислением Состояние (EnumRef.СостоянияСбораГрафиковОтпусков).
    //    Конкретные переходы состояний — в модуле объекта (в выгрузке нет).

    // 2. При аннулировании:
    //    СборАннулирован  = Истина;
    //    ДатаАннулирования = ТекущаяДатаВремя();
    //    ОтветственныйЗаАннулирование = ТекущийПользователь();

    // 3. Движений по регистрам НЕТ — Движения.Записать() не вызывается
    //    (register_records пуст).

КонецПроцедуры

Зависимости

BSL-зависимости в выгрузке не определены. Структурно объект связан:

🔗 Связанные разделы

• График отпусков — хаб раздела «Отсутствия»; утверждённый график, который строится на основе собранных данных.
• Отпуск — документ фактического предоставления отпуска с начислением оплаты, ОПВ, ИПН, ВОСМС и пр.