Собственно, суть: выгрузка из самописки (ОУ) в бухгалтерию, причем из первой во вторую сразу несколько документов переносятся в документ одного вида ("Операция, введенная вручную"). Бухия ни разу не тронутая, девственная и тп.

Внимание, вопрос: что можно использовать в качестве уникального идентификатора при таком переносе?

Уникальный идентификатор.

новый уникальй, сохраненный в документе и присвоенный операции в бухе

+(1) Который уже существует.

Уникальный идентификатор ссылки. Вероятность совпадения "крайне мала" (с).

(2) а повторения не будет?

(3) херню сказал

(4) см (6) к тебе тоже относится... получил я такую вероятность - когда сливал 2 объекта по 10000 элементов в 1 общий

(6) Да ты что!!!

(6) Не груби

(7) Не повезло...

(7) я еще ни разу не попался на таком
бульбень тогда херь какую нить из вид + номер+ дата + время и все в 36 разрядном виде )

(10) ... с руками

(11) ну это канеш вариант - типа в коммент пихать "ЗначениеВСтрокуВнутр" или что-нить такое

(12) тебе с ДНК не повезло, никто же об этом не кричит на весь форум

Я бы использовал GUID (Глобальный уникальный идентификатор).
И еще потребуется создать регистр в котором отслеживать какие исходные документы соответствуют каким операциям.

(14) в принципе, в ОУ проблем нет, вопрос, насколько это затронет все остальные процессы в конфе

никакие процессы это не затронет и даже обновляться будет нормально.
При этом конечно имеется в виду, что в базе приемнике хранится XML представление GUID

(16) эмм, а что имеется в виду под ГУИД? в смысле, как его получить средствами 1С?

(17) Не поверишь, так же как УникальныйИдентификатор.

Например вот так :
XML_ПредставлениеGUID = XMLСтрока(СсылкаНаОбъект);

(19) спс, щас попробую

(20) Секундочку, вроде бы оно у тебя судя по 7 пересеклось.
Кстати, пересечение возможно, когда гуиды ставят шаловливыми ручками...

(21) да, пересеклось, думалось, что будет уникально, но при попытке УстановитьСсылкуНового оч сильно ругалось и материлось...

ЗЫ, ни одного ууида из перечисленных руками не ставилось...

Про (19) сказано еще в (1). Правда, автор сказал, что это херня.

(22) Что и требовалось доказать. Пересечение возникло при установке ссылки руками...

(24) читай постскриптум в (22) до полного просветления...

в ОУ загрузили 2 справочника по 10000 элементов...

после этого запустили перенос в один справочник в БП

в БП при создании устанавливали ссылку элемента из ОУ...

(23) читай второе предложение в (13) до полного просветления

(25) У разных элементов метаданных могут быть одинаковые уникальные идентификаторы. Но опять же только в том случае, если их ставили руками

(27) я не собираюсь тебя уговаривать и в чем-то оправдываться...

(19) почему-то XMLСтрока тот же УУИД возвращает...
короче, все извраты нафиг, ЗначениеВСтрокуВнутр рулит...

(28) Как будто ЗначениеВСтрокуВнутр вернет другое...

(29) ну ты хоть посмотри сначала, советчик ***

(28) Смотри внимательно - часто бывает, что отличается только одна буква

(29) Забей, полудурок он и есть полудурок.

(31) я канеш оч сильно извиняюсь, но: http://s017.radikal.ru/i429/1202/ee/03b38bc8c687.jpg

Код: Стр = СокрЛП(Расход.УникальныйИдентификатор()) + Символы.ПС + СокрЛП(XMLСтрока(Расход.Ссылка)) + Символы.ПС + СокрЛП(ЗначениеВСтрокуВнутр(Расход));

(32) канеш забей, даром, что полудурок на тебя из зеркала смотрит

Используй один и тот же GUID что в источнике что в приемнике и не будет проблем с синхронизацией УстановитьСсылкуНового() тебе поможет.

а код обработки можно посмотреть

(29) Емнип, значениевнутр вернет 2 идентификатора.
Второй - гуид в форме хранения скуля.
Первый, емнип, метаданного, но зуб не дам.

