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

Есть иерархический справочник, номенклатура.


Группа_1__________________|__2__
__Подгруппа_1_____________|__6__
_____Подподгруппа_1_______|_____
____________Элемент_1_____|__12_
____________Элемент_2_____|_____
_____Подподгруппа_2_______|__14_
____________Элемент_3_____|__8__
____________Элемент_4_____|_____
Группа_2__________________|_____
__Подгруппа_2_____________|_____
_____Подподгруппа_3_______|_____
____________Элемент_5_____|_____

Первый столбец - собственно номенклатура, второй столбец - порядок номенклатуры в конечном итоге.
Все подчиненные элементы группы (Например "Подподгруппа_1","Элемент_2", "Элемент_4") с заданным порядком ("Подгруппа_1", "Подгруппа_2") должны иметь порядок равный порядку родительской группы (6, 14), если таковой задан, за исключением номенклатуры, для которой задан свой порядок ("Элемент_1", "Элемент_3").

На выходе из исходной хочу такую таблицу:

Группа_1__________________|__2__
__Подгруппа_1_____________|__6__
_____Подподгруппа_1_______|__6__
____________Элемент_1_____|__12_
____________Элемент_2_____|__6__
_____Подподгруппа_2_______|__14_
____________Элемент_3_____|__8__
____________Элемент_4_____|__14_
Группа_2__________________|_999_
__Подгруппа_2_____________|_999_
_____Подподгруппа_3_______|_999_
____________Элемент_5_____|_999_

Как построить запрос?

А надо именно запросом? Другие средства не приемлимы?

если я правильно понял задачу, то нужно выводить сначала иерархию без элементов, а потом ниже уровнем - только элементы, и соответственно два поля упорядочивания

Именно запросом, потому как итоговые данные необходимо потом сунуть в ВТ_для джойна в другом запросе.
Это вывод прайса, клиент попросил задавать порядок номенклатуры в прайсе.
Можно конечно данные обработать сперва не в запросе, а затем сунуть ТЗ в ВТ, но я даже не подумываю об этом, так как позиций номенклатуры - тысячи и для каждой делать множественные запросы в бд - убийство времени..4Оптимальнее всего запрос

(2)эммм... не совсем понял, но скорее всего нет..

(3) сделай иерархию запросом с твоими порядками, обойди циклом, потом в ВТ и запрос окончательный

(0) а почему элемент 1 идёт раньше элемент 2 ?

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

(5) держу как запасной вариант..

(6) Потому как я представил в данной визуализации структуру справочника и соответствие значения порядка элементам.
Это не результат запроса или что-либо в этом роде.

(7) тогда "порядок" придется обслуживать обработкой (для новых элементов справочника номенклатура).
Так же писать код обработчиков при смене родителя (ПриЗаписи), и т.д.и т.п.
Не совсем верно...

Сейчас порядок номенклатуры хранится в очень простеньком РС.
Ключи: Номенклатура
Значение: Порядок

(9) В таком случае режим "обслуживания" придётся реализовывать при каждом запросе.

Можно было бы сделать аналогию срезу последних, только не по датам, а по значению поля "Уровень", но..... Нет в запросах Уровня :( А даже если бы и был - один фиг это сильно бы тормозило, потому как узнать уровень кроме как родитель.родитель.родитель не представляется возможным :(

(11)Ваша правда, от части...

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

ну а по сути: быстрый отчет = хранение данных в базе
динамические расчеты - тормоза

Помнится в 77у справочника было свойство ПолныйКод(). Нечто аналогичное можно реализовать в регистре сведений, имя вторым ресурсом аналогичную последовательность.
А обработку обслуживания можно запускать периодически регламентным заданием, чтобы не писать в события.

(8) у него порядковый номер больше, должен быть после

(14)им и нужна своя, настроенная "каша"..

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

Хотя.. этот костыль наиболее гладко решает задачу..
Прицеплюсь ка я к подписке ПриЗаписи... И обработкой единожды задам порядок. А далее при записи система будет этот порядок, или кашу, кому как больше нравится, поддерживать сама..

(16) в примере иерархия представлена в порядке справочника. Там еще ничего не сортировалось по полю "порядок"

Главное обработать правильно все варианты (Пустой родитель, у родителей всех уровней нет порядка, записывается новый элемент в корень и т.д.)

(17) а если есть две или больше группы нулевого уровня, которых нет в регистре, у них у всех 999?

А каким образом заполняется регистр сведений для упорядочивания? Руками или обработкой?

(19)Да.. У них да, у подчиненных элементов тоже да, если не задан порядок индивидуально

(20) обработкой. Пользователь набивает в него группы, подгруппы, сортирует стрелочками, жмакает "записать"

Оппаа

(21) а вложенность справочника какая?

Вот точно одна голова хорошо, а много - змей горыныч..

Не имеет смысла задавать порядок у подгрупп и элементов. И задачи такой не озвучивалось.. Уточню у заказчика.. Похоже это я уже выдумал "на все случаи жизни"

(22) В эту обработку и запихни пересчет порядка.

(27) Лучше "при записи", потому как если только обработкой - то гонять ее нужно будет после каждой записи номенклатуры (новой старой - пофиг). Только это будет происодить не автоматом как через подписки а в ручном режиме или регламентном задании, что больше путаницы создаст пользователям

(27) да ладно, если в лоб, то это запрос с УровеньИерархииСправочика - 1 временными таблицами

(28) Хозяин - барин. Но я сторонник минимализма. Пока пользователь вводит изменения в регистр сведений, он вряд ли будет формировать прайс. Поэтому сразу использовать подписку при записи - это с большим запасом. Но если ты уже эту подписку внедрил раньше, то конечно.

(30) Да, он не будет в 2 копиях программы одновременно вводить порядок и тут же во втором формировать прайс. По этому последовательность действий вполне допустима, но... Дело не только в последовательности, но и в перемещении номенклатуры из группы в группу. И в создании новой номенклатуры.
Если пользователь создал номенклатуру, внес ее в группу, ему придется не забывать попросить ответственного перезаписать значения порядка обработкой.
Как результат
1) человеческий фактор забывчивости\"забивчивости"
2) увеличение стоимости обслуживания данных в человеко-часах (если угодно - в человеко-минутах). Смысл..? Тут уже само решение (подход) будет похоже на костыль. А если таких доработок будет много - пользователям много чего придется держать в голове, что не есть гут..

нет, саму подписку я еще не внедрил, но собираюсь.