Здравствуйте,
Кто подскажет, можно ли с одной базой обмениваться по нескольким узлам?
Например по одному узлу выгружать справочники, а по второму выгружать доументы?

Конечно можно

(1) А примеры когда так делают есть?
Например в типовых так делают?

Нельзя. Префиксы узлов пересекаются, новую настройку создать не получается в типовых.

Так можно или нельзя?)

(2) Когда у разных данных разный приоритет обмена

Если очень хочется, то можно, но придётся доработать запрет типового механизма и в базе приемнике аналогично создать 2 узла и как-то разрулить имена файлов для обмена. И не регистрировать одно и то же в этих узлах.

(6) Имена файлов создаются по префиксу, а префиксы разные будут изза кода узла.
Создать столько же узлов в приемнике это понятно.
И то что обеспечить, чтобы регистрировалось НЕ одинаковая инфа тоже ясно.

Ну значит можно..

(3) Можно. "Пересечение" узлов ни на что не влияет, кроме как на автонумерацию, и легко устраняется их изменением.
(6) Sorry, Вы не в теме.

(7) "Пациент скорее жив, чем мертв"(с) - Скорее можно создать, чем нельзя - Вы у не уточнили главное - РИБ или не РИБ.

(2) "Например в типовых так делают?" - нет.
Там планы обмена "по организациям", "по магазинам", по подразделениям/складам и т.д. И несмотря на различие, у них у всех общая "специфика" - единая НСИ. В этом сакральный смысл Распределенных Информационных Баз.

Если Вы собираетесь делать на РИБ, то можно выкрутиться без изменений конфигурации - за счет написания "своих" правил регистрации.

"на РИБ" --> "не РИБ"

(8) При создании новой настройки обмена необходимо ввести префикс базы получателя. База получатель одна и та же. Как создать 2-ю настройку типовым способом?

(8) У меня НЕ РИБ.
Значит буду пробовать.

Прикольно. Почему возникла такая задача. Каждый узел, это отдельная база.

(12) Например разные данные нужно грузить с разной периодичностью.

Можно в одной загрузке грузить данные в зависимости от расписания

(14) Допустим идет выгрузку по правилам, тогда прям в правила вшить код по проверки времени.. помоему не очень красиво.

(15) Тут надо тогда спускать уровень рассуждений на саму технологию использования объекта метаданных ПланОбмена.

Что такое Объект ПланОбмена, что такое менеджер, откуда берутся и куда тулятся ссылки на объекты "узел ПланОбмена" и т.д.

То, что сейчас описывается в ветке = _разные_ планы обмена.
У вас есть множество экземпляров вида ИнформационнаяБаза и на этих ИБ выполняются разные планы обменов.
То, что в списках этих планов будут перечислены разные или одинаковые количества узлов...

ну есть у тебя база центрального офиса и еще две базы для двух подчиненных Структур (не важно, что это может быть: филиал, магазин, склад, цех, карьер, другая какая-то организация). И несколько разных наборов правил, связанных с несколькими разными ПланОбмена, допустим три разных: План обмена конфигурацией, план обмена справочниками НСИ, план обмена документами и оперативными справочниками.
Какой будет общий состав узлов? В идеале = в каждом плане будет 1+2 и таких планов 3 == 9 узлов. А баз сколько физически? Всего три базы

продолжу (16)

А если не хочется вводить в Центральную базу "лишние" планы обмена, то как выкрутиться? А как пишет выше в (8)

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

Только при этом не нужно забывать, что свои другие правила надо будет применять в какое-то свое время к каждому своему объекту данных.
Условно непрерывный обмен - синхронный.
Условно дискретный обмен - асинхронный.
Сколько времени должен занимать анализ данных источника, чтоб асинхронно применять к этим данным свои уникальные правила обмена? Это может быть критичной для пользователя длительной процедурой, а еще, в особо тяжелых случаях, и с требованием монопольного режима.

(16) Так а вывод какой?
Вот конкретный пример - есть ЦентрБаза и ПодчиненнаяБаза.
Нужно в течении дня выгружать только справочники, а ночью все документы изменившиеся документы.
Вот здесь мне и нужны 2 узла на одну физическую базу

(18) Какие проблемы с двумя наборами ПВД в правилах конвертации?

(18) Вывод у 1С программистов простой : два плана - с двумя разными правилами обмена

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

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

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

(20) Я чтото сильно запутался.
Правила понятно что будут разными в рамках узлов, зачем в итоге 2 плана обмена делать?
Это было моим изначальным вопросом, я хочу выкрутиться одним планом и несколькими узлами.

Прежде чем начинать программировать, напишите в блокноте префиксы узлов всех баз (три префикса - эта база и два узла) и имена файлов сообщений для каждой пары настроек обмена. Всего 6 префиксов и 4 имени файла.
Если получится, то это и будет ответом на вопрос темы топика. пмсм.

(22)
ЦБ - Префикс центрального узла
Б1 - Префикс узла 1 подчиненной базы (справочники)
Б2 - Префикс узла 1 подчиненной базы (документы)

ЦБ - Б1; Б1 - ЦБ
ЦБ - Б2; Б2 - ЦБ

Вот такой обмен.

(23) А у второй базы какие префиксы?

(24) у него в _одном_ плане, для _одной_ подчиненной базы в голове сложилось в _два_ узла с разными префиксами.

Не _правила_ разные, а _узлы_ разные.

(25) Мне понятно что хочет автор.
Непонятно понимает ли кто-то как на практике это реализовать? После вопроса (22) все советы закончились.

Предположим, что у подчинённой базы такие префиксы узлов:
Б1 - префикс узла самой базы. (ЭтаБаза)
ЦБ - узел для обмена с центральной базой (справочники)
?? - узел для обмена с центральной базой (документы) - если найдётся решение что сделать с этим узлом, будет ответ на вопрос топика.

Файлы ЦБ - Б1; Б1 - ЦБ ходят туда обратно исправно.
При поступлении файла "ЦБ - Б2" подчиненная база ответит, что нет такого узла.

По разным каталогам обмена разнести обмен не предлагать?

(26) Блин, действительно ты прав. Чтото я затупил, 1 узел должен быть равен одной базе.
Не знаю что я даже такую тему поднял, буду делать два разных плана обмена.

(28) Возвращаемся на исходные позиции? Теоретически можно обойтись одним планом обмена, но сколько это потребует доработок пока не ясно.
Нужно подождать комментария от (8) по теме )

(29) Можно на одном узле купить все изменения, но по условию (например по времени) выгружать те или иные данные, это логика будет записана в правилах обмена.
Например, весь день выгружаются только справочники, а в 3 ночи летят и документы.
Но мне так не нравится, сделаю 2 разных плана обмена.

(30) При поступлении подтверждения о доставке справочников регистрация всех документов сбросится.
Можно конечно завести 2-й узел как тут и обсуждалось и ночью при обмене узлом Б1 (справочники) смотреть на регистрацию узла Б2 (документы). С нумерацией можно запутаться - нужно понять при получении ответа и перед сбросом регистрации что было получено - справочники или документы.

(31) Значит и здесь я был неправ..
Хорошо, тогда в вашем варианте может ночью со служебного узла перекидывать регистрацию документов на основной узел. Такое может сработать?

(32) А, да, можно ночью в основной узел добавлять зарегистрированные документы из служебного узла и тут же снимать с регистрации всё на служебном узле.

(33) А когда приемник не сможет принять пакет с ночными документами, неоткуда будет взять кандидатов для повторной передачи )

(29) А в (8) ничего такого сакрального не сказано, можно не ждать очередных откровений :))
ТС уже подсказали и он уже сделал правильные выводы - два плана обмена. Это позволит легко настроить различный состав, различные правила и различное расписание. Ничего сложного и всё в пределах, не противоречащих типовым конфигурациям. И главное: без всяких танцев с бубнами.

(34) Если не сможет принять, то документы же останутся на основном узле.

(36) На основном узле документы останутся до первого подтверждения приема по справочникам, а потом тю-тю )

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

(38) "Если не смогут" // Не смогут что?

Вариант с двумя узлами к одной базе тоже имеет право жизнь. Я просто напомню: различные узлы в одном плане обмена автономны и независимы друг от друга. У них у каждого своя автономная регистрация, нумерация сообщений и т.д. Надо только в самом начале (при регистрации изменений по узлам) не тормозить и всё будет окей :)

(34) Почему не сможет принять? На приемнике не будет ограничений в видах объектов. Будут отправлять пока не примет.
(36) На основной узле днем не регистрируются документы и всё. Если ночные документы не отправились, отправляем до посинения. Либо по утрам перекидываем регистрацию документов обратно на служебный узел.

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

(39) - в (41) вот все правильно расписано. Ночью перекинулись на узел и до посинения пытаются выгрузиться. Тут уже никаких ограничений нет.

Хз о чем ты.

(43) Ну и ладно. Я все равно через 2 плана обмена считаю правильно делать, чтобы не запутывать логику.

(41) Погуглите "регистрация изменений для обмена" или нечто подобное для правил регистрации (не конвертации!). Современные платформы и конфигурации позволяют сделать нужное без изменения конфигурации... хотя как по мне - так проще изменить типовую :)

(44) Правильным будет ни в коем случае не регистрировать изменение одного и того же объекта дважды в двух узлах или в двух планах (которые к одной и той же базе). Остальное на Ваше усмотрение.

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

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

(48) В 47 наверное имеется ввиду не клепать свой план обмена в рамках БСП подсистемы, так как в типовых добавление своего плана по умолчанию подразумевавется что идет в рамках БСП,