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

Направления и режимы обмена заказами - кто кому и когда отдаёт

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

Решение

Смотрим, какие направления включены:

foreach (['1C_SALE_EXPORT_PAYED', '1C_SALE_EXPORT_ORDERS_AFTER',
          '1C_SALE_IMPORT_CANCEL'] as $code) {
    printf("%-28s %s\n", $code, COption::GetOptionString('sale', $code, '-'));
}
// приём заказов с сайта и выгрузка на сайт живут разными настройками

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

Выбираем режим: по расписанию или сразу:

$res = CSaleOrder::GetList(['ID' => 'DESC'], ['>DATE_UPDATE' => date('d.m.Y')],
    false, ['nTopCount' => 5], ['ID', 'ACCOUNT_NUMBER', 'DATE_STATUS', 'UPDATED_1C']);
while ($order = $res->Fetch()) {
    printf("%s обновлён=%s признак 1С=%s\n",
        $order['ACCOUNT_NUMBER'], $order['DATE_STATUS'], $order['UPDATED_1C']);
}

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

Сверяем версии модуля обмена и конфигурации:

Окно терминала
grep -m1 'ModuleVersion' /home/bitrix/www/bitrix/modules/sale/install/version.php
# набор передаваемых полей зависит от версии модуля обмена в учётной системе
# управление торговлей и небольшая фирма отдают разные наборы данных

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

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

Окно терминала
ls -lt /home/bitrix/www/upload/1c_exchange/ | head
grep -c 'sale' /home/bitrix/www/upload/1c_exchange/*.log
# в журнале видно направление сеанса и число обработанных документов

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

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

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

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

Заказы уходят, а статусы не возвращаются.

Включено только направление приёма заказов с сайта. Возврат статусов настраивается отдельной настройкой обмена.

В реальном времени заказы приходят пачками позже.

Учётная система не достучалась до сайта в момент оформления. Документ откладывается до ближайшего сеанса по расписанию.

Часть полей заказа не доезжает.

Конфигурация учётной системы не передаёт эти поля. Набор полей зависит от версии модуля обмена, а не от настроек сайта.

Сеанс прошёл, документов ноль.

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

Большой заказ обрывает обмен.

Документ на сотни позиций не укладывается в отведённое время. Пределы времени и памяти поднимают на стороне сайта.

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

Можно ли выгружать только оплаченные заказы?

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

Кто инициатор обмена заказами?

Учётная система: она подключается к точке обмена. Сайт только отвечает на её запросы.

Чем отличается обмен с разными конфигурациями?

Составом полей и правилами сопоставления. Общая схема одна, а детали приходится проверять на месте.

Нужен ли реальный режим интернет-магазину?

Обычно нет: обмен раз в 15 минут закрывает потребность. Реальное время оправдано там, где склад отвечает мгновенно.

Смежное

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