tabook

Да, совместим.

Т.е другими словами - никакой разницы между первой покупкой и продлением лицензии, верно? P.S. Когда тестовая кнопка в профиле будет отправлять новую форму?

Как будет выглядеть запрос для рекуррентной покупки (продление лицензии) ? Поправлена ли бага с покупкой гостем (отсутствие данных о покупателе в теле запроса) ?

Да, именно этот пвз я специально вырезаю из ответов ЯД. /sarcasm off

Добавил.

Исправлено в новой версии.

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

Что нового в версии 0.3.9 - Исправлена сортировка по стоимости методов курьерской доставки. - В css добавлено правило вывода иконки метода доставки. - исправлен алгоритм работы опции "Обработка заказа, рабочих дней"

Файл /catalog/view/javascript/yd3.css добавьте в начало файла .yandex_delivery_icon { height: 28px; width: 110px; } .yandex_delivery_icon img { width: 100%; height: 100%; } 28 и 110 можно поменять по вкусу. далее Ctrl+F5

Исправляйте. Идентификаторы партнеров у всех аккаунтов разные, значит вам не повезло. В файле system\library\yd3.php 636 строка return $this->markers[hexdec(md5($logo_url)[10])]; поиграйтесь числом индексом - 10, попробуйте другие значения (0..15).

Напишите в личку конкретные даты, скрин настроек, результат и ожидаемое поведение. Боюсь, что АПИ просто игнорирует передаваемую дату доставки.

@mx928 по п.3 немного изменений: 1. В файле system/library/yd3.php в районе 602-й строки добавьте: $properties['iconContent'] = $cost; 2. В этом же файле в районе 74 строки, где инициализируется массив маркеров, добавьте к каждому элементу после названия цвета, но перед Icon слово Stretchy, чтобы получилось вот так: private $markers = array( 'islands#blueStretchyIcon', 'islands#redStretchyIcon', ... 'islands#oliveStretchyIcon' ); Результат: P.S. Как по мне - на любителя, поэтому скорее всего в релиз добавлять не буду.

Хорошо, проверю эту часть, должна работать.

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

Планируется давно, но и причина почему не сделано также озвучена неоднократно. Хорошо, давайте еще раз подробно распишу чтобы было куда посылать, когда очередной раз всплывет этот вопрос. Дело в том, что старое API предоставляло возможность дать информацию о заказах, чьи статусы изменились за определенное время. Новое же API умеет только отдать историю статусов заказа(определенных заказов). Чтобы вы понимали - это просто пропасть в подходах, похоже вторая команда просто сделала "на отвали", ведь в реальных проектах второй подход загружает сервера большим количеством обрабатываемой информации, холостыми прогонами, ненужными запросами, необходимостью самому хранить историю. Представьте себе, что мы имеем дома (магазины), в них - квартиры (заказы) и в каждой квартире возможно некое событие, скажем, включение света. Подход номер один (старое АПИ) предоставляет возможность следующего запроса - дай мне список квартир, где с 15:00 вчерашнего дня был включен/выключен свет и текущее состояние. Где 15:00 - это моя последняя проверка. В ответ я получаю книгу, в которой перечислены дома, квартиры. Теперь смотрите что предлагает второе АПИ (новый ЛК). Ты мне скажи перечень домов и квартир, а я тебе дам все-все их учетные книги за все время, а ты бери копайся, смотри и сравнивай что изменилось. После сравнения заведи свои "домовые" книги, куда перепишешь актуальное состояние. Вы можете себе представить сколько ненужной работы нужно произвести на сервере? Сколько вызовов АПИ? Даже если ни один заказ в магазине с момента последней проверки не изменил свой статус, все равно нужно будет взять все заказы магазина, запросить по ним историю статусов и сравнить где произошла (и произошла ли) смена статуса. Сравните с поведением старого АПИ - мне бы Яндекс вернул просто пустой список - с момента последнего запроса изменений не было! Надеюсь теперь понятны причины, почему мне подобное АПИ абсолютно не приемлемо - я не хочу положить ни свой сервер, ни сервера магазинов и почему пытаюсь добиться от Яндекса адекватных методов, подобно старому АПИ.

заполнить отделение отправки в ЛК ББ. читайте readme

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

Пришлите в личку скрины вот этого "В настройках модуля указал что 1-3 тарифные зоны отключены"

Что нового в версии 0.3.7 - Исправлена ошибка при расчете веса товара в корзине, если единица измерения веса товара не совпадала с единицей измерения веса по-умолчанию. - Доработана обработка ошибок при доступе к серверу расчета.

Вы по прежнему злостно ненавидите ЛС? При апдейте вы перезалили файл со своими соответствиями на дефолтный. Это видимо ответ на вопрос со слетом регионов. На вопрос В логе нет ошибок BAD REGIONS START BLOCK: - ответ: вы невнимательно прочли readme, этот блок появляется лишь после удаления файла лога. P.S. Код новой версии состоит лишь из одной строки - добавлен код Киргизии. Так разительно поведение не могло поменяться если аккуратно и вдумчиво делать апдейт модуля.

Обновиться.

Будет.

Версия 0.3.6 - Для доставки Почтой России ввод корректного почтового индекса по прежнему обязателен. Но предлагаемое исправление почтового индекса в модуле теперь носит лишь рекомендательный характер. - Исправлен vqmod для ОС версий 1.5.x

В документации никаких изменений.