Проверка данных, документов и базы в 1С: все способы

Слово «проверка» в 1С означает совсем разные вещи. Бухгалтер проверяет, правильно ли заполнены реквизиты и сошёлся ли учёт. Администратор проверяет целостность базы и права пользователей. Разработчик проверяет конфигурацию перед обновлением и замеряет производительность. Инструмент под каждую из этих задач свой.

Ниже — конкретно: что проверяем, каким механизмом 1С 8.3 это делается и где он лежит в меню. Все пути даны для интерфейса «Такси» и типовых конфигураций на управляемых формах.

Контроль заполнения реквизитов при вводе

Самая массовая проверка в 1С срабатывает автоматически — при записи и проведении документа. Если обязательный реквизит не заполнен, программа не даст сохранить документ и подсветит проблемное поле красным, а внизу формы покажет список незаполненных полей.

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

• 🔴 поле помечено как обязательное в конфигураторе (свойство «Проверка заполнения» = «Выдавать ошибку») — пустое значение блокирует запись;
• 🟡 разработчик добавил собственное условие в обработчик ОбработкаПроверкиЗаполнения — например, «дата оплаты не может быть раньше даты счёта».

Для пользователя это выглядит так: нажали «Провести и закрыть», получили сообщение Поле "Контрагент" не заполнено и курсор прыгнул на нужную строку. Исправили — провели.

Отдельно стоит контроль формата: номер счёта, ИНН, КПП проверяются на длину и допустимые символы прямо в поле. Неверный ИНН контрагента подсветится ещё до записи — это тоже штатная проверка, заложенная в тип данных реквизита.

Проверка полноты и корректности документов пачкой

Когда нужно проверить не один документ, а весь массив за период, точечный ввод не подходит. Здесь работают групповые инструменты.

Групповое перепроведение документов . Путь в «1С:Бухгалтерии» — Операции → Групповое перепроведение документов. Обработка заново проводит все документы выбранного периода в хронологическом порядке. Те, что не проходят проверку заполнения или дают ошибку проведения, попадают в отчёт с текстом ошибки — остаётся открыть каждый и исправить.

Экспресс-проверка ведения учёта. Путь в «1С:Бухгалтерии» — Отчёты → Анализ учёта → Экспресс-проверка. Это не технический, а учётный контроль: соответствие остатков, корректность счетов-фактур, последовательность НДС, правильность закрытия месяца. По каждому пункту программа говорит, сошлось или нет, и даёт расшифровку.

Какую из проверок запускать под конкретную задачу — в таблице:

Проверка целостности информационной базы

Это уже техническая проверка — на уровне платформы, а не учёта. Она ищет не ошибки бухгалтера, а повреждения в структуре данных: битые ссылки, рассинхронизацию итогов, нарушения в таблицах.

Основной инструмент — «Тестирование и исправление информационной базы». Запускается из конфигуратора: Администрирование → Тестирование и исправление. Набор проверок задаётся галочками:

1. Проверка логической целостности — ищет противоречия в структуре данных.
2. Проверка ссылочной целостности — находит «битые» ссылки на удалённые объекты.
3. Пересчёт итогов — восстанавливает сводные данные регистров.
4. Реструктуризация таблиц информационной базы.
5. Реиндексация таблиц.
6. Сжатие таблиц информационной базы (для файлового варианта).

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

Порядок проверок имеет значение. Если база открывается, но ведёт себя странно, начинают с лёгкого: сначала пересчёт итогов и реиндексация — они быстрые и безопасные. Реструктуризацию и исправление ссылочной целостности включают, только когда первые проверки не помогли: реструктуризация физически перестраивает таблицы и на большой базе идёт долго. Для серверной базы на уровне СУБД отдельно проверяют и обслуживают сами таблицы средствами сервера баз данных — это задача администратора, а не бухгалтера.

Для файловой базы есть ещё утилита chdbfl.exe — она проверяет физическую целостность файла 1Cv8.1CD. Лежит утилита в каталоге bin установленной платформы (например, C:\Program Files\1cv8\<номер>\bin\chdbfl.exe). Запускают её при закрытой базе, указывают путь к файлу .1CD и ставят галку «Исправлять обнаруженные ошибки». chdbfl помогает, когда база вообще не открывается из-за повреждения файла — там, где тестирование из конфигуратора уже не запустить.

