Но он же пишет, что решает не эту проблему, а более широкую - как (куда) оптимально прилепить те атрибуты, которые будут критериями отбора "дай мне оплаты, что не прошли акцепт", "дай мне оплаты без счетов-фактур", чтобы отбор по критериям не приводил к JOIN-ам с дикими многоэтажными планами запросов к БД.

И решает её в отрыве от бизнес-процесса принятия документа к учёту и отражения факта этого принятия в ИУСе - т.е. бухпроводка, проводка поступления партии материала у него оторвана от документа-основания для таковой проводки (и в т.ч. проверки оригинала документа на наличие, комплектность пачки сопроводительных документов, правильности оформления).
Т.е. проводки сами по себе, DMS как файло-свалка со связями абы-каких тэгов сами по себе.
Целостного бизнес-процесса нет.
Я как бы написал описание условной задачи. :)
Напишите, как вы видите решение подобной задачи. Хотя бы очень высокоуровнево.
Желательно со схемами бизнес процессов. ))
И со схемами БД под эти процессы.
Тогда и можно обсуждать преимущества и недостатки разных решений.

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

Вспомнился mazzy со своим любимым "У нас есть такие приборы, но мы вам о них не расскажем".

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

Т.е. DMS по вашей схеме получается настолько же гибкий универсальный, насколько и толком к бизнес процессу неприспособленный (допилить напильником по месту). Кто потом будет таким пользоваться, нафигачат туда документов с кривым видом/тэгами, и собрать достоверную аналитику по такой DMS-базе будет проблематично.
???
Я хочу написать относительно универсальный модуль, и сейчас невозможно сказать, кто и для чего именно его будет использовать. Если модуль получится нормальным - я его выложу как open source.
И какая, собственно, разница, какой бизнес-смысл "зашит" в определенный тег? С точки зрения системы - это просто тег, и один тег от другого технически ничем не отличается. И базе все равно, храним мы в тегах "справочник видов прикрепляемых документов, или справочник событий (фактов хозяйственной жизни) произошедших с документом. Или сборную солянку из того и другого."

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

Если видите потенциальные проблемы такого решения - приведите какие то практические примеры возможных косяков. И как именно их можно избежать при другой организации схемы данных.
А просто рассуждения что пользователи "нафигачат туда документов с кривым видом/тэгами, и собрать достоверную аналитику по такой DMS-базе будет проблематично" - они не имеют практической пользы.

Так вы на tag_map посути начинаете таким образом дублировать поля, которые и так есть в ЕРП (в таблицах, где хранятся объекты учёта, к которым вы эту dms тулите). Только там они хранятся скорее всего в плоской таблице (заголовок документа 1:N позиция документа), а здесь у вас очень неэффективный и неструктурированный EAV-формат (dms-документ 1:N тэг).
Пример можно?
О каком дублировании идет речь?

Ну ок, вот, например, таблица заказов покупки / продажи:
https://globalqss.com/idempiere/6.2_20190709/schemaspy/Purchasing/tables/c_order.html
Предположим, распечатали документ, подписали, отсканировали (или создали электронный документ с цифровой подписью), создали для него отдельную карточку как документа, добавили теги.
Какие могут быть проблемы?
С каким полем таблицы заказов (как сущности ERP системы) могут быть конфликты?

События, о которых вы говорите - это события, относящиеся именно к сущности ЕРП, а не к документу.
Но, предположим, пользователи захотели создать тег "Заказ проинвойсирован". И прикрепляют этот тег к самому документу. Да, появляется дублирование. Но это уже будет на совести пользователей. Но в чем именно вы видите проблему?
Если уж на то пошло, пользователи точно так же могут еще одно поле создать "isinvoiced2".

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

В том, что вы перекладываете на совесть пользователей целостность тэгов (их соответствие атрибутам сущности ЕРП) :)
А обработку ДМС отрываете от обработки (жизненного цикла) самой сущности.
Т.е. умножаете хаос в системе, вместо того, чтобы увязывать конкретный вид документа ДМС с конкретной сущностью (ордер, инвойс и проч) и этапами его обработки. Т.е. не рассматриваете регистрацию/проводку сущности в ЕРП и регистрацию оптической копии оригинала документа в ДМС как две неразрывные половинки одного сквозного бизнес-процесса.

