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