Как зарегистрировать данные для синхронизации между базами 1С
Содержание
Чтобы документ ушёл в другую базу, он должен быть зарегистрирован к обмену — то есть попасть в служебную таблицу регистрации изменений по нужному узлу. При штатной настройке синхронизации это происходит само: вы меняете документ, платформа ставит в очередь на выгрузку. Проверить и настроить это можно в разделе Администрирование → Синхронизация данных.
Разберём, как устроен этот механизм в 1С 8.3, где смотреть состав плана обмена, чем отличается автоматическая регистрация от ручной и что делать, когда конкретный документ упорно не выгружается в соседнюю базу. Пути указаны для конфигураций на БСП — «Бухгалтерия предприятия 3.0», «ЗУП 3.1», «Управление торговлей 11» — в интерфейсе «Такси».
Что такое таблица регистрации изменений
Основа обмена — план обмена (объект конфигурации) и его узлы. Узел — это запись об одной из баз, участвующих в синхронизации: ваша база и каждый корреспондент. У плана обмена есть состав — список объектов метаданных (справочники, документы, регистры), которые через него передаются.
Когда объект из состава плана меняется, платформа пишет строку в таблицу регистрации изменений — отдельно для каждого узла, которому этот объект положено отправить. Фактически это очередь: «объект X, узел Y, номер сообщения». При следующей выгрузке попавшие в очередь объекты уходят корреспонденту, а строки снимаются после подтверждения приёма.
Регистрация — это не сама передача. Документ может быть зарегистрирован, но ещё не выгружен: выгрузка произойдёт в ближайшем сеансе синхронизации (по расписанию или вручную).
Пока объект не зарегистрирован по узлу, он для обмена не существует — сколько сеансов ни запускай, он не уйдёт. Именно поэтому большинство проблем «не передаётся документ» сводятся к отсутствию строки в этой таблице.
Важная деталь — нумерация сообщений и квитирование. Каждому исходящему сообщению обмена платформа присваивает номер. Строка регистрации помечается этим номером, но из таблицы не удаляется сразу. Она снимается только после того, как корреспондент пришлёт ответное сообщение — подтверждение, что данные приняты. Это защита от потери данных: если сообщение не дошло, объект при следующем сеансе уйдёт повторно.
Из этого следует неочевидный вывод: если обмен «ходит», но один из узлов не отвечает квитанцией, очередь по нему будет только расти, а одни и те же документы — выгружаться снова и снова. Разбирать такую ситуацию нужно со стороны приёмника: доходят ли до него сообщения и формирует ли он ответные.
Настройка узлов и состава плана обмена
Все действующие настройки собраны в одном месте: Администрирование → Синхронизация данных → Настройки синхронизации данных. Здесь виден список подключённых корреспондентов, дата последней синхронизации и кнопка запуска обмена.
Что проверить при первичной настройке:
- 🔹 Префиксы баз различаются. Если у двух баз одинаковый префикс, номера документов столкнутся и начнутся коллизии.
- 🔹 Дата запрета загрузки/выгрузки не отсекает нужный период. Её легко выставить и забыть.
- 🔹 Настройки выгрузки по организациям/складам — в большинстве типовых правил можно ограничить обмен конкретной организацией. Документ по «лишней» организации не зарегистрируется.
- 🔹 Расписание обмена включено, если нужна автоматическая синхронизация в фоне (регламентное задание).
Сам состав плана обмена (какие объекты вообще участвуют) в типовых конфигурациях закрыт настройками синхронизации и правилами обмена — его не редактируют вручную в пользовательском режиме. Менять перечень передаваемых объектов стоит только через настройку правил, а не правкой конфигурации, иначе обновление типовой затруднится.
При первом подключении корреспондента создаётся узел и выполняется начальная выгрузка. Для РИБ она оформляется как начальный образ — полная копия базы для подчинённого узла; загрузив образ, филиал сразу готов к обмену. Для универсального обмена начальная синхронизация переносит накопленные данные за выбранный период. Пока начальная выгрузка не завершена и не подтверждена приёмником, обычная регистрация изменений по этому узлу работать корректно не будет — сначала базы должны «познакомиться».
Не создавайте второй узел на ту же базу, если синхронизация «сломалась». Лишние узлы плодят дубли и путаницу в регистрации. Сначала разбираются с существующим узлом.
Как работает автоматическая регистрация изменений
В типовой синхронизации регистрация полностью автоматическая. Работает она по двум правилам:
- Объект входит в состав плана обмена.
- Объект проходит правила регистрации — условия, по которым определяется, какому узлу он нужен (например, документ отгрузки регистрируется только по тому узлу, с чьей организацией он связан).
Современные типовые базы обмениваются по формату EnterpriseData (универсальный формат). Правила конвертации и регистрации в нём описаны в расширении или в самой конфигурации; пользователь их не трогает. От вас требуется только корректно заполнить документ — организацию, склад, контрагента, — чтобы правило понимало, в какой узел его направить.
Старые схемы на правилах обмена (форматы КД 2.1) работают так же по сути: есть ПРО — правила регистрации объектов, которые и решают, по какому узлу регистрировать изменение.
Если вы создали документ «задним числом» за период, закрытый датой запрета выгрузки, автоматическая регистрация его пропустит. Такой документ придётся регистрировать вручную (см. ниже) и снимать/сдвигать дату запрета.
РИБ и универсальный обмен: разная логика регистрации
Понимание, какой у вас тип обмена, экономит часы при разборе проблем — потому что регистрация в них устроена по-разному.
Распределённая информационная база (РИБ). Это обмен между копиями одной и той же конфигурации — например, центральная база и филиалы. Узлы делятся на главный и подчинённые. Регистрация здесь максимально простая: в состав плана обмена входят почти все объекты, и изменение регистрируется по всем подчинённым узлам сразу. Дополнительно РИБ передаёт изменения самой конфигурации, поэтому обновлять филиалы вручную не нужно — обновление «приезжает» с главного узла.
Универсальный обмен (EnterpriseData). Это синхронизация между разными конфигурациями — скажем, «Бухгалтерия» и «Управление торговлей». Здесь регистрируется не всё подряд, а только то, что описано правилами конкретного формата, и с преобразованием структуры: документ одной конфигурации превращается в документ другой. Поэтому часть объектов РИБ-схемы в универсальном обмене просто не передаётся — и это нормально, а не ошибка.
| Признак | РИБ | Универсальный обмен |
|---|---|---|
| Базы | одинаковая конфигурация | разные конфигурации |
| Что передаётся | почти все данные + конфигурация | только объекты по правилам формата |
| Регистрация | по всем подчинённым узлам | по правилам и условиям узла |
| Обновление конфигурации | автоматически с главного узла | не передаётся, обновляют отдельно |
Прежде чем искать, «почему не регистрируется справочник», уточните тип обмена. В универсальном обмене многих объектов в составе плана просто нет — их туда и не положено включать.
Ручная регистрация и повторная выгрузка документа
Когда документ нужно отправить принудительно — он не зарегистрировался сам, или вы хотите переслать его заново после правки в базе-приёмнике, — используют повторную регистрацию.
В типовых конфигурациях на БСП для этого служит сервисная функция в настройках синхронизации — управление составом отправляемых данных. Открывается из карточки настройки конкретного обмена. Там можно:
- выбрать объект или целый тип (например, все «Реализации» за период) и зарегистрировать его к отправке заново;
- посмотреть, что сейчас стоит в очереди на выгрузку по этому узлу;
- выгрузить выбранное принудительно, не дожидаясь расписания.
Для разработчика тот же результат даёт встроенный метод: ПланыОбмена.ЗарегистрироватьИзменения(Узел, Объект). Его применяют в обработках массовой перерегистрации, когда документов много. Снять ненужную регистрацию можно ПланыОбмена.УдалитьРегистрациюИзменений(Узел, Объект).
Повторная регистрация не дублирует документ в приёмнике. При загрузке он найдётся по внутреннему идентификатору и обновится, а не создастся заново.
Частый повод для ручной регистрации — правка данных в базе-приёмнике задним числом или сбой, после которого документ в приёмнике оказался «не таким». Регистрация к отправке в базе-источнике возвращает приёмник к эталонному состоянию: источник считается ведущим, и его версия перетирает местную правку. Если приёмник вёл свои изменения осознанно, перед перерегистрацией их нужно сохранить отдельно.
Почему документ не попал в обмен
Самые частые причины и порядок проверки:
Чтобы увидеть, что реально стоит в очереди по узлу, откройте управление составом отправляемых данных по нужной настройке — там виден перечень зарегистрированных, но ещё не выгруженных объектов. Если документа там нет — значит, проблема в регистрации, а не в передаче.
Конфликты при встречном изменении данных
Коллизия возникает, когда один и тот же объект поменяли в обеих базах между сеансами обмена. Платформа не может молча затереть одну версию другой, поэтому в настройках синхронизации задаётся приоритетный узел — его изменения побеждают при расхождении.
Как с этим жить:
- 🔸 Определите главную базу для каждого типа данных. Например, справочник номенклатуры ведётся только в учётной базе, а в рознице — принимается. Тогда конфликтов по номенклатуре не будет в принципе.
- 🔸 Разграничьте зоны ответственности документами: кто создаёт реализации, кто — поступления. Одновременная правка одного документа с двух сторон — это организационная проблема, а не техническая.
- 🔸 Предупреждения о коллизиях разбирайте в журнале регистрации сразу. Накопленные конфликты сложнее распутать задним числом.
Приоритет узла решает, чья версия останется, но не отменяет потерю правок проигравшей стороны. Если важны обе — сверяйте документ вручную до следующего обмена.
Ускорение обмена при больших объёмах
На базах с историей за несколько лет первая синхронизация и разовые перерегистрации бывают тяжёлыми. Что помогает:
- Начальная выгрузка без истории. При подключении новой базы ограничьте период обмена — не тяните документы за все годы, если приёмнику нужен только текущий учёт.
- Обмен по расписанию в нерабочее время. Регламентное задание синхронизации лучше ставить на ночь или на обеденное окно, а не на пиковую нагрузку.
- Не регистрируйте лишнее вручную. Массовая перерегистрация «всех документов за три года» забьёт очередь и растянет сеанс на часы. Регистрируйте точечно — конкретный документ или узкий период.
- Контроль размера сообщения. Если одно сообщение обмена разрослось до гигабайтов, разбейте выгрузку на периоды.
Отдельная ситуация — «зависшая» очередь. Если по узлу накопились тысячи незавершённых регистраций из-за того, что корреспондент долго не отвечал квитанцией, сеанс обмена каждый раз пытается переслать всё заново и не укладывается в отведённое время. Сначала восстановите связь и дождитесь успешного квитирования на небольшом объёме, и только потом запускайте полную синхронизацию.
Не «чистите» таблицу регистрации изменений напрямую через внешние инструменты, чтобы «разгрузить» обмен. Так вы потеряете неотправленные данные без следа. Сокращать очередь нужно штатно — успешным сеансом обмена.
Если синхронизация идёт в фоне через регламентное задание, разовую принудительную выгрузку большого объёма лучше запускать вручную и в отдельное время, чтобы не наложиться на штатный сеанс.