mizzy241
-
Публікації
14 -
З нами
-
Відвідування
mizzy241's Achievements
-
Сам задаю вопрос, сам отвечаю В общем, проблема оказалась в том, что в магазине был один заказ, при обработке которого скрипт novaposhta_cron.php ломался на следующей строке: $this->model_checkout_order->addOrderHistory($orders[$document['Number']]['order_id'], $status_settings['store_status'], $sms_message, $notify); Соответственно, все заказы после этого уже не обрабатывались. Честно говоря, я сходу пока не понял, что не так с этим конкретным заказом (сообщение об ошибке сходу не смог вытащить ни в один из логов, хотя вообще ошибки PHP в логи пишутся), но как только он был исключен из обработки (руками был выставлен статус "Отправлен") - все остальные "зависшие" заказы тут же обновили статусы.
-
Добрый вечер, Несколько дней назад как-то странно начало работать отслеживание статусов. Например, включено отслеживание для статусов "Ожидает отправки" и "Отправлено". Для кода Новой почты "5" (Відправлення прямує до міста YYYY.) настроена установка статуса магазина в "Отправлен". По факту в магазине висит энное количество заказов со статусом "Ожидает отправки", через API Новой Почты у соответствующих доставок виден StatusCode: "5", но статус заказов в магазине на "Отправлено" не меняется хоть ты тресни. Буду благодарен за подсказку в какую сторону копать. Отладочный режим модуля включал, в логах на первый взгляд никакого криминала, кроме периодически встречающихся ошибок 2021-04-26 21:38:12 - Nova Poshta errors: Слишком много запросов 2021-04-26 21:38:12 - Nova Poshta info: Try again after 1 seconds ТТН проблемных заказов в отладочном режиме в логах видны, и также видно, что модуль запрашивает информацию о всех этих заказах через API и даже получает успешные ответы. Т.е. модуль на первый взгляд понимает, что статусы проблемных заказов отслеживать надо, и даже пытается это делать. Версия модуля 3.4.1 (честно говоря, без особой нужды предпочитаю не обновлять), еще 22 апреля все работало как часы.
-
Похоже, вопрос снимается. Один шорткод был написан неудачно (излишне широкий критерий для матчинга), и, соответственно, умудрялся менять и ссылку, которая использовалась при чекауте. Поправил - с оформлением заказов проблем нет.
-
Спасибо. Создал тикет в ТП с необходимыми доступами.
-
Добрый день, Внезапно наступил на грабли с тем, что при оформлении заказа с украиноязычной версии сайта все заказы попадают в потерянные. Насколько я понимаю, происходит это из-за того, что модуль оплаты не может подтвердить заказ, а именно: Успешный заказ с русскоязычной версии завершается следующими запросами в логах сервера: GET /index.php?route=extension/payment/cod/confirm&_=1600769801603 GET /index.php?route=checkout/succes При заказе же с украиноязычной версии запросы трансформируются следующим образом: GET /index.php?route=extension/uk/payment/cod/confirm&_=1600769801603 GET /uk/index.php?route=checkout/success Т.е. языковой префикс каким-то непонятным для меня образом попадает в середину route. В остальных местах сайта все ок, ссылки генерируются правильно. Попробовал поиграться с исключениями - но безрезультатно. Возможно, из-за того, что не до конца понимаю логику их реализации (например, чем отличаются исключения для router и для uri, а также для маршрутизатора и формирователя префиксов). Методы оплаты - абсолютно стандартные cod и bank_transfer, форма чекаута - Simple, opencart 2.3.0.2. Честно говоря - пока в растерянности по поводу того, куда рыть дальше. Буду признателен за любые подсказки
-
Похоже, вопрос снимается. Нашел на просторах интернета патч для похожей проблемы и творчески модифицировал его под свои нужды. Теперь order_id не меняется.
-
В принципе, такого ответа я и ждал, но призрачная надежда теплилась Если вдруг вы сможете подсказать, в каких местах опенкарта можно покопать и на что там обратить внимание - буду признателен. Ну а если нет - гугл мне в помощь P.S. Надежду мне подарила ваша фраза " заказ попробовали пересоздать под тем же номером (есть такой функционал в модуле)" из переписки 2016 года.
-
Добрый день, Пробую добавить на сайт метод оплаты кредитными картами через Portmone (модуль оплаты взят отсюда - https://github.com/Portmone/OpenCart/tree/master/2.3.0.2.3) В принципе, все работает вполне ожидаемо, за исключением одного не совсем приятного момента. А именно - если пользователь переходит на страницу оплаты Portmone, а там просто нажимает "Отменить" - его редиректит обратно на сайт, показывая страницу с информацией о том, что "Оплата отменена пользователем". При этом в базе создается заказ с order_id X (в принципе, ожидаемо Но состояние корзины пользователя остается неизменным (что тоже логично), и вот пользователь опять начинает чекаут, выбирает метод оплаты Portmone, и на странице Portmone опять нажимает "Отменить". Ситуация повторяется, за исключением того, что в базе уже создается заказ с order_id X+1. И продолжаться так может до бесконечности. Есть ли какой-то вариант побороться с этим с помощью Simple ? Листая эту ветку, нашел такие цитаты, как " в ряде случаев этот номер заказа может начать расти, подробно об этом написано в факе " и " заказ попробовали пересоздать под тем же номером (есть такой функционал в модуле) " Внимательно (надеюсь) читал фак - но не смог там найти описание механики увеличения order_id. Также не смог в настройках модуля найти ничего, связанного с пересозданием заказа под тем же номером. Поэтому решил попросить о помощи вслух.
-
Добрый день, Начиная с 29.03, при обновлении списка городов из крона (выполнение запроса к ?route=extension/module/novaposhta_cron/update&type=cities&key='), в вывод wget стало просачиваться следующее: Saving to: ‘STDOUT’ <b>Notice</b>: Undefined index: SettlementTypeDescription in <b>/var/www/xxx/htdocs/system/helper/novaposhta.php</b> on line <b>337</b><b>Notice</b>: Undefined index: SettlementTypeDescriptionRu in <b>/var/www/xxx/htdocs/system/helper/novaposhta.php</b> on line <b>337</b> Это не смертельно ?
-
Добрый день. После установки модуля в админке опенкарта (2.3.0.2) в Панели состояния в блоке Недавняя активность перестала отображаться информация о регистрациях пользователей. Не то чтобы это было критично, но, возможно, это все-таки как-то лечится - дабы была полная красота. Буду признателен за подсказку куда копнуть.
-
На первый взгляд это не совсем то - получится просто фиксированная стоимость доставки, которая не меняется ни при каких условиях. Сейчас попробую способ с модификацией catalog/model/extension/shipping/novaposhta.php
-
Спасибо!
-
Да, действительно, похоже так и есть. Спасибо. Тестировал на позициях стоимостью +/- 400 грн. Со всякой мелочью увеличения стоимости нет. Тогда еще один вопрос - а можно ли как-то задать фиксированную объявленную стоимость ? Просто задать значения в поле "Объявленная стоимость по умолчанию" не помогает. В поле "Объявленная стоимость" какую комбинацию полей не выбираю - ничего не меняется.
-
Подскажите, пожалуйста, а с чем может быть связано то, что при увеличении количества товаров в корзине с каждой новой единицей товара стоимость доставки, рассчитанная через API, растет на 2 гривны ? У всех товаров веса и размеры равны нулю, "количество мест по умолчанию" пробовал выставлять равным 1. Просто по факту все товары действительно небольшие и легкие, и даже приличное их количество легко умещается в одну посылку. И заказывают их зачастую тоже не мало, и в таком случае 30 гривен реальной стоимости доставки модуль превращает в 80-90, что может расстроить потенциального покупателя