//Определяем есть ли документ в системе
   докСсылка = Документы.ДокуменПриемник.ПолучитьСсылку(Новый УникальныйИдентификатор(ТаблицаДанных.Ид)); //ТаблицаДанных.Ид - текстовое представление GUID источника
   Запрос = Новый Запрос;
   Запрос.Текст =
   "ВЫБРАТЬ
   |    ДокуменПриемник.Ссылка
   |ИЗ
   |    Документ.ДокуменПриемник КАК ДокуменПриемник
   |ГДЕ
   |    ДокуменПриемник.Ссылка = &Ссылка";
   Запрос.УстановитьПараметр("Ссылка",докСсылка);
   Если Запрос.Выполнить().Пустой() Тогда // Нету, создаем новый устанавливаем ссылку
       ДокументОбъект = Документы.ДокуменПриемник.СоздатьДокумент();
       ДокументОбъект.УстановитьСсылкуНового(докСсылка);
   Иначе //Есть будем работать с найденным документом
       ДокументОбъект = докСсылка.ПолучитьОбъект();
   КонецЕсли;

У меня указанная схема уже пол года молотит нареканий небыло

(33)

СокрЛП(Расход.УникальныйИдентификатор())
СокрЛП(XMLСтрока(Расход.Ссылка))

это одно и тоже только второе набивать быстрее
и лучше просто
XMLСтрока(Расход.Ссылка)

(38) А как быть если база приемник была ранее получена путем копирования базы источника.
и сответственно в ней много повторяющихся GUIDов

Они не могут совпадать по определению это одни и те же элементы.

Используйте конвертацию 2.0 быстро и красиво.
И по внутренним идентификаторам умеет синхронизировать.
Указанную обработку на конвертации можно за 1 час с чайком намолотить.

Они не могут НЕ совпадать именно потому, что на момент копирования это были одни и теже объекты.
А затем эти объекты могли быть переименованы - т.е. по смыслу стать другими.

(41) Тогда это одни и теже данные.

+ 45 с учетом 44 - тогда ССЗБ

(44) Регистр соответствия GUID-ов Вам в помощь.

(45) С точки зрения GUID - одни и теже, а по смыслу может быть разные.
например был контрагент Пупкин.
Скопировали базу и мудрая девушка переименовала Пупкина в Газпром.
А в первичной базе Пупкин остался Пупкиным - Вы на него вешаете наладные и оплаты пупкина.
В тоже время в базе копии на него вешаются накладные Газпрома.
Потом Вы делаете обмен по GUID и в лучшем случае у Вас Пупкин пропадает и появляется Газпром, а в худшем на Пупкина вешаются все долги Газпрома.

(48) И какой вывод?

(47) :)

(49) Вывод такой.
По GUID синхронизировать очень хорошо, НО
Если синхронизируются не пустые базы, то прежде чем запускать обмен надо проверить, что синхронизируемые по GUID объекты семантически идентичны (т.е. обозначают одно и тоже).
Я напимер, писал обработочку которая, которая находила одинаковые GUID в обеих базах и сравнивала их типы и наименования.
В случае их совпадения вс Зер гуд. Иначе - разбираться.

(51) А если после (51) пользователь сделал (48)?

(51) ага и в случае не совпадения создать новый элемент и
(47) :)

(52) В этом случае уже должна работать бизнес логика заложенная в обмене. Какая база является первоисточником данных по контрагентам, кто может их переиминовывать, нужно ли спрашивать разрешение на переименование при загрузке и т.п.

(54) Тогда к чему пост (48). То, что изложено в (54) должно быть всегда (хотя и не все).

+(55) А бизнес-логика должна быть при работе с базой (например, нельзя переименовывать контрагента).

(55) К тому что 48 - предполагает ручное разбирательсво которое никак не запрограмировать.
а 54 - это уже после выполнения ручного разбирательства и сопоставления контрагенов

Облин, у кого-то GUID-ы пересеклись, причём он утверждает, что они сами по себе так сделали... Ну-ну. Математику принципиально игнорируем :)

(57) Зачем эти сложности?
Один раз пишется обработка которая в базе приемнике в случае совпадения GUID  с базой приемника перепривязываются на другие
назначенные им в источнике
Пример:

  Источник:           Приемник

Петров 1      Иванов 1
   Иванов 2      Петров 2
Обработали
   Пертров 1 Иванов 2
   Иванов  2 Петров 1
Все

(60) В некоторых случаях надо препривязывать, а в некотрых не надо.
Каждый раз (до первичной синхронизации) надо смотреть.

Смешно. У автора ИЗ в профиле.