Добрый день.
В первый раз написал немного не разборчиво,за что тему закрыл модератор, постараюсь описать более структурно.

Проблема следующая - необходимо настроить перенос данных между регистрами НУ. В ТПР по ПБУ 18 говорится: "Перенос фактических данных из базы НУ (FI-SL) в базу ПБУ18 (FI-SL) можно осуществить непосредственно запуском транзакции J3RPBU18DT".
Мною были выполнены настройки выбора в иерархии ПБУ 18 (DFRNC) из иерархии сбора (USP07). В иерархии DFRNC для операций (Z0TT, ZOTA, ZOCT, ZOCA) в критериях отбора указал поля структуры GLU1.
В результате настроек транзакция J3RPBU18DT корректно работает, но в продуктиве при проводке движения ММ стал вылетать дамп. Анализ дампа выявил следующее, при указании структуры GLU1 в критериях выбора, в программе происходит анализ настройки таблиц из транзакции J3RTAXTB. Если настройка таблиц не произведена для GLU1 (а именно так и было), это приводит к дампу в пуле модулей SAPLJ3RFTAX_TAXOBJSEL программе get_linked_field_fi . Для J3RPBU18DT эта настройка никакого эффекта не даст, но поможет побороть проблему дампа.
Для устранения проблемы попытался в транзакции J3RTAXTB сделать настройку с алиасом GLU1 (в соответствии с логикой алгоритма). Настройку стандартными средствами сделать не получилось, т.к. при попытке сохранения выдавалась ошибка о том, что такой алиас не разрешен. Танцы с бубном и прямой записью в таблицу алиаса GLU1 привело к устранению проблемы дампа. Надеюсь новых проблем не вызвало.
Вопрос, кто-нибудь настраивал критерии переноса между регистрами с помощью J3RPBU18DT? Если да, были ли какие-нибудь проблемы с указанием структуры GLU1? Если не было проблем, были какие-нибудь настройки с алиасом GLU1 в J3RTAXTB. И вообще, может не хватало настроек, чтобы избежать описанного выше дампа.

Нет. Специфичных настроек не было, связанных с GLU1. Вы же проверяли - эта структура стоит в качестве таблиц-отправителей в операциях Z0TT, ZOTA, ZOCT, ZOCA (тр. GCV2)? Именно поэтому кстати и нельзя прописать ее в J3RTAXTB - там при сохранении есть проверка на использование GLU1 в операциях.

Ну если вы настраивали J3RPBU18DT, то какую структуру использовали в критериях отбора? Или у вас просто не было подобного дампа ?

Нет. Я не настраивал никаких алиасов. В условиях отбора иерархии я мог выбрать поля GLU1 без предварительной настройки в J3RPBU18DT просто потому, что GLU1 была прописана в операциях Z0TT, ZOTA, ZOCT, ZOCA в тр. GCV2 как таблица-отправитель.

Нет, я немного не это имел ввиду. В настройке операции у меня все тоже Ок, и возможность выбрать структуру CLU1 в критериях выбора тоже есть. Проблемы была в том, что при указании в критериях выбора этой структуры вызывается LJ3RFTAX_TAXOBJSELF01, в подпрограмме get_linked_field_fi есть кусок кода, который анализирует имена структур :

и, конечно же, понятно, что в последней строке будет дамп, если из таблицы j_3rftax_linkh не выберется строка с алиасом с GLU1.
Что примечательно, если у меня нет настроек с критериями выбора на основе структуры GLU1, то в эту подпрограмму при проводках ММ (именно на нем начались дампы) не заходит.

Я понял. К сожалению, у меня нет возможности проверить проводку из ММ. Вы проводите документы в регистры через GCU4? Или автоматически?

Программа J3RPBU18DT используется для переноса документов из одного регистры FI-SL в другой. При этом абсолютно неважно, каков источник документа в первом регистре - ММ, FI или что-то еще. В источнике данных, в операциях для этой программы указывается Z0TA, Z0TT, Z0CA, Z0CT. В получателях - операция GLU1. С помощью этой операции будет произведено создание документов в регистре ПБУ18 (JU, если по стандарту). Поэтому, если документы переносятся неверно, а сами операции созданы правильно, нужно искать причину в настройках иерархии ПБУ18.
Если можете предположить, к какому узлу иерархии относится переносимый документ, при котором система вылетает в дамп, напишите пожалуйста настройки узла. Может в них все дело?

Верное дополнение, спасибо. Кстати, может кто знает, для чего используются настройки в транзакции J3RPBU18SC? Они же как то связаны с переносом разниц для ПБУ18?

По поводу настройки узла - уверен, что именно настройки конкретного узла не связанны с дампом, т.к. ошибка не в переносе между регистрами НУ (там все нормально переносится). Ошибка именно при переносе в НУ из ММ.

По поводу того, как настроена операция - онлайн.

И еще одно не понимаю, в иерархии декларации критерии выбора настроены тоже с использованием структуры GLU1. Однако эти настройки не вызывают дампа. Видимо настройки иерархии декларации никак не анализируются при проводке документов FI, ММ, СО. А настройки иерархий ПБУ 18 и иерархии сбора анализируются.

Думаю, что все же дело в настройках. Вы же в иерархию декларации документы с помощью GCU4 не переносите. Там сведение отрабатывает.
А по поводу дампа теперь стало понятнее. Программа J3RPBU18DT тут вообще ни при чем - она работает только для переноса документов из накопительного регистра НУ (JT в стандарте) в накопительный ПБУ 18 (JU в стандарте). Таким образом, если вы ходите получить данные в JU напрямую из ММ, то в соответствующем узле иерархии необходимо указать операцию ММ. Однако если просто в операциях в настройке узла проставить что-то типа RMWE, то система не поймет типа и составляющей разницы (временная, постоянная, БУ, НУ). Соответственно, необходимо создать группу операций в транзакции J3RTAXGR. Группа будет называться например Z0TA, что по кодировке означает временную разницу и бухгалтерскую составляющую. В этой же транзакции в группу нужно поместить все необходимые для переноса данных операции. Лучше помещать все, что присвоено самому регистру JU, тогда не ошибетесь. Соответственно, при настройке узла иерархии ПБУ необходимо, во-первых, указать данную группу операций. А во-вторых, использовать в качестве доп.криетриев ACCIT_GLX и другие структуры интерфейса с FI. Никаких GLU1 в данном случае не будет. Раз у Вас настроена он-лайн проводка в регистр, то перенос данных в будет происходить сразу при проводке в соответствующем модуле (ММ, FI или что-то еще).

Так в том то и дело, что я не хочу перемещать из ММ в JU. Получилось, что настраивал одну операцию (перенос между SL регистрами), а дамп вылез в операции (проводка онлайн движения ММ), которую я даже трогать не собирался. И после того, как я все же поборол дамп (хоть и не очень изящно), в движении ММ (и его переносе в SL) совершенно ничего не изменилось (по крайней мере я не нашел изменений, хотя искал).

Кстати, забыл написать, что нашел в итоге причину, которая привела к дампу. Было настроено старое правило (настроено до меня) для выбора регистра на базе иерархии ПБУ 18. Это конечно не объясняет того, что обработка критериев выбора со структурой GLU1 некорректна. Однако, объясняет почему при онлайн проводках стали анализироваться эти критерии.