Перейти к содержимому
BXWiki

Настройка магазина по шагам - что за чем включать

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

Решение

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

Смотрим типы плательщика:

\Bitrix\Main\Loader::includeModule('sale');
$rows = \Bitrix\Sale\Internals\PersonTypeTable::getList([
    'select' => ['ID', 'NAME', 'ACTIVE', 'SORT'],
])->fetchAll();
print_r($rows);   // обычно их два: физическое лицо и компания

Тип плательщика - корень всей настройки. От него зависят и набор свойств заказа, и доступные оплаты, поэтому его заводят первым, а не после свойств.

Проверяем свойства заказа и их группы:

$props = \Bitrix\Sale\Internals\OrderPropsTable::getList([
    'select' => ['ID', 'PERSON_TYPE_ID', 'CODE', 'TYPE', 'REQUIRED', 'PROPS_GROUP_ID'],
    'order' => ['PERSON_TYPE_ID' => 'ASC', 'SORT' => 'ASC'],
])->fetchAll();
// группы свойств заводят до самих свойств: свойство без группы не выводится

Свойства принадлежат типу плательщика и живут в группах. Пустая группа выглядит безобидно, а свойство без неё просто не попадает в форму оформления - это самая частая находка при разборе «поля нет, а оно заведено».

Наполняем справочники до служб доставки:

$locations = \Bitrix\Sale\Location\LocationTable::getList([
    'select' => ['CNT' => new \Bitrix\Main\Entity\ExpressionField('CNT', 'COUNT(%s)', 'ID')],
])->fetch();
$priceTypes = \Bitrix\Catalog\GroupTable::getList(['select' => ['ID', 'NAME', 'BASE']])->fetchAll();
// службы доставки ограничиваются местоположениями, а цены нужны для расчёта

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

Смотрим службы доставки и платёжные системы:

foreach (\Bitrix\Sale\Delivery\Services\Manager::getActiveList() as $service) {
    printf("%-6s %s\n", $service['ID'], $service['NAME']);
}
foreach (\Bitrix\Sale\PaySystem\Manager::getList(['select' => ['ID', 'NAME']])->fetchAll() as $ps) {
    printf("%-6s %s\n", $ps['ID'], $ps['NAME']);
}
// платёжные системы привязывают к типам плательщика, поэтому они идут после них

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

Заканчиваем статусами и печатными формами:

$statuses = \Bitrix\Sale\Internals\StatusTable::getList([
    'select' => ['ID', 'TYPE', 'SORT'], 'filter' => ['=TYPE' => 'O'],
])->fetchAll();
// статусы заказа и статусы отгрузки - разные наборы, тип их и различает
// печатные формы и права менеджеров настраивают после статусов

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

Типичные проблемы

Свойство заказа заведено, но в форме его нет.

Оно принадлежит другому типу плательщика либо не привязано к группе свойств. Проверяют обе привязки по очереди.

Служба доставки активна, но не показывается.

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

В форме нет нужной платёжной системы.

Система не привязана к этому типу плательщика. Привязку задают в самой платёжной системе, а не в компоненте оформления.

После смены набора статусов сломались уведомления.

Почтовые события и права менеджеров ссылались на прежние статусы. Набор статусов продумывают до запуска магазина.

Цены есть, а в корзине товар без цены.

Компонент показывает не тот тип цены либо у группы покупателя нет прав на него. Типы цен заводят до настройки витрины.

Частые вопросы

Почему порядок настройки важен?

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

Сколько типов плательщика заводить?

Столько, сколько разных наборов данных вы собираете: обычно физлицо и компания. Каждый тип - это свой набор свойств, свои оплаты и своя форма оформления, поэтому лишние типы удваивают поддержку.

Обязательно ли импортировать местоположения?

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

Когда настраивать статусы заказов?

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

Что проверить перед первым заказом?

Пройти оформление руками каждым типом плательщика: увидеть свои поля, доставки, оплаты и письмо покупателю. Это находит больше ошибок настройки, чем чтение списков в админке.

Смежное

Первоисточник