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

[nvyush]

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

Вообще-то принято разделять хранение и отображение данных. Отчёты в ёкселе можно формировать и по представлениям и по многозначным полям. Что касается вариантов — можно использовать внешнюю SQL БД и синхронизировать данные.

 

[Xalet]

думаю встроенное представление не подойдет

почему не подойдет?

 

[alexstudent]

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

 

[Xalet]

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

а кто мешает на форме под(над, ряядом) представлением добавить эти поля с формулами? =) и если сделать форму с динамически добавляемыми полями, как подсчеты будут в них попадать, скриптом обсчитываться во время генерации формы?

 

[nvyush]

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

Лотус — он как бы не для этого предназначен. Можно, конечно, шурупы молотком вколачивать — но зачем?

 

[alexstudent]

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

 

[nvyush]

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

А отдельные документы между собой как-нибудь связаны? Может все вычисления делать в ёкселе, а в Лотусе только хранить екселёвские файлы в виде аттачей?

 

[alexstudent]

Ну в общем дело вот в чем! Пишу базу (автоматизированная система управления производительностью) в одной организации. Есть структура подразделений, у каждого подразделения есть услуги, у каждой услуги состав услуги (множество подуслуг). И для каждой подуслуги услуги каждый период(в данном случае месяц) вносится количество указанных подусулуг в месяц. Количество подразделений огромное, а в дальнейшем примкнут еще таких 4-5 организаций... у каждого подразделения множество услуг, а у них в свою очередь подуслуг. Вы представляете какое количество документов со временем там будет, построение отчетов превратиться в кошмар ночной, а отчеты одна из основных функций. Основная проблема в том, что количество документов растет за счет внесения по каждой подуслуги данных за период, допустим у каждого подразделения в месяц 100 новых документов... а по моей задумке все услуги автоматически заполняются в новой форме автоматически и того вместо 100 всего 1 документ. Просто в скором будущем когда база полноценно начнет работать можно и за тысяч 500 документов перевалить, что оч сильно скажется на производительности.

Добавлено:

А отдельные документы между собой как-нибудь связаны? Может все вычисления делать в ёкселе, а в Лотусе только хранить екселёвские файлы в виде аттачей?

Нет так не пойдет!

 

[nvyush]

Что-то мне кажется, что это лучше на реляционной БД делать. Почитайте про DECS, LSX - может это больше подойдёт

 

[alexstudent]

Так все таки можно программным путем создать поле "на форме", чтобы оно отображалось при открытии???

 

[nvyush]

Так все таки можно программным путем создать поле "на форме", чтобы оно отображалось при открытии???

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

 

[K-Fire]

Услуга - документ
Подуслуга - документ
в форме подуслуги - таблица с 12ю строчками, и нужными вам столбцами.
Добавляете поля col1_1... col1_12, col2_1... col2_12 и т.д.

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

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

 

[TIA]

Так все таки можно программным путем создать поле "на форме", чтобы оно отображалось при открытии???

Динамическое создание полей на форме Вам не поможет. Не будете же вы для каждого документа по своей отдельной форме делать!?

 

[turumbay]

Так все таки можно программным путем создать поле "на форме", чтобы оно отображалось при открытии???

Можно(см. ответ nvy про dxl). Но не нужно(см. тот же ответ).
Вы хотите для ста разных подуслуг поиметь сто разных полей?
1. Кол-во полей в nsf ограничено:

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

2. У меня эта задача ассоциируется с выставлением счетов на продажу.
Счет = таблица: товар, кол-во, цена.
Никто ж не решает ее через заведение отдельного поля в счете для каждого товара...
Реализация: на многозначных полях с разделителями "new line".
В вашем случае документ может выглядеть примено так:
на форме таблица с тремя колонками. в каждую колонку по полю:
поле: код услуги( тот же unid документа, описывающего услугу; можно скрыть )
поле: наименование услуги - computed по коду ( @DbLookup )
поле: кол-во: редактируемое.
плюс UI-шные феньки( если нужны ):
-черезстрочная разлиновка таблицы при помощи backround-image( эффект как у вью: alternative color )
-проверка соответствия размерности полей - напр. на js
-придумать по вкусу...
вот и весь нехитрый дизайн...
Структура LS дял работы:

Class ReportRow
private id ' код услуги
private amount ' сколько раз оказана
End Class
Class Report
private report_id ' ключ документа
private rows() As ReportRow
End Class

 

[Medevic]

Я бы сделал отображение через richtext и html.

 

[TIA]

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

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

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

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

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


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

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

и т.д.

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

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

 

[Xalet]

А услуги и подуслуги физически чем связаны?

 

[alexstudent]

Всё связано унидами! В каждом документе услуги унид подразделения оказывающего услугу, в каждом составе услуги тоже унид подразделения и унид услуги... всё связано! Ребят сейчас убегаю из дома напишу четкую постановку... спасибо что откликнулись =) Реально помощь нужна!

 

[nadezdaMP]

Так все таки можно программным путем создать поле "на форме", чтобы оно отображалось при открытии???

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

 

[allex]

Поддерживаю nvy здесь целесообразнее было бы связать с реляционной БД, Появятся + и -, но вы зато уходите от проблемы в создании дополнительных полей, скорости обработки и возможных сложностей в текущих вычислениях.
У вас на первых порах все будет считаться, крутиться и вертеться. Но при учете масштабирования проекта ваша задумка может прогнуться.
Тащить за собой структуру реляционки может не совсем удобно, но зато с продуманной структурой будет в дальнейшем проще