Как исправить критические ошибки учета в 1С?

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

Подход одинаковый для 1С:Бухгалтерии 3.0, ЗУП 3.1 и УТ 11 на платформе 8.3: механизмы диагностики общие, они входят в платформу и библиотеку стандартных подсистем. Различаются только учётные проверки, о них — отдельный раздел.

Диагностика ошибки 1С через журнал регистрации

Журнал регистрации — первое место, куда стоит смотреть. Туда платформа пишет каждое исключение с текстом, пользователем, компьютером и объектом, на котором оно произошло.

Где открыть:

• в пользовательском режиме: Администрирование → Обслуживание → Журнал регистрации;
• в Конфигураторе: Администрирование → Журнал регистрации.

Как отфильтровать то, что важно

1. Нажмите Установить отбор.
2. Ограничьте интервал: час до и после того, как пользователь увидел сбой.
3. В поле важности оставьте только Ошибка (и при необходимости Предупреждение).
4. Укажите пользователя, у которого возникла ошибка.
5. Откройте запись двойным щелчком: в комментарии будет полный текст исключения, в поле «Данные» — ссылка на документ или справочник.

💡 Ищите первую ошибку в цепочке. Двадцать одинаковых записей подряд обычно следствие одной исходной, которая случилась на минуту раньше.

Что читать в тексте ошибки

Если журнал пуст или обрывается, проверьте его настройки: Конфигуратор → Администрирование → Настройка журнала регистрации. Там задаётся уровень записи и можно сократить журнал — но сокращение удаляет историю, делайте его после разбора.

Блокировки и монопольный режим: почему база «занята»

Ошибки блокировок бывают двух видов, и лечатся они по-разному.

Ошибки транзакционных блокировок

Тексты Конфликт блокировок при выполнении транзакции и Превышено максимальное время ожидания предоставления блокировки означают, что два пользователя или фоновое задание одновременно меняют одни данные. Типичные сценарии:

• 📦 закрытие месяца запущено, пока бухгалтеры проводят документы;
• 🔄 регламентный обмен с другой базой совпал с массовым перепроведением;
• 🧾 два кассира одновременно пробивают чеки по одной номенклатуре на старой конфигурации с автоматическими блокировками.

Что делать:

1. Посмотрите, кто работает: Администрирование → Обслуживание → Активные пользователи.
2. Найдите длительную операцию (фоновое задание, обработку, закрытие периода ) и дождитесь её окончания.
3. Тяжёлые операции разведите по времени: обмены и пересчёты — ночью, закрытие месяца — в окно, когда никто не проводит документы.
4. Если конфликт повторяется каждый день в одном месте — включите технологический журнал с событиями TLOCK и TTIMEOUT (см. ниже) и смотрите, какие таблицы конфликтуют.

Не удаётся установить монопольный режим

Монопольный доступ нужен для обновления структуры базы, загрузки .dt, тестирования и исправления. Обычная работа в Конфигураторе его не требует. Если монопольный режим не ставится, в базе остались сеансы.

Порядок действий:

1. Предупредите пользователей и задайте блокировку: Администрирование → Обслуживание → Блокировка работы пользователей. Укажите время начала и сообщение. Задайте код разрешения — с ним вы сами войдёте в заблокированную базу (параметр запуска /UC<код>).
2. Подождите, пока сеансы завершатся сами.
3. В клиент-серверном варианте зависшие сеансы видны в консоли администрирования серверов 1С в узле базы → Сеансы. Отсюда их можно завершить.
4. В файловой базе проверьте, не открыта ли она на другом компьютере или в фоне. Иногда сеанс держит процесс 1cv8.exe, оставшийся после сбоя, — его видно в диспетчере задач.

Битые ссылки и удалённые объекты в базе

Битая ссылка появляется, когда документ ссылается на элемент справочника, которого в базе уже нет. В форме вместо названия видно <Объект не найден> и внутренний идентификатор. Причины:

• 🗑️ объект удалили напрямую, минуя контроль ссылок;
• 🔁 данные пришли по обмену без связанных справочников;
• 💥 база повреждена после аварийного отключения.

Как найти и поправить вручную

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

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

Это штатный инструмент Конфигуратора: Администрирование → Тестирование и исправление. Требует монопольного режима.

Для битых ссылок есть три варианта действия:

• Создавать объекты — платформа создаст элементы-заглушки, ссылки станут рабочими, а заглушки потом заполняют или заменяют;
• Очищать ссылки — поле станет пустым, документ придётся заполнять заново;
• Не изменять — только отчёт.

💡 Для учётных данных безопаснее «Создавать объекты»: связь не теряется, а заглушку легко найти и заменить правильным элементом через поиск и удаление дублей.

Для файловой базы, которая не открывается вовсе, есть утилита chdbfl.exe в каталоге bin установленной платформы. Она проверяет файл 1Cv8.1CD при закрытой базе и умеет исправлять обнаруженные ошибки.

Удаление помеченных объектов

Элементы, помеченные на удаление, физически удаляет обработка из группы «Корректировка данных» в разделе Администрирование → Обслуживание. Она удаляет только то, на что никто не ссылается, и показывает, что мешает удалению. Не обходите этот контроль — именно так и появляются битые ссылки.

Ошибки после обновления конфигурации и расширений

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

Сбой на этапе Конфигуратора

