How to connect a price reader device to obtain values from a VFP database?
Hi Experts
Could you give a way on how to use a "price reader device" - used in supermarkets f.e.
To make it work in conjunction with a VFP app - obtaining the item price?
Thanks in advance!
Could you give a way on how to use a "price reader device" - used in supermarkets f.e.
To make it work in conjunction with a VFP app - obtaining the item price?
Thanks in advance!
ASKER
Hi
I was asked on how to deal with this situation by users of a book store - they are using a system I developed.
The book's prices must to be checked by the teller before the sale or just during the sale (still using bar code).
They wouldn't buy these devices before my instructions on possibilities.
Maybe it's a matter of atualize the device DB periodically by USB and then check how to make it operate it like you suggested.
I was asked on how to deal with this situation by users of a book store - they are using a system I developed.
The book's prices must to be checked by the teller before the sale or just during the sale (still using bar code).
They wouldn't buy these devices before my instructions on possibilities.
Maybe it's a matter of atualize the device DB periodically by USB and then check how to make it operate it like you suggested.
Many years ago when I put together a system similar to this for a arts dealer it consisted of multiple basic parts.
1. The 'back office' system which maintained the inventory and associated prices - running 'back office' functionality within an application
2. The retail workstations at which the sales were made - running a more simplistic POS (Point of Sale) application
The 'back office' people with the appropriate authorizations were responsible for keeping the inventory data tables up to date on quantities and prices and they also used the system for reporting, ordering, etc.
The complexity of the 'back office' system can be as complex or simple as you or your customer wants.
It should include Inventory Control and Sales records/reporting, but it could also, if desired, include Accounting, HR, Payroll
The retail workstations had either hand-held or stationary bar code readers which would read the item's unique barcode.
The POS (Point of Sale) application would then build a query using that barcode information to get the price from the 'back office' data tables over the in-store network (workgroup or domain).
It would then display the price on the display device for the customer to see.
Finally, when the sale was complete, it would again send a query to the 'back office' data tables to update the inventory numbers.
The retail workstation POS part of that system directly interfaced with a barcode reader/scanner, a cash drawer and a 'tower' LED/LCD display device to show prices to the customer.
At that time, my customer had some very unique requirements that required them to create a custom system, but there are a number of off-the-shelf POS systems out there which you might want to look at.
Do a Google search for: vfp pos system
Good Luck
1. The 'back office' system which maintained the inventory and associated prices - running 'back office' functionality within an application
2. The retail workstations at which the sales were made - running a more simplistic POS (Point of Sale) application
The 'back office' people with the appropriate authorizations were responsible for keeping the inventory data tables up to date on quantities and prices and they also used the system for reporting, ordering, etc.
The complexity of the 'back office' system can be as complex or simple as you or your customer wants.
It should include Inventory Control and Sales records/reporting, but it could also, if desired, include Accounting, HR, Payroll
The retail workstations had either hand-held or stationary bar code readers which would read the item's unique barcode.
The POS (Point of Sale) application would then build a query using that barcode information to get the price from the 'back office' data tables over the in-store network (workgroup or domain).
It would then display the price on the display device for the customer to see.
Finally, when the sale was complete, it would again send a query to the 'back office' data tables to update the inventory numbers.
The retail workstation POS part of that system directly interfaced with a barcode reader/scanner, a cash drawer and a 'tower' LED/LCD display device to show prices to the customer.
At that time, my customer had some very unique requirements that required them to create a custom system, but there are a number of off-the-shelf POS systems out there which you might want to look at.
Do a Google search for: vfp pos system
Good Luck
ASKER
Hi jrbbldr
Thank you for share your experieneces.
My experience has a lot o similarities with yours on this subject.
I guess the use the price reader device is a matter of to take a formated file with codebars/ prices, maybe the file format is defined by the device manufacturer. Once the device read this file (by USB f.e.) the device reader use could start. The vfp app just need to generate this file accordingly with rules. I'm still checking.
Thank you for share your experieneces.
My experience has a lot o similarities with yours on this subject.
I guess the use the price reader device is a matter of to take a formated file with codebars/ prices, maybe the file format is defined by the device manufacturer. Once the device read this file (by USB f.e.) the device reader use could start. The vfp app just need to generate this file accordingly with rules. I'm still checking.
The "price reader" is the barcode reader/scanner.
The user scans the book's barcode and the reader/scanner sends the information to the POS workstation's application.
The POS workstation's application then builds a SQL Query and requests information from the 'backoffice' data tables - that information includes the price.
The POS workstation's application then gets the price and displays it for the customer.
When the customer agrees to purchase the book, the sale is completed.
* The cash drawer is opened and/or the credit card is read and processed.
When the sale is completed the POS workstation's application then sends another SQL Query to the 'backoffice' data tables - reducing the inventory by the number of items sold.
There were no USB updates needed since the 'backoffice' staff maintained the data tables in respect to the purchase price, the sales price, the inventory quantity, etc.
They based the pricing updates on what it cost them to purchase the items - many times this is purchase price + some percentage, but sometimes you have to use a vendor/manufacturer's listed price.
And there was no need to have to update the individual POS Workstation application tables since they did not hold the book information - only the individual POS workstation sales information for end-of-day register checking to ensure that the cash drawer amount matched the sales.
If you are still unclear, you might want to do a Google search for: how point of sales systems work
The user scans the book's barcode and the reader/scanner sends the information to the POS workstation's application.
The POS workstation's application then builds a SQL Query and requests information from the 'backoffice' data tables - that information includes the price.
The POS workstation's application then gets the price and displays it for the customer.
When the customer agrees to purchase the book, the sale is completed.
* The cash drawer is opened and/or the credit card is read and processed.
When the sale is completed the POS workstation's application then sends another SQL Query to the 'backoffice' data tables - reducing the inventory by the number of items sold.
There were no USB updates needed since the 'backoffice' staff maintained the data tables in respect to the purchase price, the sales price, the inventory quantity, etc.
They based the pricing updates on what it cost them to purchase the items - many times this is purchase price + some percentage, but sometimes you have to use a vendor/manufacturer's listed price.
And there was no need to have to update the individual POS Workstation application tables since they did not hold the book information - only the individual POS workstation sales information for end-of-day register checking to ensure that the cash drawer amount matched the sales.
If you are still unclear, you might want to do a Google search for: how point of sales systems work
ASKER
Accordingly to what you post the "price reader device" - that could stay far from the server sends by wi-fi (f.e.) the codebar, the server process it and then sends the price to the device to show the price? isn't it?
ASKER
Going this way, 02 points are not clear:
A vfp service (since it must deal with vfp SQL, etc) must permanently hear the barcodes that are beeing sent from the "price reader devices"
Then another server's service has to send the price to the "price device".
A vfp service (since it must deal with vfp SQL, etc) must permanently hear the barcodes that are beeing sent from the "price reader devices"
Then another server's service has to send the price to the "price device".
This is just one option. The communication is possible via GSM, WiFi, cable, ..., or the device can work in off-line mode. How behaves the reader from your picture should tell the documentation. Do you have any link to it? Do you know exact model number?
The device (connected as an USB disk or allowing to share some internal folder) can simply place one file containing the bar code into certain folder and wait for the response until some timeout fires... The response can represent another file. If no response comes then the device resets to waiting mode. Your app must read the file from the device in some loop, process it and create another file containing the price...
And many different ways how you can communicate exist. So again, read the device manual.
The device (connected as an USB disk or allowing to share some internal folder) can simply place one file containing the bar code into certain folder and wait for the response until some timeout fires... The response can represent another file. If no response comes then the device resets to waiting mode. Your app must read the file from the device in some loop, process it and create another file containing the price...
And many different ways how you can communicate exist. So again, read the device manual.
ASKER
Sorry, I'm going to read the manual and return back later.
By the way here it is (in Portuguese - no English version found) just in the case you would like to have a look.
By the way here it is (in Portuguese - no English version found) just in the case you would like to have a look.
http://www.resteq.com.br/download/manual/Manual_do_Usuario-Busca_Preco_Wi-Fi.pdf
the "price reader device" - that could stay far from the server sends by wi-fi (f.e.) the codebar, the server process it and then sends the price to the device to show the price?
Yes the BuscaPreço Gertec V3.0 COULD send the data to a server and the server, running an application, could send back the price, so that the customer can read it.
But, by itself, that only handles part of the needs.
When the customer says "YES I WANT TO BUY IT", how would the Sales Person finalize the Sale at the POS workstation where the customer is standing and reading the price?
How would the sales dollars (or whatever currency) be tracked?
And how would the inventory be updated to indicate the number of units sold?
I don't see any of that capability in the BuscaPreço Gertec V3.0
It appears to be only a simple bar code reader/scanner plus display with the ability to communicate WiFi or otherwise.
Above I mentioned that on the Art store system we had a separate bar code reader/scanner at each POS workstation and a separate LCD/LED display on a tower for the customer to see.
It looks like your BuscaPreço Gertec V3.0 combines both the bar code reader/scanner and display device into one unit. That might make things a little easier. I apologize for not looking closer at that before. But again, that only does part of what you need no matter how it communicates.
For that additional needed functionality we also had a PC at each POS workstation to receive the bar code data and run the POS workstation application part of the overall POS system which communicated to the server.
And a different PC working as a server in the 'backoffice' for data table maintenance, inventory control and running reports.
You can see some of the various hardware configuration diagrams at:
https://www.google.com/search?q=pos+system+diagram&tbm=isch&tbo=u&source=univ&sa=X&ved=0ahUKEwiKmdngpszRAhVrllQKHREDARsQsAQIPw&biw=1083&bih=658&dpr=1.25#imgrc=_
Good Luck
ASKER
jrbbldr
Thank you for your concerns!
The POS is still running. It had been running since 2000, evolved in different versions.
I guess all the points you mentioned had been implemented during this time. Several places are using this vfp application....
I know, obviously, "Busca Preço" couldn't do all the job...
Just by now one of the users asked for the "price device reader" implementation,
Thank you for your concerns!
The POS is still running. It had been running since 2000, evolved in different versions.
I guess all the points you mentioned had been implemented during this time. Several places are using this vfp application....
I know, obviously, "Busca Preço" couldn't do all the job...
Just by now one of the users asked for the "price device reader" implementation,
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
At beggining I used the picture only to reference on what is needed... but to follow the manual was the obvious way I hadn't think... Yes, the manufacturer gives an open DLL to make it run in a LAN.
Depending on the costs I could still suggest a PC with a conventional and cheaper bar code reader dedicted only for price reading.
Thank you for the fine help and suggestions!
Depending on the costs I could still suggest a PC with a conventional and cheaper bar code reader dedicted only for price reading.
Thank you for the fine help and suggestions!
The price reader does not tell the price bet it just sends the scanned bar code into the connected computer and the software in the computer must access the price database and return the item name and price.
Scanners can be connected as an additional keyboard, so VFP application can simply place the cursor into an input field and read the scanned bar code. The output depends on the device itself and you have to read the technical documentation delivered together with the device.
Of course, price scanners can also work off-line. In such case the application must be downloaded into them and the database must be updated regularly which means additional maintenance.
Hundreds of such devices exist and each of them can have different specification. So what says the documentation for your device?