Автоматическое построение формы.

[erdi]

Программным путем можно, то только через dxl. Но dxl ошибок не прощает!

Количество подразделений огромное

Сколько? порядок хотя бы 10, 50, 100, 500, 1000?

отчеты одна из основных функций

Если отчеты главная функция - забудь про лотус!!! В этом случаи тебе придется либо полностью от него отказаться, либо делать связку с sql базой. И отчеты строить из sql базы. Оптимальное построение отчетов у меня было при кол-ве документов в отчете до 25000, потом уже неприятный напряг
Самое простое, но муторное решение это сделать таблицу с полями и с максимальным числом строк, где каждая строка это документ и формулу скрытия строк от кол-ва документов. Если документов будет 100, то будет табл из 100 строк с полями, если 200, то надо будет делать табл на 200 строк

 

[alexstudent]

Подразделений 1115, но учитывая перспективу организации со временем, может лет через 5 или более, их количество увеличится до 7000-8000 если не больше. ERDI не понял 25000 документов в отчете или построение отчета при 25000 документов в базе? Да отчеты и dash-bords одна из основных функций, база будет хранилищем данных с автоматическим подсчетов количеством носителей затрат (т.е. сбор количества заявок и т.д. из других баз). Затем каждый руковоидетель мог бы строить отчет для своего подразделения по выработки производительности подразделения. Сколько по времени у тебя строились отчеты? (вопрос для ERDI).

 

[VladSh]

alexstudent, если под браузер писать, то можно. Но оно того не стоит, т.к. точно сказал nvy: это задача для систем, построенных на РДБ, а не на Lotus. Писать такое на Lotus - сознательно идти на проблемы; в будущем всё сведётся к переписыванию приложухи под реляционку (это вопрос времени), а там переброска данных в реляционку и т.п. - матом крыть будут - о-ё-ёй!..

 

[alexstudent]

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

Теперь нам надо для каждого <подразделение,услуга> поставить в соответствие список <год,месяц,число_услуг>. Для этого можно

1) завести документ, содержащий
- ссылку на одно подразделение
- ссылку на одну подуслугу
- 12 полей с числом услуг по одному на каждый месяц.
- год

2) Можно завести документ, содержащий
- ссылку на одно подразделение
- список услуг подразделения
- 12 списковых полей с числом услуг, синхронных со списком услуг подразделения. По одному полю на каждый месяц.
- год

3) Можно завести документ, содержащий
- ссылку список подразделений
- ссылку на одну услугу
- 12 списковых полей с числом услуг, синхронных со списком подразделений. По одному полю на каждый месяц.
- год


4) Можно завести документ, содержащий
- ссылку список подразделений
- ссылку на одну услугу
- 12 списковых полей с числом услуг, синхронных со списком подразделений. По одному полю на каждый месяц.
- год

5) Можно завести документ, содержащий
- ссылку на одно подразделение
- ссылку на одну подуслугу
- списковое поле с числом услуг. Каждый элемент списка - число услуг за месяц.
- год

и т.д.

При хранении данных в документах-отчётах структуры №1, для отображения всех услуг, оказанных подразделением,
делаем:
-у подразделения делаем встроенную вьюху
-во вьюху отбираються документы-отчёты
-вьюха категаризованна по UNID подразделения
-синглкатегори по UNID текущего подразделения
-вторая категаризованная колонка - год
-третья колонка - подуслуга
-остальные 12 колонок - отображают 12 полей с числом услуг.

Вобщем, это один вариант и множества. Выбор структуры хранения зависит от объёма тех или иных данных и требований с способу отображения. Отображение - от способов использования информации юзерами.

Вот я использую документ похожий на структуру №1. Один документ в нем указывается подразделение и его унид(скрытое поле), затем по униду выбираешь одну из услуг этого подразделения(отобранных по униду подразделения) в диалогвом окне, затем после того как выбрал услугу становятся доступными её подуслуги (отобранные по униду услуги), выбираешь период и вносишь вручную количество выполненных подуслуг. И того получается один документ на каждую подуслугу. А если 20 услуг и у каждой 20 подуслуг, то 20х20=400 документов от одного подразделения за один месяц. Хранить сразу все поля всех периодов не удобно! А мне хотелось бы чтобы был один документ на одно подразделение за один период со всеми подуслугами услуг... открыл, подтянулись автоматически все подуслуги услуг внес сразу все количества оказанных подуслуг (потом кстати планируется автоматический подсчет этого количества из других баз) и всё один документ! Просто отчеты строятся путем поиска по униду для одного подразделения и сложения количества оказанных подуслуг и путем перебора всех документов и сложения количества оказанных подуслуг для всех подразделений. Отчеты хоть и будут не часто использоваться, но думаю со временем там просто будет уйма документов и все это дело будет жутко тормозить!!! При этом в базе порядка 50 представлений для разных отчетов и манипуляций по унидам, а это оч плохо для производительности. Кстати какой предел оптимального количества документов для базы???

 

[Constantin A Chervonenko]

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

А хоть-бы и не Лотуса
Форма - это код, интерфейсная программа. Просто в LND она хранится там-же, где и данные, а при СУБД+Дельфи это будет .exe-шник (.dll)

