Добрый день. Порылся по форму, но или не так или не там искал. Реализовали форму 4 на данных FMIFIIT, в целом, довольно успешно, но есть нюансы.
Чтобы навести порядок в схемах проводок и удовлетворить всех, пытаюсь понять, каким образом система определяет, какой документ нужно прописать в поле VOBELNR при выравнивании фактуры и платежа, а так же есть ли способы повлиять на этот процесс.
Очень интересует, какие критерии анализирует стандарт, чтобы понять кто кого оплачивает. Может быть кто нибудь познал кунг-фу?

В стандартных ситуациях фактура-оплата (30-60-90) все понятно. В случае выравнивания аванса с фактурой тоже понятно. А вот в более заковыристых случаях - темный лес.
Например, если сделать документ начисления дебиторской задолженности по кредитору, и выровнять с входящим платежом (операции 90-60-30), то в VOBELNR при выравнивании прописывается документ начисления задолженности, в FMIFIIT фактура как бы сама себя оплачивает.
Причем, если в такой ситуации платеж проводить сразу с выравниванием фактуры, то платежный документ определяется верно, а вот при отдельном выравнивании - нет.
В общем случае логику понять можно: дебиторская задолженность по кредитору - это или входящий аванс (если с ОГК) или возврат, а не начисление задолженности.
Но, например, в случае возмещения из ФСС это весьма мешает, а заводить контрольный для дебиторов субсчет 69-го не очень хочется, бизнес сопротивляется.

Еще веселее в случае частичных взаимозачетов (часть кредиторки оплачиваем деньгами, а остаток зачитываем с дебиторкой), тут и с SAPом переписка ни к чему не приводит, по крайней мере переубедить, что фактура дебитора это не credit memo не удается. Дословно "Both examples are not 100% to our expectations but correct".
Изначально складывалось впечатление, что анализируются коды проводки, но после вдумчивого тестирования гипотеза не оправдывается. Но и типом финансовых позиций (поступления/выбытия) условия точно не ограничиваются.

Может быть есть какой-то материал по этой теме? Буду очень благодарен за любые наводки!

Привет. Очень интересный вопрос. Раньше никогда не обращала внимания на подобные несрастушки со сплиттингом.
Удалось ли найти какую-нибудь инфу или убедить САП исправить этот баг? Потому что, как мне кажется, это все-таки баг.

Пока что САП убедить, к сожалению, не удалось.
Информации тоже не нашел, придется, похоже, "обратным инжинирингом" заниматься
Собираем информацию и помаленьку пишем в САП по более явным ошибкам. Надеюсь где-нибудь по ходу дела поправят и эту ошибку. Пока стараемся учесть такие нюансы работы в схемах проводок и инструкциях для пользователей, если уже провели неправильно и исправить трудоемко - правим ссылку в fagl_splinfo, благо, такие ситуации довольно редки.