Коллеги, добрый день.

С 01.01.2021 изменяются реквизиты казначейских счетов для уплаты налогов (https://www.nalog.ru/rn27/news/tax_doc_news/10131148/).

Среди прочего там требуется в поле 17 вводить не корреспондентский счет банка, а казначейский.
Есть вариант хранить вместо корсчета для этих БИК казначейский счет, но, может, SAP готовит другое решение?

Буду рада идеям.

Добрый день! Я бы то же хотела знать ответ на этот вопрос. Будет SAP работать в этом направлении или самим решать этот вопрос?

ФНС объявила переходный период с 01.01.2021 по 30.04.2021.
Ранее всегда под письма минфина, серьезно меняющие процедуру формирования налоговой платежки, выпускались ноты, меняющие структуру таблицы J_3RF_PLAT, ФМ ники на BTE и пр.
Но тут следует ЧЕТКО понимать, что структура налоговой платежки НЕ изменилась. Новые поля не добавлялись. 13, 14, 15, 17 как были, так и остались. Изменился порядок их заполнения, структура налоговой платежки НЕ поменялась. Процесс формирования платежки у вас на DME дереве, значит, меняйте дерево. Я почти уверен, что по №15Н никаких изменений sap делать не будет. Максимум - теоретическая короткая выкладка по просьбам трудящихся.

p.s. В этом году будет еще изменение реквизитов 101, 106, 108, 109. Вот там, скорее всего, следует ожидать ноту.

Не могу с Вами согласиться.
Выводом в ДМЕ дерево занимается консультант, но система должна предложить место для хранения информации, в данном случае Казначейского счета и ЕКС.
Как выяснилось, нельзя использовать поле для хранения Корсчета для ЕКС, т.к. есть пример БИК, которому соответствуют 2 ЕКС.

Согласно письму минфина БИК поменяются тоже. И наименования поменяются у банков-получателей.
Я вообще допускаю, что новые БИК 1 к 1 сделаны будут.
Так или иначе, я не официальный представитель SAP) сверху лишь моя гипотеза. Я лично начну делать уже, не дожидаясь ноты, так как может случиться так, что ее все же и не будет.

Для всех страждущих.
Вот по этой ссылке можно посмотреть весь список территориальных органов с новыми
- БИК (14)
- наименованиями (13)
- номер счета в ЕКС (15)
- номер казначейского счета (17)
https://www.buhonline.ru/pub/news/2020/10/16075
Все БИК уникальны, нет ни одного повторения, это легко увидеть, если сделать сводную таблицу.
Все БИК НОВЫЕ. Таким образом, нужно просто создать новые банки, на УФК насадить новые банковские реквизиты.
Из письма минфина следует, что не может быть у одного нового казначейского БИК двух ЕКС.
А вот для одного ЕКС может быть сто тысяч миллионов КС, например, в Башкирии. Но это будут счета кредиторов в LFBK, а не кор. счет в BNKA.
Ну и особое внимание уделить 15 реквизиту, потому что ранее для налоговых платежей оно не заполнялось.

Рекомендую пользоваться официальной ссылкой https://roskazna.gov.ru/dokumenty/sistema-kaznacheyskikh-platezhey/kaznacheyskie-scheta/
В приложенной таблице несколько вкладок, и если их проанализировать, то БИКу 011117401 соответствует 2 ЕКС. И этот факт очень усложняет реализацию.
Буду рада, если Вы меня поправите.

Вот здесь есть проблема. Мы создали новые банки, но проблема в том, что поле BNKA-BANKA (наименование банка) имеет всего 60 символов, а вот новые наименования Банка получателя по казначейским счетам практически все имеют больше 60 символов.
Возможно с этим будут какие-то изменения.

По Архангельской и Ненецкому да, эпично вышло.
Но не забывайте, что в основной записи банка в ключе находится не БИК, а КЛЮЧ банка.
Поле BANKL - это техническое поле, которое однозначно идентифицирует банк в стране на уровне клиента.
Вы можете сделать BANKL = 'ЧЕБУРАШКА', но при этом в поле BNKLZ внести настоящий БИК банка.
Именно в этом поле хранится БИК, поле неключевое. Как и SWIFT (при его использовании) хранится в специальном поле.
Ошибочно думать, что BANKL - это БИК. Так повелось в России при использовании обычных биков в отсутствие свифтов.
Но это заблуждение. Определите два банка с разными ключами и одинаковым биком.
Но тогда тестировать придется намного тщательнее и DME исходящее дерево, и разноску в RFEBKA00.
Там, как правило, делают нехитрый Z. Правильнее всего мэпить изначально в исходящую платежку не BANKL, а BNKLZ.
У кого это было не так, тому придется заморочиться.

