Как создать приложение для учёта отпусков: заявки, согласования и баланс

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

Что нужно приложению

Данные

Главное правило: никогда не храните баланс, который редактируете вручную. Баланс равен норме + перенос + корректировки − одобренные дни. У каждого изменения есть запись с причиной, поэтому на вопрос «почему у меня осталось 3,5 дня?» можно показать ответ.

Страницы

• Сотрудник: мой баланс по каждому виду отпуска, форма заявки, мои заявки со статусами, календарь моей команды.
• Руководитель: заявки на рассмотрении рядом с календарём команды, одобрение или отклонение с комментарием, балансы команды.
• HR/администратор: сотрудники, виды отпусков, нормы, праздничные дни, корректировки, отчёты и экспорт.

Права доступа

Это персональные данные, и часть из них чувствительна. Сотрудники видят свои заявки, а в общем календаре команды — только то, что коллега «отсутствует», но не причину. Руководители видят своих прямых подчинённых. HR видит всех. Больничный и другие чувствительные виды отпуска должны показываться как «отсутствует» всем, кроме самого сотрудника, его руководителя и HR. Соблюдайте это на сервере; см. ролевой доступ. Правила защиты персональных данных сотрудников различаются по странам, поэтому проверьте свои.

Решения и компромиссы

Дни или часы

Учёт в днях (с половинками) проще и подходит большинству офисных команд. Учёт в часах удобен для сотрудников с неполной занятостью и для сменного графика, но все расчёты становятся сложнее. Для первой версии выберите один вариант, исходя из того, как ваши договоры описывают нормы.

Норма сразу или начисление

Выдать всю годовую норму в первый день учётного года — самый простой вариант. Начисление, при котором сотрудник получает часть дней каждый месяц, распространено в некоторых странах и для новичков, и оно требует ежемесячного расчёта. Пропорциональный расчёт для тех, кто приходит или уходит в середине года, всё равно понадобится.

Какие дни считаются

Заявка с четверга по вторник должна учитывать только рабочие дни, исключая выходные и праздничные дни по локации этого сотрудника, с учётом неполного графика. Именно этот расчёт чаще всего ошибочен, поэтому проверяйте его на реальных примерах.

Цепочка согласования

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

Перенос и конец года

Решите, каков ваш учётный год, сколько неиспользованных дней переносится и сгорают ли перенесённые дни. Попросите ИИ показывать перенос отдельной строкой, чтобы баланс оставался объяснимым.

Пример первого запроса

Создай внутреннее приложение для учёта отпусков для компании на 45 человек с офисами в Манчестере (Великобритания) и Дублине (Ирландия). Виды отпусков: ежегодный (25 дней, весь год сразу, до 5 дней переносится, сгорает 31 марта), больничный (без лимита, без согласования, виден другим только как «отсутствует»), без сохранения и другой. Учётный год с января по декабрь. Сотрудники подают заявку с датой начала, датой окончания и необязательными половинками дней и видят, сколько рабочих дней она займёт, без выходных, выходных дней неполной занятости и праздников их офиса. Баланс считается по нормам, переносу, корректировкам и одобренным заявкам, никогда не редактируется напрямую. Руководители одобряют или отклоняют заявки подчинённых с комментарием, видя при этом календарь команды. HR управляет сотрудниками, видами отпусков, нормами, праздничными днями и корректировками с причиной и экспортирует одобренный отпуск по месяцам в CSV для зарплаты. Роли: сотрудник, руководитель, HR. Всё храним в базе данных. Простой и быстрый интерфейс.

Шаги сборки

1. Начните с письменной политики. Если её нет на бумаге, сначала запишите её — приложение может применять только правила, которые вы можете сформулировать.
2. Импортируйте сотрудников с руководителем, локацией и графиком, обычно из таблицы. См. как превратить таблицу в приложение.
3. Виды отпусков, нормы и праздничные дни.
4. Форма заявки с расчётом рабочих дней, проверенная минимум на десяти реальных случаях: через выходные, государственный праздник, сотрудник с неполной занятостью, половина дня, переход через границу года.
5. Согласование и календарь команды.
6. Вход и роли, с чувствительными видами отпуска, скрытыми от коллег.
7. Уведомления: письмо руководителю о новой заявке и сотруднику о решении через ваш почтовый провайдер. См. как отправлять письма из приложения.
8. Отчёты и экспорт для зарплаты.
9. Параллельная работа с таблицей в течение месяца: сравните балансы и только потом переходите.

Частые ошибки

• Хранение числа баланса с ручным редактированием. Вы теряете историю, и каждый спор превращается в гадание.
• Подсчёт календарных дней вместо рабочих или игнорирование офиса сотрудника при учёте праздников.
• Показ всем причины отсутствия коллеги. На общем календаре достаточно пометки «отсутствует».
• Нет резервного согласующего. Заявки висят две недели, пока руководитель в отпуске.
• Разрешение отменять одобренный отпуск без ведома руководителя. Об отмене должен узнавать согласующий.
• Жёстко заданные правила текущего года. Храните нормы и праздники как данные, которые HR сможет изменить в следующем году.

Когда лучше готовый продукт

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

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

Создание с Mythex

В Mythex вы описываете политику и процесс в чате, а агент собирает приложение в живом превью; база данных Postgres добавляется, когда заявки нужно сохранять. Вы можете пригласить коллег в ваше рабочее пространство Mythex, чтобы вместе собрать и проверить приложение, и показать превью двум-трём реальным пользователям до публикации — кейс внутреннего инструмента в документации предлагает именно это. Вход сотрудников и письма с уведомлениями используют ваших провайдеров; встроенного входа для конечных пользователей и отправки писем в Mythex нет. Используйте режим Plan, чтобы согласовать расчёт баланса до написания кода, и /test, чтобы пройти сценарии заявки и согласования.

Для стартового запроса попробуйте шаблоны трекер согласований или корпоративный справочник.

Вопросы