КД2 или КД3 ?

1. alexander-lubich 26 19.04.21 11:48 Сейчас в теме
Добрый день!

есть холдинг 30 баз БП3 / 50 юрлиц в одной сети. сейчас обменов нет (нет исторической данности которой надо поклоняться)


все бп3 актуальных релизов однообразного наполнения очень близки к типовым . в НСИ нет перекосов на обилие торговой номенклатуры или контрагентов, после выделения целевых контрагентов и физлиц (все с кем были взаиморасчеты за последние 2 года) и свертки дублей контрагентов + физлиц оказалось около 2700шт

Нужна центральная база для ведения казначейства, центральной базой выбрана типовая 1С:УХ.

Стоит задача
1) наполнить центральную базу справочниками (Достаточными для заведения банковской Выписки в УХ - организации, контрагенты, договоры, банки , банковские счета , физлица) и начать централизованное ведение НСИ из центральной базы
т.е. в периферийных базах реализовать запрет ввода и отправлять пользователя вводить требуемые ему справочники в центральную базу.

и далее:
2) Загружать банковскую выписку в центральной базе и распостранять ее по периферийным - начальная задача становления планируемого казначейства.


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

В БП и УХ введены общие реквизиты "Ссылка локальная" и "Ссылка общая" для упрощения обслуживания возможных правил обмена и однозначной идентификациии элементов при обмене.

какую технологию использовать разумнее КД2 или КД3 и какая аргументация может быть использована для обоснования выбора ? пока это достаточно простой односторонний обмен справочниками и двумя документами.
По теме из базы знаний
Вознаграждение за ответ
Показать полностью
Найденные решения
6. dandykry 9 19.04.21 13:49 Сейчас в теме +2 $m
(1)
Оба механизма выполняют одну и ту же задачу - данные из точки А появляются в точке Б, С .....Ж п е. Основное волшебство в руках разработчика. Пользователи и заказчики вообще без понятия что там происходит и что это за буквы КД2, КД3.

Почему:
Минусы КД2
1) Трудность сопровождения: необходимо отслеживать изменения метаданных и актуализировать правила обмена данными. В типовых конфигурациях это происходит часто, поэтому обновление даже средних по сложности правил порой требует больших трудозатрат, нежели само обновление конфигурации т.к. требуется:
- проанализировать изменения и при необходимости изменить правила
- протестировать обмены на нестандартные ситуации, которые могут быть привнесены обновлением вендора

Для людей, далеких от программирования, обменов можно сказать - сопровождение дорогое.

2) Не развивается, не поддерживается.

Плюсы КД2:
Из-за того, что КД3 как раз решала основные узкие места КД2, к плюсам можно отнести
1) Если требования к составу обмена данными будут изменяться, сопровождение останется все таким же сложным, как и было.
2) разработка сравнительно проще для разработчика - разработка дешевле. Но это субъективно и зависит от ситуации. Что-то в КД3 проще разработчику, что-то в КД2 проще.

Минусы КД3:
1) Если требования к составу обмена данными будут изменяться, сопровождение может стать нереально сложным, что проклянете выбор КД3.
2) Из-за наличия стандарта некоторые вещи разрабатывать сложнее - разработка дороже. Но это субъективно и зависит от ситуации......
3) EnterpriseData уже будет нетиповой из-за нестандартного справочника.

Плюсы КД3
1) Основное преимущество КД3 - нет привязки к метаданным. Это облегчает сопровождение т.к. первая конфигурация выгружает свои данные в формат EnterpriseData. Вторая загружает данные из этого формата. При изменении конфигурации, правила меняются только на 1 стороне. Проще загружать данные из систем не на 1с.
Требуется в конфигурации, которая изменилась проверить выгрузку и загрузку. Вторую конфигурацию, как правило, подпиливать не нужно в 99%
2) Развивается, сопровождается
3) Вроде б как веб сервисы из коробки уже есть (БСП). Почти в реальном времени можно крутить, но я точно хз как оно там все.

Итого:
КД2 если в будущем придется масштабировать решение (дополнять обмен некими сущностями, возможно теми, которых нет в формате EnterpriseData)
КД3 если есть острая проблема в актуализации правил. Например будет зоопарк из разных релизов БУХ.
Остальные ответы
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
2. tolyan_ekb 104 19.04.21 11:57 Сейчас в теме
(1) Что знаете лучше КД2 или КД3? Как срочно может потребоваться изменения в обмене?
3. Torin 735 19.04.21 12:01 Сейчас в теме
(1)
какую технологию использовать разумнее КД2 или КД3
- Как вам удобнее ту и используйте!
"таблетки от всех болезней нет" - примете стандарт EnterpriseData будете работать с ним ,примете другой будете работать с другим

