Кто нибудь использует/видел/может сделать такое чудо?

Суть проблемы (уже не раз поднималась в форуме):

Небольшая преамбула...

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

У товара есть потребительские характеристики как таковые, которые могут быть едины для нескольких физически реальных товаров (позиций номенклатуры). Назовем их свойства товаров. Например ОС, частота процессора, диагональ экрана, предустановленные приложения и т.д.

А еще есть характеристики индивидуальные, присущие только конкретной номенклатурной позиции - реально существующему товару. Например вес, габариты, артикул/part#, SKU, штрихкод, количество по складам, цена, валюта цены, единица измерения, цвет, размер и т.д. Назовем их параметры номенклатуры.

Среди параметров номенклатуры можно выделить группу значений которая будет определена только конкретным группам товара, например для одежды это будет размер, материал и цвет/расцветка. Для обуви: размер, полнота и так далее. Назовем такие параметры характеристики номенклатуры (как в 1С)

Текущая ситуация:

разработчики практически всех поголовно движков ИМ извращаются на тему вариантов товара основанных на параметрах и характеристиках номенклатуры кто во что горазд. Например в simpla и imagecms представление крайне упрощенное - можно подставить только строку обозначающую отдельную характеристику/наименование варианта (например для обуви "42р-р, нат.кожа, черный") цену и артикул, в CS-cart заморочено но вполне работает, в OpenCart заморочено еще больше...

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

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

Увы, сколько не смотрел нигде этого не увидел. Но при этом во фронтэнде серьезных магазинов все выглядит правильно. Всего два параметра: цвет(или какая нибудь особенность) и размер. Остается только догадываться какого гемороя это стоит.

Например, имеем 100 моделей одежды, каждая модель в 3-ти цветах и 5-ти размерах. Получается 1500 позиций номенклатуры В каждой карточке товара надо завести 15 вариантов, проставить артикулы, количество, прикрепить фотографии и т.д. Объем работы для одной карточки весьма большой но это ерунда по сравнению с тем что некоторые делают отдельные карточки для моделей разного цвета! А это уже не 100 карточек товара, а 500. В 5 раз больше. То есть вместо того чтобы сделать работу за понедельник, сотрудник потратит на нее всю рабочую неделю... Ну если вам больше нечем его занять или есть деньги на отдельную должность - флаг в руки...

При наличии справочника номенклатуры с заполненными полями индивидуальных свойств время на заполнение 15-ти вариантов товара в такой карточке можно сократить раз в 5 как минимум. Просто потому что все актуальные данные номеклатуры уже были записаны в учетной системе (артикул, штрих, код, кол-во в наличии по складам, цена, фото и т.д.). Карточка товара будет играть только описательную роль - продавать, а вся логистика и учет будут использовать только номенклатуру.

Может кто видел или использует подобную систему? Как вы вообще рассчитываете доставку для товара который имеет вес отличающийся у разных вариантов в 1,5-2 раза? (ну это не сама большая проблема) Откуда вы узнаете сколько какого варианта товара на каком складе осталось?

ДЛЯ РАЗРАБОТЧИКОВ

Может кто нибудь написать модуль для какого нибудь движка или доработать собственный продукт? Пусть даже платный и возможно по не скромной цене за "коробку", пофиг, по крайней мере будет куплено именно то что на 100% соответствует потребностям.

У меня есть опыт веб разработки времен php3/4, но сейчас, я очень далек как от программирования так и от индустрии в целом чтобы заняться подобным проектом. Однако общий язык найти будет проще.

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

P.S.
Больше года назад активно высказывал идею по поводу многовалютности админики для конкретных товаров (у разных поставщиков прайсы в разных валютах соответственно была необходимость для товара указывать валюту цены) при одновалютности во фронтэнде (продажа всегда в рублях). Тогда это было реализовано всего лишь в паре движков. Сейчас их уже почти с десяток. Просто потому что существует массовый запрос на такой функционал. А разработчики у которых до сих пор этого нет, либо прикалывались либо просили какие то нереальные деньги за доработку собственного же продукта =) не имея при этом даже работающей демки. Фиг знает чем думают...

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

