On Mon, Jul 25, 2011 at 1:36 AM, Sebastian Weitmann <[email protected]> wrote: > On 25/07/11 09:35, Rolf Stöckli wrote: >> >> Am 22.07.2011 17:53, schrieb Rich Shepard: >>> >>> Reconciling bank statements has been discussed here before and, while >>> I've >>> followed the advice and suggestions in the threads, I'm still having fits >>> each month. >> >> Sooner or later we should arrive at a point where we can reproduce the >> issue. One problem seems to be that under certain circumstances bookings >> disappear. >> I've tried the following: >> Created an invoice, added 2 identical payments of 20 EUR. Then I open the >> reconciliation screen. >> >> - original SQL-Ledger: shows 1 entry of 20 EUR >> - community version and L123: show 1 entry of 40 EUR > > If you choose 'Detail' instead of 'Summary' when you open the reconciliation > screen in the community version and in L123 you will see both entries of 20 > EUR and not only one of 40 EUR. > > In the original SQL-Ledger version, it makes no difference whether you > choose 'Detail' or 'Summary'. The original SQL-Ledger version always only > shows 1 entry of 20 EUR.
Ok. So my guess is that the database stuff hasn't changed in fundamental ways beyond the type and significance of the acc_trans.cleared field. In other words, no significant new tables added, and no re-arrangement of the tables in terms of how payments relate to invoices. My most recent direct experience with SL was 2.7.9. The LedgerSMB project recently rewrote the reconciliation side (not part of a general release yet) but we didn't address some of the database issues entirely (both of our interfaces currently include data which can be used to identify individual payments, but no tracking data is added for historical payments, so we can't use the tracking data for payment searches and reconciliation). So consequently I think I am in a position to comment on what correct values should be and why. This should be useful in creating manual test cases and verifying proper operation of SQL-Ledger, L123, etc. Currently payments are just tracked as collections of line items against invoices. There is no single table to track what a payment is. So of you create an invoice X of $20 and an invoice Y of $20, and you pay them both with Check 12345 (source ck-12345) you get two line items added, one against each invoice, with the date, memo, and source fields all in common. There is no record inserted anywhere to track this data. If these are done using the batch/voucher workflows, the voucher_id field is also in common. So, in terms of dealing with "what is a payment" we came to the following definition for most scenarios: A payment is a collection of acc_trans records against a specific cash account, on a specific date, to a specific customer or vendor, and which MAY have a specific voucher id. So in the case you describe I would suggest that a single line of $40 is correct in both the summary and details reports (meaning SQL-Ledger is incorrect on both sides, and L123 is providing useful numbers on both sides, but it might be cleaner and provide fewer opportunities for data entry errors if aggregated in the details report). Also I would suggest the following best practices for users in avoiding this sort of problem: 1) Always add unique source numbers at least for the date. If you want to have wire-01, wire-02 each day, that';s fine but don't leave the source field blank and don't put generic tags in there. 2) If you receive payments which you take to the bank, use a separate account to track funds received before deposit, and transfer the money in when you make a deposit. Best Wishes, Chris Travers _______________________________________________ SQL-Ledger mailing list [email protected] http://lists.ledger123.com/mailman/listinfo/sql-ledger