• Сообщение о том, что конфигурация базы данных не соответствует сохранённой конфигурации, значит: изменения не применены. Выполните Конфигурация → Обновить конфигурацию базы данных (F7) в монопольном режиме.
• Если обновление прервалось на реструктуризации, не запускайте его повторно до разбора: сначала проверьте наличие резервной копии, затем повторите F7. При повторной ошибке — восстановление из копии.
• Проверьте версию платформы: каждый релиз конфигурации требует платформу с номером не ниже указанного в описании релиза.

Сбой обработчиков обновления

После входа программа показывает экран обновления версии. Если там ошибка:

1. Откройте журнал регистрации с отбором по событию обновления информационной базы — там точный текст и обработчик.
2. Частая причина — расширение, которое не совместимо с новым релизом.
3. Отключите расширения и повторите вход.

Проблемы с расширениями

Расширения конфигурации (появились в 8.3.6) встраиваются поверх типовой. После обновления они перестают применяться, если в типовой изменился объект, который расширение заимствует.

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

Права доступа: в 1С и на уровне СУБД

Ошибки прав в программе

Текст Нарушение прав доступа! или Недостаточно прав для... значит, что роли пользователя не разрешают операцию.

1. Откройте Администрирование → Настройки пользователей и прав → Пользователи, затем карточку пользователя.
2. Посмотрите, в какие группы доступа он входит, и сравните с коллегой, у которого всё работает.
3. Профили (наборы ролей) настраиваются в разделе Профили групп доступа, ограничения по организациям и складам — в самих группах доступа.
4. Не выдавайте «Полные права» ради одной операции: найдите профиль, где нужная роль уже есть.

После изменения прав пользователь должен перезайти в программу.

Права СУБД и службы сервера

В клиент-серверной базе ошибка может прийти от SQL-сервера. Признак — в тексте есть Ошибка СУБД и сообщение драйвера Microsoft SQL Server или PostgreSQL про отказ в разрешении (permission denied).

Что проверить:

• 🔑 у пользователя СУБД, указанного в свойствах базы в кластере, есть права владельца базы (db_owner в MS SQL, владелец базы в PostgreSQL);
• 🔑 для создания новой базы нужны права на создание баз данных на сервере;
• 📁 учётная запись службы агента сервера 1С (по умолчанию USR1CV8) имеет доступ на запись к каталогу кластера srvinfo и к каталогу логов;
• 🔐 пароль пользователя СУБД не истёк и не менялся без правки в свойствах базы.

Технологический журнал и дампы памяти

Когда журнал регистрации не объясняет причину — падает клиент, сервер перезапускает рабочий процесс, запрос «висит» — включают технологический журнал. Это текстовые логи платформы с подробностями до уровня запросов к СУБД.

Настройка — файл logcfg.xml в каталоге conf установленной платформы (например, C:\Program Files\1cv8\conf\). Пример, который собирает исключения, ожидания на блокировках и дампы:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\1c_techlog" history="24">
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <event>
      <eq property="name" value="TTIMEOUT"/>
    </event>
    <event>
      <eq property="name" value="TDEADLOCK"/>
    </event>
    <property name="all"/>
  </log>
  <dump create="1" location="D:\1c_dumps"/>
</config>

• history="24" — хранить логи 24 часа;
• EXCP — исключения, TTIMEOUT — таймауты блокировок, TDEADLOCK — взаимоблокировки;
• для анализа долгих запросов добавляют событие DBMSSQL или DBPOSTGRS с отбором по длительности.

Дамп (.mdmp) — снимок памяти процесса при аварийном завершении. Сами вы его не разберёте, но он нужен разработчику конфигурации или в обращение по ошибке платформы. Вместе с дампом передают точную версию платформы и событие из техжурнала на момент падения.

Если ошибка на одном компьютере

Сбой только у одного пользователя часто лечится очисткой кэша клиента. Закройте 1С и удалите папки с GUID-именами в %APPDATA%\1C\1cv8 и %LOCALAPPDATA%\1C\1cv8, либо запустите программу с параметром /ClearCache. Список баз и настройки не пострадают.

Учётные ошибки: остатки, закрытие месяца, проводки

Не каждая «ошибка учёта» — технический сбой. Красное сальдо, неверная себестоимость, расхождение НДС — это данные, а не поломка базы.

Порядок разбора:

1. Найдите самую раннюю дату, с которой цифры расходятся: ошибка в марте ломает все месяцы после него.
2. Откройте документы за эту дату и проверьте движения (кнопка просмотра проводок и движений в форме документа).
3. Исправьте документ и перепроведите период последовательно, затем повторите закрытие месяца.
4. Если меняется закрытый отчётный период — сначала снимите или перенесите дату запрета изменения: Администрирование → Проведение документов.

💡 Если пересчёт итогов в «Тестировании и исправлении» убрал расхождение — проблема была технической. Если нет — ищите неверный документ.

Профилактика и регулярное обслуживание базы

Большинство критических ошибок предсказуемы. Регламент обслуживания закрывает их до того, как бухгалтер их увидит.

Ещё три привычки:

• ⏰ тяжёлые регламентные задания (обмены, пересчёты) — ночью и не одновременно;
• 🔌 файловая база — на сервере с ИБП, не на компьютере сотрудника;
• 📏 при росте файловой базы и числа пользователей — переход на клиент-серверный вариант, где блокировки управляемые и мельче.

Частые вопросы об ошибках 1С