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

на ИТС есть неплохой мануал как для начала

К плану нужны правила, КД читай.

(1) щас гляну, спс. (2) в КД писал правила для переноса данных как их забубенить в план обмена?
Суть вопрсоа в чем - есть торговля самописная и пару бухий перепаханных. Нужно что бы номенклатура и часть документов (только приходные и расходные с фильтром по организациям) из торговли мигрировала в бухии

и вопрос на засыпку, если по УИ переносится часть элеменетов справочника не будут возникать дубли УИ?

(4) Мне консультант 1С сказал что не будет дублей. Но я им не верю...

(4) А как они физически могут возникнуть?

(6) потому что в бухию. переносится справочник товаров. кроме того в бухиях создается своя номенклатура по счетам прочих запасов.

(7) И?

Чисто физически в какой момент должны появится дубли?

(6) "Зита и Гита" смотрел? В 1Ске так-же, но немного хуже, богов-производителей больше.

Дублей по ГУИД-у быть не должно, так как ГУИД-ы уникальны (по крайней мере, так обещают создатели ГУИД-а).
А дубли по названиям - на совести пользователей, которые вводят всё куда не попадя, не задумываясь о том, что получится.

(9) в разных базах получатся разные ГУИДы. Зита и Гита здесь не проканает.

(10) В мире "ифнорматики" нет "уникальности", все случайные цифрры не "случайны".
(11) Ты знаешь как делают новые базы юЗвери?

(12) а не пофиг, даже копирование не обеспечит дублей, он просто затрет старую инфу. Был Иванов, станет Петровым

(13) Ваша правда - глюки будут - дублей ГУДов в одной таблице быть, в принципе, не может.

хоть одна приятная новость)

(10) у пользователей совести нет - доказано экспериментальным путем )

Мне вот только одно интересно - а зачем две фирмы вести в двух разных бухгалтериях ?
Чтобы интереснее было, что-ли ?
Ведь бух-то наверное один.

(17) не, бухи разные и как тушки и территориально

(18) более того, они еще и терпеть друг друга не могут)

(19) Тогда "обмен" БП->УТ нужно исключать, так как иначе "кому-то будет плохо".

(13) Затрёт он премию кому-то с таким подходом. Бухие за свои действия не в ответе, они распечатали букмажку, а дальше не их проблемка.

(20) так о том и речь, что выгрузка должна быть односторонней. То есть в торговле клепают справочники и документы, а бухия тока принимает, но я так понял на итсе почитав, что все равно назад должна идти "квитанция"

(21) Слава богу - это не ЗУП.
И премия никоим образом в УТ не попадёт.

(22) Если квитанции не будет, то каждый раз будет выгружаться всё больше и больше.
Можно ещё ручной режим использовать через КД, когда пользователи сами диапазон выбирают, но это не для (16).

(24) так они сейчас вручную и грузят, хочется это дело автоматизировать, а то задолбали со своим цирком

(25) Тогда - в одну сторону пакет, а назад летит ответ, чтобы всё, что выгружалось, по таблицам вычищалось.

(26) еще такой вопрос, дата запрета редактирования в торговле ставится жестко. но все же иногда они чето там правят в заднем числе по подписи Самого генерального). Вот вопрос, можно сделать так, если документ изменен в прошлом периоде, все документы текущего грузятся, а этот либо как то выпрыгивает пользователю в списке либо загружается но уведомляет что так и так, документ за такую дату был изменен проверьте что у вас ндска не слетела ?

(27) в типовой БП 3.0/ УТ11 помимо механизма даты запрета изменения данных, есть механизм даты запрета загрузки данных

Из справки
Если дата запрета загрузки данных установлена, то при попытке пользователя загрузить данные в ИБ до даты запрета загрузки все запрещенные для загрузки данные будут пропущены, сведения о них будут записаны в журнал регистрации, а разрешенные данные будут загружены.

(27) В обработчике ПослеЗагрузки делай какие угодно проверки и сообщения

Сколько делал настроек обменов, небыло у меня дублей.....

Что я делал не так???

(29) (30) спасибо, буду пробовать

(31) Ну, чтобы были дубли нужно взять одну базу - поработать в ней, потом сделать её копию и поставить в другое место, чтобы там поработали тоже.
Потом эти две базы попытаться слить в одну третью и посмотреть, что из этого получится.

(33) При условии поиска по гуид?

(34) Да при любом условии.
Если поиск по GUID-у, то два разных элемента из двух разных баз попадут на один элемент в итоговой базе (две организации в одну - крутизна неимоверная).
Если поиск по коду, то будет тоже самое, так как и там и там будут элементы у которых и код и Гуид одинаковые.
Понятно, что, например, организацию нужно по ИНН-у искать, но не факт, что его введут.
В общем, если начали через ж, то через неё же и закончат.