Tutorial по обмену с 1С. Часть третья: Выжимаем максимум из стандарта. Что мы хотели бы знать 1000 проектов назад

• Штатный обмен first – и максимально быстро!
• Сущности и порядок обмена
• Точка правды. Единый источник достоверных данных
• Хитрые настройки
• Вывод и личное мнение

Всем привет! Я Дина, ведущий разработчик личных кабинетов и ecom-систем в ИНТЕРВОЛГЕ. Мы не делаем тривиальных проектов. Все что я буду описывать ниже – уникальные задачи. Однако очень часто мы решаем их стандартными средствами за счет хитрых трюков и опыта.

Disclaimer: «Сайтом» мы называем не homepage, не корпоративную визитку и даже не классический интернет-магазин. Для нас «сайт» – B2B интернет-магазин с кучей складов и типов цен, маркетплейс, личный кабинет документооборота.

В каждом втором проекте надо делать обмен данными между сайтом и чем-то на базе 1С: Предприятие.

В статье я расскажу, как настроить стандартный обмен и добиться от него максимума пользы «почти без кастомизаций».

Штатный обмен first – и максимально быстро!

В городе N Наполеона должны были приветствовать салютом, но этого произошло. Император спросил:

– Почему..?

– На это было двадцать пять причин. Первая – у нас не было пороха…

– Достаточно.

Исторический анекдот.

Структура данных и бизнес-процессы в компаниях отличаются. «Стандартная» 1С на самом деле имеет очень много настроек и дает очень большую степень свободы.

«Сайты» также отражают особенности бизнеса, и совмещение данных и логики двух систем часто требует огромных ресурсов.

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

Первый шаг — установка типового модуля обмена с 1С. С чем вы столкнетесь?
Как ни странно, чаще всего модуля в системе просто нет. Почему? Причин много:

• используется базовая 1С, а стандартные модули есть только для ПРОФ или КОРП (приходится переходить на другую 1С, другого пути нет);

• устаревшая конфигурация 1С, для которой нет модуля обмена (можно попробовать запросить модуль в технической поддержке или поставить «через боль» модуль из другой конфигурации);

• 1С настолько сильно кастомизирована, что модуль ставится, но не работает;

• как там все устроено, знает ровно 1 человек, а он занят до 2035 года;

• не получается сделать копию 1С (нет места, например);

• вас не пускают безопасники Заказчика.

Эти вопросы придется решать, они часть критического пути проекта. Как? Разбираться в 1С самому или иметь рядом толкового специалиста. Мы несколько лет назад создали собственный отдел 1С-ников, которые в наших проектах вопрос интеграции закрывают полностью.

Сделали импорт товаров и справочников. Проверяем:

• Выгружается ли товар на сайт с SKU (торговыми предложениями) или без.

Это зависит от выбранного в 1С способа организации хранения товаров (в виде простых товаров или товаров с характеристиками) и влияет на структуру и настройки каталога на сайте.

• Какие свойства товаров выгружаются, все ли они нужны на сайте, есть ли свойства, которых не хватает.

• Выгружаются ли изображения по товарам, каков размер этих изображений.

Если картинки в 1С большие (от 1 Мб), то нужно передавать сжатые картинки.

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

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

• Существуют ли в 1С какие-то хитрые приемы хранения данных:

  • товарами являются группы номенклатуры нижнего уровня, которые по умолчанию выгружаются на сайт из 1С как разделы каталога (это может быть связано с особенностями предметной области, либо является результатом неправильной организации номенклатуры в 1С, когда каждый SKU заводится как отдельный товар, а товаром становится группа последнего уровня вложенности);

  • когда характеристики товара в 1С (SKU) должны стать основными товарами на сайте;

  • когда на сайте нужно продать товар, который фактически из 1С приходит в виде составных частей (например, в импорте приходят столешница и ножки, а на сайте нужно продать целый стол).

• Выгружаются ли все нужные типы цен и сами цены товаров.

• Выгрузку остатков товаров.

• Импорт справочников: все ли данные приходят, корректно ли записываются, есть ли лишние поля.

• Импорт изменений онлайн заказов, ранее выгруженных с сайта в 1С, сопутствующих документов оплат и отгрузок.

Анализируем передачу заказов с сайта в 1С:

• Проверим выгрузку в 1С онлайн заказов с сайта, свойств заказов, контактных лиц, контрагентов, документов оплат и отгрузок.

• При экспорте новых (самостоятельно зарегистрированных на сайте) контактов и контрагентов обычно всегда возникает вопрос их сопоставления. 

