С.Быков. Краткий анализ внедрения NEXUS в ПМ.

Nexus - система контрастов. Решения удачные и неудачные, востребованные и нет

Автор: С.Быков. По опыту внедрения ИС в компании Питер-Мобайл

1. Использование ссылок и копий

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

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

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

Второе применение ссылок – выборочное предоставление доступа к администраторским операциям отдельным пользователям. Ссылка на операцию помещается в Личную папку пользователя.

2. Пользовательские отчеты

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

3. Фильтры

Используются для группировки документов по заданным критериям. Есть папки «Не оплаченные счета», «Не отгруженные накладные», «Не отгруженные счета», «Оплаченные счета». Как средство произвольного поиска информации используется только администраторами системы. Обычные пользователи используют только готовые фильтрующие папки.

Эти же фильтрующие папки используются как корни для выбора в таких функциях как «Оплатить сделки».

4. Управление видимостью

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

5. Дробление папок при большом числе документов

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

Большое кол-во документов содержат только служебные папки, которые хранят автоматически создаваемые документы – складские операции и проводки аналитического учета. Доступ к документам из этих папок осуществляется только администраторами, посредством пользовательских фильтров.

6. Importer

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

7. UserAssistant, роли UserAssistant

Широко используется для задания папок для выбора документов, задания значений по умолчанию при создании документов, «закрытие» атрибутов, которые не используются в ПМ. Управление доступом к атрибутам документов по ролевому принципу используется в очень ограниченном количестве. Причины: сложность настройки. А так же не абсолютная защита. Например, _сycl_ может изменить доступ к полю на нежелательное значение.

Роли используются для создания набора стандартных настроек, которые применяются при внесении в систему нового пользователя.

8. ACL

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

9. Расширения: обычные, списковые, сложные списковые со многими колонками

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

10. Экспорт в Word и Excel

Практически не используется. Причины: плохая работа с новыми версиями Office, слабое репрезентативное качество результата. При экспорте в Excel экспортируется только табличная часть, что абсолютно не устраивает.

Потребность в экспорте огромная (см. требования к новому клиенту от ПМ). Но требуется высокое репрезентативное качество и возможность автоматической пост обработки результата.

11. Система полномочий. Роли.

Используется. Я уже описывал, как все устроено. Интерфейс, на мой взгляд, требует серьезной переработки. В текущих условиях, имея навыки и знания, как размещены привилегии в дереве привилегий, управление привилегиями не создает проблем.

12. Автоматическое создание роли по трейсу

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

13. Примитивная почта ядра

Не используется. Я не считаю эту функцию лишней, она является базой для документооборота. Но отсутствие интеграции с e-mail, делает ее самостоятельное использование бессмысленным. Проще позвонить, чем писать записку. Эта функция может быть востребована в более крупных компаниях (по опыту Sellerв ННШ) для рассылок  информации от администраторов системы пользователям.

14. Готовность клиента к документообороту

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

15. Нумераторы

Используются для ведения нумерации по типу оплаты (-/1/2 или бухгалтерские/внутренний учет). Так же задействован агент/контрагент для ведения нумерации в рамках каждой фирмы-партнера. Другие аналитики практически не задействованы. Внедрение ряда доп. классов показало, что набор параметров нумератора должен зависеть от класса документа и его атрибутов. Без МД не реализуемо.

16. Доп. колонки проводника

Используются широко. Одна из основных функций настройки системы, наряду с расширениями, пользовательскими фильтрами и UserAssist.

17. Фича EXE 'связь документов'

Нет. Тяжело расположить окна в оптимальном сочетании. В принципе потребность в такой функции только у администратора. Остальные пользователи «тупым» просмотром документов подряд не страдают. Они всегда осуществляют прямой доступ к документу по ключевым атрибутам – номер, клиент, менеджер и т.д.

18. Хитрые доп. колонки EXE которые создаются по какому либо документу справочнику.

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

Forums: 

Re: С.Быков. Краткий анализ внедрения NEXUS в ПМ.

1
Использование их для создания и ведения альтернативной товарной классификации не представляется возможным, т.к. нет механизмом автоматического создания и размещения ссылок.
...
Используются для группировки документов по заданным критериям. Есть папки «Не оплаченные счета», «Не отгруженные накладные», «Не отгруженные счета», «Оплаченные счета». Как средство произвольного поиска информации используется только администраторами системы.

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

2
А так же не абсолютная защита. Например, _сycl_ может изменить доступ к полю на нежелательное значение.

3
Экспорт в Word и Excel
Практически не используется. Причины: плохая работа с новыми версиями Office, слабое репрезентативное качество результата.

4. Нумераторы
Внедрение ряда доп. классов показало, что набор параметров нумератора должен зависеть от класса документа и его атрибутов. Без
МД не реализуемо.

1 Было бы интересно сделать униварсальный автоматический группиратор на псевдопапках... Я уже вижу как это сделать

2 Не понял

