Есть подчинённый справочник. Я правильно понял, что вводимый элемент в этом справочнике может быть подчинён только Элементу (но не группе) основного справочника?

Как обойти данное ограничение?

Никак, это ограничение платформы, меняй архитектуру решения.

Хотел было предложить устроиться в 1с и внести исправления в код, но увидел, что это 77...
Я думаю, что исходников там уже не найти...

Ясно. Значит подчинённый Справочник будет "idГруппа, idПодчинённый"

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

(4) Всё верно, это и есть (3)

Просто красивей, когда через подчинённый справочник это реализовано. Уже сделал, и по факту увидел, что для групп это не работает

(6) вопрос привычки.
часто иметь плоский справочник удобнее.
все равно запросами/отборами все что надо вытаскивается.

(7) Стандартный подчиненный платформа еще на экране нормально отображает.

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

(9) это имеет смысл для "свойств", например. например, за группу номенклатуры отвечает какой-то категорийщик.
табчастей-то в клюшках "по умолчанию" нет

(10) емнп можно было добавлять свои реквизиты как свойство номенклатуры в ТИС

(10) Всё верно. Задача стояла такая: импортируются в 1с новые товары программно, например "оперативная память".
Все эти товары попадают на 1й уровень справочника "оперативная память".  А их нужно распределить по подчинённым группам (ddr2 ddr3 dd4 и т.д.).
Вот для этого и нужно определить свойства для этих подчинённых групп (эти же свойства уже есть на новых товарах).

И так для всех групп товаров Номенклатуры

(12) как-то сложно все ... тут фигурирует смена родителя (а владелец - это когда элементы одного справочника подчинены одному элементу другому)

(12) а в чем проблема? понять что "оперативная память" из прайса должна типа автоматом попасть в группу со "свойством" = "оперативная память"..?

(13) (14)
В базу 1с импортируется прайсы поставщиков. В них постоянны появляется много нового товара. В прайсах есть поле "группа товара". Т.к. прайсы поставщиков в большинстве своём - одноуровневые
В 1с - 3 уровня товаров.
https://prnt.sc/13h7zbh
Задача - все новые товары распределить по "правильным" группам

Вот поэтому на эти группы товаров нижнего уровня и нужно один раз определить руками связки "СвойствоТовара, ЗначениеСвойства"
пример: для папки в 1с "DDR-3 8Gb" в подчинённом справочнике определяем руками
СвойствоТовара = "Объём памяти"
ЗначениеСвойства = "8Гб"

На новых товарых "ЗначениеСвойства" парсится с онлайн-сервисов.

После этого мы можем всю память , которая имеет "Объём памяти" = "8Гб" занести в нужную папку

(11) свойство номенклатуры в ТиС - оно и привязывается, емнип, только к элементу

(17) да

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

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

(17) шттано программно подчиненному элементу назначить владельцем группу - не получится тоже

(20) https://prnt.sc/13h8bvp
вот так у меня :)

(20) Свойства у меня парсятся естественно сами , с  onliner.by

Заваял примерно месяц. вот что на выходе:
https://f1shop.by/
тоже нравится, довольно сложный алгоритм чтения и обработки характеристик, имеют в т.ч. и единицу измерений, т.е. Значение не тупо строка а может быть и числом
Т.е. Свойства поддаются фильтрации на сайте
https://prnt.sc/13h8jmb

(19) > "сделай справочник "группа,свойство,значение"
так я так и сделал ), /на скринах видно/

>или в типовой Спр.СвойстваНоменклатуры добавь реквизит "Группа"
так не пойдёт. этим проблему не решить (потому что группа может определяться набором нескольких свойств)

п.с. Неделю думал, как же автоматизировать перенос всех новых товаров из группы Номенклатуры "Не разнесённые" в нужные подгруппы.
уже расстроился, что решения нет. но на 7й день осенило :)

(25) >>группа может определяться набором нескольких свойств
так классическая игра "животное" жеж... придумано лет 40 назад

(24) нууу....... весьма частное решение. негибкое...
имхо если делать по уму то что-то типа
правило "ключ, значение, плугин-для-обработки" (плугин реализует частную обработку значения)
и делать последовательность правил для разбора, где например значение на первом уровне разбирается на ключ(и)-значение(я) нижележащего уровня...
.
сильно не думал

(27) > нууу....... весьма частное решение. негибкое...

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

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

У меня это получается очень легко реализовать, потомучто мои новые товары уже имеют определённые формализованные свойства.

И здесь программный код дополнительный не нужен

(26) Да, сложность не в этом была. Это мелочь естественно.
Я просто упустил изначально, что для всех мои новых товаров автоматизированно определяются значения их свойств/характеристик

