Ограничение импорта свойств товаров
Свойства товаров в 1С имеют параметр "назначение", при указании которого это свойство применимо к товарам указанных разделов.
При импорте номенклатуры из 1С в XML описания товаров попадают только те свойства, которые этому товару соответствуют, и это правильное поведение.
Независимо от ограничения импортируемой номенклатуры и от проставленных "назначений" свойств, в инфоблок запишутся ВСЕ имеющиеся в 1C свойства.
То есть если решили создать два отдельных инфоблока на "мебель" и "компьютеры", расположенные в одной базе 1С, в ИБ "мебель" будут присутствовать свойства типа "Тактовая частота процессора", а в ИБ "Компьютеры" - "Материал столешницы"
Ситуация усугубляется, если в базе много разнородных товаров, и кол-во свойств велико (в моём случае >4000). В такой ситуации Битриксу становится очень тяжело работать с каталогом, да и менеджеру работать с товарами затруднительно. Кроме этого архитектура MySQL не позволяет хранить большое количество свойств в отдельной таблице, поскольку на свойство создаётся отдельный столбец (для UTF8 это 85 столбцов varchar(255) )
Ниже привожу фрагмент лога обмена, чтобы пояснить вышесказанное.
Проблема обнаружена при работе с модулем интеграции на стороне 1С: 4.0.5.1.
Считаю необходимым сделать ограничение на выгрузку только тех свойств, которые соответствуют выгружаемым товарам, а лучше, в дополнение к этому, позволить указывать в настройках обмена свойства, которые нужно выгружать.
При импорте номенклатуры из 1С в XML описания товаров попадают только те свойства, которые этому товару соответствуют, и это правильное поведение.
Независимо от ограничения импортируемой номенклатуры и от проставленных "назначений" свойств, в инфоблок запишутся ВСЕ имеющиеся в 1C свойства.
То есть если решили создать два отдельных инфоблока на "мебель" и "компьютеры", расположенные в одной базе 1С, в ИБ "мебель" будут присутствовать свойства типа "Тактовая частота процессора", а в ИБ "Компьютеры" - "Материал столешницы"
Ситуация усугубляется, если в базе много разнородных товаров, и кол-во свойств велико (в моём случае >4000). В такой ситуации Битриксу становится очень тяжело работать с каталогом, да и менеджеру работать с товарами затруднительно. Кроме этого архитектура MySQL не позволяет хранить большое количество свойств в отдельной таблице, поскольку на свойство создаётся отдельный столбец (для UTF8 это 85 столбцов varchar(255) )
Ниже привожу фрагмент лога обмена, чтобы пояснить вышесказанное.
Проблема обнаружена при работе с модулем интеграции на стороне 1С: 4.0.5.1.
Считаю необходимым сделать ограничение на выгрузку только тех свойств, которые соответствуют выгружаемым товарам, а лучше, в дополнение к этому, позволить указывать в настройках обмена свойства, которые нужно выгружать.
Похоже на глюк выгрузки, так быть не должно. Может Битриксы оптишутся, когда исправят.
Во всех старых обменах выгружались только свойства, которые заполнены у выгружаемых товаров.
Некритично, но если вдруг вы начнете выгружать по 10 товаров, то каждый раз придется перезаписывать 4000 свойств.
Во всех старых обменах выгружались только свойства, которые заполнены у выгружаемых товаров.
Некритично, но если вдруг вы начнете выгружать по 10 товаров, то каждый раз придется перезаписывать 4000 свойств.
| Похоже на глюк выгрузки, так быть не должно. Может Битриксы оптишутся, когда исправят. |
| Во всех старых обменах выгружались только свойства, которые заполнены у выгружаемых товаров. |
| Некритично, но если вдруг вы начнете выгружать по 10 товаров, то каждый раз придется перезаписывать 4000 свойств. |
А вот попробуй изменить товар, у которого 4000 свойств, настроить компонент для их вывода, изменить ИБ, настроить фильтр товаров?
Это критично!
4000 - это дофига.
Мы в свое время научились делать производительные сайты на одном инфоблоке с тысячами свойств. И в разы ускорили обмены модулем "", опцией "Быстрая запись свойств".
В наших сайтах все свойства были нужные, потому что каждое свойство хотя бы у одного товара было заполнено.
Я совершенно согласен с вами, что неправильно то, что дополнение выгружает все свойства. Даже те, которые не заданы ни у одного товара.
Ненужные тысячи свойств - это большая проблема, и её надо как-то до Битрикса донести, чтобы разобрались.
Мы в свое время научились делать производительные сайты на одном инфоблоке с тысячами свойств. И в разы ускорили обмены модулем "", опцией "Быстрая запись свойств".
В наших сайтах все свойства были нужные, потому что каждое свойство хотя бы у одного товара было заполнено.
Я совершенно согласен с вами, что неправильно то, что дополнение выгружает все свойства. Даже те, которые не заданы ни у одного товара.
Ненужные тысячи свойств - это большая проблема, и её надо как-то до Битрикса донести, чтобы разобрались.
| Для каждого инфоблока можно задать отборы. Один из отборов - свойства. Т.е. установив этот отбор - для инфоблока будут выгружаться только свойства удовлетворенные отбору. |
Отбор можно сделать для настройки обмена в целом, но не для каждого инфоблока, если они создаются в рамках одной настройки обмена .
Согласитесь, не учитывать назначение свойств, а отмечать их руками в обмене - это колхоз.
© 2001-2023 «Битрикс», «1С-Битрикс». Работает на 1С-Битрикс: Управление сайтом.
Соглашение об использовании сайта
Соглашение об использовании сайта
У вас эти отборы не заполнены, в результате чего - выгружаются все свойства.
Идею закрываю, у нас сделана очень гибкая система в этом плане, и исправлять не чего не нужно, нужно вам только разобраться.
Попробуйте почитать: