СКД + Иерархия элементов + Итоги показателей по иерархии #805980

Добрый день, форумчане! Много лазил по форумам, читал вумные книжки, но так и не нашёл для себя решения задачи, описанной ниже. Очень надеюсь, что среди Вас найдутся более знающие и более опытные люди, чем я. Итак, в базе есть справочник контрагентов с иерархией ЭЛЕМЕНТОВ, есть регистр накопления с показателями продаж этих контрагентов. Задача: вывести контрагентов в иерархическом виде, для каждого контрагента вывести показатель продаж, а также итоговый показатель продаж тех контрагентов, которые находятся "под ним" в структуре справочника НА ВСЕХ НИЖНИХ УРОВНЯХ. Всю эту кухню надо реализовать на СКД, чтобы иметь возможность строить отчёт с произвольным отбором по реквизитам контрагентов, а также, чтобы можно было менять период продаж. Например, это выглядеть должно так: Бьюсь уже пару недель :( Отдельно иерархию контрагентов получается сделать, показатель продаж достать по конкретному контрагенту нет проблемы. Вся проблема найти сумму по иерархии. Была бы иерархия групп и элементов справочника "Контрагенты", вопросов бы вообще не было. Вроде, кажется, простой вопрос, а ставит в тупик. Подбросьте идею, пожалуйста. Спасибо заранее всем откликнувшимся.

ВычислитьВыражение пробовал?

по Пупкину Сумма продаж + свои вероятно должна быть 9100?

Пробовал, но как-то безуспешно. Работало только когда действительно выводил иерархически, но тогда появлялись двойные записи, т.е. под Пупкиным ещё один раз Пупкин был, а мне так не нужно. В таблице всё верно. 5100 = 3500+500+1000+100

Про такую штуковину думал, но так и не понял, в каком месте её лучше прикрутить. Ведь выводить дерево "без лишних строк" можно двумя способами: 1. Соединять набор с самим собой по полям "Ссылка"-"Родитель" на вкладке "связи наборов данных", но тогда в результат выводятся ДЕТАЛЬНЫЕ записи, где итогов иерархии нет. 2. Выводить иерархично, но определять пользовательское поле с условием отбора, но тогда выводятся не все записи: либо без "листиков", либо вообще лажа какая-то.

не знаю что и как ты там соединяешь, но у меня все работает

а прикрутить ее в ресурс

Я примерно с подобной задачей бьюсь постоянно. И ниразу ничего адекватного у меня не выходило))) Поэтому буду очень внимательно следить за этой темой. По своим изысканиям: делал и ВЫЧИСЛИТЬВЫРАЖЕНИЕСГРУППИРОВКОЙМАССИВ и вычислитьвыражение, предварительно в запросе как то ставив метку на нужную мне запись, и экспортными функциями как то делал, иногда забиваю на скд и делаю макетом)))) Во общем все мои варианты мне не нравятся самому - поэтому каждый раз нахожусь в поиске нового варианта)

вот вам пример в УПП, иерархия контрагентов построена через реквизит ГоловнойКонтрагент

> справочник контрагентов с иерархией ЭЛЕМЕНТОВ У вас там МММ что ли?

тебе действительно интересно или выпендриться решил? у нас не МММ

Не МММ, но задача есть и я её хочу решить. :) Т.е. если, к примеру, попытаться не использовать стандартную иерархию по родителю, а сделать свою, но тоже по родителю, то будет нужный результат? Фокус-то как раз в иерархии ЭЛЕМЕНТОВ. Завтра попробую замострячить. :)

Кстати, суммы в Вашем скриншоте не так рассчитываются, как мне нужно. Думаю, вряд ли получится. Но попробую.

уверен что не так? если что пиши на мыло

а, ну да, ок.. Но тогда почему по Иванову 5000, подчиненных нет, а своих только 1000.

Уууу... Это да. Напротив Иванова в последней колонке должна быть 1000. Остальное, вроде, нормально. Спасибо за поправочку.

колонку справа можно посчитать и без скд, чисто в запросе.

С трудом представляю себе такой запрос.

соединить табличку с самой собой по условию, что поле1.Родитель=Поле1 или поле1.родитель.родитель=поле1 ...

Количество уровней справочника "Контрагенты" не ограничено.

в конце концов, для универсальности, запрос можно собрать кодом

давай запрос, ща проверим твои расчеты )))

вот как раз для универсальности и сделано на СКД

мне такое не надо, спасибо. нужно правда учесть, что при большом справочнике такой запрос будет очень долго выполняться

замеры показать?

Я простых вопросов не задаю. Это уже крайняя мера для меня - идти на форум и задавать вопрос. Это мой первый вопрос. Обычно, решение нахожу достаточно быстро, но это не тот случай. :( а справочник очень большой. Может достигать 100000 контрагентов и уровней ой-ёй-ёй сколько...

давай

сколько элементов и уровней?

DrShad, можешь схему СКД выложить?

546 элементов, вложенность не ограничена, но в данном примере у меня 5

не, это детсад. на 100 000 элементов и скд будет долго считать, хотя и быстрее, имхо, чем запрос с соединением таблицы самой на себя.

один хрен быстрее чем даже составной запрос собранный программно

пожалуй, да.

Программно запрос составлять тоже непонятно, как, т.к. пользователь может выбрать любой элемент из этих 100000, а отчёт должен будет вывести ему данные только по этой иерархии. Вышестоящие контрагенты ему в отчёте будут не нужны. Это, кстати, ещё один гемор, который надо лечить.

Любит СКД выводить вышестоящие уровни, если использовать стандартную группировку по иерархии.

тут схема

Спасибо! Поковыряюсь. ;)

удачи

лично мне непонятно, что вам может быть тут непонятно. при сборке запроса вычисляется существующее количество уровней иерархии справочника и в зависимости от вычисленного числа уровней собирается условие соединения таблиц

Не приходилось ни разу менять текст запроса СКД после нажатия пользователем кнопочки "Сформировать". Попробую и этот вариант. Спасибо.

вот не нужно этим извращаться

А вдруг я ещё тот извращенец? )))))))))

Мне это может пригодиться в следующем отчёте, который по своей сути является следующей стадией извращения над этим отчётом. Там надо будет эти же показатели, только за несколько периодов и ещё с отбором по значениям этих самых показателей (+ нулевые тоже будут нужны!).

Мне действительно интересно. Я такое встречал только в двух местах: в МММ-подобных схемах и у терминальщиков-обнальщиков.

DrShad, спасибо за выражение: Вот именно в таком синтаксисе у меня заработал ресурс так, как надо. Но в целом компоновку пришлось переделать, т.к. группировка по реквизиту мне не подходит.

Ладно. Результат я получил примерно такой: В параметрах отчёта пользователь указал, что выводить нужно по тем контрагентам, которые под Шишкиным. Вопрос: как избавиться от Сухова, Лапина и самого Шишкина, которых в отчёт не просили выводить. :) Можно даже оставить Шишкина - это не будет проблемой или ошибкой.