Доставка цифровых товаров.

[elsin]

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

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

может у кого есть решение, поделитесь, буду благодарен

[nemo]

Так, на вскидку, или где-то в настройках статусов заказа может быть ошибка или нет вот этого патча: http://forum.viarts.ru/downloads.php?do=file&id=97 Хотя, может и ещё в чём дело... У нас пока не очень много пользователей, которые продают пинкоды (ключи, серийные номера), поэтому информации мало, надо разбираться.

[Alex]

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

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

может у кого есть решение, поделитесь, буду благодарен

На данный момент дела обстоят следующим образом:
В результате тестирования продажи пин кодов была выявлена вышеописанная ошибка в скрипте и отписано разработчикам скрипта, но они как то "ПОЛОЖИТЕЛЬНО" (т.е. на все положили) отнеслись к решению данной проблемы и выпустили патч, который при удалении заказа освобождает зарезервированные пин коды, что с моей точки зрения в корне неверно, т.к. если удалить уже оплаченный и выданный заказ коды тоже освобождаются и поступают в продажу, но других решений на данный момент НЕТ.

[nemo]

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

Алексей, я долго думал над этим и наблюдал за форумом разработчиков, т.к. знаю точно, что среди них есть пользователи, продающие цифровые товары... Так вот... никто из них почему-то не озадачился этой проблемой, а может за проблему это не считают...
Посмотрим на данную ошибку (или особенность?) с другой стороны, точнее, сторон... Со стороны владельца магазина, менеджера этого магазина, зарегистрированного пользователя этого магазина, который так же имеет право выставлять в нём на продажу свои электронные товары...
1. Если в магазине работают наёмные специалисты (даже если не работают), существование понятной и прозрачной отчётности должно быть по умолчанию. В скрипте это раздел со всеми заказами, которые по мере поступления записываются по порядку, каждый имеет свой номер и можно посмотреть его детали и историю. Не важно, был заказ доставлен или отменён, история о нём должна оставаться для отчётности всегда (если он не тестовый). Если в списке заказов будет нумерация 18,19,20,27,28,29, то у владельца магазина к менеджеру могут возникнуть вопросы о том, куда делись заказа с 21 по 26, что это были за заказы и почему удалены? Теперь, я думаю, что на месте владельца запретил бы вообще удалять менеджеру заказы, т.к. исчезает "прозрачность" работы магазина. Если у менеджера широкие полномочия, ничто не помешает ему даже в случае удаления отменённых или выполненных заказов ввести заново эти серийные номера (заранее их скопировав), указать другие реквизиты для оплаты, продать, уже после сменить статус на отменён или удалить. И узнать или доказать будет проблемно, кроме отсутствующих по порядку нумерации заказов, ничего нет, а по отчётности проданного в заказах и поступивших денежных средств на счёт владельца расхождений не будет.
Хорошо, может это только я параноик, может надо людям больше доверять, но если нет самой возможности обмануть, это всё же лучше... Не удаляя заказы, доверия больше, и никто никому ничего не обязан доказывать.
2. Это случай с управляющим магазинов (менеджером), а теперь представил, что произойдёт, такая ситуация с зарегистрированным пользователем и его товарами... в существующей версии ведь, оплата приходит на единый счёт магазина... если так же удалить отменённый заказ, его так же не будет в статистике продаж, пользователь ничего не увидит. А если пин-код товара пользователя был уникальным? Получится, что удалив отменённый заказ, вы удалили его пин-код, т.е. решили за него...
В общем, всё не так уж просто... есть над чем подумать...

[Alex]

Алексей, я долго думал над этим и наблюдал за форумом разработчиков, т.к. знаю точно, что среди них есть пользователи, продающие цифровые товары... Так вот... никто из них почему-то не озадачился этой проблемой, а может за проблему это не считают...
Посмотрим на данную ошибку (или особенность?) с другой стороны, точнее, сторон... Со стороны владельца магазина, менеджера этого магазина, зарегистрированного пользователя этого магазина, который так же имеет право выставлять в нём на продажу свои электронные товары...
1. Если в магазине работают наёмные специалисты (даже если не работают), существование понятной и прозрачной отчётности должно быть по умолчанию. В скрипте это раздел со всеми заказами, которые по мере поступления записываются по порядку, каждый имеет свой номер и можно посмотреть его детали и историю. Не важно, был заказ доставлен или отменён, история о нём должна оставаться для отчётности всегда (если он не тестовый). Если в списке заказов будет нумерация 18,19,20,27,28,29, то у владельца магазина к менеджеру могут возникнуть вопросы о том, куда делись заказа с 21 по 26, что это были за заказы и почему удалены? Теперь, я думаю, что на месте владельца запретил бы вообще удалять менеджеру заказы, т.к. исчезает "прозрачность" работы магазина. Если у менеджера широкие полномочия, ничто не помешает ему даже в случае удаления отменённых или выполненных заказов ввести заново эти серийные номера (заранее их скопировав), указать другие реквизиты для оплаты, продать, уже после сменить статус на отменён или удалить. И узнать или доказать будет проблемно, кроме отсутствующих по порядку нумерации заказов, ничего нет, а по отчётности проданного в заказах и поступивших денежных средств на счёт владельца расхождений не будет.
Хорошо, может это только я параноик, может надо людям больше доверять, но если нет самой возможности обмануть, это всё же лучше... Не удаляя заказы, доверия больше, и никто никому ничего не обязан доказывать.
2. Это случай с управляющим магазинов (менеджером), а теперь представил, что произойдёт, такая ситуация с зарегистрированным пользователем и его товарами... в существующей версии ведь, оплата приходит на единый счёт магазина... если так же удалить отменённый заказ, его так же не будет в статистике продаж, пользователь ничего не увидит. А если пин-код товара пользователя был уникальным? Получится, что удалив отменённый заказ, вы удалили его пин-код, т.е. решили за него...
В общем, всё не так уж просто... есть над чем подумать...

