Перейти до вмісту
Пошук в
  • Детальніше...
Шукати результати, які ...
Шукати результати в ...

osstore 1.0.1 если удалить заказ товар не плюсуется на склад


erzya

Recommended Posts

Версия osstore 1.0.1 релиз

Стоят все необходимые настройки, чтобы товар показывался на складе и вычитался при оформлении заказа.

Например было 10 штук шляп, я 2 добавляю в корзину и оформляю заказ - становится 8 штук шляп.

А вот когда я удаляю заказ, то 2 шляпы обратно на склад не возвращаются.

Хотя даже в версии 1.4.х возвращались.

Замечается это начиная с версии osstore 0.2.х

Надіслати
Поділитися на інших сайтах


А должны? Случаи разные бывают. Поступил заказ, шляпы отправлены, про деньги магазин в общем случае не в курсе. Через некотрое время удаляете заказ. То ли потому, что обработан, то ли потому, что денег не дождались. Возврата товара нет. Я бы удивился и негодовал, если бы магазин вдруг 2 шляпы добавил в этом случае.

Надіслати
Поділитися на інших сайтах


А должны? Случаи разные бывают. Поступил заказ, шляпы отправлены, про деньги магазин в общем случае не в курсе. Через некотрое время удаляете заказ. То ли потому, что обработан, то ли потому, что денег не дождались. Возврата товара нет. Я бы удивился и негодовал, если бы магазин вдруг 2 шляпы добавил в этом случае.

Я думаю, что должны возвращаться и в старых версиях это было реализовано.

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

Тем более, как Вы потом будете статискику смотреть по продажам. За месяц, за год и.т.д., если все поудаляете =)

Надіслати
Поділитися на інших сайтах


Логично было бы, чтобы возвращались. Тоже заметил такое неудобное решение. В принципе ручками поправил и все.

Я ручками не умею править на пхп =((((

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

Надіслати
Поділитися на інших сайтах


У меня, кстати, магазин год работает на OpenCart и по статистике около 30% заказов не выкупаются.

Срок выкупа 10 дней. Если заказ не выкупили - я его удаляю и товар возвращается на склад (у меня версия 1.4.7 со своими доработками).

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

Ил как вариант - плодить невыкупленные заказы в БД.

Ни тот ни другой вариан не кажутся мне подходящими. Не удобно вообщем...

Это единственное, из-за чего я не стала ставить на новый магазин osstore 1.0.1

Там есть еще кое-какие неприятности, но это - уж очень существенное упущение (на мой взгляд).

Надіслати
Поділитися на інших сайтах


Я думаю, что должны возвращаться и в старых версиях это было реализовано.

А в старых версиях были реализованы возвраты товара? Я просто не в курсе. Мне кажется, из-за них логика могла поменяться.

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

Это совет теоретика или практика? Много у Вас продаж и заказов?

Тем более, как Вы потом будете статискику смотреть по продажам. За месяц, за год и.т.д., если все поудаляете =)

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


Это единственное, из-за чего я не стала ставить на новый магазин osstore 1.0.1

Да ну, этот момент очень легко исправить и может кто-то посвободней подскажет Вам здесь решение.
Надіслати
Поділитися на інших сайтах


А должны? Случаи разные бывают. Поступил заказ, шляпы отправлены, про деньги магазин в общем случае не в курсе. Через некотрое время удаляете заказ. То ли потому, что обработан, то ли потому, что денег не дождались. Возврата товара нет. Я бы удивился и негодовал, если бы магазин вдруг 2 шляпы добавил в этом случае.

Ну тогда уж в админке должно настраиваться плюсовать товар или нет.

Чаще все-таки товар плюсуется, но лучше конечно сделать эту возможность настраиваемой.

Надіслати
Поділитися на інших сайтах


Ну тогда уж в админке должно настраиваться плюсовать товар или нет.

Чаще все-таки товар плюсуется, но лучше конечно сделать эту возможность настраиваемой.

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

У меня стоит версия 1.4.7 и при всех правильных настройках товар возвращается.

А в версии 1.5.1 open или 1.0.1 os не возвращается.

Настройки одинаковые, в одном работает в другом нет - значит косяк =(

Надіслати
Поділитися на інших сайтах


А в старых версиях были реализованы возвраты товара? Я просто не в курсе. Мне кажется, из-за них логика могла поменяться.

Это совет теоретика или практика? Много у Вас продаж и заказов?

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

Вы мне отвечаете, а что я пишу не читаете, похоже...

У меня год работающий реальный магазин с продажами. В день не менее 10 заказов. 1-с и прочей фигней я не пользуюсь т.к. у меня 6% усн от доходов и кроме статистики сайта мне нечего для отчетности не нужно. Таких как я - почти 100% владельцев интернет-магазинов с оборотом до 500.000 рублей в месяц. Поэтому мои советы - советы практика.

Если у Вас оборот большой, то Вам надо и 1-с привязывать и кассу штрих-М на 1-с завязаывать и прочее, прочее Вообщем автоматизация нужна. Тогда можно использовать битрикс или другое платное многофункциональное двигло. А opencart - это для малого-малого бизнеса и ему нужны возвраты товара на склад.

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

Выглядит это так:

- О, крутую фичу добавили, теперь можно нажать около товара кнопку и порекомендовать товар через Вконтакт!

- О, да, круто!

- Админы, а сделайте еще чтобы с Твиитер можно было заслать!

- Не вопрос!

И.т.д.

А реальные функции полезные где? То что было и то перестало работать =)))

После установки версии 1.4.7 мне пришлось такие доработки внедрить:

- нормальные настройки доставки: доставка почтой, доставка курьером, доставка EMS и.т.д. Это всем надо, но ни в одном релизе нет. Зато есть куча неработающих модулей типа Робокассы, киви, какихто забугорных хреновин и.т.п.

1. Я не говорю, что Робокасса не нужна, но она с багами (поиск форума выдаст обсуждение, если что).

2. Я не прошу что-то дорабатывать как мне надо в этом движке (самостоятельно сделаю), просто не надо убивать те функции (полезные функции), которые уже были сделаны ранее и прекрасно работали.

  • +1 1
Надіслати
Поділитися на інших сайтах


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

А вот то, что как при удалении, так и при выставлении возвратных и отмененных статусов товар не зачисляется обратно — факт.

Надо будет допилить, да.

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

  • +1 1
Надіслати
Поділитися на інших сайтах


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

А вот то, что как при удалении, так и при выставлении возвратных и отмененных статусов товар не зачисляется обратно — факт.

Надо будет допилить, да.

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

Плюсую! Хоть кто-то этот движок себе ставил и кнопки нажимал.
Надіслати
Поділитися на інших сайтах


Плюсую! Хоть кто-то этот движок себе ставил и кнопки нажимал.

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

Вот, сейчас, например, я пилю драйвер для PostgreSQL, чтобы магазин можно было ставить на высоконагруженные сервера :). Чуть позже попробую запилить «постоянное соединение» с базой. А потом, вот, возьмусь за Ваш репорт :)