Поэтому собрать достоверную картину выборок, о которых вы писали в начале псто, на такой базе представляется сложным - т.к. никогда нет уверенности, что тэги отражают реальную картину сущностей. Целостность информации в вашей ЕРП-ДМС сомнительна.
Я понял.
Видимо, у вас не очень большой опыт работы с документами.
Сами по себе процессы обработки документов не очень сильно пересекаются с ERP системой. В ERP как сущности обычно содержится небольшое подмножество всех документов, обрабатываемых предприятием. И стадии обработки документов часто не совпадают со стадиями обработки сущностей ERP.
Например, тот же заказ покупки / продажи, после того, как получен / отгружен товар и учтены инвойсы, в ERP не изменяется. А вот бумажный документ, например, может быть передан в центральный архив на хранение - и этот факт надо фиксировать в системе документооборота, но НЕ НАДО ФИКСИРОВАТЬ В ERP (в таблицах, которые являются "сущностями" для ERP).
Да, это можно зафиксировать в ERP. Но - не надо. Точно так же, как не надо добавлять в 1С игру в шахматы
https://infostart.ru/public/13810/

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

Если есть очень высокие требования к уровню контроля и качеству данных - надо внедрить ERP, DMS and BPMS как отдельные системы и настроить их взаимодействие. В таком случае пользователям может быть запрещено ставить теги вручную, и они (теги) будут импортироваться из DMS. А управление всеми этими бизнес процессами может делать BPMS.

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

Я как раз и не хочу добавлять в ERP систему полноценную DMS . Я об этом в самом первом сообщении написал.
Это должно быть простое и максимально гибкое решение.

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


Не будут, да.

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

Ну писал же выше - если вы из Немеции, обратитесь к соседям в Дортмунд. Там уже лет 40 пилят единую систему всего, называется SAP. Краха пока не наблюдается, - целый мир в коробке. ;)

авторВ ERP как сущности обычно содержится небольшое подмножество всех документов, обрабатываемых предприятием. И стадии обработки документов часто не совпадают со стадиями обработки сущностей ERP.
Но это самые важные "денежные" документы - и по ним ЖЦ документа в учёте неотрывно связан с движением бумажного оригинала (особенно если местное законодательство не готово к цифровизации, и работает исключительно по оригиналам с синей печатью).
Поэтому, если бы вы вместо абстрактных тэгов выделили бы явно справочник "Вид документа", и поле "Статус документа", к которому бы разработали подробную статусную схему (которая может включать как статусы принятия документа к учёту, так и статусы движения оригинала) - то выборки в ЕРП-системе у вас бы свелись к Таблицы_Ерп-сущности JOIN Таблица_истории статусов ЖЦ.
Выборки бы тогда получились в виде набора подзапросов, вроде "дай документы такогото вида, которые прошли статус "Принят к учёту" и хотябы раз получали статус "Оригинал возвращён на доработку".

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

А вы же упорно отвязываете бизнес-процессы dms от бизнес-процессов учёта - т.е. создаёте файло-свалку по сути.
авторА если идиоты - у них ERP не работает, и спорить не о чем При таком подходе у вас получится весьма фиговая система :)

авторЕсли есть очень высокие требования к уровню контроля и качеству данных - надо внедрить ERP, DMS and BPMS как отдельные системы и настроить их взаимодействие.
Как отдельные системы - это очень дорогой, глючный, не шибко удобный пользователям процесс, да ещё и с повышенными трудозатратами на администрирование и сопровождение (одна только синхронизация НСИ между такими системами, и администрирование пользователей выпьют мозг службе поддержки).

Когда ДМС и БПМС (воркфлоу) вшит прямо в коробку ЕРП - получается гораздо удобнее и для пользователей, и для сопровождальщиков.
А пруфы будут?

Я правильно понимаю, что вы знакомы с идеями Gartner ( Postmodern ERP ) и у вас есть некие доказательства, что их точка зрения ошибочна?
Если да, интересно было бы ознакомиться. ))

Ну и еще одна "мелочь".
Я в первом сообщении этой темы прямо указал ERP систему, о которой идет речь. Это iDempiere .
Предназначена для предприятий среднего размера с соответствующими бюджетами на внедрение и поддержку.
Можно поинтересоваться, о какой именно системе вы говорите (ДМС и БПМС (воркфлоу) вшит прямо в коробку ЕРП)? ))