Журнал посещений в СКУД — это операционный отчёт и источник событий для контроля доступа. Его состав, сроки хранения и экспорт зависят от контроллера и программной платформы; перед закупкой проверьте эти параметры по выбранной модели. В этой статье — разбор функциональности журнала и критерии выбора СКУД.
Что должен фиксировать журнал СКУД
Базовый набор событий для коммерческой системы контроля доступа:
- Успешный проход: дата, время, точка прохода, идентификатор (номер карты / имя сотрудника), направление (вход/выход)
- Отказ в доступе: дата, время, точка, идентификатор, причина (неизвестная карта / вне временного профиля / карта заблокирована)
- Тревожные события: взлом двери (дверь открыта без карты), удержание двери открытой более N секунд, попытка прохода по заблокированной карте
- Системные события: потеря питания, разрыв связи с контроллером, перезагрузка
- Действия администратора: добавление и удаление пользователей, изменение расписаний — аудит действий для безопасности
Расширенные возможности журнала для B2B
| Функция | Применение | Нужна для |
|---|---|---|
| Фото при проходе | IP-считыватель с камерой или домофон фиксирует фото при проходе, если функция предусмотрена моделью | Объекты с высокими требованиями безопасности |
| Отчёт присутствия (T&A) | Система рассчитывает время на объекте по первому входу и последнему выходу, если функция доступна | Учёт рабочего времени, HR |
| Антипасбэк | Контроллер запрещает повторный вход без выхода, если функция включена в модели | Режимные объекты, парковки |
| Кросс-зонный контроль | Система ограничивает одновременное нахождение в зонах, если функция предусмотрена | Крупные объекты с множеством точек |
| Экспорт в Excel/CSV | Выгрузка за период, если функция предусмотрена контроллером или ПО | Объекты с отчётностью |
| API для интеграции | Передача событий через доступный интерфейс или API, если это предусмотрено моделью | Корпоративная интеграция |
Доступ к журналу: что проверить до заказа
Способ просмотра журнала и управления правами зависит от контроллера и программной платформы. До заказа проверьте доступные роли, формат отчётов, сроки хранения и порядок резервного копирования:
- Способ просмотра журнала и отчётов определяется контроллером и программной платформой
- Количество операторов, уровни доступа и возможность удалённой работы подтверждаются по модели
- Разграничение доступа по ролям, зонам и событиям проверяется до заказа
- Экспорт и автоматические отчёты доступны только при наличии соответствующей функции модели
- Уведомления о тревожных событиях и интеграции подтверждаются по модели
Журнал может использоваться как внутренний источник данных при разборе инцидентов или учёте рабочего времени. Юридическая сила, срок хранения, защита от редактирования и требования к временным меткам зависят от объекта, договора и применимых правил. Ответственная сторона определяет эти требования. До заказа проверьте роли, резервное копирование, срок хранения и экспорт по выбранной модели.
Интеграция журнала СКУД с HR и учётом рабочего времени
Один из типовых сценариев для коммерческих объектов — передача данных о первом входе и последнем выходе в HR-систему для автоматического табелирования:
- Синхронизация сотрудников: база сотрудников из HR-системы → СКУД (через API или CSV-импорт). Единый источник данных
- Сбор событий: СКУД фиксирует входы/выходы → накапливает журнал
- Экспорт в HR: по расписанию, если это поддерживается платформой, — передача событий за день через доступный интерфейс в HR-систему
- Табелирование: HR-система рассчитывает фактическое рабочее время, переработки и опоздания, если функция предусмотрена
Политика хранения и доступа к журналу
Журнал посещений имеет ценность только тогда, когда понятно, какие события он фиксирует и кто может их выгружать. До заказа согласуйте период хранения, формат времени, часовой пояс, резервное копирование и роли пользователей. Объём памяти и срок хранения зависят от контроллера и программной платформы, поэтому их подтверждают по конкретной конфигурации.
- Разделить права на просмотр, экспорт, изменение настроек и удаление данных.
- Определить, как помечаются проходы сотрудника, гостя, подрядчика и администратора.
- Проверить, что в событии видны точка прохода, идентификатор, дата и время.
- Зафиксировать резервное копирование и порядок восстановления журнала.
- Проверить экспорт в согласованный формат до передачи объекта.
Приёмка отчётов на объекте
Для пилота достаточно одной двери и небольшой группы пользователей. Создайте несколько разрешённых и запрещённых сценариев, выгрузите отчёт, измените роль и повторите проверку. Если СКУД передаёт события в систему учёта рабочего времени, сопоставьте идентификатор сотрудника, время и смену на тестовых данных. Интеграцию с конкретной версией ПО нужно подтверждать отдельно.
В итоговом акте укажите модель контроллера, версию программы, политику хранения, формат отчёта и ограничения. Это снижает риск, что при расширении объекта заказчик получит другой набор событий или другой порядок доступа.
Роли пользователей и экспорт данных
До выбора платформы опишите, кому нужен журнал: охране — оперативный просмотр, HR — отчёт по сменам, руководителю — сводка, администратору — настройка. Эти роли могут требовать разных прав и форматов выгрузки. Проверьте, можно ли получить данные за период, отфильтровать точку прохода и сохранить исходный файл без ручного копирования.
Если планируется интеграция с учётом рабочего времени, зафиксируйте идентификатор сотрудника и правило округления времени. Не принимайте интеграцию по названию программы: проверяйте экспорт или API на той версии контроллера и ПО, которая будет на объекте. При отсутствии подтверждения опишите обмен как отдельный этап проекта.
Что передать заказчику
В комплект передачи включите реестр устройств, роли пользователей, правила хранения, форму отчёта и контакт администратора. Проверьте, что заказчик может самостоятельно выгрузить журнал и восстановить доступ после замены сотрудника. Непроверенная инструкция превращает исправную систему в источник повторных обращений.
Срок хранения и формат отчёта закрепляйте до закупки. Если заказчику нужен архив за длительный период, проверьте не только память контроллера, но и резервное хранение на сервере.
Если журнал используется для спорных ситуаций, синхронизация времени и неизменность выгрузки должны быть отдельным пунктом приёмки. Не ограничивайтесь демонстрацией одного успешного прохода.
После проверки сохраните пример отчёта и акт с версией системы. При обновлении платформы его можно использовать как контрольный образец для повторной приёмки.
Контрольный пример снижает риск спорной трактовки отчёта.
При расширении объекта сохраните контрольный набор событий для нескольких ролей и точек прохода. После изменения настроек повторите тот же тест и сравните отчёты с исходным образцом. Так журнал остаётся проверяемым, а не только формально включённым в состав системы.
FAQ — часто задаваемые вопросы
Срок хранения и объём журнала зависят от памяти контроллера, интенсивности событий и программной платформы. Перед заказом подтвердите фактические ограничения выбранной модели, резервное копирование и требуемый срок хранения для объекта.
Формат экспорта журнала, фильтры и интеграции зависят от выбранного контроллера и программной платформы; проверяем их до заказа.
Антипасбэк — логика, запрещающая дважды «войти» без «выхода». Если сотрудник передал карту коллеге, второй войдёт, но карта заблокируется до момента фиксации выхода первого. Нужен на режимных объектах, парковках с поштучным учётом мест, в зонах с ограниченным числом одновременных посетителей.
Уведомления и интеграции с внешними сервисами доступны только при подтверждённой функции выбранной модели; состав событий и получателей фиксируем в проекте.
МЗК — 200 единиц (считыватели + контроллеры в комбинации). Состав ПО и функции управления журналом определяются выбранной моделью. Пришлите параметры объекта — рассчитаем конфигурацию и условия. Ответим за 24 часа.