Коллеги, возникла следующая проблема.
Вешаю на точку измерения два класса: один содержит служебную информацию за прошлый период, другой за текущий.
Признаки в обоих классах называются одинаково. Когда присваиваю значение 11 признаку Priznak01 класса текущего периода TEK, значение у признака Priznak01 класса прошлого периода PROS тоже становится 11.
Можно ли как-то работать с признаками имеющими одинаковые имена, так чтобы можно было их менять независимо?

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

Ключевые поля AUSP:
OBJEK Ключ классифицируемого объекта
ATINN Внутренний признак
ATZHL Счетчик характеристик признака
MAFID Индикатор: объект/класс
KLART Вид класса
ADZHL ВнутрСчетчик для архивации объектов посредством СлужбыИзмен

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

Сделай отличный принак (Priznak02 ) и все будет ок, в принципе он и должен быть у тебя отличным от первого по его id, поскольку подспорье для использования немного другое.

Дык это то понятно...
Обошлись префиксами для признаков.
А какое другое подспорье для использования двух классов?

Можно создать другой вид класса, тогда проблем с разграничением не будет даже на одних и тех признаках

В моем случае необходимо будет создать 11 новых видов классов, т.к. на одну ТИ нужно вешать до 12 классов.

Зачем так много? Почему так получается?

Мы помимо наработки, ведем еще информацию о времени простоя (время простоя в ремонте, в резерве, на вынужденного простоя, в т.ч. из-за отстуствия запчастей, реконструкция - 5 видов простоя). Вся эта информация ежемесячно сохраняется в ДИ (времена простоя сохраняются в расширении ДИ - 5 дополнительных полей). Помимо ежемесячной наработки, также ведется посменная, каждые 12 часов. По ряду причин посменная наработка ведется не в ДИ, а сохраняется значение наработки и простоев за каждую смену месяца, а в конце месяце все эти значения суммируются и идут в ежемесячный ДИ. Посменная наработка хранится за 2 месяца: текущий и прошлый. Таким образом нам необходимо 12 классов: 6 классов с ежедневными наработкой и 5 простоями (по 62 смены в каждом классе) умножить на 2 месяца - текущий и прошлый.
Сорри если сумбурно...

да, что то не совсем понятно.
На сколько я понял, что данные о простоях и ежесменных наработках вы временно храните в классификации, а потом переносите в ДИ (сводно за месяц), так?
Ну не совсем понятно - зачем так мудрено надо?
Кроме того, даже естли предположить, что этого изменить нельзя (в чем я сомневаюсь:-)), то зачем 6 классов на ежедневные наработки? почему нельзя обойтись одним с 62мя признаками?

Почему не стали делать ежесменные ДИ: до этого была проработана схема с ежемесячной наработкой, к ней были привязаны расширения, отчеты и т.д. Потом заказчик захотел перейти на ежесменный учет, от слома старой схемы и соотв. переделок отказались.
Информацию где-то надо было хранить, решили использовать классы.
Почему 6 классов, а не один: дык на каждую смену не только наработка может приходиться, но и разные виды простоев, например 3 часа в работе, 3 в ремонте, 6 в резерве. Вот так.

Так может просто сделать еще одну точку измерений, и для нее делать нормальные ДИ?

Была такая мысль, но т.к. про такую проблему с классами тогда не знали, утвердили схему с классами.
Также заказчик сказал что так слишком много ДИ в системе будет накапливаться. Но если честно, по сравнению с объемами других документов это ничтожное количество.

А схему переутвердить?
Кроме того, признаки точно так же будут занимать место в таблицах. А лишние ДИ потом можно легко архивировать. Но только оно надо? )

Согласен коллега, но спека была на половину написана (заказчик требует переписать интерфейс ввода ДИ, фактически мы разработали отдельное приложение для работы с наработкой). А за срыв сроков - расстрел и четвертование.