Что за фуфло в тренде развития движков ?

ОНи все пока работать не начинаешь "производят впечатление".

Всех не попробовать. В этот раз допилим уже престу,там хоть конец какой-то виден.

В следующий раз буду смотреть что-нибудь "на рельсах".

Вопрос не в объединении заказов. Вопрос в том, что не слишком комфортно пользоваться

софтом, в котором нет ДАЖЕ объединения заказов. Не для того, чтобы им пользовались

он сделан, судя по всему. Там еще дофига всего нету, просто это, возможно, более

частные "хотелки", и всплывет это в следующие полгода.

А что, на рельсах лучше ездить будет?-)) Там такие же грабли, только кодеров меньше и дороже (правда, и общий уровень выше)

К слову, чисто логически, как объединяете/разьединяете заказы? К примеру, есть заказ 2 и заказ 5. Надо их объединить. Что делаете: удаляете заказ 2, все товары переносите в заказ 5 или добавляете заказ 6, куда переноситься вся информация с заказа 2 и 5.

Как разьединяете заказ?

подготовка данных каждый раз при загрузке этого прайса или разовая, а потом будет намного быстрее?

А при чем тут осмысленные слова и номенклатура товарная? в осмысленном языке нет аббервиатур, например, товарная позиция cpc2 - это разве относится к осмысленным словам? У нас в базе сейчас более 500 000 товарных позиций, более 500 поставщиков в системе, у одного поставщика в среднем около 3 000 позиций, 500*3000= 1 500 000 вариантов написаний товаров, это только сейчас по нашей текущей базе. До конца года мы планируем иметь в базе 1 500 000 товарных позиций и более 2 000 поставщиков. Так что словари - это гиблое дело, особенно, если надо делать словари синонимов, ведь важно не только текущую номенклатуру привязать автоматически, но и предсказать возможные варианты ее написания другими поставщиками.

каждый раз

в словари не добавляется номенклатура!

словари это цвета(синий, голубой, персиковый, серебристый..)/типы(велосипед, самокат, скейт.../возраста(подростковый, детский, взрослый...)

не стоит создавать словарь названий товара - это действительно гиблое дело :)

варианты написания одного и того же товара разными поставщиками вычисляются "на лету" и предлагаются к утверждению

Да как угодно.

Разделять легко созданием нового, соединять удалением одного из объединяемых.

В любом форуме посмотрите как сделана функция объединения-разъединения тем.

Нет тут больших проблем.

Будет ли лучше на рельсах неизвестно. Надо пробовать.

Диафан хороший движок

Во оно как...вся ветка под вас писалась.

Чем же хорош ваш диафан, кроме того, что он диафан?

Ну, если нет интеграции с учетной системой бух-склад, тогда да.

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

Из своего примера...взялся за развитие одного ИМ. На сайт выгружаются товары из 1с. Реализовано просто через одно место. Все цвета и размера товара заданы как свойства товаров. Таким образом, карточка товара "обувь" имеет свойства -"24 и 25 размер, цвета сиреневый и голубой". Причем, эти свойства можно переключать в карточке на сайте. НО...если в 1с, есть только 25й размер - сиреневый, то сайт то один фиг показывает всю карточку товара со всеми свойствами. В итоге куча отказов. Но это мало относится к CMS - это скорее к кривой реализации.

Теперь далее - решение.

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

Имеем: карточка товара -"обувь" и 4 торговых предложения в ней "

1. 24й сиреневый

2. 24й голубой

3. 25й сиреневый

4. 25й голубой

Делать это все отдельными карточками - естественно бред. Поэтому и сделали так - 1 карточка и 4 товарных предложения.

Далее - хуже.

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

Вот тут то и начались танцы с бубнами =). Имеем в примере - 1 карточка товара - 4 товарных предложения и 17 возможных мест наличия для каждого товарного предложения с ценами.

Покажите мне CMS - которая это сделает...

fisher_ak, эт вы батенька извращаетесь. К примеру, если взять друпал 7 коммерц (я думаю, в других движках аналогично будет), то там есть карточка товара (физическая на складе, к примеру, обувь сиреневая 24 размер бренднейм, обувь сиреневая 26 размер бренднейм2 и так далее) и дисплей товара (отображение товара на сайте - покажет вашу карточку товара + доступные атрибуты товара. Если на складе нет сиреневой обуви, в атрибутах не будет отображаться цвет сиреневый):