Для одного существующего документа необходимо добавить еще одну табличную часть + несколько реквизитов, так как документов данного вида очень много, добавлять табличную часть в сам документ не хочу.  Эта таблица не всегда будет использоваться и ограниченным количеством  пользователей, поэтому работу с ней я решил вынести в отдельную форму, но вот как хранить информацию решить не могу. Что лучше документ или регистр сведений?

Как хочешь, так и храни.
Сравни предполагаемое увеличение объёмов и принимай решение

Мало информации.

Чтобы решить, как хранить, нужно не только знать, когда, как, кем и для чего информация будет вводиться, но также и когда, как, кем и для чего извлекаться

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

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

(0) Новая таб.часть, конечно. Если она пустая - место на дисках не ест.

(0) >> так как документов данного вида очень много, добавлять табличную часть в сам документ не хочу

Эта фраза вообще не понятна. При чем тут количество документов?...

>> документ или регистр сведений?

Откуда такая альтернатива? Зачем этот геморрой? Чем конкретно таблица регистра сведений будет отличаться от табличной части?
РС: Измерения: ДокСсылка, НомерСтроки. Ресурсы: Нужные реквизиты.
Табличная часть документа: ДокСсылка, НомерСтроки, Нужные реквизиты.
Задачка на найти 10 отличий?...
Ведь с точки зрения объемов в БД эти две таблицы будут почти (если не абсолютно) идентичны.

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

И чисто с практической точки зрения, если данные относятся к объекту, то предпочтительнее хранить их в объекте.

А вот как работать с этими данными - в форме документа или в отдельной форме - решать тебе.

(5) Меня это не интересует

(7) вопрос и был где хранить данные в отдельном новом документе или регистре сведений.
>>При чем тут количество документов?
новая таблица добавится у всех существующих документов, что не может не отразиться на размерах базы.

(9) "новая таблица добавится у всех существующих документов" // На одну ТЧ одного вида документа одна-единственная таблица СУБД создается, прикинь?

+(10) А регистр сведений типа будет не в той же базе? Или наличие регистра никак не скажется на размере?

(10) да , но у каждого существующего документа добавятся хоть и не заполненные реквизиты и пустая таблица, это не повлияет на размер базы?

(12)*каждого существующего документа данного вида

(12) Табличные части - ОТДЕЛЬНЫЕ таблицы. Как и регистры сведений. Об этом тебе уже, в приципе, написали не раз, но ты ж не читаешь

(12) "пустая таблица" в метаданные - да добавится. В табличку хранения пустая не добавится.

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

(12) Куда "добавится"?

(16) Таки да.
И для ТЧ и для РС будет выделена отдельная таблица. Изменения в метаданных практически одинаковые.
Объем данных во вновь добавленной таблице будет также практически одинаковым. За исключением того, что ссылка на документ в случае ТЧ будет организована платформой, а в РС придется городить дополнительное поле самостоятельно.

(16) Жесткий диск на терабайт стоит меньше одного дня работы одинэсника.

(9) >> новая таблица добавится у всех существующих документов, что не может не отразиться на размерах базы

Что?....

(12) >> у каждого существующего документа добавятся ... пустая таблица

Откуда эти фантазии?
Таблица БД с данными табличной части документа хранит только существующие строки. Пустые строки не хранятся. В этом нет никакого смысла.

(16) Бинго!