При обновлении технологической платформы «1С:Предприятие» до версии 8.3.14.1565 многие администраторы и разработчики столкнулись с неприятным сюрпризом: в типовых и самописных отчетах перестала корректно работать расшифровка. Типичный сценарий: пользователь открывает отчет (например, «Ведомость по товарам на складах»), пытается расшифровать итоговую цифру по полю Регистратор, отчет формируется, список документов выводится, но колонки с количеством или суммами остаются абсолютно пустыми.
В этой статье мы подробно разберем, почему это происходит, как технически устроена эта ошибка внутри системы компоновки данных (СКД) и какие шаги необходимо предпринять, чтобы восстановить работоспособность системы. Мы проанализируем ситуацию с точки зрения серверных процессов и взаимодействия платформы с базой данных SQL.
Давайте рассмотрим подробнее, что именно видит конечный пользователь. Основная проблема проявляется в механизме Системы компоновки данных. При попытке детализации отчета до уровня первичного документа (поля Регистратор):
Проблема носит массовый характер и затрагивает конфигурации, активно использующие управляемые формы и последние возможности расширений, такие как Управление торговлей 11.4, ERP 2.4, Зарплата и кадры государственного учреждения 3.1.
Разберем по шагам, что происходит «под капотом» платформы. Система компоновки данных — это декларативный механизм. Когда мы просим расшифровать отчет, платформа динамически генерирует SQL-запрос к базе данных. В релизе 8.3.14.1565 разработчики 1С внесли изменения в алгоритм оптимизации запросов для виртуальных таблиц (остатков и оборотов).
Выясним причину некорректного поведения: при построении схемы компоновки, если в настройках выбрана детальная запись или группировка по регистратору, механизм оптимизации 8.3.14 ошибочно помечает поля ресурсов как «неиспользуемые». Платформа считает, что для получения ссылки на документ (регистратор) ей не нужно обращаться к физическим таблицам накопления за итогами. В результате в итоговом SELECT запросе к SQL-серверу поля с ресурсами просто отсутствуют или заменяются на NULL.
Это подтверждается официальным реестром ошибок (например, баг с кодом 10210214). Ошибка возникает именно в момент компоновки макета, когда платформа решает, какие данные ей «выгодно» извлекать из БД.
Посмотрим на ситуацию со стороны системного администратора. В некоторых случаях попытка сформировать расшифровку в «тяжелых» отчетах (с большим объемом данных) приводит не просто к пустым колонкам, а к полному падению рабочего процесса rphost. В журнале регистрации или в окне пользователя появляется сообщение:
«Удаленный хост принудительно разорвал существующее подключение (10054)».
Проанализируем ситуацию: это происходит из-за того, что некорректно сформированный запрос или ошибка в модуле управления памятью платформы 8.3.14 вызывает исключение Access Violation. Рабочий процесс аварийно завершается, и все пользователи, подключенные к данному процессу, теряют связь с базой. Это делает работу на данном релизе практически невозможной в многопользовательской среде.
Если ваша конфигурация позволяет использовать более ранние версии платформы, самым быстрым и надежным способом будет откат. Как отмечают специалисты, стабильной версией для работы УТ 11.4 и других современных решений является ветка 8.3.12 или конкретный релиз 8.3.13.1690.
Разберем процесс отката по шагам:
Режим совместимости установлен в значение, не превышающее 8.3.12. Если стоит 8.3.14, откат может потребовать дополнительных манипуляций с расширениями.8.3.13.1690.1C:Enterprise 8.3 Server Agent.Важно: Помните, что некоторые релизы конфигураций (например, самые новые версии ЗУП или УТ) могут жестко требовать версию не ниже 8.3.13. Всегда сверяйтесь с файлом readme.txt к вашей конфигурации.
Если вы не можете откатиться назад (например, используете новые возможности расширений, доступные только в 8.3.14), необходимо обновиться до версии, где эта ошибка была официально исправлена. Разработчики 1С оперативно выпустили последующие сборки.
Рассмотрим подробнее: стабильная работа механизмов СКД и расшифровок по регистратору была восстановлена в релизе 8.3.14.1642 и во всех последующих версиях ветки 8.3.15 и выше.
Если вы решите обновляться, придерживайтесь следующего алгоритма:
// Примерный план действий для администратора:
1. Создать резервную копию базы данных (SQL или DT).
2. Завершить все сеансы пользователей.
3. Остановить службу сервера 1С.
4. Установить новый релиз (например, 8.3.14.1854 или 8.3.15.х).
5. Выполнить первый запуск от имени администратора для обновления конфигурации БД.
Проанализируем еще один аспект: влияние расширений. В версии 8.3.14 механизм расширений претерпел значительные изменения. Если ваш отчет или данные, которые он использует (например, дополнительные реквизиты, добавленные в расширении), задействованы в расшифровке, платформа 1565 может входить в конфликт с логикой сопоставления типов данных.
Если обновление платформы временно невозможно, попробуйте выполнить следующие действия в качестве временной меры (костыля):
Однако, как показывает практика обсуждений, эти меры помогают крайне редко, так как ошибка заложена глубоко в программном коде самого исполняемого файла платформы (в библиотеках, отвечающих за генерацию макета компоновки).
Подведем итоги нашего анализа. Платформа версии 8.3.14.1565 оказалась крайне неудачной для организаций, активно использующих аналитическую отчетность и механизмы расшифровки. Основная причина — баг оптимизации СКД, приводящий к «потере» ресурсов при детализации до регистратора.
Наши рекомендации:
Совместный анализ проблемы показывает, что только системный подход к выбору версии технологической платформы позволяет избежать простоев бизнеса из-за некорректных данных в управленческой отчетности.