Добрый день.

Подскажите, кто как реализует на проекте требование по разным платежам в бюджетные организации.

Согласно ноте 1883302 - Budget Payment Order in Russia у САП есть стандартное решение: при создании документа каждый раз выбирать правильные реквизиты.

Можно ли как-то автоматизировать данный процесс?

Заполнение каких именно реквизитов Вы хотите автоматизировать? Речь об окошке, всплывающем для налоговых контрагентов, или о чем-то еще? Не очень-то понятно.

Да, именно их, заполнения окошка для налоговых контрагентах.

Автоматизировать означает подставить значения в эти поля автоматически? Некоторые вещи и правда можно определить и подставить автоматом по какой-нибудь логике, которую еще предстоит описать (статус плательщика, ОКТМО по основной записи контрагента, тип платежа и пр.) Но такие вещи, как УИН, налоговый период, дата документа-основания, номер документа-основания, КБК и др. где-то придется до этого вводить. Задача по сути превратится в "перекладывание" из одного места в другое, а в первое место все равно придется вводить руками, данные эти переменные и хранят информацию, специфическую для конкретного налогового платежа, а не контрагента. Посему вколотить это, к примеру, в основную запись контрагента не получится.

Далее. В сапе заполнение этих реквизитов реализовано в ФМ J_3RF_PDOC (событие 00001030 в P/S модулях, транзакция FIBF) и J_3RF_PDOC1430 (событие 00001430 в модулях процесса там же). Они начинаются с сакрального абзаца

IF SY-BINPT EQ 'X'.
EXIT.
ENDIF.

То есть использовать эти вещи в пакетном вводе, к примеру, не получится. Так же, как и вписать сюда свою логику заполнения полей. Сделать это можно, если снять с них копию и создать свои измененные Z функциональные модули, посадив их на эти события, а старые - отключив. Однако в этом случае Вы потеряете драгоценную возможность обновления логики, которую SAP меняет в связи с меняющимся законодательством (периодически). Так было в 2014 с УИН, к примеру. Мы хотели "свою" логику в ожидании ноты, но все равно потом пришлось возвращаться к стандартным ФМ.

Так что чисто мое мнение - трогать эти ФМ не стоит.
p.s. Однако если есть совсем уж острая потребность, то можно сделать свои ФМ все на тех же событиях 1030 и 1430 (в дополнение к существующим), в которых постараться описать логику некоторых полей, после чего менять их в таблице J_3RF_PLAT апдейтом (тысячу раз проверив правильность ключа). Однако я лично не вижу физической возможности определить значения для ряда полей, взять которые просто неоткуда: их придется заносить не в этом месте, дак в другом. А это уже не совсем автоматизация.