Да не суть важно, удален заказ или нет, хотя допустим живет магазин 2-3 года, и решили урезать базу... и что мы получим?
Правильнее делать так же как и с реальным товаром, оплатил-получил, а если не оплатил, то товар находится в продаже. Здесь же получается: заказал-не оплатил, а потом админу вылавливать такие заказы и УДАЛЯТЬ т.к. при выставлении статуса отменен не решает ситуации, т.е. не о какой автоматизации процесса просто нет.
ПС При таком решении вопроса можно запросто вывести конкурентов с рынка, и продавец может поиметь кучу проблем. Идем к конкуренту и заказываем весь цифровой товар, отказываемся от оплаты, и товары у конкурента появятся в продаже только после вмешательства админа, что совсем не есть хорошо!!!

[elsin]

Да не суть важно, удален заказ или нет, хотя допустим живет магазин 2-3 года, и решили урезать базу... и что мы получим?
Правильнее делать так же как и с реальным товаром, оплатил-получил, а если не оплатил, то товар находится в продаже. Здесь же получается: заказал-не оплатил, а потом админу вылавливать такие заказы и УДАЛЯТЬ т.к. при выставлении статуса отменен не решает ситуации, т.е. не о какой автоматизации процесса просто нет.
ПС При таком решении вопроса можно запросто вывести конкурентов с рынка, и продавец может поиметь кучу проблем. Идем к конкуренту и заказываем весь цифровой товар, отказываемся от оплаты, и товары у конкурента появятся в продаже только после вмешательства админа, что совсем не есть хорошо!!!

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

[nemo]

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

[elsin]

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

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

[Ches]

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

Если правильно Вас понял - при отмене заказа нужно ещё демаркировать серийники - снова свободны... Так?

[Alex]

Если правильно Вас понял - при отмене заказа нужно ещё демаркировать серийники - снова свободны... Так?

В кратце ДА.
А точнее процедура такая, по пунктам:
1.Создаем заказ - номер сразу резервируется.
2.Изменяется статус заказа (не важно на какой) - номер остается зарезервированным.
3.Удаляем заказ - номер снимается с резерва.

[Ches]

Задание добавлено в TODO Developing Team

[nemo]

В кратце ДА.
А точнее процедура такая, по пунктам:
1.Создаем заказ - номер сразу резервируется.
2.Изменяется статус заказа (не важно на какой) - номер остается зарезервированным.
3.Удаляем заказ - номер снимается с резерва.

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

[Ches]

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

2 elsin - уточняйте задачу с учетом вышесказанного

[elsin]

2 elsin - уточняйте задачу с учетом вышесказанного

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

[Ches]

было бы неплохо это все автоматизировать с неоплачеными заказами.

Автоматизировать как? Уточняйте! По шагам, конкретно.

[Alex]

Автоматизировать как? Уточняйте! По шагам, конкретно.

В идеале должна быть настройка в " Действия со складом " - снять с резерва, на данный момент есть только зарезервировать и отпущен.

[Ches]

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

Это окончательное ТЗ разработчикам?

[Alex]

Это окончательное ТЗ разработчикам?

Окончательное ТЗ я думаю должно выглядеть так: "Поле действие со складом" должно иметь четыре значения: 1.Зарезервировать 2.Не резервировать 3.Отгрузить 4.Снять с резерва.
И я думаю, что с такими настройками можно реализовать любые пожелания.

[Ches]

ТЗ я думаю должно выглядеть так: "Поле действие со складом" должно иметь четыре значения: 1.Зарезервировать 2.Не резервировать 3.Отгрузить 4.Снять с резерва.
И я думаю, что с такими настройками можно реализовать любые пожелания.

Если в течение 24 часов дополнений к ТЗ не будет - ставим в TODO Developing Team.

[Alex]

Если в течение 24 часов дополнений к ТЗ не будет - ставим в TODO Developing Team.

Когда можно ожидать доработки?