Здравствуйте, есть запрос, чтобы данные представлялись в виде Иерархии папок номенклатуры:

|И ТоварыНаСкладахОстатки.Номенклатура В ИЕРАРХИИ (&ГруппаНоменклатуры)";


ГруппаНоменклатуры - ссылочный реквизит, который выбирает пользователь

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

В идеале желательно Определять по длине ее наименования ( меньше или 6)  и отсутствию пробелов в наименовании.

(0) Правильно - сделать для групп реквизит "НеПоказыватьВОтчете".

(0) в первом запросе - получаем все группы, собираем плохие группы в массив по условиям (длина, пробелы, цифры) и передаем во второй запрос параметром.

(1) Такой вариант не подходит, к сожалению.

(0) проверяй на шаблон, раз отдельное поле не хочешь делать. Вот тут есть небольшой пример v8: Проверка на число в запросе

(0) в тексте запроса пока только фильтр на номенклатуру. В каком месте у тебя иерархия при выводе ?
И что ты не хочешь видеть ?

(4) Спасибо! Буду смотреть.

Обычно, если бизнесу кровь из носу нужен какой-то криво определяемый признак, который они не хотят самостоятельно проставлять, я делаю просто:
1) добавляю этот признак в целевой объект
2) при записи объекта делаю его автозаполнение
3) профит

(7) > добавляю этот признак в целевой объект

Тогда уж еще
2.5) Прогоняю запись миллионов элементов, чтобы этот признак определился и терпеливо жду окончания обменов со всеми узлами =)

(8) Это очевидно. Но миллионы объектов случаются редко, ибо обычно эта хрень нужна для НСИ и прочей условно-постоянки.

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

(10) А это уже опыт, сын ошибок трудных. Ленивая жопа должна чуять, приходящая ли это блажь или с ней жить придется. И если второе - то эта соломка окупит себя многократно.

(11) А для первого случая имеются доп. свойства.

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

(13) где та тонкая грань, когда сложное условие превращается в доп реквизит? ПО мне так должно быть веское обоснование, чтобы менять структуру и утяжелять запись объектов.

(14) Где-то рядом с началом того конца, которым оканчивается начало.

Если серьезно, то грань не так уж и тонка. Если речь про условно-постоянную информацию, то скорость ее записи обычно не слишком критична а события записи редки по определению. Что дает достаточно большую свободу для маневра. Если уж это дает существенное "утяжеление записи объектов", то многократно это вычислять в разных местах - дороже тем паче.

И речь не про "сложное условие". Речь про полновесный атрибут. Который может маскироваться под незначительную хотелку. Вовремя его распознать - долг опытного разраба.

(16) вот мы и пришли к пониманию, что нужно оценить затраты системы на этот реквизит и понять перекрывает ли профит его использования эти затраты. К примеру, я знаю конфу одну, где каждый день под 200 позиций только новых заводится, в базе под полтора ляма номенклатуры. А выгрузка этой номенклатуры производится лишь раз в сутки, в этом случае добавлять реквизит и рассчитывать к примеру должна она выгружаться или нет при изменении остатков/заполняемости и т.д. каждый раз не имеет смысла. Если выгрузка на 5сек выиграет от этого, то бизнесу на это пофиг.

(17) + Долг перед самим собой :) Чтобы уменьшить себе количество работы в будущем.

(18) То есть внезапно оказалось, что универсальных рецептов нет и голову на плечах никто не отменял? :) Да, тоже каждый раз огорчаюсь.

(14) Например в (0) уже явно прослеживается наличие той грани :), где нужен явный признак , который будут ставить заинтересованные в нем люди. Слишком неопределенные условия , еще и не надежно реализуемые условия.

(0) Если конфа позволяет, то можно попробовать сегментировать номенклатуру, как вам хочется. А в запросах уже работать с нужными сегментами

(22) тогда и новый реквизит лепить не нужно и типовые механизмы используется.