Jump to content

Developing Point of Sale module


Recommended Posts

I've been developing this module for about a little while now, and it looks like it's going to work.

I started with what I thought would be the hard parts.

What I got working:

Adding products to the cart via a barcode scanner and the ean13 database field without search (ajax and non ajax versions).
Empty the entire cart (cancel order) with a button or by scanning a special barcode.
Barcode generation of my special barcodes for printing.
Limit POS module to access from specific IP's.
Hide POS block while maintaining it's functionality for barcode readers.
Install script that can create indexes for ean13 and reference columns without creating duplicate indexes.

What I think I still need to do:
One click checkout, cash/credit selection, and receipt printing.
Buttons for manual SKU/UPC entry, etc.. on touchscreens.
Simplified main page and alternate layout when module active?
Group based access security?
(Your thoughts here!)

I would appreciate some input on what else you think I need to add here to make this viable.
I've read some other threads where people thought this was a dead end. I'm also curious to know why they thought that..

Link to comment
Share on other sites

Use on a Hosted server:
yes. Having reliable internet and a good hosting provided then becomes critical for your POS usage.

Importing products by scanning:
Well, the only field you'll get by scanning is the ean13 field. Compared to product descriptions, etc.. that's pretty minor information. But.. I will look at product add and see if I can hook that page so the scanned barcode goes into the ean13 field automatically.

Link to comment
Share on other sites

Handling Customer Information methods

1) POS operators could log in via their credentials, and place POS orders for customers as themselves.
Advantages:
Existing customer groups could be utilized for POS security.
Easy to implement.
Groups can be hooked to present POS checkout and main page.
Disadvantages:
We loose visibility on the customer information this way.
Customers don't have history if visiting the corresponding website for the POS.

2) POS operators could have admin access to log in as a customer and place the order as them without a password.
Requirements:
Searching for the existing customers should be simple. (ajax typeahead at least)
Account creation would need to be simplified to only require an email address and maybe a phone number, but all fields should be available if the POS operator has time to enter them.
The other customer registration fields should be autopopulated and a temporary site password sent to the customer's provided email address.
Customers would be required to provide at least an email address/phone number, or for those who do not wish to participate, a Guest POS account could be logged into via admin access.
Customer fields that were autopopulated at POS should prompt the customer to change them on first web login.
Advantages:
Closes the loop for customers and has the potential to drive subsequent web based sales.
Customers are just a few clicks away from making another web based purchase.
They have a digital record of their past purchases.
Customer emails could be used for store marketing and specials.
Disadvantages:
Using group based security for POS operators goes out the window. An alternate login/security facility would have to be provided for POS operators.
POS will be slower requiring text entry for every customer, unless the customers could be identified via a barcode as well (keychain plastic thingys) or the Guest POS account is used.
Lots of work to implement.

Link to comment
Share on other sites

  • 2 weeks later...

Yeah, so I know it's possible, but that's a pay module. I've been trying to duplicate it on my own and taking apart order.php has been pretty helpful.

I've been working under the assumption that this should be a front end interface. That gives me ready access to add customers, and work with carts and such. It doesn't give me access to administrative logins though.

I've looked at the SuperUser module and I may be able to adapt some of that, but it still relies on the normal cookie, and you loose the ability to know that you are NOT the real user.

So... should this be a front office, or a back office module?

Link to comment
Share on other sites

i think the most straight forward solution may be using this as a front office module, where the operator can be logged in as a 'general' customer/user. When scanning with barcode scanner, it can search the product by EAN-13, and auto add to cart? Then i suppose all that need to be done from there is click collect in store, and cash on collection - job is done? Whether the selection of cash/collection can be improved, i'll leave that to you...

I am currently looking to see whether there is a simple way of syncing stock QTY between prestashop and openbravo, as i feel openbravo is a superb POS solution. Fair enough you would need to add products to the catalog in each DB, but if I can get the stock QTY updated easily, then this is a good solution...

Anthony

Link to comment
Share on other sites

Barcode scanning is done. I wrote an ajax hook that looks up the EAN13 on scan (the scanner sends a prefix, so I can hook that), and then triggers the existing ajax add to cart.

Credit card data via a USB keyboard wedge can also be caught, as it has a similar consistent string you can look for.

I don't want to use only a guest account. Customer data is valuable information for those that choose to provide it.

Link to comment
Share on other sites

As it stands, yes. Entering a customer takes like a minute and just is not practical for POS.

I plan on cutting down customer entry to just the email, or phone number. Problem with phone number is it's a field within the address.

If I don't enter an address at all during the POS transaction, the customer returning via the web is simply prompted to add an address. If I enter the phone number, then I got a mostly blank address record but they are not prompted. I'm thinking I might just add a phone number field onto the customer table.

Customer searching will have autocomplete so retreiving a returning customer is down to a couple characters and a click/enter.

Link to comment
Share on other sites

Great news!

Please consider 2 things:

1. POS implementation in front office so when employe logs in he can start it.
2. Adding of products serial numbers to invoice or delivery slip (and backwards aswell, when scanning a SN to find its invoice)

Link to comment
Share on other sites

  • 3 weeks later...
  • 2 weeks later...
  • 3 weeks later...
  • 6 months later...
  • 5 months later...
  • 2 weeks later...

Darenschwenk, are you continuing your POS development ? If so I have two questions :-

POS till software deals with "terra firma" shop sales with the POS printer issuing a customer with their invoice.

1. Does your solution result in the till polling Prestashop with a batch file with data acquired from the barcode scanner over the course of the day or is each sale immediately polled to Prestashop once scanned ? I take it that your solution then registers a terra firma shop sale in Prestashop to amends the online stock held.


With on line sales which will automatically amend the online stock and affect financials then :-

2. are you working on how to poll that data back to the POS software to keep your POS software stock data in sync and ensure a single unified financial data on your POS backoffice. If I am misunderstanding your use of a POS scanner I would be most grateful for more info. Thanks.

Link to comment
Share on other sites

  • 6 months later...
  • 1 month later...

PrestaShop v1.5 will have the ability to manually add orders from the Backoffice, which is cool. However, I had already started working a POS solution before I knew that, and almost have it ready. I think my POS module will have more features than the "Add New Order" functionality, but will have to see. Maybe they will out do me, and mine will become irrelevant!

Link to comment
Share on other sites

I don´t mind how but I would like to have a POS working with Prestashop.

I run a real shop with its own POS and Prestashop on internet.

It´s a mess...!!

I have seen other programs in this forum (here in spanish, you may use google translator)

http://www.prestashop.com/forums/topic/123498-aporte-tpvpos-compatible-con-prestashop-vende-tus-articulos-web-directamente-en-la-tienda-fisica/page__fromsearch__1

Link to comment
Share on other sites

@Aldeag- I think you are saying that the current POS you use is NOT incorporated into Prestashop, so you have two different systems that do not talk to each other? Is that correct?

What POS are you currently using?

 

That´s right.

I have one computer in my shop with a POS system. Is not a commercial one, so you cannot buy it in a shop.

And I have Prestashop, which I use from home, from the shop, from my iPhone, from...

Link to comment
Share on other sites

×
×
  • Create New...