Возникли проблемы со структурой подчинённости документов в переписанной конфиге
Ромбовидные связи и взаимные ссылки привели к выбросу в типовую форму подчинённости овер 9000 ссылок
После многодневных измышлений было принято решение лепить свою форму с уникальной логикой
А именно
Все бизнес-процессы в компании заданы, их количество не более десятка, даже меньше
Рисуем для каждого бизнес-процесса своё дерево
Отправляем в форму подчинённости ссылку на искомый документ, программа опредялет какому бизнес-процессу принадлежит документ. Затем вычисляет корневой документ и рисует дерево. Искомый документ высвечивается в этом дереве своим цветом.
К плюсам можно отнести также возможность заталкивания в дерево прочих реквизитов типа суммы, валюты, склада
Что думаете, коллеги?

Рисуй на здоровье.

(0) я бы на месте ТС сделал 10 критериев, поскольку отборы много важнее структуры подчиненности

плохо конфиг. переписали
или у вас такие длинные-длинные БП ?

Хмм... хотел бы я взглянуть на "... овер 9000 ссылок" :)

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

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

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

не надо путать подчинение и связи, автор

(5) ну и какая там разница?
если реквизит документа ссылается на другой документ прямо или косвенно, то он уже находится в бизнес-процессе

(6) подчинение - это древовидная структура
   связи - это граф

садис два

берём любой объект метаданных, вычисляем, в каких бизнес-процессах он может участвовать и строим дерево
вот, например, взять того же контрагента
он участвует в процессах Продажа, Покупка, как минимум
типовая СП этого не учитывает, конечно, но предлагает своё решение - документы контрагента

(7) подожди, подожди
я, может, не согласен с тем, что связи это граф
бизнес-процесс предполагает однонаправленные связи
заказ - накладная - ордер
заказ - оплата
нет связей документов друг с другом, которые бы выбивались из схемы подчинённости
в этом плане я использую понятия связь и подчинённость в одном смысле

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

(9) с дуба упал, БП предполагает и обратные связи и вложенные связи, т.е. граф в чистом виде.

"тупые и жадные" могут считать иначе, я не против

(11) не верю я в то, что ты тут мне говоришь
приведи пример

(12) отррой документообор на УФ, я не тебе на училка по математике за 5-й класс

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

(13) ты говоришь про БП, а у БП нет графов!

бизнес-процесс это строгая подчинённость
есть инициатор, есть исполнители
я чего-то в жизни не понимаю?

(15) я говорю, что проблема в (0) не столько проблема конфигурации, столько проблема ваших реализаций БП без глубокого понимания сути

(16) это догма и неспособность мыслить шире, прощай

(18) ты даже примера не привёл, чтобы показать, где я не прав

(16) И чо? Никакой итерационности ваши бизнес-процессы не предусматривают? Только вперед, ни шагу назад?

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

(21) мдя, эту ветку тоже можно переносить в секцию

"как страшно жить"

(0) делай

(20) корректировка заказа это документ, главный по отношению к заказу, но никак не может быть его потомком, если ты это хотел сказать
тут нет графов

(22) ты ни одного примера не привёл, только умные речи ведёшь
я, может, где и туплю, но, по крайней мере, обосновываю свои мнения

хотя бы один пример, где бизнес-процесс это граф
хотя бы один..
нет, зажали

(25) читай (13),

ты ведь не баба, чтобы тебе что-то в рот ложить, направление есть - смотри примеры

(27) причём тут баба
открыл я конфигу, куда нажать

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

интересно а как ты будешь классифицировать перевыставление услуг?

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

по большому счету это узкоспециализированная фишка которая мало кому подойдет, + может умереть еще не родившись или в процессе внедрения с вероятностью близкой к 100%