"Следуя из этого список отличий КД3.0 от КД2.0 можно свести к нескольким пунктам:

*результатом работы КД3.0 является код модуля менеджера обмена, состоящий из процедур и функций, в которых *реализована логика загрузки данных, представленных в формате EnterpriseData, а также логика выгрузки данных в формат;
*алгоритмы конвертации содержат код, выполняемый в одной конфигурации - той, для которой разрабатывается модуль конвертации;
*алгоритмы конвертации не несут в себе информации о внутреннем устройстве конфигурации-корреспондента, вместо этого они ориентированы на структуру формата EnterpriseData (для простоты разработки в КД3.0 объекты формата EnterpriseData представлены аналогично объектам метаданных 1С:Предприятие)."
6. dandykry 9 19.04.21 13:49 Сейчас в теме +2 $m
(1)
Оба механизма выполняют одну и ту же задачу - данные из точки А появляются в точке Б, С .....Ж п е. Основное волшебство в руках разработчика. Пользователи и заказчики вообще без понятия что там происходит и что это за буквы КД2, КД3.

Почему:
Минусы КД2
1) Трудность сопровождения: необходимо отслеживать изменения метаданных и актуализировать правила обмена данными. В типовых конфигурациях это происходит часто, поэтому обновление даже средних по сложности правил порой требует больших трудозатрат, нежели само обновление конфигурации т.к. требуется:
- проанализировать изменения и при необходимости изменить правила
- протестировать обмены на нестандартные ситуации, которые могут быть привнесены обновлением вендора

Для людей, далеких от программирования, обменов можно сказать - сопровождение дорогое.

2) Не развивается, не поддерживается.

Плюсы КД2:
Из-за того, что КД3 как раз решала основные узкие места КД2, к плюсам можно отнести
1) Если требования к составу обмена данными будут изменяться, сопровождение останется все таким же сложным, как и было.
2) разработка сравнительно проще для разработчика - разработка дешевле. Но это субъективно и зависит от ситуации. Что-то в КД3 проще разработчику, что-то в КД2 проще.

Минусы КД3:
1) Если требования к составу обмена данными будут изменяться, сопровождение может стать нереально сложным, что проклянете выбор КД3.
2) Из-за наличия стандарта некоторые вещи разрабатывать сложнее - разработка дороже. Но это субъективно и зависит от ситуации......
3) EnterpriseData уже будет нетиповой из-за нестандартного справочника.

Плюсы КД3
1) Основное преимущество КД3 - нет привязки к метаданным. Это облегчает сопровождение т.к. первая конфигурация выгружает свои данные в формат EnterpriseData. Вторая загружает данные из этого формата. При изменении конфигурации, правила меняются только на 1 стороне. Проще загружать данные из систем не на 1с.
Требуется в конфигурации, которая изменилась проверить выгрузку и загрузку. Вторую конфигурацию, как правило, подпиливать не нужно в 99%
2) Развивается, сопровождается
3) Вроде б как веб сервисы из коробки уже есть (БСП). Почти в реальном времени можно крутить, но я точно хз как оно там все.

Итого:
КД2 если в будущем придется масштабировать решение (дополнять обмен некими сущностями, возможно теми, которых нет в формате EnterpriseData)
КД3 если есть острая проблема в актуализации правил. Например будет зоопарк из разных релизов БУХ.
7. nomad_irk 68 19.04.21 18:13 Сейчас в теме
(6)что в кд3 сделать проще, чем в кд2?
Вы лукавите, когда говорите о том, что в случае изменения структуры метаданных править придется только на одной стороне, при использовании кд3: обе стороны должны знать об изменениях.

Чтобы изменить правила Кд3 - нужно обновлять конфигурацию, в случае кд2 достаточно просто обновить правила перед выгрузкой данных + выгрузить данные по новым правилам, чтобы загрузка данных так же происходила с учетом изменений.

кд3 - это универсальный формат, на этом его плюсы заканчиваются и начинаются минусы.
15. dandykry 9 20.04.21 07:15 Сейчас в теме
(7)

