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.

gcdb-devel mailing list
"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