If an invoice calls for $19.95 and someone pays $20.00, I just mark it paid
at $19.95, then run a small script using ISQL/w that changes the payment
value for whatever PaymentID was associated with that invoice. So now the
Payments.Amount is listed as 20.00. Then I go into Emerald and into the
MBR for that customer and create a charge for -0.05 and give it a
description of something like "Credit from overpayment for inv. 7432".
When I remember to, I also adjust the MBR's Balance from 0.00 to -0.05.
The next time an invoice (type=renewal) is created for that person, the
"negative" charge will appear on it and the total amount due will be $19.90
instead of the normal $19.95.
This isn't a perfect solution, but I've been doing this since sometime
around October of last year and our accountants/bookkeepers seem to be a
little happier. You can do the same thing for shortages too (invoice
called for $19.95 and they mailed $19.00 or something).
My emerald db has a Credits table, but there's nothing in it. I guess this
is for use with Emerald 2.5 and/or later...
> From: Jeff Woods <firstname.lastname@example.org>
> To: email@example.com
> Subject: Re: Carry Balances Forward
> Date: Monday, May 04, 1998 4:36 PM
> At 12:56 PM 5/4/98 -0700, you wrote:
> >1) Carry Balances Forward. On average, we have approximately two hundred
> >people that owe the previous months payment at time of invoicing, about
> >that owe two months and about 6 that owe three months payment. I have
> >figured out that I can change the expiration date based on the paid
> >date to show the customers as "current" in order to print their next
> >invoice and then change the dates back. My problem is that the past due
> >amounts are not reflected on the current invoice and I fear that people
> >will ignore or overlook the fact that they have not yet paid for the
> >previous month or months.
> Emerald 2.2 does not support balance forward. It cannot be done. In
> fact, Emerald 2.2 won't even generate a new invoice for a cusotmer with
> outstanding prior invoice. Partial payments are also not available.
> >We would like to drop our existing accounting system and go with Emerald
> >but can not do this until we get some of these issues resolved. We were
> >hoping that we would be able to have 2.5 up and running in order to
> >this issue, but we don't want to run parallel systems much longer as
> >is time consuming and hard to keep track of. Any suggestions that you
> >have would be greatly appreciated.
> Wait for 2.5, from what I'm told. That's the only solution, apart from
> dumping Emerald entirely, and it has too many other nice features
> (SQL/Radius integration) to consider that.
> Emerald Mailing List firstname.lastname@example.org