А можно поподробнее про корни проблем поговорить?
Сам этой темой очень интересуюсь в свете рассмотрения внедрения 1с в своей конторе.
Я так понимаю:
По тем данные, которые меняются всегда только в одном узле и передаются в удаленные узелы только для просмотра блокировок возникать не должно. Если конечно в удаленном узле механизмы работы с базой "нормальные" (отсутствие длительных блокировок и транзакций)
По тем данным, которые могут меняться в разных узлах(или как тут писали "разные части взаимосвязанных данных вводятся в разных узлах"), должны быть предприняты определенные меры:
1) Или на уровне логики обмена(например, тупо перезаписать значение в таблице - это тоже правило логики обмена, но можно и алгоритм накрутить(приоритеты и т.д.)
2) Или на уровне логики приложения(исключение таких одновременных исправлений с целью поддержания целостности данных. Например, пока за документ отвечает подразделение находящееся в одно узле, никакой другой узел не может редактировать его или информацию с ним связанную. Подразделение сделает свое в документе, передаст документ в другой узел(это изменение тоже придет по обмену), там смогут править и т.д.)
Применительно к "отгрузка вводится в одном узле, а оплата - в другом узле." не должно быть такого, что отгрузка и оплата производились по одному документу и этот документ был доступен к редактированию в 2 узлах одновременно. Можно создать 2 документа(накладная и счет), счет передать для обработки в другое удаленное подразделение там оплатят, а тут отгрузят. Потом счет можно обратно передать вместе с платежом и т.п.

Если этого не сделать, то и блокировки неизбежны и целостность данных пострадает.

Подобное есть в 1с с УРБД?
По идее за 2 пункт УРБД не должно отвечать, это должно быть заложено в логике приложения и поддержано в конфигурации(дополнительные поля в документах и т.д.)

"Последовательность" и размеры сообщений это проблемы нижнего уровня обмена.
Можно поподробнее про них?
Хотя тут все должно работать вообще как часы.(отправка, подтверждение, перезапросы и т.д.) Сообщения, кстати, паковать можно перед отправкой и распаковывать на месте.

fankВот, нарыл.
Во-во. Посмотрите сколько там сделано доработок на уровне обмена, логики приложения и данных для корректной работы в распределенной системе.
Это я к тому, что скорее всего в голой 1с всего этого нет. И чтобы все красиво работало придется либо самим вот так дорабатывать(при наличии специалистов) либо красиво заплатить таким как itrp

AleksandrM Вопрос "что значит адаптация 1С к использованию механизма репликаций SQL" ?
Поделитесь опытом,пожалуйста, кто использовал репликации SQL в работе с 1С.

Опытом не поделюсь, но по материалам softpoint.ru и других источников в Инете на эту тему, я понял основной смысл следующий:
1) Необходимо иметь механизм получения соответствия таблиц и полей конфигурации таблицам и полям MSSQL. Все большинство остальных пунктов подразумевают наличие этого.
2) Для использования репликации MSSQL необходимо преодолеть ограничения 1с на возможность добавления собственных полей в таблицы данных 1с, полей не описанных конфигурацией. Слово "собственных" относится в первую очередь к системным полям, добавляемых системой репликации MSSQL. Это достигается путем нехитрых механизмов подмены представлений данных и системных процедур MSSQL. Но обязательно нужно учесть, чтобы эти "механизмы" учитывали и отслеживали возможные дальнейшие изменения в конфигурации(полей таблиц).
3) И вроде как все про "адаптацию" 1с. Можно использовать репликации от MSSQL.
Для нормальной работы в распределенной системе останется дело за "малым", а именно "доработка" 1с для использования репликаций от MSSQL
a) Написать систему управления логикой репликаций(публикации, подписчики, что, кому, как отправлять и т.д.) Bceм этим конечно можно управлять в ручную в MSSQL, а можно и красиво расписать в виде отдельного модуля на 1с(тем более что, в 1с логику репликаций можно расписывать через объекты конфигурации)
б) Учесть в репликациях распостранение изменений в конфигурации(определения таблиц) в разных точках. Учитывая описанное выше, та еще проблема. Можно конечно все вручную отслеживать и менять.
в) Заложить в бизнес-логику конфигурации работу над объектами бизнес-логики в распределенной системе. Без этого никакие репликации от MSSQL не помогут.
г) Реализовать разрешение конфликтов репликаций.
д) Оптимизация кода приложения для исключения длительных блокировок и т.п.
и т.д.

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

А чтобы узнать конкретные цифры, можно наверно обратиться в softpoint.ru, выкатив им конкретное ТЗ по репликациям 1с.