Краткое описание :

Сломалось вычисление амортизации для поля OperIzmStoim.SumL_Next

Описание :

Амортизация

Что измененно :

Сломалось вычисление амортизации для поля OperIzmStoim.SumL_Next (потеря преемственности).

Используем мы поле &SumL_Next примерно следующим образом
Причем в 60 ключе мы вычисляем амортизируемую стоимость, от которой нужно посчитать линейную часть амортизации.
Эта амортизируемая стоимость должна удовлетворять следующим требованиям:
1) Не должна учитывать модернизации текущего периода, поэтому берем за основу стоимость на начало месяца, см. ключ 55 &StoimNachM
2) Амортизационная премия начисленная в текущем месяце, пришедшая из операции прошлого месяца, должна уменьшить амортизируемую стоимость;
3) Амортизационная премия начисленная в текущем месяце из операции текущего месяца не должна уменьшить амортизируемую стоимость.

Пункт 2 и 3 объясняются тем, что амортизационная премия исключается в том же периоде, когда и изменение стоимости начинает влиять на расчет амортизации. Но это не столь важно, откуда это требование, важно что это требование методологической службы заказчика и его нужно соблюсти.

При настройке алгоритмов мы решили поставленную задачу указанным ниже способом.
Учитывая, что OperIzmStoim.SumL_Next может работать неправильно, ломается вся логика заложенная в ключ 60.
Прошу Вас прокомментировать,
1) сломался ли OperIzmStoim.SumL_Next в связи с внесенными изменениями (Тестирование на Мосводоканал показали, что у них этот алгоритм сломался)

2) какие есть варианты временного решения проблемы с соблюдением вышеуказанных требований заказчика?

Как временное решение можно попробовать в алгоритме поменять ключ &SumL_Next
Было
if(IsValidAll(tnOperIzmStoim), OperIzmStoim.SumL_Next / SpKatOS.PoprKoef, 0)
Переписать
if(IsValidAll(tnOperIzmStoim) and (OperIzmStoim.dOperPrizn <> OperIzmStoim.dOper), OperIzmStoim.SumL / SpKatOS.PoprKoef, 0)
В нашем примере при расчете за июнь dOper=30.06.14 а dOperPrizn=30.07.14.
Но сработает это только если операция с льготой будет одна.
Если будет несколько операций с льготой (например добавится операция изменения стоимости за июнь с учетов в июне) то SumL будет содержать сумму
двух операций и поступления и изменения стоимости.




Алгоритм:
Наименование алгоритма !АК! ***2011_НУ_Линейный, ДатаВвода после 2010_Льгота учит при Поступлении
Алгоритм &AmRes
Применение алгоритма с учетом доп. параметров Расчет от даты: ввода в эксплуатацию
Анализ остаточной стоимости в архиве на ноль: нет
Коэффициенты расчета из архива
Архив износа на конец предыдущего месяца
Правило округления округлять по правилам: >= 0.5 Точность: 0,01
Номер Ключ Алгоритм для расчетов Описание алгоритма

10 &SumL if(IsValidAll(tnOperIzmStoim), OperIzmStoim.SumL / SpKatOS.PoprKoef, 0) Амортизационная льгота для учета в текущем месяце
15 &AllSumL if(IsValidAll(tnOperIzmStoim), OperIzmStoim.AllSumL / SpKatOS.PoprKoef, 0) Накопленная величина амортизационной льготы с учетом текущего месяца
25 &SumL_Next if(IsValidAll(tnOperIzmStoim), OperIzmStoim.SumL_Next / SpKatOS.PoprKoef, 0) Амортизационная льгота для учета в текущем месяце с прошлого месяца
40 &Norm if(IsValidAll(tnArcIznos), (ArcIznos.SrokIsp-SpKatOS.IspPS), (SpKatOS.SrokIsp-SpKatOS.IspPS)) Норма амортиз.: если было изменение СПИ, то чтобы оно началось со след месяца
55 &StoimNachM if(IsValidAll(tnArcIznos), ArcIznos.Stoim, SpKatOS.Stoim) Условность: если нет архива считаем что ОС в месяце ввода.
60 &AmStoim Сейчас алгоритм выглядит так.
&StoimNachM - (&AllSumL-if(&SumL<>&SumL_Next, &SumL-&SumL_Next, 0))

Можно упростить следующим образом
&StoimNachM - (&AllSumL- (&SumL - &SumL_Next))
Может быть в таком виде будет более доступно для понимания. В линейной части исключаем влияние мод.тек.периода и АЛ тек.перода
61 &SPosle Months_Between(KATOS.datek, katos.otchper)
62 &FirstAmort if (spkatos.sumizn=0, &SPosle, 1)
65 &AmLin round(&AmStoim*(1/&Norm),2)*&FirstAmort Линейная часть амортизации
70 &AmRes IF (&AmStoim-spkatos.sumizn > &AmLin, &AmLin, &AmStoim)+&SumL Анализируем на превышение только линейную часть, т.к. АЛ должна начислиться!

Как измененно :

Исправлено вычисление льготы для поля OperIzmStoim.SumL_Next (потеря преемственности).

Пример.
Есть ИК стоимостью 1000 р, льгота в следующем периоде = 200р. Операция поступления проведена в 05.2014.
Теперь стало считаться так
05 06 07.2014
SumL 0 200 0
SumL_Next 200 0 0

Расчет поля OperIzmStoim.SumL_Next для итоговых значений возвращен к первоначальному варианта (так как раньше рассчитывалось).
05 06 07.2014
SumL 0 200 0
SumL_Next 0 200 0