Обмен между базами 1С остановился: ищем, где он ломается

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

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

Что проверить до поиска сложных причин

Первые проверки занимают пять минут и отсекают половину ложных тревог.

• ✅ Флажок «Синхронизация данных» включён в Администрирование → Синхронизация данных в обеих базах.
• ✅ Префиксы баз разные. Одинаковый префикс даёт совпадающие номера документов и путаницу при сопоставлении.
• ✅ Синхронизация запускалась. Посмотрите дату последнего обмена в списке настроек: если она застыла неделю назад, проблема в расписании, а не в данных.
• ✅ Обмен идёт в обе стороны. Бывает, что отправка проходит, а загрузка на другой стороне ни разу не запускалась.
• ✅ Пароль пользователя, под которым подключается база-корреспондент, не менялся. Сменили пароль — обмен через интернет перестаёт подключаться без явной подсказки в интерфейсе.

Сеть, общая папка и FTP: почему база не видит каталог обмена

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

Файловый вариант против клиент-серверного

Главная ловушка — от чьего имени работает обмен.

В клиент-серверной базе файлы пишет не ваш компьютер, а сервер 1С. Учётная запись службы (часто это USR1CV8 или доменная служебная учётка) должна иметь права на чтение и запись в каталог обмена.

Что исправить

1. Укажите путь в формате UNC: \\server\exchange\filial1, а не Z:\filial1. Подключённые диски существуют только в сеансе пользователя, служба их не видит.
2. Выдайте учётной записи службы сервера 1С права «Изменение» на папку и на общий ресурс.
3. Проверьте путь с самого сервера 1С: откройте его в проводнике под той же учётной записью.
4. Для FTP проверьте логин, пароль, порт и пассивный режим. Многие межсетевые экраны пропускают только пассивный режим.
5. Убедитесь, что антивирус не удаляет и не блокирует архивы обмена. Добавьте каталог в исключения.

Блокировки и занятые сеансы во время обмена

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

Как распознать

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

Что делать

1. Перенесите расписание обмена на время, когда в базе нет тяжёлых операций. Для филиалов часто хватает обмена каждые 15–30 минут днём и полного ночью.
2. Не запускайте закрытие месяца и групповое перепроведение одновременно с синхронизацией.
3. Посмотрите активные сеансы: в клиент-серверной базе — в консоли администрирования серверов 1С, в списке сеансов информационной базы; в любой базе — в Администрирование → Обслуживание → Активные пользователи.
4. Если сеанс пользователя обмена «завис» после обрыва связи и держит блокировки, его можно завершить.

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

Особенность файловой базы

В файловой базе регламентные задания выполняет один из открытых клиентских сеансов. Если вечером все закрыли программу, обмен по расписанию просто не запустится. Это не ошибка, а свойство файлового режима. Решение — держать на компьютере открытый сеанс 1С, перейти на клиент-серверный вариант или запускать обмен вручную.

Правила регистрации и конвертации: обмен проходит, а данных нет

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

Почему так бывает

• 📋 Фильтр в настройках обмена. Задан отбор по организациям, складам или дате начала. Документ вне отбора не регистрируется к отправке.
• 📋 Дата начала обмена. Документы раньше этой даты не выгружаются, даже если их перепровести.
• 📋 Дата запрета загрузки. В базе-получателе установлена дата запрета загрузки данных из других программ. Документ закрытого периода отклоняется, это видно в предупреждениях.
• 📋 Объект не входит в состав обмена. Не всё синхронизируется: часть справочников и регистров передаётся только в одну сторону или не передаётся совсем.
• 📋 Ошибка сопоставления. Получатель не нашёл существующий элемент и создал дубль. Классика — два одинаковых контрагента, отличающихся КПП или пробелом в наименовании.
• 📋 Изменённые правила конвертации. Если обмен настроен на доработанных правилах (например, из «Конвертации данных»), обновление конфигурации могло их перезаписать.

Как проверить

1. Откройте настройку обмена и посмотрите параметры отбора: организации, дату начала, режим выгрузки.
2. Проверьте состав отправляемых данных из формы настройки синхронизации: там видно, какие объекты зарегистрированы к отправке и ждут следующего сеанса.
3. Если нужный документ не зарегистрирован, а под отбор подпадает, его можно зарегистрировать вручную в той же форме и запустить обмен повторно.
4. Дубли справочников разберите командой сопоставления объектов в настройке обмена, а не удалением в базе-получателе. Удалённый элемент придёт снова при следующем изменении.
5. Посмотрите предупреждения синхронизации: непроведённые документы, отклонённые по дате запрета, конфликты изменений.

Размер пакета, таймауты и веб-сервер

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

Типичные проявления

Что сделать

1. В настройках канала почты и FTP задайте ограничение размера сообщения. Программа разобьёт пакет на части, которые пропустит сервер.
2. Для обмена через интернет проверьте лимиты веб-сервера, на котором опубликована база. У IIS по умолчанию ограничен размер тела запроса (параметр maxAllowedContentLength, около 30 МБ), у Apache и nginx — свои директивы на размер и таймаут.
3. Если пакет огромный разово, выполните первую выгрузку через общую папку или дождитесь ночи, затем верните обычный канал.
4. Не регистрируйте к обмену лишнее: перепроведение года в базе-источнике регистрирует к отправке все перепроведённые документы.

Разные версии конфигураций и платформы

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

Что проверить

• 🔄 Версия формата обмена. Типовые конфигурации обмениваются через универсальный формат EnterpriseData. Новый релиз может перейти на новую версию формата, а старый корреспондент её не знает. Обычно хватает обновить отставшую базу до актуального релиза.
• 🔄 Пара «конфигурация — конфигурация». Обмен поддерживается только между определёнными продуктами и релизами. Если обновили только Бухгалтерию, а УТ осталась на релизе годовой давности, синхронизация может перестать проходить.
• 🔄 Платформа. Для обмена через интернет обе стороны и веб-сервер должны работать на поддерживаемых конфигурацией версиях платформы. Номер версии платформы смотрите в окне «О программе» каждой базы; он должен быть не ниже требуемого релизом конфигурации.
• 🔄 Незавершённое обновление. Если после обновления не прошла обработка данных (отложенное обновление), часть механизмов, включая обмен, работает с ошибками. Проверьте результаты обновления в разделе Администрирование → Обслуживание.

Правило для обновлений

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

Журнал регистрации и регламентные задания: как найти точную причину

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

Журнал регистрации

1. Откройте Администрирование → Обслуживание → Журнал регистрации.
2. Задайте отбор по событиям: в списке событий найдите группу событий обмена данными и отметьте её.
3. Ограничьте период временем неудачного запуска.
4. Отфильтруйте по уровню «Ошибка». Комментарий записи обычно содержит полный текст: имя объекта, на котором остановилась загрузка, и причину.

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

Регламентные задания

Автоматическая синхронизация запускается регламентным заданием по сценарию синхронизации.

1. Откройте Администрирование → Обслуживание → Регламентные операции → Регламентные и фоновые задания.
2. Найдите задание синхронизации данных и посмотрите, включено ли оно, расписание и результат последнего выполнения.
3. Сообщение «Выполнено с ошибкой» раскрывается двойным щелчком — там текст исключения.
4. В клиент-серверной базе убедитесь, что для информационной базы на сервере не установлена блокировка регламентных заданий. Её ставят в свойствах базы в консоли администрирования серверов, и иногда забывают снять после обслуживания или копирования базы.

Распределённая база (РИБ): сбои, которых нет в обычном обмене

Распределённая информационная база — это главный узел и подчинённые, у которых одна и та же конфигурация. У РИБ свои болезни.

Номера сообщений

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

Что делать:

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

Изменения конфигурации

В РИБ конфигурацию меняют только в главном узле. Подчинённый получает изменения с очередным сообщением обмена.

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

Чем РИБ отличается при диагностике

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

Частые вопросы