Из заказа B2B пропадают позиции после резервирования в 1С: разбор повторного обмена

Как выглядит сбой на двух последовательных обменах

Представим учебный B2B-заказ из трёх позиций. Покупатель заказал два привода, один блок питания и комплект креплений. Магазин сохранил три строки, передал документ в учётную систему и получил подтверждение. После этого сотрудник в 1С изменил резерв одной позиции: товар должен поступить к согласованной дате. На следующем обмене магазин показывает уже две строки. Это описание проверочного сценария, а не утверждение о результате конкретного внедрения.

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

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

Товар, строка заказа и резерв описывают разные вещи

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

В учебном документе у привода может быть заказано две единицы, зарезервирована одна и ожидается поступление второй. В другом случае весь объём идёт под поставку. Ещё один вариант: резерв не передан, потому что используемый формат или настройка его не выгружает. Для магазина это три разных состояния. Если каждое из них превращается в «позиции нет», обработчик уничтожает коммерческую информацию на основании складского признака.

Полезно заранее выписать словарь входящих значений. Что означает ноль? Чем отличается отсутствующий элемент сообщения от пустого элемента? Как передаётся отмена резерва? Есть ли отдельный признак удаления строки? Ответы должны следовать из фактического формата обмена и согласованных правил магазина. Названия полей и внутренние коды не следует брать из случайного примера: версия модуля, конфигурация 1С и собственные доработки могут менять контракт.

Какие снимки нужны для сравнения

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

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

Сначала сравнить исходное сообщение, потом обработчик

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

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

Когда входные данные выглядят корректно, смотрят журнал решений обработчика. Полезна запись вида «строка сохранена; изменён резерв» или «строка исключена; получен явный признак удаления». Запись «обмен завершён успешно» слишком общая: она сообщает только о завершении операции. Для поиска причины нужно видеть, какое условие сработало. В журнал не включают персональные данные, комментарии покупателя и секреты подключения.

Как задать безопасное правило неизвестного состояния

Для неизвестного состояния резерва разумно остановить зависимое изменение и сохранить прежний состав до разбора. Это рекомендация для проектирования, а не универсальная настройка любой интеграции. Если договорённость требует другого поведения, её описывают явно и проверяют отдельно. Главный критерий: необратимое изменение коммерческого документа не должно происходить по молчаливому предположению о незнакомом значении.

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

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

Повтор сообщения не должен менять результат повторно

После исправления полезно дважды обработать одно и то же учебное сообщение. Состав, количество и суммы после второй попытки должны совпасть с первой успешной обработкой. Иначе интеграция зависит от числа доставок: например, резерв каждый раз вычитается из остатка или строка повторно добавляется. Такая проверка касается повторяемости результата, даже если конкретный транспорт обычно доставляет сообщение один раз.

Отдельный опыт нужен для нарушенного порядка. Сначала обрабатывают более новое состояние, затем более старое. Решение о допустимости второго обновления связывают с версией или временем изменения документа, если эти признаки надёжно поддерживаются системой. Сравнивать только время получения на сайте недостаточно: старое сообщение может прийти позже после восстановления связи. Если источник не даёт надёжной версии, ограничение фиксируют и выбирают согласованный способ сверки.

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

Что включить в приёмку кроме удачного примера

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

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

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

Как исправлять накопленные расхождения

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

Восстановление лучше проводить как отдельную операцию с предварительным просмотром. Для каждого заказа видны добавляемые строки, количества, суммы и основание изменения. Затем выбирают, должны ли повторно формироваться уведомления и документы. Автоматическая повторная отправка всех писем способна запутать покупателя, особенно если он уже получил согласованное предложение другим способом. Техническое исправление и коммуникация о нём требуют разных правил.

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

Разбор частичного резерва на одной строке

Уточним учебный опыт: строка «Привод» содержит две единицы, а сообщение о резерве касается только одной. Первый вопрос к обработчику: обновляет ли он отдельное складское значение или заменяет заказанное количество? Если после обработки заказанное количество стало единицей, строка ещё не исчезла, но смысл документа уже изменён. Поэтому контроль только числа строк недостаточен. В протокол включают количество и коммерческую сумму каждой позиции.

Затем берут уже обработанный заказ и подают тот же пакет ещё раз. Если количество снова уменьшилось, обнаружена накопительная операция вместо установки состояния. Если сумма изменилась без изменения состава, нужно проверить независимый пересчёт. Эти наблюдения не доказывают конкретную причину исходного сбоя, но дают точные направления поиска. Исправление принимают по заранее выбранному результату каждой строки таблицы, а не по общему сообщению «обмен выполнен».

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

Смежная тема разобрана в материале Интеграция интернет-магазина с 1С: правила обмена.

Вопросы по теме

Почему позиции с резервом к дате исчезают из заказа при повторном обмене?

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

Документация и источники

• 1С-Битрикс: обмен с 1С: Наличие компонентов обмена CommerceML; конкретные правила проекта проверяются отдельно.