Семён, вы опять не совсем правильно все поняли. Это не минимальная база. Да, есть какие-то моменты, которые могут создать видимость недоработки. Но здесь самое ценное — это самое ядро и основа этой сборки. Повторюсь: сделать редактирование заказов — это не большая проблема для понимающего разработчика, и делается за день-два (с какими-то наворотами может конечно больше времени занять). А вот тот же биллинг, который входит в саму сборку, вот его не всякий средний разработчик напишет и за пару месяцев. Там очень много моментов тонких есть. У нас многого нет в коробке, но многое легко дорабатывается. Там есть больше из коробки, но вы попробуйте это доработать. Взять те же заказы, которые изначально хранятся в БД, а не в сессиях, как на других модулях. Вы это просто так не доработаете в шопкипере. Вот вам простой пользовательский сценарий для примера: оптовый магазин, постоянные клиенты со скидками. Вот зашел клиент, добавил несколько товаров со скидками в корзину, а потом ушел (это нормальная практика, что они несколько дней набивают корзину, а потом делает окончательный заказ). Так вот, ушел он, вернулся через пару дней, и не обратил внимание, что он уже не авторизован. Он ходит по сайту и накидывает товары в корзину (даже не обращая внимания, что ему скидок не показывается, и такое бывает). А потом такой оформить заказ, и вдруг понимает, что он не авторизован, что только текущие товары в корзине. Понимаете? Вот мы с таким сталкивались. И на одном магазине дорабатывали это, что когда пользователь авторизовывается, выполняется поиск предыдущей корзины, и если она есть и она не оформленная, то происходит перенос товаров в нее, при чем с пересчетом скидок, а новая ненужная удаляется. Попробуйте сделать это на шопкипере или минишопе. Уточню: сессия всегда одна. Нельзя с новой сессией найти старую.
Те, кто сделал не один магазин на всех трех модулях, понимают уже разницу.