Архитектура конфигурации, которую я пишу, на мой взгляд достаточно необычна. В данной конфигурации должны учитываться множество справочников и их реквизитов, состав которых может очень сильно меняться от фирмы к фирме. Поэтому от решения делать какой-либо фиксированный набор справочников и реквизитов было решено отказаться. А сделать этот механизм на базе характеристик. Т.е. у нас есть справочник типов объектов, и для каждого элемента есть возможность определять набор реквизитов и свойств. На основании этого набора реквизитов, для объекта автоматически генерируется форма. При построении отчетов СКД, подхватывает все характеристики, что очень удобно при построении отчетов.
Скриншот рабочего стола:
http://s006.radikal.ru/i215/1108/c5/5d6d5a3791c9.png
Скриншот генерируемой формы:
http://s006.radikal.ru/i215/1108/c5/5d6d5a3791c9.png
Важно ваше мнение о данном решении Может кто-то уже сталкивался?

Sorry, ошибка вышла:
*Скриншот рабочего стола:
http://s006.radikal.ru/i213/1108/82/a4d584a3e68f.jpg

ап

"Поэтому от решения делать какой-либо фиксированный набор справочников и реквизитов было решено отказаться. "

Капец

(3), можно по-подробнее обосновать, что не так

(0) Велосипед.
В СКД точно потом ошибки не всплывут? =)

(0) это твой диплом?

есть определенные справочники, базовые, например Физ.Лица и др. а есть другие простые справочники, объекты которых надо учитывать, состав которых учитывать

(5) Почему велосипед. Нет СКД замечательно работает с этим механизмом

(6), нет не диплом

>>множество справочников и их реквизитов
а если добавлять реквизиты в справочники программно из кода;)

Не понял вопроса... у меня вот так форма выглядит автособираемая http://screencast.com/t/1MHbrPbbl

Если это решение плохо, то как выходить из ситуации, когда в одной организации нужно учитывать всего 5 объектов, при этом набор реквизитов у них один, а в другой организации 100 объектов со своими реквизитами?

(9) курсовая?

(11) вопрос в том, можно ли с помощью механизма характеристик и автогенерируемых форм, сделать гибкий механизм по учету различных объектов. Или следует применить какой-либо другой?

(12) бери БСП и перенеси из него подсистему свойств, будет быстрее и качественнее... там как раз в основе ПВХ, Справочник доп. значений и РС с значениями

(13), нет и не курсовая, я пытаюсь сделать прототип по учету и хранению объектов, на базе которого будут строиться другие механизмы

(14) у Инталева это Проформами называется. Можно, ты же сделала =)

(12)
>> то как выходить из ситуации, когда в одной организации нужно учитывать всего 5 объектов, при этом набор реквизитов у них один, а в другой организации 100 объектов со своими реквизитами?
Имхо нормально.
(15) прав насчет БСП, там это должно быть реализовано.

(0)
1. Свойства - это всегда лишние джойны - везде.
2. 1 Объект - 1 Свойство - 1 Значение.
3. Вообще вся эта идея дурно пахнет.

(15), Спасибо, посмотрю. а там можно с помощью БСП, описывать "табличные части" объектов?

(20) нет. Там и список свойств в отдельном окне открывается...

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

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

(21)Спасибо, БСП я видела, думала может в последних версиях есть какие-либо еще изменения.

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

(24) И, как кто-нибудь сделал более удобный?

(0) >> у нас есть справочник типов объектов

Этот справочник называется План видов характеристик

>> для каждого элемента есть возможность определять набор реквизитов и свойств

Обычно этот набор определяют в регистрах сведений Назначение свойств объектов и/или Значения свойств объектов.

А вообще смотри БСП. Там есть готовая подсистема свойств и характеристик. И не надо изобретать своих велосипедов с квадратными колёсами, а то еще, не дай бог, начнешь себе думать, что программист - творческая специальность.

(24), требование есть - гибкость, а как ее реализовать - вопрос...

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

(24), (28) +100!
(27) предоставь им пустую конфу, и инструкции по открытию 1с в режиме конфигуратора!

(26), я знакома с механизмом характеристик и БСП. и "Типы объектов" - это справочник, в котором есть ТЧ, которая содержит характеристики(План видов характеристик), значения которых потом записываются в РС

(25) Заканчивается это тем, что сам программист начинает теряется в многочисленных настройках. А запустить с нуля новую систему на такой конфигурации... Про это уже и не думает никто.

(31), это основано на личном опыте?)

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

(32) Да, проходили.
И гибкость это совсем другое. То что вы пытаетесь сделать в (0) это будет наоборот не гибко. Потому что если изменится бизнес-процесс - все эти характеристики вас не спасут. А доработать этого монстра будет гораздо сложнее, чем "стандартное" решение.

(33), это уже сделано в виде требований и ТЗ. Требование к этой подсистеме гибкость в добавлении новых объектов учета. Изначально ограничение на справочники, хранимые таким образом, что это будут простые справочники, которые должны просто отображать и хранить реквизиты, определенные им.

(34), а какие задачи решались?

(35) объектов учета чего?
что учитывать то будем, как, какие показатели - количественные и суммовые требуется отразить в системе?

(35) Угу. Окончится это одноразовым желанием расширить аналитику накопительного регистра или "добавить субконто"(с).

(37) объектов учета научной деятельности, количественные

(39)что характеризует каждый объект учета, чем он отличается от других?

А названо-то как - _архитектура Решения_.

В (19) всё четко сказали насчет этой дурости.

"При построении отчетов СКД, подхватывает все характеристики, что очень удобно при построении отчетов. "

Ага мля, забесплатно.

(0) Вот судя по названию вы занимаетесь НИОКРами это совершенно конкретная деятельности. И если вы делаете это для ВУЗов обращайтесь в СГУ-Инфоком или СГУ-Информ, там люди вам помогут. Нет никаких плавающих понятий в учете НИОКРов, надо разбираться, а вы не можете уместить в голове сложную систему и идете путем непонятной универсализации. Ни один человек в итоге работать в этом не сможет ИМХО.

(39) - какую либо сущность(диссертацию, выставку и др.) которые отличаются составом реквизитов

(43) что мешает добавить справочники Диссертации, Выставки со своим составом реквизитов???

(0) можно посмотреть, как в "Документообороте" сделан справочник "Договоры", кажется.

Хотя по мне там некрасиво

(45) а, не договоры, а внутренние документы вроде

А главное - чего ради?? От "нету реквизита" - до "есть реквизит" - пара кликов мышью на рабочей базе. Всё.

Тот же SYNC FW требует -
1. Deprovision/provision DB
2. Генерация серверных классов
3. Генерация клиентских классов.
4. Перекомпиляция.

Тут реально задумаешься о своем "конфигураторе".

Но когда 1С-ник начинает городить такую фуету - это лишь говорит о его некомпетентности.

(44) могут отличаться состав реквизитов и вообще наличие этих объектов в системе.

(42), спасибо за совет, воспользуюсь)

(48) хорошо, каждый объект характеризуется набором собственных реквизитов и т.п.
есть ли группы объектов, имеющих родственные(одинаковые) признаки? Сколько таких групп?
Про наличие объектов - это несущественно

(50) Ты решил моделирование предметной области за ТС провести ? )

(51)подтолкнуть, не более того)

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