При переходе на новые релизы платформы 1С:Предприятие 8.3 специалисты часто сталкиваются с неожиданным поведением типовых отчетов в конфигурациях, использующих обычные формы (например, УПП 1.3, УТ 10.3 или КА 1.1). Одной из наиболее острых проблем стал баг ветки 8.3.16, из-за которого в отчетах «Товары на складах», «Товары в рознице» и других «Универсальных отчетах» некорректно рассчитываются итоги по группировкам. Вместо получения остатка на конкретный момент времени, система начинает суммировать все промежуточные остатки, что приводит к получению астрономических и заведомо ложных цифр.
В этой статье мы подробно разберем, почему возникает эта ошибка, как она связана с внутренними механизмами платформы и какими способами можно восстановить корректную работу системы, если ваша бухгалтерия требует использования именно новой платформы.
Проанализируем техническую сторону вопроса. В старых конфигурациях большинство отчетов построено на объекте ПостроительОтчета. Этот объект автоматически анализирует текст запроса и назначает «роли» полям. Для виртуальных таблиц регистров накопления (таких как РегистрНакопления.ТоварыНаСкладах.ОстаткиИОбороты) Построитель должен четко понимать, что поля КонечныйОстаток и НачальныйОстаток — это не просто числа, которые нужно складывать (как «Приход» или «Расход»), а значения на временную метку.
В первых релизах платформы 8.3.16 (в частности 8.3.16.1063, 1148, 1224) произошел сбой в логике оптимизатора запросов. Платформа перестала правильно транслировать метаданные виртуальных таблиц в объект ПостроительОтчета. В результате:
Рассмотрим пример того, как это выглядит в коде запроса, который формируется динамически. Вместо корректного получения итогов, платформа генерирует SQL-запрос, где к полям остатка применяется агрегатная функция SUM() без учета специфики начальных и конечных значений.
Проблема носит массовый характер для систем, работающих в режиме совместимости 8.2.13 или 8.2.16. Именно в этом режиме эмуляция работы старого Построителя отчетов на новом движке 8.3.16 дает сбой. Если ваш отчет построен на СКД (Системе компоновки данных), вы, скорее всего, не заметите этой ошибки, так как СКД использует иные механизмы компоновки макета и обработки виртуальных таблиц. Однако «Универсальный отчет» в УПП 1.3 базируется именно на ПостроительОтчета, что и делает его главной жертвой данного бага.
Если специфика вашего бизнеса позволяет, самым быстрым и надежным решением будет возврат на ветку 8.3.15. Как показывает практика и отзывы коллег, версия 8.3.15.1830 является одной из самых стабильных для «старых» конфигураций на обычных формах.
Проанализируем ситуацию, когда откат затруднен (например, обновленная Бухгалтерия предприятия 3.0 требует платформу не ниже 8.3.16). В этом случае мы рекомендуем использовать «правило двух платформ». На сервере или рабочих станциях могут быть установлены обе версии платформы одновременно.
Для реализации этого метода выполним следующие шаги:
В поле «Версия программы» пропишем конкретный релиз, например: 8.3.15.1830. Это заставит систему запускать нужный движок для конкретной конфигурации, игнорируя более новую установленную версию.
Фирма «1С» признала данную проблему и выпустила исправления в более поздних сборках. Если вам принципиально оставаться на ветке 8.3.16, необходимо обновиться до релизов 8.3.16.1359 и выше. Однако, судя по опыту эксплуатации, наиболее безопасным вариантом в этой ветке считается финальный релиз 8.3.16.1814.
Посмотрим на последовательность действий при обновлении серверной платформы:
1C:Enterprise 8.3 Server Agent.snccntx в каталоге reg_1541), так как старые метаданные запросов могут сохраниться и воспроизводить ошибку даже на новой платформе.Если обновить платформу нет возможности, а отчет «Товары на складах» критически важен, можно попробовать внести изменения в программный код формирования отчета. Рассмотрим, как принудительно указать Построителю на роли полей.
В модуле отчета, где происходит инициализация ПостроительОтчета, можно попытаться вручную описать роли через текст запроса. Построитель понимает специальные инструкции в комментариях запроса. Посмотрим на пример изменения текста запроса:
ТекстЗапроса = "
|ВЫБРАТЬ
| Товары.Номенклатура КАК Номенклатура,
| Товары.КоличествоНачальныйОстаток КАК НачальныйОстаток,
| Товары.КоличествоКонечныйОстаток КАК КонечныйОстаток,
| Товары.КоличествоПриход КАК Приход,
| Товары.КоличествоРасход КАК Расход
|{ВЫБРАТЬ
| Номенклатура.*,
| НачальныйОстаток,
| КонечныйОстаток,
| Приход,
| Расход}
|ИЗ
| РегистрНакопления.ТоварыНаСкладах.ОстаткиИОбороты(&ДатаНач, &ДатаКон, Авто, , ) КАК Товары
|{ИТОГИ ПО
| Номенклатура.*}";
Важным моментом является использование конструкции {ИТОГИ ПО...} и корректное описание полей в фигурных скобках. Иногда помогает явное указание типа итога для остаточных полей, но в ПостроителеОтчета возможности управления итогами более ограничены, чем в СКД.
Если вы столкнулись с подобным поведением, выполните следующие проверочные действия, чтобы убедиться, что причина именно в платформе:
ОстаткиИОбороты регистров накопления.Не использовать или 8.3.16. Внимание! Это радикальный шаг, который может «сломать» другие механизмы конфигурации (интерфейс, процедуры проведения), поэтому делайте это только для подтверждения гипотезы в тестовой среде.Проанализировав ситуацию, мы видим, что проблема некорректных итогов — это результат конфликта между старыми механизмами построения отчетов и новыми алгоритмами оптимизации запросов в 1С. Основным инструментом решения остается контроль версионности платформы. Не спешите переходить на самые свежие релизы в продуктивной среде без предварительного тестирования ключевых отчетов управленческого учета.
Подводя итог, если вы используете УПП или УТ 10.3, старайтесь придерживаться ветки 8.3.15 или выбирайте только проверенные временем, финальные сборки 8.3.16+, где ошибки взаимодействия с Построителем отчетов были официально исправлены разработчиками 1С.