Bitrix: Как отфильтровать по свойству SKU?

Question

[Максим Гречушников]

Можно ли, как-то используя arrFilter, отфильтровать по свойству SKU?
В частности вывести лишь те товары у которых доступное кол-во > 0

>QUANTITY = 0 не предлагать. он фильтрует сам товар, а не SKU

Answer 1

[Алексей Емельянов]

Попробуйте использовать подзапросы:

array("ID" => CIBlockElement::SubQuery("ID", array("IBLOCK_ID" => 1, ">PROPERTY_QUANTITY" => "0"))),

где "IBLOCK_ID" => 1 - это ИБ товарных предложений

Comments

[Максим Гречушников]

Благодарю вас. А вот тех поддержка, что ответила: "Других стандартных вариантов решения этой задачи нет."

[Алексей Емельянов]

Максим Гречушников: не торопитесь благодарить, я делал выборку не используя стандартные компоненты. Неизвестно удастся ли передать это условие во внутрь компонента catalog, а ТП наверняка имела ввиду его.

[Александр Маджугин]

Алексей Емельянов: Почему не удастся если это сунуть в фильтр - отлично будет работать.
Только был какой-то способ проще и без подзапроса. Пару дней назад наткнулся на такой же вопрос в другом месте и вспоминал-вспоминал - не вспомнил. А способ был...

[Максим Гречушников]

Алексей Емельянов: получилось. потому и благодарю. я сразу же попробовал решение.

[Алексей Емельянов]

Максим Гречушников: крутяк

[Алексей Емельянов]

Suntechnic: можно обойтись и без подзапросов, но понадобится финт ушами: нужно добавить обработчик события на изменение/добавления элементов ИБ товарных предложений, в котором в "родительский" элемент добавлять ссылки на все элементы товарных предложений (будет множественное св-во PROPERTY_SKU) и тогда выбирать можно будет вот так: ">PROPERTY_SKU.PROPERTY_QUANTITY" => "0"

[Максим Гречушников]

Алексей Емельянов: Думал о таком. но мне показалось правильней как можно сильнее придерживаться стандартного поведения битрикса

[Александр Маджугин]

Алексей Емельянов: Да это понятно. Но это денормализация а значит плохо.
Возможно я путаю и это был какой-то компонент у которого внтури подзапрос сидел...

[Алексей Емельянов]

Suntechnic: ну не знаю, третья нормальная форма это сугубо академическая сущность, в реальной жизни бывает полезно от неё отступить. В случае с SKU мне кажется более правильной двунаправленная связность элементов, т.е. товарное предложение знает свой родительский товар, а товар знает все свои товарные предложения. В идеале товарное предложение ещё должно знать своих "соседей" по товару - да избыточность, но зато сложность запросов падает на порядок. А что бы следить за целостностью модели нужно на крон вешать скрипт который будет бегать по БД и проверять связность.