При ведении учета в программе 1С:Бухгалтерия предприятия 3.0 пользователи и администраторы иногда сталкиваются со сложной и малоинформативной ошибкой при попытке изменить параметры учетной политики. Типичный сценарий: предприятие переходит с одного режима налогообложения на другой (например, с УСН «Доходы» на УСН «Доходы минус расходы» или на ОСНО) с начала нового календарного года. При попытке сохранить изменения в форме Налоги и отчеты система выдает критический сбой: «В данной транзакции уже происходили ошибки!».
В этой статье мы подробно разберем, почему возникает эта ошибка, проанализируем внутренние механизмы платформы «1С:Предприятие 8.3», приводящие к сбою, и рассмотрим эффективные методы диагностики и устранения проблемы — от простых административных действий до программной отладки и использования расширений конфигурации.
Для начала разберем техническую природу этого сбоя. Сообщение «В данной транзакции уже происходили ошибки!» является следствием защитного поведения систем управления базами данных (СУБД, таких как Microsoft SQL Server или PostgreSQL) и самой платформы «1С».
Когда вы меняете систему налогообложения в форме Налоги и отчеты, программа запускает единую транзакцию. Внутри этой транзакции происходит не просто запись новой настройки, но и масштабная реструктуризация параметров учета. В частности, система пытается автоматически перенастроить субконто, признаки учета и свойства счетов в Плане счетов ПланСчетов.Хозрасчетный, вызывая процедуру ПрименитьПараметрыУчета.
Если во время записи какого-либо счета база данных сталкивается с ошибкой (например, из-за нарушения уникальности индекса СУБД, наличия дублирующихся записей или битых ссылок), транзакция на уровне базы данных помечается как «обреченная» (doomed). Любая последующая попытка записать другие данные в рамках этой же незакрытой транзакции приводит к выбросу платформенного исключения. При этом истинная причина (ошибка конкретного счета) маскируется этим общим сообщением.
Чаще всего виновниками сбоя становятся некорректные состояния счетов учета. Практика показывает, что наиболее «проблемными» являются следующие счета:
---
Самая распространенная причина сбоя — появление скрытых «двойников» предопределенных счетов. Такие дубли часто возникают при некорректно настроенной синхронизации данных (например, при обмене с «1С:Управление торговлей» или «1С:ЗУП»), когда правила обмена создают новый счет по уникальному идентификатору (UUID) вместо поиска по коду, или после сбоев при обновлении конфигурации.
Проанализируем ситуацию на примере счета 45.04. В Плане счетов может присутствовать два элемента с кодом «45.04», причем один из них может быть помечен на удаление и скрыт от глаз обычного пользователя. При записи параметров учета система пытается обновить оба объекта, что приводит к нарушению уникальности индексов в таблицах СУБД.
Выполним следующие шаги для зачистки базы данных:
45.04 или 08.04.1), объединим их, назначив правильный предопределенный счет в качестве оригинала.---
Если автоматический поиск дублей не дал результатов, нам необходимо выяснить, на каком конкретно счете прерывается транзакция. Для этого воспользуемся возможностями отладчика платформы.
Разберем по шагам процесс поиска источника проблемы:
Налоги и отчеты.В момент возникновения первичного сбоя (до того, как транзакция заблокируется полностью) отладчик остановит выполнение кода и покажет конкретную строку модуля, на которой произошла ошибка. Как правило, остановка произойдет в модуле ОбщийМодуль.ОбщегоНазначенияБП в процедуре ПрименитьПараметрыУчета.
В табло отладчика проанализируем свойства переменной Объект (или ТекущийСчет). Посмотрев значение Объект.Код, мы сразу поймем, на каком именно счете программа не смогла выполнить запись.
---
Если мы обнаружили проблемный счет (например, счет 08.04.1), но стандартные средства удаления дублей не помогают из-за наличия по нему действующих проводок в закрытых периодах, можно применить временный программный обход.
Ранее программистам приходилось снимать типовую конфигурацию с поддержки (снимать с «замка»), чтобы внести изменения. Сегодня мы решим эту задачу более изящно и безопасно — с помощью **Расширения конфигурации**. Это позволит сохранить базу полностью типовой и готовой к автоматическим обновлениям.
Создадим расширение и переопределим запись счетов:
ОбщегоНазначенияБП, вызовем контекстное меню и выберем Добавить в расширение.ПрименитьПараметрыУчета. Нам потребуется модифицировать блок записи счета внутри конструкции Попытка...Исключение.Напишем код-заплатку с использованием аннотации &Вместо, которая позволит пропустить запись сбойного счета 08.04.1 (или любого другого проблемного счета), чтобы дать транзакции успешно завершиться:
&Вместо("ПрименитьПараметрыУчета")
Процедура Расш1_ПрименитьПараметрыУчета(Параметры, Отказ)
// Реализуем безопасную попытку записи счетов с обходом проблемного объекта
// Ниже представлен фрагмент кода, где выполняется запись объектов плана счетов
// ... (оригинальный код подготовки параметров)
Попытка
// Проверяем код записываемого счета перед вызовом метода Записать()
Если Объект.Код <> "08.04.1" Тогда
Объект.Записать();
Иначе
// Записываем предупреждение в Журнал регистрации, но не прерываем транзакцию
ЗаписьЖурналаРегистрации("НастройкаПараметровУчета",
УровеньЖурналаРегистрации.Предупреждение,, Объект.Ссылка,
"Пропущена запись проблемного счета " + Объект.Код + " во избежание сбоя транзакции.");
EndIf;
Исключение
// Стандартная обработка исключения
ОписаниеОшибки = ИнформацияОбОшибке();
ОтменитьТранзакцию();
Отказ = Истина;
// ... (код формирования подробного протокола ошибок в Журнал регистрации)
КонецПопытки;
КонецПроцедуры
После успешного сохранения расширения запустим базу в режиме «Предприятие», выполним смену системы налогообложения (настройки запишутся корректно), а затем просто отключим или удалим созданное расширение, вернув конфигурацию в исходное типовое состояние.
---
Иногда сбой вызван не программными дублями, а логическими ошибками в таблицах итогов или нарушением ссылочной целостности базы. Прежде чем приступать к написанию кода, мы рекомендуем выполнить стандартный комплекс профилактических мер обслуживания базы данных «1С»:
Систематическое проведение этих несложных профилактических процедур и своевременный контроль чистоты Плана счетов защитят вашу систему от подобных транзакционных ошибок в будущем.