DHES

Those of you that have been receiving these notices probably new that when you received the notice for POS version 6.38 with a new feature that version 6.38b with a bug fix for it would not be far behind. Well good news, here it is. And as an added bonus 6.38b has few new features.

Bug fix. In version 6.38 the auto reports feature would not function if your register had PIN numbers enabled. It has also been decided that you will not have to enter a password or PIN number when closing the register and the program goes off to create your auto report. Also the data for sales reports was being reset to all zeros before auto reports executed.

Bug fix. In version 6.38 only if in the POS.EXE program you used main menu option “5. Voids” to view a previous transaction that contained reductions the program would crash.

New features.

Note: this is not a bug fix because I am correct and all of you folks are just nuts. : )

REDUCTIONS WITH “INCLUDED” TAX
If your register used included tax and you reduced a previous line in a sale by an amount, the program would reduce the price (not including tax) by the amount entered.

For example

<pre>NET 10.00
TAX 1.00
TOTAL 11.00</pre>

Reduced by –1.00 would equal

<pre>NET 9.00
TAX .90
TOTAL 9.90</pre>

Which makes perfect sense to everyone here in the U.S. where we have “added” tax but apparently causes enormous gnashing of teeth elsewhere on Earth. So now if you use “included” tax an amount reduction will work like this…

<pre>NET 10.00
TAX 1.00
TOTAL 11.00</pre>

Reduced by –1.00 would equal

<pre>NET 9.17
TAX .83
TOTAL 10.00</pre>

Which would get you sued in the U.S.

CHANGING CURRENCIES
If your country is changing from one currency to another (for example Lira to Euros) your country may require that the total amount of the sale will always be printed on the receipts in both currencies. To have the program do this you must use one currency as the default currency and the other currency must be listed as currency #2 in the currency list of the POSCONFG.EXE program. Then to always print the total for currency #2 on all receipts press [F1] to make the line near the bottom of the screen read "[F1] ALWAYS print currency #2 total on all receipts." Then an additional line will be printed under the "TOTAL" line on all receipts like this...

<pre> TOTAL 236.23
EURO 189.72
---------------------------</pre>


Here is the link...

<center> http://keyhut.com/pos3.htm </center>

Dale Harris wrote:<pre>NET 10.00
TAX 1.00
TOTAL 11.00</pre>
Reduced by –1.00 would equal
<pre>NET 9.17
TAX .83
TOTAL 10.00</pre>

Hi Dale,

In actual fact if you do that in Australia, you will be sued as well by not declarating an extra 7 cents tax!

Here goes:
<pre>NET 10.00
TAX 1.00
TOTAL 11.00</pre>

Which is 10% tax I see.
If Reduced by $1.00, the total should be then $10.00. Yes?
The tax on the item is to remain at 10%....

<pre>NET 9.09
TAX 0.91
TOTAL 10.00</pre>

Is Correct.

But, in Australia you can't charge more than *EXACTLY* 10% tax, it needs to be rounded down (which should be taken care of by that tax penny rounding feature)....

So the $11 item (with 10% tax) that is to reduced to $10 should be

<pre>NET 9.10
TAX 0.90
TOTAL 10.00</pre>

Just thought I say something before someone gets into trouble....

BH

BH,

Yes, I also agree with your calculation.
This is also the way it should be done in South Africa.

I hope that is why the link to the 6.38b download does not work - because 6.38c is on its way.

The reasoning behind this way of calculating is that whatever you decide to sell a product for, it will be taken to include tax at X%.

A difference is that in SA tax is rounded to the nearest .01 and not to the next .01.


Hope this helps


ToPS

The "amount reduction" samples that I provided, while I did say that they were at 10% sales tax, were actually at a different tax rate, namely 9%. So that feature is correct if anyone had taken the time to actually run the program and then check the math.

As far as rounding up or down so that you do not charge 10.000001% on an item instead of 10% or less, I do not see that as a problem. If a country wants to throw DHPOS users into into the local sales tax lockup for taxing an item an additional tiny fraction of a penny, then there will be just that many fewer people (since they will be in jail and I assume therefore have no access to a computer) who will be sending me emails or posting on the forum insisting that I spend an endless amount of time and code space chasing vanishingly insignificant amounts of money in order to satisfy their local tax gods who obviously are insane.To placate them you can have a "tax error" day once a year where every customer who enters your store is given a dime (0.10) to make up for all the money that you have embezzled out of them in the past year.

That said, in version 6.38c I have reworked the "Coupon / Unit reduction" feature to maybe work properly, I hope. Give it a try and report back here.

Also in version 6.38c, in another pathetic attempt to cut down on my email, I have changed the wording in the "No sale" feature from "Cash pull" to "Put cash in the drawer" and "Cash drop" is now "Remove cash from the drawer" in a vain effort to prevent people from telling me it is backwards, that they have it correct, and I am stupid. Or at least they will have to find something new to complain about.

I am now going to try to take those huge graphics from Rollerball that I had to print out and try to scrape off the ink to put back into the cartridge.

Download from the usual place...

<center> http://keyhut.com/pos3.htm </center>

oooooooh its the admin!

Yep, my secret identity.

daleadmin wrote: As far as rounding up or down so that you do not charge 10.000001% on an item instead of 10% or less, I do not see that as a problem.

Then, I guess there a slight programming issue then.

For the above example, a $10.00 item will have tax of 90.9090... cents. Yes? Round that to 90.91 to make it easier.

But, I have set the tax penny rounding to .99 of a penny. Why is it still rounding at .91 of a penny?

BH

The tax rounding factor does not really apply to "included" tax because included tax is just weird.

The problem with taxes is that when you consider the entire earth, there are an endless number of different rules (laws) to calculate tax, some of them defy all rules of logic or comprehension.

Most people do not consider this to be a problem because all I have to do is to rip out the code for everyone else's taxes and just concentrate on making sure that DHPOS calculates their taxes perfectly no matter how bizarre they are.

Unfortunatly writing a personal version of DHPOS for every living person on this planet may be beyond my capabilities. At least it would take far more time than I have for the remainder of my life.

So what I try to do is to make the tax routines of DHPOS be as flexible as possible considering the limits of my time and the remaining code space in the program, which is not much.

This also means that all the code for all the possibilities of different tax rules must work together. Changing the code to accomodate the Northern Protectorate of Aden may totally screw up the the tax calculation for Humnabi Valley district of Outer Krakistan. For this reason, for me to change the code for the taxes there must be a truly compelling reason that will affect a huge number of users and involve a significant amount of money, at least a few cents (like the stuff I just did.)

Just tracking down occasional small fractions of a penny may be vitally important to you (and your local tax gods) but quite a while ago I gave up on this program being totally perfect in calculating all possible tax codes of any government in any part of any country on any continent on Earth. I am afraid that I am settling on only being very, very good, but not perfect.

Y'all can't please everybody.

No worries Dale.

Barry

Does BH = Barry Hart?

If so, how are you? Where have you been?

Yes. That is me.

Barry Hart