При работе с Системой Компоновки Данных (СКД) в 1С:Предприятии 8.3 разработчики и пользователи часто сталкиваются с различными нюансами, которые могут привести к непредсказуемым результатам. Одной из таких распространенных ситуаций является расхождение итоговых сумм в отчетах, когда один и тот же отчет, настроенный с использованием пользовательского макета, выдает иные (чаще всего заниженные) значения по сравнению с его вариантом без макета. В данной статье мы подробно разберем, почему возникает такая ситуация, как ее диагностировать и, самое главное, как ее эффективно решить.
Представим себе типичную ситуацию, описанную в исходной теме на форуме 1С: разработчик создает отчет на СКД, настраивает группировки, отборы, ресурсы и определяет параметры в областях макета. После запуска отчета обнаруживается, что итоговая сумма меньше, чем та, которую показывает аналогичный отчет, но сформированный без использования макета. На первый взгляд может показаться, что проблема кроется в макете, его настройках или даже в группировках и отборах. Однако, как показывает практика и опыт нашего сообщества, причина часто оказывается более глубокой и связана с фундаментальными принципами работы СКД.
Давайте подробно рассмотрим ситуацию, с которой столкнулся автор темы. Изначально казалось, что ошибка может быть в коде, в настройках группировок или отборов, или в самих макетах. Создавались два варианта одного и того же отчета: один с макетом, другой без. Итоговые суммы расходились. Верный ответ был получен только во втором варианте (без макета). Это навело на мысль, что проблема не в визуальном представлении данных, а в самих данных, которые СКД получает и агрегирует.
Автор в сообщении 6 четко формулирует свою находку: "все дело оказалось не в группировке, не в отборе, а в выбранных полях. набор полей, которые выбирались во втором варианте (без макета), оказались достаточно, чтобы СКД выводила все выбранные строки. потому что без некоторых полей были дубли, строк, которые скд схлопывала". Это и есть краеугольный камень нашей проблемы – схлопывание строк Системой Компоновки Данных.
Система Компоновки Данных — это мощный механизм 1С для построения гибких отчетов. Она работает по принципу обработки запросов к данным, их агрегации, группировки и последующей компоновки в отчетный документ. Ключевую роль в этом процессе играют выбранные поля и настройка ресурсов.
Сумма(ПолеСуммы), Количество(ПолеКоличество)), СКД будет агрегировать эти значения. Проблема возникает, когда СКД "схлопывает" строки до того, как будут рассчитаны ресурсы. Если две или более строки, которые должны были быть уникальными, становятся одинаковыми из-за неполного набора выбранных полей, СКД их объединяет в одну логическую строку. И затем, при расчете ресурсов, она суммирует значения только этой "схлопнутой" строки, а не исходных нескольких строк.Представим ситуацию: у нас есть таблица с данными о продажах, где каждая строка содержит Дата, Номенклатура, Контрагент, СуммаПродажи, НомерДокумента. Если мы в отчете выберем только Дата, Номенклатура, СуммаПродажи и настроим ресурс Сумма(СуммаПродажи), но при этом у нас были две продажи одной и той же номенклатуры одному и тому же контрагенту в один и тот же день, но по разным документам, СКД их "схлопнет". Она увидит две строки: (01.01.2023, ТоварА, 1000) и (01.01.2023, ТоварА, 1000). Так как поля Контрагент и НомерДокумента не выбраны, для СКД эти две строки станут идентичными. В итоге, если бы у нас было (01.01.2023, ТоварА, 1000, Контрагент1, Док1) и (01.01.2023, ТоварА, 1000, Контрагент1, Док2), СКД вместо двух строк схлопнет их в одну, и ресурс Сумма(СуммаПродажи) по этой "схлопнутой" строке будет не 2000, а 1000, что является ошибкой.
Именно об этом говорит сообщение 7, называя это "очередной жертвой автозаполнения". Хотя автор сообщения 8 поправляет, что поля выбирались вручную, суть от этого не меняется – невнимательность при выборе полей приводит к тому, что СКД не видит уникальности строк.
Важно понимать, что макет в СКД сам по себе является лишь инструментом для оформления выводимых данных. Он не изменяет способ получения или агрегации данных СКД. Если СКД уже "схлопнула" строки до того, как макет был применен, то макет просто отобразит те данные, которые СКД ему предоставила. Иными словами, макет не может исправить неверно агрегированные данные, но он может скрыть проблему.
Когда мы работаем без макета, СКД использует свой стандартный механизм вывода, который часто более детализирован и может автоматически включать больше полей для группировок и детализации, что помогает избежать схлопывания. Когда же мы создаем свой макет, мы вручную определяем, какие поля и как будут отображаться. Если мы при этом не включаем в список выбранных полей те, которые обеспечивают уникальность строк, то макет будет работать с уже "схлопнутыми" данными, демонстрируя некорректные итоги.
Рассмотрим, какие особенности работы с макетами следует учитывать:
Таким образом, макет не является причиной ошибки, но он является индикатором того, что мы, возможно, недостаточно внимательно отнеслись к выбору полей в настройках СКД, что привело к некорректной агрегации данных.
Для того чтобы избежать расхождения итогов и обеспечить корректную работу отчетов СКД с макетами и без них, необходимо систематически подходить к настройке компоновки данных. Рассмотрим подробнее шаги, которые помогут нам в этом.
Это самый важный шаг, так как именно он был основной причиной проблемы, описанной в теме форума. Наша задача — убедиться, что в списке выбранных полей присутствуют все поля, которые в совокупности однозначно идентифицируют каждую строку данных, которую мы хотим видеть в отчете.
СсылкаНаДокумент, Номенклатура, Характеристика, Серия. Если вы забудете выбрать Серия, а у вас было две строки с одинаковой номенклатурой и характеристикой, но разными сериями, СКД может их схлопнуть.Важный совет: Даже если вы не планируете выводить какое-либо поле в отчете (то есть оно не будет использоваться в макете), но оно необходимо для обеспечения уникальности строк, всегда добавляйте его в "Выбранные поля". Вы можете просто не включать его в макет, но СКД будет использовать его при формировании внутреннего набора данных, что предотвратит схлопывание.
Например, если у нас есть запрос:
ВЫБРАТЬ
РеализацияТоваровУслугТовары.Ссылка КАК Документ,
РеализацияТоваровУслугТовары.Номенклатура КАК Номенклатура,
РеализацияТоваровУслугТовары.Количество КАК Количество,
РеализацияТоваровУслугТовары.Сумма КАК Сумма,
РеализацияТоваровУслугТовары.Характеристика КАК ХарактеристикаНоменклатуры,
РеализацияТоваровУслугТовары.Серия КАК СерияНоменклатуры
ИЗ
Документ.РеализацияТоваровУслуг.Товары КАК РеализацияТоваровУслугТовары
И мы хотим посчитать общую сумму. Если мы в "Выбранных полях" укажем только Документ, Номенклатура, Сумма, а у одной номенклатуры в одном документе могут быть разные ХарактеристикаНоменклатуры или СерияНоменклатуры, то СКД их схлопнет. Чтобы этого не произошло, обязательно включите ХарактеристикаНоменклатуры и СерияНоменклатуры в выбранные поля, даже если вы не собираетесь их показывать.
После того как мы убедились, что СКД получает корректный, не схлопнутый набор данных, нам необходимо правильно настроить расчет ресурсов.
Примеры выражений для ресурсов:
Сумма(ПолеСумма)Количество(Различные ПолеИдентификатор) или Количество(ПолеИдентификатор) (если хотим посчитать все строки, даже дубликаты, или КоличествоВсего() для подсчета всех записей в группировке/отчете).Среднее(ПолеЧисло)Максимум(ПолеЗначение), Минимум(ПолеЗначение)Убедитесь, что выражение для ресурса соответствует вашим целям. Если проблема была в схлопывании строк, то после добавления всех идентифицирующих полей, ресурсы должны начать рассчитываться корректно.
Хотя автор темы указал, что проблема не в группировках и отборах, они все равно являются важными элементами СКД, которые могут косвенно влиять на восприятие итогов или усугублять проблемы с данными. Мы должны убедиться, что они настроены правильно.
Номенклатура, а затем по Контрагент, это логично. Но если вы группируете по полям, которые сами по себе могут содержать дубликаты (например, по короткому описанию, а не по уникальному идентификатору), это может привести к неверному представлению итогов, даже если СКД получила все детальные строки.Важно: При отладке отчета, когда есть подозрения на некорректные данные или расчеты, временно отключите все отборы и группировки (кроме детализации), чтобы убедиться, что базовый набор данных СКД формируется верно. Затем постепенно включайте группировки и отборы, проверяя результат на каждом шаге.
В случае, если ваш отчет СКД использует несколько наборов данных (например, запрос к регистру и запрос к справочнику), критически важно проверить корректность связей между ними. Неправильно настроенные связи могут привести к дублированию строк или, наоборот, к потере данных, что непосредственно влияет на итоговые суммы.
Левое соединение, Правое соединение, Внутреннее соединение, Полное соединение).Левое соединение: Включает все записи из левого набора данных и соответствующие записи из правого. Если соответствия нет, поля правого набора будут иметь значение NULL. Это чаще всего предпочтительный вариант, чтобы не терять данные из основного набора.Внутреннее соединение: Включает только те записи, для которых есть совпадения в обоих наборах данных. Если нет совпадения, запись исключается. Это может быть причиной заниженных итогов, если часть данных не находит соответствия и отбрасывается.Наименование вместо поля Ссылка может привести к дублированию, если есть одноименные элементы.Всегда используйте отладчик запросов или предварительный просмотр данных на вкладке "Наборы данных", чтобы убедиться, что после объединения нескольких наборов вы получаете ожидаемый результат.
В некоторых случаях, особенно при работе с полями-характеристиками или когда требуется сложная логика агрегации, стандартных ресурсов может быть недостаточно. В таких ситуациях мы можем создавать пользовательские поля.
Это особенно полезно, когда необходимо реализовать нестандартную логику агрегации. Например, если нужно сложить значения только при выполнении определенного условия:
// Выражение для детальных записей
ВЫБОР КОГДА ПолеУсловие = Истина ТОГДА ПолеСумма ИНАЧЕ 0 КОНЕЦ
// Выражение для итоговых записей
Сумма(ВЫБОР КОГДА ПолеУсловие = Истина ТОГДА ПолеСумма ИНАЧЕ 0 КОНЕЦ)
Или если необходимо использовать специфические функции:
// Пример использования выражения для детальных записей с преобразованием
ПРЕДСТАВЛЕНИЕ(ПолеСсылка)
// Пример выражения для итоговых записей, если нужно, чтобы в итоге было 'Всего'
"Всего"
Важно: Всегда тщательно тестируйте пользовательские поля, особенно их выражения для итогов, чтобы убедиться в их корректной работе.
Рассмотренная нами ситуация с расхождением итогов в отчетах СКД с макетом и без него является классическим примером, когда кажущаяся сложность проблемы сводится к фундаментальному принципу работы Системы Компоновки Данных – правильному формированию набора данных и обеспечению уникальности строк. Макеты, будучи инструментом оформления, могут лишь визуально проявить или скрыть уже существующие проблемы в данных.
Мы выяснили, что основной причиной обычно является неполный набор выбранных полей, что приводит к "схлопыванию" (объединению) строк СКД и, как следствие, к заниженным итоговым суммам. Решение заключается в методичной проверке и настройке следующих аспектов:
Следуя этим рекомендациям, вы сможете значительно повысить надежность и корректность своих отчетов на СКД, а также избежать подобных ситуаций в будущем. Внимательность к деталям при настройке СКД – залог успешной работы с данными.