Добрый день!
Стоит такая задача : необходимо сделать отчеты вида план/факт, но проблема в том что планы необходимо вбивать не на элементы справочника а на группы , причем каждый раз уровень иерархии может быть разный...при этом распределить количество на сами элементы нельзя, т.к. когда например продается только 1 элемент из 100 это нормально....вопрос как это соединить с продажами? ведь там продажи идут по элементам....на текущий момент я решил этот вопрос очень криво и коряво, сначала выбираю планы, после для каждого элемента плана в цикле делаю запрос с условием иерархии того элемента к регистру продаж...все кроме скорости работы устраивает....как это сделать оптимально и быстро? Решал кто уже такую задачу? в стандартных конфигурация все планы обычно привязываются к элементам и проблем нет...очень нужен совет..
---
Cool_vsi, Вам нужно разработать отдельный регистр, куда будете писать в "прямом" виде связи "элемент-группа-чего-нибудь-еще-что-понадобится". Регистр обновлять раз в час, например.
А потом - делать соединение с чем угодно по группам и элементам или каким-угодно-другим псевдообъектам 1С.
---
Cool_vsi, Вам нужно разработать отдельный регистр, куда будете писать в "прямом" виде связи "элемент-группа-чего-нибудь-еще-что-понадобится". Регистр обновлять раз в час, например.
А потом - делать соединение с чем угодно по группам и элементам или каким-угодно-другим псевдообъектам 1С.
---
Cool_vsi, А чем не устраивает планирование по номенклатурным группам?
---
alex_sh2008, А чем не устраивает планирование по номенклатурным группам?Факт работает по проданным позициям, а планирование - с более общей моделью: по группам.
Это Планирование и Бюджетирование, а не Бухгалтерия ))
---
AlexO, причем тут вообще бухгалтерия, когда речь о планировании
---
AlexO, можете поподробнее рассказать про дополнительный регистр накопления? не могу понять суть идеи
(15) alex_sh2008, к сожалению учет по номенклатурным группам не ведется
---
Cool_vsi, можете поподробнее рассказать про дополнительный регистр накопления?А зачем вам накопления регистр?! Связи между объектами удобнее всего хранить в регистре сведений, неподчиненном и непериодическом (хотя можете и периодическом - плюс, будете знать, когда кто "привязался" по времени :) )
---
Cool_vsi, Ну тогда может есть смысл ввести учет по номенклатурным группам, как ни странно но номенклатурные группы именно для планирования и были введены в учет.
---
Такие приколы очень любит руководство :)
Я бы предложил сделать регистр оборотный типа "План-Факт по продажам". С измерением "Показатель", ресурсами "План" и "Факт". Дальше наверное нужно каким то образом создать группы показателей и привязать к ней элемент и группы справочника. Возможно создать регистр сведений "Состав показателей" и справочник "Показатели".

Дальше... наверное с конца - при проведении реализации - делаем движения по факту. к какому показателю относить - смотрим в регистре сведений.
Ну и наверное документ "План продаж", который делает движения по плану. Показатель снова получаем из регистра сведений.

НУ а собрать отчет по такому регистру наверное уже не сложно.

Это очень приблизительно, так как не совсем понятно что значит каждый раз уровень иерархии может быть разный. Собственно наш справочник "Состав показателей" может быть иерархический и в отчет выводится по то иерархии, которая там задана. т.е. выподится будет не сама номенклатура а именно элемент того справочника.
Такой подход должен достаточно быстро работать, в противном случае отчет (если собрать без дополнительных объектов) будет достаточно громоздким и придется при любых изменениях настроения начальства его переписывать. В какой конфигурации работаете? Может это поможет другим коллегам что-нибудь предложить из типового.
---
1. Один запрос к продажам с итогами по иерархии номенклатуры, выгруженный в дерево значений
2. Один запрос плану продаж (регистру, документу, где указаны группы номенклатуры и планы), выгруженный в таблицу значений
3. Выборка таблицы значений и поиск группы из таблицы в дереве.
4. Профит

выигрыш в скороси должен быть на порядок.
---
spezc,
да, норм вариант. Но может не получится, если нужно будет вывести номенклатуру (или чего там продают) в собственной иерархии какой-нибудь сложной.
Типа: <Неважные товары>, а там внутри "Ботинки 47 размера" и "Рукава от безрукавок", в которые входят элементы разных групп.
Ждем расшифровки "причем каждый раз уровень иерархии может быть разный."
---
netesoff, под разным уровнем иерархии я имел виду что Есть группа "ГР1" в ней "ПодГр2","ПодГр3" в "ПодГр3" есть "ПодПОдГр4" и тд, и в разных группах разное количество подгруп, поэтому привязываться к Родитель.РОдитель не получиться.

