Коллеги, сейчас думаю, как добавить в 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 По определенному сотруднику (выбор из списка всех сотрудников) надо получить список всех документов (с доступом к сканам), имеющих отношение к ковиду.

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

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