Дарю народу отчет для просмотра цепочки выравниваний!
Качать здесь.

Вот валяется, почти никому не нужная. Почему то все предпочитают напрямую лезть в поля AUGBL и REBZG, хотя там нюансов куча. Или пытаются использовать наикривейшую таблицу BSE_CLR.
Писал отчет больше для себя, для контроля других разработок.
В нем собран опыт моих столкновений с выравниваниями за несколько лет. Поэтому некоторые места алгоритма могут показаться странными. Это обход кривизны САП. Например простая истина, что поле AUGDT не имеет никакого отношения к документу в поле AUGBL, далеко не всем известна...

P.S.
Маленькое дополнение:
Отчет выдает иерархический список. Одна строка показывает две выравненных позиции двух документов.
Стрелочки показывают тип ссылки, например:
поз 1. >> - >< поз 2.
означает, что поз 1. полностью выравнена с поз 2., т.е. поле AUGBL поз 1. содержит номер документа поз. 2, а поле AUGBL поз 2. ссылается на самого себя.

или:
поз 1. > - ? поз 2.
означает, что поз 1. частично выравнена с поз 2., т.е. поле REBZG поз 1. содержит номер документа поз. 2, а поз 2. открыта, т.е. не содержит ссылок вообще.

P.P.S.
И еще одно:
Нужно создать GUI-статус с именем MAIN, а в нем пару кнопок с кодами PICK и NEW_FIND. PICK позволит проваливаться в документы, а NEW_FIND построить новую цепочку от документа, выбранного на экране.

а почему AUGDT не имеет никакого отношения к документу в поле AUGBL? я всегда думала что это дата выравнивания? разве нет?

Это именно ДАТА ВЫРАВНИВАНИЯ! Но не дата документа и не дата проводки. Я сталкивался с документами, в которых AUGDT не совпадала ни с одной датой обоих выравненных документов, даже год был другой. Уж не знаю, как пользователи это делают, но похоже как то через отмену выравнивания (например прошлогодних документов) и новым выравниванием, но без создания новых документов выравнивания (изменяются только ссылки старых документов). Это встречалось на разных проектах и в разных версиях (4.0 и 4.6).

SAP сама косвенно признает, что ссылка на документ выравнивания неполная (т.е. только номер документа, без года). Когда в транзакции просмотра позиции вы пытаетесь провалиться по ссылке выравнивания (AUGBL), то в случае, если в другом году есть документ с таким же номером, SAP выдает окно с выбором года вручную. Т.е. они сами не знают год, в котором этот документ заведен и не опираются на AUGDT.

В большинстве случаев AUGDT просто совпадает с датой проводки документа выравнивания, т.к. он обычно создается в момент выравнивания.

ясно. Спасибо за подробное объяснение!

Вам нужно подумать над оптимизацией селектиков...
в классе Clears_Doc


ИМХО использование таких конструкций плохо отражается на производительности программы

Дык, вроде этот класс у меня вообще закомментирован...


Далеко не всегда. Иногда наоборот, повышает. Вынос неоптимизируемых выражений из селекта в check может ускорить выборку. В R/3 4.0 сталкивался с такими случаями, но, вероятно, это сильно зависит от оптимизатора, т.е. от версий R/3 и Oracle.

Хотя, признаюсь, не до оптимизации было, боролся с глюками. Необходимость лазить в BSEG мешает оптимизации.

Вот все собираюсь свой вторичный индекс для BSEG сваять, а уж на его базе и оптимизировать несложно, алгоритм можно будет втрое сократить. Вот здесь обсуждал эту тему. В принципе уже сделал индекс, но до всестороннего тестирования руки не дошли.

Мне тоже кажется что
select ...
select...

endselect.
endselect.

Лучше не использовать. Это связано с трафиком м-ду БД и application.

Этот весьма объемный труд выбирает цепочки выравнивания, при методе частичного платежа? или при обоих методах?

Оба метода, т.е. все выравнивания.

Если в операции выравнивания участвуют позиции с датой большей даты выравнвиания, то AUGDT будет наибольшей датой этих позиций. Т.е., например, выравниваете позиции 31 маем, среди выравненных позиций есть позиция за 1 июня.. тогда AUGDT будет не 31 мая, а 1 июня.

Повторюсь, что мне попадались документы, где AUGDT не совпадала ни с какой датой ни одного документа.

Кто-нибудь запустил? Все работает? Я ничего не забыл?

Ну, придерживаясь методологии, работает.

Это какой методологии? Там вроде любые выравнивания находит. Единственное, при ситуации "много ко многим" суммы выравнивания не может расчитать, что логично.

Валера,
ну и надо сказать огромное спасибо постановщикам, коих сменилось несколько за время работы над модулями...
А то как-то "дарю" - звучит очень эгоистично.

Фига с два, они наоборот всячески упирались против моего алгоритма и упорно ставили задачу через глючную BSE_CLR, что я и сделал. А это исключительно моя разработка, которую я делал параллельно по собственной инициативе и по своему алгоритму. Потом им же его и подсунул, чтобы они могли контролировать и выискивать ошибки в своих алгоритмах.
Так что именно ДАРЮ!