(3) spezc, можно поподробнее, каким образом это реализовать?

(6) AlexO, к сожалению не получиться так сделать, уже думал, тк разные отделы устанавливают на разные подгруппы своим планы, то есть 1 элемент может входить в несколько групп, и например когда будет формирование по всему филиалу , будет непонятно какую цифру плана брать

конфигурация ут 10.3(10.3.12.3) но очень старая и очень сильно переписанная
---
Cool_vsi,
Ну норм. :) "под разным уровнем иерархии я имел виду что Есть группа "ГР1" в ней "ПодГр2","ПодГр3" в "ПодГр3" есть "ПодПОдГр4""
А планировать будут на ГР1 или могут на "ПодГр3" и "ПодПОдГр4"?
---
netesoff,
каждый отдел по своему, там еще у плана есть показатель менеджер, то есть для руководителя менеджеров может быть ГР 1, для какого то менеджера ПодГр1
а для кого-то ПодПодГр4
---
Cool_vsi, там еще у плана есть показатель менеджерОтлично, добавите еще и Менеджера, и Помощника менеджера, и авто менеджера ))
---
Cool_vsi, то есть 1 элемент может входить в несколько групп, и например когда будет формирование по всему филиалуНичего сложного: вводите еще аналитику "Отделы", и смотрите еще и по отделам. Тут в регистр можете вводить что угодно ))
А как тогда сейчас смотрите - ведь элемент не может принадлежать разным группам? О чем я и писал в (5 ), что элементы могут быть и не подвязаны к группам.
под разным уровнем иерархии я имел виду что Есть группа "ГР1" в ней "ПодГр2","ПодГр3" в "ПодГр3" есть "ПодПОдГр4" и тдВсе прекрасно реализуется на уровне таблиц.
(8) netesoff, А планировать будут на ГР1 или могут на "ПодГр3" и "ПодПОдГр4"?Как угодно и с чем угодно. А ваш вариант - лишь "кусочек" общей мозаики планирования: закрывает "типовой" вариант реализации бюджетирования "1 элемент - 1 группа" + непонятно-какой-план + непонятно-какой-отдел.
---
AlexO,
Ну пускай кусочек. Если нужно - можно добавить точно также разрез для формирования групп по отделам, менеджерам и чего там еще нужно.
В вашем случае, добавляя регистр - структура будет определятся непосредственно при формировании отчета? Т.е. куда и какой элемент факта относить. Получится ли достаточно быстро и однозначно определять принадлежность элемента? Ведь исходя из описания там может быть туча записей. Такой способ где-то уже использовали?
---
netesoff, структура будет определятся непосредственно при формировании отчета?Структура "чего" имеется ввиду?
Регистр нужен для фиксации и актуализации всевозможных связей. А будете в отчете его смотреть, или в обработке, или в документе - это не важно.
Получится ли достаточно быстро и однозначно определять принадлежность элемента? Насчет однозначности - все в ваших руках: как создадите поля, как их будете заполнять и актуализировать - так и будет "степень однозначности".
По поводу быстроты - мало что сравнится в 1С поиском в иерархии (собственно, для чего 1С и напрягалась столько лет - сделать "объектную иерархическую СУБД") по тормозам.
Ведь исходя из описания там может быть туча записей.Посчитайте связи между элементами. А потом - все возможные комбинации, когда придется искать "в иерархии". Все вытекает отсюда.
Такой способ где-то уже использовали?Это сугубо способ для вашей задачи. А сам принцип - использовался неоднократно.
---
spezc, выгруженный в дерево значенийА что, две ТЗ сравнить - это "проигрыш на порядок"?
3. Выборка таблицы значений и поиск группы из таблицы в дереве.
И какую группу в планах будете искать, если элементы к ней не подвязаны никак?
---
Слушайте, ребята, если я правильно понял проблему - то это не проблема вообще. Все делается одним запросом. В одну ТЗ (&План) засовываем все наши планы, в другую (&Факт) все данные по факту. Скорее всего их можно даже не засовывать, а получить запросами, но я не знаю как у топикстартера они хранятся. Дальше делаем такой запрос:

