Переход на новые релизы платформы 1С:Предприятие часто сулит не только новые возможности, но и неожиданные технические сложности. Одной из самых резонансных проблем последних лет стала ошибка в ветке 8.3.16.1063 (и смежных релизах), когда в типовых отчетах, таких как «Ведомость по товарам на складах», начальные и конечные остатки начинали отображать некорректные данные, многократно превышающие реальные значения. Особенно остро эта проблема проявилась в конфигурациях на обычных формах, таких как Управление торговлей 10.3, работающих в режиме совместимости.
В данной статье мы подробно проанализируем, почему возникает эта «ересь» в отчетах, как это связано с механизмом генерации SQL-запросов и какие существуют пути решения — от оперативных «костылей» до полноценного исправления кода.
Давайте разберем механику возникновения ошибки. Как отмечают специалисты, проблема кроется в регрессионном баге платформы, который затрагивает оптимизатор запросов к виртуальным таблицам остатков и оборотов. Когда отчет строится с группировкой по периодам (день, неделя, месяц) или по регистратору, платформа должна корректно сопоставлять данные об остатках на границы этих периодов.
Однако в версии 8.3.16 при определенных условиях (использование разыменования ссылок через точку в полях или условиях) вместо получения одного значения остатка на начало периода, СУБД выполняет левое соединение, которое приводит к дублированию строк. В результате начальный остаток суммируется столько раз, сколько было движений (записей оборотов) в данном периоде. Например, если на начало дня было 10 единиц товара и в течение дня произошло 5 отгрузок, отчет может показать начальный остаток как 50 единиц.
Рассмотрим ситуацию, когда отчет строится на базе механизма УниверсальныйОтчет. Проблема часто локализуется в том, как именно формируются поля коэффициентов при пересчете единиц хранения в единицы отчетов. Проанализируем фрагмент кода, который вызывает ошибку, и вариант его исправления.
В типовом исполнении запрос может выглядеть так:
ИсточникДанных.КоличествоНачальныйОстаток * ИсточникДанных.Номенклатура.ЕдиницаХраненияОстатков.Коэффициент / Номенклатура.ЕдиницаДляОтчетов.Коэффициент КАК КоличествоЕдиницОтчетовНачальныйОстаток
Заметим, что в конце выражения обращение к коэффициенту идет напрямую через Номенклатура.ЕдиницаДляОтчетов.Коэффициент. Как выяснилось на практике, если явно указать путь через источник данных, платформа начинает строить план запроса более корректно. Исправленный вариант будет выглядеть следующим образом:
ИсточникДанных.КоличествоНачальныйОстаток * ИсточникДанных.Номенклатура.ЕдиницаХраненияОстатков.Коэффициент / ИсточникДанных.Номенклатура.ЕдиницаДляОтчетов.Коэффициент КАК КоличествоЕдиницОтчетовНачальныйОстаток
Важный момент: такие изменения следует вносить непосредственно в процедуру формирования текста запроса в модуле отчета или в общих модулях, отвечающих за работу УниверсальногоОтчета.
Еще одна причина «кривых» остатков связана с использованием Системы Компоновки Данных (СКД). Выясним причину: если в настройках отчета в качестве группировки выбрано не само измерение, а его реквизит через точку (например, АналитикаУчетаПоПартнерам.Партнер), то при детализации до регистратора механизм расчета итогов может дать сбой.
Чтобы выправить ситуацию, придерживайтесь следующих правил при настройке СКД:
Если правка кода невозможна или не дает мгновенного результата, проанализируем административные способы решения проблемы. Поскольку ошибка является платформенной, она часто связана с некорректными планами запросов, которые сохраняются в кэше сервера приложений 1С.
Пошаговый алгоритм действий для системного администратора:
%ProgramFiles%\1cv8\srvinfo (или ваш путь к данным сервера) и удалите содержимое папок snaccfg и временных файлов сеансов.Если бухгалтер или менеджер не может ждать обновления платформы, можно предложить быстрый обходной путь непосредственно в интерфейсе программы. Как показала практика, ошибка часто проявляется только при выборе определенных показателей, связанных с пересчетом единиц (например, «Количество в единицах отчетов»).
Попробуйте посоветовать пользователям следующее:
Проблема некорректных остатков после обновления — это яркий пример того, как изменения в ядре платформы (оптимизаторе запросов) могут конфликтовать со старым кодом конфигураций. Для решения задачи мы рассмотрели три уровня воздействия: исправление текста запроса, изменение логики группировок в СКД и административное обслуживание сервера.
Помните, что для критически важных баз данных (особенно с учетом ЗУП и требований законодательства) лучшей стратегией является использование LTS-релизов (версий с длительной поддержкой) и обязательное тестирование обновления на копии базы перед промышленным внедрением.