Необходимо экспортировать в csv товары, а именно чтобы было Название - Полный УРЛ (сайт-категория-товар), сейчас же почему-то экспортируется неполный УРЛ, так как с большими объёмами работа идет с помощью exel и программы Директ Командер

У russianpostcalc.ru есть API для печати форм для нужд Почты России.

Отправляем туда запрос с параметрами, в ответ получаем ссылку на pdf файл.

Подробная информация по API: http://russianpostcalc.ru/api-devel.php
Основная форма, которая всем требуется, Ф116.

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

Скрин результата работающего примера прицеплен.

Яндекс доставка обновила апи, и сильно толкает продукт как доставку для интернет магазинов,
с учетом того что Озон-доставка закрывается,
а цены у яндекс доставки низкие
это было бы хорошей альтернативой почте и озону

https://dostavka.yandex.ru/integrations/ecommerce/

Здравствуйте, столкнулся с тем, что нужно добавить дополнительное поле в Orm объект catalog-product. Для этого у API есть событие orm.init.КОРОТКОЕ_ИМЯ_ORM_ОБЪЕКТА. Однако в базе поле хранится в сериализованом виде, а для работы с объектом product его нужно обратно преобразовать в массив. Отсюда и необходимость в дополнительном событии по типу orm.afterobjectload.КОРОТКОЕ_ИМЯ_ORM_ОБЪЕКТА. Тем более у RS::ORM::AbstractObject есть такой метод. Будет достаточно в этом классе сгенерировать новое событие. Например так:

public function afterObjectLoad()
{
/**
* Event: orm.afterobjectload
* paramtype \RS\Orm\AbstractObject
*/
\RS\Event\Manager::fire('orm.afterobjectload.' . $this->getShortAlias(), $this);
}


И во всех потомках этого класса в методе afterObjectLoad (если он там переопределен) вызывать:
parent::afterObjectLoad()

Возможно я упускаю какие-то трудности в реализации, но отсутствие такого событие показалось как минимум странным. Если можно изменить данные объекта перед самой записью в базу, то почему нельзя изменить его и сразу после получения из базы?

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

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

Когда мы создаём алиасы (оно же URL-имя) для товаров, брендов, категорий, задействуется функция \RS\Helper\Transliteration
Когда мы вручную из карточки создаём алиас, работает js /resource/js/jquery.rs.autotranslit.js
И всё вроде хорошо, пока кириллица и латиница присутствует.
Но бренд "Baumüller" превращается в "baum-ller"
Косяк? Да. Подобных брендов навалом. Если делать интернет-магазин двуязычным, нарваться на названия категорий и товаров элементарно. Даже, если просто парсить, отследить наличие всяких умляутов и прочих диакритических символов нереально.

Проблема тут в том, что RS не знает о таких символах. И ставит вместо них дефис. А ставить надо ближайший латинский символ.
Реализовать подобное очень просто, я не понимаю, почему это вдруг "такая функциональность не ожидается".

Вот эти символы. Полный список.
¡¿
ÄäÀàÁáÂâÃãÅåǍǎĄąĂăÆæĀā
ÇçĆćĈĉČč
ĎđĐďð
ÈèÉéÊêËëĚěĘęĖėĒē
ĜĝĢģĞğ
Ĥĥ
ÌìÍíÎîÏïıĪīĮį
Ĵĵ
Ķķ
ĹĺĻļŁłĽľ
ÑñŃńŇňŅņ
ÖöÒòÓóÔôÕõŐőØøŒœ
ŔŕŘř
ẞߌśŜŝŞşŠšȘș
ŤťŢţÞþȚț
ÜüÙùÚúÛûŰűŨũŲųŮůŪū
Ŵŵ
ÝýŸÿŶŷ
ŹźŽžŻż

p.s. я понимаю, что мультиязычности по факту нет, но мультисайтовость есть и вот официальная позиция по этому поводу
https://helpdesk.readyscript.ru/wish/Podklyuchenie-vtorogo-yazyka-13.html

Сейчас есть такое понятие как "Склад". Согласно логики скрипта "Склад" - это место хранения товаров и пункт выдачи товара. В реальности же это не всегда так. В моем случае есть реально существующий магазин, в котором покупатель может получить товар и есть еще удаленный склад (склад поставщика), с которого есть возможность оперативно заказать и доставить товар, но получить покупатель там ничего не может. Я хочу на странице товара показывать наличие товара на удаленном складе и не хочу, чтобы этот склад был доступен покупателю при выборе места получения заказа. Логично добавить такое понятие как "Пункт выдачи". Склады отображаются на странице товара и показывают его наличие. Пункты выдачи отображаются для выбора покупателю при оформлении заказа.

Предлагаю доработать админку или создать модуль вывода на печать документа: Условия гарантии

Как это должно работать?

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

Создаем шаблоны:

1. Технически сложные товары - в шаблон заносим текст условий: гарантия 12 мес, при неисправности обращаться в сервис: город, адрес, контактный телефон, при каких неисправностях гарантия не действует и т д.
2. Средства личной гигиены - в шаблон заносим текст условий: средство личной гигиены обмену и возврату не подлежит

Далее:

В редактировании товара, устанавливаем к какой категории гарантийных условий принадлежит товар.

Далее:

Заходим в редактирование заказа, и выбираем печать: Условия гарантии (там где печатаются документы: Заказ, Товарный чек, Счет)
Если товары из заказа в одной категории гарантийных условий, то на печать уходит 1 лист с условиями гарантии, если товары из разных категорий гарантийных условий то на печать выходят несколько листов. В листах на печать, до отображения условий гарантии выводим список товаров из заказа, на который действует данная гарантия.

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

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

-----------------------

Данные функции будут полезны при передаче закрывающих документов после продажи или допустим менеджерам магазина

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

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

Менеджер распечатывает условия гарантии и в каких ситуациях этот товар можно вернуть по закону или отправляет на e-mail клиента. (Оба сверяют условия) Если все верно и по закону, то менеджер спит спокойно, а клиент возможно успокаивается и понимает что был не прав.

В продолжение, также о функционале возврата товара http://helpdesk.readyscript.ru/wish/Razrabotat-funkcional-vozvrata-tovara-419.html

Предлагаю разработать модули для интеграции с сервисами приема платежей в криптовалюте.
Как пример, интегрироваться можно с этими сервисами
1. https://ru.cryptonator.com/merchant/
2. https://bitaps.com/ru/merchant

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

То есть можно было сделать страницу с формой и при обращении к ней посредством javascript, получить ответ в формате json. теперь же возвращается html полностью всей страницы.

Проблема в том, как в файле modules\menu\controller\front\menupage.inc.php формируется результат обработки в строке 45:
return $this->view->fetch($menu_item['link_template']);
До обновления было:
return $this->result->setTemplate($menu_item['link_template']);

Если можно, то сделайте как было до обновления или объясните, зачем нужно это изменение.