При обновлении платформы «1С:Предприятие» программисты нередко сталкиваются с ситуациями, когда отлаженный годами код начинает вести себя непредсказуемо. Одной из наиболее острых проблем релиза 8.3.13.1644 стала ошибка работы с виртуальными таблицами регистров накопления. В этой статье мы подробно разберем, почему поле Период может возвращать пустые значения или вовсе отсутствовать в выборке, а также выясним причину появления странной даты 01.11.5999 в таблицах итогов.
Рассмотрим ситуацию, с которой столкнулся автор темы. Имеется типовой запрос к виртуальной таблице ОстаткиИОбороты регистра накопления. Обратите внимание на структуру запроса:
ВЫБРАТЬ
ax_ФИ_ВзаиморасчетыПоФинасовымИнструментамОстаткиИОбороты.Период,
ax_ФИ_ВзаиморасчетыПоФинасовымИнструментамОстаткиИОбороты.СуммаПланКонечныйОстаток,
ax_ФИ_ВзаиморасчетыПоФинасовымИнструментамОстаткиИОбороты.СуммаПрогнозКонечныйОстаток,
ax_ФИ_ВзаиморасчетыПоФинасовымИнструментамОстаткиИОбороты.СуммаФактКонечныйОстаток
ИЗ
РегистрНакопления.ax_ФИ_ВзаиморасчетыПоФинасовымИнструментам.ОстаткиИОбороты(, , День, , ФинансовыйИнструмент = &ФИ) КАК ax_ФИ_ВзаиморасчетыПоФинасовымИнструментамОстаткиИОбороты
Проблема заключается в том, что при указании периодичности День поле Период в результате оказывается пустым. При этом, если изменить периодичность на Запись, данные начинают выводиться корректно. Выясним причину такого поведения. В релизе 8.3.13.1644 был допущен баг в механизме генерации SQL-запросов (SDBL). Когда система пытается сгруппировать данные по периодам (день, месяц, неделя) для регистра, который находится в расширении конфигурации, оптимизатор запросов некорректно формирует временные таблицы во внутренней СУБД. В итоге поле периода просто «теряется» при объединении данных основной базы и данных расширения.
Разберем подробнее, почему расширения становятся камнем преткновения. В современных версиях 1С расширения позволяют добавлять собственные регистры накопления. Однако механизм работы виртуальных таблиц для таких регистров реализован иначе, чем для объектов основной конфигурации. Платформа должна «на лету» строить связи между таблицей движений и таблицей итогов, учитывая метаданные расширения.
В релизе 8.3.13.1644 при использовании периодичности, отличной от Запись, система не может правильно сопоставить интервалы времени. Это происходит из-за того, что механизм итогов для расширений в данной версии платформы имеет дефекты в части обработки пустых дат и границ периодов. Если ваш регистр ax_ФИ_ВзаиморасчетыПоФинасовымИнструментам добавлен именно через расширение, вы гарантированно попадете в зону действия этого бага.
Проанализируем второе сообщение автора: после попытки пересчета итогов все записи «встали» на дату 01.11.5999. Для многих разработчиков это выглядит как фатальный сбой базы данных, но на самом деле это служебная особенность 1С.
В архитектуре 1С дата 01.11.5999 (иногда 3999-11-01 в зависимости от СУБД) используется для хранения текущих остатков. Это так называемая «точка бесконечности». Если в консоли управления итогами или через запрос к физической таблице итогов (_AccumRegTotals) вы видите эту дату, это означает, что система хранит там актуальный остаток на данный момент.
Однако проблема автора в том, что все итоги переместились на эту дату, и платформа перестала видеть промежуточные итоги (на концы месяцев). Это происходит по следующим причинам:
Рассмотрим пошагово, как можно исправить данную ситуацию и вернуть работоспособность отчетов.
Способ 1. Обновление платформы (Рекомендуемый)
Поскольку проблема носит платформенный характер, никакие изменения в коде запроса не дадут стабильного результата (кроме перехода на периодичность Запись, что часто неприемлемо для бизнес-логики). Данный баг был официально признан и исправлен в последующих сборках. Вам необходимо обновить платформу до версии не ниже 8.3.13.1809 или перейти на более современные ветки 8.3.14 и выше. После обновления платформы обязательно выполните полный пересчет итогов еще раз.
Способ 2. Перенос регистра в основную конфигурацию
Если обновление платформы по каким-то причинам невозможно (например, из-за требований совместимости с другим ПО), единственным надежным способом будет отказ от использования регистра в расширении. Рассмотрим алгоритм действий:
Объекты в основной конфигурации используют стандартные механизмы обращения к СУБД, которые в 8.3.13 работают значительно стабильнее, чем механизмы для расширений.
Способ 3. Очистка серверного кэша
Иногда после пересчета итогов платформа продолжает «помнить» неверную структуру данных из-за кэширования планов запросов на стороне сервера 1С. Выполните следующие действия:
1C:Enterprise 8.3 Server Agent.snccntxt и папки с GUID-ами баз в каталоге пользователя, под которым работает служба).Если ваш запрос используется в Системе компоновки данных (СКД), проанализируем еще один важный момент. Платформа 8.3.13 при работе с расширениями может некорректно автоматически определять роли полей. Посмотрим на решение через настройки набора данных:
Период.ОстаткиИОбороты должна быть указана роль «Период» с соответствующим типом (День, Месяц и т.д.).Подводя итог, можно сказать, что релиз 8.3.13.1644 оказался крайне неудачным для работы с расширениями. Отсутствие поля Период и «улетающие» в 5999 год итоги — это симптомы одной болезни: нестабильности механизмов интеграции расширений в ядро системы. Мы рекомендуем не тратить время на попытки «подправить» запрос, а сосредоточиться на обновлении платформы до актуальных исправленных версий.