4.9.3 и статус Отложен

Баг-трекер
1

Я из тех, для кого пока в обновлении больше болезни мозга, чем пользы. Спрашиваю у таких же как я и у знающих, а возможно также ведет себя и обновленная новая версия.
Начал писать, и вспомнил, что когда-то давно уже задавал подобный вопрос, и ТП не смогла воспроизвести проблему, я же тогда не совсем понимал как сам добился подобного результата. Сейчас понимание пришло.
Если установлено отслеживание количества на складе и запрет заказа отсутствующего товара - то при оформлении заказа покупателем или через админку - просто не удастся положить товар в корзину или в заказ.
Но.
Преамбула: изменение количества для статусов Открыт и Отложен - Уменьшение.
Есть интеграции с другими площадками, и не всегда обмен количеством с ними идет в реальном времени. Может сложиться ситуация, когда в ИМ осталась 1 штука, а на сторонней площадке пока еще 2. Там заказывают эти две штуки, заказ приходит через веб хук и размещается через функцию fn_place_order, в результате статус у него Отложен, количество товара в базе не изменилось.
Теперь работаем с заказом.
Позвонили покупателю, договорились, он согласен купить одну штуку.
Меняем количество в заказе со статусом Отложен с 2 на 1 - и товара в базе становится 2. Теперь безболезненно меняем статус заказа с Отложен на Открыт - изменения количества не происходит, так как у обоих статусов количество на уменьшение.
Встречался кто-нибудь с подобной ситуацией?
Может возникнуть также например при отслеживании количества на складе и синхронизации количества с 1с: пришел заказ на товар, он разместился в статус открыт, затем из 1С пришел 0 на его количество, и при любой попытке изменить статус заказа - он попадет в Отложен. Правда тут не знаю как поведет себя количество при смене статуса из Открыт в Отложен, но скорее всего также, так как уменьшение и уменьшение. Поэтому количество останется без изменений.
Поэтому та же схема: сделали заказ на товары, он в статусе Открыт. После этого произошла выгрузка количества из 1С - и один товар например в результате инвентаризации, или его купили оффлайн - стал 0. Менеджер же не в курсе этого, он просто пообщался с клиентом и пытается перевести заказ в статус В Работе - а заказ падает в Отложен. Менеджер разбирается в чем дело, снова звонит покупателю, и тот дает согласие что согласен получить заказ без этого товара. Менеджер удаляет нулевой товар из заказа - и(!) в базе этого артикула становится 1 штука! Вот тут хорошо бы проверять что если статус заказа Отложен - ведь это не просто статус, а статус со специфичным смыслом и константой STATUS_BACKORDERED_ORDER - при изменении количества товара в заказе - количество этого товара в базе не менялось.

PS кстати, товары, которых хватает в наличии, но из за того отсутсвующего - лежа в заказе со статусом Отложен - тоже в итоге не отнимались от общего числа из базы. И не будут уменьшены при переводе в статус Открыт потом, после редактирования “неугодного” количества. А значит по факту после перевода в статус Открыт таких товаров в базе будет числиться больше чем имеется.

Вижу пока решение в лоб. В функции fn_change_order_status
вместо условия

if ($order_statuses[$status_to]['params']['inventory'] == 'D' 
&& $order_statuses[$status_from]['params']['inventory'] == 'I') {
                // decrease amount

прописать

if (
    ($order_statuses[$status_to]['params']['inventory'] == 'D' 
    && 
        ($order_statuses[$status_from]['params']['inventory'] == 'I'
        || $status_from == STATUS_BACKORDERED_ORDER)
) {
                // decrease amount

Если в новых версиях та же фигня - переложу в баг трекер.

Отыскал прежнюю тему

а также

2

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

            if ($order_statuses[$status_to]['params']['inventory'] == 'D' && $order_statuses[$status_from]['params']['inventory'] == 'I') {
                // decrease amount
                if (!fn_update_product_amount(
                    $v['product_id'],
                    $v['amount'],
                    @$v['extra']['product_options'],
                    '-',
                    $force_notification !== false,
                    $order_info
                )) {
                    $status_to = STATUS_BACKORDERED_ORDER;

                    $_error = true;
                    fn_set_notification('W', __('warning'), __('low_stock_subj', array(
                        '[product]' => fn_get_product_name($v['product_id']) . ' #' . $v['product_id'],
                    )));

                    break;
...
и далее 
...
    if ($_error) {
        if (!empty($_updated_ids)) {
            foreach ($_updated_ids as $id) {
                // increase amount
                fn_update_product_amount(
                    $order_info['products'][$id]['product_id'],
                    $order_info['products'][$id]['amount'],
                    @$order_info['products'][$id]['extra']['product_options'],
                    '+',
                    $force_notification !== false,
                    $order_info
                );
            }
            unset($_updated_ids);
        }

то есть по сути статус заказа Отложен - хоть у него и указоно влияние на количества товара - уменьшение, по сути своей - у него здесь стояло бы - Не Изменять
(помните, давно-давно обсуждали, и предлагалось ввести такой вариант? Вы сказали - нельзя, а получается - он существует)

3

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