Question

Здравствуйте!

Возникла такая проблема. Делаю на Битрикс магазин одежды. Каждый товар имеет характеристику размер (типа селект, множественная).

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

Делать на каждый размер свой товар не хотелось бы, это очень не удобно. Плюс возможно надо будет сделать тоже самое в зависимости от цвета товара..

Не подскажите как решить данную проблему?

Answer 1

Однажды в закрытом форуме мы уже давали ответ на подобный вопрос.
Попробуем рассмотреть его тут детальнее.

Цитата
Сергей С. пишет: Делать на каждый размер свой товар не хотелось бы, это очень не удобно. Плюс возможно надо будет сделать тоже самое в зависимости от цвета товара..

Вообще, в бухгалтерских системах обычно так товар не хранится. Т.е. одной позиции товара соответствует одна цена и один уникальный код, штрих код (VIN, SCU, XML_ID и подобные аббревиатуры).

Т.е. разный размер товара соответствует разному коду.

Бывают случаи, когда в бухгалтерии не хранят размеры. Мол приняли товар, а цвет и размер в ассортименте. Тогда в системах хранится один товар и выгрузить его и анализировать в разрезе не получается.


Теперь посмотрим, как решить данную проблему представления с продуктом:

Цитата
Сергей С. пишет: Хотелось бы ,что бы пользователь добавлял в корзину товар и мог бы при этом выбрать какое кол-во ему необходимо для каждого размера. Т.е. пользователю необходимо 3 шт. данного товара одного размера и 1 шт. того же товара другого размера.

Каталог делается на базе информационных блоков. Рассмотрим на примере дверей разного размера.

Еще раз повторился бы, что правильным с точки зрения бухгалтерии будет вариант ввода разных позиций товара:

1. Стол 100 см
2. Стол 120 см
и т.д.

Для этого достаточно одного информационного блока.
Для удобства такой вариант можно реализовать с использованием свойств. Т.е. определить в свойствах инфо-блока свойство размер и указывать его для столов и потом искать по нему.

Второй вариант основан на двух инфо-блоках.
Первый инфо-блок создается для хранения каталога товаров. Так как обычно товары бывают не только столы, но и стулья, диваны, гвозди, клей и т.п. То в этом инфо-блоке будет храниться дерево товаров + общие описания самих товаров.

В нашем случае все столы в дереве каталогов будут представлены одной записью "Стол" с какими-то общим описанием товара.

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

Например, все позиции столов будут представлены каждый отдельными записями с разными свойствами размера в инфо-блоке Предложения. Каждый стол будет так же иметь ссылку на Стол в каталоге товаров.

При показе посетитель может выбирать стол и увидеть под ним все варианты предложений данного товара.

В общем, второй варианте не исключает загрузку данных из 1С или другой бэкофисной системы. И вы всегда будете иметь возможность каталог товаров делать удобным для клиентов, а Предложения удобными для реальной продажи.

Конечно, в корзину добавляются объекты из каталога Предложений и они же продаются.

Если необходимо реализовать возможность добавления товара в корзину покупателя с выбором цвета и размера при добвлении.

Для такой задачи можно предложить опять же два варианта реализации в зависимости от идеологии построения каталога.

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

Если вы сделали два инфо-блока: каталог Товаров и каталог Предложений.
Будем считать, что товары в каталоге Предложений обладают свойствами Цвет и Размер. В корзине делается дополнительная обработка, которая позволяет сгруппировать товары по определенной категории каталога Товаров, выбрать доступные для заказа свойства Предложений и показать возможность смены опции для выбора. Реально при смене опции в корзине, происходит удаление одной позиции и добавление другой позиции со своими уникальными идентификаторами. Но делается это прозрачно для пользователя.

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

Answer 2

Спасибо за ответ!

Answer 3

Sergey! Вы не учитываете, что при каталоге цветов несколько десятков, а то и сотен цена будет с большой вероятностью одна и та же. Для изменения цены одной номенклатуры придется менять цены у всех.
В любой программе есть свои нюансы, но предлагать вность декартово произведение (видов свойств может быть и два и три, например, размер, цвет, материал) в каталог, имхо, не очень правильная идея. Эдак вместо тридцати моделей диванов, в каталоге будет их несколько тысяч.
Правильнее было бы, имхо, давать возможность выбирать кортеж, влияющий на цену.

ЗЫ Знакомлюсь с системой.
ЗЗЫ Бухгалтерские программы и торгово-складские суть разные вещи. Вы же не 41 счет предлагаете выгружать в CommerceML, а прайслист. В бухгалтерии прайсов не делают, там другие задачи.

Answer 4

