Аудит изменений в справочниках ERP: цены, ЕИ и контрагенты

Зачем вообще нужен аудит справочников ERP

Когда в ERP меняют справочники без следа, проблемы проявляются не сразу. Сначала это выглядит как невинная правка: обновили цену, поправили единицу измерения, заменили реквизиты контрагента. А через неделю начинается разбор: почему маржа «поехала», откуда взялась недостача, кто согласовал отгрузку «не тому».

Без истории изменений обычно возникает три вида боли: споры между отделами (продажи уверены, что цена была одной, закупка доказывает другое), ошибки в отчетах и закрытии периода (цифры не сходятся с первичкой), а также риск злоупотреблений (условия меняют «под сделку», а затем возвращают обратно).

Справочники напрямую влияют на то, как ERP считает документы. Цена попадает в счета и накладные, единица измерения влияет на количество и себестоимость, контрагент определяет договор, НДС, лимиты и даже маршрут согласований. Одна незаметная правка способна изменить результаты продаж, закупок и бухгалтерского учета, даже если сами документы никто не редактировал.

Самые чувствительные справочники обычно такие:

• номенклатура (включая характеристики и упаковки)
• цены и скидочные условия
• единицы измерения и коэффициенты пересчета
• контрагенты и договоры
• банковские реквизиты и адреса

Простой пример: менеджер выставил счет в штуках, а позже кто-то поменял базовую единицу на упаковки. В отчете продажи «просели», на складе появились расхождения, а клиент спорит по сумме. Журнал изменений ERP в таких ситуациях отвечает на главный вопрос: что именно изменили, кто, когда и на основании чего.

Что именно нужно отслеживать: цены, ЕИ, контрагенты

В аудите изменений в справочниках ERP не стоит пытаться логировать все подряд. Лучше заранее определить поля, по которым чаще всего возникают споры, потери денег и сбои в документах.

Цены: что фиксировать, чтобы потом можно было разобраться

По ценам редко хватает записи «было 10 000, стало 9 500». Для нормального разбора нужен контекст: кто поменял, по какой логике, на что это повлияло.

Обычно имеет смысл фиксировать:

• тип цены (закупочная, розничная, оптовая, договорная)
• валюту и курс (если курс участвует в расчете)
• период действия (дата начала и окончания, признак «актуально с»)
• НДС (ставка, включен или нет)
• источник изменения (ручная правка, загрузка, пересчет по правилу)

Типичный случай: менеджер обновил цену, но не заметил, что в карточке выбран другой тип цены. В итоге в заказах пошли «не те» значения, а спор начинается с фразы «я ничего не менял».

Единицы измерения: где чаще всего ломается пересчет

С ЕИ проблемы возникают там, где есть упаковки, коэффициенты и альтернативные единицы (шт, короб, кг, м2). Важно фиксировать не только выбранную единицу, но и коэффициенты пересчета, правила округления и минимальные партии. Иначе вы увидите изменение в карточке, но не поймете, почему отгрузка стала в 10 раз больше.

Контрагенты: реквизиты, договоры и «тихие» правки

У контрагентов критичны изменения, которые влияют на оплату, налоги и юридические риски: реквизиты, договоры, банковские счета, признаки резидентства, КПП или БИН/ИИН, адреса, ответственные менеджеры.

Отдельно стоит логировать статусы и блокировки: кто и когда отключил контрагента или товар, поставил стоп-лист, запретил отгрузку или изменил признак «активен». Эти действия часто делают «на минуту», а последствия тянутся неделями.

Роли и права: кто должен иметь доступ к изменениям

Проблемы с ценами, единицами измерения и контрагентами чаще начинаются не с ошибки в ERP, а с размытых ролей. Когда «могут все» или «никто не отвечает», история изменений справочников превращается в поиск виноватых вместо быстрого разбора.

Обычно изменения делают несколько групп: закупки правят закупочные цены и условия, продажи - прайсы и скидки, бухгалтерия следит за реквизитами и налоговыми атрибутами, команда мастер-данных (если она есть) управляет структурой справочников и правилами заполнения, ИТ поддерживает доступы и технические настройки. Важно, чтобы ИТ не становилось «владельцем данных» только потому, что у них есть права.

Работает простая матрица ответственности: кто создает, кто согласует, кто только смотрит. Например, менеджер по закупкам создает запрос на изменение закупочной цены, руководитель направления согласует, а бухгалтерия и продажи видят историю и текущие значения.

Права лучше выдавать по принципу «только по роли» и «минимально необходимое». Это обычно означает меньше людей с правом правки, больше людей с правом просмотра и выгрузки отчета, и отдельное право на массовые изменения (именно оно чаще становится источником крупных ошибок).

Процесс стоит закрепить хотя бы в упрощенном виде:

• заявка на изменение (что меняем, почему, с какой даты)
• подтверждение (кто согласовал и когда)
• внесение изменения (кто выполнил)
• проверка (кто убедился, что документы не «поехали»)

Простой пример: сотрудник продаж меняет единицу измерения товара с «шт» на «уп» без согласования. В итоге в отгрузках появляются кратные ошибки, а спор начинается с вопроса «кто виноват». Если роль продаж ограничена запросом, а менять ЕИ может только НСИ после подтверждения, журнал сразу покажет цепочку: запрос, согласование, исполнение. Разбор становится быстрым и спокойным.

Какие данные должен хранить журнал изменений

Чтобы аудит изменений в справочниках ERP помогал в реальных разборах, журнал должен отвечать на три вопроса: что изменили, кто изменил и при каких обстоятельствах. Если хотя бы один из них «проваливается», спор по цене или единице измерения быстро превращается в гадание.

Во-первых, фиксируйте событие и объект. Логируйте не только изменение, но и создание, удаление, восстановление записи. Иначе вы не увидите, что контрагента сначала удалили, а потом «вернули» с другими реквизитами.

Во-вторых, нужна точная фиксация значения: какое поле меняли, что было до и что стало после. Желательно сохранять тип данных и формат (например, количество знаков после запятой), потому что округление тоже бывает причиной расхождений.

Контекст не менее важен, чем сами цифры. Минимальный набор:

• дата и время с точностью хотя бы до секунды
• пользователь (учетная запись) и роль
• рабочее место или источник (клиент, веб, интеграция)
• связанный документ-основание или операция (если есть)

Чтобы разбор был честным, добавьте причину изменения. Это может быть короткий комментарий или код причины из списка (например, «ошибка в ЕИ», «индексация», «новый договор»). Тогда в ситуации «почему цена стала другой» проще понять, это ручная правка, корректировка по договору или массовое обновление.

Пример: в карточке товара поменяли ЕИ с «шт» на «уп», и через день в заказах «вдруг» выросла сумма. Если в журнале есть старое и новое значение, пользователь, время, источник и причина, вы быстро установите, было ли это осознанное изменение, ошибка или результат загрузки.

Где хранить историю: варианты и компромиссы

Место хранения истории важно не меньше, чем сам факт фиксации. Если журнал неудобно читать или записи легко удалить, разборы превращаются в спор на словах.

Встроенные возможности ERP

Во многих ERP уже есть механизм истории или протоколирование изменений. Этого достаточно, если нужно быстро ответить на вопрос «кто и когда поменял поле» и объем изменений небольшой. Минус обычно в том, что встроенная история не всегда удобна для проверок: сложно собрать отчет по периоду, по конкретным полям, по списку номенклатуры или контрагентов. Иногда система не хранит старое и новое значение в нужном виде.

Когда встроенного механизма не хватает, добавляют отдельное хранилище, которое проще анализировать.

Отдельный журнал (таблица или регистр)

Отдельный журнал полезен, когда разборы и отчеты должны быть быстрыми и одинаковыми для всех подразделений. В него обычно кладут минимум нужных полей: объект, измененные реквизиты, старое и новое значение, пользователь, дата и время, основание (документ, задача, заявка), комментарий.

Практичный компромисс часто такой:

• встроенная история как базовый уровень (чтобы не потерять ничего)
• отдельный журнал для ключевых справочников (цены, ЕИ, контрагенты), где важна аналитика
• логи доступа и действий пользователей как подтверждение факта входа и активности

Логи доступа не заменяют журнал изменений. Они отвечают на другой вопрос: был ли пользователь в системе в это время и с какого устройства.

Срок хранения и право на удаление

Срок задают от задач контроля и требований бизнеса. Часто выбирают 1-3 года для оперативных разборов и дольше для чувствительных данных (например, по ценам для закупок). Главное правило: право удалять записи должно быть только у ограниченного круга (а лучше вообще запретить ручное удаление), а доступ на просмотр разделить по ролям. Если запись можно «подчистить», журнал перестает быть доказательством.

Как настроить журнал для разборов: пошаговый план

Чтобы журнал был рабочим инструментом, а не складом сырых событий, настройку стоит делать от реальных кейсов.

1. Зафиксируйте, что вы считаете критичным. Начните со справочников номенклатуры (цены, единицы измерения), контрагентов (ИНН/БИН, договоры, банковские реквизиты) и полей, которые влияют на документы и расчеты.

2. Согласуйте правила внесения изменений. Важно, чтобы в журнале было не только «кто и что», но и «по какой причине». Минимум - номер заявки или письма и короткий комментарий.

3. Подготовьте отчеты и фильтры: пользователь, период, объект, поле, старое значение, новое значение, основание.

4. Ограничьте доступ и настройте резервное копирование с понятным сроком хранения.

Проверка на здравый смысл: возьмите реальный кейс (например, смена ЕИ с «шт» на «упак») и убедитесь, что по журналу можно за 2 минуты восстановить цепочку: кто изменил, с какого значения на какое, в какое время, и какая была причина. Если это не получается, значит, не хватает полей в записи или неудобны отчеты.

Как проводить разбор инцидента по журналу изменений

Разбор удобнее начинать по понятным сигналам: резкий скачок цены в заказах, массовые правки в одном справочнике за короткое время, изменения в нерабочие часы. Такие триггеры стоит закрепить как повод открыть инцидент.

Быстро собрать картину по журналу

Чтобы не утонуть в деталях, соберите короткую хронологию: что изменили, когда, кем и в каком объекте. Смотрите и на новое значение, и на старое - иначе трудно понять масштаб.

Дальше проверьте, где это уже проявилось: в заказах, прайсах, документах закупки, печатных формах, интеграциях. Иногда ошибка в единице измерения не видна в карточке номенклатуры, но дает перекос в количестве или сумме в документах.

Для быстрого старта помогает одинаковый набор вопросов:

• какой объект изменен (номенклатура, цена, контрагент, договор)
• какие поля трогали (значение, валюта, ЕИ, коэффициент пересчета, ИНН)
• кто и под каким аккаунтом сделал правку
• было ли согласование (заявка, письмо, протокол) и совпадают ли детали
• какие документы уже «подхватили» новое значение

Ошибка или согласованное изменение

Ключевой тест простой: есть ли след процесса, который объясняет правку. Если изменение согласовано, в журнале обычно виден ожидаемый пользователь, понятное окно времени и «ровный» набор полей (например, обновили цену и дату начала действия).

Если это ошибка, часто видно «случайное» поле (поменяли ЕИ вместо коэффициента) или «не того» контрагента (похожее название, но другой ИНН). Важно фиксировать не только виновника, но и причину: спешка, отсутствие прав, неясная форма заявки.

Итоги разбора лучше записывать в трех частях: решение (что откатили или поправили), корректировка данных (какие документы пересчитали), профилактика (какое правило или право доступа меняем, какой отчет добавляем). Тогда следующий инцидент будет короче и дешевле.

Отчеты, которые реально помогают, а не просто собирают лог

Лог сам по себе редко спасает. Помогают отчеты, которые отвечают на конкретный вопрос и дают понятный список действий: что проверить, какие документы затронуты, с кем согласовать.

Три отчета, которые стоит сделать в первую очередь

Отчет «кто менял цены» должен быть рабочим инструментом для коммерческого отдела и закупок. В нем важны период, тип цены, номенклатура, старая и новая цена, пользователь, время, причина (хотя бы короткий комментарий). Тогда видно, где было плановое обновление прайса, а где одиночная правка без объяснения.

Отчет по единицам измерения лучше строить вокруг рисковых изменений: коэффициенты пересчета, упаковки, правила округления. Именно они приводят к «внезапным» расхождениям в отгрузке, складе и себестоимости. Хорошо, когда отчет показывает не только факт, но и потенциальный эффект: например, какие позиции используют эту единицу.

Отчет по контрагентам особенно важен для финансов: изменения реквизитов, ИИН/БИН, адресов, банковских счетов, контактных данных. Здесь ценны отметки, кто подтвердил изменение и было ли оно сделано по заявке.

Чтобы отчеты не превращались в мусор, оставьте в них только то, что помогает быстро принять решение:

• фильтр по ответственному подразделению и пользователю
• выделение критичных полей (цена, коэффициент, банковский счет)
• сравнение «было/стало» без лишних технических колонок
• признак «без причины» или «вне регламента»

Регулярный контроль: как часто и кому

Практичный режим - ежедневная короткая выборка по критичным изменениям и недельный обзор по всем правкам. В компаниях с большим каталогом ежедневный контроль цен и банковских данных помогает поймать ошибку до оплаты или отгрузки. Недельный обзор нужен, чтобы видеть повторяющиеся проблемы: один и тот же пользователь регулярно меняет коэффициенты или правит контрагентов «вручную».

Частые ошибки при внедрении аудита и как их избежать

Первая ошибка: фиксируется только новое значение. В итоге вы видите, что цена стала 12 500, но не знаете, была ли она 12 000 или 8 000.

Сразу проверьте, что журнал хранит обе стороны изменения (было и стало), плюс дату, пользователя и объект. Без этого контроль цен и единиц измерения превращается в формальность.

Вторая ошибка: включили «все подряд». Журнал разрастается, поиск становится медленным, а люди перестают им пользоваться. Лучше начать с критичных полей: цена, единица измерения, ставка НДС, ключевые реквизиты контрагента (ИНН, договор, банковские данные), и только потом расширять.

Третья ошибка: нет обязательного комментария. Если сотрудник поменял ЕИ «шт» на «уп», без пояснения вы не поймете, это исправление карточки или попытка скрыть пересчет.

Хорошее правило: запретить «тихие» правки и добавить мини-проверку перед сохранением:

• комментарий обязателен для цены, ЕИ и реквизитов контрагента
• для крупных изменений нужен второй человек на согласование
• выгрузка отчета по изменениям доступна руководителю, а не всем подряд
• права на редактирование справочников отделены от прав на просмотр журнала

Четвертая ошибка: журнал доступен слишком многим. Это риск давления на сотрудников и риск утечки чувствительных данных. Дайте доступ на просмотр узкому кругу (без права правки и очистки), а технические права отделите.

Пятая ошибка: нет бэкапов. Если база повредилась, вместе с ней пропадает и история изменений. Проверьте, что резервные копии покрывают и журнал, и что восстановление реально тестируется хотя бы раз в квартал.

Короткий чеклист: все ли готово для проверок

Перед проверкой или внутренним разбором важно убедиться, что аудит справочников настроен не «для галочки».

1. Определены справочники и поля под контролем. Обычно это номенклатура (цены, единицы измерения, коэффициенты пересчета), контрагенты (реквизиты, статус, условия), связанные классификаторы, которые влияют на расчеты и отгрузку.

2. Назначены роли. У каждого справочника есть владелец данных (отвечает за корректность) и согласующий (подтверждает изменения в рискованных полях).

3. Журнал хранит минимум для доказательного разбора:

• старое и новое значение, дата и пользователь, объект (конкретная номенклатура или контрагент)
• причина изменения для чувствительных полей
• раздельные права на правки и просмотр журнала

4. Есть 2-3 отчета, которыми реально пользуются: изменения цен за период, изменения ЕИ и коэффициентов, изменения карточек контрагентов с фильтром по пользователю и подразделению.

5. Настроены хранение и резервное копирование: срок хранения (часто нужен минимум 6-12 месяцев) и регулярная проверка восстановления.

Пример из практики: спор из-за цены и единиц измерения

В закупках заметили странность: себестоимость по одной позиции резко выросла, хотя цена по договору не менялась. Поставщик говорит, что счет выставлен правильно. Финансы считают, что «в ERP кто-то подкрутил справочник». Частый скрытый фактор в таких спорах - единица измерения.

Сценарий простой. Раньше материал учитывался как «кг», а закупали его партиями. Кто-то в карточке номенклатуры или в связке «номенклатура-поставщик» поменял единицу на «г» или на «шт», при этом коэффициент пересчета остался старым или был сбит. В документах закупки цена подтягивается «за единицу», и система честно пересчитывает суммы. В итоге в приходе и в себестоимости появляется рост, который выглядит как завышение цены.

Чтобы разобраться, в журнале ищут не «все подряд», а конкретные признаки:

• какой объект менялся (карточка номенклатуры, упаковка, единицы, прайс поставщика)
• какие поля трогали (ЕИ, коэффициенты, цена, валюта, округления)
• кто и когда это сделал (пользователь, время, рабочее место)
• было ли изменение массовым (одна карточка или десятки позиций за минуту)

Дальше влияние подтверждают по документам. Берут первый документ, где сумма стала «не той» (заказ, приход, счет, списание), и смотрят: какая ЕИ и цена подтянулись в строку, был ли пересчет количества, как изменилась сумма по сравнению с предыдущими операциями. Обычно хватает пары документов «до» и «после», чтобы посчитать разницу в деньгах и снять спор.

После подтверждения причины выбирают действия по ситуации: откатить справочник на правильные значения, исправить документы (если они уже попали в учет), коротко обучить пользователя и пересмотреть права. Часто помогает простое правило: менять ЕИ и коэффициенты могут только ответственные за НСИ, а закупки работают через заявки на изменение.

Следующие шаги: закрепить процесс и подготовить инфраструктуру

Чтобы аудит изменений не остался разовой настройкой, превратите его в понятный процесс. Начните с малого: выберите 10 самых критичных полей (обычно это цена, валюта, единица измерения, ставка НДС, контрагент и его реквизиты) и включите контроль именно по ним.

Минимум, который можно сделать за неделю:

• назначить владельца справочников (одного ответственного по каждому разделу)
• утвердить список критичных полей и правило: кто может менять, кто согласует
• включить журналирование по выбранным полям с фиксацией: кто, когда, что было, что стало
• настроить простой отчет для разборов (фильтр по периоду, пользователю, объекту)
• провести короткую тренировку на тестовом случае

Дальше оцените нагрузку: сколько правок в день, какой срок хранения нужен (3, 6, 12 месяцев), кому можно видеть историю цен и контрагентов, кто поднимает инцидент и за какое время команда должна дать ответ.

Интегратор обычно нужен, когда появляются сложные согласования (например, смена ЕИ только после подтверждения закупок и склада), требования безопасности (разные уровни доступа к истории), или когда отчеты должны быть пригодны для проверок: с выгрузками, единым форматом и понятной трассировкой.

Если вам параллельно нужно укрепить инфраструктуру под ERP (серверы, рабочие места, поддержка), это удобно делать в одном проекте. У GSE.kz, как у производителя и системного интегратора, есть опыт построения серверной инфраструктуры и организации поддержки 24/7, чтобы ERP и журнал изменений работали стабильно и предсказуемо.