× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



A few years ago I had to write a routine to calculate tobacco taxes. The
rules differed by state and type of tobacco product. In addition a few
states, such as Alabama, have local options and each locality can define
their own rules/methods. It seemed really complicated at first.

I wound up creating a state rules table and a locality rules table.
Generally, the state rules table was pretty straight forward. When
exception changes reared their ugly head, changes to the table and to the
service program were relatively easy because the table defined which
procedure to use in the service program.

The locality seemed a little hairier at first. But the service program for
local taxes had separate procedures for tobacco_type + method (how taxed).
One service program, many procedures. Only basic information was passed to
it from the caller, such as state, locality, and item#. The service program
then figured out which procedure to use and passed back the tax amount.

As time went on, we went into new territories that had (wouldn't you know
it) different rules for some products. Just added a code to the locality
table and a new procedure to the service program. Testing was a snap
because of the segregation of methods into separate procedures, which were
table-driven.

Jerry C. Adams
IBM i Programmer/Analyst
Real programmers don't comment their code. If it was hard to write, it
should be hard to understand.
--
A&K Wholesale
Murfreesboro, TN
615-867-5070

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Jonathan Mason
Sent: Tuesday, August 07, 2012 2:08 AM
To: 'rpg400-l@xxxxxxxxxxxx'
Subject: RE: Callp question (Alan Shore)

It would still make sense to have it file driven. Having a procedure access
those rules from a file and perform its calculations appropriately would
seem to be the way to go. One procedure, one file, one less headache when
it comes to maintenance.

Jonathan

-----Original Message-----

message: 4
date: Mon, 6 Aug 2012 15:02:47 +0000
from: Alan Shore <ashore@xxxxxxxx>
subject: RE: Callp question

If I am understanding what you are saying, it's a little more complicated
than that.
Certain states charge tax on shipping, certain states charge tax on shipping
ONLY if you have at least ONE taxable item in the order, then the rate you
charge can depend upon the item that is being purchased - it's NOT always
one flat tax rate

Alan Shore
Programmer/Analyst, Direct Response
E:AShore@xxxxxxxx
P:(631) 200-5019
C:(631) 880-8640
"If you're going through Hell, keep going" - Winston Churchill


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Erhardt, Bill
Sent: Monday, August 06, 2012 10:53 AM
To: RPG programming on the IBM i / System i
Subject: RE: Callp question

If you're going to write a procedure to calculate State Taxes, why not make
it file driven. The file could be indexed by location (IE State, or State &
City, or at worst by Zip Code) with and local, Township, County, and State
tax calculations defined.


Proud partner of The Ageas Bowl and the Ageas Salisbury International Arts
Festival.

Registered Address: Ageas House Tollgate Eastleigh Hampshire SO53 3YA
Registered Number: 354568 England
Authorised and regulated by the Financial Services Authority

This e-mail together with any attachments are intended for the addressee
only and may be private and confidential. If you are not the intended
recipient, or the person responsible for delivering it to the intended
recipient, you must not open any attachments, or copy, disclose, distribute,
retain or use this e-mail, including any attachments, in any way whatsoever;
please return it to us immediately using the reply facility on e-mail.

Consider the environment and think before you print this email.

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or
change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.