The expire date is the ONLY thing used to determine billing.
> If you run billing after the account expires, folks can't get online.
So you do billing 2-3 weeks before they expire. For example you could
do billing for March right now, giving them about 2-3 weeks to pay their
bills.
> If you run billing before the account expires, you end up running way in
> advance.
I don't quite know your definition of "way", but I generally like to see
my bills a couple weeks in advanced to allow me to pay them in time. :)
> The underlying issue is, where do you get the slack time for folks to pay
> the bill, or for us to get into contact with the folks whose credit cards
> didn't go through?
You bill before they expire. Thats your slack time.
> Q: Related to above, if you DO have to bill in advance (like the middle of
> the month) what happens to any charges that accrue between when you actually
> run your billing and the end of the month? Like time overage charges or
> support time or whatever.
They get put on the next bill.
> Q: When doing invoices, does the autobill checkbox tell the Credit-invoice
> to pick that MBR up for billing and batching? Does the Renewal-invoice
> therefore ignore MBR's that have autobill set?
Yes. That is why there is TWO (actually three) distinct billing runs
you
can do, Renewal (non auto-bill CC) and Credit Card Auto Bill.
> Q: For that matter, what are Invoice-invoices and Trade-invoices for? And
> what effect does selecting them have?
Invoices are items which must be paid. Trade isn't used.
> Q: Speaking of checkboxes, what is the "New" checkbox for? How about the
> "Current" checkbox?
It means the account is New. Current means its current. These are ONLY
applicable if you use External Systems. Otherwise ignore them.
> Q: What is the *exact* process that occurs when the "Paid" button is pushed?
I assume you mean "pay". It checks to see if there is any line items on
the
invoice left to pay. If so, it adds then up, creates a payments, and
extends
the account according to their billing cycle.
> Bug: Running "Charges with yesterday's date repeatably results in a
> type-mismatch.
Fixed in 2.0.86
> Bug: There is no hourglass when "charges" are running.
:( Ditto.
> Bug: Renewal invoice totals, if you manually edit the invoice from the
> "Invoice" button on the MBR, round up to whole dollars.
This isn't editing an Invoice, its creating a new one. The rounding
has been fixed, though.
> Bug: When adding a new service, you can't select the service type unless
> you save then re-edit the service record.
Fixed in 2.0.80.
> Note: The Expire date is very useful for creating a buffer between the end
> of paid-up time and the actual expiration of an account. But when you pay
> an invoice, instead of adding the paid-time to the paid-through date, adds
> it to the expiration date and then replaces both the paid through and
> expiration dates. The effect is that you are extending the pay period by
> the default expiration interval. (Not sure if this recurs every month or
> just the first time.) In any case, it would be *most* useful if either the
> paid-through and expiration dates advanced by the pay period independently,
> OR the "extend" value should stick across months.
Extend is a temporary extension. Limit is the permanent extension. We
are
also looking at allowing the Paid-Thru field to replace the ExpireDate
as the
update for payments, as requested earlier.
> (Note, note: If the Expire date and the Paid-thru date are supposed to be
> the same, why have two? Second-degree normalization takes it out.)
Because you can give someone a couple of extra months of service
without them actuall "paying" for it. In this case, their paid thru
would NOT equal their expiration.
> Note: In the list of invoices, how about some indication when an invoice
> has already been paid?
Thats more tricky, although we have been working on it. You don't pay
an invoice, you pay line items. We are working on adding this plus the
ability to only search invoices with open invoices. Some of this is
already
in 2.0.85.
> Note: This is a philosophy piont, if you're going to impose a process, you
> really have to define it for the folks who are using it. The lack of
> documentation is really a critical issue. If the software was more
> flexible, it would be less of an issue, since we could adapt it to our own
> processes, but Emerald doesn't work that way. To use Emerald you have to
> buy into Emerald's way of working -- which you don't define. The *entire*
> process has to be *at least* (and I know that many programmers shudder at
> this, but I'm a firm believer) flowcharted with the breakpoints and
> conditions laid out. If you had just that much, I think a lot of these
> questions would go away. And note, we really do want to bill once a month.
We are working on this. We now have to sepeerate peieces of
documentation
(user and technical) and are also working on new additions to Emerald to
allow
it to adapt to YOUR billing method.
-- Dale E. Reed Jr. (daler@iea.com)_________________________________________________________________ IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs Internet Solutions for Today | http://www.emerald.iea.com-Emerald Mailing list (emerald@iea.com)