Нет никакого секрета или патента в таком подходе, все это уже реально существует, но не применительно к движкам интернет-магазинов. Кто первый встанет того и тапки.

Самый простой способ сделать такую доработку:
1. берем движок у которого отсутствует возможность работы с вариантами или реализована очень скудно (например simpla, imagecms)
2. дублируем, карточку, справочник товаров и связанный справочник характеристик как справочник номенклатуры и справочник характеристик номенклатуры
3. дубль карточки товара - адаптируем под номенклатуру, убираем лишнее (описание и т.д.) жестко задаем поля параметров (индивидуальных свойств реального товара которые есть у КАЖДОЙ номенклатурной позиции)
4. дубль справочника соответственно тоже адаптируем под хранение записей номенклатуры
5. дубль справочника характеристик адаптируем под характеристики номенклатуры которые есть у НЕКОТОРЫХ позиций номенклатуры.
6. модернизируем исходную карточку товара для подстановки записей номенклатуры в качестве вариантов убирая их нее все данные которые специфичны для конкретного реального товара (позиции номенклатуры) то есть вес, цену, фото, артикул, щтрих код, остатки и т.д.
7. можно подумать над более интелектуальной обработкой при подборе номенклатуры в карточку. Например, при выборе одного-двух из вариантов товара - предлагать пакетно добавить схожие (фильтр по наименованию вполне будет работать).

Мне думается всё это на 80% уже есть в фасетной навигации. Которую скорее всего и юзают "серьёзные магазины".

Всё это уже реально существует и работает и применительно к ИМ. Коробочные решения есть, но их ещё нужно внедрить и объединить со всем остальным. Бизнес процессы, системы бухгалтерского учета, CRM, ERP всегда индивидуальны. Коробка 1С стоит немного. Поинтересуйтесь у одинэсников во что обойдется внедрение в вашей компании? В 2009 комплексное решение того, о чем Вы говорите, в небольшой компании стоило порядка $200 000.

Посмотрите эту программу: http://elbuz.com/e-trade-content-creato ... eator.html
Её можно использовать не только как парсер, но и как базу данных с фасетной навигацией. Тогда вы можете создать сами нужные вам характеристики и далее заполнять их в полуавтоматическом режиме и выгружать на сайт.

Парсер > Учетная система > Сайт
Решений масса, все зависит от потребности

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

1С ненавижу за все три года работы в ней. Не потрачу больше ни копейки на это бесполезное и монструозное г..но. ИМ можно работать в ней только через одно место. Ничего полезного кроме отчетности и куча гемора с обновлением.

Что получается то? ИМ работает в основном с физиками, но технология обработки заказа схожа с той которая используется например в любой оптовой конторе которая с ЮЛ работает. На деле происходит такое:

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

В итоге, происходят следующие ситуации...

Клиент менеджеру - где мой заказ?!
Менеджер ИМ - срок поступления оплаты от 5 до 7 рабочих дней, сейчас уточню в бухгалтерии прошла ли оплата и сообщу вам как только узнаю.
Менеджер ИМ бухгалтерии - посмотрите пожалуйста, прошла ли оплата от клиента?
бухгалтерия менеджеру - у наст тут сервер завис, как починят, перезвоню скажу
Клиент - прошло уже два дня емае сказочники, где мой заказ? Я его уже неделю назад оплатил!
диалог менеджера с бухгалтерией ...
Менеджер клиенту - да, оплату получили, ваш заказ будет передан в службу доставки завтра.
...
можно дописать еще на три экрана по диалогах менеджера со всеми службами и сотрудниками через которые проходит процесс оформления заказа и клиентом...

Причем чем крупнее интернет-магазин тем больше проявляется такая ситуация. Менеджер/девочка в колл-центре отвечают перед клиентом за всех и сделать толком ничего не могут. Остальные понятия не имеют о клиенте и его сложностях. Мало того, менеджер и информацией то толком не владеет. Прошла оплата или нет? Скомплектован заказ или нет? Отправлен или нет? И так далее.
Невероятно большое количество лишних телодвижений.

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

Сейчас тренд идет к тому что в учетных системах появляются средства наполнения контентом ИМ, а в ИМ какие никакие возможности учета товаров, выручки и т.д. Это тупик который выгоден только тем кто поставляет костыли за $ 200 000 чтобы это все в связке нормально работало..

Бухгалтерия пусть остается бухгалтерией. ИМ - магазином. Дело бухгалтерии вести номенклатуру, дело ИМ продавать её. Не надо сваливать все в одну кучу и ждать приемлемого результата.

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

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

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

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

Вот и я о том же. Кто хочет зарабатывает.
остальные чешут репу.

Ваша система работает только для мэйнстрим-товаров.

Скормите ей название Nic-Impex makalu evolution light расскажите что получилось.

Во-первых это не моя система, мы просто её используем. Под наши задачи она подходит. Во-вторых наименование товара вообще может быть любым.

Ну естественно любым. А в чем смысл АСУ? Автоматизировать! Товар, название которое я предложил нет не только я яндекс маркете, но и в 99,999% российских магазинов. Кое где продается за рубежом, в очень немногих магазинах...

То есть, описание копировать не откуда, а если есть то на вражеском языке, вбиваем все ручками в систему которая по идее должна избавить от ручного труда На самом деле она его добавляет.

Бессонные ночи в поисках не прошли зря!

Хорошо имею привычку раз в полгода-год просматривать все известные движки которые имеют демо. В Spree, про которую незаслуженно забыл, примерно то что описано в первом посте - реализовано в текущей версии. Причем очень грамотно и юзабельно. Если у товара есть варианты, поля свойств номенклатуры (SKU, габариты, вес, цена, кол-во на складе) можно заполнить только для вариантов. Картинки добавляются отдельно для каждого варианта + общее изображение. Описание общее. Матрица комбинаций генерируется автоматически Больше нифига и не надо! Супер. Многоволютности админки при дефолтной валюте фронтэнда нет, но это скорее задача для учетной системы.

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

Ну и... Не поверите! Есть программа учета в которой можно хранить размеры и вес номеклатурной позиции + объем автоматически считает. Модуль доставки будет очень рад этому.

Я счастлив. Всем спасибо.

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

При стоимости внедрения Spree примерно равной стоимости битрикс+малый бизнес или даже чуть выше, скорее выберу Spree. По одной простой причине - операционные расходы (стоимость владения) при дальнейшей эксплуатации меньше как ни крути. На УСН 6% это актуально. Про гибкость даже и говорить нечего.

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

Взять хотя бы переход с конфигурации 1.6 на 2.0 - это кошмар. Сделать его средствами коробочной базовой версии невозможно! Все потому что система работает строго в однопользовательском режиме доступа к базе, а при обновлении требуется доступ более чем одного процесса... Прям так и пишет что мол у вас базовая версия идите лесом, возможен доступ только одного пользователя. ВСЯ 1С в одном сообщени об ошибке! Пришлось платить бухгалтеру за подготовку и сдучу декларации и потом отдавать базу для конвертации чтобы хотя бы новую форму декларации получить для следующего года. Это при живой учетной системе за которую уже заплачено!!!

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

P.S.
Цены у вас конечно извините... более 80к за допиливание битрикса котрый сейчас можно купить в готовом виде не дороже 35к (около 50к без скидки) это перебор

Видимо я в другом сегменте, где распоряжаются собственными средствами, а не бюджетом фирмы

Сильное подозрение, что вам нужна Magento с правильной настройкой экспорта/импорта. Это единственный движок, которые не заморачивается на опции или атрибуты как большинство движков, включая Opencart и Prestashop соответственно. Там иная идеология работы с данными о товарах, благодаря чему есть возможность делать легкую заливку данных для описанного вами случая.