Проблемы со СДЭК. Падает СДЭК, подвешивает сайт. Большое количество писем-ошибок

Интернет-магазины Пожелания и обратная связь
1

Вчера удалось в полной мере ощутить недоработку модуля СДЭК. СДЭК вчера значительную часть дня не работал. Менедежеры в филиале вынесли мозг.

Версия движка 4.11.2

Итого 375 писем “Ошибка доставки”
Возникли проблемы с расчётом тарифов для способа доставки СДЭК. Убедитесь, что он настроен правильно, и расчёт тарифа ведётся верно.
Ну и как результат, отправка писем через SMTP яндекс была заблокирована на день Яндексом.

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

Как решение из сообщения ниже.

Очень интересно получается в итоге – работоспособность собственного сайта зависит от стороннего сервиса. В целом согласен, нужна проверка доступности API СДЭК (и прочих сервисов доставок), например, раз в 5 минут и если оно не работает – скрывать этот способ доставки и отправлять единичное уведомление на почту. Типа того.

Ближе к делу.

  1. Почему нельзя сделать возможность отключения уведомлений об ошибках? СДЭК часто падает на короткое время, но такие уведомления носят регулярный характер. Уведомления можно полностью отключить, но это неверно всегда, если отключить, то нет уведомлений, вопрос, а почему доставка не оформляется. Ничего не происходит. Такие отзывы от клиентов. Сообщение должно быть, это сигнал к тому, что СДЭК не работает.
  2. Проще сделать, не работает СДЭК, тогда надо, чтобы вкладки доставки по СДЭК не скрывались, а на них написано было, что способ доставки временно недоступен.
  3. Не баг, а недоработка. Если ставишь вручную цену на доставку, допустим пункты самовывоза. Карты не показываются. Почему нельзя сделать так, чтобы карты показывались в любом случае? Есть фиксированная цена, есть карта, выбрал, далее с менеджером детали, если что.
  4. Наложенный платеж при отгрузке. Это тоже недоработка. Наложенный платеж должен считаться сразу от способа оплаты. А, если как в тех.поддержке говорят, что напишите уведомление, а при отгрузке на сайте будет конечная цена. Логика неправильная, клиент купил, а мы ему сверху цену еще накинули. Реакция, зачем мне доп.услуги навязываете. Можно было просто установить возможность % от способа оплаты для наложенного платежа.

Просьба рассмотреть некоторые недоработки, даже, если это не баг. Сайт вчера поднапрягся, а клиенты изрядно потрепали нервы менеджерам, потому что заказ не могли оформить.
Но ощущение создается такое, что модуль не тестировался как надо. Для региональных сайтов мы специально выбрали CS CART, но при таких косяках, сколько нужно сил потратить, чтобы доработать все как надо?
Хотелось бы обратку, у нас в компании есть специалист по логистике, который может все разложить как надо в ТЗ и т.д. Если интересно. С доставкой далеко не очень хорошо реализовано все.
По СДЭКУ много вопросов.
Если не баг трекер, то куда писать? Есть сомнения, что это вообще кто-то будет читать, вникать, как-то исправлять. Приобретать CS CART, чтобы потом самим пол движка переписать, это конечно шикарно.

1 лайк
2

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

3

Так и сделаю!
Спасибо!

4

По первому пункту:

image
image1248×482 17 KB

6

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

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

7

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

Очень интересно получается в итоге – работоспособность собственного сайта зависит от стороннего сервиса. В целом согласен, нужна проверка доступности API СДЭК (и прочих сервисов доставок), например, раз в 5 минут и если оно не работает – скрывать этот способ доставки и отправлять единичное уведомление на почту. Типа того.

Другой вопрос, что вряд ли подобное стоит ожидать в ближайшее время, если вообще стоит. Проблеме не один месяц уже. А СДЭК падает периодически.

2 лайка
8

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

9

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

10

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

Но когда это происходит на шаге добавления товара в корзину? Как это вообще можно объяснить?! Клиент собирает корзину, которую, возможно, оплатит завтра или еще позже, но из-за косяка на сервере СДЭК добавить выбранный товар невозможно. Что отвращает клиента от покупки.

@imac @ikoshkin — можно что-то сделать, чтоб устранить этот косяк в принципе? Или наши клиенты обречены на мучения? :frowning:

1 лайк
11

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

12

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

13

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

14

Все значения? Для всех доступных тарифов, городов, ПВЗ, весов, объемов и стоимостей? И какой это будет объём данных, как вы думаете? :face_with_raised_eyebrow:

15

Ну значения то рассчетные, за вес километр, город, разве нет? А запрос на каждую итерацию это не объем данных да? ) А транзакционные издежки на запрос, а вероятность отказа, которая ненулевая. Как мне кажется, данные которые постоянно нужны надо при себе держать, а не запрашивать постоянно. Впрочем все зависит от объема заказов наверное.

16

Там объём не большой, всё на сервере должно считаться и выдавать обратно только стоимость и, может быть, ещё несколько параметров.
Меня калит в основном то обстоятельство, что при добавлении товара отправляется запрос и за это я на еДост плачу в разы больше по тарифу на ровном месте.

17

Ну оно ж пересчитать должно… может убрать пересчет аяксовый если, то не будет постоянно посылать?
А что запрос в сдек на рассчет доставки платный? Они там офонарели совсем

19

в eДост как я понял платный расчет для инет магазинов.

20

Из поддержки ответили, что есть задача на систему оповещений.

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

На все остальные вопросы по СДЭК неизвестно, будет или нет. Оставят так или еще что-то доработают, неизвестно. Будем дорабатывать сами.

21

И самое интересное в этой ситуации, что cdek.market сделан на карте )

22

Возможно это было дешевле, чем на битриксе и прочих. Могу предположить.
Сайт можно хоть на чем делать, зависит от возможностей нанять хороших специалистов. Если компания монстр, лучше самим написать с нуля и поддерживать. Но это очень дорого. Видел крупные сайты построенные на вордпресс. Люди даже на таком блоговом движке умудряются создавать серьезные вещи. Один из порталов по недвижимости СПб был модифицирован на базе вордпресс. Не знаю как сейчас, но там и компания, которая его обслуживала, это вебстудия, где целый отдел программистов. Вопрос в наличии $. Да и не всем надо делать что-то крутое. Потенциал у cs cart есть, зависит от того, как быстро будут учтены просьбы. Программисты не продажники, им кажется, что так лучше, а на деле не всегда так.