Ситуация очень проста и однозначна (с точки зрения механизмов УРБД). Предположим, есть центральная Ц и две периферийных - А и Б.
1. Меняются периодические реквизиты в А. Они передаются в Ц только в составе объектов: изменение одного элемента истории толкает в выгрузку всю историю всех реквизитов элемента.
2. Ц получает измененный объект - и должна его раздать всем остальным периферийным. Отправляет. И пока от Б не придет квитанция сеанса, маркер изменений этого объекта остается в 1SUPDTS центральной базы.
3. В базе А продолжается работа. Создан новый элемент истории реквизита. Весь объект со всей историей - опять в выгрузке.
4. Квитанция от Б не пришла. Зато пришла свежая выгрузка из А. И там объект - маркер изменений которого ждет в Ц той квитанции. "Коллизия !" - говорит Ц. И не принимает объект из А. Вместо этого создается маркер изменений этого объекта для А. В результате в следующей выгрузке для А Ц отправляет свою версию объекта. Которую А обязана принять.

Другой вариант возникновения коллизии - в Б меняется история другого реквизита того же объекта. Результат - тот же. Даже если квитанция из Б пришла вовремя (до получения след. выгрузки из А).

С коллизиями первого типа можно справляться тщательной организацией последовательности обменов (в простых случаях). Для более сложных - могут подойти внешние (по отношению к 1С) средства обработки 1SUPDTS. А могут и не подойти.
Тогда остается только менять логическую структуру базы - освобождая реализацию важных функций от использования периодических реквизитов.

The EclipsEpail,

Это все верно, но есть один нюанс. При обмене с базами никто не работает.

Верно ли я понимаю это утверждение, что существует время, когда:
- во всех базах останавливается работа,
- делаются выгрузки из всех периферийных,
- заливаются в центральную,
- делается раздача изменений из центральной во все периферийные,
- изменения принимаются последними
- и только затем возобновляется работа?

"Коллизия" - получение ЦБ из ПБ объекта, маркер изменения которого в ЦБ уже есть (или еще есть).
Такой маркер будет существовать, пока не придут квитанции сеансов (в которых объект раздавался в ПБ) от ВСЕХ периферийных. Этого можно добиться, если делать два полных обмена с каждой ПБ. (в первом будут изменения, во втором - только квитанции).
Но должен помочь более простой вариант, через соблюдение последовательности обмена:
принимать в ЦБ изменения от ПБ-источника проблемного справочника в последнюю очередь - только после того, как файлы изменений будут приняты от всех остальных ПБ.