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

[kery]

Если ведем в магазине учет товаров на складе и обновляем количество товаров через csv файл то возникает неправильный учет а именно:
1. при наличие размещенных заказов (еще не оплаченных) -товар списался со склада, мы обновили количество товаров из csv, но склад не актуален т.к. если заказ отменен пользователем или администратором как не оплаченный склад становиться больше чем есть в наличие т.к. мы обновляли склад а размещенные заказы к примеру у меня всегда висят в магазине и там в каждом заказе по 20-30 товаров и если заказ отменился то товары обратно плюсуются на склад в итоге неверное количество и как следствие может прийти новый заказ товар оплатиться а в наличие его не будет.
2. я выхожу из этой проблемы следующим образом сначала отключается магазин минут на 15 вручную админ отменяет заказы, и обновляет склад из csv а потом снова отмененным заказам делает статус размещен, но в этом случае у пользователя в личном кабинете появляются несколько статусов то размещен то отменен и так несколько раз т.к. склад обновляется несколько раз в день а заказ можно оплатить в течении 3-х суток что приводит пользователя в замешательство.

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

[eugene_wb]

просто чаще обновлять из csv при обновлении раз в пол часа проблема исчезнет сама собой, так как не важно будет отменен заказ или нет, все равно в течении 30 минут все остатки синхронизируются

[kery]

просто чаще обновлять из csv при обновлении раз в пол часа проблема исчезнет сама собой, так как не важно будет отменен заказ или нет, все равно в течении 30 минут все остатки синхронизируются

не исчезнет так как у меня еще розничный магазин и в нем идут покупки как снимается z-отчет так сразу идет обновление из csv, поэтому лучше если при обновлении из csv будет списываться еще из размещенных

[eugene_wb]

ну в таком случае варианты решения я думаю известны

[badisoft]

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

В общем случае есть два момента:
1. Создан CSV-файл с состоянием склада.
2. как только в дальнейшем произошло какое-то действие со складом (заказ, отмена заказа, розничная продажа), так состояние склада в этом CSV-файле становится неверным. Дальше можно что угодно делать и как угодно выдумывать, но исходное состояние склада уже не верно.

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

PS. Мне думается, что для такой операции (добавление товара на склад) вообще надо использовать не штатную выгрузку-загрузку CSV, а просто отдельную страничку в админке. В реальной жизни ведь мы не используем полный переучет склада для добавления на склад коробки нового товара, а просто создаем приходную накладную.

[kery]

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

поподробней можно про отдельную страничку и сам алгоритм

[badisoft]

поподробней можно про отдельную страничку и сам алгоритм

Есть штатные складские операции:
1. уход со склада (продажа товара, списание товара)
2. приход на склад (приход товара, возврат товара)
Вот из этих четырех вариантов с точки зрения склада реализованы только продажа товара (создание заказа) и возврат товара (отмена заказа). Приход товара и списание товара реализуются либо впрямую уменьшением-увеличением количества в таблице (что вполне приемлемо), либо экспортом CSV, изменением CSV, импортом CSV, где Вы и столкнулись с проблемой.

Правильнее сделать отдельный модуль прихода товара с созданием некой "приходной накладной". А уж как эта "Приходная накладная" оформляться будет - прямо в админке или отдельно в виде XLS/CSV-файла - вопрос десятый.

[kery]

где Вы и столкнулись с проблемой.

Проблема в следующем к примеру на складе 3 палки колбасы, у меня магазин розница и интернет магазин оба они висят на одном физическом складе, при снятии z- отчета в конце смены cнимается csv, в интернет магазине как минимум каждый день висит 4-заказа-которые разрешено оплачивать в течении 3-суток - на этих заказах со склада зарезервированы товары со склада, то что продалось в розницу остатки в csv заносим в интернет магазин(на складе 3 шт. колбасы), через час как занесли один из 4 заказов в ин.магазине отменяется пользователем и к примеру в нем 3 шт колбасы, с этого момента склад в интернет магазине стал +6 штук колбасы и сразу же еще несколько заказов размещаются и оплачиваются .и во всех есть колбаса общим числом в 6 шт. т.к. с интернет магазине ее стало 6 и она доступна для заказа, вот в этом и проблема что +3 шт. еще надо гдето докупить чтобы заказ в интернет магазине доставить вовремя

[badisoft]

Марк Твен как-то очень ехидно прошелся по английским (?) писателям, которые могут нырнуть на одной стороне Ла-Манша с началом предложения и вынырнуть на другой стороне с глаголом в зубах не поставив ни одной точки. Вы не Марк Твен, но точка у Вас во всем сообщении одна единственная. Я не докапываюсь, я реально потерял мысль где-то на третьей строке Вашего сообщения. Перечитал. Понял, что все равно не понимаю и не пойму. Если хочется, чтобы я понял и что-то ответил - постарайтесь поделить эту непрерывную мысль на отдельные предложения. Очевидно, что сами Вы прекрасно понимаете, что написали, т.к. это Ваша проблема, она Вам близка и понятна. Но читая со стороны хрен поймешь, о чем речь.

[kery]

