Is Bills Due Reminder broken ?

[John Zoetebier]

On 10 Jul 2003 11:23:04 -0400, Derek Atkins <warlord at MIT.EDU> wrote:

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

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.

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

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.

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

Where can I find the payment transaction.
Also: you mean I do not have to re-enter the invoices. only the payments.

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

This is my problem:
- I cannot see which payments have been done for a bill (or invoice) on the 
bill form.
- When I unpost a bill I have to manually remove the payment from register 
"Accounts Payable".
	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 ?


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

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 ?

>
> But even so, you can just remove the payment transaction
Where ?
How ?

> , unpost the
> bill, change the bill, post the bill again, and then process payment
> again.  Why doesn't that work?

To be honest: I did not know that this was the process for handling changes 
to bills.
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.

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

Could this be caused by me using 1.8.0 first and 1.8.4 later on ?

>
>> 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.
I was not aware of this.
Do you recommend to download CVS version ?
If so, which version ?

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

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.

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

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.

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

Bill and payments should be kept together for the end-user during all 
stages of the billing cycle, otherwise the billing process becomes 
confusing.
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.
All information should be visible on the same billing form.

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

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.

-- 
John Zoetebier
Web site: http://www.transparent.co.nz