Расширили структуру BKPFа полем № контракта (EKKO-EBELN) - чтобы формировать в FI/FM аналитику по контрактам. Всё работает, но FIщики просят в FBL1N предусмотреть аналитику по полям сидящим в заголовке контракта. Копировать эти поля в BKPF не очень удобно, т.к. № контракта он фикированый, а значения этих полей в контракте могут меняться (тогда придётся каскадно обновлять эти поля во всех уже сформированных документах FI).
Вопрос - а если на тип данных поля № контракта прикрутить свой conversion_exit, который делал-бы select single нужное_поле from EKKO where EBELN = BKPF-№_контракта, насколько это плохо в плане производительности? Можно ли вообще так делать?

А зачем вообще так делать?
Если стоит задача добавить доп поля в отчет, имхо, следует просто добавить доп поля в отчет.

Чтоб во всех стандартных отчётах, где такое поле вытягивается на экран, можно было фильтровать/сортировать по нему.

pberezin, все в вашей идее, конечно, замечательно, кроме маленькой детали. Откуда ваш conversion_exit возьмет BKPF-№_контракта?

дык это exit к этому-же самому полю. Я в BKPF его объявлю как свой Z-тип, совместимый с EKKO-EBELN, но с дополнительным своим conversion_exit'ом, который лезет в EKKO и в качестве внешнего представления поля тянет нужное мне значение из EKKO.

СПП-элементы както так ведь работают - у них внутреннее и внешнее представление абсолютно разные. Пользователь на экране в отчётах видит одно значение, а в таблицах хранится совсем не то что он видит.

Хорошо. Вы добавили свое поле в стандартный отчет и каким-то образом заполнили его нужным значением. Тогда зачем лишний шаг в виде conversion_exit'а? Почему бы не выводить туда сразу то, что нужно?
Или вы заполняете это поле не в момент вывода документа, а в момент формирования? Тогда ваша идея имеет право на жизнь. И, в принципе, достаточно удачно решает проблему.

Может поможет Note 373268 - Line item: new display field

Минусы такого подхода:
1. При каждом обновлении экрана отчета, будет выполняться пересчет данных.
2. Добавите поле, в отчет, где допданные в общем то и не нужны, а они все равно будут подтягиваться.
3. Если нужна фильтрация по этому полю, то тогда необходимо будет выполнять и обратное преобразование - из допданных доставать номер контракта. Получится однозначно это сделать?

Вот чего не пойму еще: добавление поля на уровне таблицы не добавляет это же поле в отчет. Т.е в любом случае придется брать конкретный отчет и добавлять туда расчет и вывод еще одного поля. Почему бы тогда не обработать и вывести не одно, а сразу несколько полей с доп данными?

Чтобы, если те, кто создавали контракт, поменяют в его заголовке значение нужного мне поля (уже поле того, как соданы FI-документы со ссылкой на контракт), это изменение сразу увидели те, кто запускает FBL1N по этим FI-документам. Номер контракта в BKPF не изменился, но FI видит в колонке отчёта не сам номер контракта, а изменившее значение нужного мне поля в этом самом контракте.

Фактически - неявный автоматический BKPF inner join EKKO, но через conversion_exit (ну если хотите - вычисляемое поле в отчёте). Плюс видится в том, что единожды настроенное, такое поле одинаково будет работать не только в FBL1N но и в любых других отчётах, где оно тянется на экран.

Про п.3. я чтото не продумал
Придётся тогда в FBL1N вставлять вычисляемое поле както иначе.