3 Detailed хорошо подходит для экспорта документа в XML. А потом можно запускать .EXE на .net, который все зальет в XLS или Word
Это чтобы не ковырять древний код С++

4 ЧТо такое МД
И как мне помнится класс в нумераторе есть...

Изображение пользователя st.

Серега, а ты не забыл упомянут

Серега, а ты не забыл упомянуть отсутствие такой важной фичи, как поиск документа вводом его имени в поле (автозаполнение) ?
Я чувствую, в ПМ не знают, что такое в природе возможно, а потому кликают мышкой и ползают по папкам.
Если ввод будет более интенсивный, то выбор из проводника не покатит. Оператору, например, нужно будет быстро вбивать товары в состав документа. Он набирает первые буквы называния или цифры кода а в ответ либо автозаполнение поля, либо список из небольшого числа документов, выбранных поиском по этим символам, а пользователь окончательно выбирает уже из него.

Re: С.Быков. Краткий анализ внедрения NEXUS в ПМ.

1 Было бы интересно сделать униварсальный автоматический группиратор на псевдопапках... Я уже вижу как это сделать

2 Не понял

3 Detailed хорошо подходит для экспорта документа в XML. А потом можно запускать .EXE на .net, который все зальет в XLS или Word
Это чтобы не ковырять древний код С++

4 ЧТо такое МД
И как мне помнится класс в нумераторе есть...

1. Можно, но не обязательно. Достаточно комбинации папок и пользовательских фильтров.

2. Есть два атрибута: "мин. запас" (число) и "управление мин. запасом в ручную"(флаг). Если флаг взведен, то поле мин.запас доступно, иначе нет. В _cycl_ стоит проверка, если флаг изменился, то менятся доступность поля. Если я сделал пользователю поле мин. запас RO в UserAssist, но забыл про флаг. То он может получить доступ к полю изменив флаг.

3. Только не плохо, что бы это было завернуто в NEXUS browser, потому что сама идея кнопочки по которой можно бросить данные в Excel или Word очень привлекательна для пользователя. Сама задача не так проста как кажется. Например, в ПМ экспорт в Excel из Cristal Report тоже критикуется, особенно в новой версии 9.2.

4. МД - метаданные.
Класс указывается, но какой класс не указывай, все равно будешь вынужден указывать тип оплаты, агента, контрагента, РЦ, валюту и т.д.

Серега, а ты не за

Серега, а ты не забыл упомянуть отсутствие такой важной фичи, как поиск документа вводом его имени в поле (автозаполнение) ?

В NEXUS такая фича есть!
В ПМ ей не пользуются, т.к. например товары имеют одинаковое начало названия "Чехол для р/т...", а использовать артикул (aka Номенклатор) менеджеры пока не хотят. Если надо вводить большие спецификации, то надо автоматизировать закачку спецификации целиком, а малая механизация - это слабое утешение.

Изображение пользователя st.

В NEXUS такая фича

В NEXUS такая фича есть!
В ПМ ей не пользуются, т.к. например товары имеют одинаковое начало названия "Чехол для р/т...", а использовать артикул (aka Номенклатор) менеджеры пока не хотят. Если надо вводить большие спецификации, то надо автоматизировать закачку спецификации целиком, а малая механизация - это слабое утешение.

Да, я помню, что она есть (использовалась для "Ланы"), но кстати, не помню точно, работает ли она в гридах. Вроде бы нет, только в полях.
По поводу спецификации согласен. Нужно разрабатывать внутреннюю кодификацию и правила именования продукции. А при небольшой номенклатуре это может быть неоправданно, т.к. хватает названия товара, заимствованного у поставщиков.
Хотя если ты говоришь о совпадении первых букв в названиях, то ПМ есть повод подумать о систематизации каталога товаров.

Re: С.Быков. Краткий анализ внедрения NEXUS в ПМ.

4. МД - метаданные.
Класс указывается, но какой класс не указывай, все равно будешь вынужден указывать тип оплаты, агента, контрагента, РЦ, валюту и т.д.

По моему есть такая фича как нумераторы базирующиеся на фильтрующих папках. Для них как раз можно определить все характеристики документа

Еще хотел сросить по две вещи

Папки для создания
И удаленные документы с recycle bin. Undelete

p,s
Извините меня пожалуйцста
Я сегодня не выдержал и сляпал макет универсального группиратора. Завтра он будет представлен на суд публики

Да, я помню, что о

Да, я помню, что она есть (использовалась для "Ланы"), но кстати, не помню точно, работает ли она в гридах. Вроде бы нет, только в полях.
По поводу спецификации согласен. Нужно разрабатывать внутреннюю кодификацию и правила именования продукции. А при небольшой номенклатуре это может быть неоправданно, т.к. хватает названия товара, заимствованного у поставщиков.
Хотя если ты говоришь о совпадении первых букв в названиях, то ПМ есть повод подумать о систематизации каталога товаров.

Работает везде, в том числе и в гридах. Делалось это для Ангелины. В гридах обычно делают так, в столбце Наименование настривают выбор из каталога, в столбце Артикул - выбор вводом.

