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

С учетом того что данные могут меняться желательно иметь историю изменений поэтому скорее здесь предпочтительней периодический РС. Однако поле Дата может быть добавлено и в ТЧ и в ПС и затем запросом запросто можно получить срез последних

у справочника запросто получить срез?

Я за РС.

(1) Стаж больше 9 лет. Наверное не только у справочника, а даже у константы срез найдёт ;)

(3) LivingStar - у него тоже около 9 лет...

(3) не, я знаю как получить срез у чего угодно, но это будет не проще, чем хранимый срез у ВТ регистра ))

ЗначенияСвойствОбъектов не подойдёт?

На самом деле надо всё это вместе:
1. Подчиненный контрагентам справочник ДопПараметры с ТЧ ЗначенияДопПараметров
2. Периодический РС ДопПараметрыКонтрагенты, измерение Контрагент, ресурс - ссылка на ДопПараметры

(7) Не проще в справочник из 1 реквизит Дата добавить?

(7) лучше тогда уж ПВХ + РС

(0) если история не нужна, то в типовых уже реализовано. Называется Доп реквизиты.

Если нужна история, то проще всего сделать механиз аналогичный ДопРеквизитам (ПВХ + РС) с тем лишь отличием, что добавить туда периодичности в РС.

(5) У ТС нет слова "проще". Это же классика:
"...И можно свернуть, обрыв обогнуть,
Но мы выбираем этот путь,
Опасный как военная тропа!..."

(1,3) плохо sql владеете это классика. Срез последних из реальной таблицы на заданную дату (ReqDate):
Select
    S1.Период,
    S1.Валюта,
    S1.Курс
From
    РегистрСведений.КурсыВалют S1
Where
S1.Период В
(Select MAX(S2.Период) From РегистрСведений.КурсыВалют S2
where S1.Валюта = S2.Валюта
AND S2.Период <= &ReqDate
)

(6),(7) честно не понял идею
Механизм доп свойств не подходит поскольку позволяет хранить только одно значение, а табличную часть нужно заполнять связанными данными. Например, нужно знать в какой документ какую номенклатуру и какое количество нужно заполнять.

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

лично я думаю поступить так:
РС
Измерения:
Период
Контрагент
ВидДокумента
НомерСтрокиДокумента

Ресурсы:
Номенклатура
Количество
...
N Реквизит ТЧ Документа

Сделай как маркетинговые акции в рознице. Тут тебе и периодичность и в документе. )))
А то их незаслуженно пропустили.

(0) если история, то регистр сведений

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

в (12)
у вас будет fullscann. при больших объемах данных из-за (15) произойдет серьезное замедление.
секционируйте явно (разделите на N таблиц например по типам документов). либо переносите данные в архивные таблицы

(0) рс лучше, проще будет с обновлением, единственное рс не умеет сохранят порядок строк, если это вам важно, то придётся подумать о ресурсе для сортировки

(0) Как часто нужны эти данные?

(15)
Если это про историю закупок покупателя
У меня был просто отчет по кнопке в заказе -
показывает что заказывал, что есть на складе цена по какой брал цена нынешняя и т.п. а также "часто с этим берут" и новые   "подходящие" позиции
Менеджер мог сформировать новый заказ по этим данным

(18) порядка 100 контрагентов и пара доков в месяц. при этих объемах замедления не произойдет. можно и по регистру на каждый док, но и так сойдет.
(19) порядок строк без разницы.
(20) данные нужны в раз в месяц для автозаполнения документовв (0) все написано читайте внимательнее.

+15 конечно еще регистратор добавить нужно

(12) Из 1С Вы к 1с-овской базе будет подключаться и юзать select.
Да, я вижу что был прав про простой/сложный путь.
Самое простое и логичное РС.

(22) Только регистр седений