Коллеги, сейчас думаю, как добавить в erp (вот схема базы, если интересно: https://globalqss.com/idempiere/6.2_20190709/schemaspy/) управление документами.
Речь не идет о функционале DMS / ECM, но и не просто прикрепление файла к объекту системы (такое уже есть).

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

Вроде бы стандартная задача (облако меток) и давным давно описано решение такой задачи: http://howto.philippkeller.com/2005/04/24/Tags-Database-schemas/ (“Toxi” solution).

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

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

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

Это точно не статус.
Есть много разных файлов (PDF и прочие форматы).
Одни из них, например, только инвойсы. Другие - контракты. А третьи - одновременно и инвойс и контракт (такое тоже бывает).
А еще может быть некий сертификат соответствия на партию товара или на партии, полученные в рамках отдельного доп соглашения к контракту, причем в ЕРП такой сущности нет - партии есть, контракты / доп соглашения есть (BPO / PO), а всяких сертификатов - нет. И такой сертификат - это не бух. документ, так как к бухучету отношения не имеет.
Контракт, к примеру, должен проверить юр отдел и бухгалтерия.
А инвойс - закупщик и бухгалтерия.
А сертификат соответствия, полученный от поставщика, надо отсылать покупателю.
Это все условные примеры, на практике могут быть очень разные комбинации.
Но одним полем "статус" точно обойтись не получается.

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


Так и задумано. Есть карточка документа, в которой есть поле URL, в котором хранится ссылка на скан документа в DMS-хранилище или на гугл диске или где то еще.

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

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

Воркфлошки вобщемто так и работают в ЕРП системах.
Ну по крайней мере - у ваших соседей в Дортмунде ;)
Хм.
Предположим, с поставщиком подписали контракт.
Он отгрузил товар и отправил документы - транспортные накладные жд и сертификаты.
Операторы вбивают данные в систему.
Обнаружили, что по одному вагону сертификат забыли прислать. Они что, не должны отгрузку в системе фиксировать? Вагон то едет, его, возможно, завтра на корабль перегружать...

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

И давайте не будем про ворклошки. :))
Как оно работает, я в курсе.
https://wiki.idempiere.org/en/Workflow_(Window_ID-113)
Но для этих целей не очень подходят они.

И как тогда бизнес планирует в учёте различать "забыли прислать" от "подсунули некондиционную несертифицированную партию товара"? Всёравно при приёмке партии на склад нужно один раз весь пакет документов проверить и отметить соответствующий статус.
Просто, складывается ощущение, что техническая задача "подвязать абы-как много сканов к карточкам" решается в отрыве от бизнес-задачи, где какраз воркфлошка+статусы ЖЦ очень бы помогли выстроить бизнес-процесс единообразно, без всяких там "если забыли".

Конкретно в том примере про сертификаты, что я описывал, большую часть партий товара никто из сотрудников фирмы и в глаза не видел ни разу. ))
Есть экспертизы независимые (если конечный покупатель недоволен). А вообще я очень глубоко в вопросы контроля качества не вникал.

Стандартных возможностей движков воркфлоу, встроенных в ЕРП, обычно не хватает для точной подстройки под подобные процессы. Они (движки) - слишком "прямолинейные".

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

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

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

Типы тегов пользователи сами будут придумывать. То есть они не будут "прошиты" в коде. И пользователи сами и должны будут подумать, какие названия им понятнее.

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

А ведь это должно быть первым этапом проектирования базы, поскольку именно под запросы
строится её структура.

Я подумал, какие отчеты надо делать. ))
Это в самом первом сообщении есть:

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

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

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

Бедный покупатель, кто у продаванов с такой ИУС будет товары покупать. Особенно если конечный потребитель гденить в ипенях, "где даже упряжке полярных собак в любую погоду нет ходу", а без сертификата соответствия, пришедшую партию товара смонтировать ну например на опасный производственный объект нельзя.
У меня для вас плохие новости.
Оптовая торговля - она такая.
Вы поинтересуйтесь ради интереса реалиями торговли нефтью, углем, рудами, металлами, зерном и прочими ништяками, которые принято считать в тоннах. Вас ждет много нового. :))

Т.е. хитрые продаваны саботируют выстраивание шаблонного бизнес-процесса внутри ЕРП, по жёстким рельсам, с жёстким внутренним контролем (в т.ч. контролем наличия и качества прикрепляемой к проводке/партии оптической копии соответствующего документа/пакета документов). Им конечно внесистемно в эксельках подрисовать "как надо" - удобнее. Контролируемый хаос (нихт орднунг) :)
И вы пытаетесь помочь им усилить хаос уже в ЕРП, позволив абы-что прикреплять к абы-чему. ТЗ видимо не владелец бизнеса писал, а сами хитрые продаваны-участники процесса.
Вы в поддержке ЕРП когда то работали?
Достаточно распространенная ситуация, что низкоприоритетные задачи находятся в бэклоге по нескольку месяцев. У меня сейчас висят несколько тасков, еще в 2019 созданных. ))
Так что если у юзеров будет какое то средство, которым они смогут воспользоваться самостоятельно - это будет большим плюсом.

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

Предположим, вы работаете в компании, где внедрена ваша любимая ЕРП с воркфлоу.
В ерп есть список сотрудников.
К вам приходит начальник и говорит - нам надо наладить учет всяких бумажек, связанных с ковидом - все эти тесты, сертификаты о вакцинации / ревакцинации, справки, что человек переболел и прочее, что уже выдумали власти и еще могут выдумать.
Ключевые требования:
1 Надо время от времени формировать отчеты, которые от нас могут запросить разные гос органы о количестве привитых / переболевших / привитых повторно и т.п. Отчеты будет делать аналитик, знающий SQL, с интерфейсом сильно заморачиваться не надо.
2 Надо иметь два отчета, доступные по нажатию кнопки, где:
2.1 Есть список всех сотрудников предприятия на определенную дату, по каждому из которых стоит признак - может он приходить в офис / поехать к клиенту в этот день, или должен сидеть дома.
2.2 По определенному сотруднику (выбор из списка всех сотрудников) надо получить список всех документов (с доступом к сканам), имеющих отношение к ковиду.

Согласитесь, пример довольно животрепещущий и реалистичный? ))

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

Но он же пишет, что решает не эту проблему, а более широкую - как (куда) оптимально прилепить те атрибуты, которые будут критериями отбора "дай мне оплаты, что не прошли акцепт", "дай мне оплаты без счетов-фактур", чтобы отбор по критериям не приводил к 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 .
Предназначена для предприятий среднего размера с соответствующими бюджетами на внедрение и поддержку.
Можно поинтересоваться, о какой именно системе вы говорите (ДМС и БПМС (воркфлоу) вшит прямо в коробку ЕРП)? ))