Вот так выглядит мое ТЗ на улучшение «Расширенного импорта»:
Обязательно добавить возможность работы с параллельными узлами, хотябы с узлами категорий и вложенностью категорий. Пример: есть узел yml_catalog/shop/offers/offer из которого мы забираем значения для товара , где одно из значений категория и описывается как id = 1293. А есть несколько параллельных узлов один из которых yml_catalog/shop/categories/category в котором идет название, описание категорий и присвоение этого id = 1293 , а так же указана вложенность parent_id = 116
Задал разрабам вопрос Как совокупить эти id с названиями категорий? и получил ответ
“Проблема с заменой ID категории на её название решается с помощью модификаторов” а то что на сайте дропо.ру категорий всего 3140 причем эти категории друг другу дочерние и постоянно меняются про это ни слова, модификатор для данного поля с указанием вложенности вида: case($value> 233, “ Ракеты///Стартовое оборудование, инструменты”, $value> 341, “ Аппаратура и электроника///Регуляторы бортового питания (BEC)”) будет размером в 3 тома «Войны и Мира», а настроить такой модификатор 1 раз и забыть не получится его надо будет на каждое обновление новый писать, и снова это дерево в экселе генерить, так как товары постоянно меняются и категории соответственно.
Обязательно добавить вложенность в модификаторы Пример: Сайт hobbycenter отдает поле features вида: Назначение: Авиа |Объем : 7,45 |Тип: Двухтактный привести такое выражение к виду: Назначение: S[Авиа];Тип: S[Двухтактный];Тип топлива: S[Метанол];Объем : S[4.07 см] не получится так как надо использовать модификатор replace как минимум дважды, плюс модификатором concat закрывать получившееся выражение скобкой “]”, но как уже все знают модификаторы не поддерживают вложенность
Не обязательно , но желательно добавить возможность вытягивать значения для следующей задачи:
ID столбца | Имя столбца | Значение ячейки | Применяемая функция |
1 | Розничная Цена | 1000 |
2 | Оптовая цена | 700 |
3 | Кол-во на складе | 23 | if(($value_2/$value_1*100)>“7”, “$value_3”, “0”)
Здесь мы смогли бы отсечь товары поставщиков у которых скидка на товары динамическая и, предположим меньше 7 процентов ставим кол-во товаров 0 хотя они есть у поставщика. Про GUI-конструктор я и говорить не буду это просто для удобства, а уж какое там удобство без функционала.
Если внедрить 3 первые пункта тему автоматизации импорта для cs cart можно закрыть на несколько лет вперед. Должен отметить что сторонние решения вообще не применимы к реальным задачам автоматизации импорта так как не поддерживают модификаторы.
Если кто то уже просек фишку автоматизации импорта готов выслушать ваши предложения.
Удалось ли кому-то решить эту или похожую задачу?
Столкнулся с такой же проблемой при импорте прайса в нескольких xml-файлах от поставщика.
Может быть подскажете решение?
Заранее благодарю.
В полной мере не удалось, так как нет спроса на решение данной проблемы. Мониторил настроения рынка на предмет крауда разработки полнофункционального приложения работающего на удаленном хосте и управляющего состоянием базы нескольких поставщиков сайта через API. Итог НЕ актуально пару лайков в теме и 0 желающих поучаствовать. В итоге Я написал прогу под C# которая крутится под MSSQL и выгружает изменения в файл который в свою очередь скармливается расширенному импорту по крону. Грубо, безвкусно, никакого API но мои задачи, описанные в данном ТЗ, закрывает.
Было бы полезно усовершенствовать импорт вашими предложениями!
Для Multi-Vendor вообще крайне необходим такой функционал, иначе все стоит на месте. Плюс ко всему, не возможно удержать вендоров, так как они уходят из-за невозможности комфортно обновлять прайсы. На какой хрен мне нужен дворец у которого вход с булавочное ушко - ответил как-то один из продавцов покидая мой проект.
Интересно, разработчики читают эти темы?
Также столкнулся с проблемами импорта из xml от поставщиков. Проблемы ровно те же - импорт категорий нормально не реализован. Но он вполне был бы решаем, если реализовать предложенные пункты ТЗ.
Заодно также решались бы пункты с добавлением характеристик - их также много произвольных.
Упаковка товара также идёт отдельным узлом. Цвет товара и т. д. и т. п.
Кстати, сейчас, в текущей версии 4.9.3 выгрузка файлов через URL работает (у меня, во всяком случае).
Модификаторы НЕ решают эту проблему - попробовал написать длинных модификатор, и он не был воспринят. Видимо длина его всё же ограничена чем-то (может размер поля БД, или ещё чего, пока не искал). Причём, если делить модификатор, все части работают - то есть ошибок синтаксиса нет.
Темы читаем, а об актуальности судим по количеству заинтересованных и частоте запросов (кстати, не только здесь, но и в техподдержку). Затем сопоставляем со сложностью внедрения и тем, насколько это будет полезно широкому кругу пользователей. На самом деле факторов больше, но общий принцип именно такой.
Это известная проблема; вот как сделать, чтобы длинные модификаторы работали. В будущих версиях там по умолчанию будет ограничение в 50 000 символов (т.е. в 50 раз больше, чем сейчас), как раз для подобных случаев.
Поддержу коллегу @aksenovaa что импорт rкатегорий немного не доработан если в магазине несколько сотен или еще хуже тысяч категорий, то нужно написать несколько сотен или тысяч модификаторов, намного удобнее было бы сделать таблицы соответствий для категорий, чтобы указать какие категории куда направить, особенно это удобно было бы когда товар нужно направить в несколько категорий вместо того чтобы писать варианты модификаторов.
Также у меня допустим не получилось настроить импорт по xml yml из одного магазина на ЦС карт в другой - импортирующий магазин просто не принимает файл
Также есть проблема хоть и не значительная с обнулением количества - если оно формируется при помощи модификатора, то полученное количество не проставляется а просто обнуляется нужно делать 2 импорта сначала с включеным обнулением потом с выключенным если кто- то делает по крону то нужно ставить два задания с обнулением и без один за другим