Перейти к содержанию

Рекомендуемые сообщения

Очень хочется сделать динамическую цену на товар, пока зашел в тупик. Может у кого есть идеи?

Сейчас цена может меняться в зависимости от выбранной опции, у каждой опции своя наценка. А если наценка нужна динамическая, например:

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

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

Как-то же передается и хранится содержимое текстового поля, возможно подобным принципом передавать и цену? Как вариант передавать наценку в скрытом текстовом поле, а в корзине делать проверку, если группа товаров такая-то, то к цене плюсовать значение из текстового поля с последующим сохранением заказа в базу. Я правильно понимаю структуру, когда заказ выполнен, в базе хранится просто его цена одним значением?

Заранее спасибо за ответ.

  • +1 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Очень хочется сделать динамическую цену на товар, пока зашел в тупик. Может у кого есть идеи?

Сейчас цена может меняться в зависимости от выбранной опции, у каждой опции своя наценка. А если наценка нужна динамическая, например:

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

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

Как-то же передается и хранится содержимое текстового поля, возможно подобным принципом передавать и цену? Как вариант передавать наценку в скрытом текстовом поле, а в корзине делать проверку, если группа товаров такая-то, то к цене плюсовать значение из текстового поля с последующим сохранением заказа в базу. Я правильно понимаю структуру, когда заказ выполнен, в базе хранится просто его цена одним значением?

Заранее спасибо за ответ.

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Судя по всему задача не простая и возможно не стоит двигаться по такому пути. Пока мысли пришли такие: сделать несколько опций с фиксированным диапазоном размеров и сравнивать их с введеным, если размер от....до... тогда опция №1, если от......до.....тогда опция №2 и так штук 5 опций для каждого товара, которые будут использоваться в зависимости от диапазона введенного размера. По крайней мере сделать это можно все в product.tpl не препятствуя обновлениям.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Судя по всему задача не простая и возможно не стоит двигаться по такому пути. Пока мысли пришли такие: сделать несколько опций с фиксированным диапазоном размеров и сравнивать их с введеным, если размер от....до... тогда опция №1, если от......до.....тогда опция №2 и так штук 5 опций для каждого товара, которые будут использоваться в зависимости от диапазона введенного размера. По крайней мере сделать это можно все в product.tpl не препятствуя обновлениям.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Поддерживаю тему...очень нужно...

нашел рабочий пример на ОпенКарте...не реклама http://print.kartina.ua/%D0%90%D0%B1%D1%81%D1%82%D1%80%D0%B0%D0%BA%D1%86%D0%B8%D0%B8?product_id=427

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Пока я сделал что бы размеры в полях высота и ширина менялись от ползунка и ТИПА цена генерировалась на странице, но не понимаю как засунуть эту ТИПА цену в корзину

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Поддерживаю тему...очень нужно...

нашел рабочий пример на ОпенКарте...не реклама http://print.kartina...?product_id=427

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

По Вашей ссылке два поля с размером - это обычные две опции с типом text, ползунок использую яву меняет в них значения, а также меняет значение price + скрытое поле custom_price.

Возможно происходит событие при нажатии кнопки КУПИТЬ. Оно берет значение из количества, цену и вычисляет дробное количество для получения нужной цены.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

По Вашей ссылке два поля с размером - это обычные две опции с типом text, ползунок использую яву меняет в них значения, а также меняет значение price + скрытое поле custom_price.

Возможно происходит событие при нажатии кнопки КУПИТЬ. Оно берет значение из количества, цену и вычисляет дробное количество для получения нужной цены.

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

Такой подход плох тем, что можно цену в firebug поменьше сделать (price, custom_price поменять) и положить в корзину товар задешево. Если менеджер проморгает - продадите себе в убыток. Цена должна на стороне сервера лежать.

  • +1 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Такой подход плох тем, что можно цену в firebug поменьше сделать (price, custom_price поменять) и положить в корзину товар задешево. Если менеджер проморгает - продадите себе в убыток. Цена должна на стороне сервера лежать.

Да, есть такое дело, посему в своих прошлых решениях, в скрытых полях храню только техническую информацию, поменяв которую просто не отработает добавление.

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В связи с критическим отсутствием времени на всяческие пробы, пользуясь случаем :) спрошу, авось кто возьмется написать(платно) подобное решение, пример можно посмотреть по ссылке Выше?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Похоже вариантов нет, а там где и есть, молча работают :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Эта задача довольно широка по своей сути. Нужен некий универсальный инструмент, позволяющий формировать цену товара в зависимости от N параметров разных типов.

