Сообщений в теме: 6

[roman_noir]

Еще такой вопрос - несколько торговых точек. Например, на сайте key.ru, ret.ru и так далее, реализована функция наличия товара в конкретном магазине, городе. Есть ли возможность, сделать так в шопкмс? Т.е. чтобы при занесении товара можно было указать и привязть товар к торговой точке, а потом в карточке товара увидеть типа
Метла. Наличие в магазинах: Маг-н "Лес" (есть), Маг-н "Поле" - (нет)
И чтобы при покупке товар списывался с конкретной торговой точки.
В принципе, проблему можно решить и иначе, как у меня на www.terbuny.info но это не эффективно. Потому как точек может быть не 2, а 10, и тогда будет не сайт, а сплошное меню.

[R.Sergey]

Если все точки в одном магазине, то опять же на помощь приходят Дополнительные характеристики. Добавьте доп. характеристику
Наличие:
с вариантами - Маг-н "Лес" - Маг-н "Поле" и т.д.
До добавлять/удалять наличие придется разумеется вручную.

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

[roman_noir]

нет, на одном магазине. Более простой вариант.
Про харакетристику, опять же, понятно. Дополнительно поле, и в путь.
А списывание товара со склада? Сейчас у меня две точки, два склада типа. Т.е покупаем в катеории ЛЕС/метлы товар списывается со склада ЛЕС. При варианте дополнительно поле, будут списыватся только МЕТЛЫ, вне зависимости от ЛЕС или ПОЛЕ?

[R.Sergey]

нет, на одном магазине. Более простой вариант. Про харакетристику, опять же, понятно. Дополнительно поле, и в путь. А списывание товара со склада? Сейчас у меня две точки, два склада типа. Т.е покупаем в катеории ЛЕС/метлы товар списывается со склада ЛЕС. При варианте дополнительно поле, будут списыватся только МЕТЛЫ, вне зависимости от ЛЕС или ПОЛЕ?

При использовании доп. характеристик к складу это вообще не будет иметь отношения. Наличие будет как бы обще, но ХАРАКТЕРИСТИКА покажет на каком именно складе лежит товар.
Если вы продали со склада ЛЕС, то заходите в редактирование товара и ручками убираете характеристику ЛЕС. или переключаете ее на НЕТ. А Поле остается
тогда в карточке будет выглядеть так

Наличие: есть
Склад ЛЕС: нет
Склад ПОЛЕ: есть

можно убрать строку наличие и назвать так
Наличие ЛЕС: нет
Наличие ПОЛЕ: есть

при этом кол-во разумеется тоже можно указать но при продаже править придется каждый раз руками.

Второй вариант
Наличие - выпадающий список складов в которых есть: ЛЕС, ПОЛЕ

Включайте фантазию, вариантов много и можно найти альтернативу не платив ни копейки за разработку модуля.

[roman_noir]

Это вариант не подойдет. Магазин можно использовать и как складскую программу. У меня сотрудник оформляет продажу таким образом. Если дать ему права редактировать базу через админку, это приведет к катастрофе при ближайшей ревизии.
Так что именно привязка конкретной точки к конкретному складу, как сделано сейчас. Вопрос не в деньгах даже, этот вопрос обсуждаем вполне.
Кстати, есть идея, а что если совместно выработать "пожелания" к движку, сделать (администраторам данного сайт к примеру) и продвать как дополнение? Вполне рентабельно должно получиться.

[badisoft]

Кстати, есть идея, а что если совместно выработать "пожелания" к движку, сделать (администраторам данного сайт к примеру) и продвать как дополнение? Вполне рентабельно должно получиться.

Рентабельно - это когда штатно зарабатывая десять-условных-денег-в-день тратишь неделю своего свободного времени "по чуть-чуть" (на работе, дома) на "нечто" и получаешь в выхлопе прибыток хотя бы единицу-денег-в-день, десять процентов. Иначе смысл во всей этой возне? Ежедневные сто рублей в довесок к ежедневным десяти тысячам? А оно надо? Они же не просто сто рублей, а за них еще и ответственность нести надо, на вопли клиента реагировать, ошибки исправлять, штанишки поддерживать. Причем на одно исправление ошибки или действительную проблему будет девяносто девять поддерживаний штанишек, когда клиенту просто лень прочитать десять строчек и он считает "я заплатил? да! Хачю сервиса и кнопку "сделать все зашибись"" .

ИМХО, что-то комплексное, называемое "Проект" или (нынче это стало более модным словом) "Решение" вполне можно делать и за деньги. Нормальный бюджет, нормальные сроки, интересная задача не на вечер и не на неделю. А вот клепать модули и прочие дополнения к инструменту (подчеркиваю, к ИНСТРУМЕНТУ! клиенту похрену, чем и как забит гвоздь) - ну его нах за деньги, забесплатно дешевле выйдет.

Но это так, мое видение ситуации с написанием модулей и довесков к инструменту для создания сайтов. По части же того, что Вы хотите мне кажется, что правильнее (и в конечном результате проще) таки менять структуру таблиц. Поле "на складе столько-то товара" (не помню его название) из таблицы prоducts заменить отдельной НОВОЙ таблицей из трех полей {'productID","skladID","in_stock"}. Т.е. сначала создать такую таблицу, затем постепенно (поиском) найти все места, где используется запрос из products с количеством товара и добавить туда "LEFT JOIN наша_новая_таблица USED (ProductID)". Это сильно упрощено по синтаксису, но главная задача в том, чтобы вынести количество товара в отдельную таблицу (пусть изначально с одной записью на товар, т.е. количество-товара-в-одном-магазине, как штатно) и подключить ее так, чтобы все работало как и раньше, внешне неотличимо. Ну а дальше, как мне кажется, будет уже проще, т.к. надо будет уже не ПРАВИТЬ, а ДОПИСЫВАТЬ НОВОЕ.

[yura]

можно убрать строку наличие и назвать так
Наличие ЛЕС: нет
Наличие ПОЛЕ: есть

при этом кол-во разумеется тоже можно указать но при продаже править придется каждый раз руками.

Есть модуль учета по доп. характеристикам от namer. С ним не надо будет руками кол-во править