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

а чем типовой подход не нравиться?

Это должен быть реквизит документа. История не нужна но статусы должны иметь порядок и невозможность возврата.
Как-то : "Заказан - оплачен - собран - отгружен"
Только в таком виде статусы имеют смысл для опер учета.

(2) Как это, "история не нужна"? А вдруг руководство захочет отслеживать, когда произошла смена статуса?

(2) Да ладно. Вот есть, к примеру, у тебя цепочка этапов жизни заказа "К сборке"->"Собран"->"на проверке"->"проверен" и обнаруживается на этапе проверки, что собран заказ неверно. И как ты с невозможностью возврата в таком случае жить будешь? Или захочешь узнать (а руководство точно захочет) среднее время жизни заказа на каждом этапе и отклонения - вот тебе и история пригодится.

(2) интересно, но если это делать через реквизит объекта, то получается при оформления ПКО нужно будет открыть заказ и поменять там статус (естественно программно, но все равно не очень красиво почему-то). А если встанет задача построить отчет (лог) по изменением статуса объектов, то это станет вообще нереальной задачей или я не так понял?

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

(4) Тогда нужна возможность добавить перехода из статуса "Проверка" в статус "К сборке".
Вообще практика показывает, что статус к сборке нужен больше для распределения работы между кладовщиками. Ошибочная сборка это очень большая редкость.

Вы тут чего, бизнес-процессы изобретаете?

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

(0) Изменение статуса - это изменение объекта? Сначала реши для себя (с учетом прав, проведения, закрытия периода, обмена и т.д.)

(10), а что тут решать и да и нет. Создали/удалили заказ, изменение объекта?, да! Приняли оплату, не изменили т объект?, нет!
Повторюсь еще раз, вопрос сейчас стоит. Как лучше сохранять эту информацию базу с наименьшим причинение ущерба для производительности?

(11) хорошо, зайдём с другой стороны:
статусы/изменение статусов чуть ли не в каждой типовой уже есть (УХ, БФ, ДО, УТ...)
чем тебя типовые решения не устраивают?

(12), тем что они в регистр не записывают.

(13) Здрасти, приехали. Это какая типовая в регистр не записывает? Ну мне так для общего развития интересно. По моему все конфы на УФ чисто через регистр работают, чтобы исключить "правку задом".
Ну может УНФ, потому что там инопланетяни пишут

(0) Начни анализ с ожидаемых отчетов. Тогда и с регистром определишься.Конфигурация типовая?
(13) А здесь поподробнее

К примеру типовая БП 3.0
РеализацияТоваровУслуг (статус документ получен), СчетНаОплатуПоставщика (статус оплаты и статус поступления),  СчетНаОплатуПокупателю (статус оплаты и статус отгрузки) -> РегистрыСведений СтатусыДокументов

+ ПоступлениеТоваровУслуг (статус счет-фактуры проведен/не проведен/не требуется)