"Automatic Payment Forward" - what the hell?

[Derek Atkins]

tereque <tereque at gmail.com> writes:

> hi Maf,
>
>
> On 2013.08.14 12:00 AM, gnucash-user-request at gnucash.org wrote:
>> Message: 8
>> Date: Tue, 13 Aug 2013 11:13:37 +0100
>> From: "Maf. King"<maf at chilwell.net>
>> To:gnucash-user at gnucash.org, tereque<tereque at gmail.com>
>> Subject: Re: "Automatic Payment Forward" - what the hell?
>> Message-ID:<2122216.yVv0mS0dJ3 at calufrax.standbyevents.co.uk>
>> Content-Type: text/plain; charset="utf-8"
>>
>>
>> You'll need Derek to go into the mechanics, but AFAIK, the "automatic payment
>> forward" happens if you book more payment than has been invoiced.
>>
>> Say you have a invoice for ?70, and payment comes for ?100.  you'll get an
>> A.P.F of ?30.
> generally I though something like that would be happening. Is there a
> way to either shut that automatic off, or control it's behavior? maybe
> Derek can switch the lights for us all here?

In the original design you didn't pay an invoice, you paid a Customer or
Vendor.  The Invoices were just the vehicle for the process.  When you
Process a Payment from a Customer you are saying that the customer sent
you a check.  GnuCash will apply that payment to the invoices for that
customer in FIFO order.  Originally there was no other way, it was
ALWAYS FIFO.

GnuCash always let you pay multiple invoices.  E.g., sometimes I'd
invoice a customer multiple times and then they would eventually pay all
the invoices at once in once check to me.  A single Process Payment
would let me mark all the invoices paid at one time.  The way this works
is that it takes the payment and applies it to the first invoice until
it's fully paid.  Then it applies any payment overage to the next
invoice, and so on, until either it runs out of payment or runs out of
invoices.  If it runs out of invoices then you have an "over payment"
which sits in A/R and will get applied to the next invoice you post in
the future.

Later on I added the ability to put one invoice in the front of that
FIFO (the ability to pay a specific invoice).  All this does is put the
selected invoice at the front of the FIFO list and applies the payment
to it first.  After that the process works exactly as before.

> Actually my day to day situation is that customers never pay the exact
> amount invoiced to them, or sometimes the invoice amount has to be
> changed because some parts of an order are cancelled, etc ...

It sounds like you really want credit notes, which might be better for
you.  Alas, that wont be there until 2.6.

> So I have to post/unpost/post invoices quite often. Even after
> payments had been made. Or a project (would be a 'job' in the
> terminology of GC) consists of several Invoices .... So I am trying to
> keep control of what actually happened.

Unposting an invoice AFTER a payment has been applied to it is one
possible bug in the process.  There IS a bug somewhere that will cause
the invoices and payments to get out of sync, and it's *likely* that
unposting and reposting an invoice is a part of the problem.  However
nobody has ever been able to come up with a reliable method to reproduce
the problem, so the bug has been long-outstanding.

So I would suggest that you don't do that.  If you're going to reset an
invoice amount then I suggest you do it before you pay it.

>> I think it comes about if you try to pay several invoices with one payment -
>> whilst GC by default will allocate payments to the oldest invoice first
>> (FIFO).  You can make one invoice "jump the queue", but not several.  EG. if
>> invoices 1 to 5 are outstanding, you can allocate payment to no.3, but not 2
>> and 4 - you'll pay 1 and part of 2.

This is correct, at least for now.  I believe Geert has been working on
a way to select the invoices to be paid as part of his 2.6 work.

> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.

-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