# Какие данные HR должен видеть при согласовании отпуска

- Канонический адрес: https://qrgate.az/ru/blog/dannye-dlya-soglasovaniya-otpuska
- Markdown: https://qrgate.az/ru/blog/dannye-dlya-soglasovaniya-otpuska.md
- Язык: ru
- Дата: 2026-07-20

Приходит заявка на отпуск. Перед HR - диапазон дат и фамилия. Для нажатия кнопки «согласовать» этого мало: кто ещё из команды отсутствует на той неделе, как проходили прежние заявки этого сотрудника, попадают ли даты на праздники? **Система согласования отпуска** - вопрос не технический, а информационный: что человек, принимающий решение, должен видеть на одном экране. В этой статье мы разбираем именно такой список; расчёты по трудовому законодательству сюда сознательно не входят.

## Контекст, нужный до согласования

Согласование выглядит как один клик, но за ним стоят четыре вопроса:

- **Есть ли покрытие?** Сколько человек уже в отпуске на эти даты?
- **Позволяет ли график?** В сменной команде - какая смена останется неполной?
- **На что попадают даты?** Праздники, отчётный период, сезонный пик?
- **Что говорит история?** Сколько дней использовано в этом году?

Когда ответы лежат в четырёх разных местах, согласование затягивается - а чаще эти вопросы просто не задаются. Последствие проявляется через неделю: трое отсутствуют в один день.

## Тип и диапазон дат

Не все отсутствия одинаковы, и различие напрямую влияет на решение о согласовании.

| Тип | Планируется? | Главный вопрос при согласовании |
| --- | --- | --- |
| Ежегодный отпуск | Да | Покрытие и график |
| Отпуск без содержания | Обычно да | Длительность и повторяемость |
| Больничный | Нет | Документ и срок |
| Короткий отгул | Отчасти | Покрытие в этот день |

Если тип не виден, всё попадает в один список и планирование становится невозможным. Поэтому тип должен быть первым полем заявки, а не комментарием, добавленным позже.

## Ожидает, согласовано, отклонено: зачем нужен статус

Самая упускаемая деталь: **заявка на согласовании - это тоже данные**.

Типичная последовательность: двое просят одну и ту же неделю, одному согласовали, второй остался в состоянии «посмотрим позже». При построении графика вторая заявка не учитывается, потому что не попадает ни в один список.

Раздельное хранение трёх статусов служит трём разным задачам:

1. **Ожидает** - для планирования: на этих датах есть риск.
2. **Согласовано** - для графика и табеля: эти дни уже заняты.
3. **Отклонено** - для истории: кто, когда и почему отказал.

Последний слой чаще всего игнорируют - и именно он нужен, как только возникает разногласие.

## Фильтры по сотруднику и по датам

Данные об отпусках читаются с двух сторон, и обе нужны.

**Срез по сотруднику** отвечает на индивидуальный вопрос: сколько использовано в этом году, когда человек отсутствовал, какие были типы. Обычно он нужен перед разговором.

**Срез по датам** отвечает на организационный вопрос: кого не будет в июле, где образуется провал. Он нужен при построении графика.

