Как настроить триггерную цепочку?
Скопировать ссылку на статью
Скопировано

Информирование о местонахождении долгожданной посылки в настоящее время стало обязательным, если мы хотим получить только положительные отзывы о работе магазина. В данной статье мы разберем возможность настройки автоматического информирования клиентов, от отправки трек-номера до контроля забора посылок из ПВЗ, путём настройки триггерной цепочки

1. Отправка трек-номера клиенту при оформлении доставки

Под оформлением доставки подразумевается отправка заявки в интеграционную службу доставки, которая подключена к системе, и присвоение трек-номера в соответствующем поле заказа.

Сформируем код триггера, который будет отправлять необходимую нам коммуникацию клиенту.

Сначала укажем, на какое изменение заказа будет срабатывать триггер, а именно изменение трек-номера в заказе, с дополнительной проверкой, что новое значение трек-номера не пустое. Это требуется для предотвращения случаев отправки клиенту коммуникаций без трек-номера, например, при отмене заявки на доставку трек-номер будет удален из заказа.

changeSet.hasChangedField("integration_delivery_data.track_number") and changeSet.newValue("integration_delivery_data.track_number") != null

Данный код идентичен для всех служб доставки.

Примечание

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

Если требуется разграничить отправку разных коммуникаций для разных типов доставки при изменении трек-номера в заказе, то к имеющемуся коду необходимо добавить условие:

order.deliveryType.code == "russian-post"

где, вместо "russian-post" необходимо указать символьный код типа доставки, для которого должен сработать триггер.

Дополнительно к получившемуся коду можно добавить условие, которое предотвратит повторный запуск триггера в случае, если первый запуск уже был осуществлен (подробнее в статье "Как избежать повторного срабатывания триггера"):

not last_run("1 days")

Готовый код для данного кейса:

changeSet.hasChangedField("integration_delivery_data.track_number") and changeSet.newValue("integration_delivery_data.track_number") != null and order.deliveryType.code == "russian-post" and not last_run("1 days")

2. Отправка информации о передаче заказа курьеру

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

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

changeSet.hasChangedField("integration_delivery_data.courier") and changeSet.newValue("integration_delivery_data.courier") != null

Дополнительно к данному коду необходимо добавить проверку по установленному в заказе типу доставки, так как проверяемое в вышеуказанном коде поле integration_delivery_data.courier имеется только у типа доставки, который интегрирован с "Курьерской доставкой":

order.deliveryType.code == "courier"

где, вместо "courier" необходимо указать символьный код типа доставки, который интегрирован с модулем курьерской службы.

3. Информирование о прибытии посылки в ПВЗ

Важная часть автоматизации и контроля выкупов заказов из ПВЗ - это информирование клиентов о том, что их посылка находится в пункте выдачи службы доставки.

Как правило, службы доставки уведомляют интернет-магазины о прибытии посылки в ПВЗ с помощью статуса доставки. Для реализации необходимого нам кейса предварительно необходимо выполнить настройку соответствия статусов доставки в модуле интеграции со службой доставки, для которого мы настраиваем триггер (подробнее о данном процессе можно прочитать в статье "Службы доставки").

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

Родительский триггер будет содержать следующий код:

changeSet.hasChangedField("status") and changeSet.newValue("status").code == "delivered"

с проверкой на необходимый тип доставки следующим кодом:

order.deliveryType.code == "sdek"

В действии триггера выберем необходимый нам шаблон коммуникации с информацией о том, что заказ доставлен в пункт выдачи.

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

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

Событием триггера будет "После срабатывания триггера для заказа", в поле "После триггера" - выбираем ранее созданный, родительский триггер, в поле "Через" - указываем необходимое количество дней, через которое сработает триггер и отправит коммуникацию клиенту, например:

2 дня

Примечание

В поле "Через" отложенного триггера необходимое количество дней указывается с учетом склонения, например: "1 день", "2 дня", "6 дней".

В коде отложенного триггера добавим проверку, что статус заказа, на который срабатывает родительский триггер, до сих пор не изменился, то есть в течение 2х дней заказ не забрали из пункта выдачи:

order.status.code == "delivered"

В действии триггера выберем нужную коммуникацию, с напоминанием, что заказ уже прибыл в пункт выдачи.

В случае, если требуется отправить напоминание повторно, через какое-то время, то можно создать еще один отложенный триггер, но в поле "После триггера" необходимо выбрать ранее созданный отложенный триггер.

4.Фиксирование расхода на доставку

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

Создадим триггер, который будет добавлять себестоимость доставки как отдельный расход по заказу в момент его выполнения.

В коде триггера укажем:

changeSet.hasChangedField("status") and changeSet.newValue("status").code == "complete"

В действии триггера выберем "Добавить расход".

Из выпадающего списка выберем подходящую для нас статью расходов. В поле "Сумма" укажем следующий код:

order.deliveryNetCost

В поле "Дата" зафиксируем текущую дату с помощью кода:

date("now")
Благодарим за отзыв.
Была ли статья полезна?
Нет
  • Рекомендации не помогли
  • Нет ответа на мой вопрос
  • Текст трудно понять
  • Не нравится описанный функционал
Да
Предыдущая статья
Как избежать повторного срабатывания триггера?
В статье описаны возможные причины повторного срабатывания триггера по одному и тому же условию, а также варианты решения подобной ситуации.
Следующая статья
Работа с товарами в триггерах, валидации и типах цен
Состав заказа является массивом данных, соответственно, работа с ним ведется с помощью специальных фильтров созданных в PipeLanguage. В статье разберем, как работать с фильтрами в типах цен, триггерах и валидации и в разрезе товаров.