Overpayment reversal (doesn't) reverse payments already entered
Looking at the code of overpayment__reverse, studying its call to payment__reverse and especially the query to generate the calls, I have to conclude that it's extremely unlikely that the payment-reversal code will ever be called.
There is a meta-question here: should overpayment reversal be so brutal as to simply reverse all payments associated with the overpayment, or should there at least be some indicator (force parameter? explicitly list which payments to reverse?) that the user is aware of what they are doing? Or should the user simply reverse the payments before being able to reverse the overpayment?
My suspicion is fueled by the line with the <---- HERE marker, which queries the transaction id (usually called trans_id) for the in_id parameter, which is the payment sequence number (which is orders of magnitude smaller than the gl transaction id, in any regular database): the filter is highly unlikely to return results.
PERFORM payment__reverse(ac.source, ac.transdate, eca.id, at.accno,
in_transdate, eca.entity_class, in_batch_id, null,
in_exchangerate, in_curr)
FROM acc_trans ac
JOIN account at ON ac.chart_id = at.id
JOIN account_link al ON at.id = al.account_id AND al.description like 'A%paid'
JOIN (select id, entity_credit_account FROM ar UNION
select id, entity_credit_account from ap) a ON a.id = ac.trans_id
JOIN entity_credit_account eca ON a.entity_credit_account = eca.id
JOIN payment_links pl ON pl.entry_id = ac.entry_id
JOIN overpayments op ON op.payment_id = pl.payment_id
JOIN payment p ON p.id = op.payment_id
WHERE p.gl_id = in_id <---- HERE