Описание можно скачать здесь

http://webfile.ru/5451248

Это не реклама, просто хочу узнать мнение

Система документооборота

Система поддерживает:
- Модульность
- Расширяемость
- Систему прав доступа
- Встроенный Data Flow
- Генератор форм
- Редактор форм
- Встроенный язык программирования
- Систему логгирования

Oracle + Delphi

Документооборот состоит из следующих частей:
- Диаграммы процессов
- Дизайн форм для каждого состояния процесса
- Определение процедур, срабатывающих на событиях компонент

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

Диаграмма уровня документа

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

Рассмотрим низкоуровневый процесс оформления приходной накладной.
Допустим, что в формировании приходной накладной участвуют люди, работающие в разных отделах и имеющие различные привилегии.
Определяем путь документа между отделами
В данном примере в оформлении документа участвуют 2 отдела:
- Отдел закупок
- Склад
- Бухгалтерия

Схема прохождения документа Приходная накладная

Дизайнер форм предназначен для:
- Дизайна формы для конкретного состояния и роли пользователя
- Программирования действий на события компонентов формы
- Отладка

Внешний вид редактора форм напоминает среду разработки Delphi, но вместо палитры компонент определяется
- Проект
- Модуль
- Форма модуля
- Роль пользователя
- Диаграмма
- Состояние
- Основные свойства формы – размер, заголовок

Все это определяет свойства формы для роли пользователя и состояния.

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

Режим дизайна обеспечивает:
- Перемещение компонентов по форме
- Установка видимости, доступности, очередности, текста по умолчанию, шрифта
- Определение процедур, выполняемых при определенных событиях компоненты
- Локальные переменные, используемые процедурами

Допустим, что для формирования ключа документа нам необходимо указать номер документа + дата документа в формате
«№ + номер документа + от + дата документа»
Для этого перед запуском процедуры сохранения, необходимо выполнить процедуру склеивания rbConcat.
Заполним параметры процедуры следующим образом

Такким образом в процедуру склеивания мы передаем 4 параметра
1 - "№"
2 - Значение компоненты eDocNum (TEdit)
3 - "от"
4 - Значение компоненты dtDocDate (TDateTimePicker)

на выходе получаем строку, сохраненную в локальную переменную

На рисунке показан результат работы процедуры rbConcat. В нижнем левом окне показаны входящие параметры p1-p4, в левом нижнем – значение выходного параметра,
В левом верхнем окне показана переменная и ее значение – результат работы процедуры.

Использование логических процедур и процедур перехода

Для переходов к различным процедурам используются процедуры сравнения и метки.
Рассмотрим следующий промер. Допустим номер документа имеет следующую структуру:
- 1-й символ – код валюты (U – доллар США, E – Евро, R – Российский рубль)

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

Начало работы – определен первый символ номера документа

Пользователь ввел первую букву Е в номере документа, прошла проверка по правильности ввода, определелся код валюты и расшифрованный код валюты добавлен к номеру документа

Код как раз и не формируется.
Компилить ничего не надо.

Пакет BPL в Delphi - это таже самая DLL, в которой хранятся формы для работы с таблицами БД.
Регистрация пакета - это указание имени пакета с относительным путем к нему. Плюс осуществляется сканирование форм, находящихся внутри пакета и выбор формы, которая будет открываться при выборе пункта меню.

Вот ссылка по созданию пакетов в Delphi

http://wm-help.net/books-online/book/56472/56472-96.html

AlexsalogСистема супер.
Вопрос - модель данных пляшет от форм и процедур, а не наоборот? то есть модели, которая бы порождала действия и логику - нет ?

Как модель данных может порождать логику?

Этапы построения такие
1. Формирование модели данных (справочники, документы)
2. Разработка диаграм бизнес процессов на верхнем(логическом) уровне и на нижнем(уровень документа)
3. Генерация форм на основе модели данных, создание модуля (BPL), регистрация в системе и привязка к диаграмме (в одном проекте у модуля может быть одна диаграмма, если надо для одного документа (модуля) сделать разные диаграммы, то их надо раносить по проектам. Например для накладной в центральном офисе один маршрут, а в филиале для этого документа будет другой маршрут и другие уровни доступа)
4. Дизайн форм для каждого состояния в разрезе ролей (в зависимости от прав доступа пользователь может видеть или не видеть контролы на форме)
5. Создание обработчиков событий для контролов по каждому состоянию и роли. Например кнопка Далее для каждого состояния может иметь разные обработчики.

Вот собственно и все.
Оптимально для разработки нужны
- аналитик для описания диаграмм
- разработчик БД для создания объектов в базе
- программист Delphi для написания низкоуровневых процедур
- программист-кастомайзер для написания обработчиков из низкоуровневых процедур

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

В диаграмме надо описывать состояния и их связи.
К модели данных диграмма не привязана. По одной диаграмме может работать несколько документов
В коде (в модуле BPL) пишутся процедуры, уникальные для конкретного документа, но запускаются они будут из определенного состояния. Например кнопка Далее в состоянии создания нового документа будет выполнять INSERT, эта же кнопка в следующем состоянии будет делать UPDATE. Какие процедуры и в каком состоянии запускаются определяются в дизайнере форм.

AlexsalogSergey_rbВ диаграмме надо описывать состояния и их связи.
К модели данных диграмма не привязана. По одной диаграмме может работать несколько документов
В коде (в модуле BPL) пишутся процедуры, уникальные для конкретного документа, но запускаются они будут из определенного состояния. Например кнопка Далее в состоянии создания нового документа будет выполнять INSERT, эта же кнопка в следующем состоянии будет делать UPDATE. Какие процедуры и в каком состоянии запускаются определяются в дизайнере форм.

Хорошо, а вот та самая логика поведения контролов на форме, о которой я говорил - она как? Кодом реализуется? Или автоматизируется системой как-то ?

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

iscrafmSergey_rbДиаграмма уровня документа


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

Диаграммы хранятся в базе. Каждый объект имеет свой ID.
ID объекта - это ID состояния документа, ID стрелки - это ID выполненной операции.

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

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

Выложил описание, как можно использовать диаграммы для работы со справочниками
http://webfile.ru/5550924

Решил прикрутить к системке интеграцию с 1С 7.7 DBF версии.
Оказалось не так уж и сложно.

Теперь задумался о настраиваемой интеграции с различными серверами.

Маланин АндрейА почему "радактор"?

От сердца отлегло.
А то я уже подумал, что написал систему и ни одной ошибки не сделал

Tango600А где же система?

Я на нее пока забил.

ЛагманЭто может быть киллер-продукт, если будет всё в веб-интерфейсе, с упором на распределенную структуру предприятия, а пока непонятно, кому это можно продать.
Delphi, окошки, при всех достоинствах - просто огромный минус к имиджу, имхо.
Надо что-нибудь более модное, а главное более-менее стандартизированное, с сервером приложений, майкрософт, оракл, java, например.

Дело в том, что на вебе невозможно реализовать то, что можно реализовать на Дельфи.
Даже DevExpress компоненты в веб-версии имеют очень ограниченные возможности.

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

Было несколько проектов на 3х-звенке и везде 3 звено было самым слабым.
Если надо обеспечить работу большого числа пользователей, то проще вынести листенер на отдельный сервак и работать как с 2х-звенкой.

Alexander2Sergey_rb,

Понравился подход с использованием диаграмм. Как с вами связаться? Мой мыл действительный.

e-mail скрыт...

OrinSergey_rb,

почему забил?

Уже не знаю, что еще бы прикрутить...