что в кд3 сделать проще, чем в кд2? - чуть внимательней прочитайте. КД2 разработка проще, КД3 разработка чуть сложнее

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

Чтобы изменить правила Кд3 - нужно обновлять конфигурацию - в плане обмена можно выбрать внешнюю обработку, которая может быть модулем выгрузки/загрузки. Обновлять не обязательно.

Может вы плохо знаете КД3 ?
16. nomad_irk 68 20.04.21 07:57 Сейчас в теме
(15) При переименовании реквизита достаточно изменить правила выгрузки. Правила загрузки - остаются прежние.
Правила в этом случае можно изменить с помощью любого текстового редактора.
17. dandykry 9 20.04.21 09:04 Сейчас в теме
(16) Напомните мне, в архиве с правилами обмена КД2 лежат 3 файла, Правила обмена, Правила регистрации и Правила обмена корреспондента. Вот 3ий пункт, он не добавляет трудностей?

И вот это вот "редактирование при помощи текстового редактора" очень неудобное, когда правил больше 5.
19. nomad_irk 68 20.04.21 09:36 Сейчас в теме
(17)
Напомните мне, в архиве с правилами обмена КД2 лежат 3 файла, Правила обмена, Правила регистрации и Правила обмена корреспондента. Вот 3ий пункт, он не добавляет трудностей?


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

И вот это вот "редактирование при помощи текстового редактора" очень неудобное, когда правил больше 5.

Т.е. поправить больше 5 пусть даже внешних обработок - это удобно, а сделать исправления в 5 текстовых по-сути файлах - перестало быть удобным. Хорошо.
20. dandykry 9 20.04.21 11:40 Сейчас в теме
(19) Где я в расчетах ошибаюсь?

Правила регистрации (ПР)
Правила обмена (ПО)
Правила обмена корреспондента (ПОК)

Есть 1 шт УХ и 30 шт БУХ. Обмен в обе стороны.

Вариант 1) В БУХ переименовывается реквизит. Был Склад, стал МестоХранения.

КД2
В ПО БУХ изменяются правила, т.к нужно правильно выгрузить. Итого 30 изменений Склад на МестоХранения
В ПО УХ изменяются правила, т.к нужно правильно выгрузить. +30 изменений Склад на МестоХранения
В правилах ПОК УХ нужно это менять (есть эта самая необходимость)? Если да, то + еще 30 изменений Склад на МестоХранения
В правилах ПОК БУХ нужно это менять (есть эта самая необходимость)? Если да, то + еще 30 изменений Склад на МестоХранения

От 60 до 120 изменений

КД3
В БУХ правилах выгрузки 30 изменений Склад на МестоХранения. Нужно правильно Выгрузить/Загрузить
В УХ 0 изменений, она как загружала/выгружала из формата, так будет дальше

30 изменений

Вариант 2) В УХ переименовывается реквизит. Был Склад, стал МестоХранения.
КД2
В ПО БУХ изменяются правила, т.к нужно правильно выгрузить. Итого 30 изменений Склад на МестоХранения
В ПО УХ изменяются правила, т.к нужно правильно выгрузить. +30 изменений Склад на МестоХранения
В правилах ПОК УХ нужно это менять (есть эта самая необходимость)? Если да, то + еще 30 изменений Склад на МестоХранения
В правилах ПОК БУХ нужно это менять (есть эта самая необходимость)? Если да, то + еще 30 изменений Склад на МестоХранения

От 60 до 120 изменений

КД3
В БУХ 0 изменений. Они как загружали/выгружали из формата, так будут дальше
В УХ 1 изменений. Нужно правильно Выгрузить/Загрузить
21. nomad_irk 68 20.04.21 11:47 Сейчас в теме
(20)Ваша ошибка в расчетах:

В правилах ПОК УХ нужно это менять (есть эта самая необходимость)? Если да, то + еще 30 изменений Склад на МестоХранения
В правилах ПОК БУХ нужно это менять (есть эта самая необходимость)? Если да, то + еще 30 изменений Склад на МестоХранения


Этого не нужно делать, т.к. уже изменились ПО для БУХ и УХ.

З0 изменений нужно сделать в том случае, если правила ну прям совсем разные. В идеальном случае: 1 правило для всех 30 БУХ и 1 правило для 1 УХ.
22. dandykry 9 20.04.21 11:50 Сейчас в теме
(21)

Оба механизма выполняют одну и ту же задачу - данные из точки А появляются в точке Б

