GDA: Status

[Derek Atkins]

hi,

Quoting Graham Leggett <minfrin at sharp.fm>:

> 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.

Huh!  It shouldn't be making that assumption.  Indeed, one of my
test cases was applying a Payment before I post the invoice, and that
certainly works in my testing.  This is partly where the sign issue
comes in.  The code searches for open lots and uses the positive/negative
balance to determine how to find the customer.

Yes, this algorithm could be improved.

> 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.

Eh?   I receive a bill from my vendor.  It's not due for another
20 days.  I enter it into gnucash and then later on pay it.

In your case you're talking about a completely different paradigm.
You're talking POS/Orders, and the gnucash business features don't
implement that right now.  For that you should probably just forego
the business features because you're never in a situation where a
customer owes you money.

> 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.

You can choose the first item to get paid.  yes, if you unpost then
it can get confused.  There's certainly some post/unpost/pay series
that gets it very confused but I haven't been able to reproduce this
case in my testing.

> 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.

The flags are purely based on the transaction lots.  What's going on
is that the algorithm to move overpayments between lots is getting
confused.  Those extra A/R (and A/P) transactions don't get removed
when you unpost and invoice, so that's probably related to the issue.

>>> 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.

It's respected in some places.  It's meaningless in others.

> Regards,
> Graham

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available