Задача: Есть 2 БД на 1с:предприятие. Есть некий БП, часть его выполняется в первой базе, часть во второй.
Вопрос: Как правильно организовать структуру метаданных? Отрисовать полностью одинаковый БП в обеих базах и постоянно обмениваться информацией об этапах БП и состоянии задач? Или первую часть БП отрисовать в одной базе, при обмене стартовать вторую часть БП во второй и писать информацию о состоянии задач и БП в РС, а этим регистром обмениваться?

Ваши идеи, господа!

Бп это что?

(2) Быстрое питание. То чем Мигалков собрался заниматься

(2) вроде бизнес процесс

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

Если во второй базе нужно видеть кто и что и сколько времени делал в первом куске, то рисуй весь процесс во второй и половинку в первой

(6) спасибо. Во второй базе неважно кто, что и сколько делал в первой. А вот в первой базе важно знать на каком этапе сейчас находится бизнес-процесс во второй. Как только бизнес-процесс заканчивается во второй именно тогда же он заканчивается в первой.

(7) ну, супер. Как у тебя блоки то обновляться будут? Будут ли в первой базе такие же сущности как во второй?

(0) Лучше разные БП в каждой базе. Только в первой будет системная задача, вроде "СогласованиеВоВторойБазе". Наладить обмен статусами для информации. При получении статуса "СогласованВоВТоройБазе" выполнять задачу и все.

(8) у меня есть регистры, которые одинаковы в обоих базах, они заполняются в результате прохождения по БП (там собирается некая отчетная информация). То есть по ним я смогу собирать информацию в отчеты. Но в то же время, есть необходимость знать в первой базе, на каком этапе находится бизнес-процесс во второй. Поэтому и возник вопрос о РС , который бы собирал в себе статусы задач из второй базы.

Вроде как в первом приближении
"писать информацию о состоянии задач и БП в РС"

Но вот дальше "первой базе важно знать на каком этапе сейчас находится бизнес-процесс во второй"

Этап и статус это как бы разные понятия
Статус "Согласование"
Этап "Согласование у Иванова", "Согласование у Петрова"
Ну т.е. у Статуса могут быть дополнительные сущности. например кто согласовывает
Или если статус с состоянием "Просушка", то может быть сущность - влажность на дату


Это я все к чему?
Если в первой базе будут все те же сущности, что и во второй, то проще писать один БП и делать хитрый обмен
Если все же в базы разные то и БП тоже должно быть два и какой-то там регистр состояния

(10) ИМХО, это оптимально.

(11) базы разные, но часть сущностей повторяется.

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