Рассмотрим достаточно распространенную задачу: нам необходимо создать механизм учета рабочего времени сотрудников в конфигурации, разрабатываемой "с нуля". Главное условие — нам не требуется сложный расчет заработной платы и начислений, нужна исключительно фиксация информации об отработанных часах по дням (например: явка — 8 часов, выходной — 0 часов). Разберем по шагам, какую архитектуру объектов метаданных выбрать, как автоматизировать процесс и какие элементы интерфейса использовать для визуализации.
Поскольку сложный расчет зарплаты нам не нужен, мы сразу отказываемся от громоздких планов видов расчета и регистров расчета, которые применяются в типовых зарплатных решениях. Проанализируем оптимальный набор объектов для нашей задачи.
Сотрудники и ВидыРабочегоВремени. В последнем будут храниться элементы, определяющие характер времени: явка, ночные часы, выходной, больничный, отгул и так далее.ПроизводственныйКалендарь. Это позволит автоматически предзаполнять документы (например, подтягивать 8 часов в будние дни и 0 в выходные), оставляя пользователю лишь корректировку отклонений.ГрафикиРаботы. В нем мы будем задавать плановое время или норму. В качестве измерений используем Сотрудник (или График) и Дата, а в качестве ресурса — КоличествоПлановыхЧасов.ЛистУчетаВремени или ЕжедневнаяОтметка. В его табличной части мы будем указывать сотрудника, вид времени и количество фактически отработанных часов (либо точное время начала и окончания работы).ОтработанноеВремя. Измерениями выступят Сотрудник и ВидВремени, а ресурсом — Часы. Оборотный регистр идеально подходит для этой задачи: он позволит нам моментально строить отчеты (за неделю, месяц, год) без сложных и тяжелых запросов к табличным частям документов.Посмотрим на пример простого кода обработки проведения нашего документа в модуле объекта:
Процедура ОбработкаПроведения(Отказ, Режим)
Движения.ОтработанноеВремя.Записывать = Истина;
Движения.ОтработанноеВремя.Очистить();
Для Каждого ТекущаяСтрока Из ОтработанныеЧасы Цикл
Движение = Движения.ОтработанноеВремя.Добавить();
Движение.Период = Дата;
Движение.Сотрудник = ТекущаяСтрока.Сотрудник;
Движение.ВидВремени = ТекущаяСтрока.ВидВремени;
Движение.Часы = ТекущаяСтрока.КоличествоЧасов;
КонецЦикла;
КонецПроцедуры
Даже в самой простой конфигурации настоятельно рекомендуем сразу заложить возможность дробного учета времени. Установите тип данных для ресурса Часы как число с точностью до 2 или 3 знаков (например, длина 10, точность 2). Использование строго целочисленных значений быстро приведет к погрешностям в отчетах. Например, 8.5 часов будут означать 8 часов 30 минут. Если сотрудники будут задерживаться или уходить раньше на 15–20 минут, десятичные дроби позволят учесть это максимально корректно.
Чтобы избавить пользователей от ручного вбивания часов (особенно при большом штате), мы можем автоматизировать заполнение документов.
РегламентныеЗадания. На основе этих данных система будет автоматически рассчитывать фактически отработанное время и формировать документы, при необходимости вычитая время обеденных перерывов.Для удобной работы руководителя или табельщика простой список документов не всегда подходит. Выясним, какие инструменты интерфейса платформы мы можем задействовать.
Планировщик. Элемент формы Планировщик отлично справляется с задачей наглядного распределения смен. Мы можем программно выводить в него элементы, показывая расписание каждого сотрудника на день или неделю.
Диаграмма Ганта. Если нам важна детализация до минут и анализ пересечений смен, используем объект ДиаграммаГанта. На ней очень наглядно отображаются периоды работы, перерывы и отклонения. Руководитель сразу увидит, если в графике образовались "дыры" или рабочие часы разных сотрудников дублируют друг друга.
Сводная таблица (Табель). Самый классический подход — создать отчет или обработку на базе объекта ТабличныйДокумент. Мы формируем матрицу: по вертикали располагаем список сотрудников, по горизонтали — дни выбранного месяца. В ячейках выводим количество отработанных часов. Дополнительно можно настроить расшифровку: при двойном клике на ячейку открывать детализацию (например, "с 09:00 до 12:00, с 13:00 до 18:00").
Если мы учитываем время не просто общим количеством часов за день, а фиксируем время начала и окончания работы, нам потребуется алгоритм контроля пересечений. Рассмотрим ситуацию: в один и тот же день для сотрудника введен документ явки (с 09:00 до 18:00) и документ отгула (с 14:00 до 16:00).
Чтобы избежать логических ошибок, при записи документа нам необходимо делать запрос к регистру графиков или регистру отработанного времени, проверяя, не попадают ли новые временные рамки в уже зарегистрированные интервалы. Для этого в запросе используются условия сравнения дат начала и окончания вводимого периода с уже существующими в базе записями по конкретному сотруднику.
Применив описанную архитектуру, мы получим легкую, быструю и масштабируемую подсистему учета рабочего времени, которая не перегружена лишней логикой расчетов, но при этом предоставляет исчерпывающую информацию для руководства.