Comments 26
Я занимаюсь созданием интернет магазинов, и делал подобные надстройки на openCart и другие платформы.
И я могу с уверенностью сказать, что данный подход скрывает множество подводных камней.
Например, он может быть абсолютно удобен только в случае, если каталог товаров не слишком велик, и его вполне реально забивать в ручную.
Основная проблема в том, что большинство поставщиков предоставляют «плоские» прайс-листы, не подразумевающие разбиение комплектаций по характеристикам.
И, уж тем более, заранее не известно — какие именно допустимые характеристики комплектаций могут быть у товара (оговорюсь, что эту проблему частично удавалось решить парсом характеристик товара по артикулу из ЯМ, но в этом случае комплектации получались слишком «многомерными»).
Как вы собираетесь решать (или, возможно, уже решили) данную проблему?
И я могу с уверенностью сказать, что данный подход скрывает множество подводных камней.
Например, он может быть абсолютно удобен только в случае, если каталог товаров не слишком велик, и его вполне реально забивать в ручную.
Основная проблема в том, что большинство поставщиков предоставляют «плоские» прайс-листы, не подразумевающие разбиение комплектаций по характеристикам.
И, уж тем более, заранее не известно — какие именно допустимые характеристики комплектаций могут быть у товара (оговорюсь, что эту проблему частично удавалось решить парсом характеристик товара по артикулу из ЯМ, но в этом случае комплектации получались слишком «многомерными»).
Как вы собираетесь решать (или, возможно, уже решили) данную проблему?
UFO just landed and posted this here
Если вы продаете всего 15 товаров, то действительно важно, чтобы как можно больше из них вылезли в топ и в данном случае группировка ни к чему.
А если вы продаете 15 тысяч товаров, которые после группировки образуют 10 тысяч товаров, то удобство навигации по товарам для пользователей, на мой взгляд, уже перевешивает. При том, что не факт, что вы потеряете позиции по точным запросам «Iphone 4 Белый 16 Гб», в движке есть все инструменты для работы с СЕО.
При смене комплектации сейчас изменяются — характеристики, артикул, цена. Смена фото у нас появится в следующих версиях. ( Смену фото можно сделать на уровне шаблонов уже сейчас, несложным javaScript'ом ) Если требуется менять описание, то наверное, это уже должен быть другой товар. По крайней мере инструмент задумывался так ( и в 1С для характеристик номенклатуры нельзя задать различные описания )
Сортировка по цене будет выстраиваться по цене «характеристики по умолчанию», т.е. в вашем примере первым будет Iphone.
А если вы продаете 15 тысяч товаров, которые после группировки образуют 10 тысяч товаров, то удобство навигации по товарам для пользователей, на мой взгляд, уже перевешивает. При том, что не факт, что вы потеряете позиции по точным запросам «Iphone 4 Белый 16 Гб», в движке есть все инструменты для работы с СЕО.
При смене комплектации сейчас изменяются — характеристики, артикул, цена. Смена фото у нас появится в следующих версиях. ( Смену фото можно сделать на уровне шаблонов уже сейчас, несложным javaScript'ом ) Если требуется менять описание, то наверное, это уже должен быть другой товар. По крайней мере инструмент задумывался так ( и в 1С для характеристик номенклатуры нельзя задать различные описания )
Сортировка по цене будет выстраиваться по цене «характеристики по умолчанию», т.е. в вашем примере первым будет Iphone.
Безусловно для использования многомерных комплектаций, контент должен быть качественно подготовлен, либо в 1С, либо в нашем формате CSV для импорта, либо в самой админке. Мы исходим из того, что продавец должен иметь информацию о том какие комплектации возможны для его товара.
Если прайс поставщика содержит данные в не самом удобном виде, то есть 2 варианта:
1. С помощью инструментов одиночного или массового редактирования в админке приводить товары в порядок, после частичной загрузки данных из CSV.
2. Писать простенький скрипт, приводящий прайс поставщика к виду нашего CSV (это на случай, если из прайса поставщика все-таки можно извлечь необходимую информацию или скрипт может дополнить её).
Насчет чрезмерной многомерности, действительно у нас есть ограничение — не более 500 простых комплектаций, порождаемых многомерными. В противном случае это скажется на производительности, да и администрировать такое количество сочетаний товара — практически нереально.
Если прайс поставщика содержит данные в не самом удобном виде, то есть 2 варианта:
1. С помощью инструментов одиночного или массового редактирования в админке приводить товары в порядок, после частичной загрузки данных из CSV.
2. Писать простенький скрипт, приводящий прайс поставщика к виду нашего CSV (это на случай, если из прайса поставщика все-таки можно извлечь необходимую информацию или скрипт может дополнить её).
Насчет чрезмерной многомерности, действительно у нас есть ограничение — не более 500 простых комплектаций, порождаемых многомерными. В противном случае это скажется на производительности, да и администрировать такое количество сочетаний товара — практически нереально.
1. А если белые айфоны есть только с 64 Гб и Wi-Fi? Клиент что увидит?
2. А цены на комплектацию как назначать? Через матрицу цен?
3. Имхо правильнее было бы линеаризовать составную комплектацию, особенно если вариантов меньше 6, было бы сразу видно, какие варианты можно купить, а какие нельзя.
Т.е. так:
* белый, 16Gb, Wi-Fi+3G
* черный, 32Gb, Wi-Fi
* черный, 64Gb, Wi-Fi+3G
2. А цены на комплектацию как назначать? Через матрицу цен?
3. Имхо правильнее было бы линеаризовать составную комплектацию, особенно если вариантов меньше 6, было бы сразу видно, какие варианты можно купить, а какие нельзя.
Т.е. так:
* белый, 16Gb, Wi-Fi+3G
* черный, 32Gb, Wi-Fi
* черный, 64Gb, Wi-Fi+3G
Добавлю лишь то, что ВСЕ варианты группировки/сортировки/показа могут быть в одном магазине. В разделе ноутбуков обычно самая «шоколадка», а в телефонах попроще.
1. В случае, если сочетания Черный-16GB-WiFi не существует, есть возможность поставить данному сочетанию остаток — 0. В этом случае его нельзя будет купить.
2. Если установить флажок «использовать многомерные комплектации» и нажать кнопку «создать», то система сама создаст плоский список комплектаций на основе возможных значений параметров. Т.е. цены задаются в плоском списке.
3. Можно ведь линеаризовать, используя для такого случая простые комплектации.
2. Если установить флажок «использовать многомерные комплектации» и нажать кнопку «создать», то система сама создаст плоский список комплектаций на основе возможных значений параметров. Т.е. цены задаются в плоском списке.
3. Можно ведь линеаризовать, используя для такого случая простые комплектации.
1. Но выбрать можно будет? Неудобненько выходит в таком случае. Выбрать можно, а купить нельзя.
2. ок
3. Не подойдет, если цена зависит от набора параметров. Я имел в виду линеаризовать для клиента.
2. ок
3. Не подойдет, если цена зависит от набора параметров. Я имел в виду линеаризовать для клиента.
Если нужно представить в линейном виде, т.е. по сути с одним параметром, то в админке нет смысла создавать многомерные комплеткации.
У простых комплектаций можно задавать цену.
Посмотрите, в данной статье есть пример с комплектациями планшета 16,32,64 GB, можно по аналогии назвать комплектации:
* белый, 16Gb, Wi-Fi+3G
* черный, 32Gb, Wi-Fi
* черный, 64Gb, Wi-Fi+3G
У простых комплектаций можно задавать цену.
Посмотрите, в данной статье есть пример с комплектациями планшета 16,32,64 GB, можно по аналогии назвать комплектации:
* белый, 16Gb, Wi-Fi+3G
* черный, 32Gb, Wi-Fi
* черный, 64Gb, Wi-Fi+3G
В поиске товар отсутствующие не должен вылезать, как и в каталогах, а по прямой ссылке страница быть должна.
Что бы такой «сложносоставной» товар был понят 1С при загрузке, нужно чтобы он был изначально был выгружен из 1С с его уникальным кодом, входящих в него опций, и у каждого нового товара, этот код опций уникален. В 1С есть дословно товар «Iphone 4 Белый 16 Гб» с кодом «много_символов». Он у вас может выгрузится как раз с единым названием и кодом. По существу это главный товар «Iphone 4» и подтипы товара «Iphone 4 Белый 16 Гб», «Iphone Черный 16 Гб » и т.д. В заказе 1С должна получить уникальный код готового сборного товара с опциями, а не код главного товара и название характеристик. Во первых названия могут не совпадать с названиями в 1С, для каждого товара они уникальны, для каждой группы они могут иметь разные коды и склад. Стандартная логика выгрузки 1С от Битрикса даже не дает такой возможности. Вы можете их выгрузить как характеристики для выбора на стороне сайта, а вот собрать их в читаемый код в самой 1С (для учета цены и склада) при поступлении заказа не получится так просто, нужно дорабатывать (особенно если сама платформа не была изначально заточена на обмен с 1С с ее системой ключей в характеристиках). Ну и если у вас не УТ 8,2-8,3 то само собой этого сделать не получится, узконаправленные, но популярные конфигурации проходят мимо.
Если логика ПО использует нативную логику обработчика 1С (сделанный Битриксом), то возможности синхронизации будут весьма скромные. Но не надо печалиться, есть хорошая альтернатива штатной 1С синхронизации…
Если логика ПО использует нативную логику обработчика 1С (сделанный Битриксом), то возможности синхронизации будут весьма скромные. Но не надо печалиться, есть хорошая альтернатива штатной 1С синхронизации…
Всплакнул читая комментарий. Вспоминаю свой опыт выгрузки из 1С более 75 млн scu (более 10 складов, магазинов со складами, магазины без склада, сотни поставщиков), у поставщиков свои id|scu товаров, группировка по штрихкодам и т.п. В момент разработки и последующей работы столько наелись всего…
1С более 75 млн scuБудет что рассказать внукам. Обычно так много scu у автозапчастей, или? Кстати, сама баз 1С на чем стояла или там несколько было баз на разных машинах? Когда такие объемы то первый удар в ребро дает сама 1С и ее «очень быстрая работа».
БД 1С на sql, был слейв для выгрузок на сайт+ селейв для олап/аналитики
сама 1С кстати менее грузила сервак, чем аналитика и обработки импорта товаров. При добавлении товара в корзину происходил доп расчет времени доставки в зависимости от нахождения данного товара на складе магазина/региональном складе/складе поставщика в регионе или центральном.
сама 1С кстати менее грузила сервак, чем аналитика и обработки импорта товаров. При добавлении товара в корзину происходил доп расчет времени доставки в зависимости от нахождения данного товара на складе магазина/региональном складе/складе поставщика в регионе или центральном.
Чтобы в заказе 1С (который был загружен с сайта) были выбраны «характеристики номенклатуры» у товаров (те, что заказали на сайте),
товар с такими характеристиками номенклатуры должен присутствовать в 1С и быть выгружен на сайт предварительно. Цена в заказе 1С устанавливается та, что была на сайте в момент заказа.
Насчет возможностей стандартного модуля обмена, то его вполне хватает, для обычных схем торговли. Все сведения, что отдает 1С в XML по товарам успешно выгружаются на сайт, заказы успешно загружаются в 1С.
товар с такими характеристиками номенклатуры должен присутствовать в 1С и быть выгружен на сайт предварительно. Цена в заказе 1С устанавливается та, что была на сайте в момент заказа.
Насчет возможностей стандартного модуля обмена, то его вполне хватает, для обычных схем торговли. Все сведения, что отдает 1С в XML по товарам успешно выгружаются на сайт, заказы успешно загружаются в 1С.
А у меня в поддержке несколько магазинов на magentocommerce
Там эта штука по комплектациям называется Custom Options у товаров и тоже можно сколько угодно их создавать, но проблема в том что для опций складской учет нельзя вести — т.е. складской учет только для самого товара.
Есть также ещё одна интересная возможность — создавать (импортировать скорее при больших кол-ах) товары как обычные, каждый со своим набором выбранных опций, а потом их связывать в один товар по этим опциям. Таким образом система сама скушает нужные простые товары и доступные варианты опций, и на фронте выведет один товар, в котором будет доступно переключение лишь доступных вариантов опций (т.е. после выбора любого параметра — остальные фильтруются скриптом). Т.е. если у нас нет простого товара iPhone 4s 64GB Black к примеру в наличии или вообще в системе, но есть iPhone 4s 32GB Black, то при выборе 64GB опция Black обрежется из выбора
Но все-равно мы пришли к выводу (как и некоторые комментаторы выше), что лучше и проще делать иначе и для СЕО и для удобства пользователей. В админке создаются все товары во всех возможных вариациях. Там же они объединяются в групповые товары. В поиске и всяких выгрузках на маркеты участвуют простые товары как есть, а вот в каталоге выводится именно групповой товар. Сам же групповой товар на странице является просто оберткой по сути — зайдя на него мы видим список его подчиненных товаров и можем добавить в корзину любой из них или перейти на карточку этого подчиненного товара — где есть его конкретное описание и т.д.
Как-то все-же последний вариант видится наиболее подходящим и удобным с моей точки зрения…
Там эта штука по комплектациям называется Custom Options у товаров и тоже можно сколько угодно их создавать, но проблема в том что для опций складской учет нельзя вести — т.е. складской учет только для самого товара.
Есть также ещё одна интересная возможность — создавать (импортировать скорее при больших кол-ах) товары как обычные, каждый со своим набором выбранных опций, а потом их связывать в один товар по этим опциям. Таким образом система сама скушает нужные простые товары и доступные варианты опций, и на фронте выведет один товар, в котором будет доступно переключение лишь доступных вариантов опций (т.е. после выбора любого параметра — остальные фильтруются скриптом). Т.е. если у нас нет простого товара iPhone 4s 64GB Black к примеру в наличии или вообще в системе, но есть iPhone 4s 32GB Black, то при выборе 64GB опция Black обрежется из выбора
Но все-равно мы пришли к выводу (как и некоторые комментаторы выше), что лучше и проще делать иначе и для СЕО и для удобства пользователей. В админке создаются все товары во всех возможных вариациях. Там же они объединяются в групповые товары. В поиске и всяких выгрузках на маркеты участвуют простые товары как есть, а вот в каталоге выводится именно групповой товар. Сам же групповой товар на странице является просто оберткой по сути — зайдя на него мы видим список его подчиненных товаров и можем добавить в корзину любой из них или перейти на карточку этого подчиненного товара — где есть его конкретное описание и т.д.
Как-то все-же последний вариант видится наиболее подходящим и удобным с моей точки зрения…
Если уже пошли название CMS аналогов стартопика, то я писал про подтипы товаров у PHPShop + учет таких товаров при загрузке в 1С + поддержка большого количества версий 1С и конфигураций из коробки. Спасибо за признание такого подхода, но такой вариант результат 10 летней работы и наличие в штате 1С разработчиков, которые быстро развенчивают мечты синхронизации 1С с ее возможностями и формулами. Можно создать хороший магазин — но это только половина задачи. Не желая изобретать свой велосипед (или экономя ресурсы, что больше вероятно) все стараются использовать нативные обработки — но в некоторых моментах это не даст нужного результата. Настроить простую синхронизацию товаров — да. А если шаг в сторону, например учет сложносоставных товаров, обработка изображений (нарезка, ватермарк, поиск изображений в сети), выгрузка печатных копий отчетных документов, интерактивные прайс-листы и т.д. — то начинается новый квест (обычно клиенту сообщается пренеприятнейшую новость о том, что CMS только принимает файлы, для новых возможностей нужно искать 1С разработчика, который еще и должен разбираться в CMS магазина — тупик или потеря денег/времени клиента).
Не совсем понял суть ответа Вашего.
Я написал что наиболее безболезненным является (на мой взгляд) подход — иметь все товары, как обычные товары (т.е. то что якобы из коробки есть везде и с 1С так или иначе не сложно прикрутить для интеграции), а уже для удобства пользователя объединять их в группы на сайте. Т.е. группу купить нельзя, можно только простой товар внутри группы.
Таким образом для 1С получаем тоже упрощенную схему интеграции, не важно 1С забирает данные с сайта или мы из 1С грузим данные на сайт изначально — все товары получаются линейными без каких-либо опций, каждый товар имеет свой артикул уникальный и набор свойств — их и пробрасываем туда-сюда. И тогда не надо 1С разработчику изучать CMS или ещё чтото — делай как угодно.
Конечно я не говорю что при таком подходе все идеально гладко и все само работает из коробки ))), но он может упростить работу в целом
Вообще конечно не претендую на лучший вариант и в разных ситуациях могут быть более эффективны разные подходы. Есть проекты, которые по своим причинам используют подход с опциями и добавочными ску или вовсе без добавочных, но в таком случае просто напросто складской учет просто не ведется в разрезе опций или часто товары, выбранные на сайте, приходится заменять на другие уже через манагеров
Т.е. например некий товар имеет разные цвета и они на цену не влияют — в 1С у них все эти товары через 1 ску (1 товар), а по факту узнаю есть тот или иной цвет только просмотрев на складе вручную. В таком случае нет смысла делать отдельные товары — добавил опцию и вперед. Но такой подход применим наверно только для достаточно небольших магазинов
Я написал что наиболее безболезненным является (на мой взгляд) подход — иметь все товары, как обычные товары (т.е. то что якобы из коробки есть везде и с 1С так или иначе не сложно прикрутить для интеграции), а уже для удобства пользователя объединять их в группы на сайте. Т.е. группу купить нельзя, можно только простой товар внутри группы.
Таким образом для 1С получаем тоже упрощенную схему интеграции, не важно 1С забирает данные с сайта или мы из 1С грузим данные на сайт изначально — все товары получаются линейными без каких-либо опций, каждый товар имеет свой артикул уникальный и набор свойств — их и пробрасываем туда-сюда. И тогда не надо 1С разработчику изучать CMS или ещё чтото — делай как угодно.
Конечно я не говорю что при таком подходе все идеально гладко и все само работает из коробки ))), но он может упростить работу в целом
Вообще конечно не претендую на лучший вариант и в разных ситуациях могут быть более эффективны разные подходы. Есть проекты, которые по своим причинам используют подход с опциями и добавочными ску или вовсе без добавочных, но в таком случае просто напросто складской учет просто не ведется в разрезе опций или часто товары, выбранные на сайте, приходится заменять на другие уже через манагеров
Т.е. например некий товар имеет разные цвета и они на цену не влияют — в 1С у них все эти товары через 1 ску (1 товар), а по факту узнаю есть тот или иной цвет только просмотрев на складе вручную. В таком случае нет смысла делать отдельные товары — добавил опцию и вперед. Но такой подход применим наверно только для достаточно небольших магазинов
Я написал что наиболее безболезненным является (на мой взгляд) подход — иметь все товары, как обычные товары (т.е. то что якобы из коробки есть везде и с 1С так или иначе не сложно прикрутить для интеграции), а уже для удобства пользователя объединять их в группы на сайте. Т.е. группу купить нельзя, можно только простой товар внутри группы.
Из коробки в 1С как раз все не так. Он выгружает 1 товар и набор характеристик к нему. Это 1 товар, а не группа товаров. Если это небольшой магазин — то зачем ему вообще 1С?
Ну все правильно — 1 товар и характеристики к нему. А групповых товаров в 1С и нету — они уже создаются на самом сайте и чисто для удобства пользователей, их нельзя продать — поэтому в 1С они и не нужны.
Т.е. в 1С есть отдельные товары:
ip4sb64 / iPhone 4s Black 64 GB / Color: Black / Mem: 64GB / Price: 1$
ip4sw32 / iPhone 4s White 32 GB / Color: White / Mem:32GB / Price: 1$
…
И на сайте они есть 1 в 1. Именно их артикул передается при заказе, именно по этому артикулу обновляются / загружаются товары между сайтом и 1с
Но на сайте дополнительно создается ещё товар
ip4s-gr / iPhone 4s / Далее могут быть некие характеристики, а могут и не быть / Дочерние товары: ip4sb64 | ip4sw32…
Т.е. в 1С есть отдельные товары:
ip4sb64 / iPhone 4s Black 64 GB / Color: Black / Mem: 64GB / Price: 1$
ip4sw32 / iPhone 4s White 32 GB / Color: White / Mem:32GB / Price: 1$
…
И на сайте они есть 1 в 1. Именно их артикул передается при заказе, именно по этому артикулу обновляются / загружаются товары между сайтом и 1с
Но на сайте дополнительно создается ещё товар
ip4s-gr / iPhone 4s / Далее могут быть некие характеристики, а могут и не быть / Дочерние товары: ip4sb64 | ip4sw32…
Не дописал — в продолжение у предыдущему…
Т.е. групповые нужны при большом кол-е различных похожих на сайте и вообще при большом кол-е товаров и они на мой взгляд лучше, чем товары с опциями в виде выпадающих списков / радио или чекбоксов — не суть (хотя наверняка найдутся товары, для которых лучше использовать опции — т.е. какой-нибудь тросс продаваемый по длинне не особо нужно разделять на отдельные товары...)
Ну а на счет небольших — тут кто как понимает небольшие ))) кол-во позиций небольшое на сайте — в реальности же если разложить позиции по всем возможным опциям и вариациям — получится с несколько тысяч позиций…
Т.е. групповые нужны при большом кол-е различных похожих на сайте и вообще при большом кол-е товаров и они на мой взгляд лучше, чем товары с опциями в виде выпадающих списков / радио или чекбоксов — не суть (хотя наверняка найдутся товары, для которых лучше использовать опции — т.е. какой-нибудь тросс продаваемый по длинне не особо нужно разделять на отдельные товары...)
Ну а на счет небольших — тут кто как понимает небольшие ))) кол-во позиций небольшое на сайте — в реальности же если разложить позиции по всем возможным опциям и вариациям — получится с несколько тысяч позиций…
Товары с комплектациями экспортируются нашей платформой в Яндекс.Маркет в виде отдельных товаров.
У товаров формируются URL'ы, такого вида:
/product/Apple-iPhone-4/
/product/Apple-iPhone-4/#1
/product/Apple-iPhone-4/#2
…
Наименование товара автоматически формируются из названия и комплектации.
При посещении страницы с хэшем, автоматически выбирается соответствующая комплектация.
Пример:
http://full.readyscript.ru/product/Planshet-Archos-A9-PCtablet/#1
http://full.readyscript.ru/product/Apple-iPhone-4/#3
У товаров формируются URL'ы, такого вида:
/product/Apple-iPhone-4/
/product/Apple-iPhone-4/#1
/product/Apple-iPhone-4/#2
…
Наименование товара автоматически формируются из названия и комплектации.
При посещении страницы с хэшем, автоматически выбирается соответствующая комплектация.
Пример:
http://full.readyscript.ru/product/Planshet-Archos-A9-PCtablet/#1
http://full.readyscript.ru/product/Apple-iPhone-4/#3
Sign up to leave a comment.
Реализация комплектаций товаров в интернет-магазинах ReadyScript