01
Решение о доступе с объяснимой причиной
Клиент открывает короткоживущий QR-пропуск в приложении. Контроллер или киоск передаёт подписанный запрос в facility access API. Система проверяет credential, филиал, зону, статус абонемента, доступное время, ограничения и anti-passback. Ответ содержит решение и код причины для сотрудника.
Каждая попытка записывается как неизменяемое событие. Успешный вход открывает визит, выход закрывает его. Ручной пропуск требует права сотрудника и сохраняет обоснование. Инцидент можно связать с устройством, клиентом и конкретным событием, а затем передать ответственному.
- динамический QR с коротким сроком жизни;
- карта, браслет или внешний credential через адаптер;
- правила по филиалу, зоне и времени;
- anti-passback и контроль открытого визита;
- ручной доступ с обязательным аудитом.
02
Работа с контроллерами и потерей связи
ProGym отделяет бизнес-правила доступа от протокола конкретного производителя. Адаптер переводит команды контроллера в канонические запросы платформы. Это позволяет подключать разные СКУД по филиалам и сохранять одинаковую модель зон, credentials, событий и состояния устройств.
Для offline-режима контроллер получает ограниченный набор разрешений с версией и сроком действия. После восстановления связи события отправляются пакетно с идемпотентным ключом. Конфликт не скрывается: система формирует инцидент для сверки. Устройство имеет собственный секрет, который можно заменить без смены всех клиентских пропусков.
03
Ресепшен и присутствие в клубе
На экране ресепшена видны ожидаемые занятия, последние входы, открытые визиты, очередь и причины отказов. Администратор быстро находит клиента, проверяет долг или ограничение и выполняет разрешённое действие. Киоск после периода бездействия очищает персональные данные и возвращается в закрытый режим.
Руководитель получает статистику по часам, зонам, направлениям и типам членства. Данные о посещениях участвуют в сегментах удержания, загрузке расписания и расчёте востребованности услуг. Журнал доступа остаётся отдельным источником правды и связывается с CRM через идентификаторы клиента и визита.
- кто сейчас находится внутри;
- последние входы и отказы;
- здоровье устройств и очередь команд;
- инциденты и действия сотрудников;
- сверка посещения с записью на занятие.
04
Виртуальный стенд для приёмки до монтажа
Команда клуба может проверить правила прохода прямо в рабочем месте ProGym до подключения турникета. Отдельное sandbox-устройство имитирует вход и выход, принимает выбранный credential, показывает решение, причину отказа, offline-режим и состояние присутствия. Сценарий подходит для демонстрации заказчику, обучения ресепшена и приёмки бизнес-правил на тестовых клиентах.
Стенд работает в изолированном контуре. Тестовый запуск не создаёт боевой визит, событие доступа или инцидент, не списывает посещение и не меняет дату последнего использования пропуска. Журнал приёмки хранит автора, время, входные данные, результат и идемпотентный ключ. Руководитель получает воспроизводимый протокол, а живая аналитика клуба сохраняет чистые показатели.
После успешной проверки тех же правил команда подключает адаптер конкретного контроллера и проводит полевые испытания. Виртуальный стенд подтверждает логику членства, зон, времени и anti-passback. Физический тест отдельно подтверждает обмен с оборудованием, реле, датчики двери, сетевой режим и доставку накопленных событий.
- разрешённый и запрещённый проход по тестовым клиентам;
- вход, выход, offline и контроль присутствия;
- отдельный журнал приёмки с причиной решения;
- безопасный повтор запроса по идемпотентному ключу;
- полная изоляция от боевых визитов и аналитики.
05
Что потребуется от клуба
Для подключения нужны модель контроллера, описание протокола или SDK, схема точек прохода, сетевые ограничения и политика offline-доступа. На стенде проверяются вход, выход, повторный скан, просроченный QR, заблокированный абонемент, потеря сети и повторная отправка событий.
Интеграция получает статус готовности после испытаний на конкретном оборудовании. До этого модуль работает в FIELD-режиме с безопасным отказом. Такой подход защищает клуб от ситуации, когда интерфейс показывает успешный проход, а физический контроллер не выполнил команду.