В ПМ нет проблемы с названиями, они утсраивают как сам ПМ, так и их клиентов. Задачи классификации подчененые в первую очередь маркетингу. Т.е. выделению линий, коллекций и т.д. С другой стороны чехлы классифицированы по моделям телефонов. В результате имеем матричную классификацию, которая находит отражение во многих отчетах предназначенных для маркетинга - наличие на складе, прайс-лист, текущий ассортимент.

Re: С.Быков. Краткий анализ внедрения NEXUS в ПМ.

По моему есть такая фича как нумераторы базирующиеся на фильтрующих папках. Для них как раз можно определить все характеристики документа

Огласи название класса.

Еще хотел сросить по две вещи

Папки для создания
И удаленные документы с recycle bin. Undelete

Папки для создания используются. Основное их назначение - определить место складирования служебных документов - складские операции, проводоки, ряд документов созданных для ПМ, например, корректировка баланса клиента.
Мусорная корзина используется, но не часто. Т.е. раз в квартал возникает необходимость восстановить важный счет или накладную которую удалили не подумав. Это сугубое IMHO, т.к. статистики у меня нет - ни кто не обращается с сообщениями о глюках в этой функции, соотвественно, равновероятно что фукцией не пользуются или она работает абсолютно без ошибок (кто в это верит? :) ).

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

p,s
Извините меня пожалуйцста
Я сегодня не выдержал и сляпал макет универсального группиратора. Завтра он будет представлен на суд публики

Ну и что с тобой теперь делать? :)
Сделал - отлично.
Мне не нравиться твой подход, точнее полное игнорирование стратегии развития продукта. Есть ряд важных задач, которые существенно могут повысить качество NEXUS. Но эти задачи требуют проектирования и серьезной работы по кодированию (больше месяца).
А тут ты видишь как за час можно прикрутить некоторую фичу, которая даже прямо не называлась как потребность. Просто было описано альтернативное решение на существующих средствах. И решаешь воплотить ее в коде. Без иследования как она должна работать, что вообще хочет заказчик и хочет ли он ее. И таких вот фич в NEXUS пруд пруди. Реально они ухудшаю качество продукта, т.к. они, как правило, не описаны (1), делаются "по наитию", по этому не применимы в реальных условиях (см. например, п. 17, 18 здесь)(2).
(1) + (2) = cheap&dirty. :(

Re: С.Быков. Краткий анализ внедрения NEXUS в ПМ.

"Dmitry_Tsuranoff":
По моему есть такая фича как нумераторы базирующиеся на фильтрующих папках. Для них как раз можно определить все характеристики документа

Огласи название класса.

Это не класс
В нумераторе есть Класс а есть Папка
ПО моему надо указывать чтото одно из них
Вместо указания класса создаешь фильтр для этого класса
Указываешь характеристики
Указываешь этот фильтр в нумераторе
Смысл: нумератор срабатывает если документ находится в папке, то есть обладает заданными характеристиками

По поводу твоей критики согласен но вчера не мог удержаться

Действительно можно указать па

Действительно можно указать папку, в том числе и фильтрующую.
Надо проверить, требуется ли в этом случае создаение процедуры GetAttrib_<имя класса>. Мне почему-то кажется, что требуется :(.

Ты обещал опубликовать фичу. И где? Может в выходные побалуюсь.

В нумераторе есть

В нумераторе есть Класс а есть Папка
ПО моему надо указывать чтото одно из них
Вместо указания класса создаешь фильтр для этого класса

Класс - обязательное для заполнения поле. И это - ПРАВИЛЬНО. :)
Далее можно задать параметры, включая папку, они все проверяются на истинность при поиска нумератора.

Действительно можн

Действительно можно указать папку, в том числе и фильтрующую.
Надо проверить, требуется ли в этом случае создаение процедуры GetAttrib_<имя класса>. Мне почему-то кажется, что требуется :(.

Ты обещал опубликовать фичу. И где? Может в выходные побалуюсь.

ЧТо это за процедура ???
Зачем она ?

Фичу скоро опубликую

"Serge

"Sergey_Bykov":
Действительно можно указать папку, в том числе и фильтрующую.
Надо проверить, требуется ли в этом случае создаение процедуры GetAttrib_<имя класса>. Мне почему-то кажется, что требуется. :(

ЧТо это за процедура ???
Зачем она ?

Хорошие вопросы от "главного по ядру". :)
А вот из вредности не скажу, залезь в код и сам посмотри для чего она нужна.
"Учите матчасть" (С) Дымов

ПосмотрелНет, эта процедуру

Посмотрел
Нет, эта процедуру не нужно менять при использовании фильтров
Она не используется

Ты не понял моего вопроса.Я

Ты не понял моего вопроса.
Я о том, что даже если я не задействовал в нумераторе ни одного параметра, то для класса все равно должна быть создана GetAttrib_, иначе FindNumer возвращает ошибку.
Примечание: я не считаю, что это надо сразу исправлять :)