Как вариант, если хочется использовать именно табличную форму, объединить оба этих поля в одном столбце,
к примеру, возвращать v1 || some_delimiter || v2
+написать instead of триггер, который раскидывает изменения по этим 2-м столбцам.

Ну или программировать это всё на уровне яваскипта/html.

И возможно подойдёт как раз Popup Key Lov. Еще вариант добавить столбец Standard report column, и сделать его расчитываемым в запросе под Tabular Form.

Отличия в том, что Popup Key Lov отображает одно, а возвращать может другое, а что именно можно скрыть.
Т.е. возвращать можно id из этого справочника, а дальше с помощью instead of триггера можно прокопировать эти поля в таблицу, по этому ID. Конечно, для такого действа предполагается наличие unique по этим полям.

У меня для такой схемы, обычно записи заполняются поштучно, а не разом,
поэтому использую чаще формы с items, а не tabular forms, проще выходит, не знаю как у других.

Добавлю, придумалась лёгкая реализация через JavaScript.
Добавляем 2 hidden (или text field column) в которые будут копироваться v1 и v2. Добавляем им классы, скажем class="t_v1", class="t_v2"
Заводим Popup Lov который возвращает v1 || some_delimiter || v2, но не связываем его с таблицей.
Добавляем к нему в атрибуты что-то типа (внимание, это схематический, а не конечный код, его я не тестировал!!!):

suPPLerFFFFFFFFFFFFFFКак такое можно реализовать?

У меня есть вопрос, возможно, не совсем по теме. А зачем такое делать? Почему в одной табличной форме получились такие два поля, что одно из них однозначно определяет второе?
FFFFFFFFFFFFТаблица T1 используется как справочник. С нее просто нужно подтянуть данные в поля.
Объяснено не очень, но подобные задачи изредка могут возникать:
т.е. есть справочник, грубо говоря, id и N полей. Далее этот справочник используется некоей сущностью. Но тут возникает проблема, меняем справочник => меняется сущность,
это если использовать foreign key, а сущность может являться, к примеру, уже подписанным документом, помещенным в архив, отсюда проблема.
Одно из простых решений: продублировать N полей из справочника в сущность, тем самым при выборе из справочника меняется не id, а эти N полей.
Описанная выше задача возникает при необходимости использовать Tabular Form с такой сущностью.

Это я про себя,
у FFFFFFFFFFFFFF, возможно, другой случай.

suPPLerИ документ в архиве не надо будет обновлять из-за обновления справочника
И в приведенном решении тоже.

suPPLerПодобный случай - ошибка проектирования. :) Такой справочник должен иметь период действия у записи. Тогда "изменение" превращается в занесение новой информации, а "удаление" - в указание конца периода действия для записи. И документ в архиве не надо будет обновлять из-за обновления справочника, спасибо второй нормальной форме . Но это уже офтоп.
Всё это сложнее реализуется, в простых задачках в этом нет необходимости, так во всяком случае меня учили.
Или это можно автоматизировать каким-то простым способом? линки плз
ну у меня задачки либо небольшие, с малым бюджетом, либо дорабатываю большие (200 таблиц) с уже (по крайней мере частично) готовой структурой, поэтому каких-то особых решений на эту тему мало копал.