При тонкой настройке типовых отчетов в конфигурации «1С:Управление торговлей 11» (на базе системы компоновки данных — СКД) пользователи нередко сталкиваются с двумя сопутствующими сложностями. Во-первых, при наложении фильтра непосредственно на подчиненную группировку платформа начинает выводить служебный текст вида «Отбор: Сальдо конечное > 0» прямо в табличную часть отчета. Во-вторых, стандартные вышестоящие итоги отчета игнорируют отборы вложенных группировок, рассчитываясь по полному набору данных. Разберем по шагам, как решить обе эти задачи в режиме «1С:Предприятие» без доработки конфигурации.
Проанализируем поведение системы компоновки данных. Когда мы накладываем отбор на весь отчет целиком, параметры выводятся в шапке или подвале документа в зависимости от общих настроек. Однако если отбор задан для конкретной ветки дерева структуры (например, по группировке Клиент), платформа по умолчанию выводит поясняющую надпись непосредственно перед выводом записей этой ветки. Это сделано для прозрачности данных, но часто нарушает визуальное оформление отчета.
Что касается расчета итогов: в архитектуре СКД отбор, установленный на дочернюю группировку, отсекает только вывод строк на ее уровне. При этом вышестоящие агрегаты (родительские группировки и строка Общий итог) рассчитываются независимо по всему набору записей. Если нам необходимо, чтобы в общих суммах участвовали исключительно отфильтрованные строки, простого отбора на группировке недостаточно — потребуется создать пользовательское поле.
Выясним причину появления служебной строки и уберем ее штатными средствами расширенной формы настроек отчета. Выполним следующие действия:
Клиент).Рассмотрим вторую задачу: нам нужно, чтобы в колонках вышестоящих итогов суммировались только положительные значения конечного сальдо. При попытке вручную ввести внутреннее имя поля из конфигуратора (например, ДолгКонечныйОстаток) платформа выдает ошибку о том, что поле не найдено. Выясним, почему это происходит.
В режиме «1С:Предприятие» СКД не оперирует внутренними идентификаторами схемы компоновки данных. Генератор выражений пользовательских полей понимает только пользовательские представления (заголовки), которые видны в дереве доступных полей, причем они обязательно должны быть обрамлены в квадратные скобки. Посмотрим на алгоритм создания такого поля:
Сальдо долга к получению.
Выбор
Когда [Сальдо конечное] > 0
Тогда [Сальдо конечное]
Иначе 0
Конец
Сумма(Выбор Когда [Сальдо конечное] > 0 Тогда [Сальдо конечное] Иначе 0 Конец)
Сальдо долга к получению.Клиент. Теперь строки с нулевым или отрицательным остатком перестанут искажать суммы, а итоги на всех уровнях рассчитаются математически верно.Совет: чтобы не ошибиться в написании имени поля внутри квадратных скобок, выбирайте нужное поле двойным щелчком мыши из списка доступных полей, расположенного в окне редактора выражений. Платформа подставит точное системное представление автоматически.
Разберем альтернативный сценарий: если в отчете требуется лишь визуально спрятать неположительные суммы, не изменяя базовый расчет регистра, можно задействовать механизм условного оформления вместо жестких отборов:
[Сальдо конечное] со значением сравнения Меньше или равно 0.Проанализируем типовую специфику ведения взаиморасчетов в УТ 11. Партнеры предприятия нередко выступают одновременно и покупателями, и поставщиками. Важно учитывать, что в программе учет задолженностей ведется в двух независимых регистрах накопления: РасчетыСКлиентами и РасчетыСПоставщиками.
Ни один типовой отчет (включая отчеты «Ведомость расчетов с партнерами» или «Сводная ведомость расчетов») не выполняет автоматического зачета между долгом покупателя и нашим долгом перед ним как перед поставщиком на уровне базы данных. Они лишь сводят цифры в общую таблицу. Если компании требуется реальное сальдирование долгов, в программе необходимо отразить документ Взаимозачет задолженности (раздел «Казначейство»). После проведения документа расчеты скорректируются по обоим регистрам, и типовые отчеты покажут корректный чистый остаток без необходимости сложных манипуляций с СКД.