Можно "на лету" под любой док-т генерировать свой ехе-шник, со своими контролами, окошками и кнопками? В принципе - да: макрогенератор+компилятор+линкер. В LND этому пути есть эквивалент - DXL

Можно сделать некую "универсальную" форму для достаточно широкого подмножества док-тов. Такую-же можно сделать и на LND!

Добавлено:

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

Как раз - ничего сложного: состряпать форму, которая будет отображать ВСЕ поля док-та. Про СуперФорм не слышали (всё уже украдено до нас!)?

Но как потом этим пользоваться в мирное время, если полей более 10 и/или они взаимосвязаны? (СуперФорм - это хаЦкерский инструмент)

 

[turumbay]

... становятся доступными её подуслуги (отобранные по униду услуги), выбираешь период и вносишь вручную количество выполненных подуслуг. И того получается один документ на каждую подуслугу. А если 20 услуг и у каждой 20 подуслуг, то 20х20=400 документов от одного подразделения за один месяц.

ну дык храните 1 документ 400 строк:
ключ подразделения, период, плюс таблица 400x2: ключ подуслуги - кол-во. итого 4 поля.

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

именно так и получица.

 

[alexstudent]

ну дык храните 1 документ 400 строк:
ключ подразделения, период, плюс таблица 400x2: ключ подуслуги - кол-во. итого 4 поля.

именно так и получица.

Так количество услуг и подуслуг у всех разное, поэтому я и спрашиваю как бы программно и не сильно навороченно нарисовать форму.... и вообще возможно ли это... и стоит ли заморачиваться. По желанию чтобы были поля, а не строки в многозначных полях. По мимо скрытых полей (униды) были в одной строке для первой услуги: Услуга - Service_1 Состав услуги - CostDriver_1 носитель затрат - NemeDriver_1 количество носителя затрат Fact_1. Следующая строка для следующей услуги: Услуга - Service_2 Состав услуги - CostDriver_2 носитель затрат - NemeDriver_2 количество носителя затрат Fact_2. И т.д. Как отыскивать документы с услугами это не сложно, по униду подразделения смотреть услуги, по униду услуги смотреть подусулги. Записываем в коллекцию все услуги подразделения по униду, берем первый документ из коллекции с услугой и по её униду записываем в другую коллекцию все подуслуги, затем берём первую подусулгу и начинаем создавать на форме поля как я описал выше и так с каждой подуслугой и все это желательно в таблице.

 

[nvyush]

alexstudent

... и начинаем создавать на форме поля ...

Лотус - это не с или дельфи. Он не может динамически создавать форму в памяти. Форма - это особый документ в базе. Можно динамически сгенерить форму в памяти в виде дхл, но перед использованием её нужно обязательно сохранить в базе. Будете создавать формы под каждый документ? Конечно, можно удалять форму после закрытия документа, можно хранить форму в самом документе, но в любом случае, то, как Вы собираетесь реализовывать выльется в жуткий тормоз, да и да малевича недалеко. Кстати, для создания форм нужны права как минимум дизайнера. Откажитесь от этой идеи, пока не поздно, и направьте Ваши усилия в более конструктивное русло.

 

[turumbay]

По желанию чтобы были поля, а не строки в многозначных полях.

Это чье желание? Ваше или заказчика? Если заказчика - то пусть подвинется. Это детали реализации, которые никому кроме вас знать не положено. Ваше дело - предоставить интерфейс( API )

для первой услуги: Услуга - Service_1 Состав услуги - CostDriver_1 носитель затрат - NemeDriver_1 количество носителя затрат Fact_1. Следующая строка для следующей услуги: Услуга - Service_2 Состав услуги - CostDriver_2 носитель затрат - NemeDriver_2 количество носителя затрат Fact_2. И т.д.

Ну нафига вам куча полей? Вы бы в реляционке тоже поля в таблицу добавляли? Поля - это столбцы. А вам нужны строки. Строки в LN - это многозначные поля.
для первой услуги: Услуга - Service[1] Состав услуги - CostDriver[1] носитель затрат - NemeDriver[1] количество носителя затрат Fact[1]. Следующая строка для следующей услуги: Услуга - Service[2] Состав услуги - CostDriver[2] носитель затрат - NemeDriver[2] количество носителя затрат Fact[2]. И т.д.

все это желательно в таблице.

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

З.Ы. можно отрисовать таблицы неральной красоты, с использованием html import. с кликабельными строками и прочими рюшками...

 

[alexstudent]

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

Не подскажешь как?

 

[turumbay]

Не подскажешь как?

link removed
про html:
notesuidocument.import()
т.о. можно импортировать html-таблицу.
при формировании таблицы - на строки вешаются вызовы типа <td><a href="java script:myFunction( номер строки )">текст ячейки</a></href>
в загловок формы jsheader: function myFunction( rowId /*GUID*/){}
вместо uidoc.import можно использовать апишную. т.о. импорт можно выполнять в бэкенде

Добавлено: таблица без html(по многозначным полям):

 

[alexstudent]

а можешь скинуть код документа который на картинке??