Про Консультантов Scala и методы амортизации

А чего тут ждать-то, ведь программный файл и так называется СФВ Ай-Яй-Яй

Где же все-таки история? Все так заинтригованы

Вообще, если говорить не столько о конкретной ситуации, сколько, скорее об общих принципах, то обычно в самом простейшем случае пользуют такую схему, при которой один вид амортизации используется для местного учета, другой для западного, причем счета настраиваются таким образом, чтобы для российского учета в российской компании одна (местная) амортизация «валилась» на балансовые счета, а другая (западная) на забалансовые. А после консолидации мы получаем обратную картину — из российской компании российская же амортизация идет на забалансовые счета, а западная, напротив, на балансовые. Ну, Вы, наверняка, именно такую схему и пользуете (с учетом того, что это я описываю «в стиле Сикейроса», крупными мазками). А в чем практический смысл конкретного описанного выше вопроса не подскажу, надо узнать у консультанта, который его задавал. Может поделитесь в личном сообщении, чес слово, даже интересно, кто бы это мог быть, особенно с учетом того, что он(а) уже в 2000 был(а) консультантом.

На одном предприятии данная функциональность использовалася для налогового учета, в деталях я сейчас не помню как именно, но идея такова, на бухгалтерские счета идет сумма амортизации как положено, а на счета 07 и 99 идет 24 % от разницы, между плановой и налоговой амортизацией.

ИМХО извращенцы.
Наверно их ОС можно было по пальцам считать…
Зачем делать лишнюю проводку, увеличивать объем базы, когда на этих счетах важны только итоги?

Порядка 1000-1500 ОС можно и по пальцам сосчитать, только сколько нужно человек с целыми пальцами?

Что бы не вспоминать мучительно и долго, кто и почему не сделал проводку, а если сделал, то почему именно такую.

Не объем.

И еще добавлять 2 строчки с ручными вычислениями в проводку по выбытию ОС, которая должна учитывать особенности НУ, БУ И GAAP, кстати у нас такая проводка делается АВТОМАТИЧЕСКИ.