Вот здесь - http://www.binomsoft.ru/product/transfer/ - есть довольно удобная программа для синхронизации любых баз. Гибкая настройка позволяет настраивать профили переноса любых видов данных (справочники, документы), учитывая зависимости. При импорте данных есть возможность настройки вызова определенных хранимых процедур в базе для более утонченной обработки синхронизации. Проблема со слиянием отредактированных (измененных) документов решается.

Вот описание алгоритма КОМПЛЕКС из документации по продукту:

Обработка схемы КОМПЛЕКС

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

Есть и другой аспект у данного вопроса. Обычно в бухгалтерских системах документы такого типа как расходная накладная служат для изменения состояния некоторых учетных регистров, например баланса платежей и остатков на складе. Следовательно, документ при вводе должен произвести некоторые действия, которые приводят к изменению учетных регистров. Часто такие действия выделяют в специальные хранимые процедуры, которые выполняются на сервере БД. При передаче документов в БД бухгалтерской системы логично предположить, что эти действия также должны выполняться, так как это аналогично вводу документа в данной системе. Однако ситуация гораздо более сложная, чем кажется на первый взгляд. Дело в том, что здесь мы сталкиваемся также с вопросами передачи уже существующих, но измененных данных (например, накладная уже была передана, но затем в спецификации был удален или изменен ряд строчек с товарами). При последующей передаче необходимо корректно обработать все изменения в документе с коррекцией данных в учетных регистрах (посредством вызова соответствующих хранимых процедур). Для некоторого упрощения и автоматизации в технологию обработки документов было введено понятие "проведенности" документа (бухгалтерский термин). Считается, что документ "проведен", когда выполнены все сопутствующие с ним действия (выполнены проводки, списан товар и т.д.). Также считается, что документ "отложен" ("не проведен", "откатан"), когда документ существует в базе данных, однако действия, сопутствующие ему, не произведены. Обычно в бухгалтерских системах в таблицах, которые хранят документы, существуют специальные поля, которые индицируют статус документа (его "проведенность").

Учитывая вышеизложенные соображения, схема "Комплекс" функционирует следующим образом:
1. В зависимости от типа процесса основной таблицы (обычно это "Замещение данных") происходит передача данных для строки основной таблицы. При этом сначала выполняется оператор SQL (Insert, Update). Если оператор завершился без ошибки, затем выполняется ассоциированная с ним команда (OnInsert, OnUpdate). Если команда завершилась успешно, то происходит переход к обработке подчиненной таблицы. Если нет, то в случае оператора Update выполненные действия отменяются, и трансферт переходит к обработке следующей строки. При ошибке команды для оператора Insert выполняется команда CallBack (если она определена). Это может понадобиться для сброса флага "проведенности" для текущей строки в таблице приемника. Далее выставляется специальный флаг и происходит переход к обработке подчиненной таблицы, однако в этом случае для нее не будут выполняться ассоциированные с операторами команды (так как документ считается "не проведенным").

2. Если для основной таблицы определен флаг F (флаг "проведения") для какого-либо поля, и значение этого поля в источнике больше, чем в приемнике, то выполняется команда OnInsert. Подчиненная таблица обрабатывается дважды. Сначала данные в источнике и приемнике приводятся во взаимное соответствие без выполнения ассоциированных команд. Затем для каждой строки субтаблицы приемника выполняются только команды OnInsert. Если обработка субтаблицы не завершилась успешно, то происходит отмена команды для основной таблицы, а также вызывается команда CallBack для сброса флага "проведенности".

3. Если для основной таблицы определен флаг F (флаг "проведения") для какого-либо поля, и значение этого поля в источнике меньше, чем в приемнике, то выполняется команда OnDelete. Подчиненная таблица обрабатывается дважды. Сначала для каждой строки субтаблицы приемника выполняются только команды OnDelete. Если обработка субтаблицы не завершилась успешно, то происходит отмена команды для основной таблицы, а также вызывается команда CallExec для восстановления флага "проведенности". Затем данные в источнике и приемнике приводятся во взаимное соответствие без выполнения ассоциированных команд.

4. Далее проверяются значения полей в основной таблице, для которых установлен флаг T (триггер). Если значение поля изменилось, то это служит сигналом к тому, что всю строку (блок данных) нужно удалить и ввести заново. Таким образом, если строка уже существовала в таблице приемника, то происходит сначала удаление данных из субтаблицы с вызовом ассоциированных команд, а затем удаление данной строки. Затем вся информация передается заново с выполнением ассоциированных команд.

5. Обработка субтаблицы выполняется в соответствии с указанным типом процесса (обычно это "Полное сравнение"). Для каждой строки субтаблицы выполняются соответствующие операторы и ассоциированные с ним команды. При этом все произведенные действия записываются во временный буфер. Для каждой строки также проверяются значения полей с флагом T (триггер).

6. Если в процессе обработки субтаблицы оператор SQL возвращает ошибку для какой либо строки, то все ранее произведенные действия отменяются, используя информацию из временного буфера (все введенные строки удаляются, все удаленные или измененные - восстанавливаются). Также отменяются все выполненные ассоциированные команды (для этого определяются обратные команды ReInsert, ReUpdate, ReDelete). Обработка подчиненной таблицы прекращается, а для строки основной таблицы также отменяются все произведенные действия. Далее происходит переход к следующей строке основной таблицы.

7. Если происходит ситуация, когда для какой-либо строки субтаблицы ассоциированная команда не может быть выполнена (например, нет остатка товара на складе для спецификации расходной накладной), то дальнейший сценарий зависит от типа оператора SQL для главной таблицы.

· Если это был SQL Insert (ввод новой строки), то все выполненные ранее команды в субтаблице (не операторы SQL) отменяются, используя данные во временном буфере. Обработка субтаблицы не прекращается, однако все последующие строки обрабатываются без вызова ассоциированных команд. При завершении обработки подчиненной таблицы также отменяются выполненные ассоциированные команды для текущей строки основной таблицы, а также вызывается команда CallBack для сброса флага "проведенности".

· Если для основной таблицы был выполнен оператор SQL Update, то все произведенные действия в субтаблице отменяются (включая SQL операторы). Обработка подчиненной таблицы прекращается, а для строки основной таблицы также отменяются все произведенные действия. Далее происходит переход к следующей строке основной таблицы.

Ну, я в целом с Вами согласен. В общем (теоретическом) случае проблема слияния модифицированных документов - трудна для решения, особенно если документ имеет сложную структуру хранения. И не в 100% случаев удается ее решить.

Что касается всяческих репликаторов, в том числе и от Sybase, то их проблема в том же, что и их недостатки - а именно в чрезвычайной универсальности, не позволяющих доостаточно просто решать специфические задачи по обмену документами...

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

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