Yml Экспорт: Яндекс Маркет Стоимость И Сроки Доставки - Изменения


#1

Всем привет,

Сейчас на прайс листе YML экспорта есть вкладка Варианты доставки, где мы можете указать сроки и стоимость:

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

Что хотим сделать:

1) В настройках доставки, добавить новую вкладку Яндекс.Маркет где будут указываться эти данные.

2) Убрать возможность добавлять стоимость доставки для прайс листа.

3) У скольких методов доставки будут заполнены данные в п.1 (настройки на вкладке Яндекс.Маркет) столько строк и будет выгружаться в прайс-листе.

Что изменится:

1) Стоимость и сроки доставки теперь нужно будет указывать на методах доставки

2) Интерфейс будет более понятным https://www.evernote.com/l/AQFtTPvAYHhOtL8TwZjeiyafsH7ma6Agpwk

3) Для всех прайслистов будут выгружаться одни и те же данные.

Вопросы

- Есть ли у кого то возражения по подобным изменениям

- Используем ли кто-то разные прай-листы с разными "вариантами доставки", т.е. где цена и сроки доставки различаются.


#2

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


#3

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

Курьерская по мск, за мкад мск, по спб, за кад спб, до урала, за уралом, сибирь, дв.

Пункты выдачи. Почта.

Всего более 60 способов доставки. Под каждый пункт создан свой способ доставки. Будет ли корректно принят такой прайс ЯМ?

Дополнительно - если используется способ доставки на основе агрегаторов, с рассчетом стоимости "В режиме реального времени" - Яндекс Доставка, Апишип и др, как в этом случае быть?


#4

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

Курьерская по мск, за мкад мск, по спб, за кад спб, до урала, за уралом, сибирь, дв.

Пункты выдачи. Почта.

Всего более 60 способов доставки. Под каждый пункт создан свой способ доставки. Будет ли корректно принят такой прайс ЯМ?

Дополнительно - если используется способ доставки на основе агрегаторов, с рассчетом стоимости "В режиме реального времени" - Яндекс Доставка, Апишип и др, как в этом случае быть?

Добрый день,

А у вас сейчас один прайс лист используется? Я так понимаю на вкладке "Варианты Доставки" вы заполнили данные для него.

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

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


#5

Приветствую! Вот сейчас я в плотную занялся этим вопросом. Всё оказалось не так просто на практике.

Дело в том, что как только мы практически начинаем реализовывать механизм "покупка на Маркете" то попадаем в круг связей:

1. Реальные даты доставки заказа

2. Информация о сроках, которую мы публикуем на сайте для клиента

3. Информация о сроках, которую мы передаём по API.

Пункты 2 и 3 технически не связаны, поскольку пункт 3 мы задаём вручную, а пункт 2 может быть рассчитан автоматически (Сдэк, например).

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

Далее трудность - они (Маркет) не учитывают выходные в сроках. Если бы им отдавать сроки с момента отгрузки в службу доставки - то пол-беды - там выходных в контрольных сроках нет. Но фактически - мы не можем объявить сроки исполнения заказа равными контрольным срокам служб доставки. Фактически - нам нужно прибавить 2 дня на комплектацию заказа. А эти два дня могут попасть на выходные и праздники. То есть могут превратится в 4 дня. А могут восьмого марта превратится в 7 дней.

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

Ладно. В ручных методах можем попробовать жёстко прибавить минимум 2 дня, максимум 4 дня. На сайте срок станет растянутым, но достоверным.

Теперь проблема в API. По документации диапазон FromDate - ToDate не может быть больше 3-х дней. А у нас, например, реально с Почтой России и нашими выходными получится 5-12.

Я пока настроил API именно так и вроде, пока не ругались на диапазон. Может просто не заметили. Поскольку раньше бвыало, что ругались. Пока не разобрался. Может что-то поменялось.

Короче. в идеале формула должна быть такая (рабочие дни на обработку заказа)+(контрольные сроки службы) = общий диапазон. При этом хорошо бы чтобы он выводился в датах а не днях.

И вообще - мыслить в датах - как-то больше дисциплинирует в этой задаче.