[freeside-devel]

[Dave Burgess]

ivan wrote:

> On Sun, Dec 23, 2001 at 05:04:04PM -0600, Dave Burgess wrote:
> > - Generally Accepted Accounting Practice (GAAP) says that when a
> > customer has more than one outstanding invoice, any payments received
> > will be applied to the oldest invoice first, and the remainder of
> > the payment will then be applied to each subsequent invoice.  We
> > can get into the reasons in private E-Mail if anyone would like.
> > The current payment processing system doesn't do this.
>
> Current CVS now does this in all cases.  The only missing piece was
> calling ->apply_payments on the FS::cust_main object when a new payment
> (not against a specific invoice) was entered.
>
> > - Extend the 'invoicing' code so that it looks for unapplied credits
> > and applies them to the new invoice (this might already work, I
> > haven't even checked).
>
> It does.  See the `-p' option to freeside-bill.
>

You're a mind reader - that's all there is to it :-)

I'm having a little weirdness in the Invoicing code, by the way.  I haven't
done enough research to figure out what broke, but my freeside-bill runs
abort with a complaint in one of the records about duplicate services.  I'm
not seeing them, but I've no doubt the problem exists.  The core dump is a
little disconcerting, though, so I need to get back to it and see if I can
figure it out.

>
> >  This way, pre-paid accounts (which we
> > regularly get) will work correctly.  Every once in a while, we'll
> > get a customer that drops $50 on us for $15 a month dial-up.  From
> > what I've seen, we would go in and change his 'next bill' date to
> > 100 days from now - that's suboptimal.
>
> Sounds shady from an accounting perspective, too.
>

That's one of the reasons it's suboptimal.  The other reason its suboptimal
is Donna.  When she's unhappy - everybody's unhappy.  The extra data entry
would spin her clear into the ceiling!

How shady it is from an accounting perspective depends on how you track it
(accrual vs cash basis).  If you use accrual, then you need to actually
carry the payment forward as an 'unapplied credit' and carry the money
forward from month to month, since the money could only be 'consumed' based
on the consumption of the service.  If you use cash, you need to report it
as received and then carry the excess in a pre-paid account.

We (Nebraska On-Ramp) use the cash method, which is easier in this
scenario.  We made the decision that any 'unapplied credits' are equivalent
to a prepaid account (since they exist on a per-account basis) so we're in
good shape.  Of course, having made that decision, I need to go into the
database and write a report for the accountant to let him know what
liability accounts (the pre-paids) we have so that he can include it on the
balance sheet.  It's isn't true double entry accounting, but it simulates
it just fine.

The part about getting the MBA that I hated the most was the accounting.
I'm not bad at it - I just hate it.

I'm still working on splitting up those diffs.  I know you prefer -u diffs,
but I'm finding it really hard to split the diffs up by hand that way.
Would you be willing to accept them as context diffs, if I can separate
them into logical blocks that you can check out.  Whatever it takes to make
this more palatable for you without me having to retype all of these
changes....