01
От черновика до действующей редакции
Ответственный сотрудник создаёт документ в статусе черновика, задаёт понятное название, текст, номер редакции и область действия. Правило можно применить ко всей сети или выбранным филиалам. Пока документ остаётся черновиком, клиентское приложение и киоск его не показывают. Команда спокойно проводит юридическую и операционную проверку до публикации.
Публикация фиксирует конкретное содержимое и его серверный отпечаток. Новая формулировка выпускается следующей редакцией, поэтому уже собранные подтверждения остаются связаны с тем текстом, который видел человек. Сотрудник может снять документ с публикации. История редакций и действий сохраняется для разбора спорных ситуаций и внутреннего контроля.
- черновик, публикация и снятие с публикации;
- отдельный номер каждой редакции;
- обязательные и информационные документы;
- область действия по филиалам;
- серверный SHA-256 для точной привязки текста.
02
Один документ для приложения, киоска и ресепшена
Клиентский кабинет загружает действующие документы для выбранного профиля. Человек раскрывает полный текст, видит номер редакции и подтверждает его отдельным действием. После успешного ответа интерфейс показывает дату и статус. Для семьи родитель работает с конкретным профилем ребёнка в рамках разрешённой связи, поэтому подтверждение не прикрепляется к случайной карточке.
Киоск получает список обязательных документов через короткоживущий токен взаимодействия. Текст, название и версия приходят с сервера. В исходном коде киоска нет постоянной заглушки, которую можно случайно выдать за реальный документ. Если клуб публикует несколько обязательных правил, киоск проводит посетителя по ним последовательно и передаёт идентификатор каждой редакции.
На ресепшене сотрудник видит тот же статус, но действует в рамках своих прав. Он может помочь клиенту открыть документ или проверить наличие подтверждения. Создание и публикация доступны только назначенным ролям. Отзыв сотрудником требует причины и остаётся отдельным событием, а исходное подтверждение продолжает существовать в истории.
03
Проверяемое доказательство вместо галочки в карточке
Запись подтверждения содержит организацию, профиль клиента, документ, редакцию, время, канал и технический контекст операции. Сервер сам берёт заголовок, версию и отпечаток из опубликованного документа. Клиентский интерфейс не может прислать произвольный текст и объявить его действующими правилами. Повторный запрос обрабатывается идемпотентно и не создаёт несколько одинаковых доказательств.
Отзыв оформляется добавлением новой записи. Система не стирает первоначальный факт и не переписывает его задним числом. В журнале видно, кто инициировал отзыв, когда это произошло и какая причина была указана сотрудником. Такой подход помогает внутренней проверке, поддержке клиента и подготовке выгрузки для уполномоченного специалиста.
Доступ к журналу ограничен организацией, ролью и назначенными разрешениями. Отчёт для руководителя может показывать количество действующих, ожидающих и отозванных подтверждений. Полные тексты и персональные данные остаются в операционном контуре. Конкретный набор документов, срок хранения и юридическая формулировка согласуются с юристом клуба и применимыми требованиями.
- привязка к опубликованному документу на сервере;
- неизменяемая история подтверждений и отзывов;
- идемпотентная обработка повторного запроса;
- разделение прав чтения, публикации и отзыва;
- агрегированная аналитика для руководителя.
04
Рабочие очереди для команды клуба
Руководитель видит документы, которые ждут согласования, приближаются к дате пересмотра или требуют новой редакции после изменения процесса. Отдельная очередь показывает клиентов без обязательного подтверждения. Фильтры по филиалу, документу и каналу помогают найти причину, а ответственному сотруднику назначается конкретное действие вместо общей цифры в отчёте.
Поддержка ищет событие по клиенту и редакции, видит разрешённый технический контекст и фиксирует результат обращения. Ошибки приложения и киоска попадают в операционный журнал с кодом причины. Команда может отличить отказ сервера от проблемы связи и не просит клиента повторять подтверждение вслепую. В сети филиалов общие документы выпускаются централизованно, а локальные правила остаются в области конкретной площадки. Каждая операция сохраняет автора и точное время.
05
Как проверить функцию на демонстрации
В интерактивном демо выберите рабочее место владельца и откройте раздел «Правила». Там видны опубликованная редакция, черновик и последние действия клиентов. Опубликуйте документ и проверьте изменение статуса. Затем смените роль на клиента, откройте тот же раздел, разверните текст и подтвердите новую редакцию.
На пилоте сценарий повторяется с тестовой организацией и реальными ролями. Команда создаёт документ для одного филиала, проверяет его отсутствие в другом, подписывает через приложение и киоск, повторяет запрос после имитации таймаута и выполняет отзыв. Приёмка завершается сверкой журнала, прав доступа и отображения на телефоне шириной 390 пикселей.
Для проверки обновления выпустите вторую редакцию с изменённым абзацем. Клиент должен увидеть новый номер и отдельное требование подтверждения, а прежняя запись должна остаться связана с первым текстом. Затем снимите новую редакцию с публикации и повторите запрос. Сервер должен отклонить операцию, даже если вкладка с документом осталась открытой у клиента.
Проверьте роли в двух организациях. Обычный сотрудник видит разрешённый ему журнал, ответственный за документы управляет черновиками, а пользователь соседнего клуба получает отказ при прямом запросе по идентификатору. Такой сценарий одновременно проверяет интерфейс, API и изоляцию данных. Результат фиксируется в протоколе пилота вместе с версией системы и датой теста.
- публикация редакции владельцем;
- отображение только в назначенном филиале;
- подтверждение в приложении и киоске;
- повтор запроса без дубля;
- отзыв с причиной и сохранением истории;
- проверка ролей и мобильного интерфейса.