DHES

Hi, i have problem about transaction number.
I have 2 computer running DHPOS, when i open Purchase menu on PC 1 it say transaction number 10, but when i open VOID program on PC 2 it say transaction number 2. It`s happen again when i rang a sale from PC 2, it`s start from transaction number 3 not 11.

Network mistake ????

Next Question
History Reports By Category show No transaction/blank when month set to 2-11 ,only 1 and 12 show the correct history.

Thank`s

NuQ,

The transaction numbers are kept by each register and are not shared. This is why in the "Network" feature of the POSCONFG.EXE program you are supposed to give each register a letter to designate that register. The letter will follow the transaction number on the printed receipt. So one register will have these transaction numbers...

0023A
0024A
0025A

and the other register will have these transaction numbers...

0089B
0090B
0091B

I will look into the history thing but that is going to take a while.

Dale

Thank`s for your reply.

One more questions :
How to reset transaction number and history file ?

And my problem about History Report, I think like "videotek" problem on previous topics "History By Category - Reporting problem"

You can't reset the transaction number and history file. If you could that would make fraud possible. Once you start to use the system the audit trail is continuous. If it wasn't the system would be useless for serious users.

The only thing you can do if you want to experiment with the system and find out how it works is take backups of the original 'empty' files before you start and revert to them when you are ready to start using the system properly.

Can't tell you about the history file print as so far because of the annoying bugs that seem to be plaguing the latest system I've continued with 6.39k which has proven to be very stable and almost totally bug free.

NuQ,

Rollerball is correct in that there is no way to reset or alter the transaction number other than by ringing up another transaction or creating a new register.

Read this http://keyhut.com/faq.htm#filename

However you can delete the history file by deleting the files that have the extensions .HSS and .HST

Dale

Rollerball,

Actually it is possible that the problems with version 6.40c have been fixed but apparently no one will ever know.

A couple of people have complained that they after ringing from 40-60 sales that they are getting "Out of stack space" errors and the program was dying.

So I immediately pulled an all-nighter to try to fix the problem and I think that I have. Since this problem is not happening here I posted the fix at http://www.dhpos.com/pos640cx.zip two weeks ago so that they can test it and report back if the problem is solved.

I have noticed that when a problem is reported that I am expected to drop everything and fix it. However letting me know if the fix works is apparentely not a priority.

Note: the file http://www.dhpos.com/pos640cx.zip contains only a new POS.EXE file and must be tested with version 6.40c

So here I sit, waiting.

Dale

Thank`s
I`ll inform you asap...

I try 6.40cx and the new one 6.40d, for me it1s still have history reports error (show blank lines) .

Then i try 6.39q like RollerBall said, and it`s works fine Reports show the correct value.

There is a any major different between version 6.39 and 6.40?

What`s fix in the version 6.40d?

Sorry Dale, I understand your frustration. I always stay a bit behind the curve though as I'm not the end user. I'm hoping to have a bit of time over this Christmas break as many UK companies are closing down for what seems like weeks. So I should be able to put the new version through its paces then. I'll let you know how I get on

NuQ,

I tried the history thing here with no problems on version 6.40d. As far as I remember there have been no changes in the history feature for a long time.

Go to the "History" feature of the POSCONFG.EXE program and then press [F4] to see the raw data in the history file. Is there data in the file that is not being printed in the report?

Version 6.40d fixed a problem where if you ring up 50+ transactions in a day the program would encounter an "Out of stack space" error and crash.

Dale