Надіслати
Поділитися на інших сайтах


Эта тема реально достала перед глазами маячить...

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

Короче ищем в файле admin/model/sale/order.php строки

		if ($this->config->get('config_stock_subtract')) {
			$order_query = $this->db->query("SELECT * FROM `" . DB_PREFIX . "order` WHERE order_status_id > '0' AND order_id = '" . (int)$order_id . "'");

			if ($order_query->num_rows) {
				$product_query = $this->db->query("SELECT * FROM " . DB_PREFIX . "order_product WHERE order_id = '" . (int)$order_id . "'");

				foreach($product_query->rows as $product) {
					$this->db->query("UPDATE `" . DB_PREFIX . "product` SET quantity = (quantity + " . (int)$product['quantity'] . ") WHERE product_id = '" . (int)$product['product_id'] . "'");

					$option_query = $this->db->query("SELECT * FROM " . DB_PREFIX . "order_option WHERE order_id = '" . (int)$order_id . "' AND order_product_id = '" . (int)$product['order_product_id'] . "'");

					foreach ($option_query->rows as $option) {
						$this->db->query("UPDATE " . DB_PREFIX . "product_option_value SET quantity = (quantity + " . (int)$product['quantity'] . ") WHERE product_option_value_id = '" . (int)$option['product_option_value_id'] . "' AND subtract = '1'");
					}
				}
			}
		}
и меняем так

		$order_query = $this->db->query("SELECT * FROM `" . DB_PREFIX . "order` WHERE order_id = '" . (int)$order_id . "'");

		if ($order_query->num_rows) {
			$product_query = $this->db->query("SELECT op.*, p.subtract FROM " . DB_PREFIX . "order_product op JOIN `" . DB_PREFIX . "product` p ON (p.product_id = op.product_id) WHERE order_id = '" . (int)$order_id . "'");

			foreach($product_query->rows as $product) {
				if ($product['subtract']) {
					$this->db->query("UPDATE `" . DB_PREFIX . "product` SET quantity = (quantity + " . (int)$product['quantity'] . ") WHERE product_id = '" . (int)$product['product_id'] . "'");

					$option_query = $this->db->query("SELECT * FROM " . DB_PREFIX . "order_option WHERE order_id = '" . (int)$order_id . "' AND order_product_id = '" . (int)$product['order_product_id'] . "'");

					foreach ($option_query->rows as $option) {
						$this->db->query("UPDATE " . DB_PREFIX . "product_option_value SET quantity = (quantity + " . (int)$product['quantity'] . ") WHERE product_option_value_id = '" . (int)$option['product_option_value_id'] . "' AND subtract = '1'");
					}
				}
			}
		}
Надіслати
Поділитися на інших сайтах

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

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

Тем не менее, товар не возвращается при удалении заказа. Попробую завтра покопать, если будет время. Ну или ты можешь еще идеи озвучить :)

Надіслати
Поділитися на інших сайтах


в коде ошибка - не хватает первой строки этого отрывка.

Все строки на месте, никакой ошибки нет.

Если ты добавил в начало

if ($this->config->get('config_stock_subtract')) {
то работать не будет.
Надіслати
Поділитися на інших сайтах

Я мержну этот код в мастер-бранч в гите? :)

