Дорогие коллеги,

Не взыщите строго, но опять про двадцать пять сколько уже написано про эти программы, сколько повторено и еще один камень в это поле. Пытаюсь уложить для себя приемственность, принципы указанных программ, и потому, выношу на Ваш суд свои нехитрые мысли. Поправьте, если увидите, где беда.

Итак, насколько я понимаю, давным давно (вплоть до 2006 года) в России было два метода начисления НДС: по отгрузке и по оплате.
а) Метод по отгрузке означал, что исходящий и входящий НДС принимался к учету при условии, что было совершена отгрузка (исходящя и входящая соответственно). При это был такой прикол (да и до недавнего времени он был), что при этом, если товарищ получал аванс, то он все равно должен был начислить НДС с аванса, а потом, после отгрузки, сторнировать его. Товарищ, который этот аванс платил, естественно не мог принять сумму НДС в зачет, если сам работал также по отгрузке. (тут кстати, вопрос: а если работал по оплате, то мог? не помню.)
б) Метод по оплате означал, соответственно, что НДС принимался к начислению в момент оплаты. Т.е. входящий НДС принимался к зачету, только после оплаты сч.ф. поставщика, а исходящий, только после оплаты сч.ф. покупателем.
Важно, что как в случае а) , так и в случае б) для принятия НДС к зачету необходимо было также выполнение определенных условий. Назвом их "в" и "г": в) у Вас на руках должна была быть правильно оформленная сч.ф. поставщика г) если Вы купили ОС, то оно должно было быть введено в эксплуатацию.
Итак входящий НДС можно было принять к зачету в случае а) + в) + г) либо б) + в) + г)

В те далекие времена, чтобы облегчить себе жизнь, люди, как я понимаю, использовали для автоматизации процесса принятия НДС к зачету две программы J_3RFUM25 и J_3RFUM26. Вот здесь в моем повествовании начинают появляться элементы вымысла и домысла
25-ю программу люди использовали для того, чтобы отследить факт оплаты (в случае использования метода "по оплате" (а)) . Но т.к. при этом необходимо было также гарантировать использование условий в) и г) , то помиому 25-й программы, при методе "по оплате", люди использовали 26-ю программу. Порядок был такой: сначала прогоняем 25-ю программу, потом 26-ю. Соответственно переносили по кодам V2-> V9 -> VC. (c V2 на V9 при помощи 25-й, с V9 на VC при помощи 26-й).
Людям, которые избрали для себя метод "по отгрузке", жилось чуть проще. Они использовали только 26-ю программу (или вообще ничего не использовали???)

Тут наступил 2006 год и принес 119 ФЗ, согласно которому анархия и казуистика в методах начисления прекращалась и утверждался единственный верный метод: по отгрузке.
Для того, чтобы работать по данному методу необходимо было использовать только 26-ю программу, которая теперь игнорировала промежуточный код налога V9 и в случае наступления вторичного события смело все перетаскивала с V2 сразу на VC.
Но несчастные, которые до 2006 года вели себе НДС по оплате, оказались вынуждены незакрытые сч.ф. продолжать учитывать по старому - "оплате". Поэтому им пришлось для "по отгрузке" создать новые коды НДС , а для "по оплате" использовать старые.

Кроме того, метод "по оплате" является обязательным для учета НДС по таким операциям как НДС по импорту и НДС по налоговому агенту. Для этих операций, некоторые организации, насколько я понимаю, используют также 25-ю программу.

Но потом, организации, стали переходить на erp2005 и оказалось, что тем из них, кто хотел продолжть использовать для определенных случаев метод "по оплате" придется отказаться от 25-й программы, которая в erp2005 не вошла, и перейти на программу RFUMSV50, которая была сделана с учетом специфики НДС в России. Для того, чтобы перейти на эту программу, надо было сделать несколько шагов по конвертации текущих отложенных налогов и выполнить определенные настройки.
Вниимание! Тем предприятиям, которые 25-ю программу до erp2005 не использовали, а знали и любили только 26-ю программу, тем ничего делать при переходе на erp2005 не пришлось (так ли это?). А поскольку RFUMSV50 им была не нужна, то соответственно и не нужны были новые правила по отложенным налогам, которые появились в erp2005. Поэтому эти правила можно не присваивать российским БЕ таких предприятий (Customizing for Financial Accounting (FI) under General Ledger Accounting  Business Transactions  Report  Sales/Purchases Tax Returns  Deferred Taxes.)

