One thing that may be critical in the design of the data model, at least to someone who hasn't encountered it before, is the application/calculation of (sales) taxes. For example, in Tennessee and at least a few other states, as best I recall, the state applies a sales tax on the entire total extended price. Then, each county is entitled to its own local levy, but only on a percentage/fixed_amount of the price of each item.
I just chatted with one of my economist colleagues who consults with local/state government, in this and other areas, and he shared enough with me that I can add the following, so that you'll be totally confused : An item is $10,000.00 in price. The state taxes it at 7.0%. The local taxing entity with jurisdiction, County or Municipality, may assess up to an additional 2.75% of the item price, up to $1600, a lower rate up to $3200, and no further tax above $3200. Now, the state tax applies to whole extended price and, as a matter of fact, the sum of the extended prices, whereas the local applies to each item. IOW, in the example above, if one were to buy 3 items at $10,000, then the local taxing entity would make its assessment on EACH of the items, not just on the extended price. I have seen POS systems work fine in this environment as long as the item-prices were below the local-cap. Then, as soon as an item sold went over the cap, the vendor collected to much tax. Tennessee citizens know about this when they buy big-ticket items and, as customers, they ain't so satisfied when they think they're being ripped off ... Anyway, speaking logically, it's not a single tax rate, but multiple rates with a twist. It's either 2 or 4, in this case. 2 ) 1 - a blanket for the state ) 2 - for the local entity with a calculation 4 ) 1 - a blanket for the state ) 2 - for the local entity on the first $1600 ) 3 - for the local entity on the from $1601 to $3200 ) 4 - 0 for the local entity above $3200 *Of course, as I've said, the local assessment is applied to each unique item-price, not the extended-price or sum thereof. However, down the road, just most of the states in The Union are working on what's called "The Streamlined Sales Tax Project" in order to collect sales taxes they are currently losing (mail-order, 800#, WWW, etc). This should simplify the data model. Although it's not adopted 100%, there should be ample info on the WWW about this. (Let me add, please don't take any of this TAX, TAX, TAX stuff as any kind of attack||defense of government. It's just what's going on in this area. I would add, should anyone get riled up about this TAX, TAX, TAX stuff, that, IMO, there ain't no free lunch, whether it's actually lunch, launching shuttles, missiles, aircraft, or corporate tax breaks, etc - sooner or later, somebody's got to pay ...) FWIW, Steve in Memphis ----- Original Message ----- From: "Sami Aaron" <[EMAIL PROTECTED]> To: "RBASE-L Mailing List" <[EMAIL PROTECTED]> Sent: Thursday, October 07, 2004 8:59 AM Subject: [RBASE-L] - POS System > I have a contact who is interested in setting up a Point-of-Sale system > using R:BASE and would like to contact others who have already done so. If > you have some information about this, please let me know. > > thanks, > > ------------------------------------------ > > Sami Aaron > > Software Management Specialists > > 19312 W 63rd Terr > > Shawnee KS 66218 > > 913-915-1971 > > mailto:[EMAIL PROTECTED] > > www.softwaremgmt.com >