Итого:
КД2 если в будущем придется масштабировать решение (дополнять обмен некими сущностями, возможно теми, которых нет в формате EnterpriseData)
КД3 если есть острая проблема в актуализации правил. Например будет зоопарк из разных релизов БУХ.


Что я не так написал?
23. nomad_irk 68 20.04.21 11:55 Сейчас в теме
(22)Здесь - все так.
Зоопарк из разных релизов ЗУП и в случае КД3 будет достаточно проблемно обслуживать.
24. dandykry 9 20.04.21 12:04 Сейчас в теме
(23)

Причем здесь ЗУП?......)))

Итак вопрос автора темы:
какая аргументация может быть использована для обоснования выбора ?

Аргументацию я привёл. Автор как-нибудь там разберется.

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

все еще придерживаетесь этой точки зрения?
25. nomad_irk 68 20.04.21 12:10 Сейчас в теме
(24)
Причем здесь ЗУП?

ЗУП - не при чем, речь была про зоопарк БУХ.

(24)
все еще придерживаетесь этой точки зрения?

Все еще придерживаюсь.
26. dandykry 9 20.04.21 12:13 Сейчас в теме
27. MaxS 2822 20.04.21 19:35 Сейчас в теме
(22)
дополнять обмен некими сущностями, возможно теми, которых нет в формате EnterpriseData

На всякий случай проинформирую, что технология обмена в формате EnterpriseData подразумевает доработку XDTO пакета. Если без новой сущности не обойтись, создаём свой формат на основе типового и добавляем туда любые сущности. Размещаем пакет и правила в расширении.
Получается основной минус ED можно устранить. Какие ещё минусы остались? )
29. dandykry 9 21.04.21 06:51 Сейчас в теме
(27) Да, в курсе) Без грамотного документирования это минус)
Записал в минусы, скорее всего потому, что я получал в наследство измененный XDTO пакет с хер пойми для чего и почему) Осадочек остался) В целом ED приятнее выглядит xml правил и я выбрал бы его
30. MaxS 2822 21.04.21 10:32 Сейчас в теме
(29) Например из-за того, что современные автомобили становятся всё сложнее и невозможно их качественно обслуживать в гаражном сервисе, их не стали меньше покупать.
Так же и с современными технологиями обмена. Некачественное обслуживание - это не минус технологии, это минус исполнителю.

У КД2 тоже есть подобные проблемы. Правила, созданные вручную в полуавтоматическом режиме как-то приятнее редактировать и обслуживать, чем типовые. Там увлеклись программным формированием данных к выгрузке и пропала возможность мышкой интерактивно поправить правила. Нужно лезть в код. Это в зависимости от личных предпочтений тоже можно отнести к плюсам или минусам.
Всё субъективно.
31. dandykry 9 21.04.21 11:09 Сейчас в теме
(30) Да, я согласен с Вами))
4. GeraltSnow 171 19.04.21 12:37 Сейчас в теме
Обмен, написанный на КД2, прозрачен и прост для доработки. В обмене на КД3 черт ногу сломит. Вот и вся аргументация.
nomad_irk; +1 Ответить
5. MaxS 2822 19.04.21 13:22 Сейчас в теме +1 $m
Обмен, написанный на КД3, прозрачен и прост для доработки прямо общем модуле. В обмене КД2 не так просто оперативно отладить код и внести исправления.
При обслуживании 30-ти баз правила обмена для КД2 придётся обновлять во всех базах и следить за синхронностью обновления конфигураций.
КД3 нечувствительна к версии конфигурации, дорабатывать и обновлять можно в произвольное время или вовсе не обновлять какую-нибудь конфигурацию
Обмен в КД3 есть штатно в базах, используются планы обмена. Синхронизацию на КД2 там почти всю выпилили.
И многое зависит от специалиста, который обслуживает обмен.
8. nomad_irk 68 19.04.21 18:16 Сейчас в теме
(5)ну как сказать, не чувствительна.....добавили/изменили реквизит объекта в приемнике и приплыли.
9. MaxS 2822 19.04.21 18:20 Сейчас в теме
(8) Допустим из 30 баз в одной что-то поменяли. Соответственно в этой базе поправили правила КД3 и всё. Остальные 29 баз не трогаем, обмен работает.
В случае с КД2 есть вероятность, что все правила нужно будет поправить.
10. nomad_irk 68 19.04.21 18:54 Сейчас в теме
(9)ага, добавили реквизит и приплыли, нужно как минимум еще и источник данных обновить, т.е. все то же самое, что и при Кд2, только еще и конфигурацию придется обновить, в отличии от версии правил в случае кд2.
11. MaxS 2822 19.04.21 19:32 Сейчас в теме
(10) Если в одной конфигурации чо-то меняется, то в ней одной дорабатываются правила КД3.
Правила для КД3 можно хранить в расширении.
В КД2 в любом случае при изменении в одной, затрагиваются минимум две конфигурации.
victorree; Xershi; +2 Ответить
12. nomad_irk 68 19.04.21 22:21 Сейчас в теме
(11)Откуда приемник возьмет данные для нового реквизита при использовании Кд3?
13. MaxS 2822 20.04.21 05:09 Сейчас в теме
(12) Тут всё просто. Если зная преимущества КД3 появляются такие вопросы, используйте КД2. )
Каждый специалист использует механизм в рамках своих знаний и умений. Можно найти сотню плюсов и минусов при желании.
У меня уже лет 5 как используется универсальная процедура, которая выгружает все реквизиты шапки, не задействованные в ED. Если добавили реквизит в шапку, правила можно не трогать. Они автоматически выгрузят значение нового реквизита и если в другой базе есть такой же, загрузят его.
В типовых правилах ED этого нет, но возможности формата ED позволяют так делать.
victorree; Xershi; dandykry; +3 Ответить
14. nomad_irk 68 20.04.21 06:40 Сейчас в теме
(13)если вас эта возможность поставила в тупик при использовании КД2, то да, используйте КД3.

