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

Статусы заказа при обмене - возврат из 1С и обратное направление

Разбираемся, как статус заказа возвращается из учётной системы, и что делать, когда он не меняется.

Решение

Смотрим текущее состояние заказа и признаки обмена:

use Bitrix\Main\Loader;
use Bitrix\Sale\Internals\OrderTable;


Loader::includeModule('sale');
$row = OrderTable::getRow([
    'select' => ['ID', 'STATUS_ID', 'PAYED', 'DEDUCTED', 'VERSION_1C', 'ID_1C'],
    'filter' => ['=ID' => $orderId],
]);
printf("статус=%s оплачен=%s отгружен=%s версия=%s\n",
    $row['STATUS_ID'], $row['PAYED'], $row['DEDUCTED'], $row['VERSION_1C'] ?: '-');

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

Проверяем, приезжает ли заказ обратно:

Окно терминала
# обратное направление: учётная система отправляет заказ на сайт тем же адресом
grep -c '<Документ>' /home/bitrix/www/upload/1c_exchange/*.xml 2>/dev/null
tail -30 /home/bitrix/www/upload/1c_exchange.log 2>/dev/null | grep -i 'sale\|order'

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

Сопоставляем статусы двух систем:

$res = CSaleStatus::GetList([], [], false, false, ['ID', 'NAME', 'SORT']);
while ($status = $res->Fetch()) {
    printf("%-4s %-30s\n", $status['ID'], $status['NAME']);
}
// соответствие статусов задаётся на стороне учётной системы, в настройках узла

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

Ловим момент изменения заказа обменом:

// обработчик события: сработает и при обмене, и при правке из админки
AddEventHandler('sale', 'OnSaleOrderSaved',
    static function (\Bitrix\Main\Event $event) {
        $order = $event->getParameter('ENTITY');
        // здесь видно новое состояние заказа, включая пришедший статус
    }
);

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

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

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

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

Статус на сайте не меняется после обработки в 1С.

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

Заказ отмечен оплаченным, а статус прежний.

Оплата и статус заказа - это разные поля. Учётная система может прислать признак оплаты, не меняя при этом статус заказа.

Пришедший статус игнорируется.

Нет соответствия между статусом учётной системы и статусом сайта. Незнакомый статус отбрасывается при разборе документа молча.

Правка заказа на сайте не доезжает до 1С.

У заказа не сброшен признак выгрузки. Он считается уже отданным, и повторно в учётную систему не уезжает.

Заказы двух сайтов путаются в одной базе.

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

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

Можно ли менять статусы только из 1С?

Да, и на боевых магазинах так обычно и делают: учётная система становится единственным источником состояния заказа. Ручную смену статуса при этом закрывают правами.

Уходит ли письмо покупателю при смене статуса обменом?

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

Что происходит с позициями, удалёнными в 1С?

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

Как понять, что заказ вообще приезжал обратно?

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

Смежное

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