```1c
    ВЫБРАТЬ
    План.Группа,
    План.Кво
    ПОМЕСТИТЬ врПлан
    ИЗ
    &План КАК План
    ;

    ////////////////////////////////////////////////////////////­////////////////////
    ВЫБРАТЬ
    Факт.Номенклатура,
    Факт.Кво
    ПОМЕСТИТЬ врФакт
    ИЗ
    &Факт КАК Факт
    ;

    ////////////////////////////////////////////////////////////­////////////////////
    ВЫБРАТЬ
    Номенклатура.Ссылка,
    врПлан.Кво
    ПОМЕСТИТЬ План2
    ИЗ
    Справочник.Номенклатура КАК Номенклатура
    ЛЕВОЕ СОЕДИНЕНИЕ врПлан КАК врПлан
    ПО Номенклатура.Ссылка = врПлан.Группа
    ;

    ////////////////////////////////////////////////////////////­////////////////////
    ВЫБРАТЬ
    План2.Ссылка КАК Номенклатура_или_Группа,
    План2.Кво КАК КвоПлан,
    врФакт.Кво КАК КвоФакт
    ИЗ
    врФакт КАК врФакт
    ПОЛНОЕ СОЕДИНЕНИЕ План2 КАК План2
    ПО врФакт.Номенклатура = План2.Ссылка
    ИТОГИ
    СУММА(КвоПлан),
    СУММА(КвоФакт)
    ПО
    Номенклатура_или_Группа ИЕРАРХИЯ
```

И наслаждаемся результатом:
---
dusha0020, Все делается одним запросом.Вы будете удивлены - но в 1С вообще все делается запросами! Даже поиск по справочнику ))
---
AlexO, Я не просто удивлен. Вы меня провали...
---
dusha0020, Вы меня провали...Что-то я нехорошее с вами сделал...
---
dusha0020, идея конечно хорошая, но она в данном случае работать не будет , приведу пример:
элем1 храниться в ПодГр1 а подГр1 храниться в гр1

план установлен на Гр1, у элем1 родитель ПодГр1, которая не равна гр1...это самый простой пример, по факту бывает родителей от 1 до 12...поэтому сравнивать группу плана и группу элемента в данном случае бесполезно.

сейчас проверю что быстрее цикл запроса с условием иерархии или сравнение таблиц...эхъ =(
---
Cool_vsi, сейчас проверю что быстрее цикл запроса с условием иерархии или сравнение таблицне там копаете, вам сейчас намного важнее установить прозрачную связь элемент - группа - план (сотрудник, отдел, менеджер...), и чем прозрачнее будет - тем быстрее будет работать в 1С.
---
AlexO, какого рода связь должна быть? как мне константно установить связь на элемент-группа, если я не знаю в каком периоде отделы на какую группу будут устанавливать планы?
---
Cool_vsi, как мне константно установить связь на элемент-группа, если я не знаю в каком периодеДля начала - "разложите" в регистре все элементы по родителям (можете - 1 родитель - 1 поле, можете - родителей в строчку; во втором варианте не надо заботиться о глубине родительских каталогов, но придется терпеть накладные расходы на анализ и обработку строки).
Потом посмотрите, как в Планах выбирают группы - если они одни и те же (или повторяются циклично) - то и планы (отделы) можно включить в регистр следующим полем. И даже дополнительное поле - если вдруг еще какой-то отдел захочет "подключиться" к процессу по группе.
Но в любом случае, даже на первом этапе, у вас дело пойдет намного быстрее в соединении РС и планов (и РН), чем если справочники, иерархии в них - с РН и планами.
---
Cool_vsi, Еще раз повторю мысль: не важно кто родитель какого элемента. Вы берете весь справочник номенклатуры (со всеми группами и подгруппами) и соединяете его с планом левым соединением по совпадению. Получаете весь справочник Номенклатура с колонкой "План" для тех подгрупп, групп или даже элементов для которых установлен план. Затем получившуюся таблицу соединяете с фактом. Также слева и также по совпадениям и получаете колонку "Факт". Затем подводите итоги ПО ИЕРАРХИИ элементов справочника. Результат запроса вернет вам напротив каждой группы, подгруппы, подподгруппы и т.д. (сколько бы уровней вложенности в справочнике не было) итоги по плану и по факту. Если дальше Вам сложно отобрать только те группы (подгруппы и т.д) по которым был установлен план от тех по которым просто был подбит итог по иерархии можете выгрузить этот результат в ТЗ и соединить ее с таблицей плана. Опять по совпадениям ссылок, только на этот раз таблица плана слева. И все.
---
dusha0020, в факте только элементы, к сожалению связь или под запрос с условием в иерархии нельзя сделать
---
dusha0020, Вы берете весь справочник номенклатуры (со всеми группами и подгруппами) и соединяете его с планом левым соединением по совпадению. Собственно, он в заголовке темы в 1) так и делает. Только соединяет сразу все и с регистрами - для получения сумм.