• 1С должна установить существование контакта и контрагента в своей базе, корректность входящих данных и связей между объектами.

• Юридических лиц можно идентифицировать по ИНН, а физических - по номеру телефона и/или E-mail. 

• Возникает вопрос правдивости введенных пользователем сайта данных, решать который всегда нужно с учетом бизнес-процессов клиента (возможно, при помощи оффлайн идентификации).

• 1С может вернуть на сайт информацию об ошибке, когда проверка контактного лица или контрагента не прошла, либо пойти по другому сценарию. Если контактное лицо и контрагент уже заведены в 1С, то новый онлайн заказ и пользователь сайта будут привязаны к ним. Иначе будут созданы новые контактное лицо и контрагент и заведены все сопутствующие документы (например, типовой договор, пользовательское соглашение). 

• В обоих случаях успешной привязки онлайн заказа 1С должна вернуть на сайт информацию по привязанному контакту и контрагенту для установки корректных связей между сущностями проекта (например, guid-ы пользователя и компании из 1С; новые элементы справочников, если контактные лица и контрагенты выгружаются на сайт в highload-блоки).

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

Гладко было на бумаге, да забыли про овраги.

(строка Льва Толстого, но уже считается народной пословицей)

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

Модули обмена могут импортировать на сайт из 1С:

• номенклатуру товаров (разделы и подразделы, товары с привязкой к разделам, SKU с привязкой к основным товарам, свойства товаров, типы цен, цены в одной валюте - многовалютности нет, склады, остатки по складам и общий остаток, изображения, единицы измерения);

• контрагентов (выгружаются в список пользователей и в профили покупателей);

• справочники (выгружаются в highload-блоки сайта), например, список контрагентов, поставщиков, производителей и любая другая “первичная” информация;

• изменения по онлайн заказам сайта из 1С (в том числе по связанным документам оплат и отгрузок);

• оффлайн-заказы, 

• документы оплат и отгрузок (на практике оффлайн заказы редко участвуют в импорте).

С сайта в 1С можно выгружать:

• онлайн заказы, 

• связанные документы оплат и отгрузок, штатно создаваемые на сайте;

• контактные лица и контрагенты по онлайн заказам;

• каталог товаров сайта (на практике почти никогда не экспортируется с сайта, может быть актуально в случае, если 1С вступает в бизнес-процессы клиента позже, чем сайт), его разделы и подразделы, товары, характеристики (SKU), типы цен, цены, свойства товаров, изображения.

Тут не все гладко.

Пример 1 «Структура контрагентов». 1С поддерживает выгрузку контрагентов, но на деле эта функция работает не стабильно и часто с ошибками.

Поэтому для получения корректного результата мы выгружаем контакты (пользователей сайта), контрагентов и связи между ними в виде справочников (в highload-блоки). Добавляем в обработчики событий создания и изменения элементов highload-блоков сайта - создание и изменение соответствующих пользователей и профилей покупателей. 

При формировании в 1С указанных справочников стоит учитывать разницу в архитектуре сущностей взаимодействующих систем, чтобы продумать заранее их синхронизацию и гармоничное внедрение сайта в бизнес-логику клиента.

Также стоит отметить, что логику формирования справочника на стороне 1С можно реализовать произвольную, например, выгружая на сайт только отмеченные специальным признаком элементы.

Пример 2 «Скидки»

Типовой обмен не поддерживает выгрузку скидок на сайт, хотя эта функция очень часто нужна на проекте (исключение — скидки, зависящие от количества товара в заказе).

Возможным решением является создание и выгрузка дополнительных типов цен (уже со скидкой). Теоретически это выглядит хорошо, что не всегда подходит в силу используемой редакции БУС, соображений производительности обмена или специфики скидки (персональные скидки). В таком случае мы рекомендуем выгружать скидки через справочники (в highload-блоки), создавая/редактируя на основе этой информации кастомные скидки на стороне сайта (без изменения ядра сайта).

Настройка узлов обмена

Обычно для каждой сущности (справочника, заказов, номенклатуры) мы создаем отдельный узел обмена в 1С. Это удобно для отладки.

Однако если вы выгружаете пользователей из 1С на сайт в виде справочников, стоит объединить обмен заказами и справочниками (как минимум по контактным лицам и контрагентам) в один узел обмена.

Это нужно для того, чтобы по онлайн заказам новых пользователей сайта в том же обмене импортировать вновь созданные/найденные (и ранее не выгруженные) в 1С контакты и контрагентов в highload-блоки сайта. 

