При работе с подсистемой бюджетирования в 1С:ERP или 1С:Комплексная автоматизация одной из самых гибких возможностей является использование произвольных запросов через Систему компоновки данных (СКД) для получения фактических данных. Однако пользователи и разработчики часто сталкиваются с ситуацией, когда один и тот же запрос в консоли СКД выдает верные цифры, а в бюджетном отчете — колоссальные расхождения (например, вместо миллионов система показывает миллиарды). Рассмотрим, почему это происходит и как правильно настроить правила получения факта.
Разберем типичную ситуацию: вы создаете простейший запрос по оборотам счета (например, 8410 «Вспомогательные производства»). В консоли отчетов или при проверке «Результата работы правил» вы видите корректную сумму — 290 млн. Но как только эта статья попадает в структуру бюджета, сумма превращается в 65 млрд. Проанализируем причины такого поведения системы:
КомпоновщикМакета, который оборачивает ваш текст во внешний запрос, добавляя свои условия по периоду, организации, сценарию и валюте.ГДЕ), но не вывели это поле в доступные поля компоновки или не настроили параметры, движок бюджетирования может «отрезать» это условие при оптимизации запроса.LEFT JOIN с таблицами аналитики отсутствие четких фильтров по регистратору или периоду во вложенных таблицах приводит к тому, что суммы начинают кратно множиться (происходит «раздувание» выборки).Выясним, как именно БСП (Библиотека стандартных подсистем) модифицирует ваш код. Когда вы загружаете схему СКД в «Правило получения фактических данных», система ищет в ней определенные маркеры. Рассмотрим пример структуры запроса, который считается «безопасным»:
ВЫБРАТЬ
ХозрасчетныйОбороты.Счет КАК Счет,
ХозрасчетныйОбороты.Подразделение КАК Подразделение,
ХозрасчетныйОбороты.СуммаОборот КАК Сумма,
ХозрасчетныйОбороты.Период КАК Период
ИЗ
РегистрБухгалтерии.Хозрасчетный.Обороты(&НачалоПериода, &КонецПериода, Месяц, , , , , ) КАК ХозрасчетныйОбороты
Важно понимать: если в этом запросе параметр &НачалоПериода не будет соответствовать стандартным именам, которые ожидает бюджетный движок, система может попытаться выгрести данные за весь период существования базы, что и приводит к астрономическим суммам.
Проанализируем наиболее эффективные способы исправления ситуации, которые подтвердили свою работоспособность на практике.
Если вам нужно жестко ограничить выборку конкретным счетом, самым надежным способом будет указание значения счета непосредственно на вкладке «Параметры» внутри схемы СКД. Посмотрим, как это работает:
ГДЕ Счет = &Счет).8410) и обязательно поставьте галочку «Ограничение доступности», если вы не хотите, чтобы пользователь менял его в правилах.Этот метод гарантирует, что при любой трансформации запроса подсистемой параметр &Счет останется в структуре и будет применен.
Рассмотрим ситуацию, когда запрос должен быть универсальным. В этом случае счет нельзя «зашивать» в СКД. Выясним, как правильно прокинуть настройки:
Счет должно быть обязательно выбрано в секции ВЫБРАТЬ.Счет Равно 8410.Важный нюанс: Отборы, указанные в самом Правиле, имеют приоритет. Если вы оставите отбор в Правиле пустым, система может проигнорировать внутренние ограничения СКД и попытаться собрать данные по всем счетам, что снова приведет к неверному результату.
Если суммы все равно не сходятся, рекомендуем выполнить «расковыривание» запроса в отладке. Вы можете сохранить СКД, которая генерируется бюджетным отчетом в момент выполнения. Рассмотрим, какие различия обычно обнаруживаются:
ГДЕ Счет В (&СписокСчетов).ВЫБРАТЬ * ИЗ (ВашЗапрос) КАК ВложеннаяТаблица, где внешние условия накладываются некорректно из-за конфликта псевдонимов.Чтобы избежать этого, всегда используйте стандартные псевдонимы для итоговых полей: Сумма, Количество, СуммаУпр, СуммаСцн. Это помогает подсистеме бюджетирования правильно идентифицировать ресурсы для агрегации.
Проанализируем лучшие практики, которые минимизируют риск ошибок:
ВЫРАЗИТЬ), фильтры системы могут просто не сработать.Таким образом, решение проблемы кроется в том, чтобы сделать все ключевые аналитики «видимыми» и управляемыми для подсистемы бюджетирования. Вынося настройки из жесткого кода запроса в параметры или явные отборы правила, вы позволяете механизмам ERP корректно модифицировать запрос без потери смысла данных. Если требуется готовое решение для план-фактного анализа без ручной настройки правил сбора факта, можно использовать расширение для план-фактного анализа БДДС с детализацией до документов.