(28) "и юзеры их руками разносят. И автоматизировать этот процесс разноса по нужным папкам очень сложно, во многих системах почти не реально."
- потому что у меня ассортимент небольшой.

(27) ты изобретаешь регистры правил? :-)

(28) "потомучто мои новые товары уже имеют определённые формализованные свойства."
- это частное решение потому что (например, у тебя прайс по всем товарам с одной площадки). Поэтому "просто". пока.
если появятся новые "поставщики" прайсов - ты сразу упрешься в охеревание от альтернатив. И будешь строит чтото подобное "плугинам". Я такое проходил давным-давно, более 15 лет назад, на фармации, когда под 15 прй1асов поставщиков (фармация) засасывал в базу. у каждго - свой формат и свои тараканы. в итоге, под каждый прайс писался отдельный "плугин нормализации" прайса под типовой вид, который (типовой) уже потом уже обрабатывался единственным модулем загрузки/обработки.
.
потом такую систему плугинов хотел запилить в районе 2010г на торговле дисками/фильмами - там вообще с прайсами трэш страшный был (Маня с его мегапрайсом и универсальной загрузкой слился), но в итоге чуть по другоум сделал намного проще(хуже) ибо бюджет мелкий был

(31) не, мне влом ;-) ТС чтобы херней не страдал, а хоть как-нибудь бы рос профессионально. Хотя может это и не надо ему...

(33) а кто сказал, что он страдает? он ей наслаждается...

(32) Я всё это прекрасно понимаю.

>это частное решение потому что (например, у тебя прайс по всем товарам с одной площадки). Поэтому "просто". пока.
Твой программный "плагин-код" врядли сильно поможет в разнесении новых товаров, это тотже ручной труд :)

У меня есть не один поставщик , а много поставщиков. И я импортирую их прайсы, но да, сложно их увязать , т.к. разношёрстные они
Но сейчас ситуация поменялась, т.к. я получил доступ  к площадке "onliner.by" и привязываюсь к ней

Их огромный каталог я пропарсил и формализовал, и другие прайсы уже намного проще увязать по "АртикулуТовара"
Для 90% товара Артикул есть во всех прайсах, и по нему можно делать увязку. Мне этого достаточно.

Задача стоит иметь свой виртуальный склад товаров и продавать из него. Ничего страшного если в нём будет 90% а не 100% от нужного рынка

Вот так выглядят прайсы:
https://prnt.sc/13h9ze6

(34) Я бы сказал что просто использую )

ну и ок.
"Твой программный "плагин-код" врядли сильно поможет в разнесении новых товаров, это тотже ручной труд :)"
плагтины обрабатываю данные из прйасов отнсоя их на нужные сущности (то есть формализируя), а когда позиция из прайса "ДДР3" формализована как "память DDR3" и автоматом привязана - то разноска уже практически автоматическая...
как-то так...

(36) ну вот не хватит у тебя для очередного файла прайса колонки нужной - ну нет ее в твоем спр.ФайлыПрайсов
в ы другом файле - то что у тебя в дувух колонках описываетяс в этом файле запихнуто строкой в одну коолонку...

(38) Объясню:
Мне повезло, есть один поставщик, в прайсе которого 71 тыс  позиций товара. Это охват 80% моего рынка. Я продаю сейчас 5%.
В этом прайсе почти для каждого товара есть ССЫЛКА НА ОНЛАЙНЕР. Поэтому все эти товары я могу проимпортировать и запарсить характеристики товаров.
Все новые товары из него будут разнесится автоматически по нужным папкам Номенклатуры (пока этого нет и это проблема - куча ручного труда)

Ну а далее под этот большой каталог парсятся все остальные прайсы. По артикулу. И пусть они парсятся на 70%, это не страшно. Они ведь парсятся только для поиска "лучшей цены поставщика"
Сам то каталог уже есть у меня в базе/на сайте


>ну вот не хватит у тебя для очередного файла прайса колонки нужной - ну нет ее в твоем спр.ФайлыПрайсов
если будет большая потребность в этом новом прайсе нового Поставщика, я модернизирую единый свой алгоритм :).
Это проще чем то что ты предлагешь - изначально в движок закладывать на прайс "ссылку на процедуру" . Здесь это не нужно

(40) ну да, просто потму что у тебя вриативность малая, поэтому как ты сделал - ну и норм будет.

(41) Да, это точно не подходит для дисков или формацевтов :))

(42) это ваще мало для чего подходит.
особенно для лавочников. сегодня от чехлами торгует, завтра бытовой химией. а перед новым годом вязаными шапочками. и везде хочет до каждой копейки дтянуттся... а ресурса - нема... ;-)

(43) Это подходит для техники. Мне достаточно