Друзья, добрый день.
К сожалению, раньше почти не работал с основными средствами, приходится догонять семимильными шагами.
Допустим, уже начислено амортизации за 3 месяца 60 тыс. по данному основному средству. Но при существенном увеличении срока эксплуатации может возникнуть ситуация, когда накопленной амортизации даже без текущего периода уже больше, чем необходимо. В этом случае счета, указанные в типовой амортизации в AO90, просто меняются местами. И становится Дт 02* Кт 30*. А проводку по кредиту счета затрат выполнять нельзя.

Правильно ли я понимаю, что это нужно самостоятельно отслеживать и сразу выполнять корректировку с нужным видом движения по конкретному ОС до запуска/перезапуска плановой амортизации?

Я вообще-то хотел бы использовать второй момент замещений для этих целей и проставить на 30* счете красное сторно. Однако второй момент работать отказался. Предпосылка совершенно точно верная:
( SYST-TCODE = 'AFAB' OR SYST-TCODE = 'AFABN' ) AND
BKPF-BLART = 'AF' AND BSEG-SHKZG = 'H' AND
BSEG-HKONT IN ZAMORT_XNEGP (набор, в котором перечислены 30* счета, по которым нельзя проводить в кредит при запуске AFAB).

Буду благодарен вам за подсказку.

У нас в случае изменения срока использования (за исключением случаев изначально неверно введеного срока) новый срок вводится новым интервалом, при этом никакого перерасчета уже начисленной амортизации не происходит.

А что в трассировке останавливается в AFAB? Подозреваю, что тут замещения не работают и надо OpenFI.

Вобще амортизацию обычно проводят в разрезе класса, счета и МВЗ, и там все должно хлопаться в дебет.

Спасибо! Попробую. То есть система будет далее начислять по новому сроку использования от уже имеющейся остаточной стоимости? "Типа" прошлое не вернуть, а дальше живем правильно?


В том-то и дело, что останавливается. AFAB даже заранее моделирует работу проверок и замещений в нужном порядке. В конце концов я для проверки предпосылки просто уже вбиваю замещение счета ГК на константу "ВАСЯ", AFAB ругается... мол ВАСЯ не существует. Ну и, наконец, вот тут юзер описывает успешный опыт замещений в AFAB. viewtopic.php?f=27&t=53390&hilit=%D0%B7%D0%B0%D0%BC%D0%B5%D1%89%D0%B5%D0%BD%D0%B8%D0%B5+afab
В общем могёт система, но пока не хочет.


Все верно, могла бы и затеряться в общей куче. Но если первый запуск не прошел полностью, а перезапуск добивает пропущенные оски, то тогда запросто. Или просто маленькое подразделение.

Да, именно так и будет.

В ERP 2005, не помню с какой версии, но уже достаточно давно активировать красное сторно в проводках по уменьшению амортизацию в ГК можно через SPRO: Учет ОС - Интеграция с ГК - Проводка амортизации в ГК - Функции с нац спецификой - Россия - Разрешить красное сторно.

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

Что ж, с причиной явления понятно, с действиями тоже. Тогда остается последний вопрос. Почему не работает замещение на афабе. В поиске видел уже несколько тем, где люди отписываются об успешной работе замещений (и в том числе красное сторно замещением ставят). Может, они не второй момент используют... Или что-то не так с моей предпосылкой? Не понимаю написал за последние годы несколько сотен этих замещений, разве что с осами не связывался особо.

Друзья, взгляните на предпосылку в первом посте. Может, кто-то видит криминал?

Разобрался. Во-первых, работа предпосылок в тестовом прогоне и в продуктивном отличается.
Так, в тестовом ( SY-TCODE = 'AFAB' OR SY-TCODE = 'AFABN' ) работает, в продуктивном - нет.
Также в тестовом работает условие на вхождение в набор, в продуктивном - нет.
Удивительно, но это так. Пришлось предпосылку "оголить" до вида документа 'AF' и проводки по кредиту, а все остальные ограничения реализовать через подпрограмму в ZRGGBS000.
Так что останется загадкой, почему в других темах такая предпосылка у людей на втором моменте сработала. Может, с более поздней версией что-то поменялось.
Спасибо!

В фоне запускается? Транзакции там может не быть, можно проверить CPROG. А вот с набором чертовщинка

Делайте замещение в БАДИ - BADI_FIAA_DOCLINES
метод CHANGE_DOCUMENT.
Например с предпосылками:


Оно отрабатывает, как при моделирование, так и при проводке.

А замещение работает только при проводке( т.е. в продуктивном прогоне).

Спасибо! В будущем, наверное, badi и буду пользоваться.
А по поводу замещения - работает оно всегда. Это хорошо заметно в дебаге. Нюанс заключается в том, что если ошибок не возникло при моделировании, система зачищает все, что назамещала. И для вывода на экран использует то, что было по умолчанию. Поэтому складывается обманчивое впечатление, что они не работали. Но я (как уже писал выше) заменял hkont на "ВАСЯ", тестовый прогон слёг.

В самом начале post_fi_document
* sort the tables gt_accit gt_acccr gt_accda in the buffer
.............
CALL FUNCTION 'AMBU_AC_TABLES_GET_FROM_BUFFER'

Вот тут достает из буффера и в тестовом режиме шлем нам пламенный привет. Хотя фактически Вы правы, можно сказать, что не работает.