Николай Савин

Насколько я вижу в приложенном файле нет четкой постановки задачи.
Что конкретно нужно доработать в табличке?

Если не договоритесь с этими тремя, то вам будет сложно

О, пришел Папа с работы и разогнал детишек по кроваткам.

Я про территорию, а не национальность.

О, нефига себе. Еще один казах обьявился

Так то Михаил и сам выступал на конференции, более того он ее организовывал.

А что уже можно? Я думал ты еще не создал компанию

Вот тут читайте.

В принципе если 100 человек по 2 тысячи скинутся уже почти 3000 долларов выходит. Mission complete
А в сообществе уже 5600 человек.

Поддерживаю идею.
2-5 тыс. рублей ежемесячно буду оплачивать гарантировано, а там посмотрим как пойдет.

Хм. Давай разбираться, я пока не очень понимаю.
Задача — сделать рассылку тысяче клиентов о подходящей им заявке с сайта.
Я могу напрямую перебрать подходящих пользователей и отправить каждому сообщение через консоль. Это вызовет определенную нагрузку на сервер. Это я понимаю.
В чем польза очередей?
Я вместо отправки сообщений тысяче клиентов делаю тысячу записей в таблице очередей.
А что дальше?
Настроенный мною скрипт будет вызывать скажем по десять записей в минуту и отправлять письма? Нагрузка явно будет меньше. Я правильно понимаю суть компонента и его пользу? Только хранение очередей в заранее подготовленной таблице и упрощенное добавление\запрос из таблицы очередей?

Однозначно в избранное.
Спасибо Михаил.
А как работает выполнение действий из очереди? по крону? или что то вроде постоянного запуска через sleep?
Как вообще правильнее всего подобные вещи делать?

Да нет там проекта, там ошибки. Достал уже всех бот тупой.

После обновления modRetailCRM до версии 2.0 заказы перестали отправляться в CRM.
С таким вопросом обратился ко мне пользователь.
Для решения проблемы я открыл плагин modRetailCRM, нашел строчку, которая отвечает за отправку заказа в RetailCRM

$response = $modRetailCrm->request->ordersCreate($orderData, $site);

Результат выполнения команды сохраняется в переменную $response.
Чтобы просмотреть возможную ошибку (а к слову RetailCRM присылает подробное описание ошибки на русском языке) достаточно распечатать эту переменную и сохранить ее в лог журнал MODX

$modx->log(1, '[modRetailCRM]  Order Response '.print_r($response, true));

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

Оказывается если передать в этой строке

$orderData['payments'][0]['type'] = $order['payment']['description'];

произвольный текст — RetailCRM не примет заказ.
Проблема решилась комментированием строки.

А откуда собственно взялся произвольный текст?
При создании способов оплаты я предложил в поле Описание — description указывать символьный код способа оплаты из справочника REtailCRM. Например Оплата наличными — cash.
Если же указать там именно произвольное описание способа оплаты, чтобы показать его клиенту в корзине — получится ошибка, которая решается всего лишь исключением передачи способа оплаты в CRM.

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

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

5000 — серьезно?

Написал в телеграм тебе

На меня в этом году выходил владелец местной сети кофеен с предложением создать такой продукт. Может ему было бы интересно.

А права на софт тебе принадлежат или заказчику? То есть будешь ли выводить продукт на рынок?

Я так понимаю следующая статья Почему MODX? будет иметь примерно следующее содержание. «Потому что я его неплохо знаю»