Welcome Guest, Not a member yet? Register   Sign In
Point of Sale (POS) Application
#41

[eluser]kurucu[/eluser]
Wow. Interesting project and plenty of controversy!

My thoughts:
- The hardware will interface with the client, not the server, so it's not a PHP problem but a Java/ActiveX/other problem... which makes it a lot easier as the program can run and interact with the user, then just call a server (PHP) request with the results
- Manual SKU entering sounds horrible - but then we have no idea of the size of shop or type of products. A specialist/organised shop might be OK with auto-suggest dropdowns. I worked in a McD where we entered all SKUs manually through navigating menus or typing the remembered SKU number. In a supermarket this would be dead in the water.
- Security. Availability. Reliability. It had better all be over HTTPS, and have the highest availability rates going. I'm not giving any webPOS my credit card knowing it's being transfered via an insecure AJAX request.

Personally, I'd expect a project like this to be done in (you said rapid development) C#, VB, Mono, whatever. But that's the fun of the world! Surprise us with a web-based (, reliable, secure, easy to use, scaleable) POS system!
#42

[eluser]Myles Wakeham[/eluser]
[quote author="evinrows" date="1250109007"]I'm surprised at how quick a few people in this web development community is to turning down a web based POS system. (We all know web based applications are the future. Smile) I think it's an interesting concept and the application looks very nice and clean. Congratulations on your work so far and good luck.[/quote]

I'm in two minds on this one...

Firstly this sounds like technology looking for a business requirement rather than the other way around. If you think in terms of the promise of web based technology from a business perspective, its about the business being able to remove its need to support its IT by using a hosted solution for this and letting the 'cloud' provide that support. That works great when the data and application is best provided in a hosted format. But when you need to be able to work with local hardware and provide the business an ability to trade if they lose connectivity, this won't work. And from a sales perspective (and I'm talking about the ability to convince a retailer to adopt this), you have a HUGE objection to over come there.

If I was a retailer and I wanted to put a system in place, I'd be concerned about lines of customers with products in hand, and wanting to pay for it and my Internet connection was down. I'm sure it's bad enough if I couldn't take credit card transactions under this situation, but most retails have a dial-up backup for this sort of thing. But if the entire POS is down, its going to be really hard to provide the same level of redundant backup systems for this.

Then there is the issue of speed. Taking a lot of POS transactions requires fast response. If there is any concern over Internet speed, then this will be an additional factor.

Finally (and this is probably the big one), hardware integration is key with POS systems. Cash drawer handling, Bar code readers, credit card swiping systems, and in the case of entertainment systems (ie. bars, clubs, restaraunts, etc.) then there is security logins of which many systems are moving to biometric IDs (ie. fingerprint readers) or card swiping systems for ID, integration with dispensary systems, etc. POS systems are most popular in industries when staff using them are entry-level staff with little or no training, and placed under high-stress sales positions with customers who just want to pay for their purchase and go. In this environment, fast response and handling of disasters is key. That's why a lot of retail businesses keep backup cash registers around in case one goes down.

Now if I owned such a business, I would want complete independence in case of disaster. I have enough to worry about with staff stealing money from the damn cash register, rather than if the technology was going to work at 11PM on a Friday night when my restaraunt was busy and some kid down the street has brought the entire local Internet down while they were surfing for Bittorrents, etc.

I'm not trying to bring down a project but I do feel that there is an order in which one should approach these things that has been common in engineering stuff in the past, and an accepted methodology that seems to be completely ignored here:

1. Feasibility
2. Requirements
3. Design
4. Build
5. Test
6. Implement

This seems to be done with the order of:

1. Build
2. Requirements
3. Design
4. Test
5. Feasibility
6. Implement

OK, maybe it will work. But it would have to be that the developer(s) lived in the retail space so that they could see some advantage of their approach in a very entrenched industry that currently isn't in search of a solution that I can tell. Its a solution looking for a problem, rather than the opposite.

The idea that 'web applications are the future' isn't totally true. Web applications solve a problem in terms of removing reliance on expensive IT labor for installation and management of applications, and high accessibility anywhere, anytime. But let's move forward from there - until there is a communications infrastructure that is 100% reliable, the last bastion of technology implementation for it will be in mission critical environments that rely on 100% uptime. I can't find any ISPs that can guarantee 100% uptime. Maybe 99%, not 100%. So who pays for the 1% downtime here? The retailer. They may as well close the door if they can't trade. The rent still needs to be paid, the inventory still keeps devaluing, etc. While the Internet connection is repaired.

