При работе со старыми конфигурациями 1С, такими как Управление торговлей 10.3 или Бухгалтерия предприятия 2.0, администраторы и программисты часто сталкиваются с ситуацией, когда добавление новой настройки обмена (например, по другой организации) внезапно «ломает» уже существующую и исправно работающую синхронизацию. В этой статье мы подробно разберем, почему так происходит, изучим внутреннюю механику планов обмена и научимся восстанавливать работоспособность системы без потери данных.
Для начала проанализируем ситуацию, описанную пользователем. В базе УТ 10.3 существовал обмен с кодом 003 (код текущей базы). После создания новой настройки через прямое подключение код базы изменился на 006. В результате старый обмен, который ожидал увидеть в файлах или при подключении идентификатор 003, перестал узнавать базу.
Ключ к пониманию проблемы кроется в архитектуре объекта ПланыОбмена. В каждом плане обмена существует один специальный предопределенный элемент, который называется «ЭтотУзел».
Важно понимать: ЭтотУзел — это глобальный идентификатор текущей информационной базы в рамках конкретного плана обмена. Если у вас в одном плане обмена настроено десять синхронизаций с разными базами, у всех них будет один и тот же ЭтотУзел. Изменяя код этого узла для «новой» настройки, вы автоматически меняете его для всех «старых» настроек в этом же плане обмена.
Рассмотрим подробнее, почему при использовании прямого подключения (через COM-соединение) риск совершить ошибку выше. Когда мы настраиваем обмен через файлы, мы вручную прописываем коды. Однако мастер настройки прямого подключения в УТ 10.3 часто берет на себя «автоматизацию» процесса.
В процессе работы мастера может возникнуть запрос: «Укажите код этой информационной базы». Пользователь, полагая, что он создает уникальные настройки для новой организации, вводит новый код (например, 006). Программа, не выдавая предупреждений о глобальных последствиях, перезаписывает код предопределенного элемента ЭтотУзел. С этого момента все исходящие сообщения из этой базы будут помечаться кодом 006, а входящие файлы будут отклоняться, так как они адресованы узлу 003, которого в базе больше формально не существует.
Если вы столкнулись с подобной ситуацией, паниковать не стоит. Проанализируем алгоритм действий для возвращения системы в рабочее состояние:
003, значит, именно это значение нам нужно вернуть в УТ 10.3.Операции — Планы обмена. Выбираем нужный план обмена. В списке узлов находим тот, который помечен жирным шрифтом или специальной иконкой (это и есть ЭтотУзел). Заходим в него и меняем код обратно с 006 на 003.007).После того как мы вернули код 003, работа может не возобновиться сразу. Проанализируем ситуацию с номерами сообщений. Каждый обмен хранит два счетчика: НомерПринятого и НомерОтправленного.
Если во время «экспериментов» с кодом 006 база успела отправить или принять какие-то данные, счетчики сбились. При попытке загрузить старый файл обмена 1С может выдать ошибку: «Номер сообщения меньше или равен номеру ранее принятого сообщения».
Рассмотрим, как это исправить программно или через интерфейс:
В форме узла обмена обычно есть поля «Номер отправленного сообщения» и «Номер принятого сообщения». Если они недоступны для редактирования, можно воспользоваться небольшой обработкой или кодом во внешней консоли:
УзелОбъекта = ПланыОбмена.ОбменУправлениеТорговлейБухгалтерияПредприятия.НайтиПоКоду("001").ПолучитьОбъект();
УзелОбъекта.НомерОтправленного = 0;
УзелОбъекта.НомерПринятого = 0;
УзелОбъекта.Записать();
Совет: Установка номеров в «0» заставит систему принять следующий файл как первый, но будьте осторожны — это может привести к попытке повторной выгрузки большого объема исторических данных. Лучше установить номер, на единицу меньший, чем номер в последнем успешном файле обмена.
Чтобы избежать подобных проблем в будущем, проанализируем правила «хорошего тона» при настройке синхронизации в 1С:
Мы выяснили, что ошибка «Сбой в синхронизации» в 1С:УТ 10.3 чаще всего вызвана тем, что пользователь случайно изменил глобальный код ЭтогоУзла в плане обмена.
Краткий итог действий для исправления:
Во-первых, верните код ЭтогоУзла к первоначальному значению.
Во-вторых, проверьте и при необходимости сбросьте номера сообщений в узлах-корреспондентах.
В-третьих, при настройке новых обменов через прямое подключение внимательно следите за тем, чтобы не перезаписывать текущие идентификаторы базы.
Соблюдение этих простых правил позволит вам поддерживать стабильную работу даже сложной системы распределенных баз с множеством организаций.