Проверили по вашим рекомендациям программу SAPFF012:

в строке 304 принудительно не разрешается редактировать выровненные позиции.
*------- ... alte Nettobelege mit Skonto ? -----------------------------
if bseg-kzbtr = 0
and ( bseg-dmbt1 ne 0 or
bseg-dmbt2 ne 0 or
bseg-dmbt3 ne 0 ).
m01-rcode = 4.
endif.
endif.
if bseg-augbl ne space.
m01-rcode = 4.
endif.

Мне непонятно, как вы это можете редактировать, если от настроек не зависит?

Я бы не стал так пока утверждать
В подпрограмме modif3_pruefen Вы в case вошли, судя по скопированному куску, с i_group3 = '017', а мы с darkduck - со значением '001'.
Вот с этим и надо разбираться.

Зайдите в SE51, программа SAPMF05L, экран 0302.
Вкладка "Список элементов", подвкладка "Модиф.группы".
Найдите BSEG-ZFBDT. Что стоит в поле "Группа 3"? У меня вот стоит 001, а у Вас стоит 017.
Это какая-то еще более приоритетная хрень, чем TBAER, раз зашито хардом аж вот тут.
Ведь настоящий анализ выровненности делается не здесь, а в tbaer_pruefen.
Там все сделано довольно гибко:
if tbaer-xausz = 'X' and ( bseg-augbl ne space or
bseg-xpypr ne space ).
t01-rcode = 4.
endif.

Кто-то (я даже знаю кто) очень не хочет, чтобы поля с группой '017' после выравнивания меняли свое значение.

1. Экран не ломали?
2. Нет ли пользовательских расширений, которые у поля BSEG-ZFBDT данного экрана меняли бы атрибуты?

А кая у вас версия системы, номер пакета?

EHP7 для SAP ERP 6.0

SAP_APPL 604 0007 SAPKH60407

А, ну да, сорри.
SAP_APPL 617 0002 SAPKH61702

Но вообще-то базовая дата менялась и 10 лет назад, друзья. Так что не уверен, что тут в компоненте дело.

А у нас:
SAP_APPL 605 0015 SAPKH60515

и еще у нас активированы только две бизнес-функции:

FIN_LOC_CI_7
FIN_LOC_CI_8

А у вас?

А у нас пользовательских расширений нет. Пока не знаю, где дальше "копать"

Ну Вы группу3 посмотрели? Если она 017, то
- либо она была поломана кем-то (пусть программист посмотрит, экран меняли или нет), тогда поломайте ее обратно
- если экран родной, то тогда сами ломайте группу3 на свой страх и риск.

Вообще-то я больше согласен с тем, как сейчас сделано у Вас. Потому что базовая дата участвует в расчете срока платежа НЕТТО, а после оплаты может, к примеру, в каком-то аналитическом отчете использоваться для расчета просрочки в днях. И на каком основании после выравнивании ее менять?

Группа 3 у нас равна 017.
С бизнесом еще поговорим. В базовую дату мы собираемся грузить дату ППС, которой в момент ввода входящего счета еще нет.

Мы используем условие платежа с базовой датой без значений по умолчанию.
В таком случае система проставляет дату документа. У нас это дата отгрузки. А по условиям договора отсрочка платежа от даты ППС, которая, как я уже сказала, появляется гораздо позже, чем документ введен.

Нужно знать просрочку и по уже оплаченным документам.