Is Bills Due Reminder broken ?

[Derek Atkins]

John Zoetebier <john.zoetebier at transparent.co.nz> writes:

> > This should work fine...  At least in my tests it did the right thing,
> > but my testing was rather limited...  I assume you've done all this
> > with 1.8.4?
> 
> Maybe this is part of the problem.
> I switched to 1.8.4 after having entered several transaction, because
> I got a post recommeded to switch to 1.8.4.

Hmm.. There were definitely problems with payments in the early 1.8
series...  There was a MAJOR problem in either 1.7.8 or 1.8.0 in that
payments were applied incorrectly -- actually I just looked, the
problem I'm thinking of was fixed in 1.7.8.  But yea, it's possible
there were other bugs fixed along the way.

> > I'm not sure why you removed all the items just to change the date.
> 
> I could not change the date of the invoice.
> My next thought was to remove the invoice.
> As that was not possible I thought, if I remove all items, may I can
> remove it then.

Hmm, unposting the invoice should have been sufficient to allow you to
change the date.  Clicking on the "Edit" button should bring up the
dialog to edit the invoice parameters.  Re-posting will allow you to
set the "posting" date.

As for "removing" the invoice, yea, there's no way to do that.  Sorry.

> Where can I find the payment transaction.

You'd find it where you find any transaction... in the chart of
accounts.  Open up your A/P account, or look in the account where the
payment came from (the Bank account, or Credit Card account).  You'll
see the payment transactions there.

> Also: you mean I do not have to re-enter the invoices. only the payments.

Correct, you should not have to re-enter the invoices.

> > Which "previous system"?
>
> Previous system was SQL Ledger, which has caused me some problems in
> the passed when upgrading from one version to an other. Also I found
> the lack of a reconcile function so important that I decided to switch
> to gnucash which I had been using privately for several years.

Ok..

> > I don't think I understand...  You can just delete the "Payment"
> > transaction directly from the register.  As for them not to be treated
> > together, again I don't think I understand -- there is a "lot" that
> > ties the payment to the invoice.
> 
> This is my problem:
> - I cannot see which payments have been done for a bill (or invoice)
> on the bill form.

Yes, this was a concious choice.  A payment is not a bill/invoice
item.  Also, payments apply to customers/vendors, not to individual
invoices.

> - When I unpost a bill I have to manually remove the payment from
> register "Accounts Payable".

Why?  The payment has still been made, so why do you need to remove
it?  The payment should remain in the system, and invoices/bills will
get applied to it as they are posted.

> 	As the transactions in this reigster are not grouped by {bill,
> payment} I find it hard to see which payment 	belongs to which bill.
> 	I do not see something like a lot number.
> 	How do I match them up ?

Yea, lack of a lot GUI interface is an issue, and something that is
being worked on.  As for how you match them up, well, you already know
the customer/vendor a payment is for, so the only question is which payments
get applied to which invoices.

In particular, using the Printable Invoice report will tell you which
payments are attached to a particular Invoice.

> > Ok, so you figure out the bill is wrong... You unpost it, make the
> > changes, and then repost it.  The fact that payment has been applied
> > shouldn't matter.  It's not like the amount of the payment has changed
> > -- the check (or cash) that you deposited didn't magically change
> > value, too.  So, this should just work, and in my original testing
> > doing this should put the posted transaction back into the same place.
> 
> This logic only holds if the bill amount does not change.
> If the bill amount changes I have to go through the register to change
> the payment amount, right ?

No...  You've already made the payment -- that shouldn't need to
change.  For example, the amount that your customer paid you hasn't
changed...  Or the amount on the check that you've written hasn't
changed..  So, no, the payment shouldn't need to change.

If it does, then you can either adjust the Payment manually from the
A/R or A/P register, or you can remove the transaction from the
register and then Process Payment again.

> To be honest: I did not know that this was the process for handling
> changes to bills.

This is (hopefully) due to lack of documentation.

> All end-user actions should go via the bill form, not partly via bill
> form, process payment and when I need to change something I have to go
> via the register.

I (and most of the GnuCash developers) disagree.  Most user actions
should go via the account registers.  The problem is that invoices and
bills are "special" and live outside the register / chart-of-account.
So you need a special interface for those...

> > If you unpost a transaction and then repost it (without posting
> > anything else), it _should_ re-apply itself to the same place it came
> > from.  However, given the randomness you showed me, it's possible this
> > isn't happening correctly.
> 
> Could this be caused by me using 1.8.0 first and 1.8.4 later on ?

It could.  It shouldn't, but it could..  There were a LOT of problems
in the early 1.8 releases, but I don't _think_ this was one of them.

> > As I've said multiple times, this is in CVS and will be in 1.8.5.
>
> I was not aware of this.
> Do you recommend to download CVS version ?
> If so, which version ?

No, I do not recommend CVS for the light-at-heart..  If you ARE going
to use CVS, I would recommend the 1.8 branch...  However, my point was
more along the "I've already dealt with this issue, can the subject be
dropped?"

> Or an arithmetic bug ?
> If you register the amounts in floating point, these amounts will most
> likely never match up.
> The best way to prevent floating point arithmetic error is by storing
> all currency amounts as long values in cents.

Unlikely.  Amounts are not stored in floating point.  Now, that
doesn't mean that there isn't an incorrect math function or some other
math problem, but floating point isn't an issue.  Besides, looking at
your data file, that's clearly not the problem.

> > The printed invoice will do this (if you turn the feature on in the
> > report options).
> 
> I swiched on payments in options and it works.
> However setting is not remembered for other bills.
> I have to switch it on for each bill individually.
> What I discovered from this report is that the payments and bill
> connections is completely stuffed up.
> Just one example.
> When I look in register ASB VISA for bill 111 the payments do not
> match the payments on the report.

Yea, this is a known problem, bug #104156.  And yea, this report shows
the problem quite clearly, doesn't it?

> > You edit the transaction in the register, just like any other
> > transaction in gnucash.  A payment is special only in the creation
> > process...
> 
> Bill and payments should be kept together for the end-user during all
> stages of the billing cycle, otherwise the billing process becomes
> confusing.

See, I don't see payments being applied to bills; I see payments being
applied to vendors.  It's quite possible to pay multiple bills at
once.  Or a customer may pay multiple invoices at once...

> The internals of the system should be hidden for the end-user.
> Where you store the bills and payments should not matter from an
> end-user point of view.

Most of the internals are hidden from the end user.  It's just that
in this case there is a bug which is making the internals quite
obvious.  This is unfortunate. :(

> All information should be visible on the same billing form.

See, I don't agree.  The developers had this dicussion months and
months ago, and we decided that "separation of functionality" was a
virtue.  The "all information on one page" is the Printable Invoice.
No, you can't edit from there....

> > I still agree there is a bug here in the posting/unposting and payment
> > process... I'll try some code inspection to see if I can find it.  The
> > best way you could help is if you could try to remember the
> > step-by-step process you used that caused the problem.  I understand
> > that might not be possible, but it would help me tremendously.
> 
> I will try to fix up the present system first.
> Then if I enter my next bill I will check to see if it happens again.

Thanks!  I'd really like to hear if it happens again, and if so,
what you did to get it that way.

-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