Состав заказа является массивом данных, соответственно, работа с ним ведется с помощью специальных фильтров созданных в pipeLang, в данной статье мы разберем работу с фильтрами в разрезе состава товаров в триггерах и валидациях.
Важно!
В условии применении типов цен синтаксис обращения к товарам будет отличаться от обращения к ним в триггере или валидации, так как тип цены применяется к товарной позиции, которая не является массивом данных.
Ознакомится и подобрать подходящий для нужного вам кейса фильтр, можно в статье Язык выражений. Рассмотрим триггер, который будет реагировать на перевод заказа в статус "Выполнен" с проверкой, что в составе заказа все товары имеют статус "Продан" и отправлять письмо клиенту, с просьбой об отзыве.
Укажем в коде триггера следующий код:
changeSet.hasChangedField("status") and changeSet.newValue("status").code == "complete" and order.availableOrderProducts | every(item => item.status.code == "saled")
В данном коде используется фильтр every, который даст сработать триггеру только в случае, если все элементы массива удовлетворяют условию, которое указанно в скобках.
Рассмотрим популярный кейс триггера, который производит проверку, что в заказ добавляется товар из определенного перечня товаров и устанавливает задачу на ответственного менеджера по добавлению подарка в заказ.
Создадим триггер со следующим кодом:
changeSet.hasChangedField("order_product") and changeSet.newValue("order_product") and order.availableOrderProducts | contains (item => item.offer.id in ["1","2","3"])
Примечание
Идентификаторы торговых предложений можно посмотреть в ICML каталоге товаров.
В данном триггере использовался фильтр contains, который вернет успешный результат проверки в том случае, если условия указанные в скобках фильтра удовлетворены в заказе.
В pipeLang существует фильтр reduce, который может агрегировать необходимые элементы в массиве и вернуть агрегирующий результат.
Рассмотрим триггер, который просуммирует значение габаритов товара из дополнительных свойств товара, которые были заведены в ICML каталоге и запишет полученный результат в соответствующие поля габаритов в заказе, в момент добавления новых товаров в состав заказа, либо их удаления.
Примечание
С помощью фильтра reduce триггер сможет осуществить математическое действие только с доп.свойствами без специальной обработки, то есть те, которые добавлены через тег param.
Добавим следующий код в триггер:
(changeSet.hasChangedField("order_product") and changeSet.getNewValue("order_product")) or (changeSet.hasChangedField("order_product") and changeSet.getOldValue("order_product"))
В действие триггера выберем изменение поля "Высота", в выражении укажем:
order.availableOrderProducts | reduce( (sum, x) => sum + x.offer.properties.height * x.quantity )
Данный код сработает для всех товаров в заказе и просуммирует значение их доп.свойств с символьным кодом height. С помощью аналогичного кода можно применить данный кейс и для других полей габаритов, "Ширина" и "Длина" изменив лишь символьный код доп.свойства на соответствующий.
Практически все интернет-магазины ведут остатки товаров с специализированных складских системах, и выгрузка или загрузка остатков может происходить по событию перевода заказа в определенный статус, чтобы исключить ситуаций, когда менеджер забывает произвести бронирование товара в заказе и переводит его в статус отгрузки, создадим валидацию, которая будет срабатывать на изменение статуса заказа, с проверкой массива с составом товаров на наличие в нём не пустого массива с паками:
changeSet.hasChangedField("status") and changeSet.newValue("status").code == "send-to-assembling" and not order.availableOrderProducts | every (item => item.packs | contains (pack => pack))
Для создания условие применения типа цены не придется всегда использовать pipe фильтры, потому что тип цены применяется к одной товарной позиции и соответственно не является массивом. Сформируем код, который будет применять необходимый нам тип цены если покупатель приобретает 10 и более штук одной позиции:
item != null and item.quantity >= 10