В практике работы с конфигурацией 1С:Управление торговлей 11.4 (а также ERP и Комплексной автоматизацией) пользователи часто сталкиваются с парадоксальной ситуацией: при установке фильтра Равно по конкретной номенклатуре отчет показывает одну сумму, а при использовании фильтра В списке с тем же самым единственным значением — другую. Казалось бы, с точки зрения формальной логики, эти условия тождественны. Однако программные механизмы Системы компоновки данных (СКД) и особенности архитектуры регистров себестоимости диктуют свои правила.
В этой статье мы подробно разберем, почему возникает такая разница, как платформа 1С интерпретирует различные виды сравнения и что нужно сделать, чтобы отчет выводил корректные и идентичные данные в обоих случаях.
Рассмотрим подробнее, как именно Система компоновки данных обрабатывает отборы, установленные пользователем. Когда мы выбираем условие Равно, платформа зачастую пытается оптимизировать запрос и передать это значение напрямую в параметры виртуальных таблиц регистров накопления (например, в таблицу ОстаткиИОбороты). Это означает, что выборка данных из базы происходит уже с учетом этого ограничения.
В случае с условием В списке, даже если в списке всего один элемент, СКД может повести себя иначе. Нередко такие условия накладываются не на уровне параметров виртуальной таблицы, а на уровне секции ГДЕ итогового SQL-запроса. Проанализируем ситуацию: если отбор срабатывает после того, как данные из виртуальной таблицы уже получены, это может повлиять на расчет средневзвешенных показателей себестоимости, особенно если в запросе участвуют сложные соединения с другими наборами данных.
Выясним причину, связанную со спецификой отчета Себестоимость товаров предприятия. Этот отчет не является простым выводом данных из одного регистра. Он собирает информацию из нескольких источников, включая РегистрНакопления.СебестоимостьТоваров и технические данные о партиях. Как было отмечено в ходе обсуждения проблемы, ключевым фактором может выступать измерение Хозяйственная операция.
Проанализируем следующий момент: при использовании фильтра Равно по номенклатуре система может применять дополнительные неявные фильтры для оптимизации производительности. Если же используется В списке, оптимизатор может «подтягивать» технические записи (например, корректировки стоимости, внутренние перемещения без изменения финансового результата), которые при строгом равенстве отсекались бы на уровне первичного обращения к данным.
Посмотрим на практическое решение, которое помогло устранить расхождения:
Хозяйственная операция (уровнем ниже, чем Номенклатура), данные в обоих случаях становятся идентичными. Это происходит потому, что принудительный вывод детализации заставляет СКД одинаково обходить записи в обоих вариантах формирования отчета.Разберем по шагам еще одну важную техническую деталь — работу с составными типами данных и значениями NULL. Поле Номенклатура в регистрах себестоимости тесно связано с аналитикой учета номенклатуры. Рассмотрим, как это влияет на SQL-запросы:
Поле = Значение жестко требует совпадения Unique Identifier (GUID).Поле IN (Список) в некоторых версиях платформы может по-другому обрабатывать записи, где ссылка является «битой» (Объект не обнаружен) или тип значения не полностью совпадает с ожидаемым.Кроме того, если в отчете используются левые соединения (LEFT JOIN) между таблицей остатков и таблицей оборотов, то при отсутствии данных в одной из таблиц возникнет NULL. Фильтр Равно по умолчанию отсекает NULL, в то время как В списке может обрабатывать такие строки иначе в зависимости от внутренней логики построения временных таблиц в СКД.
Для того чтобы окончательно убедиться в причинах расхождений, мы рекомендуем воспользоваться инструментом Консоль системы компоновки данных. Проанализируем ситуацию с ее помощью:
Равно и варианта с В списке.Особое внимание обратите на секции {WHERE...} и параметры, передаваемые в функции виртуальных таблиц. Обычно вы увидите разницу в использовании конструкции IN против прямого оператора сравнения, что и приводит к разным планам выполнения на стороне СУБД.
Важный совет: Чтобы отчет всегда работал предсказуемо, старайтесь использовать штатные механизмы отборов на панели настроек, не перегружая структуру отчета сложными пользовательскими полями без необходимости. Если расхождение сохраняется, использование группировки по измерениям, участвующим в расчете (например, Вид запасов или Хозяйственная операция), является наиболее эффективным и быстрым способом «выровнять» цифры.
Таким образом, мы выяснили, что фильтры Равно и В списке не всегда тождественны в сложных отчетах 1С из-за специфики работы СКД. Для исправления ситуации необходимо проверить состав типов данных, сбросить пользовательские настройки и добавить в структуру отчета дополнительные группировки для более детального анализа движений по регистрам. Это обеспечит прозрачность расчета себестоимости и исключит технические ошибки при выводе итоговых сумм.