Аренда спецтехники: смена, моточасы и простой в учёте

Диспетчер записал одну смену, оператор передал показания счётчика, а клиент назвал другое количество часов работы. Все три записи могут описывать один выезд и при этом отвечать на разные вопросы. Если программа складывает их в общее поле «часы», итог становится непроверяемым. Для заказной системы аренды спецтехники сначала нужно развести календарный план, фактические события и основание расчёта.

Ниже предложена модель операционного учёта, которую можно обсудить перед разработкой CRM. Она не устанавливает отраслевую норму длительности смены, правила оплаты простоя или юридический порядок приёмки. Условия берут из согласованного заказа. Счётчик и отметка времени помогают проверить события, но сами по себе не определяют сумму, которую должен оплатить клиент.

Четыре разных вопроса вместо одной колонки

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

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

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

Начните с карточки условий конкретного заказа

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

Если условия меняются во время исполнения, нужен отдельный след изменения. Перезаписанный тариф задним числом не объясняет, почему итог отличается от предварительного. Сохраните прежнюю версию, новое соглашение и момент, с которого его применяют. Финансовую и юридическую сторону такого согласования определяют участники; программа должна позволять восстановить основание выбранного варианта.

Не смешивайте несколько единиц в одной формуле без явного перехода. Смена, календарный час и единица показаний счётчика — разные величины. Даже если в одном учебном примере их числа совпали, это не делает их взаимозаменяемыми. Проверяемый расчёт содержит единицу каждого входа и правило использования именно для этого заказа.

Учебный выезд: почему разница показаний не равна времени визита

Возьмём вымышленный пример без денежных тарифов. Работа на объекте отмечена с 09:00 до 16:00, то есть календарный интервал составляет семь часов. Показания условного счётчика изменились с 1250 до 1255,5: разница равна 5,5 единицы этого счётчика. Между 12:00 и 13:00 зарегистрировано ожидание. Эти сведения нельзя сложить в 13,5 часа или автоматически вычесть одно из другого.

Календарный интервал и показания могут описывать пересекающиеся периоды разными способами. Запись ожидания тоже не становится автоматически дополнительной единицей к оплате. Для учебного заказа нужно отдельно задать правило расчёта, а затем проверить его на этих исходных сведениях. Если правила нет, корректный итог программы — «нужно согласование», а не произвольная сумма.

Для такой таблицы полезен самостоятельный экран сверки. Сотрудник видит исходные данные рядом с применённым правилом, а не ищет их в нескольких переписках. Если часть сведений спорная, выделите её до окончательного подтверждения. Отдельная очередь разногласий лучше, чем общая зелёная отметка «выезд закрыт» у записи с неизвестным основанием суммы.

Простой — событие с причиной, а не готовая надбавка

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

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

Решение о расчёте храните отдельно от причины. Даже понятное описание задержки не устанавливает автоматически, кто за неё платит. Это помогает не менять фактическую историю ради удобного итога: спор можно согласовать, сохранив первоначально зарегистрированные события. В карточке остаются и сведения выезда, и принятое по ним решение.

При замене техники не продолжайте чужой счётчик

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

Сохраняйте интервалы участия каждой единицы техники и причину замены. Если они пересекаются, это нужно показать для проверки, а не автоматически считать дублированием или дополнительной работой. На месте могли происходить разные действия. Их смысл выясняет ответственный сотрудник; приложение помогает собрать достаточные сведения и отметить несогласованный участок.

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

Как принимать расчётный модуль на демонстрации

Подготовьте набор учебных случаев: обычный выезд, неполные показания, повторная отметка ожидания, замена машины и изменение условий. Для каждого заранее укажите ожидаемое поведение. Не во всех случаях ответом должна быть сумма. Иногда правильный результат — запрет подтверждения до уточнения конкретного поля с указанием ответственного.

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

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