При организации обмена данными между Управление торговлей 10.3 и Розница 2.2 через электронную почту часто возникают сбои, сопровождающиеся ошибкой Номер сообщения меньше или равен текущему. Несмотря на то, что механизм транспорта работает корректно и письма доставляются, система отказывается принимать пакеты данных. Давайте разберем, почему это происходит и как найти источник проблемы.
Механизм обмена данными в 1С:Предприятие опирается на строгую последовательность номеров сообщений в Планах обмена. Когда база-получатель получает файл обмена, она проверяет номер входящего сообщения. Если он меньше или равен уже загруженному, 1С считает такое сообщение устаревшим или дубликатом. Если вы видите, что сообщение пришло, но не загрузилось, это означает сбой логической последовательности обмена.
Одной из наиболее частых, но неочевидных причин является наличие копий баз данных. Рассмотрим подробнее ситуацию, когда тестовая копия базы выполняет обмен с той же учетной записью электронной почты.
Плана обмена, что и в основной, тестовая база может отправить «ответное» письмо с некорректным номером, которое введет основную базу в заблуждение относительно текущего состояния обмена.Что нужно сделать: Проверьте все тестовые и архивные копии базы. Убедитесь, что в них отключены все Регламентные задания, связанные с обменом данными. Идеальный вариант — изменение кода узла в тестовой базе, чтобы исключить пересечения.
Если вы уверены, что тестовые базы не влияют на обмен, необходимо проанализировать работу самого почтового транспорта. Электронная почта не гарантирует порядок доставки и может быть подвержена задержкам.
Рассмотрим по шагам, как диагностировать почтовый канал:
Выгрузка и загрузка данных XML. Это позволит понять, является ли файл «битым» или ошибка кроется именно в самом механизме Плана обмена.Помните, что загрузка сообщения обмена — это Транзакция. Если в момент записи данных происходит ошибка (например, из-за нехватки прав или нарушения целостности данных), вся транзакция откатывается.
Если в коде конфигурации есть ошибки в обработке исключений, может сложиться ситуация, при которой:
Для отладки этой ситуации мы рекомендуем проанализировать Журнал регистрации в момент времени, предшествующий сообщению об ошибке нумерации. Скорее всего, вы обнаружите запись об ошибке доступа или неверных данных, которая и стала причиной незавершенной транзакции.
Электронная почта является не самым надежным транспортом для высокоинтенсивного обмена. Если вы столкнулись с регулярными потерями данных, рассмотрите следующие варианты:
Переход на файловый обмен: Используйте общую сетевую папку или FTP-сервер вместо Электронной почты. Это исключит влияние почтовых серверов и протоколов на целостность файлов обмена.
Реализация контроля через РС: Если смена транспорта невозможна, создайте Регистр сведений для логирования входящих сообщений. В нем фиксируйте номер сообщения ДО начала процесса загрузки. Это позволит вам видеть, какие номера действительно были приняты системой, и сравнивать их с текущим значением в Плане обмена.
Проанализировав эти пункты вместе с системным администратором, вы сможете локализовать «узкое место» и предотвратить потерю данных в будущем.