После копирования B2B-портала не сопоставляются статусы: как проверить справочники

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

Названия, коды и внутренние ID имеют разные роли

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

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

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

Сначала прочитайте реальное состояние копии

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

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

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

Карта сопоставления должна быть читаемой

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

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

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

Добавление недостающего статуса

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

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

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

Копирование среды требует проверки конфигурации

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

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

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

Пробный обмен нужен до массового запуска

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

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

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

Порядок событий и запоздавшие сообщения

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

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

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

Что увидит сотрудник

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

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

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

Критерии готовности

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

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

Учебная карта с изменёнными внутренними ID

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

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

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

Новый заказ и существующая история

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

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

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

Проверка неизвестного значения

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

Затем добавьте соответствие и повторите ту же операцию по предусмотренному механизму восстановления. Она должна примениться один раз к нужному объекту. Добавление карты не должно требовать массового повторного импорта всей истории без понимания последствий.

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

Что включить в паспорт переноса

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

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

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

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

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

Связанные разборы

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

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

Нужно ли сразу создать все статусы заново?

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

Доказывает ли одинаковое название правильное сопоставление?

Нет. Проверяют код, сущность, внутреннюю ссылку и смысл перехода.

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

• 1С-Битрикс: объекты интернет-магазина: Заказ, оплата и отгрузка имеют отдельные роли; бонусный договор статьи не объявлен штатной функцией.
• Обмен 1С-Битрикс с 1С: Разделение импорта и экспорта CommerceML; правила частичного обновления нужно проверять в конкретном проекте.