Re: [Emerald] Changing Permanent Expire...

David Routh ( )
Wed, 15 Sep 1999 21:50:08 -0500


>remaining). However, this isn't the cleanest way to do it. Customers
>get very concerned about any kind of implication they didn't pay you on

Yep, I have to agrre with you there.

>time. I believe an Anniversary billing cycle will work better for you
>if you do not want to invoice your customers for the prorate+the first
>month on their first bill. My own opinion (I used to run an ISP) is
>that it's also better to have money coming in all the time instead of
>just once a month, but your mileage may vary.

Yep, that's pretty much what I think... besides, once we grow to tens of
thousands of customers (always gotta think BIG) it'll spread accounts
receivable throughtout the month...

>> What was (is) confusing is a large part of our customers that we're
>> inputting now expire on the 1st of the month... they're not paid thru that
>> date but "to" that date... so my thoughts were to expire them on the 30th
>> and that's why the questions...
>Do they expire on the first of the month because you were manually
>entering them while you had the monthly billing cycle configured?

Yes and no. Before Emerald we pro-rated the second month invoice and made
them due on the 1st. And we did start out setting the customers we were
entering into Emerald on a Monthly cycle, which set the expire to the
1st... which we're now changing to Anniversary.

>The real question here is, are your customers really paid through the
>last day of the month, or are they actually paid through varying dates
>but have an expire date of the first due to the data entry process (and
>the configuration while it was being done)?

Actually, varying dates as we used to pro-rate them to the 1st... which is
changing now... hummm... What happens when they sign up on a day of the
month, say the 31st, and the following month only has 28 or 30? :^) Sorry,
just had to ask!

>something you want to manually set each month, either - and it's updated
>automatically each time you take a payment so that it matches the
>EndDate of the invoice you paid (in other words, modifying the PaidThru
>date won't change the behavior of the program at all, and will be
>overwritten at the end of the first billing cycle). The date you want

OK, so really, we don't have to set it (Paid Thru) to any particular date
right now since when we create the first invoice for that customer it'll
reset it anyway... is that right?

>to modify, if you choose to modify any of them, will be the BilledThru
>date - that date determines the StartDate (and therefore the EndDate) of
>each subsequent invoice, which in turn defines the Expire date for the
>account once you've been through a billing cycle.

OK, that's the one we're setting now to match the actual date our customers
are paid thru (or to). So to start with now, we should have the Billed
Thru and Expire dates matching each other...

>So, if you want your accounts to expire at the beginning of the day they
>expire (or at the beginning of the day their grace period ends), you can
>set the values above to 6 and 14 respectively. Emerald inactivates an
>account at midnight on the date of expiration. The dates on the
>customers' invoices need not change, it's only the behavior of the
>authentication and bill generation that will change.

That sounds good to me... we were trying to determine how many days before
to invoice and then how many days after to have the account become
inactive... 20 seemed like a fair number.

>*smacks self in head* I believe the solution to this is as simple as
>putting the dates inside of quotes (set paidthru="9/30/1999"). I should
>have caught it the first time you sent it through. :) Try that.

Well, I looked thru the archives and while I didn't find an answer I did
see soome dates in quotes... *smacks self in other side of head*.

>(Remember, you're not changing how the system behaves by changing the
>PaidThru date though.) (It must be late. I'm getting parentheses-happy.)

late... hey, is it dark outside already?

>Let me know how it goes.

Going good now... Thanks very much for all the help...
Thanks, David

For more information about this list (including removal) go to: