Customer Accounts Ver. 7.04x

[daleadmin]

The only new feature in this is that if you change the description of the item you are selling and then look up the sale using "5. Voids" the new description will still be there. If you then reprint the sale the new description will print.

Keep reading, there is an important surprise at the end.

Here is the change from the manual....

Changing Descriptions
If you are using a stock table the program will look up the description for each item you sell. If you are not using a stock table the description for every item you sell will be "MERCHANDISE".
Normally the POS program will not allow you to change the description for an item while you are ringing up a sale. However if you set "Should you be able to edit an item's description when ringing a sale?" to "YES" you will be able to change the description. This new description will print on receipts and if you look up the sale in the “5. Voids” feature the description you typed in will be listed for that item. However the description in the stock table will not be changed to the description you typed in.

When you run this version the CONVERT.EXE program will start. This is because to save up to 60 descriptions the .REC file has to be reformatted. You must allow the CONVERT.EXE to reformat the .REC file. This means that this is a ONE WAY UPGRADE. Once you upgrade to 7.04 or later the only way to revert to a previous version would be to delete your ??????.REC file and you would lose the record of your previous sales. So follow the upgrade instructions here http://pages.prodigy.net/daleharris/upgrade.htm#current MAKE YOUR BACKUP FOLDER.

This also means that the size of the .REC file will increase, which is why the descriptions were not filed in the first place. A full size 10,000 record .REC file will increase in size from 20MB to 36MB.

This was a lot of work for me and somewhat of a hassle for you to upgrade, for not much of a new feature. So what is the point of this feature? It is a harbinger of something major to come. Since the upcoming customer account invoices may have to be stored for quite a while and in the time they are stored the tax rates may change or items may be discontinued from the stock table. So the description and actual tax rate at the time of purchase has to be stored in each customer account invoice. Since the code in the POS.EXE program will not only update the .REC file but also create the invoice this upgrade is required.

So this is the first concrete step toward customer accounts. Yep, it is really coming.

This download link is a full download of version 7.04x (Download from below)

Here is the deal, you try this out and report back, I will continue working on the customer accounts.

[cwathen]

Seems to work fine, no problems so far.

I don't agree that this is 'not much of a feature' - this is REALLY USEFUL!

The EPOS system we have at work allows you to have 'text lines' on a sale - these can be used to enter delivery dates, serial numbers for high value items, who has authorised discounts etc etc. When playing with DHPOS, I set up a 'product' called 'textline' which you then overwrite to enter extra text.

The problem being that whilst this information prints on the receipt the only way to get it back out of the program is to trawl through the journal file in POSCONFG. Being able to just go back through previous transactions with this information saved is a brilliant addition.

Whilst reprinting receipts has been mentioned - at present only the original receipts will print customer details, reprints will not. Any chance of an option to allow this?

[daleadmin]

cwathen,

Wow, an actual beta test report, and so soon. I am grateful and impressed.

As your reward for an excellent job I have looked into the printing customer info on receipt reprints, it was always supposed to do that. I found a bug and squished it. So here is another beta version to test, version 7.04x1at http://www.dhpos.com/pos704x1.ex Let's hope I get some feedback soon from not only you but others also.

It is a full download even though the only file changed was the POS.EXE file.

Dale

[brucef2112]

Yeaaa!!
I agree with cwathen. Maintaining a manually changed description in the sale is a major improvement! And the same for the customer info showing on a re-print!

Dale, I have a question. I use a similar method as cwathen to add notes to the sales slip. Is there a chance that a 'add note' feature would add just the text in the description area and not print the '1 @ 0.00ea. 0.00' line below it? This would make notes more readable. More so when two 'notes' are needed to 'wrap the note' to a second line.

And I have a second question that may fit it with the harbinger of something major to come; if I knew what it was. For Mail Order, Telephone Orders or Special Orders we have a Purchase Order book to take these orders. Our credit card system has a MO/TO key that allows us to add our PO# to the credit card transaction. I would like to know if a sales record could have a field for a Purchase Order number as part of the sales transaction. I don't want to take up too much of your time right now so I'll wait until after that's done to ask; Can you make this PO# field searchable to find sales by a PO#?


I'm off to DL the new ver and check it out.
Thx Dale,
Bruce

[daleadmin]

Bruce,

The file has been expanded just large enough to store the 60 descriptions so there is no room for notes. I am trying to get the customer accounts feature to work while adding no more than 300 bytes to the code in the POS.EXE program. "Notes" would be way more than that. The additional code in the POS.EXE program would only create and store the invoices. Managing the invoices would be thousands of lines of code but that would go into a new program file.

Invoices would get a 6 digit invoice number based on the transaction number. For example if the transaction number was 5298 the invoice number could be 745298. If a transaction was not turned into an invoice then the invoice number would be skipped therefore invoice numbers would not be sequential. However you could search for an invoice number.

Dale

[daleadmin]

This is going to be blog-like for a while. I am going to be posting a log of what I am doing toward getting the customer accounts feature to function. This way it will help me organize what I am doing and you folks can see what goes into adding a major feature to DHPOS. This is also an opportunity for you to tell me if I am headed in the wrong direction and if you have a better idea of where I should be going.

Things I have done before today...

I came up with the idea of using the part of the program that writes the record of past transactions (the .REC file) to also write the invoices. This would save code space by using the same code to do two different things.

Since it is possible that an invoice could be in the file long after an item has been discontinued from the stock table it would be neccessary to save the descriptions in the invoices and thereby the .REC file. An added feature from that would be that changes made in the descriptions would be there when a past sale was recalled by the void feature. I also thought that between the time the stuff was purchased and the time the bill was paid that the tax rates may have changed. So save the tax rates for each line also.