В таблице первый срез удобен, а второй мучителен: каждая заявка - отдельная строка, а диапазоны накладываются. В системе оба - просто два взгляда на одни данные. Общая логика описана на странице [что такое система учёта посещаемости](https://qrgate.az/ru/chto-takoe-sistema-ucheta-poseshchaemosti).

## Отчётность и выгрузка

Данные об отпусках покидают систему в трёх случаях: в бухгалтерию, в архив и к проверяющему.

Практическое правило то же, что и в других разделах: **Excel - если будут работать, PDF - если будут читать**. Важен источник: выгрузка должна быть копией, а не оригиналом. Иначе по компании начинают ходить три разных списка отпусков за один месяц.

Как устроен такой отчёт, описано на странице [отчёт по посещаемости](https://qrgate.az/ru/otchet-po-poseshchaemosti).

## Практический пример

В маркетинговом агентстве на 70 человек заявки на отпуск приходили по почте. HR переносил их в таблицу, устно согласовывал с руководителем отдела и отправлял подтверждение ответным письмом.

Процесс работал - до июля. В том месяце трое из пяти сотрудников одного отдела ушли в отпуск на одной неделе. Никто не ошибся: заявки приходили в разное время, и никто ни разу не видел их рядом.

После того как заявки со статусами собрали в одном месте, ситуация не повторилась. Но полезнее оказался другой результат: HR впервые увидел картину отпусков на три месяца вперёд и вовремя начал строить график. О совместном ведении графика и посещаемости - на странице [график и посещаемость вместе](https://qrgate.az/ru/grafik-i-poseshchaemost-vmeste).

## Критерий решения

Три вопроса: куда приходят заявки; где видны заявки на согласовании; можете ли вы сегодня сказать, кто будет в отпуске в июле?

Если ответ на третий - «надо проверить», отпусками по-прежнему управляют постфактум: процесс построен на реакции, а не на планировании.

## У кого полномочия согласовывать

Больше всего согласование затягивает не техника: когда неясно, кто решает, заявка просто ждёт.

Рабочая модель двухуровневая. Первый уровень - непосредственный руководитель: он ближе всего к вопросу покрытия. Второй - HR, который проверяет баланс и соответствие правилам.

Одноуровневая модель работает в небольшой компании, но с ростом команды HR становится узким местом для всех заявок.

## Как давать отказ

Это самая чувствительная и наименее продуманная часть процесса.

Отказ требует двух вещей: причины и альтернативы. Без причины он воспринимается как произвол, даже когда решение полностью обоснованно.

Альтернатива продолжает процесс: «в эти даты нельзя, но в конце той недели можно» работает, а простое «нет» его останавливает.

Отказы стоит сохранять письменно - и для истории, и чтобы тот же вопрос не возвращался без изменений.

## Путь поступления заявки

Качество согласования часто зависит от первого шага - от того, как заявка попадает в работу.

У почты три недостатка: заявка не попадает в список, статус не виден, поиск затруднён. В переписке ещё хуже: через неделю найти её практически невозможно.

Польза единой формы не в бюрократии, а в *полноте*: тип, диапазон дат и причина заполнены сразу, и согласующему не нужно ничего уточнять.

## Подготовка к сезонной нагрузке

Заявки на отпуск распределяются в течение года неравномерно: летние месяцы и период вокруг праздников всегда дают пик.

Практическое решение - открывать окно подачи заранее: например, собирать летний план весной.

Это облегчает согласование, потому что заявки видны рядом друг с другом, а проблема покрытия решается за несколько месяцев до её появления.

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

## Следующий шаг

Посчитайте заявки этого месяца: сколько из них видны в одном списке, а сколько остались в почте?

QRGate хранит заявки на отпуск и отгул вместе со статусами внутри контекста посещаемости. [Посмотреть возможности QRGate](https://qrgate.az/ru/preimushestva) или [рассчитать стоимость](https://qrgate.az/ru).

## Часто задаваемые вопросы

### На какие четыре вопроса нужно ответить до согласования?

Есть ли покрытие на эти даты, позволяет ли график, попадают ли даты на праздники или отчётный период и сколько дней уже использовано в этом году.

### Зачем хранить отклонённые заявки?

Ради истории. При разногласии появляется письменный ответ на вопрос «кто, когда и почему отказал» - слой, которым чаще всего пренебрегают и который нужнее всего.

### Сколькими способами нужно смотреть данные об отпусках?

Двумя: по сотруднику (сколько использовано в этом году) и по датам (кого не будет в июле). Первый нужен перед разговором, второй - при построении графика.

### У кого должно быть право согласования?

Обычно работают два этапа: непосредственный руководитель смотрит на нагрузку, HR - на остаток дней и документы. Одноэтапная модель быстрее в небольшой команде, но в крупной структуре начинает давать противоречия. Важно не количество этапов, а письменно зафиксированная зона ответственности.

## Связанные страницы

- Система учёта посещаемости - [Markdown](https://qrgate.az/ru/chto-takoe-sistema-ucheta-poseshchaemosti.md) | [HTML](https://qrgate.az/ru/chto-takoe-sistema-ucheta-poseshchaemosti)
- Учёт без оборудования - [Markdown](https://qrgate.az/ru/uchet-poseshchaemosti-bez-oborudovaniya.md) | [HTML](https://qrgate.az/ru/uchet-poseshchaemosti-bez-oborudovaniya)
- Анализ показателей - [Markdown](https://qrgate.az/ru/analiz-pokazateley-poseshchaemosti.md) | [HTML](https://qrgate.az/ru/analiz-pokazateley-poseshchaemosti)
- Системы регистрации часов - [Markdown](https://qrgate.az/ru/sistemy-registracii-rabochih-chasov.md) | [HTML](https://qrgate.az/ru/sistemy-registracii-rabochih-chasov)
- Контроль посещаемости - [Markdown](https://qrgate.az/ru/kontrol-poseshchaemosti-sotrudnikov.md) | [HTML](https://qrgate.az/ru/kontrol-poseshchaemosti-sotrudnikov)
- Управление отпусками и отгулами - [Markdown](https://qrgate.az/ru/upravlenie-otpuskami-i-otgulami.md) | [HTML](https://qrgate.az/ru/upravlenie-otpuskami-i-otgulami)