Идея: комментарии к разным сущностям слить в одну таблицу

[mira]

Всем добрый день!

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

Следующий у нас CS. Они вообще "центровые" : и договор заключают, и в производство заказ с их подачи, доставку контролируют, и сервис (монтаж) от них принимает "мяч". У них есть комменты как для себя, так и для других отделов.

В общем, комменты "все со всеми" И "внутри отдела" (т.е. что-то адресуем другим подразделениям, что-то только для себя).

Ессно, родилась идея все комменты сделать на одной таблице, добавив в нее условно "код сущности", вместо (фильтр по *Comment Line* дает нам больше 30 таблиц) трех десятков таблиц. (Формы-интерфейс пользователя под такие запросы отдельная тема)))

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

Усматриваете ли вы минусы подхода "все комментарии держать в одной таблице"?
Я недолго пожила с этой идеей и ничего "страшного" не придумала.

Но не понятно, зачем столько таблиц Comment создатели Nava наплодили? Комментарии это некий сервис, а сервис чем протяжённее, тем продуктивнее.

Буду благодарна, если поделитесь опытом развития "Comment's".
Может, идеи из других систем есть?

С уважением,
Мира

[Captain]

Добрый день,
Вы путаете комментарии сущности с комментариями бизнес процесса. Что вы предлагаете, это на мой взгляд тупик. Если у Вас есть внутренняя система обмена информацией по процессам (хотя бы outlook, SharePoint или иное), может проще это приложение "прицепить" к документам, книгам и.т.п. ИМХО.

[mira]

Цитата:

Сообщение от Captain

Добрый день,
Вы путаете комментарии сущности с комментариями бизнес процесса. Что вы предлагаете, это на мой взгляд тупик.

Captai, наверняка путаю! Но, судя по всему, не одна я )) И чтобы как-то объяснить коллегам, мне надо самой понять.
Пожалуйста, дайте хоть немного фактуры!!!

Почему "на мой взгляд тупик"?! Как тупик будет выглядеть?

Ведь, сущность - часть бизнес-процесса да еще в нескольких "срезах" (пример, сущность = заказ продажи, данные 36 и 37 таблиц формируются разными подразделениями : продавцами, CS , производством и ... остальными).
Можно ли разделять комментарии к сущности (сущность , на мой взгляд, описывает часть бизнес-процесса) и "комментарии бизнес-процесса"?
Я вижу : несколько сущностей содержат данные по бизнес-процессу. Например, продажа от начала до конца: заказ продажи, заказ производства,... производство..., доставка и монтаж, сервисные товары (это если крупными мазками и про таблицы). Я не права?

Шефу только написала, что задала вопрос на форуме "мол, подозрительно", что наше решение расходится с идеей Нав. Отвечает "Ничего подозрительного .. задачу поставил.. тратить время на форум - ваш выбор". Вот такой контекст.

Цитата:

Сообщение от Captain

Добрый день,
Если у Вас есть внутренняя система обмена информацией по процессам (хотя бы outlook, SharePoint или иное), может проще это приложение "прицепить" к документам, книгам и.т.п. ИМХО.

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

С уважением,
Мира

[Captain]

Зацепили!))
Есть правило, информация введенная однократно, должна использоваться многократно. НАВ закрытая система с ограниченным количеством пользователей, которые в ней работают по обязанности или по поступающим уведомлениям. Вывод - уведомления должны быть вне системы. Пример - сотруднику продаж надо что-то сделать, как он об этом узнает? 1.Откроет нав и прочитает сообщение. 2 Получит сообщение по почте с ссылкой на документ и указанием что сделать. После этого откроет Нав. 3 Ничего не узнает, пока не откроет НАВ.4 Ничего не захочет открывать и знать.
Попытки внести комментарии в нав и включить это в процесс, работают только если в данном приложении человек живет, спит и кушает. Если он в нем работает фрагментарно, особенно руководители - вот это тупик (в моем понимании). Удачи!
Я бы в outlook написал макрос на VBA, который сразу генерит задачу и и кляузу руководителю по факту её игнорирования со смайликами типа

