A couple of doubts

Mike or Penny Novack stepbystepfarm at mtdata.com
Wed Dec 16 08:34:27 EST 2009


Elizabeth Dodd wrote:

>On Wed, 16 Dec 2009, Conscious User wrote:
>  
>
>>That's too bad. But is "paying the entire bill" that rare of a use case?
>>
>>I'm surprised that no accounting package does this.
>>    
>>
>My accounting package doesn't pay the bill
>I do.
>And 99% of the time I pay the entire amount.
>
>
>  
>
Perhaps there is misunderstanding about the original question? Could you 
please rephrase it. I was interpreting the original question as asking 
whether there could be an AUTOMATED action on the part of the package to 
"pay the entire bill", so you didn't have to enter this transaction 
manually after having made the decision to pay the entire amount (once 
the action has been taken to pay the entire bill, etc.).

I was imagining that this was a case who had linked a current funds 
account to their credit card and had a standing order that this account 
pay the bill on the due date.

Please understand that I used to work with systems like this. For 
example, a life insurance  policy holder could have a standing order "if 
not OTHERWISE paid by the due date then surrender from the accumulated 
extra policy values to pay the premium". But you aren't understand how a 
SYSTEM of this sort works. That wasn't done in the accounting package 
(general ledger system). There were programs that generated the 
transactions which caused actions like this and these transactions 
merged into the stream of transactions entered manually -- as far as the 
accounting package was concerned, no difference whether a human sitting 
at a terminal entered the transaction, one of these automated 
transaction generators, or a special transaction generator I wrote ad 
hoc to create a few tens of thousands of transactions to correct the 
records after some bug was fixed (imagine how many people sitting at 
their terminals to manually correct if 30,000 policies had been affected 
by a bug).

The key is that 99% --- that is NOT good enough. In the example I just 
gave notice that the policy holder COULD have chosen to send in a check 
for the premium due and that could have been coming through the system 
the same night. Which means that the overall system had to be "smart 
enough" to spot the duplicate payment and back out the surrender of 
values, etc. In other words talking about a very serious collection of 
software maintained by 20-30 full time programmers and a few senior 
systems analysts. That 99% might look good to you, but with an error 
rate that high, imagine how many bad transactions when it would be 
100,000 transactions per night.

I will repeat -- that's an entire "system" and the "transaction 
generators" were NOT part of the "general ledger" (accounting) system.

Michael D Novack, FLMI


More information about the gnucash-user mailing list