Например, в той базе, где есть констрейнты, пометить их как NOT FOR REPLICATION. Или определить фильтры, которые запретят реплицировать потенциально кофликтующие записи.

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

дата уже есть и ее нужно просто расставить....проще говоря - из двух сделать одну, но с датой от двух
Это как?

Вам нужно почитать про conflict resolution в BOL. Определиться, какой из резолверов подходит к вашей задаче, а потом указать его при создании публикации. Тогда будет оставаться победившая запись, ну а принцип победитель/проигравший вы и задаете при выборе резолвера.

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

значение на ключ там разное
Знаете, я вашу терминологию вообще не могу понять. Ключ - это поле, определяющее уникальность записи. Если ключи у записей разные, то это РАЗНЫЕ записи. Короче, если что не получится самостоятельно, вы попробуйте более доходчиво объяснить, что есть и что нужно сделать, желательно с примерами данных.

P.S. Мож, это я туплю, конечно, но просто никто не отзывается больше...

Поскольку вы работаете с MS SQL, то вам придется смириться с мыслью о том, что если ключи у записей разные, то это разные записи. Откуда вы берете данные, из каких БД, чем обвешаны таблицы и проч. - это сиквелу по сараю абсолютно. Вы должны придерживаться определенных соглашений.

Как, по вашему, сиквел может понять, что это одна и та же запись? Интуитивно, что ли?