Проблема новых значений свойств

Иногда изменения в объектах обмена на стороне 1С (например, при добавлении в онлайн заказ нового свойства на стороне 1С, которое нужно вернуть заполненным на сайт) могут автоматически не распознаваться службой регистрации изменений в 1С. Такие кейсы нужно отслеживать и исправлять.

Пример организации расписания обменов сайта и 1С

Мы пользуемся расписанием автоматического обмена. Вот пример:

• Полный обмен номенклатурой: занимает 1 час, запуск 1 раз в сутки в 04:00.

• Обмен изменениями номенклатуры (выгрузка остатков): занимает 5 минут, запуск каждые 10 минут.

• Полный обмен заказами проводим только 1 раз при старте проекта — для первичной выгрузки оффлайн заказов на сайт (и вручную по необходимости).

• Полный обмен справочниками: занимает 10 минут, запуск 1 раз в сутки в 05:00.

• Обмен изменениями заказов и справочников (общий узел обмена): занимает 2 минуты, запуск каждые 5 минут.

Реалтайм

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

Точка правды. Единый источник достоверных данных

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

Когда мы настраиваем обмен данными между несколькими системами, возникает вопрос синхронизации и достоверности изменений в них. Если данные меняются в 2 системах сразу — не избежать коллизий.

В простых ситуациях, «точкой правды» считается 1С, она вправе перезаписать любые данные в других системах. Однако в реальности бывает и сложнее:

• 1С + 1С + Сайт.

Примеры ситуаций, когда у клиента может быть несколько 1С систем: 

• компания ведет в одной 1С оптовые продажи, а в другой розничные; 

• у магазина есть региональные подразделения со своими отдельными складами и 1С;

• есть несколько поставщиков маркетплейса и у каждого своя 1С, и своя 1С есть у владельца маркетплейса;

• 1С + CRM + сайт.

• 1С (хранит номенклатуру, цены и остатки) + Сайт + третья система, из которой на сайт подтягиваются/парсятся изображения/описания/характеристики.

• 1С + сайт + маркетплейсы + программа лояльности + отдельная WMS + …
  В такой ситуации не обойтись без шины и “взрослого” обмена, но это совсем другая история.

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

Мы советуем в большинстве случаев в качестве главной (master-системы) выбирать одну 1С, а сайт будет обмениваться данными только с ней и через нее.

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

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

Принцип «изменения каждого вида данных только в одной системе».

Помимо онлайн заказов никакие другие сущности, участвующие в импорте из 1С (каталог товаров, оффлайн заказы, справочники), на сайте не редактируются, а их изменения не отправляются в 1С и затираются очередным обменом.

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

В крупных проектах может быть сложнее, потребуется внедрение ESB на базе классического Rabbit или 1C:Шина/Datareon, но пока это все же редкость.

Хитрые настройки

Величайшая уловка дьявола состоит в том, чтобы убедить вас, что он не существует.

Шарль Бодлер

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

Расскажу самое интересное.

Важные настройки - форма "Интеграция с 1С" (Администрирование / Магазин / Настройки / Интеграция с 1С)

Настройка "Использовать контрольные суммы элементов для оптимизации обновления каталога" (вкладка "Каталог") включает механизм контрольных сумм (хешей), определяющих, были ли произведены изменения над объектом обмена и нужно ли его пересохранить. Это позволяет экономить ресурсы сервера и сокращает время выполнения обмена каталогом, так как операции чтения данных из базы работают быстрее операций обновления. 

На скриншоте изменение данных работает в 1,8 раз медленнее, чем чтение.

Объект в базе сайта обновляется лишь в случае, если он был изменен (из 1С пришла новая контрольная сумма). Настройка работает и при полном обмене каталогом.

Эта настройка регулирует контроль версий элементов каталога (товаров, SKU, разделов) и справочников (highload-блоков), выгруженных из 1С. 

На практике бывают ситуации, когда 1С-специалисты, дорабатывая модуль обмена, забывают о необходимости пересчета контрольных сумм каталога после внесенных ими кастомных изменений, в этом случае на сайт приходят новые данные со старыми контрольными суммами, и возникает проблема обновления объектов. Решение этого кейса заключается в отключении контрольных сумм. Если это устраняет проблему обновления, то есть вероятность, что можно исправить причину проблемы на стороне 1С в кастомизированной части модуля обмена.

