2: Old Nick

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

1) Реализация настройкой выбора полей из српавочников при заполнении форм
2) Генератор процедур (задача была решена только написание своего макро-языка)
3) Наследование документов (вообщем полностью реализовать не смог)
4) Поддержка перечней документов в документах (многоуровневый master-detail)

Но на мой взгляд идея правильная ;)

1) Реализация настройкой выбора полей из справочников при заполнении форм
Как ни странно столкнулся с тем что это одна из самых сложных задач интерфейса.
Например есть счет, нужно выбрать партнера и его расчетный счет.
Есть на форме поля:
код партнера
наименование партнера
банк
РС

И две кнопки, по первой необходимо с возможностью поиска/фильтрации выбрать партнера (возможно с предварительно установленной фильтрацией например только по Юр. лицам), и заполнить поля код/наименование. А по второй из расчетных счетов привязанных к выбранному партнеру выбрать нужный и заполнить поля ID_счета/Банк/Номер счета. При смене партнера очистить поля ID_счета/Банк/Номер счета.

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

4) Поддержка перечней документов в документах (многоуровневый master-detail)

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

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

Old NickЯ писал генераторы для своей системы, даже 2, один скульный, один дельфевый, но пока не использую, причем сделал за несколько часов.
У нас например исходя из настройки и шаблона на макро-языке генерятся достаточно сложные процедуры, включающие в себя проверки, расчеты остатков, проводки... так что при сохранении процедуры получить сообщение об ошибке в 8154 строке очень даже можно было... правда в данном случае это конечно перебор ;)

Old NickА вообще очень дельные замечания. Именно они определяют правильно ли спроектирована система. :-)

Несколько лет потратил на решение подобных задач правда PB - Sybase/MS.

Old NickСистема прав представляет собой матрицу Object, Method, User
Под методом подразумевается форма. Формы бывают всякие, какие

Кстати по поводу допусков, как показал опыт всяких внедрений, для большого количества пользователей структура Object-Method-User неудобна, лучше
Object-Method-Role-User. У нас около 1000 методов (к которым можно дать допуска) и расстановка галочек 5 ролей на 1000 методов это уже утомительное занятие, а на 40 пользователей.... ;(

А вот для маленьких систем я в свое время разрабатывал иерархическую систему допусков, когда у пользователей есть уровень безопасности и у методов есть уровень безопасности (вообщем у документов тоже есть уровень безопасности) и пользователь видит метода с уровнем безопасности <= своего. Закладки в таб-ах, меню, документы в списках тоже зависят от уровня безопасности.

vadiminfoА причем здесь кернел и систем? Ведь там систем - это СУБД, а кернел - это Ось. Я так понял, что это ядро где-то между СУБД и сераерным приложением и (или) клиентским. А реалным ядром ИС считалоась вроде БД.
Не буду спорить на счет терминов, но типичным представителем ядра может служить 1С ;) программирование бизнес логики идет внутри. А само ядро предоставляет функции по работе с бизнес объектами.

vadiminfoНо поскольку идеи с ядрами были всегда, а широкого применения не нашли, мне пока не верится в пользу.
Пример 1С, SAP, Axapta и множества более мелких и менее известных контор и приложений по моему свидетельствует об обратном.