Цитата
Yura Ivanov пишет: В любой программе есть свои нюансы, но предлагать вность декартово произведение (видов свойств может быть и два и три, например, размер, цвет, материал) в каталог, имхо, не очень правильная идея. Эдак вместо тридцати моделей диванов, в каталоге будет их несколько тысяч. Правильнее было бы, имхо, давать возможность выбирать кортеж, влияющий на цену.

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

Если у вас у товара цена одна и не зависит от свойств товара (цвет, размер и любое другое количество свойств), то никаких проблем. В этом случае свойства каталога используются только для удобного поиска, представления товаров и правильного оформления заказа. Кстати, часто так бывает.

Но если вы решили, что у вас моделей диванов 30 штук, а цена зависит от обивки, а типов обивки 50 штук, то ничего не поделать, значит у вас уже появляется потребность где-то указать 1500 вариантов цен.

Теоретически, вы можно было бы сделать то в карточке товара. Можно сделать это предложениями цен для одной модели. Но суть вопросы не меняется. Где-то надо вводить все варианты цен.

Цитата
Yura Ivanov пишет: Бухгалтерские программы и торгово-складские суть разные вещи. Вы же не 41 счет предлагаете выгружать в CommerceML, а прайслист. В бухгалтерии прайсов не делают, там другие задачи.

Да, 41 счет нет смысла выгружать :) Но мы и не говорим об этом. Упоминание бухгалтерских программ сделано только для того, чтобы понять суть автоматизации при выгрузке цен. А автоматизация бывает нужна даже уже при 1500 вариантов цен. Я не говорю про каталоги с десятками тысяч товаров и типов цен.

Answer 5

Цена действительно ависит от свойств, но не ото всех.
От материала зависит, от цвета нет.
Например.

Код
Диван (арт10475) Кожа Черный   1000$ Диван (арт10475) Кожа Белый    1000$ Диван (арт10475) Кожа Кремовый 1000$ Диван (арт10475) Ткань Красный 800$ Диван (арт10475) Ткань Белый   800$

Покупателю в любом случае будет выведен данный список, т.к. с точки зрения программы каждая строка - это элемент инфоблока со своей ценой, не так ли? Получается, что все это нужно только для выбора цвета. Хотя достаточно было бы:

Код
Диван (арт10475) Кожа  [Цвет|v] 1000$ Диван (арт10475) Ткань [Цвет|v] 800$

т.е. комбобокс для цвета. Цена в данном случае от цвета не зависит, но для программы это не так. Иными словами структура хранения данных о цене и соответственно представление товаров в заказе не отражает реальной картины.
В метаданных свойств можно было бы предусмотреть возможность галками отметить свойства, влияющие на цену. При редактировании элемента задавать цену на список значений свойств.

ЗЫ Пробовал с наскока реализовать предложенную Вами схему с подчиненным инфоблоком (предложения), корректно отобразить необходимую информацию без правки шаблонов. Не вышло.

Answer 6

А ведь юзер прав. У меня та же проблема с магазином одежды. Цвет конкретной футболки надо дать выбрать клиентке до того как он положит его в корзину, т.к. клиенты не кладут в корзину вещь пока не выбирут ее цвет. Т.к. заказывают одежду женщины и они не могут знать что оказывается конечный выбор они должны сделать в корзине товаров. Они решают сразу по принципу: красная кофточка мне идет, а черная не идет и соответственно им нужно дать возможность выбирать размер сразу до добавления в корзину. А я так понял, что если делать привязку:

Цитата
Сергей С. пишет: Для хранения конкретных позиций, назовем их Предложениями, создадим еще один инфо-блок. В нем одно из свойств будет типа "привязка к элементам" и будет указывать на дерево каталогов.

то будет слишком много позиций у каждой кофточки, т.к. цветов у кофточки и размеров может быть в сочетании до 50 вариантов, и что представлять все эти 50 вариантов? Да никто такой интерент-магазин посещать не будет. Некжели задача для Битрикса не разрешима простым способом? Например буржуи www.otto.de сделали все четко удобно и понятно для клиента.

Answer 7

Цитата
Дмитрий пишет: Например буржуи www.otto.de сделали все четко удобно и понятно для клиента.

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

В первом случае БУС играет роль фреймворка и задача решается тривиально, но требует довольно квалифицированнгого разработчика (который заточит логику), во-вторым -- придется мириться с ограничениями.

Answer 8

Сделать комбо-списки для выбора ряда характеристик для такого серьезного продукта как битрикс думаю не составит труда - это не суперспециализированная задача. Видимо просто упустили этот момент при проектировании базы данных, а сейчас надо переделывать структуру для этого вот и всё. Мы то просто сейчас выбираем движок для своего магазина, думаю с Битриксом из-за такой мелочи не получиться.