в ТПР по ПБУ18 рекомендуют настраивать области оценки ОС:

09 "Бухгалтерский учет без постоянных разниц"

10 "Налоговый учет"

11 "Постоянные разницы"

12 "Временные разницы"

Проводки амортизации идут по 10, 11, 12 областям.

При этом в иерархии ПБУ18 традиционно при расчете разниц используются 2 строчки: например, бухгалтерская составляющая постоянной разницы (вид операции Z0CA) - налоговая составляющая постоянной разницы (вид операции Z0CT). Я могу понять, откуда мы возьмём первую часть, но откуда брать вторую, если проводки по 09 области не идут?

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

НО: все стандартные отчёты и программы переноса используют виды операций (Z0CA, Z0CT, Z0TA, Z0TT) для для анализа. Стандартные отчёты у нас в итоге получаются кривые.

Поделитесь, как Вы поступаете? Включаете проводки по 09 области? Меняете отчёты? Что-то ещё?
У нас 6.0, если что.

Вообще-то тема с ПБУ18 довольно старая, я бы все-таки воспользовался поиском.
По поводу вопроса:
Это ж простая арифметика:
11 = 01 - 09, следовательно 09 = 01 - 11.
Это я к тому что если есть два слагаемых, то третье найти не проблема.

я поиск просмотрела, конечно. вот тут кстати:
viewtopic.php?f=5&t=24971&hilit=%D0%BF%D0%B1%D1%8318
есть Ваш ответ о том, что Вы отошли от ТПРа при реализации учёта по ПБУ18.

смотрите, как получается:
а) в ТПР рекомендуют настраивать 09 область без проводок, а 11 и 12 с проводками амортизации (для версии 4.7, у нас, кстати, 6.0)
б) в типовой иерархии RUP18 разницы расчитывают как постоянные разницы = амортизация по бу - амортизация по 09 области (см., например, узел U2-02-04)

вот мне и интересно, кто как делает?
- делаются настройки как в ТПР для 4.6
- в спецрегистры по налоговому учёту передаются данные амортизации из таблиц по основным средствам
- берутся разницы сразу со счетов для областей 11 и 12
- иное?

дело ещё в том, что у нас нет чёткой постановки задачи, настраиваем тестовый пример. и делаем это впервые

спасибо заранее за ответ!

ПБУ 18/02 для объектов ОС (или объектов модуля FI-AA, так как этот модуль зачастую используют не только для ОС, но например для учета ценных бумаг и т.д.) выполняется, как вы правильно заметили разными способами.
Рассмотрим основные:
Первый вариант: формирование ЭР (элементов разниц) на N-счетах
Считаю, данный способ самым простым, но в нем есть один огромный минус. Так как амортизация проводится на первичный вид затрат(30-счет), то в позиции документа амортизации, должен быть объект контировки, например МВЗ или внутренний заказ СО... Если счета для проводки амортизации в 01, 11, и 12 еще разные, то контировка у всех этих позиций будет одна, в следствии чего в СО на МВЗ будет формироваться не верная сумма. Данная проблема может быть решена с помощью операции замещения контировки на техническое МВЗ для позиций счетов 11 и 12 области оценок. Честно скажу, мне лично этот вариант не нравится, хотя тоже имеет право на существование.
Второй вариант: формирование ЭР на 30-х счетах (с привидением оборота по 30-му счета "Амортизация БУ" в ноль и без обнуления оборота ). Данный вариант и его аналоги широко применяются и наверное являются самым успешным решением по формированию разниц в модуле FI-AA.
принцип прост.
заводятся счета
3401 амортизация БУ
3402 амортизация НУ
3403 амортизация ПР
3404 амортизация ВР
Выбор счетов в FI-AA настраиваются так, чтобы при прогоне амортизации сформировались следующие проводки:
3401 - 0200
3402 - 3401
3403 - 3401
3404 - 3401
(вроде так )
Данная схема мне, очень нравится, но она не нравится бухгалтерам сальдо по счету БУ после прогона амортизации будет 0, чтобы посмотреть амортизацию по БУ нужно смотреть либо Д или К счета 3401 (отчеты по FI-AA будут показывать 0), либо смотреть БУ в комплексе 3402+3403+3404
Есть компромиссное решение имеющее свои истоки из выше описанного.
заводятся счета
3401 амортизация БУ
3402 корректировка
3403 амортизация ПР
3404 амортизация ВР, проводки выглядят след образом
3401 - 0200
3403 - 3402
3404 - 3402
Здесь со счетом БУ все в порядке, а для счетов ПБУ18/02 вводится "технический счет" для погашение излишних сумм.

И последний вариант.
Написать программу которая будет формировать проводки в FI-SL на основе таблицы ANLP. Программа не очень сложная будет, поэтому тоже имеет право на существование.
Да, про отчеты. Обычно на проектах отчет по ПБУ18/02 для ОС разрабатывается, так как пользователи хотят видеть в разрезе ОС ПР, ВР (ОНА, ОНО)

спасибо.
очень интересный комментарий по поводу использования 30х счетов для формирования ЭР.

посмотрела таблицы ZTAXREGT, ZPBU18T. В первой присутствует поле "номер основного средства", во второй нет. вообще не пробовали просто расширить таблицы группы ZPBU18 - добавить данные по основным средствам? есть ли какие-то структуры для интерфейса с основными средствами (типа ACCHD, ACCIT_GLX, ACCCR для FI)?

и ещё такой вопрос.
вот тут:
viewtopic.php?f=5&t=29253
вы, уважаемый Kiselev, пишите:


что сейчас у нас происходит с точки зрения налогового инспектора?
ведь если мы настраиваем ОС с прямо проводкой по 11 и 12 областям и получаем разницы уже сразу на счетах ГК, то ни о каких составляющих речи быть не может. или налоговых инспекторов вполне удовлетворяют отчёты по основным средствам?

Стандартные формы отчетности модуля FI-AA вам все равно не дадут полной картины по разницам. Вы сможете сформировать проводки по ВР и ПР, но не сможете (точнее, сложно сделать это) показать погашение/начисление ВР, так как решение ПБУ формируется НИТ(нарастающим итогом). Обычно отчет по разницам делается на ABAPе исходя из данных таблицы ANLP. а проводки по счетам ГК делаются без развертки. Скажем так, проводки по ГК делаются на основе счетов по 11 и 12 области (для разниц это не эффективно, так как проводки по ГК в ОС-ах проводятся группированные), а отчет делается на основе ANLP.

Вы правы, для ОС не формируются разницы путем вычитания БУ - НУ+(ВР/ПР), так как данные показатели мы уже имеем на счетах.

Всем добрый день!

В продолжении темы:

Необходимо учитывать разницы по основным средствам с НИт. В транзакции GCIN в таблицах ZPBU18A и ZPBU18T добавили поля RANLN1 и RANLN2, Суммы по разницам формируются в транзакции GB01 в регистре ZU с заполнением полей:
RDIFF_OBJ Объект разницы
RDIFF_TYPE Вид разницы
RDIFF_SOURCE Компонент разницы
RANLN1 Основной номер основного средства
RANLN2 Субномер основного средства.

При просмотре таблицы ZPBU18A поля RANLN1/RANLN2 заполнены, таблицы ZPBU18T - пустые.

Вопрос: возможно ли заполнить поля RANLN1/RANLN2 в ZPBU18T так чтобы итоговые данные формировались в разрезе ОС? если да, то что нужно сделать для этого?

Чтобы данные появились в итоговой таблице -T это поле должно быть прописано в таблице -O. В вашем случае поля RANLN1/RANLN2 вероятнее всего прописаны только в таблице -A.
Здесь стоит заметить, что вывод RANLN1/RANLN2 на уровень итоговой таблицы резко увеличит количество строк в этой таблице, а так как все SL расчеты работают на итоговой таблице, то у вас существенно вырастет время налоговых расчетов.