ПРИЁМКА МНОГОРЕСУРСНОЙ ЗАПИСИ
Запись на несколько ресурсов: сотрудник, помещение и оборудование
Свободный специалист ещё не означает доступную услугу. Для фотосессии нужны фотограф, студия и комплект света; для мастерской — сотрудник, пост и оборудование. Ошибка появляется, когда календарь проверяет один ресурс, а клиенту обещает весь комплект. Ниже — спецификация многоресурсной записи: как описать зависимости, учесть разные интервалы занятости и проверить конфликтующие запросы до запуска.
Начните с состава одной услуги
Выберите конкретный вариант услуги и перечислите обязательные ресурсы. Формулировка «фотограф и студия» недостаточна: нужно указать допустимую квалификацию, филиал, тип помещения, оборудование и число единиц. Если клиент выбирает конкретного специалиста, это ограничение нельзя незаметно заменить любым доступным сотрудником.
Различайте два отношения. «И» означает, что нужны все элементы одновременно: фотограф, помещение и свет. «Или» означает выбор одной подходящей альтернативы: студия А либо студия Б. Список из двух комнат не должен случайно означать одновременный резерв обеих. И наоборот, список «комната, проектор» нельзя интерпретировать как выбор чего-то одного.
В Dynamics 365 Field Service группы требований используют варианты All и Any для таких сочетаний; подбор ищет ресурсы для совместного назначения. Документация также содержит ограничения конкретной реализации, включая одинаковую длительность требований внутри группы и отсутствие многодневного планирования таких групп. Microsoft Learn. Это пример модели, а не универсальное описание всех календарей.
Данный материал предназначен для настройки и приёмки записи. Вопрос, когда бизнесу добавлять время и людей, требует отдельного анализа спроса и расходов.
Опишите интервалы каждого ресурса
Храните клиентское начало и окончание отдельно от занятости ресурсов. Комната может требовать 15 минут уборки после визита. Оборудование — 10 минут подготовки до начала и 10 минут проверки после. Сотруднику может понадобиться иной интервал. Общий буфер на всю запись способен одновременно недооценивать один ресурс и излишне блокировать другой.
Для каждого ресурса интервал резерва начинается раньше клиентского визита на его подготовку и заканчивается позже на его завершение. Доступность проверяют на всём этом интервале. При точном совпадении конца предыдущего резерва с началом следующего конфликт отсутствует, только если необходимая передача уже включена в буферы. Это правило границы нужно одинаково применять во всех каналах.
Не путайте буфер с технологическим ожиданием внутри услуги. Square, например, описывает processing time как паузу, во время которой специалист может принять другую запись; длительность визита складывается из начального этапа, ожидания и завершения. Square: Processing time. Для вашей услуги отдельно проверьте, остаются ли занятыми помещение и оборудование во время такого ожидания.
Поля, без которых модель неоднозначна
В справочнике услуги и записи потребуются:
- Версия варианта услуги и клиентская длительность
- Группы обязательных ресурсов и допустимых альтернатив
- Количество единиц каждого ресурса и допустимая совместная вместимость
- Требования к сотруднику, филиалу и совместимости оборудования
- Подготовка, активное использование и завершение по каждому ресурсу
- Рабочие интервалы, перерывы, обслуживание и временная недоступность
- Идентификаторы выбранных ресурсов, часовой пояс и абсолютное время записи
- Состояние резерва, срок временного удержания, если оно используется
- Версия записи, источник изменения, сотрудник и причина исключения
Вместимость помещения и количество оборудования — разные ограничения. Комната на шесть человек не обеспечивает шесть отдельных комплектов. Общий ресурс между филиалами требует явного расположения и времени перемещения. Не создавайте две независимые карточки одного физического прибора: календарь может принять их за два доступных экземпляра.
Названия функций сами по себе недостаточны. В Square при назначении сервису нескольких альтернативных ресурсов бронируется один из списка. Square: Resource management. Поэтому запрос «нужны три типа ресурса одновременно» нужно проверять на фактической модели выбранного продукта.
Учебный пример: три фотосессии вместо десяти
У студии два подходящих фотографа, две одинаковые комнаты и один комплект света. Все ресурсы доступны с 09:00 до 14:00, без перерывов. Сессия длится 60 минут; фотограф занят только во время неё. Комната требует ещё 15 минут после, комплект света — 10 минут до и 10 минут после. Все данные условные, спрос и выручка не прогнозируются.
Расчёт только по людям даёт 2 × 300 / 60 = 10 человеко-слотов. Это не десять возможных фотосессий: общий свет занят по 80 минут на каждую. Допустимая последовательность клиентских стартов — 09:10, 10:30 и 11:50.
Для первого визита свет резервируется с 09:00 до 10:20, клиент занимается с 09:10 до 10:10, комната освобождается в 10:25. Второй использует свет с 10:20 до 11:40 и другую комнату с 10:30 до 11:45. Третий использует свет с 11:40 до 13:00; его клиентский интервал — 11:50–12:50, комната занята до 13:05.
Все три назначения выполнимы, например при чередовании комнат; доступность фотографов также достаточна. Четвёртый последовательный старт в 13:10 потребовал бы свет до 14:20, за пределами его доступности. Верхняя оценка по комплекту равна целой части 300 / 80 = 3, и показанное расписание подтверждает достижимость трёх записей при принятых условиях.
Это доказательство для данного набора интервалов. При другом расположении перерывов даже три записи могут не поместиться. Деление общего времени на длительность не заменяет проверку конкретных резервов.
Что должно произойти при двух одновременных запросах
Рассмотрите двух клиентов, которые увидели один и тот же свободный комплект. Оба отправляют запись почти одновременно. Проверка доступности только при открытии страницы недостаточна: к моменту подтверждения другой запрос мог уже занять ресурс.
Критерий приёмки — повторная проверка при фиксации и один согласованный результат по всему набору. Либо получены все обязательные ресурсы, либо запись не считается подтверждённой, а временные частичные резервы освобождаются по установленному правилу. Технический способ реализации выбирает разработчик; бизнес проверяет наблюдаемое поведение и отсутствие двух обещаний на один эксклюзивный ресурс.
Повторная отправка одного запроса после потери ответа также не должна создавать второй визит. Сначала система или оператор находит результат исходного запроса по его идентификатору. Клиент получает понятное состояние ожидания или предложение другого времени, а не неподтверждённое сообщение об успешной записи.
Перенос и поломка требуют проверки всего комплекта
При переносе недостаточно перетащить блок сотрудника. Новое время должно подходить комнате, оборудованию и всем буферам. Если оно не подходит, исходная подтверждённая запись должна оставаться понятной и действующей до согласованного изменения. Не оставляйте клиента с освобождённым старым временем и неполученным новым.
При поломке оборудования найдите все затронутые резервы, включая подготовку и завершение. Назначьте ответственного за замену или согласование переноса. Замена подходит только при совпадении необходимых характеристик и доступности. Для оплаченных визитов денежная часть остаётся отдельной: общий порядок рассмотрен в статье о записи, предоплате и доступности.
Чек-лист многоресурсной приёмки
- Свободен сотрудник, занята комната: клиентское подтверждение не возникает.
- Есть две комнаты-альтернативы: резервируется ровно одна подходящая.
- Есть комната, отсутствует обязательное оборудование: услуга недоступна.
- Клиентские интервалы не пересекаются, буферы оборудования пересекаются: конфликт выявлен.
- Два запроса приходят одновременно: эксклюзивный комплект получает только один визит.
- Повторён исходный запрос: второй визит и лишние резервы не создаются.
- Перенос невозможен по одному ресурсу: исходная запись не теряется.
- Отмена освобождает все связанные резервы, включая буферы, без лишних действий с деньгами.
- Техническое обслуживание пересекает только подготовку: зависимая запись всё равно обнаружена.
- Изменён норматив новой услуги: ранее подтверждённые записи не переписаны незаметно.
Зафиксируйте для каждого теста исходные календари, запрос, ожидаемые резервы и фактический результат. Проверьте онлайн-форму и ручную запись администратора: обход правил в одном канале разрушает общий календарь.
В SABSUS используйте страницы записи и календаря сотрудников как отправную точку демонстрации. Многоресурсные ограничения, отдельные буферы и обработка одновременных запросов в этой статье — требования к проверке вашей конфигурации, а не обещание готовой реализации.
Частые вопросы
Достаточно ли указать оборудование в комментарии?
Комментарий помогает сотруднику, но не доказывает резерв. Проверка должна видеть конкретный ресурс, интервал и конфликт с другими записями.
Можно ли назначить второго клиента во время ожидания первого?
Только если модель освобождает нужного сотрудника и второй услуге хватает остальных ресурсов. Помещение первого клиента может оставаться занятым всё время.
Какой размер буфера правильный?
Его определяют по реальной подготовке и завершению конкретной услуги. Проверьте наблюдения и отклонения; универсальный процент от длительности не гарантирует выполнимость расписания.
Источники
- Microsoft Learn: Requirement groups — обязательные и альтернативные сочетания ресурсов.
- Square: Resource management — резерв ресурса вместе с услугой и выбор альтернативы.
- Square: Processing time — технологическое ожидание внутри визита.
Источники проверены 9 октября 2026 года. Пример расписания учебный.