Текущее время: Пт, мар 29 2024, 15:04

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 15 ] 
Автор Сообщение
 Заголовок сообщения: Заполнение казначейского счета в п/п
СообщениеДобавлено: Вт, ноя 24 2020, 17:17 
Начинающий
Начинающий

Зарегистрирован:
Вт, ноя 24 2020, 17:07
Сообщения: 3
Коллеги, добрый день.

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

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

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


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Заполнение казначейского счета в п/п
СообщениеДобавлено: Пн, янв 11 2021, 11:21 
Специалист
Специалист

Зарегистрирован:
Чт, сен 27 2007, 07:42
Сообщения: 104
Добрый день! Я бы то же хотела знать ответ на этот вопрос. Будет SAP работать в этом направлении или самим решать этот вопрос?


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Заполнение казначейского счета в п/п
СообщениеДобавлено: Пн, янв 11 2021, 13:41 
Почетный гуру
Почетный гуру
Аватара пользователя

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

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

_________________
Алё, это Пакистан? Нам нужен один килограмм


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Заполнение казначейского счета в п/п
СообщениеДобавлено: Вт, янв 12 2021, 10:37 
Начинающий
Начинающий

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


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Заполнение казначейского счета в п/п
СообщениеДобавлено: Вт, янв 12 2021, 11:22 
Почетный гуру
Почетный гуру
Аватара пользователя

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

_________________
Алё, это Пакистан? Нам нужен один килограмм


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Заполнение казначейского счета в п/п
СообщениеДобавлено: Вт, янв 12 2021, 14:43 
Почетный гуру
Почетный гуру
Аватара пользователя

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

_________________
Алё, это Пакистан? Нам нужен один килограмм


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Заполнение казначейского счета в п/п
СообщениеДобавлено: Вт, янв 12 2021, 15:14 
Начинающий
Начинающий

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


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Заполнение казначейского счета в п/п
СообщениеДобавлено: Вт, янв 12 2021, 15:28 
Начинающий
Начинающий

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


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


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Заполнение казначейского счета в п/п
СообщениеДобавлено: Вт, янв 12 2021, 15:43 
Почетный гуру
Почетный гуру
Аватара пользователя

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

_________________
Алё, это Пакистан? Нам нужен один килограмм


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Заполнение казначейского счета в п/п
СообщениеДобавлено: Вт, янв 12 2021, 16:01 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Ср, фев 21 2007, 08:50
Сообщения: 1570
Откуда: Пермь
Пол: Мужской
birdy написал(а):
Вот здесь есть проблема. Мы создали новые банки, но проблема в том, что поле BNKA-BANKA (наименование банка) имеет всего 60 символов, а вот новые наименования Банка получателя по казначейским счетам практически все имеют больше 60 символов.
Возможно с этим будут какие-то изменения.

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

_________________
Алё, это Пакистан? Нам нужен один килограмм


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Заполнение казначейского счета в п/п
СообщениеДобавлено: Ср, янв 13 2021, 12:50 
Начинающий
Начинающий

Зарегистрирован:
Пн, фев 18 2019, 21:38
Сообщения: 1
На лончпаде в 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.


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Заполнение казначейского счета в п/п
СообщениеДобавлено: Пн, фев 08 2021, 10:06 
Младший специалист
Младший специалист

Зарегистрирован:
Пт, июн 11 2010, 09:45
Сообщения: 90
Откуда: Россия
Пол: Женский
Добрый день,
у нас кор.счет банка указывается в поле BNKA-BRNCH Филиал банка.
Теперь необходимо указать 2 кор.счета.
Поделитесь, пожалуйста, каким образом решили данную проблему?


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Заполнение казначейского счета в п/п
СообщениеДобавлено: Пн, фев 08 2021, 16:24 
Почетный гуру
Почетный гуру
Аватара пользователя

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

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

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

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

_________________
Алё, это Пакистан? Нам нужен один килограмм


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Заполнение казначейского счета в п/п
СообщениеДобавлено: Пн, фев 08 2021, 17:52 
Младший специалист
Младший специалист

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

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

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

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

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


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Заполнение казначейского счета в п/п
СообщениеДобавлено: Пн, фев 08 2021, 21:35 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Ср, фев 21 2007, 08:50
Сообщения: 1570
Откуда: Пермь
Пол: Мужской
Не будет никто перезатираться. Первый банк будет BANK_1, второй банк будет BANK_2.
В ключе таблицы BNKA ключ банка и страна. Что мешает создать два банка с единственным ЕКС счетом?

_________________
Алё, это Пакистан? Нам нужен один килограмм


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 15 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB