Администрирование · 12 мин
Как проверить изменения в 1С: данные, конфигурацию и действия пользователей
Практические способы проверить изменения в 1С: история изменений данных, сравнение конфигураций, журнал регистрации, версионирование объектов и типичные ошибки.
Под «изменениями в 1С» обычно понимают три разные вещи: кто и когда изменил конкретный документ или элемент справочника, что поменялось в самой конфигурации после обновления или доработки, и какие действия выполняли пользователи в базе за период. Для каждой из этих задач в платформе есть свои инструменты, и выбор зависит от того, что именно нужно установить.
Если нужно разобраться, кто испортил данные, начинайте с журнала регистрации и версионирования объектов. Если требуется понять, что изменилось после обновления релиза или доработки программиста, используйте сравнение конфигураций в конфигураторе. Если важно проконтролировать массовые операции — помогут отчёты по изменённым документам и анализ журнала регистрации по типам событий.
Ниже разобраны рабочие способы проверки для каждого сценария: от встроенных механизмов платформы до типовых отчётов конфигураций. Отдельно описаны ограничения: часть инструментов нужно включать заранее, часть работает только с правами администратора, а некоторые данные восстановить задним числом невозможно.
Определите, какие именно изменения нужно проверить
Прежде чем открывать инструменты, сформулируйте задачу. От этого зависит, куда смотреть и хватит ли стандартных средств. Проверка «кто изменил цену в документе» и «что изменилось в конфигурации после обновления» решаются совершенно разными механизмами.
Основные сценарии: контроль изменений в данных (документы, справочники, регистры), анализ изменений конфигурации (после обновления, доработки, переноса из тестовой базы), аудит действий конкретного пользователя, поиск момента, когда данные стали некорректными. Для каждого сценария ниже приведён свой порядок действий.
Как выбрать инструмент
Проверка изменений данных через журнал регистрации
Журнал регистрации — основной встроенный инструмент аудита. Он фиксирует добавление, изменение и удаление объектов, проведение и отмену проведения документов, входы пользователей, ошибки и другие события. Открывается из меню «Администрирование» → «Обслуживание» → «Журнал регистрации» (в типовых конфигурациях) или из конфигуратора.
Чтобы найти нужное событие, настройте отбор: укажите период, пользователя, тип события (например, «Данные. Изменение») и, при необходимости, представление данных — конкретный документ или элемент справочника. В строке события видны дата, пользователь, компьютер и комментарий платформы с именем объекта.
Важное ограничение: журнал регистрации показывает факт изменения и его автора, но не показывает, какие именно значения реквизитов были до и после. Для такой детализации нужно версионирование объектов либо специализированные доработки. Также учтите, что при большой интенсивности работы журнал растёт быстро — настройте его сокращение, но не удаляйте его полностью, если аудит важен.
История изменений объекта и версионирование
В типовых конфигурациях (например, в линейке «Библиотека стандартных подсистем») есть механизм версионирования объектов. Если он включён, у документа или элемента справочника доступна команда «История изменений»: видно, кто, когда и какие реквизиты поменял, включая старые и новые значения. Это самый наглядный способ разобрать спорную ситуацию по конкретному объекту.
Проверьте, включено ли версионирование: «Администрирование» → «Общие настройки» → раздел версионирования объектов (название может отличаться в зависимости от конфигурации). Там же задаётся список типов объектов, для которых ведётся история, и срок хранения версий.
Ключевое ограничение: версионирование фиксирует изменения только с момента включения. Если настройку не выполнили заранее, узнать, каким был документ «вчера», штатно не получится — останутся журнал регистрации (кто менял) и резервные копии (что было на момент копии). Поэтому в базах, где критична история изменений, версионирование включают сразу при внедрении.
Как проверить изменения в конфигурации
Если вопрос в том, что поменялось в самой программе — после обновления релиза, доработки внешним специалистом или переноса изменений из тестовой базы — используется сравнение конфигураций в конфигураторе. Откройте конфигуратор, затем «Конфигурация» → «Сравнить, объединить с конфигурацией из файла» и укажите файл поставки, файл выгрузки (.cf) прежней версии или конфигурацию поставщика.
Результат сравнения показывает дерево объектов с отметками: добавленные, изменённые, удалённые объекты. Для модулей доступно построчное сравнение текстов — так видно, какие именно процедуры и строки кода изменил разработчик. Это стандартный приём при приёмке доработок: перед обновлением рабочей базы сравните новую конфигурацию с текущей и просмотрите все отличия.
Дополнительно полезно сравнить текущую конфигурацию с конфигурацией поставщика («Конфигурация» → «Сравнить с конфигурацией поставщика»): так видно, какие объекты в базе отличаются от типовых, то есть где есть доработки. Это критично перед обновлением — изменённые типовые объекты могут потребовать ручного объединения.
Контроль действий пользователей и массовых операций
Для аудита действий конкретного сотрудника откройте журнал регистрации и установите отбор по пользователю и периоду. Полезные типы событий: «Данные. Добавление», «Данные. Изменение», «Данные. Удаление», «Доступ. Доступ» и «Доступ. Отказ в доступе» (попытки открыть закрытые данные), а также события сеансов — вход и выход.
Если подозреваете массовую обработку данных (например, групповое изменение цен или перепроведение), ищите в журнале серию однотипных событий от одного пользователя за короткий интервал. В клиент-серверном варианте дополнительно помогает технологический журнал и средства СУБД, но их настройка — задача администратора.
В типовых конфигурациях также есть отчёты, косвенно показывающие изменения: «Анализ версий объектов», отчёты по проведённым и непроведённым документам, «Даты запрета изменения данных». Дата запрета редактирования сама по себе — инструмент защиты: всё, что раньше этой даты, штатно не изменить, и любые расхождения в закрытом периоде — повод для отдельной проверки.
Проверка через резервные копии и тестовую базу
Когда штатные средства не дают ответа (версионирование не было включено, журнал сокращён), остаётся сравнение с резервной копией. Разверните копию нужной даты в отдельной тестовой базе — никогда не восстанавливайте её поверх рабочей — и сравните интересующие документы или справочники вручную либо через отчёт.
Тестовая база полезна и для проверки изменений конфигурации: сначала обновите копию, проверьте работу ключевых сценариев (проведение документов, формирование отчётов, обмены), и только затем переносите изменения в рабочую среду. Это стандартная практика безопасного внедрения доработок.
При восстановлении копий учитывайте права доступа к данным: в копии базы доступны все данные на момент её создания. Ограничьте круг лиц, имеющих доступ к тестовым развёртываниям, особенно если в базе есть персональные данные и коммерческая информация.
Как проверить результат
Команда «История изменений» доступна и показывает версии с авторами и значениями реквизитов
Команды нет или история пуста — версионирование не включено для этого типа объектов
События находятся по пользователю, периоду и объекту, видны дата и автор изменения
Событий нет за заведомо «активный» период — проверьте настройки отбора или факт сокращения журнала
Дерево сравнения показывает только ожидаемые отличия (доработки, новый релиз)
Есть неожиданные изменённые или удалённые объекты — до выяснения причин обновление не выполнять
Ключевые документы проводятся, отчёты формируются, обмены работают на тестовой базе
Ошибки в модулях или при проведении — откатить изменения и разбирать доработку
Ограничения и когда нужен специалист
Часть проверок требует полных прав или прав администратора: журнал регистрации в полном объёме, настройка версионирования, конфигуратор, работа с резервными копиями. Рядовой пользователь увидит только историю изменений объекта, если она включена и ему доступна.
Граница безопасной самостоятельной работы проходит там, где начинается изменение структуры: объединение конфигураций, обновление релизов, восстановление из копий, работа с технологическим журналом и СУБД. Ошибки на этом уровне приводят к потере данных или остановке работы всей организации, поэтому такие операции выполняют с резервной копией и, при отсутствии опыта, с участием специалиста по 1С.
Что важно запомнить
Факт и автора изменения данных показывает журнал регистрации, старые и новые значения — только история версий при включённом версионировании, изменения конфигурации — сравнение в конфигураторе. Версионирование и резервные копии настраивают заранее: задним числом историю не восстановить. Любые обновления и объединения конфигураций — только после резервной копии.
Частые вопросы
Можно ли узнать, каким было значение реквизита до изменения?
Да, но только если для этого типа объектов было включено версионирование — тогда в истории изменений видны старые и новые значения. Журнал регистрации значений не хранит, он фиксирует лишь факт изменения, автора и время. Если версионирование не включалось, ориентир — резервная копия базы на нужную дату.
Как узнать, кто удалил документ?
Откройте журнал регистрации, установите отбор по событию «Данные. Удаление» и при необходимости по представлению данных (номеру документа) и периоду. В найденной записи будут указаны пользователь, время и компьютер. Если журнал за этот период был сокращён, восстановить информацию штатно не получится.
Чем сравнить две версии конфигурации?
В конфигураторе: «Конфигурация» → «Сравнить, объединить с конфигурацией из файла» — и укажите файл .cf второй версии. Для модулей доступно построчное сравнение текстов. Чтобы увидеть отличия от типового релиза, используйте «Сравнить с конфигурацией поставщика».
Почему в журнале регистрации нет событий за нужный период?
Наиболее вероятные причины: журнал был сокращён (старые события удалены), неверно настроен отбор (проверьте период, пользователя и типы событий) или у вас недостаточно прав для просмотра полного журнала. Сначала сбросьте все отборы и посмотрите самые ранние доступные записи.
Можно ли проверить изменения без прав администратора?
Частично. Обычному пользователю доступна история изменений конкретного объекта, если включено версионирование и у него есть права на объект. Журнал регистрации, настройка версионирования и сравнение конфигураций требуют административных прав.
Как проверить, что доработка программиста ничего не сломала?
Сравните новую конфигурацию с текущей рабочей в конфигураторе и просмотрите все отличия, особенно изменённые типовые объекты. Затем разверните копию базы, обновите её и прогоните ключевые сценарии: проведение основных документов, формирование регламентированных отчётов, обмены данными. Только после успешной проверки переносите изменения в рабочую базу.