Bug report regarding reconcilliation

Summary: Under certain circumstances, the reconcilliation routine will
clear more transactions than expected.
Severity: Moderately Severe, not a showstopper, but impacts the
consistancy of the accounting data.
Frequency: Always

Details:

When a customer purchases an item with a split payment (say, two
different checks) on the same date, these are usually entered with
different source numbers (i.e. the numbers of the checks). If, during
reconcilliation, only one of these checks is marked for reconciliation,
the other one will be reconciled too if the details report is chosen.
This is due to the fact that the details report reconciles by
transaction id, and the fact that two payments are attached to the same
transaction means that they will be reconciled as a unit.

Steps to Reproduce:
Create an AR transaction or sales invoice with an amount due.
Create two payments against this invoice on the same day but with
different source numbers against the same account.
Reconile the account and only check off one of the payments.
Go to reconcile the account again and note that the other payment has
been flagged as cleared as well.

Suggestions for Fixing:
The problem occurs because the acc_trans table has no unique or primary
key which can be used to identify a specific row. In lieu of this, the
combination of trans_id, trans_date, and chart_id are used to identify
rows for reconciliation, but these are not guaranteed to be unique. If
you add source, you might be closer to the mark (this is the hack I am
using to avoid this problem). The best solution would be to have an
autogenerated sequence for the primary key of acc_trans. But this is a
relatively invasive fix and would require some testing (better to
include it in a beta release than the production one).

Best Wishes,
Chris Travers
Metatron Technology Consulting