Подскажите, пожалуйста, как выйти из ситуации.
В старой системе особая амортизация используется для проведения 10% налоговой премии по области оценки НУ. Сама амортизаци проводится бухгалтерами вручную через тр. ABSO видами движений 620 / 630.
Выполняем перенос в новую систему датой 30.06.10.
Возникла проблема с переносом ОС, оприходованных в 2010 году (по старым ОС переносим типовую и особую амортизацию общей суммой как типовую). Коды амортизации настроены только на типовую амортизацию, поэтому хотели вводить амортизацию движениями (620 / 630). Однако особая амортизация, вводимая этим движением, планируется почему-то на первый после переноса период (07), хотя ссылочная дата движения, например, 28.02.2010. Можно как-нибудь заставить систему воспринимать ввод движения как часть переноса старых значений, а не планировать на 07 период?

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

У вас дата переноса 30.06.2010, система начинает жить с 1 июля, первый прогон амортизации будет соответственно в 7ом периоде, с 1ого по 6ой включительно прогон в системе проходить не будет. Как Вы хотите, чтобы при таком раскладе, система запланировала амортизацию на 2ой период?

PS: Может я конечно вопрос не корретно понял

нам не нужно планировать на 2 период (вообще разбивка по периодам не нужна), нам нужно, чтобы амортизация не планировалась на 7 период, а была в проводнике в строке "Перенос прежних данных". Т.е. это амортизация, переносимая из старой системы, она у нас будет проведена в ГК как открывающий баланс 06 периодом, в 07 она никак не нужна (там будет уже новая амортизация, которую будут проводить в новой системе).
Должно быть по аналогии с типовой амортизацией, которая просто фигурирует общей суммой за первые 6 периодов и проводить ее в ГК мы будем в OASV общей суммой.

Так настройте этот код амортизации так, чтобы он не пересчитывал. Для особой укажите Base method "Амортизация вручную". Этот код же вам нужен только чтобы поле открыть.

Простите за возможно тупой вопрос, но амортизация вручную - это имеется в виду метод "N No automatic calculation"? Когда я использую базовый метод 0023 с такими настройками, амортизация заносится в шестой период правильно, но в седьмом она планируется с противоположным знаком, т.е. сторнируется. В чем ошибка?

Да, я имел в виду базовый метод 0023.
В 7 периоде планируется с обратным знаком видимо типовая амортизация, так? Если да, посмотрите настройки ключа для типовой. Возможно, в multilevel method указана остаточная стоимость в качестве базы (24). Тогда надо использовать базу 21 (остаточная стоимость без особой амортизации).

нет, сумма с обратным знаком планируется в столбце особая амортизация.
Код для типовой амортизации действительно был по остаточной стоимости (24), поменяла на 21, ничего не изменилось. Типовая амортизация на год планируется до конца года корректно.
Такое чувство, как будто КА по особой амортизации настроен на амортизацию 0%, поэтому он и доводит сумму до нуля, но почему так происходит, я не пойму.

Для типовой ничего не изменилось (после смены с 24 на 21) именно потому, что особая откатывается назад и в сумме равна 0, то есть 24 = 21.
Почему особая откатывается назад, не понимаю, попробовал в своей системе - то же самое. Возможно, base method 0023 действительно так работает с перенесенной амортизацией за текущий год - восстанавливает ее до 0. Не вижу как можно на это воздействовать настройками. Другой base method (например прямой процент 0%) приведет к тому же результату.
У меня недавно был перенос данных по ОС в продуктив, но все ОС с премией были старые, и этой проблемы не возникло. Может кто-нибудь еще подскажет, ситуация вполне обычная. С помощью незапланированной амортизации?

Коллеги, добрый день.

Столкнулись с такой же ситуацией.

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

целый день вспоминала, как мы это тогда решили )) к сожалению, посмотреть в той системе уже не могу. по-моему мы в итоге настроили коды амортизации, где особая амортизация была настроена на 10 и 30% и с этими кодами амортизация не сторнировалась, но, конечно, если в исходной системе было не ровно 10 и 30%, то какие-то копейки добавлялись/сторнировались в следующем месяце.