Попробую понятней. На одном физическом складе работают два магазина один розничный второй интернет, учет продаж по рознице осуществляется по снятию z-отчета и остатки заливаются в csv-файл. Далее этот csv-файл с остатками заливается в интернет магазин.
1.В интернет магазине каждый день висят размещенные заказы которые разрешено оплачивать пользователям в течении 3-х дней, и склад актуален на момент последнего залития csv-файла с остатками, к примеру вчера мы залили на склад 3 штуки колбасы, через час клиент сделал заказ и заказал эти 3 штуки колбасы, его заказ висит как размещенный и колбаса списалась со склада т.е. она не доступна к заказу.
2. сегодня мы с розничного магазина продали товары и сняли остатки с физического склада, в этих остатках так и осталось 3 штуки колбасы и мы заносим csv-файл с остатками в интернет магазин, на складе интернет магазина стало 3 палки колбасы, т.е. товар снова стал доступен для заказа, его может заказать еще одни покупатель, в итоге в интернет магазине 2 заказа с 6 палками колбасы, а в наличие на физическом складе их всего 3 штуки, и вот проблема в том что если эти два заказа оплатятся то 3 штуки у меня есть а еще 3 мне придется где то докупать чтобы доставить заказ клиенту.

И вся проблема в том что размещенных заказов может быть 10 и в каждом по 20-30 товаров и если каждый раз отслеживать каждый заказ вручную и потом просчитывать все минуса вручную в csv-файле то это просто уйма времени и сил.

[badisoft]

Другими словами, Вам нужно, чтобы при заливке склада череp csv-файл не происходило прямого изменения склада "как в CSV прописано", а прописывалось количество из CSV минус зарезервированное количество товара. А зарезервированным количеством в Вашем случае является количество товара в заказах со статусом "новый". Так?

Кстати, а как Вы решаете момент "три дня на оплату заказа"? Через три дня вручную переводите заказ в состояние "отменен" или дописали автоматическое изменение статуса?

[kery]

Другими словами, Вам нужно, чтобы при заливке склада череp csv-файл не происходило прямого изменения склада "как в CSV прописано", а прописывалось количество из CSV минус зарезервированное количество товара. А зарезервированным количеством в Вашем случае является количество товара в заказах со статусом "новый". Так?

да именно так? только статус размещен или приостановлен!

Кстати, а как Вы решаете момент "три дня на оплату заказа"? Через три дня вручную переводите заказ в состояние "отменен" или дописали автоматическое изменение статуса?

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

[badisoft]

В файле catalog_import_functions.php в функции _importProduct перед

UpdateProduct( $productID,

вставляем

$sum = db_fetch_assoc(db_query( "SELECT SUM(Quantity) AS reserved FROM ".ORDERED_CARTS_TABLE.
									" JOIN ".ORDERS_TABLE." USING(orderID)".
									" WHERE statusID=".ostGetNewOrderStatus().
									" AND itemID IN(SELECT itemID FROM ".SHOPPING_CART_ITEMS_TABLE." WHERE productID=$productID)"));
	$in_stock -= $sum['reserved'];

перводится с PHP на русский так:
(1) считаем, сколько зарезервировано товара в заказа со статусом "новый".
(2) вычитаем это зарезервированное количество из указаного в CSV-файле перед сохранением количества продуктов.

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

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

Фу, как нерационально. Почему бы автоматически не менять статус "нового" заказа на "отменен" через заданное количество дней?

[kery]

спасибо за дополнение! Пробую вроде работает, багов пока не выявил.

Фу, как нерационально. Почему бы автоматически не менять статус "нового" заказа на "отменен" через заданное количество дней?

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

[Cruelten]

Всем привет. Подскажите плиз. А есть ли такой модуль, который может выгружать историю всех продаж, то есть всех товаров за определенный период, сколько и чего продано и на какую сумму. Считать должен по определенному статусу товара. Допустим "Доставлен"?

[badisoft]

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

Такое довольно не сложно пишется, но готового я не припоминаю. У ShopCMS вообще нет практически никакой статистики по продажам.
Но если уж писать, то надо не конкретные мелкие задачи реализовывать, а посмотреть в других CMS, где наиболее удачно реализована статистика продаж в комплексе и сделать то же самое, содрав идею и интерфейс.

PS. Кстати, ИМХО, такую задачу вполне реализует Google Analitics и прилагаемые инструменты.

[Cruelten]

Интересно, это каким таким образом гугл аналитикс знает, доставлен у меня товар или нет? И сколько товара приобретено?
Теперь по нашей теме. Готов профинансировать подобный плагин. Более подробно о нем написал в соответствующей теме. http://vsupport.club...__fromsearch__1

[badisoft]

Интересно, это каким таким образом гугл аналитикс знает, доставлен у меня товар или нет? И сколько товара приобретено?

Что Вы ему сообщите, то он знать и будет.
https://developers.g...icsjs/ecommerce
https://developers.g...anced-ecommerce
Первый вариант я тут выкладывал, но он отслеживает только факт оформления заказа, а не историю оформление/оплата/доставка.
Второй вариант, судя по наличию раздела "Отслеживание этапов оформления покупки" дает возможность смотреть статистику и по статусам, если считать смены статусов этапами оформления.