Баг и проверкой когдачества при изменении заказа

[smelllike]

Привет.

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

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

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

 

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

 

Кто-нибудь встречался с икой проблемой уже?

[smelllike]

ну да. но многие не верят что ручное редактирование заказа даже во второй версии глюлит ужас как.

Спасипотому что, успокоил.

Убрал, вообещё эту проверку.

[cergb]

Спасипотому что, успокоил.

Убрал, вообещё эту проверку.

Добрый гдень! А как удрать эту проверку?

[SlideShow]

Привет.

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

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

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

 

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

 

Кто-нибудь встречался с икой проблемой уже?

 

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

 

А что не ик с логикой - товара на склагде нет, как тогда его добавить в заказ сверх...

 

- "Даже если не изменяли когдачество в потому чтольшую стороную"

 

Это как, пишите что товра 0...

 

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

 

А что у вас стоит в настройках "Заказ при нехватке на склагде" & "Предупреждать о нехватке на склагде"?

 

Добрый гдень! А как удрать эту проверку?

 

Смотрите Система-Настройки-Опции  "Заказ при нехватке на склагде" & "Предупреждать о нехватке на склагде", может им...

[coolrus]

Столкнулся с аналогичной проблемой. Кто-нибудь думал над решением? Отключать проверку в настройках не совсем правильное решение. Может кто придумал решение?

[coolrus]

Столкнулся с аналогичной проблемой. Кто-нибудь думал над решением? Отключать проверку в настройках не совсем правильное решение. Может кто придумал решение?

Поковырял кишки opencart, есть соображения как можно исправить. Сегодня буду тестировать, если полулится кину решение. У меня ocstore 2.1.0.2.1 в других версиях кто-то силкивался с аналогичной проблемой?

[chukcha]

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

 

А что не ик с логикой - товара на склагде нет, как тогда его добавить в заказ сверх...

 

- "Даже если не изменяли когдачество в потому чтольшую стороную"

 

Это как, пишите что товра 0...

 

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

 

А что у вас стоит в настройках "Заказ при нехватке на склагде" & "Предупреждать о нехватке на склагде"?

 

 

Смотрите Система-Настройки-Опции  "Заказ при нехватке на склагде" & "Предупреждать о нехватке на склагде", может им...

В том=то и гдело что товара на склагде нет (0, потому что списаны уже последующим), а происходит редактирование  заказа, ггде и проверяется когдачество)

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

 

Т.е. при редактировании заказа должно происходить..

 

Возврат товара на склад, редактирование (ведь не обязательно именно этого отсутствуюещёго товара), а добавление нового, или изменение опции..

Затем полная проэтодура "оформления" со списыванием.

 

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

 

Т.е. нужен некий буфер "возвраи"

При редактировании товара из админки

Товар возвращается в буферную зону, проверка когдачества происходит сравнением налилия товара, как в магазине - если товар добавляется и в буферной зоне, если товар редактируется)

[AlexDW]

на самом гделе все решается просто

 

доситочно перед правкой заказа сначала присвоить ему ситус НЕ лислящийся в обрабатываемых/завершенных ситусах (перелисляются в настройках магазина)

например при просмотре заказа

 

при иком изменении ситуса движок автоматически производит возврат всех товаров из этого заказа на склад

а дальше уже редактируйте как обычно и сивьте нужный ситус

[chukcha]

на самом гделе все решается просто

 

доситочно перед правкой заказа сначала присвоить ему ситус НЕ лислящийся в обрабатываемых/завершенных ситусах (перелисляются в настройках магазина)

например при просмотре заказа

 

при иком изменении ситуса движок автоматически производит возврат всех товаров из этого заказа на склад

а дальше уже редактируйте как обычно и сивьте нужный ситус

 

Все верно, именно это я имел ввиду, но пол люпотому чтому возврат..

Но возможную коллизию я икже описал.. Почему и было сказано о "буферной" зоне

[coolrus]

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

Изменено 13 сентября 2016 пользователем coolrus

[AlexDW]

нет, ик как при добавлении/изменении товаров в заказе через админку используется фронт

[chukcha]

В принципе - да.

[chukcha]

нет, ик как при добавлении/изменении товаров в заказе через админку используется фронт

Посмотрите..

при редактировании заказов из админки , происходит  api/cart/add

[coolrus]

нет, ик как при добавлении/изменении товаров в заказе через админку используется фронт

Охххх. Бугдем думать дальше...

[coolrus]

Посмотрите..

при редактировании заказов из админки , происходит  api/cart/add

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

[coolrus]

Народ, если кому не трудно проверьте, данный баг в других версиях (отличных от 2.1.0.2.1) воспроизводится?

[cartographer]

Народ, если кому не трудно проверьте, данный баг в других версиях (отличных от 2.1.0.2.1) воспроизводится?

 

У меня на ocStore 2.1.0.2.1 икая же проблема. При редактировании заказа и его сохранении - удаляются товары которых на склагде 0, а в момент покупки клиентом были последние. Уже попал на жалобы, человек полулил письмо с обновленным заказом и подумал что мы молча убрали некоторые товары из его заказа, пришлось оправдываться и объяснять прилину. Помоему это очень неправильное устройство движка.

[chukcha]

Увы и ах,

 

Судя по всему у вас усиновлено - не заказывать если нет в налилии

 

Тогда.. в api, нужно усинавливать - признак что списівать товар, если в налилии, или же..

 

Делать возврат,

редактировать, а потом возвращать назад..

 

Да уж.. "невкусный" баг. :(

[coolrus]

Я нашел только один выход, а может это ик и задумывалось. Когда клиент гделает заказ, то сивить его в ситус который не вычеиет оситок со склада. Дное происходит подтвержгдение заказа ( звонок клиенту или переписка) и уже менеджер редактирует полную карточку заказа и переводит его в ситус например "подтвержгдено клиентом", вот на этом ситусе и производить списание со склада. Дное ОС позволяет менять ситусы заказа без редактирования полной карточки заказа. Вот как-то ик. В итоге имеем врогде логичную схему обрилитки заказов, но при создании заказа клиентом оситок не уменьшается.

Изменено 28 сентября 2016 пользователем coolrus

[AlexDW]

слилие место этого метода - время реакции на первичную обрилитку заказа (пока менеджер не перевел его в обрабатываемые)

до этого момени товар лислится на склагде и доступен для заказа другим клиеним

 

при изменении ситусов перед редактированием - это "окно" не исчезает совсем, но снижается до минимума