Проблема не в том, чтобы сделать расчет этой функции цены P(x1, x2, x3, ..., xn), а в том, чтобы написать какой-то универсальный способ задания этой функции. OpenCart позволяет вводить P как функцию от будевых параметров - опций. Получаем функцию вида:

k1*O1 + k2*O2 + ... + kn*On, где k1-kn - коэффициенты (цены опций), а O1-On - это 0 или 1.

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Ну а как все же относитесь у такому варианту: у товара или опции задана единица цены, например за 1 м.кв. - 10у.е., всякими JQuery мы двигая ползунки или меняя значения формы ввода размера по формуле получаем цену, которую и отображаем покупателю, но и имеем значение, отношение, к цене твара/опции, например 1,5 т.е. цена для клиента отображается уже 15у.е. вот это отношение передаем скрытым полем опции text, которое не отображается нигде, в корзине также отображаем цену покупателю согласно формуле, а вот после чекаута, когда ордер попадает в базу, по той же формуле пишем цену в базу и наблюдаем ее уже из админки вместе с указанными размерами в отдельном поле.

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

Не, не то? :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

...

Не, не то? :)

Общий принцип такой.

Я могу написать калькулятор цен на какой-либо товар, который в зависимости от ползунков-селекторов вычисляет его цену. Причем расчет буду вести на сервере, чтобы фаербагом не нахимичили. Делов то!

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

Вот даже в вашем примере цена считается от размера, например: "цена за метр." * "кол-во метров."

А другой продает обои, он хочет: ceil("кол-во метров"/"метров в рулоне") * "цена за рулон"

А третий продает майки с трафаретной печатью: "цена изготовления трафарета" * "кол-во цветов в рисунке" + "кол-во цветов в рисунке" * "цена печати" * "кол-во маек" * "цену майки"

И каждый ведь считает по-своему. И всем ведь не угодишь.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Общий принцип такой.

Я могу написать калькулятор цен на какой-либо товар, который в зависимости от ползунков-селекторов вычисляет его цену. Причем расчет буду вести на сервере, чтобы фаербагом не нахимичили. Делов то!

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

Вот даже в вашем примере цена считается от размера, например: "цена за метр." * "кол-во метров."

А другой продает обои, он хочет: ceil("кол-во метров"/"метров в рулоне") * "цена за рулон"

А третий продает майки с трафаретной печатью: "цена изготовления трафарета" * "кол-во цветов в рисунке" + "кол-во цветов в рисунке" * "цена печати" * "кол-во маек" * "цену майки"

И каждый ведь считает по-своему. И всем ведь не угодишь.

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

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

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

P.S.

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

А продавать неважно что, хоть метры квадратные, хоть кубические. Если уж делать модуль, для общего пользования так сказать и нужна админка, можно просто хранить в ней поле формы с формулой. Вон в теме про модуль "доставка от веса, размера и прочего" народ научился писать формулу довольно быстро :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Я могу написать калькулятор цен на какой-либо товар,

Дык калькулятор это хорошо, особенно красивый :)

а что делать потом с полученной ценой от этого калькулятора? Куда ее?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Дык калькулятор это хорошо, особенно красивый :)

а что делать потом с полученной ценой от этого калькулятора? Куда ее?

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

Ну где тут проблема то? Одну строчку добавить?

Вот кусок catalog/controller/checkout.php в 1.5.4.1 со строки 221

  foreach ($this->cart->getProducts() as $product) {
   $option_data = array();

   foreach ($product['option'] as $option) {
 if ($option['type'] != 'file') {
  $value = $option['option_value'];
 } else {
  $value = $this->encryption->decrypt($option['option_value']);
 }

 $option_data[] = array(
  'product_option_id'	   => $option['product_option_id'],
  'product_option_value_id' => $option['product_option_value_id'],
  'option_id'			   => $option['option_id'],
  'option_value_id'		 => $option['option_value_id'],		  
  'name'				    => $option['name'],
  'value'				   => $value,
  'type'				    => $option['type']
 );	
   } 

 //Добавляем +++ 
 $product['price'] = ..... Тут идет любая формула, которая на основании опций и количества вычисляет цену

   $product_data[] = array(
 'product_id' => $product['product_id'],
 'name'	   => $product['name'],
 'model'	  => $product['model'],
 'option'	 => $option_data,
 'download'   => $product['download'],
 'quantity'   => $product['quantity'],
 'subtract'   => $product['subtract'],
 'price'	  => $product['price'],
 'total'	  => $product['total'],
 'tax'	    => $this->tax->getTax($product['price'], $product['tax_class_id']),
 'reward'	 => $product['reward']
   );
  }

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Ну где тут проблема то? Одну строчку добавить?