To work on the .REC file I need a description of the file format. I had an old description but there have been changes. So I look at the code and this is what a new REC file record will look like http://www.dhpos.com/recfile.pdf The lines at the bottom are the FIELDS for the record.

It took a week but I finally got the CONVERT program to sucessfully update the version 4 .REC file into the version 8 .REC file. It took this long mostly from screwing up. I also found some room in the file that can be used to store data for when the sale is saved as an invoice. This is good because the minimum increase in the .REC file is 280 bytes. This is because when the .REC file is accessed for as a text file for opening, closing, or no sale transactions it is opened as 40 byte records. However for all other transaction types it is opend as 28 byte records. The lowest common denominater for 28 and 40 is 280 so that is the minumum amount I can increase the file size.

Cwathen point out that "voids" does not find the information on who bought the stuff for a sale. I fix that.

Today I realized that information would have to go in and out of the existing customer file ( the .CST file) so I need a file format for that. Each record in the file gets a customer system number which is how the program matches a transaction with a customer. In the past I have received a couple of emails telling me that the program would match a transaction with the wrong customer. For invoices this would be a real problem. I look into the file and see that the next system number to be used is kept in the .POS file not the .CST file. This means that if you move one of the files and then later move the other one they will no longer be in sync. This is what is causing the problem. So I have to move the "next number" to the .CST file. I also find the file version number is kept in each record but when the CONVERT program updates the file it only changes the version number in the first record. So version 4 would be changed to version 8. However if you then delete the first record the version number in the new first record would revert to version 4. ( The program only check the version number in the first record.) Not a good thing. The solution will be to move all the existing records 1 back in the file and use the new 1st record as an information record that will hold the version number and the "next available" customer system number. Then to GET or PUT a record you would add 1 to the command. For example GET 3, CSAVE would have to be changed to GET 3, CSAVE + 1

I make these changes to the POS.EXE, and CF2.EXE program files and write conversion routine for the CONVERT program. Tonight I have been debugging these changes.

Tonight I also realize if between the time a purchase is made and the time the invoice is paid if the tax rate changes that the amount due must be with the new tax rates. This is because you did not actually sell it until it is paid for and that is when the taxes are collected. How will I impliment this?

Tomorrow I will work on understanding the .CST file format.

Dale

Comments?

[daleadmin]

Today I tried to free up a little more room in the .REC file. But after working on it for a couple of hours I decided that it was going to be too much work for too little gain and I abandoned the effort.

[daleadmin]

Today's activity was to completely decipher the customer file, .CST

Here it is http://www.dhpos.com/cstfile.pdf

Not much is going to be done for the next two weeks because I have to count about 50,000 keys for inventory.

I guess that I am boring the socks off of everyone here because no one has posted anything.

Dale

[AndreasKohn]

Sorry dale, I think everyone is expect longingly the new version with this great functions. So, no one want to break your block-style diary that I am looking 3-4 times a day for.
I have only two or three customers where I can use the invoice function but for them i hope it makes it much easier to handle the sales. As yet I write the sales up to about 100-200€ in a small book. When they reached the limit I ring them in the POS.
So the new Function will be most welcome.

Greetings from Berlin, Germany

Andreas

[daleadmin]

AndreasKohn,

Thanks for the thought but I do want feedback about what I am doing rather than waiting until I am done and then being told that I did it all wrong. I know at the present stage, being deep into the code, that there is not anything to comment on but eventually there will be. And it will be more interesting for readers to come in on a discussion rather than just hearing what I did today.

Dale

[cwathen]

Tonight I also realize if between the time a purchase is made and the time the invoice is paid if the tax rate changes that the amount due must be with the new tax rates. This is because you did not actually sell it until it is paid for and that is when the taxes are collected. How will I impliment this?

If I understand you correctly (if I haven't then what is written below will be unnecessary) then this is what you want to happen:

Customer buys an item at £100 + 15% tax so owes £115 and the sale is on account. By the time the customer pays the tax rate has increased to 20% so your customer now owes £120?

Although this is fully justifiable on the grounds that it's the tax rate changing which has altered the price, no customer I deal with will accept a price increase on an order already placed - if the tax rate has gone up then I'd be expected to absorb that cost (although of course in that remarkable display of double standards which only customers have if there is a reduction by the time they come to pay they expect that to be passed on!). I also have it at the back of my head that if a deposit has been put down then under UK law this establishes a contract for the store to supply the goods at the price agreed - I'm not sure that a change in tax altering the price is considered an exception.

Also, if you have a store with credit facilities, then the finance company will only pay you the amount that was on the sale at the actual time it was made, if the tax rate increases afterwords they won't cover the extra amount. So in my example above, if I sold the £115 item on finance and the tax rate then increases, the finance company would only give me £115 to settle the account whilst the system would want £120. The only way to balance that customer's account would be to void the original sale and create a new one where everything is tweaked to bring the total to £115 - this in itself can cause a problem if the finance company picks on me for an audit because the price breakdown on the application would be different to that in my records.

All of that said, I can also see exactly why you'd want to implement it the way you are planning. I think it would be better to have the option of 'live' tax (where sales on account are always tracked to the current rate) or 'locked' tax (where the rate at the time of the sale is locked in to prevent the total price changing). This then allows invididual businesses to work in the way that's best for them.

[daleadmin]

cwathen,

Well I will have to think on this.

As advertised there has been no progreess on the customer accounts because of inventory.

Dale

[digicafe]

This POS will be nice if the purchase screen look like this

[cwathen]

Umm, why exactly?

[daleadmin]

It would be nice if the sale screen had a pony on it also. And just about as likely.

Dale