При работе в программе 1С:Бухгалтерия предприятия 3.0 (включая версию КОРП) пользователи и администраторы иногда сталкиваются с крайне неприятной ситуацией. При попытке изменить в учетной политике способ оценки материально-производственных запасов (МПЗ) со «Средней» на «ФИФО» система надолго зависает, после чего аварийно завершает операцию и выдает малоинформативное сообщение: «В данной транзакции уже происходили ошибки!».
В этой статье мы подробно разберем, почему возникает эта ошибка с технической точки зрения, что происходит в этот момент «под капотом» платформы 1С, как правильно диагностировать скрытую причину сбоя и как оперативно восстановить работоспособность системы без потери данных.
Для начала проанализируем природу самого сообщения. Ошибка «В данной транзакции уже происходили ошибки!» — это классическое поведение платформы «1С:Предприятие 8», связанное с механизмом транзакций и обработкой исключений в блоках Попытка — Исключение.
В процессе записи изменений учетной политики платформа открывает транзакцию. Если внутри этой транзакции происходит любой сбой на уровне базы данных (например, СУБД отклоняет операцию из-за нарушения ограничений целостности или структуры данных), транзакция переходит в состояние Rollback Only (так называемая «испорченная» транзакция).
Даже если разработчики конфигурации предусмотрели обработку ошибок и обернули код в конструкцию перехвата исключений, транзакция уже не может быть успешно зафиксирована. Любое последующее обращение к базе данных в рамках этого же процесса (например, вызов метода Записать() у другого объекта или регистра) приведет к тому, что платформа выдаст generic-ошибку транзакции. При этом стек вызовов укажет на последнюю строку кода, где произошло вторичное обращение (в нашем случае это строка записи регистра сведений МенеджерЗаписи.Записать(НЕ ЭтоФормаЗаписи)), полностью маскируя первоначальную, истинную причину сбоя.
Давайте выясним причину, почему именно переход на метод оценки «ФИФО» вызывает такую реакцию системы. Когда мы меняем способ оценки МПЗ со «Средней» на «ФИФО», программа выполняет масштабную реорганизацию структуры данных плана счетов:
Если до этого момента пользователи или обслуживающие специалисты вручную добавили на какой-либо из счетов учета ТМЦ (например, на счет 21 или субсчета счета 10) свои собственные кастомные субконто, заняв все три доступных слота аналитики, система сталкивается с неразрешимым конфликтом. Программа пытается программно добавить четвертое субконто (Партии), СУБД возвращает ошибку превышения лимита, транзакция помечается как «испорченная», и пользователь получает зависание системы с последующей ошибкой транзакции.
Если вы столкнулись с подобным поведением системы, разберем по шагам, как локализовать и выявить проблемный счет.
Самый надежный способ увидеть реальную ошибку до того, как платформа замаскирует ее ошибкой транзакции, — это настройка остановки по ошибке в конфигураторе. Выполните следующие действия:
Отладчик остановит выполнение кода ровно в тот момент, когда система попытается добавить лишнее субконто к счету, и вы увидите реальный текст ошибки в окне локальных переменных или в табло. Код, который вызывает сбой, обычно выглядит следующим образом:
// Системный вызов добавления субконто в плане счетов
НоваяСтрокаСубконто = СчетОбъект.ВидыСубконто.Добавить();
НоваяСтрокаСубконто.ВидСубконто = ПланыВидовХарактеристик.ВидыСубконтоХозрасчетные.Партии;
СчетОбъект.Записать(); // Здесь происходит первичное исключение СУБД
Если нет возможности запустить конфигуратор в режиме отладки (например, на рабочей базе в разгар рабочего дня), проанализируем ситуацию с помощью Журнала регистрации:
После того как проблемный счет обнаружен (в практике пользователей чаще всего страдают счета 21, 41 или субсчета 10 счета, куда бухгалтеры любят добавлять аналитику по проектам, спецификациям или дополнительным характеристикам), необходимо выполнить исправление.
Для того чтобы система смогла записать учетную политику и корректно добавить субконто «Партии», нам нужно освободить одно место в списке субконто проблемного счета. Посмотрим на алгоритм действий:
Изменение предопределенного плана счетов в типовой конфигурации «1С:Бухгалтерия» путем добавления третьих и четвертых субконто — это крайне нежелательная практика. Это приводит к постоянным сбоям при обновлении конфигурации, ломает регламентные операции закрытия месяца и усложняет расчет себестоимости.
Для внедрения дополнительной аналитики мы рекомендуем использовать типовой механизм «Дополнительные реквизиты и сведения»:
Этот подход гарантирует стабильную работу всех последующих обновлений 1С и исключит появление подобных транзакционных ошибок при изменении глобальных параметров учетной политики предприятия.