Привет. Платформа 8.3.16 (конфа совместима с 8.3.12)
Направьте в нужную сторону.
Что-то не пойму как лучше организовать добавление реквизита в табличную часть справочника в расширении.
ТиЦ же завалится, если прямо в расширении указать реквизит?

есть два лагеря - одни добавляют реквизиты в расширениях, другие нет

(0) сделай и проверь

(1) Обычные реквизиты я добавляю через зависимые справочники...  Что-то завис с реквизитом табличной части... :(

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

Добавляя В расширение немного геморрой  потом с правами получается , придётся в расширение права ещё закидывать с этим доком .
Добавление ролей в расширение и потом в профиль че то не взлетело , или криво со-то делал .
Без прав в расширении на реквизиты добавленные , они на форме не появляются заимствованной .

(5) у меня все работает...

Так-то и у меня заработало , но телодвижений с правами пришлось больше делать , чем если в основной добавить реквизиты

Я никогда не добавляю в основной конфигурации реквизиты в таб части типовых объектов.

Есть для этого другие способы. Вне зависимости от того, будешь пользоваться расширением или нет, дополнительные реквизиты устанавливаются другими способами.

(8) А не усложняются ли при этом запросы к табличной части?Почему нельзя добавлять их в расширении например?Я в курсе про ТИИ.

(9) Запросы будут немного сложней. Но это усложнение на мой взгляд вполне оправдано.

Но даже при добавлении в Расширении, то все равно не нужно идти по пути прямого изменения в составе реквизитов ТЧ типового объекта.

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

Мое предпочтение - использовать РС с сохранением в измерениях ссылки на объект и ссылки на строчку ТЧ.

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

(7) Отчеты потом запаришься в СКД лепить с реквизитами в расширении. Только в Толстом клиенте в консоли СКД

(11) ну так какое дело...
Есть разработчики, которые все пилят и пилят, пилят и пилят. Ну не логично тогда в расширении это все пилить.
И разработчик не станет страдать ерундой и пилить в Расширении то, что можно для себя любимого сделать в конфиге для разработки и тестирования,
т.е. в полностью снятой с поддержки поставки делаешь все как проще и надежнее.
И когда все нужные усилия выглядят завершенными, то готовые объекты, модули и т.п., перебрасываются в расширение и раздаются в рабочие базы.

(10) (12) Спасибо, это надо взять на вооружение).

(10) "ссылки на строчку ТЧ" - расскажи плиз что это за зверь

(14)+ Особенно когда порядок строк меняется, нет поля для ключа связи в основной и т.д.

(14) видимо, хранить номер строки или УИД, как сделано в ЗУПе, например.

(15) когда меняется порядок строк, регистр перезеписывается вместе с документом

(15) (16) (17) да, я именно по аналогии с ЗУП.
з.ы. Ну так просто случайно получилось, что я на них посмотрел и оценил подход в качестве :-)

(17) (18) кстати сказать, а ведь можно усложнять до бесконечности

(19) 1совцы с этим успешно справляются. Особенно, когда начинаются динамические команды и даже реквизиты типа v79hd5v59df875ew987rf603pq9fje7p983f

(8) Ну, а я все жду расшифровку мысли... :) Увязывать через ключ две ТЧ в конфе и расширении?

Или через РегистрСведений?

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

Больше всего интересного - как эти дополнительные реквизиты будут использоваться. Если их нужно считывать для отчетов? Ну так тем более, проблема не в том, что у документа дополнительные поля на форме списка для ТЧ заполняются, а в том, как они будут заталкиваться в регистры или куда-то еще.

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

(23) такой этюд нужен, если нужна ссылка на строчку в ТЧ. Если такой цели не стоит, из ответа не понятно - зачем так усложнять.

И кстати, если не сложно, в каком доке Зупа можно посмотреть такой подход, не подскажите?

(25) ИдентификаторСтрокиВидаРасчета

Регистр сведений ИсторияПоказателейПоШтатномуРасписанию и ИсторияНачисленийПоШтатномуРасписанию

Или вот еще регистр ИсходныеДанныеПерерасчетов и в нем измерение ИдентификаторЗаписи которому установлен тип УникальныйИдентификатор