Добрый день. Подскажите пожалуйста, можно ли изменить логику сортировки документов фактур при выравнивании в программе J3RCALD таким образом, чтобы в первую очередь выравнивались фактуры не по дате проводки или дате документа, а фактуры с наибольшим кол-м дней просрочки платежа?

удалось сделать только через implicit enhancement в подпрограмме сортировки

Плюсую. Подобные манипуляции только через расширение.

Коллеги, спасибо за ответ. Подскажите, что по вашему опыту лучше в данной задаче - enhancement или с нуля писать выборку и вызывать fb05 для проводок.

Разумеется, надо расширять просто. Две строки расширения или полностью новый самописный движок, что лучше? Вы напрасно думаете, что сделать свою программу выравнивания так просто.
Запуск автоматического выравнивания итерационный, он умеет только что созданные документы частичной оплаты вставлять в цепочку выравнивания дальше.
При самописном движке Вам придется
а) отлавливать только что созданный документ
б) моделировать в Z-программе всю цепочку выравнивания заново, чтобы понять, какие документы пустить в выравнивание с учетом только что сделанного документа.
в) отлавливать новый документ и опять все моделировать, чтобы составить новый список документов.

Ну если только, конечно, у Вас не документы, полностью совпадающие по сумме 1 к 1, во что я не верю, так как в России все платят, как им в голову взбредет.

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

Да в моем понимании все равно расширять проще.
Этот код займет у Вас несколько строк.
Управлять количеством запусков можно и через стандарт (через поле "Число последовательных запусков" = 1).

Сложности если и могут возникнуть, то только в случае, если критерии выравнивания специфические.
Если просо сталкиваете лбами по номеру контрагента, то однозначно стандарт. Такое же решение, если используется четкий критерий (поле "Присвоение" и пр.)

Другое дело, если критерии для автоматического выравнивания специфические. Как пример из того, что мне доводилось делать.
Критерии выравнивания были для дебитора различными в зависимости от счета ГК, а не от номера дебитора.
То есть для одного и того же дебитора для одного счета критериями были одни поля, для другого - другие.
Через стандартную настройку это не сделать.

Другой пример. Выравнивать нужно было только те позиции, у которых дата задолженности не превышает дату оплаты (то есть только случаи постоплаты).
Если в цепочке встречался аванс - останавливаться сразу при обнаружении авансовой позиции, но более ранние выравнивания делать.
Вот тут я делал Z-оболочку, внутри нее моделировал хронологическую раскладку позиций, но потом все равно делал submit стандартной программы.

А тут речь идет просто о пересортировке позиций, задача простая. Лично я не вижу смысла плодить Z, но решать Вам, конечно.
Можно даже разграничить запуски: оставить людям один вариант, другим - другой. Для этого в качестве предпосылки для работы неявного расширения использовать имя транзакции, какой-нибудь параметр и пр. А еще красивее - расширить сам селекционный экран, если логика программы это позволяет. Сделать красивый чекбокс последним в списке, в самом низу. Ставишь его - расширение работает, не ставишь - работает старая логика.