Настройки поиска

2. линковка значений свойств товаров через таблицу product_prop_link понятна, для фильтров работает.
В форме выбора тоже нормально.

но непонятно зачем в таблице торговых предложений product_offer все свойства без проверок писать в propsdata
при таком подходе (связывание по строке а не по id свойства + id значения) ошибка делается очень просто

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

хороший пример из 1С, тип "Дополнительное значение" = на сайте "Список"
Выбор в номенклатуре = "Товар":
http://c2n.me/3DQ5YXK
Выбор в характеристике = "Комплектация"
http://c2n.me/3DQ6eLV

При настройках номенклатуры:

http://c2n.me/3Dlt0m6

и настройках упаковок

http://c2n.me/3Dlt2vY

файл выгрузки типовой обработки остается прежним (перевел в JSON - удобнее читать)

http://c2n.me/3Dlt8EX

Это решается корректировкой шаблона формы.
"В наличии" = "10000 шт.".

"работают под заказ или частично под заказ" - статус товара "Под заказ"

Для размышления:
API это средство доступа к объектам внутри системы, отражающее "доверие" разработчика системы к сторонним разработчикам.

Для себя сделал обертку для Битрикса, которая может обращаться к основным классам, понятно что могу "чего нибудь сломать" при работе с этим API но зато "мощности" хватает под мои задачи, шлю все POST пакетом команд.

Пример:

{
  "commandList":[
    {
      "number": 1,
      "module": "catalog",
      "class": "CCatalogStoreProduct",
      "method": "GetList",
      "parametres":  {
        "arOrder": null,
        "arFilter": null,
        "arGroupBy": null,
        "arNavStartParams": null,
        "arSelectFields": []
      }
  
    },
    {
      "number": 2,
      "module": "sale"
    },
    {
      "number": 3,
      "module": "shop"
    }
  ]
}

"В текущий момент, вам возможно будет проще разработать более простой консольный импорт/экспорт файлов вашего формата"

Цель в том чтобы вложить силы в формирование базы товаров со стороны 1С, после на основе API грузить с корректировками на сайт.

Пример: профили, которые включают плинтусы, порожки и.т.д.,
в группе более 10 "характеристик",
по части из которых фильтрация в списке,
по части формирование наименований "комплектаций" и отбор в карточке товара.
часть с множественным выбором (профиль может крепиться и на потолок и на стену)

+ задумка в том что "комплектация" она же SCU представлена в 1С как элемент справочника "Номенклатура" без характеристик, т.к. по части профилей есть и вариации по ширине в рамках одной модели.

Решаю за счет группировочного поля. (+ получаю бонус отсутствия перекоса себестоимости в бух учете)

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

Делать файл выгрузки и после писать обработчик загрузки на сайт замучаюсь, проще API сделать.

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

Логика свойств комплектаций: все свойства товара есть объединение свойств его комплектаций.
Варианты формирования комплектаций:
1. Сверху вниз, указали свойства в товаре, сгенерировали комплектации со свойствами, но не всегда есть полные "линейки" товаров
2. Снизу вверх, занесли комплектации и свойства по ним, после собрали их в карточке товара.

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

Этот вопрос частично решен в HostCMS, у них все "комплектации" по сути тоже товар со скрытым родителем и они могут позволить вывести все дочерние элементы списком.