BY request here is the HTML hard copy LOL
> How should we handle an account that is billed quarterly,
biannually, or
> yearly? Here's my first guess (in
pseudocode):
>
> get Account Start Date;
> get Account Bill
Type; // This would be quarterly, biannually or yearly
> ... (assign $bill
the value of the bill type, 4, 6, or 12
>
> if(It's been $bill
months since they signed up) {
> bill_them();
> } else {
>
waive_them();
> }
>
> But isn't that just anniversary
billing? If I was billing yearly, and
> someone signed up in May,
I'd prorate them and charge them only for
> May-December... then they
would get billed in January along with the other
> Annual customers.
Then we have two types of behavior. We could give them
> options
like "Auto-ProRate yearly prices according to signup month" and
> "Treat
non-monthly accounts as Anniversary"
>
> How do you guys think it
should be handled? Troy, you said you've had
> experience with
commercial packages!
yep. The nice thing about this, is its almost
universal in that anything
other then monthly is prepaid. the important
thing to not here is that our
config function is going to be our most
important function. This is where
we will win or lose the
clients. If we build it properly they won't be
upset with "why does it
do this this way :( ". Having said that, here is
the likely scenario's
and what we must do for each. We MUST have questions
in our config that
will set this up. and there should be an option in the
customer profile
to override the default.
now, what I would do is have a question in the
config that says "allow
override defaults" IF this is set to true, then
certain extra pieces of code
could be add'd that would provide the overide
functions on a per client
basis. The reason for doing it this way, and
I realize its more difficult,
is that this prevents those folks who set it to
"no" from seeing the
overrides and being confused and trying to use
them.
ok, so having designed an overide implentation schema we now turn to
the
billing itself.
if they are quarterly, annually, etc... AND PREPAY.
then expiration date is
set to end of cycle AND when new cycle comes they are
billed x days in
advance. When they are billed, they are billed per
their format. which
should be a special billing type other then monthly cause
I seriously doubt
anyone that is doing qtr, bi, or an billing is using the
same price as
monthly for those clients.
Now, if they have qtr, bi
or an AND NO prepay, then expiration date is set
per above and billed at the
expiration. You will need to test each time for
it to have passed the
"cuttoff" date. This is the date at which it has
become deliquent and
now moves to collection. Remember that we will be
providing hooks for
events to be triggered as each deliguent bill comes.
For example, 1st late
notice, 2nd late notice, final collection & closing of
account.
Again these would be pre-configured in the configuration routine,
and show in
the clients account if they have been sent or not.
Now as to how to bill, you
always will only have 3 sets of conditions.
Everything else is an
extrapolation of one of the 3.
A: you bill them on the same day each period,
but NOT necessarily the 1st or
3rd or whatever. Its "ANNIVERSARY"
x-period will have transpired
irregardless of the month. This is
strictly by billing days.
b: you bill them on the same day each period, but
is always the same day.
5th, 3rd, whatever. Its "Period" billing.
on x date run bills.
c: you bill them on a prorata basis. Once the
prorata is computed, then the
standard billing type is applied.
now, you
could have c &b or C&A or A or B for any individual
client.
Now this would seem to be a ton of coding. BUT the thought
just crossed my
mind. IF we put a "billing date" field into the
db. That is created at
customer creation time, based on the formula's
stated above. THEN our
billing engine is GREATLY simplified.
Because then all it does, is check
the billing date field for each client and
if is at that date, THEN its
billed. PERIOD, end of story. Now,
how it bills, will vary based upon the
previously described actions.
But the billing routine itself does'nt change
:)
one caveat to watch
for. IF the billing term is "end of month", then you
must have in the
db a routine which will calculate when the end of month is.
TAKEN IN TO
CONSIDERATION LEAP YEAR!!. so a typical config might have this
in
it.
Closing
Days
[ ] INT value. ( this
is the number of days prior to the end of billing
that you want to close all
open bills and start processing. For
example. Your electric meter is read
on the 20th and your bill isn't
generated until the 23rd because it takes
time to process the
information. So while your billing date is
23rd-22nd.there are x days,
that are old if you will. This is VERY standard
in large
corporations.
Even in my small biz, when I was an ISP we closed the month, 3
days early so
that all the billing could be done and notices mailed BEFORE
the 1st so that
people had their bills no later then the 1st. ITs not
fair to the client to
give them a bill for money that is already 5 days past
due.
Default Billing term for Period
billing:
[ ]
1st
[ ] nth days since last
billing
[ ] fixed day (insert date
)
[ ] fixed week
{
choose week# ( 1, 2, 3, 4
)
AND choose day # (
M,T,W,T,F,S,S)
}
[ ] End of month
Default Billing Term for ANNUAL
billing:
[ { date }] Fixed date of year. ( month and day ONLY ) ( Physical Year
)
[ ] nth days since last billing ( Anniversary
billing
)
[ ] specified
{
Choose Month # ( 1-12
)
AND Choose Week# ( 1-4
)
AND Choose Day# ( M-S )
Default Billing Term for
Quarterly
Billing
[ ] nth days since last
billing
[ ] fixed length
{
{ }Beginning date
Q1-Q4
{ }Closing date Q1-Q4 ; Would have 4 begin and 4 Close
dates
}
Default Billing Term for Semi-Annual
Billing
[ ] nth days since last
billing
[ ] fixed length
{
{ }Beginning date S1 &
S2
{ }Closing date S1 & S2 ; Would have 2 begin and 2 Close
dates
}
[ ] Specified Term
{
Period B1 {
Choose Month # ( 1-12
)
AND Choose Week# ( 1-4
)
AND Choose Day# ( M-S
)
}
Period B2
{
Choose
Month # ( 1-12 )
AND Choose Week# ( 1-4 )
AND Choose
Day# ( M-S
)
}
}
Allow Prorated
periods?
[ y,n ]
Allow Individual
Overrides?
[ y,n ] ; This would be overrided in each customers profile
Services
are
Taxable?
[ y,n ] ; Not every state/country charges sales tax on
Services.
Send Late
Notices?
[ y,n
]
if Yes then {
File Name for notice
1
File
Name for notice 2
File Name for Notice
3
}
Charge Interest on Late
Notice?
[ y,n
]
if Yes then {
[ #days ] Grace Period before charge is
incurred
{
Use
Avg. DAily Balance? [ y, n ]
~~~~~~~~~~~~~~ Gotta run just got phone call,
will finish up as soon as I get back.~~~~~~~~~~~~~~~~
Ok, its been too many days for me to remember my train of
thought, but ya'll get the idea.
Troy
n6rej@tcsn.net"I do not understand what I do,
for what I want to do I do not do but what I hate I do"
Rom 7:15
NIV