Добрый день!
Очень похоже, что дошли до отделении "зерен от плевел" viewtopic.php?f=5&t=42741&start=0

Написана проверка по событию 1025.
Если один платеж закрывает несколько фактур и при этом сам выравнивается, то в таблице T_AUSZ3 мы видим суммы по кредиту, на которые эти фактуры были частично выровнены.

Следующий платеж закрывает эти фактуры в ноль.
Но проверка такое выравнивание идентифицирует как "многие-ко-многим".

Правильно ли я понимаю, что из анализа позиций таблицы T_AUSZ3 нужно исключить все документы, которые являются документами выравнивания.
Спасибо

Тут все зависит от того, как Вы саму проверку реализовали.
Частичные платежи ссылаются на "родительский документ" через поля REBZG, REBZJ, REBZZ.
Такие документы при включенной галке "Учесть ссылку на счет-фактуру" в FB00 можно из проверки исключать, то есть из таблицы выкинуть.

А не хотите сделать такую проверку на событии 940? Смысл, конечно, тот же, но у 940 есть бесспорный плюс. 940 выдаст error при попытке покинуть экран обработки ОП, тогда как 1025 начнет свою работу только после всех выполненных проверок, замещений и BTE, которые расположены выше по стеку. То есть вы потратите ресурсы на то, чтобы добраться почти до самой проводки, а потом в конце обломаться, как на школьной дискотеке.

Хотя в целом разницы особой нет. Если не практикуете выравнивание с остатком, то можете удалять из таблицы выравниваемых позиций все, что содержит ссылку в поле REBZG.
Или вот еще хороший критерий для идентификации "основного" документа (фактура или платеж - родители): belnr = rebzg ИЛИ rebzt = 'V' (это если в компании выравнивание с остатком тоже применяется, позиции остатка тоже содержат rebzg, но исключать их нельзя).

Поправку вношу. Принцип belnr = rebzg, скорее всего, сработает в 940 событии, а не в 1025.
В 940 таблица другая, принцип ее заполнения тоже. Там система в поле REBZG засунет реальное значение этого поля, если оно есть, или сам номер документа, если rebzg отсутствует.
Так что в 1025 критерием для выкидывания позиций будет rebzg <> ''.
В 940 критерием для выкидывания позиций будет belnr <> rebzg.

Спасибо Yozhhhhh.
хотелось бы еще что-нибудь толковое почитать на тему выравнивания дебиторской/кредиторской задолженности.

Если такая ситуация : три инвойса оплачиваются первым платежом частично c использованием транзакции Fb05, вторым закрываются полностью (опять FB05).
В финальном выравнивании получается 3 инвойса-2 платежа,
но это же не многие-ко-многим .
разве нужно запрещать такое выравнивание?

После первого частичного выравнивания первый платеж уходит в выровненные позиции, он уже никак не может участвовать в выравнивании дальнейшем.
Сколько бы фактур ни участвовало в первом выравнивании, от какой-то зависнет "кусочек". Этот кусочек сохраняется в открытых позициях и имеет ссылку в REBZG на исходную фактуру. То есть у Вас будет, к примеру:
фактура Кт60 на 100 руб
платеж №1 Дт 60 на 20 руб.

В результате выравнивания №1: фактура на 100 остается в открытых, к ней создается позиция по Дт60 на 20 руб со ссылкой в поле REBZG на фактуру. Итого -80, это единое целое, они рассматриваются вместе. Но платеж на 20 уходит в выровненные. Может быть и такой подход, при котором вообще проводка платежа сразу делается со ссылкой на счет-фактуру, без дальнейшего шага по выравниванию, то есть: Кт 51 Дт 60 20 руб со ссылкой в поле REBZG. Но это сути не меняет, эти позиции уже связаны с этого момента, их следует объединять по REBZG.
Вы называете этот кусочек по Дт20 руб со ссылкой по REBZG платежом, но это не так. По моему алгоритму, который я выше описал, он не должен восприниматься как платеж. К примеру, если вы сделали loop по позициям, участвующим в выравнивании, и крутите там какой-то счетчик платежей и счетчик фактур, то на такую позицию счетчик Вы не увеличиваете. Ну не платеж это уже, а всего лишь хвост к исходной позиции.

Технические стороны выравнивания нигде не описаны, поверхностно можно почитать в 200 или 201 курсе, а также частично в Best Practice. Технические стороны познаются только на практике, долгой и терпеливой, экспериментируйте в тестовой системе.