Меняем стоимость доставки совершённого заказа
Имеется минишоп 2.1.11 и нужно менять стоимость доставки из родного интерфейса.
В заказе у нас уже есть все данные и возможности для изменения и пересчёта общего заказа, надеюсь что не упустил никаких условий и нюансов.
Меняем тип поля доставки на редактируемый (displayfield -> numberfield) на 392 строке в assets/components/minishop2/js/mgr/orders/orders.grid.js
Добавляем 5 строк в core/components/minishop2/processors/mgr/orders/update.class.php
В заказе у нас уже есть все данные и возможности для изменения и пересчёта общего заказа, надеюсь что не упустил никаких условий и нюансов.
Меняем тип поля доставки на редактируемый (displayfield -> numberfield) на 392 строке в assets/components/minishop2/js/mgr/orders/orders.grid.js
columnWidth: .33
,layout: 'form'
,items: [
{xtype: 'displayfield', name: 'createdon', fieldLabel: _('ms2_createdon'), anchor: '100%'}
,{xtype: 'numberfield', name: 'delivery_cost', fieldLabel: _('ms2_delivery_cost'), anchor: '100%'}
]Добавляем 5 строк в core/components/minishop2/processors/mgr/orders/update.class.php
public function beforeSave() {
if ($this->object->get('status') != $this->status) {
$change_status = $this->modx->miniShop2->changeOrderStatus($this->object->get('id'), $this->object->get('status'));
if ($change_status !== true) {
return $change_status;
}
}
// начало
if ($this->object->get('delivery_cost') !== $this->delivery_cost) {
$tmp1 = $this->object->get('delivery_cost');
$tmp2 = $this->object->get('cart_cost');
$this->object->set('cost', $tmp1+$tmp2);
}
// конец
$this->object->set('updatedon', time());
return parent::beforeSave();
}
Комментарии: 16
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
То есть, просто убираешь «Итоговый» у нужного статуса и его можно менять:
Ну а пересчёт стоимости гораздо лучше повесить на отдельный плагин, если нужно.
Лично я против изменения исходников дополнения, но хозяин — барин.
Единственное правильное решение — создание нового класса оплаты со своей логикой, применимой для конкретного магазина. Тогда доставка будет сразу считаться правильно, а покупатель получит возможность оплатить заказ, стоимость которого уже не изменится.
Михаил вы описываете идеальные условия, когда покупается единица товара не завязанная на кучу условий которые влияют на стоимость доставки. Но когда от количества товара сильно зависят габариты и вес то и доставку угадать не реально. Вот для этого и требуется такое решение. Да есть куча калькуляторов все что надо рассчитывающих, но если заставлять это делать покупателя он уйдет!
Не знаю как у других, но у меня так: Пользователь оформляет заказ, выбирает способ доставки. Далее оператор связывается с пользователем и подтверждает объем заказа, параллельно он согласовывает удобную компанию для доставки и проводит расчет стоимости доставки, дополняя заказ (при этом пользователь оповещается о стоимости). Далее сменяется статус и пользователю отправляется письмо с реквизитами для оплаты. Ну и далее по сценарию :)
Василий пожалуйста подскажите автору как сделать без хака, возможно он найдет возможность и желание переделать столь полезное дополнение.
Но нет, я зачем-то придумал методы доставки и возможность их расширять, хотя можно было просто вводить стоимость прямо в заказе.
Так что без хака пока никак не получится.
P.S. Сколько чего покупал через интернет — ни разу не приходилось созваниваться с магазином. Не повезло, наверное.
Безусловно можно все автоматизировать, установить все возможные калькуляторы, вложить десятки тысяч денег, но не всегда это коммерчески оправдано.
Может подскажете способ расширить метод доставки чтоб осуществить ручной ввод стоимости доставки? Я все понимаю, время деньги, может мы тупим, а все на поверхности лежит…
Автоматизация, на самом деле, далеко не настолько дорогая, как может показаться. И в случае с доставками тоже. Например, в магазине уже есть несколько калькуляторов доставки, причем стоимость любого менее 1000 руб.
Если есть необходимость в расчете для иной ТК, для которой калькулятор еще не готов, можно заказать его создание. Стоимость будет не запредельная — 1500-10000 руб., в зависимости от дополнительных пожеланий и качества API самой ТК.
Теперь же посмотрим со стороны бизнеса — оператор, звонящий для корректировки стоимости доставки, должен получать зарплату. Если не давать пользователю возможность оплатить в момент оформления заказа (когда он наиболее «горячий»), повышается процент отмененных заказов (соглашусь, что здесь сильна специфика направления ИМ).
В результате получается, что в разрезе всего нескольких месяцев автоматизация сэкономит для компании больше денег, чем потребует для создания и внедрения соответствующего функционала.
Можно еще долго работать старыми методами, не замечая издержек, так как они много где считаются нормой, но давайте смотреть правде в глаза: XXI век, повальное стремление к максимальной автоматизации и сокращению издержек не только денежных, но и временных. Не только со стороны компании, но и со стороны покупателя. Чем дальше, тем больше людей будет требовать сервис по принципу «Здесь и сейчас». Если компания не сможет соответствовать новым требованиям, она будет терять все больше клиентов.
Личный пример — если на этапе оформления заказа я не вижу окончательной стоимости, которая не будет изменяться, вряд ли оформлю этот заказ, тк уже проще пойти к конкуренту и все оформить за несколько минут, чем создать заказ и еще пару часов ждать звонка от оператора. А если я хочу оплатить сразу же? Но через 1-2 часа я уже могу передумать или найти за те же деньги еще лучше.
Пример выше — упущенная выгода. Чем больше таких ситуаций, тем больше потери от отсутствия автоматизации.
И напоследок: стоимость доставки может зависеть от многих факторов — вес, размер, хрупкость и т.д., согласен. Но все эти параметры можно забить для товаров, после чего они будут исправно учитываться калькуляторами. Без участия оператора.
Для малого бизнеса это уже крупные вложения…
Согласен для компаний с оборотом в день от 100тр глупо не применять автоматизацию.
10тр — это крупные вложения в малый бизнес? Это уже какой-то микроскопический бизнес, а не малый — но с 6 модулями доставки и 12 способами оплаты.
Если уже на старте у бизнеса такие серьёзные проблемы с планированием — я бы не стал его запускать вовсе.
Если серьезно: расскажите мне, пжл, для чего маленькому магазину, который только с дикими усилиями может вложить в свое развитие 10 000 руб., 6 модулей доставки и 12 способов оплаты?
Любой магазин, продающий хотя бы на 3000 руб. в день, может легко позволить себе приобретение необходимых модулей доставки и оплаты.
Да и то, это абсолютный абсурд предлагать клиенту выбрать для оплаты один из 12 способов. Тем более, что среди модулей оплаты есть интеграции с агрегаторами, силами которых собираются платежи из сотен платежных систем.
Я уже не говорю о внутренних сложностях учета — из десятка платежных систем собирать, в общей сложности, 50 000 руб. за месяц (мы ведь говорим о малом бизнеса в Вашем представлении, а не в общем?).
А если Вы представляете себе малый бизнес компанией из одного человека, тем более ему необходимо максимально автоматизировать процесс оформления и оплаты заказа покупателем, иначе он так и останется бизнесменом в компании одного себя.
Всего лишь до 3000 руб., но появляется автоматический расчет стоимости доставки и мгновенная оплата, что повысит количество продаж. И эти затраты для любого малого бизнеса более, чем оправданы.