Галочки в админ интерфейсе явно не хватает. Я сохранил дифф из SVN, но в свой магазин переливать в таком виде не буду. В реальном мире удаление заказа далеко не всегда возвращает реальный товар на полки.
Надіслати
Поділитися на інших сайтах


Галочки в админ интерфейсе явно не хватает.

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

Вообще учет количества товаров на складе полностью отвратительный... особенно при использовании опций. А если у товара несколько опций - то вести учет вообще невозможно.

Надіслати
Поділитися на інших сайтах

Все строки на месте, никакой ошибки нет.

Если ты добавил в начало

if ($this->config->get('config_stock_subtract')) {
то работать не будет.

таки да, все скобки на месте, ночью уже глаза слипались и не так посчитал, но тем не менее, товар не возвращается на место :(.

Кстати, я думал сменить перевод с "вычитать товар со склада" на что-нибудь отражающее то, что он и прибавляться будет.

Кстати, обнаружил косяк: IP-адрес на страничке с клиентами в админке срезается до 15 первых символов (девы, как и в OsCommerce, видать, не в курсе про существование IPv6) ;). Надо будет поправить дамп и функцию обработки таки.

Ещё обнаружил, что неплохо бы вместе с фильтрацией на странице с товарами - прилепить там же (и на страницах с клиентами и юзерами и т.п.) — label'ы, чтобы при тыке в любое место в строчке галочка таки нажималась.

А ещё что-то я так посмотрел на это дело и подумал, что неплохо бы переписать «немного» движок магазина, чтобы исключить SQL из всех скриптов кроме непосредственно драйвера базы. Ибо иначе довольно трудно написать рабочий драйвер для чего-то отличного от MySQL ;)

Надіслати
Поділитися на інших сайтах


А ещё что-то я так посмотрел на это дело и подумал, что неплохо бы переписать «немного» движок магазина, чтобы исключить SQL из всех скриптов кроме непосредственно драйвера базы. Ибо иначе довольно трудно написать рабочий драйвер для чего-то отличного от MySQL ;)

Не понял проблему. Весь SQL и так в моделях. В контроллерах нашёл только у админа на домашней странице несколько SQL-запросов.

А, вот ещё в storefront: в catalog/controller/common/seo_url.php.

Но это же мелочи. Именно что немного, без всяких кавычек.

Надіслати
Поділитися на інших сайтах


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

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

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

Вообще учет количества товаров на складе полностью отвратительный... особенно при использовании опций. А если у товара несколько опций - то вести учет вообще невозможно.

Учёт при использовании опций недопиленный - да. Но чтоб прям отвратительный - по-моему, нет.

Там сейчас есть общее кол-во товара и кол-во, расфасованное по опциям. Сейчас оно в админке никак не связано (к сожалению). Было бы удобней при изменении кол-ва менять и в связанных местах или хотя бы писать зелёным/красным о несовпадении сумм и разнице. Но при продажах кол-во учитывается нормально. Если заказан товар белого цвета - его кол-во уменьшится и у опции, и в товаре.

Меня тоже не слишком радует реализованный в OC учёт. Но и неработающим я его назвать не могу. У нас, например, сейчас ситуация, когда уникальный идентификатор товара - SKU, а не модель, и разные модификации (тот же цвет) имеют на товарном складе разные артикулы. Разумеется, хотелось бы не плодить разноцветные товары как отдельные позиции, а реализовать по-нормальному, опциями. Но у опций нет отдельного артикула. И кол-во товаров хотелось бы обновлять тоже по артикулу (т.е. в опциях, там где есть такое деление), а в общем кол-ве ему бы хорошо самому суммироваться. То есть мы пока вынуждены будем адаптироваться под "главный склад" и скорей всего будем обновлять автоматически только общие остатки товара (в опциях - вручную распределять), а артикулы разных опций просто держать в описании товаров (чтобы были под рукой для формирования заказа для склада).

Надіслати
Поділитися на інших сайтах


Весь SQL и так в моделях.

в моделях. А я говорю о том, чтобы весь SQL был только в драйвере базы данных. Чтобы в моделях и в любых других местах не было ничего специфичного для MySQL.
Надіслати
Поділитися на інших сайтах


Створіть аккаунт або увійдіть для коментування

Ви повинні бути користувачем, щоб залишити коментар

Створити обліковий запис

Зареєструйтеся для отримання облікового запису. Це просто!

Зареєструвати аккаунт

Вхід

Уже зареєстровані? Увійдіть тут.

Вхід зараз
  • Зараз на сторінці   0 користувачів

    • Ні користувачів, які переглядиють цю сторінку
×
×
  • Створити...

Important Information

На нашому сайті використовуються файли cookie і відбувається обробка деяких персональних даних користувачів, щоб поліпшити користувальницький інтерфейс. Щоб дізнатися для чого і які персональні дані ми обробляємо перейдіть за посиланням . Якщо Ви натиснете «Я даю згоду», це означає, що Ви розумієте і приймаєте всі умови, зазначені в цьому Повідомленні про конфіденційність.