Как избежать дублирования товара при наличии нескольких родителей?

Question

[Денис Тишин]

Здравствуйте,
Нестандартная ситуация, как по мне. Если стоит задача из обмена с 1С получить товар, у которого 2 родителя. Ну вот так случилось у клиента.

Не хочу при приходе 1 товара с несколькими родителями создавать копию товара и по нужным инфоблокам распределять.

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

Comments

[IvanU7n]

а множественный выбор в "Разделы" не оно?

[Денис Тишин]

IvanU7n, Я в описании написал что проблема из за структуры главных разделов, как отдельных инфоблоков и что товар предполагается лежать в нескольких инфоблоках

Answer 1

[koder_1]

Битрикс поддерживает у товара несколько родительских разделов, это штатный функционал.
А вот как вы сделали несколько родительских разделов в 1С? Научите?

Comments

[Денис Тишин]

в 1С делал не я, проблема именно не с разделами, а то что структура на сайте реализована так, что главные разделы - это разные инфоблоки. И вот под вопросом товары, которые с несколькими родителями (по сути в разных инфоблоках один и тот же товар должен быть). Вот с этим как решается?

Answer 2

[tgarl]

Если у вас каждый основной раздел это отдельный инфоблок, то товары у каждого свои, пересекаться они не могут и не должны. И для обмена разные инфоблоки не должны содержать элементы с одинаковым внешним кодом иначе ошибки полезут такие что рагзгребать будете долго.
Можно попробовать вариант добавить множественное свойство у товара "Привязка к разделам" и в него чтобы прописывалась связка с другим инфоблоком.

Comments

[Михаил Ливач]

я правильно понимаю, что по Вашему варианту в другом инфоблоке элементов не будет? Как-то это плохо выглядит.

[tgarl]

Почему же плохой вариант, вполне рабочий. Только каталоги придется формировать на основе фильтра по свойствам, а не полям. По такому варианту в свое время один из сторонних разработчиков вообще вывел хранение разделов в редис, а обмен каталога через ftp, типа там фильтрация в разы быстрее отрабатывает, каталог по фтп тоже на сайт выгружается быстро, правда весит десяток гигов, но он его опять же как-то умудрился обрабатывать очень быстро написав серверные скрипты не на php. Потом правда из-за конфликта с конторой которая этим проектом занималась мы отказались от такого и сделали похожее, свое, на справочниках HL. Сейчас уже конечно этого нет, вернулись к класике, все в одном инфоблоке, так как многие кто сталкивается с нестандартом, не понимают как с таким работать.

Answer 3

[Михаил Ливач]

насчет фильтрации по складам - не понял вопроса, а вот в публичной части проблемы наверняка будут. Потому что у вас второй инфоблок по сути будет без элементов.
Привязать элемент к двум инфоблокам нельзя, потому что это "зашито" в структуре БД.
Если взять идею tgarl и довести до логического предела, то получится так:
Допустим, у нас 5 корневых разделов , то есть 5 инфоблоков. Делаем шестой инфоблок без разделов, сваливаем туда все элементы. А у первых пяти добавляем в раздел множественное UF-поле с привязкой к элементам шестого инфоблока.
Я глубоко убеждён, что в публичной части штатный фильтр каталога работать не сможет.