Добрый день.

Есть объекты недвижимости, налоговая база которых определяется как среднегодовая стоимость, при этом у данных объектов имеется кадастровый номер, который записан в ракурсе табл.J_3R_CADASTR_VAL. Данные объекты попадают в раздел 2.1 декларации с кадастровым номером. В течении отчетного периода, а именно 07.06.2018, произошло снятие объекта ОС с кадастрового учета, но выбытия в БУ по ним не было. Поэтому мы создали новый интервал в ракурсе с 07.06.2018, уже без кадастрового№, тот интервал закрыли 06.06. По логике бухгалтера в декларации за 9 мес. и годовой данные объекты должны выводится с инвентарным номером (условного у нас нет), но выводится всё равно с кадастровым. Подскажите как решить задачу?

Не заводите новый интервал, а просто проставьте коненую дату.

Тогда объекты перестанут попадать в раздел 2.1 декларации, а они там должны быть с инвентарным номером.
Помогает только закрывать интервал с кадастр.номером концом года 2017, и новый, без кадастр.номера, открывать с 01.01.18, только это не устраивает бухгалтера, т.к. в системе должны быть отражены фактические данные.

Проверила, поставила конечную дату в июне 2018, новый интервал удалила, объекты все равно попадают с кадастровым номером. Видимо без разницы какие были изменения в течении года, система берет данные на 01 января.

Тоже с этим столкнулся недавно: в середине года меняется метод с расчета по БСт на кадастровую стоимость или на оборот, а калькулятор (J3RALFPTAXCALC) на это не обращает внимание. Как оказалось, в программе вроде зашито отслеживание дат интервала в J_3R_CADASTR_VAL, но с косяком. Конкретно в подпрограмме get_cadastral_value сравниваются start_date и end_date из J_3R_CADASTR_VAL с датами из локальной структуры ls_cad_val, но эта структура всегда пустая, и эффект всегда один и тот же, как будто нет изменения интервала в середине года. Пришлось вставить в конце подпрограммы get_cadastral_value инхансмент, в который была скопирована вся логика этой подпрограммы, а вместо ls_cad_val была использована передаваемая в подпрограмму структура ps_cad_val - и все заработало. В общем, косяк САПа и, думаю, будет исправлен... ну не в эту пятницу, но в обозримом будущем.

... немного не правильно написал про САП логику в get_cadastral_value (по быстрому, на память). Правильно: в get_cadastral_value даты начала и окончания выбранного года сравниваются с датами из лок. структуры ls_cad_val, которая в подпрограмме всегда пустая - видимо разраб из САПа забыл провести присвоение этой структуре, и если вместо ls_cad_val использовать ps_cad_val, то изменение интервала в средине гора в J_3R_CADASTR_VAL будет калькулятором отрабатываться.