Требуется Ваше Мнение По Выбору Варианта Реализации

[phantom76]

Коллеги,

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

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

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

выгядит приблизительно так:

1. название раздела1 , итого по разделу: "сумма"
- пункт раздела 1 количество , единицы изм, цена , сумма
- пункт раздела 2 количество , единицы изм, цена , сумма
................................................................................
.........
2. название раздела2 , итого по разделу: "сумма"
................................................................................
.........

разделов может быть N-ное количество ( но не более 50) пунктов в разделе аналогично. По требованиям документ должен будет трансформироваться в печатную форму или в документ формата Word. Если реализовывать под "толстым клиентом" - вижу только вариант - несколько фреймов, данные структурировано хранить в виде массивов последовательно разделенные по полям, один элемент каждого поля - одна строка из сметы. Для отображения и редактирования конвертировать, для отображения предоставлять навигацию по разделам сметы с отображением текущего раздела через поле - listbox.

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

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

Как например "смету" можно обыграть под XPages?

 

[VladSh]

Совет по варианту реализации - не использовать Lotus для решения учётных/производственных задач. Все продукты такого типа ("Сметы", "Бухгалтерия" и др. монстры) распространения не получили и загнулись (либо им это ещё предстоит), т.к. количество (объёмы) данных в таких системах растут очень быстро, да и обрабатывать их неудобно.
Предложение: вести все эти данные в другой системе, сидящей на реляционке, затем, когда необходимо, выгружаем данные в Lotus, а лучше просто передавать ссылку на эти данные, в котором производим те действия, для которых он предназначен, т.е. проход документа по маршруту согласования со всеми плюшками типа оповещений.. Когда надо, выгружаем результат по согласованию обратно в ту систему.

Добавлено: кстати у нас (на первой Lotus-фирме, где я работал) тоже были "Ресурсы", "Сметы", "Производство", "Заказы", "Склад", "Платежи" и "Бюджетирование", всё сдохло Микроскопы предназначены не для гвоздей.

 

[phantom76]

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

 

[nvyush]

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

Ссылка скрыта от гостей

 

[VladSh]

конечно там не чистый лотус а в связке с DB2.

Предложение: вести все эти данные в другой системе, сидящей на реляционке