Ситуация, когда после планового обновления конфигурации 1С:Бухгалтерия предприятия 3.0 все документы за все периоды внезапно становятся распроведенными, является критической. Это парализует работу бухгалтерии, аннулирует результаты закрытия месяцев и вызывает панику у пользователей. В рамках данной статьи мы подробно разберем, почему это происходит, как провести диагностику и какими методами можно вернуть базу в рабочее состояние.
Первым делом нам необходимо выяснить, является ли распроведение результатом работы программных механизмов или это следствие действий пользователя. Проанализируем Журнал регистрации. Для этого перейдем в раздел Администрирование — Обслуживание — Журнал регистрации.
Настроим отбор по событию "Данные. Изменение" и найдем документы, у которых статус изменился на "Отмена проведения". Если в колонке "Пользователь" указан конкретный сотрудник, значит, имела место либо ошибка пользователя (например, запуск групповой обработки), либо запуск под этой учетной записью внешней обработки. Если же в колонке указано "Фоновое задание" или имя администратора, выполнявшего обновление, причина кроется в технических алгоритмах конфигурации.
Обратим внимание на комментарии в журнале. Часто разработчики 1С при программном изменении статуса документа оставляют технические пометки о том, какой именно обработчик обновления инициировал действие.
В современных конфигурациях на базе БСП (Библиотеки стандартных подсистем), к которым относится БП 3.0, процесс обновления разделен на два этапа: основной (в конфигураторе) и отложенный (в пользовательском режиме). Разберем по шагам, как это может повлиять на проведенность документов.
После первого запуска программы после обновления начинают выполняться Фоновые задания. Если в новом релизе радикально изменилась структура регистров (например, добавились обязательные измерения или изменилась логика учета на счетах Хозрасчетный), система может инициировать пересчет данных. В некоторых случаях, если алгоритм обновления написан некорректно или данные в базе имеют логические ошибки, система может снять признак проведения с документа, чтобы попытаться провести его заново с новыми параметрами. Если этот процесс прерывается ошибкой, документы остаются распроведенными.
Проверить состояние этого процесса можно через форму "Результаты обновления программы" (раздел Администрирование — Обслуживание — Обновление программы). Если там висят невыполненные задания с ошибками, это и есть причина проблемы.
Выясним причину, связанную с методом обновления. Существует два способа обновить базу: через файл обновления .cfu и через полный файл конфигурации .cf. Рассмотрим ситуацию, когда принудительная заливка .cf через функцию "Загрузить конфигурацию из файла" приводит к катастрофе.
При использовании функции "Загрузить конфигурацию" (вместо "Сравнить, объединить с конфигурацией из файла") происходит полная замена метаданных. Если версии .cf и текущей базы не совпадают по внутренним идентификаторам (UUID), система может "потерять" связи между таблицами документов и таблицами движений в регистрах. Для платформы это выглядит так, будто структура данных изменилась настолько, что старые записи в регистрах больше не принадлежат этим документам. В итоге флаг Проведен сбрасывается в Ложь.
Важное правило: всегда используйте механизм "Поддержка — Обновить конфигурацию" или "Сравнить, объединить", если штатное обновление файлом .cfu невозможно.
Иногда документы на самом деле проведены, но в списках они отображаются без "зеленой галочки". Проанализируем ситуацию с кэшем. Локальный кэш пользователя хранит индексы и представления объектов. После обновления структуры метаданных эти индексы могут "поплыть".
Для решения этой проблемы выполним следующие действия:
%AppData%\1C\1cv8 и %LocalAppData%\1C\1cv8.Если после этого статус документов не изменился, значит, проблема действительно в данных, а не в визуализации.
Чтобы окончательно убедиться в состоянии данных, воспользуемся консолью запросов. Нам нужно проверить два момента: установлен ли флаг Проведен и есть ли записи в регистре бухгалтерии.
Пример запроса для проверки (на примере документа "Реализация товаров и услуг"):
ВЫБРАТЬ
РеализацияТоваровУслуг.Ссылка,
РеализацияТоваровУслуг.Проведен,
Хозрасчетный.Регистратор КАК Регистратор
ИЗ
Документ.РеализацияТоваровУслуг КАК РеализацияТоваровУслуг
ЛЕВОЕ СОЕДИНЕНИЕ РегистрБухгалтерии.Хозрасчетный КАК Хозрасчетный
ПО РеализацияТоваровУслуг.Ссылка = Хозрасчетный.Регистратор
ГДЕ
РеализацияТоваровУслуг.Дата МЕЖДУ &НачалоПериода И &КонецПериода
Проанализируем результат: если Проведен = Ложь, но в колонке Регистратор есть данные, значит, движения в базе физически существуют, но статус документа программно сбит. Это "лучший" из плохих вариантов, так как данные не потеряны.
Если автоматическое обновление завершилось сбоем, могли пострадать таблицы индексов базы данных. Рассмотрим пошаговый алгоритм технического восстановления:
bin установленной платформы. Она проверяет физическую целостность файлов базы данных (для файлового варианта). Запустим её и установим флаг "Исправлять обнаруженные ошибки".Часто после пересчета итогов система "видит" записи в регистрах и корректно сопоставляет их с документами.
Если в вашей базе используются расширения, они могут конфликтовать с новым кодом типовой конфигурации. Рассмотрим механизм влияния: если расширение перехватывает процедуру ПередЗаписью или ОбработкаПроведения, и при обновлении в основной конфигурации изменился состав параметров этих методов, расширение может выдавать скрытую ошибку, которая приводит к отказу в проведении или сбросу статуса.
Попробуем временно отключить все расширения и проверить, восстановится ли возможность проведения документов. Если проблема исчезла, значит, необходимо адаптировать код расширения под новый релиз БП 3.0.
Если диагностика показала, что документы действительно распроведены, а записи в регистрах отсутствуют, единственным выходом (кроме восстановления из бэкапа) является массовое перепроведение. В БП 3.0 это лучше делать через стандартный механизм: Операции — Сервис — Групповое перепроведение документов.
Рекомендуется выполнять перепроведение помесячно, начиная с самого раннего периода, чтобы соблюсти последовательность и корректность партионного учета и взаиморасчетов. Перед этим убедитесь, что все Обработчики обновления завершены успешно, иначе система будет постоянно блокировать документы или выдавать ошибки о монопольном доступе.
Подводя итог, можно сказать, что "чудес" не бывает: массовое распроведение — это всегда либо следствие прерванного отложенного обновления, либо результат некорректной заливки .cf файла, либо повреждение таблиц базы данных. Тщательный анализ Журнала регистрации и выполнение Тестирования и исправления в большинстве случаев позволяют найти и устранить причину сбоя.