Вместе с настройкой в форме "Интеграция с 1С" на сайте нужно помнить о "Настройке версионности выгружаемых данных" на стороне 1С, которая также для определенных (выбранных) видов выгруженных на сайт объектов может генерировать каждый раз новую версию, чтобы эти объекты обновлялись при каждой выгрузке.

Настройка "Тегированный кеш инфоблока" (вкладка "Каталог") устанавливает режим сброса кеша инфоблока в процессе/после импорта каталога товаров из 1С на сайт. Если значение будет установлено в "Не сбрасывать", то и после очередного импорта товаров в публичной части сайта будут выводится ранее закешированные, не актуальные данные. Также не стоит выбирать вариант "сбрасывать после каждой операции", так как это с большой долей вероятности способно повлиять на производительность сайта. Рекомендуется сбрасывать кеш.

Если вы воспользуетесь предложенным принципом использования 1С как единого источника достоверных данных, то вам требуется проверить, что установлены опции "Менять статусы заказов по информации из 1С", "Создавать новые документы оплаты из 1с", "Создавать новый документы доставки из 1с" (вкладка "Заказы"), чтобы управление движением заказов принадлежало 1С.

Форма "Интеграция с 1С" - профили обмена и дополнительные данные по заказам.

Интеграция функционала оформления заказов на сайте предполагает создание типов плательщиков (Магазин/Настройки/Типы плательщиков, например, физических и юридических лиц), определяющих набор полей, которые покупатель того или иного типа должен заполнить при создании заказа (ФИО, телефон, E-mail, ИНН и т.д.). 

Такие поля создаются как свойства заказа (Магазин/Настройки/Свойства заказа), привязанные к тому или иному типу покупателя (плательщика).

Для экспорта заказов сайта в 1С можно штатно настроить список отправляемых данных (вкладка "Профили обмена"). Для каждого типа плательщика есть свой профиль обмена. Здесь настраивается соответствие полей экспорта в 1С с полями заказа на сайте (в т.ч. свойствами заказов).

Обязательно проверяйте корректность обмена данными отдельно по онлайн и оффлайн заказам.

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

В настройках каждого профиля обмена формы "Интеграция с 1С" в блоке "1С: Дополнительные параметры" вы можете добавить любое количество дополнительных (в том числе служебных) реквизитов, экспортируемых сайтом по заказам в 1С (данные будут добавлены в узел <Реквизиты> xml-файла экспорта). 

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

Статусы заказов

Статусы — это этапы движения заказа (например, "Новый", "Принят", "Отгружен" и т.д.).

Список и последовательность смены статусов должны соответствовать бизнес-логике сайта.

Статусы заказа на стороне сайта настраиваются через Магазин/Настройки/Статусы. Статус может относиться к заказу или документу отгрузки.

В 1С-Битрикс существуют особые статусы заказов и отгрузок заказов, удаление которых невозможно:

N — начальный статус (название по умолчанию - Принят), в который заказ устанавливается при создании;

F — финальный статус (название по умолчанию - Выполнен), в котором заказ считается выполненным (т.е. оплаченным и доставленным).

DN — начальный статус документа отгрузки товаров (название по умолчанию - Ожидает обработки);

DF — финальный статус документа отгрузки товаров (название по умолчанию - Отгружен).

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

Удобно, когда за логику смены статусов отвечает 1С, тогда на сайте остается лишь принять из 1С новый статус по заказу и вывести его пользователю (и иногда совершить сопутствующие операции, например, отправить уведомления). В этом случае на стороне сайта не нужно совершать дополнительных настроек (например, вкладка "Автоматизация процессов" модуля "Интернет-магазин") и управлять процессом смены статусов заказов.

Настройки модуля "Интернет-магазин"

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

Настройка поможет реализовать, например, такой кейс: при создании заказа для него на сайте устанавливается статус "Ожидает подтверждения", оплата в котором пользователю не доступна. После загрузки заказа в 1С и внутрисистемной проверки (автоматической или менеджером 1С), например, на фактическое наличие остатков по всем товарам или на корректность данных контрагента, 1С отдает сайту новый статус заказа, например, "Принят", в котором оплата на сайте уже возможна. 

Документы оплат и обмен сайта с 1С

При создании онлайн заказа система 1С-Битрикс автоматически штатно создает документ оплаты. Он содержит информацию о выбранной покупателем платежной системе, статусе оплаты, номере и дате документа прихода. 

Без хотя бы одного документа оплаты нельзя оплатить заказ на сайте (например, если удалить штатно созданную оплату).

