GDA: Status

[Graham Leggett]

Derek Atkins wrote:

> gncInvoice.c
> 
> in particular the code that implements the invoice and payment processing
> and the balancing code to make sure payment are split across invoices
> properly.

I have found that the current implementation of this particular 
functionality doesn't work that well, as it assumes payments will always 
follow invoices/bills.

In the invoice world this is usually the case, but in the case of bills, 
the payment will often be entered first (the bank statement gets 
reconciled to ensure the customer paid before shipping the goods, and 
both the payment from the customer and the payment to the supplier is 
captured in the process), the supplier takes their time getting their 
bill to you so the bill is captured long after the payment was made.

On top of this, you may have captured the bills in a different order to 
the captured payments, so the payment splits end up not making much 
sense. Then, if you unpost a bill to correct a mistake, it further 
complicates things, because now the bill total may be different and the 
payment splits make even less sense.

This seems to affect the payable and receivable aging, I have often seen 
cases of where payable aging says the vendor is owed X, but the final 
total on the account is zero. As a result I have learned to ignore 
payable aging entirely.

Calculating which invoices are paid and which aren't is a non trivial 
process, for my purposes I implemented a way to flag an invoice as 
unpaid if all the payments made to date by the supplier don't exceed the 
sum of all invoices up until that invoice. Getting that right gave me a 
headache.

I suspect that after an invoice or a payment is posted (or reposted) for 
an invoice or bill, what should probably happen is that the flags 
indicating paid / unpaid get reset from scratch each time. This way 
inaccuracies can get smoothed out over time.

>> In the XML tree, a transaction that belongs to an invoice has slots 
>> attached with additional information saying a) that the transaction is 
>> an invoice or a payment (from "trans-txn-type"), and b) which invoice 
>> this transaction is associated with.
> 
> This has nothing to do with the data in the XML file.  I honestly
> forget why the txn-type was created, and I dont remember where
> it's used.

The data is respected though - if you manually change the sign, load it 
into gnucash and save it again, the invoice stays an invoice, and the 
payment stays a payment.

Regards,
Graham
--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3287 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20080601/d8946447/attachment-0001.bin