Если у вас возникли какие либо вопросы которые вы не смогли решить по нашим публикациям самостоятельно,
то ждем ваше обращение в нашей службе тех поддержки.
А часто бывает необходимо менеджерам интернет-магазина получать контактные данные заказчика сразу на электронную почту, а не лезть в административную часть и не выглядывать их там.
Хочу поделиться тем, как эту проблему решал я.
Итак по порядку. Нашел 2 варианта решения задачи. Если вкратце, то это варианты:
1) с переносом компонента заказа в собственное пространство;
2) без кастомизации компонента.
Выбрал второй вариант, так как не хотел, чтобы компонент не обновлялся впредь. Первое, что пришло в голову использовать обработку событий в init.php, тем более, что и событие то вроде бы нашлось — OnOrderAdd. Но не тут то было.
Выяснилось, что компонент работает примерно по следующей схеме:
создание заказа -> OnOrderAdd -> добавление свойств -> CEvent::Send
Таким образом, необходимых свойств заказа из обработки этого события получить не удастся.
Тогда взял component_epilog.php и решил отправлять нужные письма оттуда:
В итоге получается, что менеджеру отправляется 2 письма:
1) стандартное с данными заказа из почтового типа SALE_NEW_ORDER.
2) дополнительное с контактными данными заказчика из нового созданного мной типа SALE_ORDER_NEW_MANAGER. Причем нужный шаблон выбирается в зависимости от типа плательщика.
Минусом этого способа, наверное, является как раз то, что приходит 2 письма.
В , кстати, активная дискуссия на этот счет и еще несколько способов решения подобной задачи.
Назад в раздел
Наверх
то ждем ваше обращение в нашей службе тех поддержки.
Отправка письма менеджеру интернет-магазина с данными заказчика
В стандартной поставке Битрикса не предусмотрен, на мой взгляд, весьма полезный шаблон с отправкой письма с контактными данными заказчика.А часто бывает необходимо менеджерам интернет-магазина получать контактные данные заказчика сразу на электронную почту, а не лезть в административную часть и не выглядывать их там.
Хочу поделиться тем, как эту проблему решал я.
Итак по порядку. Нашел 2 варианта решения задачи. Если вкратце, то это варианты:
1) с переносом компонента заказа в собственное пространство;
2) без кастомизации компонента.
Выбрал второй вариант, так как не хотел, чтобы компонент не обновлялся впредь. Первое, что пришло в голову использовать обработку событий в init.php, тем более, что и событие то вроде бы нашлось — OnOrderAdd. Но не тут то было.
Выяснилось, что компонент работает примерно по следующей схеме:
создание заказа -> OnOrderAdd -> добавление свойств -> CEvent::Send
Таким образом, необходимых свойств заказа из обработки этого события получить не удастся.
Тогда взял component_epilog.php и решил отправлять нужные письма оттуда:
<?
if($arResult["ORDER_ID"]){
// получаем контактные данные заказчика
$db_vals = CSaleOrderPropsValue::GetList(
array("SORT" => "ASC"),
array("ORDER_ID" => $arResult["ORDER_ID"])
);
$i = 0;
while ($arVals = $db_vals->Fetch()){
$customerProps[$i]["NAME"]= $arVals["NAME"];
$customerProps[$i]["VALUE"]= $arVals["VALUE"];
$i++;
}
// если заказ от физ. лица
if($arResult["ORDER"]["PERSON_TYPE_ID"] == 1){
$eventArFields = Array(
"EMAIL" => $customerProps[2]["VALUE"],
"PHONE" => $customerProps[4]["VALUE"],
"ORDER_USER" => $customerProps[3]["VALUE"],
"ORDER_ID" => $arResult["ORDER_ID"],
"PAYER_TYPE" => "Физическое лицо"
);
CEvent::Send("SALE_ORDER_NEW_MANAGER", SITE_ID, $eventArFields , "N", 47);
};
// если заказ от юр. лица
if($arResult["ORDER"]["PERSON_TYPE_ID"] == 2){
$eventArFields = Array(
"EMAIL" => $customerProps[2]["VALUE"],
"PHONE" => $customerProps[4]["VALUE"],
"ORDER_USER" => $customerProps[5]["VALUE"],
"ORDER_ID" => $arResult["ORDER_ID"],
"COMPANY_NAME" => $customerProps[3]["VALUE"],
"PAYER_TYPE" => "Юридическое лицо"
);
CEvent::Send("SALE_ORDER_NEW_MANAGER", SITE_ID, $eventArFields , "N", 48);
}
}
?>
|
В итоге получается, что менеджеру отправляется 2 письма:
1) стандартное с данными заказа из почтового типа SALE_NEW_ORDER.
2) дополнительное с контактными данными заказчика из нового созданного мной типа SALE_ORDER_NEW_MANAGER. Причем нужный шаблон выбирается в зависимости от типа плательщика.
Минусом этого способа, наверное, является как раз то, что приходит 2 письма.
В , кстати, активная дискуссия на этот счет и еще несколько способов решения подобной задачи.
Назад в раздел
Подписаться на новые материалы раздела:
Загрузка...
Наверх