Уважаемые коллеги, помогите найти, что в этой истории правда, а что нет?

Ох...
Вощем хотел написать сперва типа цитатами и на них ответы...
Но расскажу свое восприятие ситуации.

1) по оплате не только налоговый агент, но еще и командировочные и представительские расходы, поэтому если таких операций много, то не обойтись без автоматического контроля этого вопроса (оплаты);
2) остальные, "поотгрузочные" операции нормально обрабатываются 26й программой.

Таким образом, встает вопрос, как обработать операции, требующие контроля оплаты. САП действительно пиарит rfumsv50 с ее дополнительными таблицами, которые заполняются OPenfi-ями, которые нужно активировать, если хочется использовать это решение.
НО rfumsv50, на мой взгляд содержит в себе ОЧЕНЬ много странных и непредсказуемых глюков, на которые сап отзывается тучей нот, но они всё лезут.
Поэтому, хоть я и активировал на предыдущем проекте это хозяйство новомодное по НДС, часть операций все равно пришлось обрабатывать 25й программой (только не j*25, а rfumsv25, которая в ERP2005 сохранилась). Не знаю, что делала особенного русская модификация, но rfumsv25 делает то, что мне было нужно - контролировать оплату и перенос делать по курсу на дату оплаты и соответственно выравнивать позиции на налоговом счете.

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

По моему внутреннему ощущению - можно, но тогда придется как-то хитро настраивать прогонку "нулевых" сумм НДС для книжек....

Вот как-то так...

А в чем особенность обработки 0-вых ставок?

2All. Коллеги, уважаемые, не молчите: если я все изложил верно - соглашайтесь вслух )

Ну особенность в том, что программы переноса НДС и книжек работают по открытым позициям на налоговых счетах, а если не настроить тех. счетов для прогонки каких-нибудь сумм при нулевой сумме налога, то она эти позиции и не увидит.
При использовании же механизма отложенных налогов еще смотрятся записи в deftax-таблицах... Вернее записи смотрятся-то в любом случае, но, если это дело не активно, то записи там не создаются...

ОК, т.е. речь в данном случае о том, когда 0% - отложенный налог.
Если 0% - не отложенный налог, то книжка его увидит без технических счетов или deftax_item, правильно?

PS. Форум просто пестрит сообщениями по всяким особенностям НДС. Насколько было бы правильно все эти случаи описывать и включать в вики-документ!

Жизнь одна хлебни....

может ли кто-нибудь из коллег прояснить замысел разработчиков поручить RFUMSV50 в т.ч. заполнение таблицы UMSV при том, что она работает только по кодам налога, по которым контролируется факт оплаты?
т.е. заполнение UMSV только по подведомственным ей кодам, а остальное сделает RFUMSV00, или предполагается обращение к этой транзакции перед составлением декларации и, соответственно, после возмещения всех видов налогов - и по оплате, и по отгрузке?

Коллеги, вопрос касательно RFUMSV50 и группировку налоговых сумм для Декларации снимается: В стандартном решении по НДС в ERP 6.0 произошли существенные изменения. В связи с выходом нот 1353637 (J_3rfum26: 0% document creation) и 1366724 (RFUMSV50: New payment document date) стало возможным использовать отчет RFUMSV00 для формирования данных (прогон UMSV) для первичной и корректировочной декларации по НДС по ВСЕМ разделам. Поэтому с этого момента SAP рекомендует использовать именно RFUMSV00 вместо RFUMSV50, рекомендовавшегося ранее.