Улучшить учёт возвратов при многоскладовости

Интернет-магазины Пожелания и обратная связь
1

cs-cart 4.13.3

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

При оформлении заказа понять, с какого склада товар попал в заказ невозможно. Мы попросили Ecom-Labs разработать нам модуль, чтоб эту информацию получать, ведь она крайне необходима!

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

Выглядит это примерно так.

До заказа:
warehouse_id = 14, product_id = 4658, amount = 10
warehouse_id = 27, product_id = 4658, amount = 4

Делаю заказ на 6 единиц товара!

После заказа, вроде бы хорошо:
warehouse_id = 14, product_id = 4658, amount = 8
warehouse_id = 27, product_id = 4658, amount = 0

Аннулирую заказ:
warehouse_id = 14, product_id = 4658, amount = 8
warehouse_id = 27, product_id = 4658, amount = 6

Спасибо поддержке, получил 2 ноября ответ:

Действительно, при отмене заказа или возврате, количество товара возвращается на склад с меньшим ID.

В настоящее время в модуле “Склады” не реализован учёт того, с какого именно склада было произведено списание товара, поэтому система не может вернуть его на те же самые склады. К сожалению, для реализации данной функции необходимо перерабатывать сам модуль.

Я передала ваш запрос разработчикам и сообщу вам, как только появятся какие-либо новости.

Правда, в приведенном мной примере товар вернулся на склад с большим, не меньшим ID склада (на 27). Но не это главное. А главное то, что отсутствие учета, с какого склада заказан товар и возврат товара при отмене заказа в неизвестном направлении приводит фактически к полной невозможности настроить логистику без больших дополнительных усилий.

И это у нас пока два склада. Но на подходе третий. А у кого-то их уже больше. И очень хотелось бы иметь полноценный инструмент для работы с магазинами/складами.

Если вам тоже нужен подобный фикс, не поленитесь, нажмите на сердечко :slight_smile:

9 лайков
2

Ого!

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

1 лайк
3

По моему уже если внедрять то ручной выбор на какой именно склад будет произведен возврат каждой единицы.
Ведь не факт, что оно поедет обратно именно туда откуда приехало.

1 лайк
4

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

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

2 лайка
5

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

6

Лайкнул.

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

2 лайка
7

Может быть, для кого-то и небольшая. Только проблема для склада начинается сразу после оформления заказа. Так как сейчас совершенно непонятно, с каких складов сколько изделий заказано, ведь количество изделий в заказе показано суммой без разбивки по складам. Я с этого и начал:

1 лайк
8

Это тот случай, когда есть проблема, но она не баг, и решение скорее всего займёт больше 45 дней. Поэтому перенёс тему из раздела “Баг-трекер” в “Как улучшить CS-Cart”. Но обращение увидели, запрос на доработку я на всякий случай ещё раз зафиксировал. Посмотрим, получится ли включить улучшение в одну из будущих версий.

В поддержке ответили правильно, я лишь могу немного дополнить. При разработке функциональности складов мы исходили из нескольких принципов:

  • Склады просили выпустить как можно скорее. Поэтому из всего многообразия того, что можно было бы реализовать, мы выбирали то, без чего было нельзя. Реестр перемещений в список “безусловно необходимых вещей” тогда не попал. И доработка это масштабная (об этом и пишет поддержка).

  • Были существующие клиенты, у которых уже несколько складов, и которые как-то вне CS-Cart вели по ним учёт, а потом актуализировали количество товаров в магазине. Например, через обмен по CommerceML.

  • У всех разные правила, с какого склада брать тот или иной товар. А раз CS-Cart не складская программа, то всё учесть не получится. Поэтому реализовали единственный базовый сценарий.

Поэтому мы исходили из того, что решение проблемы с логистикой будет таким:

Например, покупатель зарезервировал товар. Его за это время могли перекинуть на другой склад. А могли и не перекинуть. CS-Cart сейчас должен узнавать об этом от складской программы. Для случая, когда такой программы нет, скорее всего будем смотреть в сторону вот этого варианта:

9

Благодарю за ответ. Срок, конечно, не радует, но что мы, ваши потребители, можем с этим поделать… :face_with_raised_eyebrow:

А вот это, простите, ерунда какая-то. Если товар зарезервирован на складе в Казани (все города и склады вымышленные, естественно), то как он вдруг может быть перемещен в Новосибирск? С какого перепугу? В том смысле, что хотелось бы увидеть ту организацию, которая так работает — перемещает зарезервированный товар куда ей в голову взбредёт?

Я считаю, что единственно верный вариант автоматический. С какого склада взяли, на тот верните. А все перемещения — не вопрос cs-cart, а вопрос организации логистики в каждой конкретной компании. Насколько я в курсе, задачу логистики cs-cart не решает от слова «совсем», не так ли?

У вас есть поле extra в таблице PREFIX _order_details
Что мешает писать туда ID_склада, количество для каждой позиции и потом эти же данные использовать для возврата товаров на верные склады?

Так что этот вариант решения:

скорее через задний проход.

Давайте посмотрим логику процесса:

  1. Клиент сделал заказ одного товара (один и тот же product_id) с трех складов: первый был ближе, но там мало товара, второй шел по порядку (кстати, по какому?), но там тоже оказалось мало товара, пришлось забрать еще и с третьего склада.

  2. В заказнике будет видно с какого склада взято сколько единиц?

2а. Если видно, то какие есть проблемы, чтоб вернуть товары на те же склады?

2b. Если не видно, то о чём мы тут вообще говорим?

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

Куда вернулся товар? На какой склад? На первый? А если он был добавлен позже и у него ID не самый маленький, но, сюрприз, и не самый большой? На второй? На n+1й?

Или вы предложите нам после каждого аннулирования заказов синхронизировать остатки по всем складам? Really?!

Может всё-таки нужно сделать по-человечески? Где взял, туда и положи?

10

Куда далеко ходить? тот же WB при заказе из Новосибирска - сначала переместит товар со склада в [Москве в Новосибирск, потом до покупателя, и при отказе покупателя - товар так и останется на складе в Новосибирске ) проходили, когда WB предлагал нам съездить за невыкупленным товаром самим в столь отдаленные города )

Логично

1 лайк
11

Возможно я не очень внятно выразился, но, естественно, я имел в виду те организации, которые:

  1. Используют cs-cart
  2. Не имеют при этом собственной транспортной компании.

Все-таки WB не только интернет-магазин, но еще и мощнейшая логистическая сеть со своими ПВЗ в огромном количестве населенных пунктов. Поэтому у них такая логика может быть оправдана. И еще один момент: WB физически может отправить товар, по которому сделано не резервирование, а заказ. Я говорю о тех товарах, которые зарезервированы, но фактически не оплачены (мы отправляем товары только после оплаты), то есть физически не перемещены со склада. Понимаю, что если кто работает с наложенным платежом или оплатой при получении может желать другой логики возврата товаров при аннулировании заказов.

1 лайк
12

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

1 лайк
13

Благодарю! :slight_smile:

Как теперь было бы здорово, если бы и разработчики тоже поняли нас :wink:

15

Здравствуйте!

В 4.15.1 была улучшена логика возврата товаров, если эти товары использовали функциональность складов. Теперь:

  • При возврате товара или отмене заказа, товары возвращаются на нужные склады.
  • Используемые в заказе склады показываются в деталях заказа, в панели администратора.
2 лайка