Ошибки обмена 1С: почему базы не синхронизируются и как починить

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

Сначала сохраните обе базы и проблемный файл обмена. Для файловых баз скопируйте каталоги с 1Cv8.1CD. Для клиент-серверных снимите резервные копии средствами СУБД.

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

Сначала найдите последний успешный этап

Откройте журнал регистрации и отберите события по времени последнего обмена. Запишите текст ошибки, имя пользователя и точное время сбоя. Эти данные доступны в журнале регистрации — на них же опирается технический разбор 1C Expert «Как восстановить обмен в 1С».

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

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

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

Если симптомы не похожи на сбой синхронизации, откройте указатель диагностики аварий 1С. По нему можно отделить ошибку обмена от неполадки сервера, СУБД или базы.

Права проверяйте от имени службы 1С

Сообщение «Каталог обмена информацией не существует» не доказывает, что папки действительно нет. Администратор может открыть её без проблем, а служба 1С — получить отказ.

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

Для сетевой папки прав на вкладке «Безопасность» недостаточно. Служебной учётной записи также нужен доступ к общему ресурсу. Если сервер запрашивает отдельные имя и пароль, добавьте их через «Панель управления → Диспетчер учётных данных → Учётные данные Windows».

Создайте контрольный файл именно от имени службы. Файл от администратора подтверждает права администратора — и ничего не говорит о фоновом задании.

На Linux сервер 1С обычно обращается к каталогу под пользователем usr1cv8. В инструкции Less-IT по ошибке «Каталог обмена информацией не существует» сетевую папку монтируют с UID этого пользователя.

UID хранится в /etc/passwd. Узнать его можно командой:

getent passwd usr1cv8

Для работы с CIFS установите пакет cifs-utils. В Ubuntu команда выглядит так:

sudo apt install cifs-utils

В CentOS:

sudo yum install cifs-utils

Создайте точку монтирования и подключите сетевой ресурс с UID пользователя сервера 1С. Адрес сервера, каталог, имя пользователя и UID замените своими:

sudo mount -t cifs //fileserver/exchange /mnt/1c-exchange \
 -o username=exchange_user,uid=993

Не пишите пароль прямо в команде или /etc/fstab: он останется в истории либо в доступном для чтения файле. Поместите пароль в отдельный файл учётных данных и закройте доступ к нему для всех, кроме root.

Чтобы ресурс подключался после перезагрузки, добавьте запись в /etc/fstab. Параметр nofail даст Linux загрузиться при недоступном файловом сервере. Сам обмен до подключения каталога работать не будет.

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

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

Сверьте релизы обеих конфигураций

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

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

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

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

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

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

Повреждённый пакет формируйте заново

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

Материал 1C Expert об ошибке формата потока называет три возможные причины недописанного файла: прерванную запись, сетевой сбой и аварийное завершение rphost. Принимающая база находит такой пакет, но не может прочитать его структуру.

Бинарный пакет не чинят в HEX-редакторе. XML тоже не стоит сохранять через редактор, который меняет кодировку. Сформируйте новый пакет в базе-источнике.

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

Если переносите файл вручную, переносите копию. Оригинал оставьте на месте до конца проверки.

Проблемный объект ищите по журналу

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

Откройте подробности события в журнале регистрации. По разбору 1C Expert там может быть UUID или название проблемного объекта. Найдите объект в базе-источнике и проверьте обязательные реквизиты.

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

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

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

Сброс всей регистрации особенно рискован. По разбору 1C Expert после такого сброса система помечает изменёнными все объекты и готовит их к повторной выгрузке. Это уже не восстановление одного сорванного этапа.

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

Порядок восстановления обмена

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

1. Снимите резервные копии обеих баз и сохраните проблемный файл.
2. Остановите автоматические повторы обмена.
3. Найдите последнюю ошибку и предыдущий успешный этап в журнале регистрации.
4. Проверьте чтение и запись каталога от имени служб обеих сторон.
5. Сверьте релизы конфигураций и версии правил обмена.
6. Сформируйте повреждённый пакет заново в базе-источнике.
7. Найдите проблемный объект по UUID или имени из журнала.
8. Исправьте исходные данные и зарегистрируйте только нужный объект.
9. Запустите один контрольный обмен вручную.
10. Возвращайте расписание после проверки результата в принимающей базе.

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

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

Если не помогло

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

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

Чтобы не повторилось

Настройте резервное копирование баз 1С и регулярно разворачивайте копии в отдельном контуре. Наличие файла бэкапа ещё не означает, что база из него откроется.

Для самого обмена оставьте четыре контрольные точки:

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

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