FIFO invoice model

[Derrick Ashby]

Sorry, didn't copy gnucash in again!

Derek Atkins wrote:

> Bug #121420      
>
> You cannot assign a payment to a specific invoice, which is what I bet
> you're trying to do..  Payments will always be applied in a FIFO,
> oldest invoice first.
>
> -derek
>
> Derrick Ashby <daeroncs at fastmail.fm> writes:
>
>  
>
Derek,

When a customer staples a cheque to an invoice, or better yet, prints a 
cheque and a payment advice on the one piece of paper they certainly 
believe that their cheque is associated with one or more invoices. When 
I sit in front of gnucash, and call up a list of customer invoices, some 
of which are ticked as paid and others not, I look for the invoice that 
the customer thinks they are paying on the list. I then click on it in 
the list and click the Process Payment button. If I don't select an 
invoice, and click Process Payment, nothing happens - even though the 
customer has unpaid invoices. Again, if you click on a paid invoice 
(i.e. one that has a tick), and click Process Payment, the resulting 
screen has 0 in the amount paid field, even if the customer owes money. 
If I think I'm assigning a payment to an invoice it's only because 
gnucash leads me to believe that's what I'm doing. What you need is a 
field showing amount owing on the search results screen.

I agree with you that the FIFO method of accounting for invoice payments 
makes sense to the supplier in many situations - particularly when you 
are supplying goods. However, where you are dealing with bureaucratic 
organisations, and particularly where you are a third party providing 
services to a client involved in a relationship with their client, as we 
are, you need to be able to account for which invoices have been paid 
and which haven't. If I phone a client and tell them that they owe us 
money, they want to know for which piece of work we have done for them. 
I can't tell them that I don't know, because my accounting system 
doesn't tell me. I always enter the invoice number in the Num field on 
the Process Payment screen for that reason, and if I have a cheque 
that's paying for multiple invoices, I process each of them 
individually. Gnucash encourages me to do that by usually defaulting to 
the total owing on the invoice I have clicked on - although it does 
sometimes display less than is owing on the invoice, presumably because 
it has assigned some part of an amount I have previously entered to that 
invoice. I now see what led to my payment entry being split into 4 
components in Accounts Receivable, but I don't know why. Clearly gnucash 
is assigning the payment to four invoices, but it doesn't tell you which 
invoices, so what's the point in the multiple entries? It's just confusing.

You may say that gnucash is following the FIFO model, but if it is the 
UI needs to reflect that. As it is, you wouldn't have to do much to 
provide the user with the alternative, since clearly gnucash already 
associates payments with invoices - you just need to allow the user to 
tell the program which ones.

Derrick

>> Derek,
>>
>> Thanks.  As you have probably noticed from my subsequent email, I 
>> managed to sort this out.  Sorry to put you to the trouble of a 
>> response.  On the subject of "Accumulate splits" I have noticed in 
>> the past that when processing a payment gnucash is just as likely to 
>> create multiple transactions out of one payment - I noticed that on 
>> the 5th January, it split one cheque into 4 transactions!  I haven't 
>> used 1.8.10 long enough yet to know whether this problem has gone 
>> away.  Another problem with processing payments has been that the 
>> program does not always mark an invoice as paid in the customer 
>> invoices window - these two behaviours are often associated. i.e. If 
>> a cheque is broken up into multiple transactions, it won't be marked 
>> as paid.
>>
>> Derrick
>>
>> Derek Atkins wrote:
>>
>>   
>>
>>> Derrick Ashby <daeroncs at fastmail.fm> writes:
>>>
>>>
>>>
>>>     
>>>
>>>> Hello all
>>>>
>>>> I've got another unbalanced balance sheet, this time in my business
>>>> accounts.  I've loaded the backup accounts files back several days
>>>> and found the newest one in which the accounts balance.  It
>>>> happened three days ago.  Is it possible to use the log files
>>>> created (or any other method) to work out which transaction(s)
>>>> caused the inbalance?  I upgraded to 1.8.10 at about that time, or
>>>> a little earlier, so it may have something to do with the bug that
>>>> Derek reported.  What does "Accumulate Splits" mean, anway?
>>>>
>>>>
>>>>       
>>>
>>> Check your AR and AP accounts and see if you have imbalanced
>>> transactions.  Most likely you are seeing one of the side effects of
>>> the bug I "reported" yesterday.
>>>
>>> "Accumulate Splits" (which is the default) means that if you have
>>> multiple invoice line-items that go into the same account the invoice
>>> code will accumulate all those entries into a single split.
>>> Unfortunately this "default" is broken in 1.8.10.
>>>
>>> -derek
>>>
>>>
>>>
>>>     
>>
>>
>>   
>
>
>  
>