Проверка конфигурации перед обновлением

Отдельная задача — убедиться, что конфигурация в порядке, прежде чем накатывать обновление или новый релиз. Здесь помогают встроенные в конфигуратор средства.

Проверка конфигурации. Путь — Конфигурация → Проверка конфигурации. Набор флажков позволяет проверить:

• синтаксический контроль модулей — компилирует весь встроенный код и показывает ошибки в окне сообщений;
• проверку логической целостности конфигурации;
• поиск некорректных ссылок между объектами метаданных.

Синтаксический контроль стоит гонять после любой доработки: он ловит опечатки в именах процедур и переменных ещё до того, как они всплывут у пользователя. Отдельно пригодится команда Поиск ссылок на объект в контекстном меню объекта метаданных — она показывает, где по конфигурации используется реквизит или справочник. Это проверка перед тем, как что-то удалять: если на объект ещё есть ссылки, удаление сломает код.

Сравнение и объединение конфигураций . Перед обновлением типовой конфигурации, в которую вносились доработки, через Конфигурация → Поддержка → Сравнить, объединить с конфигурацией из файла видно, какие объекты меняет поставщик и не затронут ли они ваши изменения. Это не даёт обновлению «затереть» доработки молча.

Автоматизированное тестирование в режиме «Предприятие»

Ручная проверка форм и отчётов после каждого обновления отнимает часы. Платформа умеет прогонять сценарии автоматически — в режиме «1С:Предприятие».

Базовый механизм — сценарное тестирование. 1С 8.3 работает в связке «менеджер тестирования» и «клиент тестирования»: один сеанс воспроизводит записанные действия пользователя (открыть документ, заполнить, провести), второй фиксирует результат. Запись сценария ведётся из конфигуратора, воспроизведение — в «Предприятии».

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

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

Проверка прав доступа и ролевой модели

Когда пользователь жалуется «не вижу документ» или «нет кнопки», проверяют не базу, а права. Разбор идёт с двух сторон.

Со стороны пользователя. Путь — Администрирование → Настройки пользователей и прав → Пользователи. В карточке пользователя видно, в какие группы доступа он входит, а каждая группа опирается на профиль с набором ролей. Отсюда понятно, какие роли реально назначены.

Со стороны ограничений на уровне записей (RLS). Даже при наличии роли пользователь может не видеть конкретные данные — например, документы чужой организации или склада. Это настраивается в группах доступа через значения доступа (организации, склады, контрагенты). Если роль есть, а данных не видно — почти всегда дело в RLS.

Чтобы быстро свести права к симптому, воспользуйтесь разбором:

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

Диагностика производительности и анализ журнала

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

Журнал регистрации фиксирует события: входы и выходы пользователей, проведение документов, ошибки, изменения настроек. Открыть его можно в «Предприятии» через Главное меню → Все функции → Стандартные → Журнал регистрации (если команда «Все функции» не отображается, включите её в Главное меню → Сервис → Параметры). В конфигураторе журнал доступен из меню Администрирование → Журнал регистрации. Фильтры по пользователю, периоду, важности события и типу данных помогают найти нужную запись в большом логе.

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

Часть «торможений» в учётной базе лечится не кодом, а обслуживанием. Если отчёты по остаткам и оборотам стали считаться заметно дольше, проверьте границу рассчитанных итогов: форма Главное меню → Все функции → Стандартные → Управление итогами показывает, до какого периода итоги регистров рассчитаны. Когда граница сильно отстаёт от текущей даты, система добирает данные «на лету» и замедляется — помогает установка актуального периода и пересчёт итогов. Это безопасная регулярная процедура, в отличие от тестирования и исправления.

Технологический журнал — инструмент уже для серверных баз и глубокой диагностики. Он настраивается файлом logcfg.xml в каталоге conf платформы и пишет подробную трассировку: долгие запросы, взаимоблокировки, ошибки СУБД. Его включают точечно, под конкретную проблему, потому что он создаёт большой объём данных.

Перед большими техническими проверками пройдитесь по короткому списку — он убережёт от потери данных и лишних сеансов:

Частые вопросы