Остатки на складе - Разработки и улучшения

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

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

Когда клиент делает заказ, количество в базе уменьшается — все верно (резерв).
Если сменить статус на "отказ" — это количество возвращается на сайт, что тоже логично.

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

В общем планируется ли или существует ли решение данных проблем? Или это уже на другом уровне надо решать (типа синхронизации с CRM)?

Апну тему, т.к. все еще актуальна.

Поглощают темные мысли о написании своей cms+crm (где есть нормальный склад, двусторонние связи похожих продуктов, телефония, функционал e-mail маркетинга и все слаженно, органично и автоматизированно работает), но с содроганием отгоняю их прочь.
Стремление к идеалу парализует работу

Как вообще работают нормальные e-commerce компании? Делают связки cms+crm+google analytics+mailchimp+какая-то штука для учета оффлайна по штрихкодам?

В общем планируется ли или существует ли решение данных проблем?

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

Как вообще работают нормальные e-commerce компании?

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

Не согласен, но не буду холиварить)

Ладно, усмирю свой перфекционизм и буду пилить связку.
Спасибо ответ!

Но вот эти косяки делают "склад" бесполезным

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

Не согласен, но не буду холиварить)

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

Возможно займусь, не понятно почему изначально не сделали.

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

Вести нормальный учет не получится без учета партий (себестоимости). сделать это в интернет магазине - ну ... может у кого то и есть свободных пару лет

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

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

имхо мысль абсолютно верная