Добрый день, коллеги!

Настраивая ПБУ 18 и в частности иерархию для разниц по ПБУ18 в присвоении операций использую ссылку на таблицу ACCIT_GLX и поле ANBWA (вид движения ОС). Однако при попытке переноса данных через J3RPBU18DT в базу разниц получаю сообщение об ошибке "Ссылка таблицы с псевдонимом ACCIT_GLX не найдена. Транзакция j3rtaxtb".

Как правильно настроить присвоение поля ANBWA из таблицы ACCIT_GLX в j3rtaxtb? Пробовал несколько вариантов, не очень получилось. И вообще, где можно посмотреть, для чего нужна эта транзакция?

А при попытке прописать руками ACCIT_GLX в колонке "псевдоним" и связать с BSEG (где есть поле "Вид движения"), получаю сообщение "ACCIT_GLX используется в переносе полей. Выберите другое имя". Это и понятно - программа проверяет настройки в таблице T022 - все таблицы из операций. И если хоть в одной операции есть ACCIT_GLX, не разрешает заводить такой алиас. Я пробовал "обзывать" псевдоним не ACCIT_GLX а ZACCIT_GLX и именно его прописывать в иерархии в настройках отбора для узла. Все равно в этом случае получаю сообщение о том, что ссылка на ACCIT_GLX не найдена.

Секундочку. Зачем Вам заполнять присвоение таблицы accit_glx, если Вы используете тр-ю j3rpbu18dt?! Эта тр-я ориентирована на перенос данных внутри SL, никакие ссылки на accit она не поймет, поскольку работает только со структурой GLU1. Или вы все такие пытаетесь тащить значения через GCU1?

Я хотел бы в иерархии налоговых разниц для ПБУ 18 в условиях отбора разделить значения по признаку вид движения ОС (поле ANBWA). Если я использую таблицу GLU1 и поле ANBWA в критериях, программа переноса разниц J3RPBU18DT вылетает с ошибкой (поля ANBWA нет в ZTAXGEGT). А для того, чтобы использовать accit_glx и поле ANBW , я так понимаю, нужно прописать ее как рах в j3rtaxtb.

а что именно Вы хотите с помощью вида движения ограничить?

Я хотел поэкспериментировать. "Повключать" в первоначальную стоимость основного средства различные суммы этими видами движения, которые приводят к временным или постоянным разницам в НУ. Соответственно разделить это в ветках иерархии ПБУ 18 для того, чтобы система в одном случае делала постоянную постоянную разницу, в другом - временную.

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

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

Вопрос погашения - хороший. Я честно говоря не думал о нем еще. Так сказать, изучаю решение по шагам. У вас есть идеи?
Что касается разделений по строчкам иерархий в зависимости от вида движения, то удалось прописать транспорт поля ANBWA в структуру GLU1 непосредственно в транзакции ведения регистра GCL2 "Изменение регистра" в переносе полей JTFI на операцию RFBU (связь GLU1-ANBWA и ACCIT_GLX-ANBWA). Правда для этого еще пришлось добавить поле ANBWA в таблицу ZXXXA итоговых записей.

интересно, как вы планируете тянуть разницы по видам движения из файных документов... В которые вид движения как признак попадает далеко не всегда ))

ЗЫ я забил на все и написал программу, которая анализирует ANLC и ANLP и разбирает мне разницы по каждому ОСу отдельно. Очень удобно, рекомендую

Никак естественно. Все операции с возникновением разниц, при такой реализации, проводятся в FI-AA. Но такое решение думаю мало кого устроит.

Насколько я понимаю, нужна разница в первоначальной стоимости, а она вроде не гасится, т.к. постоянная.

А почему отказались от стандартного решения расчета разниц в областях оценки FI-AA?

Разницы в первоначальной стоимости разные бывают, если это к примеру расхождение по валютному кредиту в стоимости - то это времянка чистой воды и ее надо гасить (по идее)!

А расчет разниц в областях оценки - это тема, которая хорошо подходит для МСФОшного учета, но не совсем подходит для нашего.... хотя мы с главбухом тут обсудили этот вопрос и решили, что пожалуй ну нахрен все эти начисления с погашениями, будем считать все схлопнуто Щас думаю о том, как это лучше реализовать.

Пока встречала только решение на параллельных областях оценки. Поэтому мне немного странно, что решили делать по-другому. Конечно, абсолютно все решить с помощью ТПР вряд ли получится. Но большую часть проблем такое решение, как мне кажется, снимает. У САПа даже вроде есть решения для начисления амортизационной премии и расчета убытка от выбытия ОС. С погашением разниц, правда, беда. Но чаще всего бухгалтера все же соглашаются с ТПР в части проводок разниц.
Скажите, а с какими операциями возникли проблемы?