Вариации по API

Разрабатываю интеграцию 1С и Cs-Cart по API Cs-Cart. В описании API ни слова не сказано как добавлять вариации к товару. Т.е. есть опции со списком возможных вариаций для этой опции. В товаре (насколько я понимаю) вариации нужно создавать отдельно, на основании вариаций опций.
Как это все делать по API? И соответственно устанавливать цену, остаток?
Вот еще риторическое обращение к разработчикам: Не будьте кодерами, типа “я художник, я так вижу”. Вы делаете продукт удобный для себя. Но работают в нем ваши клиенты. Включайте голову когда разрабатываете (дорабатываете) какой-либо функционал (особенно это касается вариаций). Или берите голову тестировщиков.

Статья есть, но пока только в англоязычной документации по API: https://docs.cs-cart.com/4.9.x/developer_guide/api/entities/product_variations.html. Так получилось, что английская документация именно по API сейчас полнее и лучше. Зато в русской больше статей для разработчиков в других разделах.

Мы бы перевели статью про Product Variations на русский, но скоро её нужно будет переделывать. На весну этого года мы планируем версию 4.10.1, где по запросам пользователей серьёзно переделаем вариации. Они будут работать не на опциях (options), а на характериcтиках (features). Пропадёт понятие “родительского товара”, а обычные товары будут собираться в группу вариаций с помощью нового поля variation_group_code (точное название будет в документации).

Благодаря этому:

  • станет проще создавать новые вариации через импорт;
  • появится возможность показывать вариации в каталоге как отдельные товары (если необходимо);
  • появятся рабочие фильтры по вариациям.

А на что будет ссылаться поле “variation_group_code”?

Эту функциональность ещё пока не ввели. Это будет идентификатор группы вариаций. Те то что объединяет несколько вариаций и позволяет между ними переключаться.

Можете посмотреть работу новых вариаций на http://dev.demo.cs-cart.com/ (единственное, интерфейс там пока на английском, а функциональность ещё в разработке):

  1. Удалите модуль “Вариации товаров [Beta]”.
  2. Установите модуль “Product variations 2.0 [Beta]”
  3. Создайте в админке характеристики с нужным типом (это новое поле, оно на dev.demo есть).
  4. Создайте вариации товара на основе этих характеристик.

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

Получается, что вариации, как они были запланированы изначально (разновидность товара) Вы убираете. Будет некий один товар, и к нему будут цепляться несколько других товаров (через новое поле, т.е. другие товары будут хранить ссылку на, так называемый, “основной товар”, но физически в иерархии он будет на одном уровне). В этом случае тогда вообще ничего не меняется. И это позволить работать сортировке и другим стандартным функциям (на что даже программист не должен обращать внимание)?
На мой скромный взгляд, Вы сами себя загнали в угол. Т.к. такой функционал не должен каким-либо образом зависит от архитектуры БД. Почему просто не взять на вооружение методологию введения номенклатуры как это сделано в типовых конфигурациях 1С (УТ, ERP и др.).
А сейчас, после обновления, у тех клиентов, которые введут учет в других системах, придется переписывать обмен (если он у них свой). Да, и еще вот вопрос: ПОЧЕМУ не работает модуль “CommerceML” с 1С. А точнее не обрабатывает ни каким образом ВАШИ вариации?

Не буду спорить о технических особенностях реализации, т.к. сам я не программист, и объяснял все эти изменения с точки зрения обычного пользователя. В тему зашёл поделиться ссылкой на документацию и предупредить, что вариации мы скоро переработаем, чтобы они были лучше – решали больше задач пользователей.

Не припомню, чтобы на это недавно жаловались. С текущими вариациями модуль работает. В https://www.cs-cart.ru/docs/4.9.x/user_guide/addons/commerceml/1c/instruction/ut11/#id12 указано, что нужно выбрать схему 2.05 и Способ загрузки опций: Вариации (рекомендуемое значение).

Если возникают какие-то проблемы, рекомендую обратиться в наш Help Desk – там техподдержка может изучить каждую проблему индивидуально и ответить на вопросы.

Спасибо за ответы. Я не Вам в упрек. Но стандартный обмен через CommerceML не совсем подходит. Плюс я пробовал настраивать вариации (в модуле), схема 2.05. Как вводиться: “Включаешь - не работает”.
Просьба: Передайте архитектору/разработчикам Cs Cart, обратить внимание на введение каталога, как это сделано в других системах.
Спасибо еще раз.

Добрый день. Раскройте подробней мысль, как Вы видите реализацию вариаций?

Хороший пример реализован в типовых конфигурациях 1С (УТ и др.). Возьмем простой вариант (индивидуальные вариации): Есть каталог товаров (номенклатур). Для примера пусть будет обувь. Товар (или номенклатура) назовем “Женская красивая Gucci”. Бренд Gucci. Для вариаций дополнительно определяем доп. реквизиты (Характеристики по вашему). Цвет, размер и т.д. В качестве торгового предложения в этом случае выступает всегда пара номенклатура+вариация. Здесь вам и отборы и сортировки. Такая организация каталога на мой взгляд максимально прозрачная, как для разработчиков, так и клиентов (владельцы сайта).
Насколько я знаю, отчасти такой механизм есть. Но он не используется (во всяком случае не рекомендуется к использованию у Вас). Камень преткновением здесь опции. Прослойка между товаром и его вариацией. Практическое использование опций мне абсолютно не понятно. Тот вариант, который я описал выше, можно применить для любого вида деятельности. Главное к организации каталога подойти с умом. А то никакие технологии не помогут.
Сами вариации, я бы хранил в отдельной таблице. У Вас получается God Object.

2 лайка

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

Как и говорил: Вы сами себя загнали в угол.
Будем надеется.

Сталкивался ли кто-нибудь с выгрузкой вариаций товара. Отправляю POST на ресурс /product_variations/. Вот текст JSON:
{
“product”: “BYREDO 1996 INEZ & VINOODH, Объемы: Парфюмерная вода 50 мл”,
“parent_product_id”: 1292,
“price”: 8500,
“base_price”: 8500,
“variation_options”: {
“458”: “831”
}
}

Говорит, что массив variation_options невалиденый. Хотя в документации именно так и указано. Т.е в ней это не массив. ОК, пытаюсь передать массив:
{
“product”: “BYREDO 1996 INEZ & VINOODH, Объемы: Парфюмерная вода 50 мл”,
“parent_product_id”: 1292,
“price”: 8500,
“base_price”: 8500,
“variation_options”: [
{
“458”: “831”
}
]
}

Присылает страшный ответ (страницу), где в начале указано “Array to string conversion”.
Что я делаю не так?
Не совсем понятно, что нужно передать в “variation_options”, массив или структуру с ключами ID опции и значениями ID варианта опции. В любом случае все варианты я перепробовал. Даже тупо строку оправлял, в таком же формате, как получается при GET.