Re: Dynamic formulae calculation in RPG

[Jerry Adams <jerry@xxxxxxxxxxxxxxx>]

Our company has a similar situation: Local taxes in some states on some 
product classifications.  And the localities each have their own method 
for the same product.

Sharing the code would be too cumbersome and, probably, not help you a 
lot.  What I can share is an outline of the method.

First, a customer may be taxed by more than one locality (city, county, 
school board, your favorite here).  There is an adjunct to the Customer 
Master which defines the localities under which the customer falls.

The hard part is classifying the product mix that works across the board. 

Next we defined the methods used to tax each product class.  For 
example, some tax the wholesale price (our price), some tax the retail 
price (like we have any control on this!), some tax by weight, etc.

Then a Locality Tax Rules table was defined.  Basic layout: State, Local 
code, product class, tax method, tax factor.
For example: AL + 79005 + Cigars + Per cigar + $.05, which says some 
city in Alabama charges 5 cents per cigar.

The invoicing program, as well as customer inquiries, use a service 
program to retrieve the tax rate and add it to the price.  As Glenn 
said, it should be simple.  However, by isolating the tax methods to a 
service program and each method to a subprocedure, that is exactly what 
is done.  Once the service program has been tested and validated, the 
programmer working on the invoice program has no reason to look at the 
service program.

We have had to add new methods (geez, you can't catch everything), but 
those went into the service program as a new subprocedure.  Only that 
subprocedure is subjected to testing.  The most complicated subprocedure 
is no more than 10 lines of calcs.

This process also uses one of my favorite programming methods: 
Table-Driven logical.  Adding a new customer in an existing tax 
jurisdiction requires only linking the customer to the local code; 
adding a new locality requires only adding it to the Locality tax Rules 
table.

I wrestled with this problem for about a month because I, too, wanted it 
to be simple.  While this is not the only way to do it, it was only when 
I quit looking at the details and looked at the big picture that I came 
to the realization that each local tax rule was a method (subprocedure). 


        * Jerry C. Adams
*IBM System i5/iSeries Programmer/Analyst
B&W Wholesale Distributors, Inc.* *
voice
        615.995.7024
fax
        615.995.1201
email
        jerry@xxxxxxxxxxxxxxx <mailto:jerry@xxxxxxxxxxxxxxx>



Glenn Gundermann wrote:
> Ewart,
>
> You should keep it simple and easy to read, hence easy to modify and easy
> to debug by coding it exactly how you have it written down in your
> requirements:
> /free
>  Base = Qty * Price;
>  Tax1 = Base * .02;
>  Tax2 = Tax1 * .03;
>  Total = Base + Tax1 + Tax2;
> /end-free
>
> You could of course make it impossible for the next programmer to
> understand what you are doing:
> /free
>  Total = Qty * Price * 1.0206;
> /end-free
>
> Glenn Gundermann
> ggundermann@xxxxxx
> (647) 272-3295
>
>
>   
> > Hello All,
> >
> > We have a complicated Invoice calculation process where a lot local taxes
> > are to be considered. In order to make these calculations dynamic I plan
> > to do the calculations using dynamic formulas so that any future changes
> > can be considered.
> >
> > Eg:
> >
> > Description             Name            Formula         Value
> > Base value              Base            Qty * price             1000
> > Tax1 20% of base        Tax1            Base * .02              20
> > Tax2 30% of Tax1        Tax2            Tax1 * .03              0.6
> > Total                   Total           Base + Tax1 + Tax2      1020.6
> >
> >
> > Has anyone built something like that & can share the code - I can save
> > some time.
> >
> > Thanks & best regards
> > Ewart
> >