Если в результате импорта заказов из 1С по онлайн заказу существующий на сайте документ оплаты не приходит, то он автоматически удаляется с сайта.

Документы оплаты могут быть отправлены сайтом в 1С и получены из нее штатными средствами обмена между 1С-Битрикс и 1С, что настраивается в узле обмена с сайтом на стороне 1С: галочки "Загружать оплаты" и "Выгружать оплаты" настроек обмена документами. 

Загрузка оплат из 1С на сайт также должна быть разрешена через вышеупомянутую настройку "Создавать новые документы оплаты из 1с" в 1С-Битрикс.

Для корректного сохранения на сайте номера и даты документа оплаты из 1С в xml-файле импорта необходимо наличие реквизитов "Номер оплаты по 1С" и "Дата оплаты по 1С" (этих реквизитов может не быть по умолчанию, нужно донастроить на стороне 1С).

1С-Битрикс не дает изменять уже оплаченные оплаты. 1С-Битрикс не позволяет удалить заказ с оплаченным документом оплаты.

Для изменения/удаления оплаченной оплаты нужно сначала ее отменить (установить статус “Не оплачено”), а затем уже следующим запуском обмена вместе с изменениями оплаты можно снова сделать ее оплаченной.

Если задачей является отмена или изменения заказа, у которого есть оплаченная оплата на сайте, то нужно сначала отменить эту оплату в одном импорте, а в другом уже отменить или удалить заказ с сайта.

Пометка на удаление документа оплаты из 1С приходит как отмена документа оплаты. Чтобы физически удалить документ оплаты с сайта нужно, чтобы оплата была не оплачена, и этот документ оплаты не пришел при очередном импорте заказов из 1С.

Документы отгрузки и обмен сайта с 1С

При оформлении онлайн заказа в 1С-Битрикс автоматически создается документ отгрузки, привязанный к этому заказу.

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

В настройках узла обмена на стороне 1С можно управлять загрузкой отгрузок в 1С и их выгрузкой на сайт. Импорт отгрузок из 1С на сайт также должен быть разрешен через настройку "Создавать новый документы доставки из 1с " в 1С-Битрикс.

Если в результате импорта заказов из 1С по онлайн заказу существующий на сайте документ отгрузки не приходит, то он автоматически удаляется с сайта.

Для сохранения у отгрузки на сайте номера и  даты документа отгрузки нужно передать соответствующие значения в реквизит "Номер отгрузки по 1С" и  узел "Дата1С" (не реквизит) xml-файла обмена.

Реквизит "Метод доставки ИД" xml-файла обмена  устанавливает способ доставки, который должен быть выбран для отгрузки, в значении реквизита должен быть ID (целое число) службы доставки с сайта.

Если ваш каталог выгружается из 1С без торговых предложений (SKU), а при обмене онлайн заказами возникает ошибка "Попытка добавить в отгрузку товар, не входящий в состав заказа", можно попробовать удалить из xml-файла обмена (на стороне 1С) реквизиты "СвойствоКорзины#CATALOG.XML_ID " и "#PRODUCT.XML_ID" у товаров в отгрузке, эти реквизиты автоматически генерируются в 1С для работы с SKU, но без торговых предложений могут приводить к ошибке.

Если при обмене по заказам (наблюдали для оффлайн заказа) возникает ошибка "Попытка увеличить количество товара в отгрузке до количества, которое превышает не отгруженное в заказе", возможно,  в xml-файле обмена в составе заказа некоторый товар указан несколько раз - с разным количеством заказанных товаров, а в отгрузке только один раз - с суммарным количеством. Нужно на стороне 1С в xml-файле выгрузки для заказа объединить записи по идентичным товарным позициям в одну. Например, если раньше в составе заказа “товар А” был указан дважды с количеством 8 400 шт. и 1 600 шт., а в отгрузке только один раз - с количеством 10 000 шт., то теперь и в заказе, и в отгрузке "товар А" нужно указать только по одному разу с количеством в 10 000 шт.

1С-Битрикс не позволяет изменить отгруженную отгрузку, для внесения изменений нужно сначала сменить статус отгрузки на "Не отгружен" (поле "Отгрузка").

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

Если физически удалить отгрузку из базы 1С, то документ отгрузки просто не придет с заказом (скорее всего потребуется полный обмен, а обмен изменений вообще не подхватит связанный заказ), что удалит отгрузку и на сайте, если она не отгружена.

Вывод и личное мнение

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