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

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

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

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

Точнее сказать - в документе был бы реквизит, в котором указан элемент справочника с дополнительными данными.
В том случае, когда наборы дополнительных данных, которые нужно указать в документах начинают совпадать на 100%. Это и удобство работы и управления данными в дальнейшем и меньше занимает место в базе данных, т.к. в документах с одинаковыми наборами доп. данных будет хранится всего лишь ссылка на элемент справочника. А сами доп. данные в виде элемента справочника будут записаны единожды в базу данных. Не будет дублирования.
---
В каком случае необходимо использовать не табличную часть документа, а отдельный справочник, где бы заполнялись также данные и ссылались на нужный документ? Не улавливаю логику правильности подхода...
Если вы действительно рассматриваете вариант "отдельный справочник, где бы заполнялись также данные и ссылались на нужный документ", то не вижу разницы между "создана табличная часть с нужными реквизитами и выведена на форму". Наоборот, первый вариант проще реализовать и с ним проще работать, да и в базе данных будет занимать меньше объем, т.к. не нужно будет хранить еще дополнительно данные по целому справочнику. И еще нужно запрограммировать вывод данных из справочника на форму документа, а потом сохранять их (элемент справочника). . В дальнейшем при получении данных из базы данных необходимо делать левое соединение для получения доп. данных из справочника.
2 вариант очень не удобен на мой взгляд, не вижу ни одного плюса перед первым вариантом.
---
Сделано все правильно. Вариант со справочником, как писали выше, это если является отдельными данными не связанный с конкретным документом.
Вариант когда можно завести справочник вместо реквизитов в самом документе только один (на мой взгляд), если делается не расширение, а меняется непосредственно конфигурация и хочется, что бы метаданные были не зависимы. Это значительно усложняет разработку, но в конфигурации будет отдельная подсистема и упрощает процесс обновления программы (но тут спорный момент).
---
Дополнительные данные можно хранить и в регистре с регистратором ЗаказКлиенту.
---
Можно, но только плюсов от этого никаких получить не удастся, а вот минусы в этом подходе имеются - аналог "отдельный справочник, где бы заполнялись также данные и ссылались на нужный документ", только с одним отличием, что работать нужно будет с регистром.
---
Зависит от данных.
Например, данные это план выполнения заказа. Такие данные лучше хранить в регистре, если кроме заказа клиенту регистраторами для таких данных могут быть другие документы. Например, (условно) "Корректировка плана заказа клиенту", "Отчет о выполнении заказа клиенту".
---
если речь идет о плане выполнения заказа, то это уже совсем другая история, которая не имеет ничего общего с сутью обсуждаемого вопроса. Для плана необходимо рассматривать задачу целиком - от фиксирования этого самого плана, до закрытия, корректировок и итоговых отчетов. Это разные задачи, которые решаются совсем по разному.