Дата отгрузки есть в XML, но не обновляется в B2B-системе: проверка поля обмена

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

Определите, что означает дата

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

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

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

Проверьте входной XML целиком в нужной области

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

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

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

Формат должен быть однозначным

Запишите допустимое представление даты и правило часового пояса, если время присутствует. Строки вроде 01/02 могут интерпретироваться по-разному. Для машинного обмена лучше использовать согласованный однозначный формат, а локализованный вид строить при показе.

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

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

Выбор целевого объекта должен быть точным

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

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

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

Создание и обновление проверяют раздельно

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

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

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

Пустота и очистка даты

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

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

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

Запоздавшие сообщения

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

На стенде отправьте новую дату, затем старое состояние. Ожидание определите заранее. Если процесс допускает исправление назад, его нужно отличать от запоздавшего повтора. Простое правило «никогда не уменьшать дату» может запретить законную корректировку.

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

Показ даты в кабинете

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

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

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

Приёмка нового поля

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

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

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

Контрольный документ с двумя отгрузками

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

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

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

Разбор пустого и некорректного значения

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

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

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

Пограничное время и дата без времени

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

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

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

Повтор после исправления обработчика

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

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

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

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

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

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

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

Доказывает ли присутствие даты в XML её поддержку сайтом?

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

Нужно ли очищать дату, если её нет в пакете?

Не автоматически. Отсутствие в частичном обновлении и явная очистка являются разными состояниями.

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

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