It wouldn't work if I owned the business. Maybe I'm too conservative, but in comparison with my business friends, they see me as the risk taker.

Myles
#43

[eluser]Unknown[/eluser]
I've been reading through this and although it sounds like a great idea, I agree that the security risks are just too high. You would be dealing with a large amount of credit card /paypal transactions.
#44

[eluser]raitucarp[/eluser]
Sad

maybe anyone can tell me what the POS is ?? and what the benefit if use it? any large website use POS ?? sorry, I am newbie
#45

[eluser]raitucarp[/eluser]
[quote author="Lex87" date="1259884717"]I've been reading through this and although it sounds like a great idea, I agree that the security risks are just too high. You would be dealing with a large amount of credit card /paypal transactions.[/quote]

hmm, IMO, thats true one, I think security risks is #1 factor before you make decision to create this application

btw, your avatar is cool buddy Big Grin
#46

[eluser]salbertson[/eluser]
[quote author="Myles Wakeham" date="1253599768"]But when you need to be able to work with local hardware and provide the business an ability to trade if they lose connectivity, this won't work. And from a sales perspective (and I'm talking about the ability to convince a retailer to adopt this), you have a HUGE objection to over come there.[/quote]

There are many redundancies that can be put in place to maintain internet connectivity. Simply having high-speed internet with a backup dial-up service works very well. Also, this can all be setup to automatically switch with a specific router setup.

Beyond redundant internet connections an off-line browser technology can be used, Google Gears for example. Most of the functionality will continue to work since JavaScript is used and communication with the server is minimal. In the case of a down internet connection Gears can step in and save/process data until the connection is back up.



[quote author="Myles Wakeham" date="1253599768"]Then there is the issue of speed. Taking a lot of POS transactions requires fast response. If there is any concern over Internet speed, then this will be an additional factor.[/quote]

Internet connections today are fast and cheap. They will continue to get faster too, so I don't see how lag is an issue.



[quote author="Myles Wakeham" date="1253599768"]Finally (and this is probably the big one), hardware integration is key with POS systems. Cash drawer handling, Bar code readers, credit card swiping systems, and in the case of entertainment systems (ie. bars, clubs, restaraunts, etc.) then there is security logins of which many systems are moving to biometric IDs (ie. fingerprint readers) or card swiping systems for ID, integration with dispensary systems, etc.[/quote]

Read through this thread, there have been discussions about this already. Hardware integration is not as scary as most people think. All the newer input devices, such as bar code scanners and credit card scanners, will dump the input into an input field just as a keyboard does. This input can be processes in the browser as needed.



[quote author="Myles Wakeham" date="1253599768"]I'm not trying to bring down a project but I do feel that there is an order in which one should approach these things that has been common in engineering stuff in the past, and an accepted methodology that seems to be completely ignored here:

1. Feasibility
2. Requirements
3. Design
4. Build
5. Test
6. Implement

This seems to be done with the order of:

1. Build
2. Requirements
3. Design
4. Test
5. Feasibility
6. Implement
[/quote]

Everything done with this project has been driven by a couple key users. All the features have been implemented after suggested by these users and run through a vetting process. Requirements are definitely at the top of our development list. FireSale did not start off as a test project, I started building it to fill a need some of my existing design clients had. Everything in the app came from real world use cases and needs.



Myles, I really appreciate the input.
#47

[eluser]pbreit[/eluser]
I own a pet store (I use Paygo POS) and work at a successful SaaS company and I don't think a web app is suitable for building a POS system. The main benefit of web apps over desktop software is fast updates but a POS system really should not be updated that rapidly. There is going to be a problem with hardware integration even if everything is USB. My POS system connects to a receipt printer, credit card swipe, barcode scanner and label printer. Are you able to do this via a web app? Even with Google Gears (which is apparently being phased out, by the way), web apps do not work that well off-line. But the biggest problem is that you will be competing with desktop apps which will perform much better in a variety of ways. Your system looks very nice but looks like it is missing quite a bit of basic functionality.
#48

[eluser]Tillman Mosley III[/eluser]
There are quite a few web based POS systems out there, so it can and is being done.
#49

[eluser]pbreit[/eluser]
Show me one that has gotten decent traction.
#50

[eluser]Tillman Mosley III[/eluser]
I just grabbed a few

PaygoSaaS
Halo Retail POS
Coresense
Some nitty gritty from Microsoft




Theme © iAndrew 2016 - Forum software by © MyBB