Graphical interface for POS

[RollerBall]

Price, no. It's something you control and it shouldn't be an item that is automatically updated by any system*. But to decide price you need to know COST. Cost is not something you can control but when you are making your price decisions it is obviously best to work on the latest, most accurate cost figures.

That is why you have systems - to do the work for you and so you know the calculations are always accurate. And that's why all proper stock control systems update costs automatically when you input new stock - usually on a simple average cost basis.

It's a pity that DHPOS will never do this. It would have been a significant and valuable enhancement. But no matter.....


* The one exception is when you always work on a fixed mark-up but then you get into a whole new bag of worms on the many different ways you can decide prices, so it's best to leave that one alone.

[roxy99]

I agree with Rollerball but I think its a difficult implementation. DHPOS would need to track purchases individually and essentially require a purchase order for each purchase and acceptance of merchandise along with approval of invoice costs. Each item in the stock table would therefor have children being individual purchase orders which constitute purchase history. As new purchases are added, the stock would need to calculate a few important values: average unit cost and last cost being the most important. So there needs to be a purchases sub-table that is related to the stock table.

I'm using relational database model that is running in parallel to the DHPOS system in the background. I'm much less limited that way. The old DOS 16 bit file format may impose certain practical limitation for the DHPOS system. I agree with Rollerball that this is very useful. I also understand Dale's position as well being that this is freeware, and its a big task.

[bob5731]

Hi
Win will you have it done?