Амортизация ОС

[TasmanianDevil]

Цитата:

Сообщение от Rivez

по причине, что статус будет "Закрыто"?

Нет. Статус ОС может меняться только в разноске операции ОС, при расчете амортизации никаких изменений статуса. Общий алгоритм формирования строк журнала таков :

• Перебор ОС, по заданным условиям
• Определение и перебор списка неамортизированных периодов для текущего ОС
• Расчет суммы амортизации по текущему ОС за текущий период

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

[nataLIE]

>>Нет. Статус ОС может меняться только в разноске операции ОС, при расчете амортизации никаких изменений статуса

А разве при разноске последней амортизации не меняется статус карточки ОС на "Закрыто" ?

[TasmanianDevil]

Цитата:

Сообщение от nataLIE

А разве при разноске последней амортизации не меняется статус карточки ОС на "Закрыто" ?

Именно так, только с небольшим дополнением - последней амортизации по последней несамортизированной модели учета. Ибо моделей учета у карточки может быть более одной и статус "Закрыто" будет поставлен, когда все модели самортизируются.

Но в данном случае разговор не совсем о том - мы рассматриваем процесс создания строк журнала амортизации за период в несколько месяцев (т.е. на каждую карточку бедет несколько строк) до момента разноски (!!!). Если внутри этого периода у каких-то карточек будет последняя амортизация - система ничего большего, чем набор строк амортизации с начала заданного периода формирова до последнего периода амортизации конкретной карточки ОС не создаст (попытки создать строки амортизации с последующего, после окончания амортизации данной карточки, периода по окончание заданного для всего журнала периода формирования строк потом аукнутся при разноске - как я уже упоминал). Реализовано это именно описанным мною механизмом и никак не контролем статуса, ибо в процессе создания статус не меняется, но лишние строки все равно не создаются.

Если амортизацию начислять помесячно, по одному на каждый журнал и не рассчитывать новую, пока не разнесен предыдущий - тогда там действительно статус влияет (есть семейство классов RAssetStatusType, в которых прошито поведение ОС и возможность проведения операций для карточек, находящихся в каждом из имеющихся статусов ОС - они как раз и используются для контроля в семействе RAssetProposal, создающем строки журнала ОС)