Добрый день!

Тут возник вопрос по исключению операций сторно из журнала налоговых операций (ТПР по 25 главе). Ну и, в общем, вообще из базы по налогу на прибыль. Кто нибуть на практики реализовывал такое?

Если не хотите видеть сторно и сторнированные документы, введите в налоговый журнал признаки таких документов, поставьте фильтр на исключение, закатайте в формат списка, укажите формат при запуске отчета... имейте ввиду, что у таких документов периоды могут быть разные...
По поводу базы... я думаю, такое реализовывать явно не надо

Я тоже думаю, что явно не надо Хочется услышать мнение коллег. Насчет формата отчета и признака сторно, то это прокатит только в идеальном варианте, когда документ изначально сформирован в FI и документ сторно и отсторнированный документ в одном периоде и за один перенос попали в спец. регистры.

я не заморачивался и мои пользователи тоже

Ну вощем мы делали что-то похожее.... но обязательно должно быть два варианта отчета - со сторнированными документами и без них, чтобы можно было сверить.
Ну и соответственно не показывать можно только те документы сторно, которые оба (и сторнирующий, и сторнируемый) попали в выбранный период.

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

Да, как вариант, если уж совсем прижмут, тоже планирую 2 отчета, один со сторно другой без, чтоб была сверка. Только смысла по прежнему не вижу, поскольку сторно в основном в расходах, а налоговики не придираются, если расходы минусуют... Зачем нужны извращения.

А можно вопрос в продолжении темы? Есть в ТПР две транзакции присвоения налоговых иерархий - J3RTAXAE и J3RTAXAS.

В чем их отличие, понятно в первом приближении. Не очень ясно вот, какая иерархия из двух или трех созданных (декларация, разницы, элементы НУ) должна присваиваться в J3RTAXAS напрямую к БЕ.

По идеи, должна именно иерархия элементов НУ
http://www.sapboard.ru/forum/viewtopic ... 43&start=0

PS Я на днях поставил сам ТПР, пытаюсь понять, как заполняются поля RTAXOBJ при переносе в итоговую таблицу. Увидел соответствующий User Exit, но значение элемента НУ берется из памяти. А вот кто и когда его туда пишет?

>В чем их отличие, понятно в первом приближении. Не очень ясно вот, какая иерархия из двух или трех созданных (декларация, >разницы, элементы НУ) должна присваиваться в J3RTAXAS напрямую к БЕ.

Иерархия элементов налогового учета.

Я в свое время в настройках правил выбора, по просьбам трудящихся соответствующего профиля, отсеивал документы с непустыми полями bkpf-stblg, bkpf-stjah

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

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

Достаточно часто в РФ проектными решениями разрешена только 03 причина сторно, поэтому предложенный способ несет незначительно мало методологических проблем

Перенос полей выполняется уже после того, как проверилась иерархия ЭНУ. Функциональный модуль иерархии, который говорит тру или не тру (в правиле выбора регистра), кроме этого действия в память запивывает элемент НУ, на основании которого он дал "добро" правилу....

Спасибо большое. Получается ТПР сделал АБАП-расширение при выборе регистра, где и проверяет в своем ФМ текущий элемент НУ, записывая его в память.

Если будет у вас возможность, не могли бы помочь с планированием еще

http://www.sapboard.ru/forum/viewtopic ... 7&start=15