[mira]

Цитата:

Сообщение от Captain

Зацепили!))

Цитата:

Сообщение от Captain

Есть правило, информация введенная однократно, должна использоваться многократно. НАВ закрытая система с ограниченным количеством пользователей, которые в ней работают по обязанности или по поступающим уведомлениям. Вывод - уведомления должны быть вне системы. Пример - сотруднику продаж надо что-то сделать, как он об этом узнает? 1.Откроет нав и прочитает сообщение. 2 Получит сообщение по почте с ссылкой на документ и указанием что сделать. После этого откроет Нав. 3 Ничего не узнает, пока не откроет НАВ.4 Ничего не захочет открывать и знать.
Попытки внести комментарии в нав и включить это в процесс, работают только если в данном приложении человек живет, спит и кушает. Если он в нем работает фрагментарно, особенно руководители - вот это тупик (в моем понимании). Удачи!

Captain, большая благодарность! Буду думать.

О! У нас есть система уведомлений : из Нава в outlook.
Разделим : комменты, которые никуда не двигаются (комменты к сущностям) и комменты, которые создают уведомления (комменты бизнес-процессов).
И подружим систему уведомлений и систему комментов, чтобы настройками (и\или пользователем) решалось лететь комменту к адресату или сидеть ровно и ждать, пока прочтут.

Цитата:

Сообщение от Captain

Я бы в outlook написал макрос на VBA, который сразу генерит задачу и и кляузу руководителю по факту её игнорирования со смайликами типа

Спасибо! Интересно! Предложу!

Остался вопрос разделения таблиц.
Т.е. по замыслу демиургов в 30 таблицах - комменты сущностей, а в некой новой таблице - комменты бизнес-процесса?
Так ли они принципиально разделены?
Регламент нужен, и разделение комментов по таблицам, привязанным к сущностям, может быть частью регламента. Если все процедуры устаканились.
А если процедуры не устаканились? Тогда все комменты свести в одну таблицу, чтобы "дорожки" протоптали сами пользователи (пусть договариваются, создают правила, а я буду подкручивать... в крайнем случае из таблицы в таблицу перебросить не сложно).
Пока так думается.

Задумалась, почему "Собрать стадо из баранов легко, трудно собрать стадо из кошек" . У кошек уровней сложности больше? но.. в общем, задумалась )

[Captain]

Остался вопрос разделения таблиц.
Т.е. по замыслу демиургов в 30 таблицах - комменты сущностей, а в некой новой таблице - комменты бизнес-процесса?
Так ли они принципиально разделены?
>>Регламент нужен, и разделение комментов по таблицам, привязанным к сущностям, может >>быть частью регламента. Если все процедуры устаканились.
>>А если процедуры не устаканились? Тогда все комменты свести в одну таблицу, чтобы >>"дорожки" протоптали сами пользователи (пусть договариваются, создают правила, а я буду >>подкручивать... в крайнем случае из таблицы в таблицу перебросить не сложно).
>>Пока так думается.
матрица нужна в нав. Попробуйте её реализовать на 91 (User). Но не явно, а
как подчиненную

[Sancho]

Цитата:

Сообщение от mira

Задумалась, почему "Собрать стадо из баранов легко, трудно собрать стадо из кошек" . У кошек уровней сложности больше? но.. в общем, задумалась )

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

[Sancho]

а вот что меня вымораживает, так это таблицы Users, User Setup, Salesperson, Employee, Warehouse Employee...
а если пользователь еще и менеджер, еще и сотрудник склада...
нафига одно и то же в пяти!!!!! таблицах прописывать?

[DA_NEAL]

Sancho не упомянул что пользователь еще Person и Vendor (в двух типах : физ.лицо и подотчетник), а раз Vendor то до кучи еще и Contact.