Собственно вопрос в теме, существует ли в классификации клиента зависимость от периода. То есть, клиент с 01.01.11 по 31.05.11 имеет свойство 1, а с 01.06.11 по текущее время у него свойство 2.
Где можно "держать" такие свойства?

в Z-полях))) расширьте kna1 и экран нарисуйте.

мы так делали для ведения лицензий на приобретение запрещенных препаратов.

на сегодняшний день у меня 7 таких свойств, к каждому делать период это еще 14 полей. К тому же нет гарантии, что аналитики не прибавится еще, очень уж хотят характеризовать клиентов по разному. Поэтому рисовать z поля ну совсем уж не хочется.
Может еще какие-нить предложения будут?

Если срок действия свойства фиксированый то полей периода может быть 7, причем поля дат могут говорит о свойствах, например ZADAT ZBDAT ZCDAT, всего 7 а не 21 как у вас получилось)))

В любом случаем вы будете делать табличку, потому как у вас кол-во свойств не фикс, вам нужно как то будет её динамично расширять.
Я даже уже представил её структуру

успехов!

Спасибо, но я попробую еще поискать варианты.
Например что вы думаете о ДМС, создаем там нужные признаки класса, цепляем через соединение объектов к kna1, если нужно изменить аналитику, то создаем документ изменений и новую версию ДМС, действующую с определенной даты.

скажу вам честно, не знаю, как для значений признаков от клиента по датам, но вот сами значения признаков по периодам можно вести через настройку функциональности SPRO-Компоненты общие для всехприложений - Служба изменений

посмотрите тут, занятная вещица

спасибо, посмотрю.

Периоды и свойства можно вести через классификацию. К примеру, создать признак ZPERIOD и добавить все значения; и создать признак ZEVENT со всеми необходимыми свойствами. Далее зайти в признак ZPERIOD, выбрать значение, к примеру, 01.01.2011 - 31.05.2011, перейти по меню Дополнительная информация - Описание отношений - Редактор и в строке исходного текста набрать что то типа этого: $SELF.ZEVENT = '1' If ZPERIOD = '01.01.2011 - 31.05.2011'. И тестируйте. Подробное описание отношений можно найти в хелпе!

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

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

Такое можно делать через ведение центрального делового партнера (тр.BP)

Я там смотрела, но видимо плохо, раз не увидела. Можно поподробнее?

Смотрите, например, идентификационные номера.
Там можно хранить, например, лицевые счета, налоговые коды, и т.п.