К сожалению, не знаю как Вас зовут.
У него под каждым сообщением подпись с именем и фамилией. Ищущий да обрящет! )
У него под каждым сообщением подпись с именем и фамилией. Ищущий да обрящет! )
Илья Макаров, простите :)
Поддерживаю, я примерно об этом писал выше.
Нужен флаг для каждой строки
Add, Rewrite, Skip (Miss).
Add -добавляет или перезаписывает все.
Rewrite - только добавляет только новые значения
Skip - пропускает строчку.
Если флага нет, то Add.
Ну, вы писали не об этом. Вы хотите зачем-то исключать из импорта определенные строки, тогда просто удалите их и все, зачем все эти сложности. Мы говорим о другом, о том как поступать с определенными полями товаров, в частности, с полем Secondary category, так как есть необходимость в нескольких вариантов импорта этого поля - перезаписать все доп. категории, либо только добавить доп. категории к уже имеющимся у определенного товара.
Проблема в том, что после импорта товаров с характеристиками в базе CS-Cart появляется куча "левых" вариантов харатеристик, которые не соответствуют названиям "наших" вариантов. Для примера, в файле одного поставщика вариант характеристики Цвет - вишневый, у другого - алый, у третьего - томатный, а у нас в базе - красный. После импорта появятся в базе все эти ненужные варианты по сути одного цвета - красный. Необходимо заменить все эти множества названий вариантов характеристик одним вариантом, который установлен у нас в базе, либо если еще не установлен тем, который нам нужен (чтобы было под контролем). Можно это делать до импорта в самом CSV файле поставщика, заменять варианты, но тут возможны ошибки, так как не всегда точно можно сопоставить с тем, что есть в базе, да и что-то упустить возможно, а если загружать прайс-поставщика по крону автоматически, то этот способ - уже не подходит. Вы предложили свой способ решения - сопоставить варианты характеристик из файла поставщика во время импорта с помощью правил замены формулой, но этот вариант очень сложен так как формула будет очень сложной, да и тоже не все можно учесть, если делать автоматически по крону, то в какой-то момент у поставщика появятся варианты характеристик, которые ранее не были описаны в правилах замены, и они попадут в базу CS-Cart. Мы предлагаем обрабатывать варианты характеристик уже после импорта, что будет удобно, когда у нас импорт товаров идет по крону автоматически. 1. Выводить статистику, какие варианты характеристик и у какой именно характеристики были они добавлены после импорта. 2. Создать обработчик, который поможет наглядно объединять в админке несколько вариантов характеристик в один с нужным названием (при этом, чтобы у всех товаров, которые имели отличные названия вариантов характеристик заменялись на нужные). Возможно это можно решить экспортом/импортом вариантов характеристик, например, выгружаем все варианты нужной характеристики, в файле CSV правим названия на нужные и загружаем обратно, тут уже вам виднее как будет работать в этом случае функционал импорта с объединением вариантов характеристик.
А может у вас появится совершенно другое лучшее решение как решить проблему с "размножением" вариантов характеристик в базе CS-Cart после импорта товаров?!
Здравствуйте.
>1. Выводить статистику, какие варианты характеристик и у какой именно характеристики были они добавлены после импорта.
очень трудоемко с технической точки зрения. А ответ на вопрос зачем это нужно пока только один - ваш сценарий работы с характеристиками.
>Создать обработчик, который поможет наглядно объединять в админке несколько вариантов характеристик в один с нужным названием
Это чистая доработка, и она явно не для ядра.
Вывод здесь такой что у вас довольно специфичный сценарий работы с импортируемыми характеристиками, и ядро мы под него допиливать не будем.
Сожалею что не могу помочь вам.
Поиск только что импортированных товаров в данном случае плох тем, что искать ты можешь, когда уже импортировал. Это удобно, конечно. Но для отлавливания багов импорта полезнее было бы видеть результат еще "До" импорта. Т.е. превью.
В случае превью ты имеешь инструмент по предотвращению появления "косяков". В случае с поиском имеешь инструмент по поиску уже появившихся косяков.
Отображение данных из первой строки - это однозначно нужная вещь. Выше описал причины.
Почему полное превью тоже имеет право на жизнь:
При относительно небольшом загружаемом прайсе от поставщика (до 500 строк) вполне реально просмотреть импортируемый файл еще до его загрузки (при наличии такой возможности). Техническую "правильность" импорта покажет превью первой строки, но превью первой строки не покажет косяки из серии "поставщик сменил артикул". Такие моменты могут привести к тому, что одна позиция однажды может быть загружена "в другую".
Может быть стОит добавить возможность ПОЛНОГО превью импорта в качестве опции (например, флаг) для параноиков вроде меня?
Пока цель такая: сделать нормальный рабочий (предсказуемый) импорт
Одно из следствий этой цели: иметь возможность посмотреть результаты
В случае если мы с основной целью налажаем и не будем понимать как это поправить то будем углубляться в подобные детали. Но я верю в лучшее и делаю все для этого.
Просмотр всех полей это ведь по большому счету костыли. Паранойю надо лечить надежным рабочим инструментом а не дополнительными проверками - это мое имхо)
Дополнительные инстурменты вроде сопоставления полей они ведь мешают, это дополнительная нагрузка как на разработчиков (разработка, сопровождение, улучшение) так и на клиентов (нафига оно тут вообще, зачем мне сравнивать если я могу на реальных продуктах все это увидить)
На этом предлагаю данный вопрос оставить в покое.
На этом предлагаю данный вопрос оставить в покое.
ОК, будем ждать идеально работающего инструмента!
Привет,
Одна из самых важных фич при импорте, это сопоставление полей из файла импорт со свойствами товара в CS-Cart.
Например надо как то указать что в файле импорта поле которое называется "КОД Товара" является артикулом (product_code)
Мы подготовили два варианта интерфейса сопоставления полей. Пожалуйста напишите как вам ближе, что не понятно? Т.е. понимаете ли вы все элементы на этой странице и их предназначение.
первый макет:
[attachment=12959:import_vertical.jpg]
второй макет:
[attachment=12960:import_horizontal.jpg]
Первый макет. Он плоский по структуре, а это хорошо.
На втором макете, если будет много полей, будет неудобно.
Однозначно первый макет. Все интуитивно понятно при первом взгляде на интерфейс. При просмотре второго макета понадобилось некоторое время, чтобы разобраться что к чему в этом интерфейсе.
Однозначно первый макет. Все интуитивно понятно при первом взгляде на интерфейс. При просмотре второго макета понадобилось некоторое время, чтобы разобраться что к чему в этом интерфейсе.
Ну и горизонтальный скролл куда хуже, чем вертикальный.
Первый макет. Он плоский по структуре, а это хорошо.
На втором макете, если будет много полей, будет неудобно.
Однозначно первый макет. Все интуитивно понятно при первом взгляде на интерфейс. При просмотре второго макета понадобилось некоторое время, чтобы разобраться что к чему в этом интерфейсе.
Спасибо. Провели так же голосование внутри компании.
Результаты 26 за 1 макет, и никого за 2й:)
...
1. Пожалуйста пришлите примеры прайс листов, которые вы хотите импортировать
...
Всем привет! Чтобы сделать новый импорт максимально удобным, для нас сейчас особенно актуальна эта просьба: присылайте, пожалуйста, примеры прайс-листов от поставщиков. Объясню, зачем нам это нужно.
В будущей версии CS-Cart 4.7.2 в рамках старого импорта мы добавим возможность создания вариаций через импорт. Работать будет так, как описано в этой статье. К нам обратился клиент с пожеланием улучшить этот процесс: в файле, который предоставляет ему поставщик, каждая вариация перечислена как отдельный товар. Чтобы импортировать вариации, клиенту пришлось бы создавать перед каждой группой вариаций запись о настраиваемом товаре.
Мы думаем, как сократить количество действий администратора при иморте. Поэтому хотим собрать сведения, в каком виде к вам попадают от поставщиков файлы, которые вы затем импортируете в CS-Cart в формате CSV. Особенно интересует два момента:
1. Есть ли у вас в прайс-листе отдельная запись о настраиваемом товаре перед группой вариаций?
2. Идут ли у вас вариации одного товара последовательно, или же между ними может оказаться какой-то другой товар?
Будет лучше, если мы увидим прайс-листы своими глазами. По опыту знаем, что если присылают небольшой фрагмент без всех столбцов или условный пример, то наверняка возникнут дополнительные вопросы (которые отпали бы, будь у нас прайс-лист перед глазами). Естественно, ваши комментарии по сложностям, которые у вас возникают, тоже приветствуются.
1. Есть ли у вас в прайс-листе отдельная запись о настраиваемом товаре перед группой вариаций?
2. Идут ли у вас вариации одного товара последовательно, или же между ними может оказаться какой-то другой товар?
1. Крайне специфично поставлен вопрос. Несколько толкований. Сможете его переформулировать по иному?
2. Даже если сейчас идут по порядку, завтра могут пойти вразнобой. Здесь на несколько присланных примеров не стоит ориентироваться. Если реализовывать - то только общий случай, считать, что все в разнобой.
Есть ли у вас в прайс-листе отдельная запись о настраиваемом товаре перед группой вариаций?
Крайне специфично поставлен вопрос. Несколько толкований. Сможете его переформулировать по иному?
Постараюсь переформулировать:
В 4.7.2 мы добавили возможность создавать вариации через импорт. Поэтому импорт вариаций будет выглядеть так:Порядок товаров важен: сначала идет запись о настраиваемом товаре (тип C), затем все его вариации (тип V). Запись о простом товар (тип P) не может вклиниваться в список между вариациями.
Мы пытаемся понять, как улучшить этот процесс. Наверняка в ваших прайс-листах нет записи Футболка X перед записями:
- Футболка X, красная, размер S
- Футболка X, синяя, размер M
Мы пытаемся понять, как улучшить этот процесс. Наверняка в ваших прайс-листах нет записи Футболка X перед записями:
- Футболка X, красная, размер S
- Футболка X, синяя, размер M
Т.е. такую запись при импорте CSV нужно добавлять вручную, а это лишняя работа.
Тут, так понимаю, речь не идет о "лишней работе". При такой логике импорта, отсутствие правильно указанной записи типа "С", приведет к краху данных. То есть, речь идет о банальной защите данных, т.к.
при отсутствии правильно указанной записи типа "С", товары типа "V" прицепятся и станут вариациями предыдущего в списке импорта товара типа "С", т.е. в товарах начинается хаос, который править возможно только вручную..
Импорт вариаций получается проблемным.
Это совсем не гуд...
Нужна, как минимум, предварительная диагностика-проверка данных.
у Вас в документации написано
Если между вариациями окажется запись с простым товаром (т.е. последовательность записей CVPV, а не PCVV или CVVP), то при импорте будет выдана ошибка.
случай CVPV включает проверку на PV или PVV?
Но это, к сожалению, не решит всю проблемность.. :-(
И встает в полный рост вопрос к разработчикам.
а API cs-cart с вариациями уже работает?
Тут, так понимаю, речь не идет о "лишней работе". При такой логике импорта, отсутствие правильно указанной записи типа "С", приведет к краху данных. То есть, речь идет о банальной защите данных, т.к. при отсутствии правильно указанной записи типа "С", товары типа "V" прицепятся и станут вариациями предыдущего в списке импорта товара типа "С", т.е. в товарах начинается хаос, который править возможно только вручную..
Импорт вариаций получается проблемным.
Нет, сейчас мы думаем именно над тем, можно ли как-то облегчить для администраторов подготовку CSV-файла в рамках нового импорта товаров (поэтому и просим примеры прайс-листов). Меры для защиты данных при импорте вариаций в 4.7.2 уже есть:
1. Проверяется, есть ли у вариации значение в столбце Variation options (это сочетание опций, которое образует вариацию), например:
Цвет: Синий|Размер: М2. Проверяется, есть ли родительский настраиваемый товар. Например, если последовательность товаров CVVVPVV, то у двух вариаций, которые идут после простого товара (тип P) родитель найден не будет, и соответвтвенно, они не импортируются.
3. Проверяется, есть ли у родительского настраиваемого товара те опции и варианты этих опций, которые указаны в Variation options. Если нет, то конкретно эта вариация не импортируется.
4. Проверяется, существует ли уже вариация с такими Variation options. Например, я создал две вариации с одинаковым Variation options, и импортировалась только первая. По второй выдалась ошибка, что вариация с такими Variation options уже существует.
Как видите, чтобы даже одна вариация оказалась приписанной не к тому товару, нужно очень много совпадений (зачастую проблемная вариация просто будет пропущена при импорте). Кроме того, теперь есть сохранённый поиск "Недавно обновлённые" на списке товаров в панели администратора. Т.е. после импорта можно зайти и проверить, правильно ли обновились товары. А с расширенным поиском вы сможете, например, найти все настраиваемые товары, которые были обновлены за последний час, и уже у них на вкладке "Вариации" всё проверить.
И встает в полный рост вопрос к разработчикам.
а API cs-cart с вариациями уже работает?
Есть сущность product_variations (документация по REST API у нас на данный момент только на английском). Существует ещё с 4.6.1, но мы её особо не анонсировали - пока модуль в бете, вероятность серьёзных изменений в нём выше, и эти изменения могут попадать в патчевые релизы (например, в 4.7.2 или 4.7.3, а не только в 4.8.1).
сейчас мы думаем именно над тем, можно ли как-то облегчить для администраторов подготовку CSV-файла в рамках нового импорта товаров (поэтому и просим примеры прайс-листов).
Иван, понимаю, что проделано много-много работы, но здесь два варианта.
либо признать что в проектировании был просчет и переделать логику,
либо сейчас бесконечно долго делать заплатки и сложные инструкции и уговаривать пользователей, что это они во всем виноваты, т.к. не следовали этим инструкциям ( по второму пути пошел Webasyst, сделав похожую зависимость связи данных при импорте-экспорте от порядка следования товаров)
Вот поймите меня правильно. Я на Вашей стороне, и на стороне cs-cart.
Может быть, заново перепроектировать этот потенциально проблемный функционал?
Для однозначной идентификации связей вариаций, нужно поле с кодом головной вариации.
Причем, в этом случае нужность полей P,C,V становится сомнительной.
Зачем пользователю вручную угадывать-устанавливать-менять эти поля, если алгоритмически станет возможно распознать их?
Если есть значение в поле головной(главной-центральной-родительской - назовите как хотите) вариации, то все такие товары становятся вариациями.
Если у товара присутствуют опции, тип - настраиваемый,
а все остальные - простые товары...
Непонятно написал? Или слишком просто и что-то не учитывается?
Или обратной дороги уже нет и перепроектирование экспорта-импорта вариаций невозможно?
Иван, понимаю, что проделано много-много работы, но здесь два варианта.
либо признать что в проектировании был просчет и переделать логику,
либо сейчас бесконечно долго делать заплатки и сложные инструкции и уговаривать пользователей, что это они во всем виноваты, т.к. не следовали этим инструкциям ( по второму пути пошел Webasyst, сделав похожую зависимость связи данных при импорте-экспорте от порядка следования товаров)
Вот поймите меня правильно. Я на Вашей стороне, и на стороне cs-cart.
Может быть, заново перепроектировать этот потенциально проблемный функционал?
Для однозначной идентификации связей вариаций, нужно поле с кодом головной вариации.
Причем, в этом случае нужность полей P,C,V становится сомнительной.
Зачем пользователю вручную угадывать-устанавливать-менять эти поля, если алгоритмически станет возможно распознать их?
Если есть значение в поле головной(главной-центральной-родительской - назовите как хотите) вариации, то все такие товары становятся вариациями.
Если у товара присутствуют опции, тип - настраиваемый,
а все остальные - простые товары...
Непонятно написал? Или слишком просто и что-то не учитывается?
Или обратной дороги уже нет и перепроектирование экспорта-импорта вариаций невозможно?
Здравствуйте,
1. Давайте начнем с того что вы пришлете пример файла который вы импортируете.
2.
Для однозначной идентификации связей вариаций, нужно поле с кодом головной вариации.
Да вариант вполне рабочий, можно и так делать. Текущая реализация не окончательная, потому и подняли эту тему.
3. Есть еще момент как обозначать к како связке опций (комбинации) принадлежит данная вариация
4.
либо признать что в проектировании был просчет и переделать логику,
Чтобы переделать логику нам нужно понять какой она должна быть, это и пытаемся сделать.
imac
Спасибо, Илья, что откликнулся.
Процитированные отдельные цитаты резковато выглядят.. :-) Хотя общий настрой совсем не в резкости заключался.
1.
про прайс-листы вариаций.
Чуть о своем статусе. Я не собственник и-магазина. И не разработчик. Я проектировщик-внедренец. Т.е. проектирую и внедряю целиком работающие системы, где и-магазин - часть. Иногда более, иногда менее значимая, но это - часть. И важно, как она работает в комплексе.. Потому пристально слежу за всеми способами передачи данных и ИЗ и-магазина и В и-магазин.
В последнем проекте, который планировал запустить на вариациях, столкнулся с тем, что функционал оказался не доработан, поэтому отказался от вариаций, и перекроив весь замысел, сделал через опции, чем, признаюсь, не очень доволен.
Это к чему? к тому, что готового прайс-листа с вариациями под руками нет.
Но понятно, что это не последний проект и вариации будут в будущем. и прикидываю, как их использовать. Причем зная, какая каша находится у юзеров в складских программах, оцениваю и проблемные зоны...
2.
3. По связке комбинаций опций и вариациям. Вот тут не могу охватить весь замысел, но, ей-богу, не понимаю, зачем вариации привязывать к опциям, а тем более, к их комбинациям?
Комбинации - наверно, неплохое решение, когда опций не много и они заранее известны. А если их много и заранее весь набор комбинаций неизвестен?
Опции и комбинации стоит оставить, как писал, для узких ниш с небольшим числом параметров, а вариации рассматривать как группу простых товаров с различным набором характеристик.
Тогда получается 3 типа товаров (как сейчас и задумано), Простые, настраиваемые и вариации. Но Вариации - это группа простых товаров, а не группа настраиваемых товаров.
Вариации в группе могут отличаться названием, любой из характеристик, несколькими характеристиками, но имеющие свои фото и свою цену.
Если юзер не указал различные характеристики у разных вариаций (или указал одинаковые) это не ошибка. Это просто этап наполнения данных. Он потом сможет это исправить. Но система работает сразу, отражая что у этого товара есть вариации по разным ценам (возможно отличия он зашьет в название)
И так далее . Если двигаться в сторону этой концепции, то можно-нужно оценить и другие сценарии.
Как понимаю, цель создания механизма опций было обоснование изменения цены. Ядро опций - модификатор цены.
а в приведенной концепции обоснование не нужно.
Смотрите
Стаканчик 200 мл, белый, пластмассовый, формы 1 при разнице в стоимости от
Стаканчик 200 мл, синий, металлический, формы 2
требует 3 модификатора цены. Товаровед с ума сойдет, чтобы определить, какие изменения в модификаторах цен сделать в опциях, чтобы получить нужные ему конечные цены. 100 руб и 130 руб
А ему нужно
Стаканчик 200 мл, белый, пластмассовый, формы 1 - 100 руб
с вариацией
Стаканчик 200 мл, синий, металлический, формы 2 -130 руб
или
Стаканчик 200 мл, от 100 до 130 руб
с вариациями
Стаканчик 200 мл, белый, пластмассовый, формы 1 - 100 руб
Стаканчик 200 мл, синий, металлический, формы 2 -130 руб
вот этот момент стоит обсуждать,
но здесь нет никаких комбинаций. Откуда знает товаровед - какое завтра будет поступление? какие варианты цветов, материалов - форм предложат поставщики?
4.
Весь этот спич вызван тем, что задача найти ошибку приходящего прайса с последовательностью вида
VV (1 товар)
VV (2 товар)
V (3 товар)
алгоритмически неразрешима.
А опыт показывает - если дать юзеру возможность сделать ошибку - он ее сделает.