Коллеги,

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

К примеру, если есть аванс и задолженность, то выравнивать нужно датой задолженности. Если есть оплата без выравнивания (мало ли) и задолженность, тогда выравнивать датой оплаты.

Пока нашел только один способ. На селекционном экране для документа удалить дату проводки и выравнивания. Тогда в пакетнике система предложит вручную вводить. Это конечно уже лучше, но тоже не очень.

Как вы поступаете с датой выравнивания?

Нашел еще один способ.

В селекционном экране необходимо последовательно все даты запускать.

При этом отчетная дата соответствует дате проводки выравнивания.

Уже терпимо. Но хочется услышать лучше способ без АВАР.

Зря Вы пренебрегаете этим способом, сам по себе он неплохой. Например, у нас в компании реализовано также. Поле "Отчетная дата" имеет довольно неплохой смысл - после выборки из ЛБД везде расставлены check budat le <отчетная дата>. Таким образом, Вы последовательно проходите все нужные отметки, играя с датами и набирая начинку для "кучек". Для этого легко сгодится ПРОСТЕЙШАЯ Z-оболочка, которая будет сабмитить J_3RCALK, увеличивая отчетную дату на 1 день. Чтобы исключить холостые запуски, Вы можете контролировать, появлялась ли за прошедший день открытая позиция по данному кредитору (хоть одна). Это позволит сократить нагрузку.

Однако при таком раскладе Вам потребуются некоторые крайне важные проверки на выравнивание. Главная из них - не допускать проводки документа выравнивания с датой проводки МЕНЬШЕ, чем максимальная дата проводки среди выравниваемых позиций. Сделать это можно в open-fi на 940 событии, кажется. Если допустите такую неконсистентность, то J_3RCALK найдет документ (например, частичного платежа) раньше, чем "родительский", и отсечет второй. Ну и много других подводных камней, все сразу не перечислить.


Совсем "без ABAP" Вы такую проблему не решите. Просто есть умный и правильный ABAP, а есть необоснованный. Совмещение ABAP и нормальных инструментов дает отличный эффект.

Я видел также и другие способы замещения даты проводки, но я их не советую. Например, в одной из компаний дата проводки замещалась имплицитным enhancement в конце управляющего ФМ на событие 1025. К тому моменту уже были наполнены GLU-таблицы, которые обновляют ГГК.

А вот 940 событие, о котором я уже говорил, можно проверить. Оно срабатывает на "покидание" подкэрана с открытыми позициями (моделирование, Esc, сохранение) и работает в том числе и из J_3RCALK, потому что там тупо реализован пакетный ввод на FB05. Но надо убедиться, что не повредится ГГК.

Наконец, еще одно экстравагантное решение, но это уже для извращенцев. Найдите место, в котором формируется BDC_DATA для пакетного ввода FB05. Там сделайте enhancement, который пройдет лупом по выравниваемым позициям и возьмет максимальную дату проводки, потом подставьте его в шапку и релаксируйте

есть вполне легальный экзит exit_j_3rcald_008

В своей системе не вижу такого exit вообще, вообще не вижу в поиске ни одного юзер exit для программ выравнивания, искал с любыми масками по компоненту.
Обновились до семерки в декабре, полный фарш.

Да, Вы правы! Я просто через smod искал в списке расширений, так как не открыл контекст вызова. А там бадишка.
Согласен, абсолютно законно и удобно использовать именно это расширение.
Выходит, решение, придуманное в голове, в сапе сделано в том же месте, что радует:)))

Коллеги, большое Вам всем спасибо! Очень подробные и полезные ответы. И стало ясно, что я не одинок в своей проблеме! Очень всем благодарен!