Программирование как "Антибиотик" проекта: "Одно лечим - другое калечим"

вот мы и добрались до истоков - не фиг покупать запор для участия в Ф1!

и самое главное не звать на должность пилота и обслуживающего персонала сына/дочь школьника с одноклассниками

Или ИМ из коробки, или инструмент продаж, но тогда и программист (ы) в штате должен быть, и складские остатки свои и тд. С этим не кто не спорит.

Тема пошла с подачи Шлакбаума, и я не готов поверить, что он не знает этого. И те кто думает, что купив коробку за 100000 они купили интернет магазин, это наверно для другой темы, в курилке например, но и там не всем можно)

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

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

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

Извините, что я тут со своим тормозком, но даже WC из коробки это позволяет.

Глобальное включение/настройки: https://i.imgur.com/PDJ4noS.jpg

Настройки товара: https://i.imgur.com/S7sucQP.jpg

Настройки вариаций: https://i.imgur.com/BiLIGIe.jpg (тут есть логическая ошибка - второй атрибут не должен быть "любой",но перескринивать заломало :) )

Поиск тоже делается без костылей.

Вот сделать интеграцию со сторонним складским ПО/СРМ - это конечно уже отдельная история (и причина тому - отсутствие унификации). Но назвать это костылями.. зависит от конкретной реализации. Так-то движки позволяют не костылить, а писать нормально.

Автозапчасти, конечно, история довольно сложна и мутная. Но делать с нуля 100500 одинаковых (по сути) ИМ - явно чем-то не тем отдаёт :)

SeVlad, проблема в том что о всех системах учёта это разный товар, а в ИМ это один товар с разными характеристиками (цвет/размер/цена/скидка/участие акции....), костыли как раз и возникают сначала при объединении из системы учёта на карточку товара, а потом обратно в систему учёта

Во первых если нужно разные - никто не мешает сделать и в ИМ разные.

Во вторых, даже если в ИМ и не разные (вариации одного), то всё рано можно получить данные по каждой вариации (см на последнем скрине ИДшники вариаций - #40, #41 ) и соответственно работать персонально.

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

В том же WC (и связках с ним) всё наверняка решается - есть довольно мощное АПИ. Насколько я знаю АПИ есть и Опенкарте и Престе. И уж точно в Мажнете.

Так что вопрос "костыльности" - это не столько технический вопрос, сколько вопрос бюджета/времени и, как следствие, квалификации исполнителя.

так в системе учёта необходимо, а в интерфейсе ИМ с точностью наоборот

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

Совершено не обязательно. Всё зависит от задач ИМа и удобств менеджерам.

Ничто хе не мешает сделать отдельными товарами.

То ты уже вообще о чём-то не о том :)

Поиск по цене и др хар-кам - "элементарные" вещи.

"элементарные" - в см легко реализуемые. Но да, в зависимости от совокупности условий поиска и структуры базы и самих данных могут "просто" вызывать сильную нагрузку. Вот тут уже приходится.. ну не то, чтобы костылить, но отходить от заложенных стандартов и может пересматривать структуру базы (опять же в WC нельзя казать, что это сверх костыль - такие возможности заложены в АПИ.)

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

это вообще не та задача ради которой стоит плодить дубли

это как раз о том что писал тс, сделав одно, ломаем другое

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

для каждой хотелки заказчика