В какой файл добавить функцию отправки заказа в CRM со статусом этого заказа?

[MrNix21]

Здравствуйте!

Есть такая задача - отправлять в CRM все заказы, в том числе и заказы со статусом "Ошибочные заказы" и чтобы эти статусы были видны.

Для этого я добавил функцию отправки в CRM в файл: /catalog/controller/checkout/simplecheckout.php

Но сейчас эти заказы приходят без статуса, т.е. я не понимаю, заказ реально совершен или это ошибочный заказ (без подтверждения). Получить статус заказа в файле simplecheckout.php, как написал разработчик модуля Simple, невозможно.

После этого я переместил функцию отправки заказа в CRM в файл /catalog/model/checkout/order.php (в функцию // Admin Alert Mail)

Но теперь в CRM отправляются только подтвержденные заказы.

Как мне сделать так, чтобы: 

1. Приходили все заказы, в том числе со статусом "Ошибочные заказы" (не подтвержденные)

2. Чтобы был виден статус этих заказов

3. Чтобы заказы не дублировались в CRM, например, сначала приходит заказ со статусом  "Ошибочный заказ", а потом, после подтверждения заказа клиентом еще раз этот же заказ, но с другим статусом.

 

Куда нужно переместить функцию отправки в CRM чтобы можно было это реализовать?

 

Буду благодарен любой помощи!

[codeKong]

checkout/success

[bogdan281989]

Идеально - отдельный метод, который будет выбирать заказы и отправлять еще не переданные в CRM, запуск в планировщике, так как часто пихают в метод истории заказа, а потом начинает оформление заказа думать в момент оформления, так как идет отправка в срм. И временами ответ задерживается и пользователь видит "повисший" сайт.

[MrNix21]

В 22.12.2021 в 11:24, codeKong сказал:

checkout/success

Спасибо, но как я понимаю, checkout/success вызывается только после подтверждения заказа, соответственно, заказы со статусом Ошибочные не будут отправляться в CRM.

[Tom]

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

[MrNix21]

В 22.12.2021 в 13:03, bogdan281989 сказал:

Идеально - отдельный метод, который будет выбирать заказы и отправлять еще не переданные в CRM, запуск в планировщике, так как часто пихают в метод истории заказа, а потом начинает оформление заказа думать в момент оформления, так как идет отправка в срм. И временами ответ задерживается и пользователь видит "повисший" сайт.

Интересный способ. Что, если добавить в таблицу "order" новое поле "sent_to_crm" и запускать планировщик каждые 5 минут? На сколько это загрузит мой сайт?

[Prooksius]

1 минуту назад, MrNix21 сказал:

Интересный способ. Что, если добавить в таблицу "order" новое поле "sent_to_crm" и запускать планировщик каждые 5 минут? На сколько это загрузит мой сайт?

Конечно загрузит, особенно когда со временем записей в таблице заказов прибавится и читать оттуда будет ох как затратно.
Можно попробовать затулить отправку в CRM в функции addOrderHistory в catalog/model/checkout/order.php

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

Как вариант, можно вызывать в ф-ции addOrder там же. И проверять, чтобы статус был = 0 - то есть заказ абсолютно новый и еще не подтвержден.
Тогда отправится только один раз - когда он создается. Но не факт, что пользователь его закончит. Поэтому опять же может быть куча мусора в CRM

[MrNix21]

2 минуты назад, Tom сказал:

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

Как я понимаю, заказы со статусом "Ошибочный заказ", это заказ, который клиент не подтвердил, но заполнил некоторые поля при оформлении. Такие заказы сохраняются в таблице "order", где в поле "order_status_id" прописывается значение 0.

Возможно я ошибаюсь, но моя догадка строится на том, что когда звоню клиентам по таким заказам, то они говорят что не подтверждали заказ.

[Prooksius]

1 минуту назад, MrNix21 сказал:

Возможно я ошибаюсь, но моя догадка строится на том, что когда звоню клиентам по таким заказам, то они говорят что не подтверждали заказ.

это и есть брошенные корзины.

[Tom]

16 минут назад, MrNix21 сказал:

Возможно я ошибаюсь, но моя догадка строится на том, что когда звоню клиентам по таким заказам, то они говорят что не подтверждали заказ.

Какой у вас "ненавязчивый" сервис 

[MrNix21]

1 минуту назад, Tom сказал:

Какой у вас "ненавязчивый" сервис 

Вот это я и хочу исправить, потому что клиенты иногда ругаются трехэтажным матом и их можно понять) Но при этом хочу получать в CRM эти заказы со статусом, отличным от реальных заказов.

[bogdan281989]

5 часов назад, Prooksius сказал:

Конечно загрузит, особенно когда со временем записей в таблице заказов прибавится и читать оттуда будет ох как затратно.
Можно попробовать затулить отправку в CRM в функции addOrderHistory в catalog/model/checkout/order.php

 

Следуя вашей логике, то даже если у человека будет несколько десятков тысяч заказов то уже все? Скажите в чем именно затуп будет и нагрузка? В выборке с таблице заказа select на одно условие?

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

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

[bogdan281989]

5 часов назад, MrNix21 сказал:

Как я понимаю, заказы со статусом "Ошибочный заказ", это заказ, который клиент не подтвердил, но заполнил некоторые поля при оформлении. Такие заказы сохраняются в таблице "order", где в поле "order_status_id" прописывается значение 0.

Возможно я ошибаюсь, но моя догадка строится на том, что когда звоню клиентам по таким заказам, то они говорят что не подтверждали заказ.

Заказ уже создан до момента оплаты (статус 0, он же потерянный заказ), разные платежки работают по разному, если это простой cod - то он просто сразу дописывает такому заказу статус и он есть в админке, если платежки - пишут статус по колбеку. Пока не подтвержден заказ кнопкой в оформлении заказа, например стандартный модуль банковского перевода - ему способ оплаты не записал статус еще.

[Prooksius]

Только что, bogdan281989 сказал:

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

да это все понятно, но ту есть ньюансы, оптимизатор MySQL должен еще правильные индексы брать при выборке только не отправленных заказов, а если их не будет, как бы не было какого-нибудь full scan-а. Вообщем тут с умом нужно подходить..

[Prooksius]

15 минут назад, bogdan281989 сказал:

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

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

[bogdan281989]

Только что, Prooksius сказал:

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

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

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

Но мой вариант имеет право на жизнь, потому что он работает, при цикле в 3-5 минут отправляется 1-2 заказа курлом, не более, я не думаю что у топикстартера больше заказов в промежутке.

[Prooksius]

2 минуты назад, bogdan281989 сказал:

Но мой вариант имеет право на жизнь, потому что он работает, при цикле в 3-5 минут отправляется 1-2 заказа курлом, не более, я не думаю что у топикстартера больше заказов в промежутке.

Да, согласен, обеспечить наличие нужных индексов для oc_order, чтобы не грузить MySQL и все будет работать как часы.