Вот кусок catalog/controller/checkout.php в 1.5.4.1 со строки 221

Спасибо за уточнения, до этого кода пока не добрался, но так и представлял себе.

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

checkout.php собирает данные форм при оформлении заказа и пихает их в базу, верно я понимаю?

Нам нужно определить, например по типу опции или наличию ID формы,

или например

если $option['type'] = "динамическая цена"

то $product['price']= $product['price'] умножаем на $option['value''].

Те же процессы отрабатываем в TPL при отображении цен в корзине. Логика событий имеет место быть?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вопрос решил таким образом. Добавил input type=hidden к отправке формы с name=custom_price

В POST запрос в обработчике корзины добавил custom_price. В cart.php в функцию add добавил    

 

$custom_price = $_POST['custom_price'];
$_SESSION['custom'] = $custom_price;

и в library/cart.php в начало idex

 

 

if (!isset($_SESSION['custom'])) {
$custom_price = 0;
} else {
$custom_price = $_SESSION['custom'];
}

потом находим массив из getProduct и добавляем к нему условие

 

 

if ($custom_price == 0) {
$this->data[$key] = array(
'key' => $key,
'product_id' => $product_query->row['product_id'],
'name' => $product_query->row['name'],
'model' => $product_query->row['model'],
'shipping' => $product_query->row['shipping'],
'image' => $product_query->row['image'],
'option' => $option_data,
'download' => $download_data,
'quantity' => $quantity,
'minimum' => $product_query->row['minimum'],
'subtract' => $product_query->row['subtract'],
'stock' => $stock,
'price' => ($price + $option_price),
'total' => ($price + $option_price) * $quantity,
'reward' => $reward * $quantity,
'points' => ($product_query->row['points'] ? ($product_query->row['points'] + $option_points) * $quantity : 0),
'tax_class_id' => $product_query->row['tax_class_id'],
'weight' => ($product_query->row['weight'] + $option_weight) * $quantity,
'weight_class_id' => $product_query->row['weight_class_id'],
'length' => $product_query->row['length'],
'width' => $product_query->row['width'],
'height' => $product_query->row['height'],
'length_class_id' => $product_query->row['length_class_id']
);
} else {
$this->data[$key] = array(
'key' => $key,
'product_id' => $product_query->row['product_id'],
'name' => $product_query->row['name'],
'model' => $product_query->row['model'],
'shipping' => $product_query->row['shipping'],
'image' => $product_query->row['image'],
'option' => $option_data,
'download' => $download_data,
'quantity' => $quantity,
'minimum' => $product_query->row['minimum'],
'subtract' => $product_query->row['subtract'],
'stock' => $stock,
'price' => $custom_price,//($price + $option_price),
'total' => $custom_price * $quantity,//($price + $option_price) * $quantity,
'reward' => $reward * $quantity,
'points' => ($product_query->row['points'] ? ($product_query->row['points'] + $option_points) * $quantity : 0),
'tax_class_id' => $product_query->row['tax_class_id'],
'weight' => ($product_query->row['weight'] + $option_weight) * $quantity,
'weight_class_id' => $product_query->row['weight_class_id'],
'length' => $product_query->row['length'],
'width' => $product_query->row['width'],
'height' => $product_query->row['height'],
'length_class_id' => $product_query->row['length_class_id']
);

 

Все работает на ура! Удачи!

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

Да и под конец при передаче json обратно нужно аннулировать сессию!!!

  • +1 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Добрый день.
 
Может кому поможет - Опции с вводом количества select, checkbox, radio (vqmod)
https://opencartforum.com/files/file/1249-optcii-s-vvodom-kolichestva-select-checkbox-radio-vqmod/

 

В корзину передается количество.

Цена формируется в корзине (system/library/cart.php).

Отсутствует уязвимость занижения цены.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Добрый день.

 

Может кому поможет - Опции с вводом количества select, checkbox, radio (vqmod)

https://opencartforum.com/files/file/1249-optcii-s-vvodom-kolichestva-select-checkbox-radio-vqmod/

 

В корзину передается количество.

Цена формируется в корзине (system/library/cart.php).

Отсутствует уязвимость занижения цены.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

В чистом виде да.

Вместо количества можно написать размер или заменить слайдером.

Чуть доработать если надо дробное число  вместо целого.

 

В опции указать цену за единицу длинны. Если укаывать за 1м например, то в обработке корзины (в модуле) добавить деление на 100.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти

  • Последние посетители   0 пользователей онлайн

    Ни одного зарегистрированного пользователя не просматривает данную страницу

×

Важная информация

На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности.