Ожидает разработки

+4

Автовыбор самого выгодного тарифа СДЭК

Идеальный Пиксель Обновлен 23 дня назад в категории CMS Общий функционал 9

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

Объясню почему так. Например, обычно тариф "Посылка склад-склад", самый выгодный, но например при отправке в Красноярск он очень дорогой и выгоднее "Экономичная посылка склад-склад".

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

Комментарии 9

  • Павел С 4 месяца назад

    Вообще многое в RS из того, что касается оформления заказа и расчета доставки дикие костыли. Доходит до того, что оформление заказа клиента в бешенство приводит и клиент просто уже матом начинает кричать ) Пожелание плюсую, опция такая нужна.

    • Идеальный Пиксель 4 месяца назад

      Павел С, в таких мелочах, заметно, что разработчики сами не пользуются своей платформой для продаж или пользуются очень ограниченно.

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

      • Артем Полторанин 2 месяца назад

        Вы зря так думаете. Ряд крупных проектов на ReadyScript мы обслуживаем самостоятельно и сталкиваемся со всеми теми же проблемами, с которыми сталкиваются наши партнеры. У нас еще есть 5+ каналов получения информации от клиентов (форум, поддержка, сервис пожеланий, online-консультант, телефон, ...), по которым мы ежедневно получаем информацию.

        Просто мы разделяем платформу и кастомы. Любой крупный серьезный проект - это всегда платформа + кастомы. Тут не должно быть иллюзий. Именно поэтому на рынке существуют интеграторы, веб-студии.

        Хотя нам конечно тоже хочется, чтобы в платформе было побольше функций, чтобы кастомов было меньше, но к сожалению приходится выстраивать приоритеты. По основному вопросу темы, я ответил ниже.

  • Ярослав Пономарев 2 месяца назад

    О, только что жалобу клиента по этому вопросу разбирал.

  • Артем Полторанин 2 месяца назад

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

    -----

    В настоящее время модуль СДЭК работает по протоколу версии 1.5, для калькуляции используется метод, описанный в "п. 4.13.1. Расчет стоимости по тарифам с приоритетом" документации по API СДЭК.

    Данный метод на вход принимает список тарифов в порядке заданных вами приоритетов, а на выходе возвращает ID выбранного тарифа и одну цену доставки. Запрос к СДЭК - это не дешевое по времени удовольствие. Бомбардировать СДЭК запросами на калькуляцию для разных тарифов будет стоить - несколько секунд, а может и несколько десятков секунд (в зависимости от нагрузки серверов СДЭК).

    Этот метод мы не рассматриваем, так как он неприемлем с точки зрения итоговых параметров времени выполнения, так как следующий вопрос, который к нам поступит от профессионалов - "Как вы догадались до такого №%## механизма определения оптимального тарифа? И почему он требует 10 секунд для калькуляции."


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

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

    -------

    Единственным корректным решением в данном случае может быть - это выполнение такого запроса к СДЭК, который бы возвращал нам сразу калькуляцию по разным тарифам. В протоколе 1.5 такого метода - нет. Возможно в новых версиях (2.0) протокола СДЭК такое уже есть, но для этого нужен совершенно новый модуль СДЭК. Это единственно верное с точки зрения оптимальности решение.

    ------

    Не забывайте, что мы мыслим при разработке абстрактно (мы не кастом строим, а платформу). Для нас доставка - это объект возвращающий точную стоимость по входным параметрам - Заказ, Адрес. Именно доставка полностью ответственна за свою калькуляцию. Не совсем логично на движок сваливать пост-обработку полученных от модуля стоимостей.

    • Идеальный Пиксель 2 месяца назад

      Артем Полторанин, ага, то есть два/три запроса в рамках одного модуля это херовое решение, а то что то-же самое приходится делать только с помощью нескольких вызовов модуля, это ок?)

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

      • Артем Полторанин 1 месяц назад

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

        В рамках модуля доставки все запросы идут через специальную прослойку ExternalRequest, который имеет всегда включенный внутренний кэш, то есть второй раз абсолютно одинаковый запрос никогда не поступает на сервер Службы доставки. Поэтому 2,3,10 одинаковых запроса всегда выполняются как один по времени и по сути.

        Совсем другое дело отправлять разные запросы, с разным tarrifList вы же именно это предлагаете.

    • Ярослав Пономарев 1 месяц назад

      Артем Полторанин, https://confluence.cdek.ru/pages/viewpage.action?pageId=63345519
      да, калькуляция с возвратом нескольких тарифов в версии 2.0 есть

  • Артем Полторанин 23 дня назад

    Приоткрою немного нашу кухню. Мы сейчас работаем над переработкой подсистемы доставок и администрирования заказов доставок из админки. В рамках этой работы, мы также перепишем СДЕК на новое API 2.0 и добавим там функцию автовыбора самого дешевого тарифа.

Написать сообщение