Добрый день!
Коллеги, подскажите пожалуйста, есть ли стандартный отчёт, который показывает документы, входящие в сформированное сальдо по декларации?
Спасибо!

F.12 не подходит?

Ну как минимум не удобно работать с транзакцией, попадают все документы, фильтра нет, т.е. если гипотетически я захочу понять что у меня попадает в строку 120 декларации, я бы мог в этом отчете отфильтровать по коду налога, но в f.12 даже этого нет.

Есть ещё информация что к декларации поставляется нота с неким стандартным отчетом для проверки.

Как нет фильтра по коду налога?

Я имел ввиду фильтр не на селекционнике, а уже при работе с отчётом. При этом всё равно не хватает критериев для корректного отображения в разрезе строк декларации, т.е. должны быть все поля для выбора, соответствующие полям таблицы UMSV.
Но ещё изучаю эту транзакцию, возможно что то упускаю.

Так всё же, как на счёт некой ноты с отчетом для декларации, никто не в курсе?

Нота 2221300, из последних. Но эта нота для подсчета подитогов и сверки с книгами, не уверен, что она дает раскладку по документам, вошедшим в подитоги.

Посмотрю.
Спасибо!

На вебинаре по подитогам 12.10.2015 подняли вопрос о просмотре в разрезе документов. Ответили, что в стандарте такого не предусмотрено и не будет. Хотите проваливание в документы - устанавливайте решение на HANA.
Декларация работает на основании записей UMSV, там просто итоги в разрезе кодов налога. Слышала, что, коллеги зэтят нулевой отчет и пишут данные в разрезе документов при записи UMSV в доп.таблицу.

Для себя понял, что RFUMSV00 выводит на экран данные абсолютно не корректно!!!
Собственно и тему на форуме нашел:
viewtopic.php?f=5&t=90074&start=15
Всем спасибо, будем модифицировать!

Друзья, хотел поделиться своим решением по поводу модификации программы. В настоящий момент я решил задачу выверки, причем получилось это сделать с минимальными затратами (накодил все сам) и работает довольно симпатично. Так что если вдруг кому понравится мое решение, можете использовать.

1. Неявное расширение №1 в инклуде I_RFUMS_SELECTION_FORMS, подпрограмма append_ep. В самом конце складываю структуру EP в свою глобальную табличку. В таблице основные поля (база, налог, вид, ссылка, код ндс и т.д.) Но что самое главное - на данном этапе EP содержит признак дебет/кредит и красное сторно. Остается только перевернуть в случае необходимости.

2. Неявное расширение №2 в инклуде I_RFUMS_SELECTION_FORMS, подпрограмма insert_umsv. Поскольку на данном этапе система обновляет таблицу UMSV, в этот же момент имею полное право зафискировать документы, составившие сальдо нужных строк, в Z-таблице. Z-не совсем элегантен, но зато в пункте 3 поймете, почему так. За объем таблицы переживать не стоит, ее можно подчищать через оболочку, сделать простейшую транзакцию пользователю. Или вообще чистить автоматически при добавлении очередного прогона с этим месяцем. В общем вариантов уйма.

3. Делаем красивую детализацию по двойному щелчку прямо из транзакции J3RVATDECL. Да-да, прямо из нее. Буквально имитируем HANA, поскольку двойной щелчок при активной HANA даст детализацию. Но HANA у нас нет, а потому поступаем просто. В самом начале метода handle_double_click в инклуде J_3RVATDECL_ALV_EVENT_RECEIVER делаем последнее неявное расширение №3. Считываем номер строки, номер столбца, версию декларации, по которым кликнул курсор. В таблице настроек J_3RVATDT007K (это папка "Критерии выбора" в основном настроечном кластере) забираем все коды НДС, которые входят в данную ячейку. Итоговые строки отсекаем сразу. Остается выбрать из Z-таблицы (вот она нам и пригодилась) конкретные документы из данного прогона (он также есть в глобальных переменных в J_3RVATDECL на данном шаге), умножить на минус 1 для тех, у которых стоит Negative Sign, привести базу или сумму налога в полное соответствие с полем "Тип суммы" (G, N или T) и вывести все это в простенький ALV-list с подытогами.

По Esc или кнопке назад возвращаться в ALV-декларацию. После проверки ALV выгружать в XML и идти