Для кд2 это не проблема, при необходимости, но лично я считаю, что нет необходимости в передачи всего и вся только для того, чтобы было.
18. MaxS 2822 20.04.21 09:10 Сейчас в теме
(14) Потерял нить о какой возможности лично я не знаю в КД2 и при чем тут собственно я при обсуждении принятия решения автором топика? )У каждого инструмента свои возможности. Нужно лишь правильно их использовать к конкретной задаче.

И по поводу конфигурации конвертация данных 3.1 хотелось бы напомнить, что в ней можно редактировать правила как для XDTO, т.е. ED, так и для xml, которые КД2. И правила регистрации.
Поэтому через несколько лет нас могут не понять, если использовать КД2 и КД3 в обсуждении.
28. alexey_kurdyukov 155 21.04.21 05:21 Сейчас в теме
Нужно понимать, что КД3 выгружает все объекты в стандартный формат ED. Если ваших объектов в этом формате нет - вы не можете их использовать. Если в ваших объектах есть поля, которых нет в ED - вы будете выгружать/загружать их через AdditionalInfo, то есть руками. Либо вы будете править XDTO-пакеты и в целом вкорячивать свои корявки. В целом, перенос любых нетиповых данных тут же делает КД3/ED неуниверсальным, и, естественно, требует доработки на обеих сторонах. Есть вариант вообще выгружать все реквизиты объекта в AdditionalInfo а в приемнике разбирать их, правда, зачем в этой ситуации КД3 как таковая - непонятно, можно вообще выгружать штатными средствами в строку/XML/JSON.

КД2 в этом плане несколько универсальнее, позволяет единообразно переносить любые объекты не опираясь ни на какие существующие структуры, но и она не идеальна.
32. hamsar 15 23.04.21 06:40 Сейчас в теме
1) КД2 но не просто КД2
2) Сделать расширение с общими метаданными распространить его по всем БП с которыми планируется обмен
2.1) В УХ добавить подписки которые регистрируют данные к отправке в переферийки в регистре(без плана обмена или с планом обмена как угодно, но я бы делал без плана) поскольку вы будете генерировать Сообщения в регистре, типа создай в такой базе элемент справочника, с такими то реквизитами. И уже эти данные отправлял бы в переферийку

3) Правила КД2 должны работать только с этими метаданными. При выгрузке из центральной вы должны помещать данные в Регистр расширения или справочник расширения. (таким образом вы решите проблем изменения метаданных при обновлении БП
4) Обработка которая будет запускаться из внешних по расписанию, которая будет тащить данные из регистров и создавать необходимые для вас движения.


