Skip to content

Журнал аудита

Полная история изменений критичных данных — кто, что, когда и почему изменил. Хранится 7+ лет для соответствия ISO 9001 и ГОСТ.

Как открыть

Боковое меню → АналитикаАудит

Зачем нужен аудит

Журнал аудита (AuditTrail) дополняет стандартную историю изменений бизнес-контекстом: почему изменение произведено, кем одобрено, какой заявкой инициировано. Это необходимо для:

  • Compliance — сертификация ISO 9001, внутренний аудит
  • Расследования — кто изменил маршрут партии и почему
  • Контроль — отслеживание несанкционированных изменений

APPEND-ONLY

Записи аудита никогда не изменяются и не удаляются. Это гарантия неизменяемости — даже администратор не может «подчистить» историю.

Что на экране

Таблица записей аудита

СтолбецОписаниеПример
Дата/времяКогда произошло изменение20.03.2026 14:32:15
ПользовательКто внёс изменение (ФИО)Иванов А.П.
ТаблицаКакая сущность измененаbatches
ЗаписьUUID изменённой записи3f2a...8c1b
ОперацияТип измененияINSERT / UPDATE / DELETE
Изменённые поляСписок полейstatus, priority
ПричинаБизнес-обоснование«Перенос на альтернативное РМ по рекомендации»
ОдобрилКто одобрил (если требовалось)Петров С.В.

Фильтры

ФильтрВарианты
ПериодСегодня / Неделя / Месяц / Произвольный
ПользовательВсе / конкретный пользователь
ТаблицаВсе / batches / production_orders / equipment / ...
ОперацияВсе / INSERT / UPDATE / DELETE
ПоискПо UUID записи, имени пользователя, причине

Типы операций

ОперацияКодОписание
СозданиеINSERTНовая запись добавлена в систему
ИзменениеUPDATEОдно или несколько полей изменены
УдалениеDELETEЗапись удалена (мягкое удаление через SoftDelete)

Детали записи аудита

При клике на строку открывается детальная карточка:

Что изменилось

ПолеОписание
Старые значенияJSON с предыдущими значениями полей
Новые значенияJSON с новыми значениями полей
Изменённые поляСписок имён полей, которые реально изменились

Пример для UPDATE:

ПолеБылоСтало
statusin_progresscompleted
actual_end_timeNULL2026-03-20 14:30:00
completed_quantity048

Контекст изменения

ПолеОписание
Бизнес-причинаТекстовое обоснование (обязательно для критичных операций)
ОдобрившийПользователь, если изменение требовало одобрения
ЗаявкаUUID заявки на изменение (если применимо)
IP-адресС какого адреса выполнено
User-AgentБраузер/приложение
Transaction IDPostgreSQL txid для группировки связанных изменений

Критичные операции

Для изменения маршрутных карт, нормативов и настроек оборудования бизнес-причина обязательна. Система не позволит сохранить изменение без заполнения поля «Причина».

Какие таблицы аудируются

МодульТаблицыЧто важно
Производство (M4)batches, workplaces, buffersСмена статуса партии, перемещения
Планирование (M3)production_orders, schedulesИзменение дедлайнов, приоритетов
Технология (M2)route_cards, operations, bomИзменение маршрутов и спецификаций
Качество (M6)defect_records, inspectionsРегистрация дефектов, результаты проверок
Оборудование (M4)equipment, maintenance_recordsСмена состояния, записи ТО
Нормативы (M7)norms, norm_historyКорректировка нормативов
Персонал (M5)employees, employee_skillsИзменение допусков и навыков

Группировка по транзакции

Одно действие пользователя может изменить несколько таблиц. Все записи аудита в рамках одной транзакции имеют общий txid (PostgreSQL transaction ID).

Пример: мастер перенаправляет партию на другое РМ:

txidТаблицаОперацияЧто изменилось
48291batchesUPDATEworkplace_id: WP-03 → WP-07
48291buffersUPDATEcurrent_count: 15 → 14 (исходный)
48291buffersUPDATEcurrent_count: 8 → 9 (целевой)
48291master_decisionsINSERTdecision_type: alternative_workplace

Поиск по пользователю

Для расследования инцидентов используйте фильтр «Пользователь» + «Период»:

  1. Выберите пользователя из выпадающего списка
  2. Укажите период (например, «Последние 24 часа»)
  3. Система покажет все действия этого пользователя в хронологическом порядке
  4. Отфильтруйте по таблице, если нужны только определённые изменения

Денормализация ФИО

Имя пользователя хранится прямо в записи аудита (поле changed_by_name). Даже если пользователь будет переименован или удалён — в аудите останется его ФИО на момент действия.

Срок хранения

ПериодХранилищеДоступ
0-90 днейГорячее (PostgreSQL)Мгновенный, полнотекстовый поиск
90 дней — 2 годаТёплое (сжатые таблицы)Поиск с задержкой
> 2 летХолодное (архив)По запросу, 24 часа на восстановление

Связанные разделы

AntRoute MES — управление блуждающими узкими местами