I've writen a module to calculate canadian sales taxes.  I'm wondering
what to call it.  Tax::Canada is the working title, but
Finance::SalesTax::Canada might be better.  I don't want to export all
functions so a shorter name would be perferable.

Features:
- Sales tax for the 10 provinces
- Most provinces don't tax books, though GST still applies
- Quebec taxes GST (piggy-back)
- HST in the maritimes
- Function that figures out if a client is in a province where the
merchant operates (ie ON client's don't pay sales tax if merchant
operates in QC, AB and NS).

Example:
use Tax::Canada;
$prov=Tax::Canada::which_province('ON', qw(QC AB NS));
($gst, $pst, $hst)=Tax::Canada::sales_tax($prov, $non_book_total,
$book_total);

I'm gathering comments before I upload this module to CPAN.

-Philip

   use Very::Long::Module::Name qw/func1 func2 func3/;

...so the length of the name matters relatively little. (If they are
likely to want several functions in a group, you could use a logical name,
like :common or something, to make importing easy.)

Hope this helps!

--
Tom Phoenix       Perl Training and Hacking       Esperanto
Randal Schwartz Case:     http://www.rahul.net/jeffrey/ovs/

I vote for Tax::CA::Sales. Or more simply Tax::GST (then instead of
Tax::UK::Sales we'd have Tax::VAT).

: I vote for Tax::CA::Sales. Or more simply Tax::GST (then instead of
: Tax::UK::Sales we'd have Tax::VAT).

        I don't.  Sorry, but Tax::CA::Sales looks *far* too much like it's
        a module for California sales tax (which, btw has far more then 10
        different rates on it's own...).  But then, maybe that's only
        because I live in California that it seems that way. :-)

        Tax::GST, Tax::VAT, etc make no sense, to me at least.

        I like something like Tom's name:
        Finance::Taxes::Sales::Canada

        It's long yes, but it should only be typed once if you're using
        functions. -I highly disagree with not importing functions.  If a
        user doesn't want anything imported they can "use My::Module ();".
        That's the "correct" way (if there is such a thing in Perl).

        This name convention allows for other modules such as say,
        Finance::Shipping::FedEx.

--
-Zenin

I would however add the ability to import the names with an otional
arg to the use statement.

use Finance::Taxes::Sales::Canada qw(-import -year 1997);

Note how I added the year component.  This is probably a very
nice feature as taxes get played with every year.  Of course the
default would be the current year.

Take a look at the import method just in case you want to role your own
importer.

Mark Daku

Is   Finance::Taxes::<type>::<country>  preferable to

     Finance::Taxes::<country>::<type>

     Or even

     Finance::Taxes::<country>::<province/state>::<type>  ??

I'd lean more toward the last item myself.  (Although I can easily see
this "de(?)-generating into

        Finance::Taxes::USA::FL::Dade::Miami::Sales

and similar monstrosities.  [That's State/County/City for those unfamiliar
with US geography.])

What's the more important hierarchical item here?  Geographical/political
region, or type of tax?

--
John G Dobnick                          "Knowing how things work is the basis
Information & Media Technologies         for appreciation, and is thus a
University of Wisconsin - Milwaukee      source of civilized delight."

: [Since this isn't really named...  yet...]
: Is   Finance::Taxes::<type>::<country>  preferable to
:      Finance::Taxes::<country>::<type>

        I'd say type first, then location.

: I'd lean more toward the last item myself.  (Although I can easily see
: this "de(?)-generating into
:       Finance::Taxes::USA::FL::Dade::Miami::Sales

        Yep, and other reasons.

: What's the more important hierarchical item here?  Geographical/political
: region, or type of tax?

        With the type first, it makes grouping all the sales tax modules
        together much easier, as well as possible income tax and similar
        modules.  My point being that someone is much more likely to want
        a complete set of just sales tax modules for all areas, then a set
        of sales, income, and gas tax modules for only Canada.

--
-Zenin

I like the Tax::Government::Type idea though, I just don't see the need
for extra
level.

(An appropriate discussion on April 15th in the US!)

Mark Kaehny

Gotta have a country code in there somewhere.  Can use 3-letter ISO
codes (e.g. AUS, CDN) rather than the 2-letter codes to avoid the US
state confusion...  or use US::CA for Fornicalia.
--
Gregory Bond                            ITG Australia Ltd, Melbourne, Australia

Finance::Tax::
Finance::Currency::Convert
Finance::Stock::
Finance::Interest::

etc.

In your scheme you'd get four top level hierarchies added to the long
list of others.

Of course, there is always the question of how abstract the top level
should be, but in my world view, Finance is probably as abstract as it
needs to be. Tax, on the other hand, isn't.

Martien
--
Martien Verbruggen                  |
Webmaster www.tradingpost.com.au    | Make it idiot proof and someone will
Commercial Dynamics Pty. Ltd.       | make a better idiot.
NSW, Australia                      |

Beware - CA is also the two letter U.S. Postal Service abbreviation
for California and so it might be a source of confusion, at least
in the U.S. Perhaps CAN instead?

I agree it could be confusing at first glance, but that's what the docs
are for -- right? :)

        Tax::CA::Sales (Canada)
        Tax::US::Sales (US)
        Tax::US::CA::Sales (US, California)

Where the second component is the standard country code.

This would keep in line with the domain naming conventions for
geographical domains.

-- Nathan