Соответственно цепочка такая.
1) Делаем Расширения с регистрами справочниками которые будут переноситься из Управления Холдингом в регистр расширения расположенного в БП.
2) Пишем правила, с отборами и параметрами выгрузки необходимыми для наполнения каждой из БП
3) При выгрузке из УХ данные попаадают в каждую из баз в ограниченном необходимом для каждой из баз составе.
4) В каждой из баз присутсвует обработка, которая из записей регистров генерирует, документы Эта обработка может присутствовать как в Расширении так, и в виде внешей,
5) Таким образом вы получаете генерацию документов из регистров обмена, можете спокойно обновлять БП, в случае изменения типовых документов, вам будет достаточно изменить обработку генерации данных. (удобно для отладки)


Почему не КД3
Потому, что с кд3 вам придется очень много гемороится при рассогласовании регистров, но в целом пункт 1-3 можно реализовать и на 1-3 тогда затрагиваемые метаданные не будут менятся.

Искуственная шина данных у вас получится, реализовать генерацию на кд2 и кд3 я бы не стал, поскольку это довольно трудоемко для поддержки. А так у вас получается
1) Простая выгрузка генерация данных которая не МЕНЯЕТСЯ.
2) И обработка в которой заложена вся бизнес логика генерация данных в целевых базах
33. alexander-lubich 26 26.04.21 14:10 Сейчас в теме
(32) Добрый день! а как в этом решении сопоставлять элементы старых справочников ?

Для КД2 желателен уникальный набор реквизитов , либо по Гуид (что тянет с собой работу в периферийных базах по замене ссылок )

КД3 предлагает использовать "Соответствие объектов информационной базы" в рамках собственного типового инструментария

новые - понятно как появится - сделаны в ЦБ , перенесены в ПБ, ок . если элемент перенесен с Гуид из ЦБ - проблем нет
34. hamsar 15 26.04.21 14:38 Сейчас в теме
(33) гуид в кд2 не обязателен, в правилах можно поставить сопоставление по коду наименованию.

Можно даже поставить приоритет, если не найден по гуид, ищем по коду наименованию или любому полю или сочетанию полей или по регулярному выражению
35. hamsar 15 27.04.21 06:52 Сейчас в теме
(34) а попутал, справочники вам не надо сразу генерировать вы льте все в регистр, а сопоставляете обработкой из пункта 4
36. alexander-lubich 26 04.05.21 08:43 Сейчас в теме
(32)
Добрый день!
правильно ли я понял эту идею? :

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

делаем подписки регистрации к обмену.
Пользователь записал справочник - мы склонировали его в расширении и сделали запись в регистре
Пользователь записал документ - мы рекурсивно собрали ссылки в документе и перенесли документ и весь ссылочный тип из документа в расширение.

таким образом у нас в расширении лежат данные предназначенные исключительно к отправки или получения.

делаются правила КД2 по метаданным расширения кстати структура метаданных для кд2 выгружается с учетом новых объектов в расширении?
не будет ли проблем сделать правила для объектов из расширения?

передаются на сторону получателя и локально уже из данных регистра и связанных объектов делаются объекты в типовой части.
Прикрепленные файлы:
37. hamsar 15 04.05.21 10:58 Сейчас в теме +2 $m
делаются правила КД2 по метаданным расширения кстати структура метаданных для кд2 выгружается с учетом новых объектов в расширении?

да, поскольку обработка "выгрузка метаданных для КД2" запускается из предприятия, где метаданные расширения доступны. Да и если будут проблемы, при генерации правил, можно ручкам добавлять реквизиты. Это не составляет труда.

правильно ли я понял эту идею? :

В целом да, но упустили пару моментов.
В правилах стоит отбор на выгружаемые данные для целевой базы, правила по сути простые они генерируют те же записи в том же расширении, но уже в целевой базе.

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

Обработка является по сути ключевой. Подписки и регистр, просто фиксируют данные к отправке. Правила выгружают эти данные в целевые базы.

А обработка в каждой базе, генерирует из них справочники и документы.

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

Можно конечно добавить, функционал обработки сразу в правила, ПослеЗагрузкиДанных.

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

Разработчик 1С
Москва
зарплата от 200 000 руб. до 300 000 руб.
Полный день

Программист 1С (удаленно)
Самара
зарплата от 230 000 руб. до 230 000 руб.
Полный день

Руководитель группы разработки 1С
Москва
зарплата от 250 000 руб. до 250 000 руб.
Полный день

Специалист техподдержки
Санкт-Петербург
зарплата от 100 руб. до 150 руб.
Полный день