Is Bills Due Reminder broken ?

Derek Atkins warlord at MIT.EDU
Thu Jul 10 12:23:04 CDT 2003


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

> Right.
> For example I entered a bill and discovered during "Process Payment"
> that the actual amount was 1 cent out.
> I had to go back, unpost, fiddle the amount, post again and then
> process payment.

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?

> An other example is the invoice date.
> I discovered that the invoice date was wrong.
> I could not change the invoice date as it was disabled.
> I unposted the bill, removed all items and discovered that I could not
> remove the invoice.

I'm not sure why you removed all the items just to change the date.
You should just be able to unpost/change/repost.  However you are
correct that there is no way to "destroy" an invoice -- you can mark
it "inactive" to keep it from coming up in (most) searches.

> > So, any guidance on what you did and how you did it would be greatly
> > appreciated.
> 
> These things do not popup in the test cases of the developer, because
> he/she know the logic of the system and enters test cases accordingly.
> How this could happen is a mystery to me too.

Well, that's why I'm asking what process you used to get into this
state.  My testing didn't show this.  If I knew what process of
posting/unpost invoices and payments you used I might be able to
reproduce it here and figure out the error in the logic.

In the meantime, what you could try to do is delete all your "payment"
transactions and re-enter them; that should do the right thing (unless
there is yet another bug).  That will at least get everything working
again.

> All I know is that I entered all invoices and bills.
> During the processing of bills there were some rounding problems which
> required me to unpost the invoice.
> After having done all bills I went over the reconciliation process.

What reconciliation process?

> Then I discovered that transactions in my previous system were
> "misplaced" to "Undeposited Funds" while they should have gone to the
> a bank account.

Which "previous system"?

> However the system does not allow me to reverse "Process Payment".
> Bill and payment belong together, but they are not treated that way in
> the system from an end-user point of view.

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.

> For example I discover  that a bill amount has to change AFTER I have
> done a process payment.
> You cannot only change the amount of the bill, because there is a
> corresponding payment.
> Both need to be changed.

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.

But even so, you can just remove the payment transaction, unpost the
bill, change the bill, post the bill again, and then process payment
again.  Why doesn't that work?

> This is not problem when the payments hs not been reconciled yet.
> If the payment has been reconciled you have to notify the end-user
> that the payment will change to unreconciled.

I'm not sure I understand what this means... What do you mean by
"notify the end user that the payment will change to unreconciled"?

> You still need to link bill to the same set of payments, even if you
> unpost the invoice.

I'm not convinced I agree with this.  If you unpost an invoice/bill,
how is the system supposed to know that you plan to post it again?  If
you do NOT plan to re-post it again, then if the payment is tied to
the invoice/bill then what do you do with this payment and how do you
untie it?

If you associate a payment with an invoice, then it means you cannot
just treat the payment transaction like a normal transaction anymore
(just like an invoice transaction is not a normal transaction).  It
would absolutely require a "unpay" feature to remove a payment...  And
then you need to deal with partial payments and such.

IMHO, the way it works now is much clearer: when you post an invoice
it creates a transaction in the CoA (which is tied to the Invoice
internally).  When you process a payment, that payment gets tied to
the invoice's "posted transaction" (via a lot).  If you unpost an
invoice, the posted transaction is removed but the payment (if any
remains).  The posting process tries to find any outstanding payments
and will associate with themselves.

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.

> The system has no (easy) way of:
> - tracking if a bill has been paid or not.

As I've said multiple times, this is in CVS and will be in 1.8.5.  The
"search for invoice" feature has a "paid" column, and the printed
invoice also can list all the payments associated with an invoice.
This tracking _IS_ done.  The problem is that there appears to be a
logic bug somewhere that is not balancing the payments and invoices
properly.

> - which payment have been done for a bill (or invoice)

I don't understand what you mean by this...

> A very convenient method of handling payment is to show them on the
> same form as the bill.
> Each payment is one line under the bill.

The printed invoice will do this (if you turn the feature on in the
report options).

> For example you are a help desk person and a customer rings they have
> paid a bill at a particular date.
> This information is not visible on the bill form at present.

It is visible in the printed invoice (see above).

> This is a feature that is dearly missing in gnucash.
> For exaple if I mistype the payment amount, how can I change the
> amount later on ???

You edit the transaction in the register, just like any other
transaction in gnucash.  A payment is special only in the creation
process...

> The forms should follow the work flow as much as possible.
> Bill/invoice and payment should be on one and the same form, otherwise
> you run into problems.

They are:

        Business -> Customer -> New Invoice
        Business -> Customer -> Process Payment

Similarly:

        Business -> Find Customer
                [Invoices]
                [Process Payment]

They are together...  Just not, perhaps, the way you think about it.
I don't know what else to say.

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.

Thanks,

> Regards,

-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


More information about the gnucash-user mailing list