Думаю, это тоже решается. Тут уже поинтереснее.
Смотрите, в FI01 есть кнопка для ведения адреса.
После ввода адреса в ADRC полетят стандартные сороковушки (char40).
1. Для длинных наименований можно внести в адресные данные длинное наименование.
2. При генерации ОНД на заданном способе платежа при наличии ADRNR забрать полное наименование, законкатить его.
3. Сложить в расширенную структуру (FPAYX) в свободный слот или в существующее поле, если длина позволяет.
4. Если дерево забирает из нужного поля, оставить как есть. Если забирало из старого, замэпить дерево на новое поле.

На лончпаде в Legal Change Announcement tool опубликовано видение SAP на данное изменение:
https://launchpad.support.sap.com/#/legalchangenotification/NoteInforSet/jira=GSREQEE-991/TwoColumnsMidExpanded/0

Expected Solution

Common treasury accounts are maintained as a Bank Branch of the Bank entry.
New treasury accounts for territorial branches of the federal treasury (number starting with '03') are maintained on the BP entry.
Payments to budget system with the new accounts are possible.

Добрый день,
у нас кор.счет банка указывается в поле BNKA-BRNCH Филиал банка.
Теперь необходимо указать 2 кор.счета.
Поделитесь, пожалуйста, каким образом решили данную проблему?

Мы выше разобрали, что это только для одного банка может выстрелить (для Архангельска и Нано-ненецкого округа).
Для всех остальных БИКов в таблице соответствия только один ЕКС. Его вы и вносите в кор. счет.
Проблему по Архангельску можно решить, заведя в систему 2 банка с ключами с префиксами, например.
В поле код банка указать БИК. В поле "Филиал" указать корректный ЕКС (кор. счет по-старому).
Но в таком случае нужно будет смотреть вашу реализацию исходящих платежей, потому что исходящие платежки сделаны у кого как (PMW на BTE, просто Z на REGUH/REGUP и пр.) Может оказаться, что парсинг ваш кушает именно ключ банка в качестве БИК, а не код. Но это в целом неверно изначально уже на этапе проектирования, потому что ключ - это ключ, а код - это БИК. И вот тут придется изворачиваться.

Я для себя сразу выбрал стратегию созданию технических ключей с префиксом EKS, но потом отказался и все пометил для удаления, потому что слишком много программ, как оказалось, заточены именно на ключ, а не на код. Поэтому я нашел все эти БИК в системе (они там уже были из-за автоматической разноски по xml от ЦБ по ночам). И изменил у них наименование, кор счет и пр. Длинное наименование стал вести не в BANKA, а в адресных данных, потому что там большие здоровенные куски для хранения имени. Смутило лишь одно: все казначейские БИКи по-прежнему торчат в реестре ЦБ с неверными реквизитами, поэтому их пришлось отключить от автоматического ночного обновления по условию в проге.
А по поводу Архангельска я просто не стал заморачиваться, потому что по таблице соответствия проверил вообще все имеющиеся в системе УФК, и этого региона там не оказалось (или все существующие расчетные счета согласно соответствию выходили на единственный ЕКС).

В то, что в указанные БИК могут совершаться платежи одновременно по-старому и по-новому, я НЕ ВЕРЮ. Потому что эти банки обслуживают УФК, а любой платеж в УФК совершаться может только по-новому. Если у УФК будут другие расчетные счета, которые будут обслуживать их хозяйственную деятельность, но это уже будут другие банки 100%.

Примерно так.

Спасибо за ответ! Нужно подумать.
У нас банки и юр.лица ведутся централизованно в системе нормативно-справочной информации и передаются к нам. В той системе сделали возможность указать два кор.счета для одного бик.
Если мы заведем два банка, то каждый раз заведенный банк будет перезатираться. И по юр.лицам тогда непонятно: нам будет для юр.лица передаваться всегда один банк. который указан в той системе.

Не будет никто перезатираться. Первый банк будет BANK_1, второй банк будет BANK_2.
В ключе таблицы BNKA ключ банка и страна. Что мешает создать два банка с единственным ЕКС счетом?