• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Point of Sale (POS) Application

#21
[eluser]salbertson[/eluser]
Here are some early invite keys to create FireSale accounts. Only use one please and let me know what you think so far.

q!dLYSuj
7Gk5Bvp$
wGe36fZU
%vckM#WY

http://www.firesalepos.com/signup

#22
[eluser]obiron2[/eluser]
There is a commercially available system in the UK using a totally web based solution called [link]http://www.cybertill.co.uk[/link]

You have all sorts of REST issues if the connection goes down and formatting and outputting to printers (local to the PC and networked)

If you are running in a multi-site, multi-till environment, how do you know which PC is which till (may have dynamic DNS)

Every entry via the interface needs to update a session and database of its current state, much more complicated than just a shopping basket application.

You would also need full back end stock control and cash reconciliation plus barcode reading and Chip and Pin integration.

I bet it is a fantastic project. If you want help in defining application specs - I am an expert in that field, esp back end system management (purchasing, stock control, warehousing,cashing up, reports etc)
obiron

#23
[eluser]salbertson[/eluser]
There are a lot of potential issues involving dropped internet connections. One solution would be redundant internet connections. For example a cable line combined with a DSL line. Another more elegant solution would be to use something like google gears to retain client side data and maintain usability until the connection is restored.


[quote author="obiron2" date="1226358667"]I bet it is a fantastic project. If you want help in defining application specs - I am an expert in that field, esp back end system management (purchasing, stock control, warehousing,cashing up, reports etc)
obiron[/quote]

thanks for the offer obiron, I sent you a pm.

#24
[eluser]obiron2[/eluser]
Please can we have some more invite keys,

The ones you have posted are saying they are invalid

Obiron

#25
[eluser]salbertson[/eluser]
[quote author="obiron2" date="1227131984"]Please can we have some more invite keys,

The ones you have posted are saying they are invalid

Obiron[/quote]

MhZSHSOW
s2Qu8Nsw
eEsQT5DH
3u01sIAj
IXA1cUs2

http://www.firesalepos.com/signup

#26
[eluser]obiron2[/eluser]
Sorry to bump this thread, but salbertson is still working on this project and making changes, can we give him some support Smile

Obiron

#27
[eluser]The Questioner[/eluser]
One of my prior businesses was the development and marketing of an EPOS (stock control, invoicing and point-of-sales) system for small-to-small-medium sized retailers and wholesalers.

It went moderately well, except that I really needed a partner to help share the workload – development/support/marketing really took a toll and was too much for one person. Constantly switching hats wore me down.

The product itself was written in VB/Access with some custom built/third-party DLL's. It utilised barcode scanners, thermal receipt printers, LED pole displays and electronic cash drawers.

I would (very strongly) suggest that you develop in a proper desktop language, such as VB.NET or C#, with an SQL Server backend. PHP is a web scripting language and is simply the wrong tool for EPOS systems.

1. Any decent EPOS system will need to integrate with all the standard EPOS hardware. The whole point of EPOS systems is they accelerate the point-of-sales stage of retailing. You cannot do this with a browser-sandboxed scripting language like PHP (e.g, integrating with a barcode scanner is critical to success).

2. Even with AJAX, web development interfaces are inferior to desktop based applications. Slower, more limited and less powerful.

3. The entry point for EPOS systems in terms of functionality is quite high (as there is so much competition). You will need to add a lot more functionality just to get on par with the standard. Look at the features of Microsoft's RMS (Retail Management System) for an idea.

4. Users will need a 100% broadband connection to the internet in order for your product to work (unless you install Apache locally on their LAN's – which is another problem). Even if their connection has a 99% up-time, that would be nearly 4 days a year with no workable EPOS system – critical to a retailer.

5. Data is sitting on a remote server, which is a potential security risk. What if the webhost falls prey to the recession? Or is compromised? Desktop-based solutions will have the database sitting locally, where they can keep an eye on it and apply their own backup and maintenance routines.

#28
[eluser]obiron2[/eluser]
[quote author="The Questioner" date="1230438440"] 1.Any decent EPOS system will need to integrate with all the standard EPOS hardware. The whole point of EPOS systems is they accelerate the point-of-sales stage of retailing. You cannot do this with a browser-sandboxed scripting language like PHP (e.g, integrating with a barcode scanner is critical to success).

2. Even with AJAX, web development interfaces are inferior to desktop based applications. Slower, more limited and less powerful.

3. The entry point for EPOS systems in terms of functionality is quite high (as there is so much competition). You will need to add a lot more functionality just to get on par with the standard. Look at the features of Microsoft's RMS (Retail Management System) for an idea.

4. Users will need a 100% broadband connection to the internet in order for your product to work (unless you install Apache locally on their LAN's – which is another problem). Even if their connection has a 99% up-time, that would be nearly 4 days a year with no workable EPOS system – critical to a retailer.

5. Data is sitting on a remote server, which is a potential security risk. What if the webhost falls prey to the recession? Or is compromised? Desktop-based solutions will have the database sitting locally, where they can keep an eye on it and apply their own backup and maintenance routines.[/quote]

@ The Questioner

All the points you raise are very good and worthy of discussion and I will start by addressing each point in order.

1) Most EPOS hardware these days is designed to plug into a PC via USB,PS2 or Parrallel port. With the exception of printer control and the disabling of the print dialog box there is no reason why the technology cannot be configured to use standard hardware. Barcode readers and scales are simply replacement IO devices and normally trigger a keyboard input. touchscreen technology replaces the left mouse click. Even for print dialog there are solutions - none of which I particularly like.

2) But because of Ajax, the functionality is actually possible. Before its development, I would agree, this sort of application would not have been possible.

3) I couldn't agree more about the high functionality requirements, but most acitivity occurs around specific and definable activity patterns and will normally require the same steps to be repeated. Linear process flows like this can easily be achieved in a Web base application. If we were tyring to do CAD design or provide 'artistic' tools (which would include anything requiring freedom of design) then I would be more sceptical.

4) There are emerging technologies to support web based applications for when the connection goes down. Two ways already suggested are Google Gears and a fallback router that drops back from ADSL to ISDN and then to PSTN (dial up - 56k - nice!) or to install apache and MySQL on the local server to act as a backup in the event the broadband connection goes down.

5) Data being held remotely is a commercial and business risk, not a technical one. Personally, provided the correct Escrow agreements are in place and I have a course of action to recover my data should anything happen to the supplier, I would rather have my data in a data center with military level security (electronic and physical) than have to maintain my own servers and do my own data backups.


To say it is not possible is a fallacy because it has been done. Cybertill in the UK have a system installed with a number of retailers including almost 300 installations for Games Workshop UK.

The benefits of Software as a Service can be huge:

Maximum flexibility on hardware. A PC stops working - swap the box. Because there is no software installed, you can get a new till up and running almost instantly (an hour perhaps -to install the peripheral drivers)

Instant data - From a head office perspective, realtime data on trading activity is a big win for SASS solutions. I was working for one company about to install Cybertill and they were planning to alert area managers of any shop that had not taken a transaction by 9:30 in case there was a problem. You cannot do that with local systems and an overnight data feed. If you are using a client application and centralised database, you would still have the same broadband connectivity issues.

Mobility - managers can access the system from anywhere they can get an internet connection.

Low running costs. One application, no client side software upgrades, payment plans based on concurrent users or volume of database activity, No DBAs, no redundancy failover hardware.

Low selling costs. Simply set up a trial company database and the system is up and running. No customer visits, no complex installation process, NO UPGRADE VISITS!!!!!

If it can be made to work - and its a big ask - it could be a fantastic product. Difficult does not mean impossible. The scope for SASS applications is huge - Accounting, workshops, Warehousing,


Obiron

#29
[eluser]The Questioner[/eluser]
obiron2, some of your points are interesting and you are right in stating that technology has advanced significantly. The undeniable truth is that the future of technology is the internet. It’s just that I don’t think we’ve quite got there yet.

1. You’re significantly underestimating the awkwardness of configuring and implementing legacy hardware, such as parallel and serial port hardware (cash drawers still widely use this technology). These are not plug and play (like USB), nor can you use a USB convertor/emulator (they don’t work properly). Some hardware has pass-through port functionality, which compounds these problems (e.g LED pole display with pass-through connector for accompanying thermal printers).

PC manufacturers have stopped building machines with old, legacy ports. So most of the time you will need to fit and install PCI serial/parallel cards into each client’s workstation (assuming that there is a free PCI slot available). The concept of a maintenance-free, thin-client is thus simply not true. An engineer will have to be on-site to take of these matters.

In addition, many clients commonly have existing EPOS hardware which your software will also need to capacitate for (i.e don’t assume that clients will only purchase/use your recommended hardware).

2. AJAX has improved the experience of web technology, but is still woefully behind what is possible with traditional desktop interfaces. Can AJAX even begin to emulate controls such as Infragistics, CodeJock or FarPoint – without suffering from speed lag (constantly having to refer back to the web server to pull data, even if only a DIV element is being updated)? AJAX will not work if Javascript is not enabled or if the client is using an older or non-standard web browser.

3. All applications can be defined as “…acitivity occur[ing] around specific and definable activity patterns…normally requir[ing] the same steps to be repeated. Linear process flows like this can easily be achieved…”, but this doesn’t change the reality that you will still need to add a lot more functionality just to sit on the same level as your standard competitor.

On a business level, clients don’t really care what technology you use to build their system, as long as it does the job to the best of what is available. PHP is (or any web technology) is not the best of what is available for EPOS applications (compared to standard application development languages).

Like all web technology PHP is not compiled, needs extra security layers/complexity (SSL) to communicate securely with the backend, needs extra layers/complexity (AJAX) to provide a decent interface, and can take over three times longer to develop than a desktop application – even with our beloved CI.

4. Again, this is extra complexity and maintenance with little benefit over desktop applications. An engineer would have to visit on-site and set-up all of these additional facilities, and then he would be roped into constantly supporting and maintaining them as well.

5. “…I would rather have my data in a data center with military level security (electronic and physical) than have to maintain my own servers and do my own data backups…”. However, the reality is that many clients would insist on “owning” all of their own data in-house where they can keep an eye on it and know 100% who has access to it. They may already have backup and maintenance schemes in place for other existing systems, or may not want to pay the additional charge of outsourcing the backup. You need to think in terms of business rather than technical.

As for the other points:

“Maximum flexibility on hardware. A PC stops working - swap the box. Because there is no software installed, you can get a new till up and running almost instantly”
Unless you have to change the PCI legacy port card, or install and configure the EPOS hardware for the new PC.

“Instant data - From a head office perspective, realtime data on trading activity is a big win for SASS solutions.”
“Mobility - managers can access the system from anywhere they can get an internet connection.”
Yes, you are correct. One of the main issues for EPOS systems is the ability to communicate, centralise and coordinate data from multiple physical locations. It is on this point that a web-based solution holds its strongest basis. This is a major weakness for traditional desktop EPOS systems.

“Low running costs. One application, no client side software upgrades, payment plans based on concurrent users or volume of database activity, No DBAs, no redundancy failover hardware.”
Again, this depends on the EPOS hardware, the PCI legacy card, the backup Apache server, the broadband router, the web host data maintenance plan and charges, etc.

“Low selling costs. Simply set up a trial company database and the system is up and running. No customer visits, no complex installation process, NO UPGRADE VISITS!!!!!”
This is easily possible with existing desktop EPOS systems.

#30
[eluser]Unknown[/eluser]
i was able to write a POS before. 1 is built in vb6 another is vb.net. the software needs to be installed into the terminal computers or should we say POS terminals. if you need to update the version you will have to update each terminal. but i don't think its that difficult to do. there could be many ways to simplify that task. about making a web based POS system, i think its somewhat challenging. external devices/periperals are used in POS software such as barcode scanner, printer and cash drawer are just basic of them. for barcode scanner, this is not a problem. as simple at it can be its just like a keyboard. as long as the input is focused on the right field in the screen there will be no problem. you will just have to do some extra manipulations on the screen and on the browser. they are sometimes sensitive to accidental pressing of keys in the keyboard. for the printer and cash drawer, this may need a written driver for the POS to interface with. the terminals will have to download the driver (written by you or 3rd party) as part of the initial setup of the software in the terminal. one feature that a desktop based POS has that i love is the ability of it to work even if the network is down. in stores, even in high tech ones, POS terminals are networked either via cable lan or wifi. the system operates in centralized manner wherein there is a database server somewhere in the store's office. when we designed the POS softwares back then, we design them to be able to work as stand alone in case they can't communicate with the server. like what the previous post said. it has its own database within the POS terminal itself (it can be exported to cd and usb drives for uploading into the server). there is the main server (the main database). and there is the terminal database. there is no downtime as long as the POS is running and the customer wants to buy what he got from the stacks in the store. even if the router broke, somebody tripped the cable, the server is down. as complicated as it can get..hehee...there's even the third background process software that synchronizes the terminal to the server when the connection is back. this setup is critical to some stores where there's always a pile up of customer waiting in the line to pay.

i would also like to be able to develop POS written in PHP via CodeIgniter if possible. the challenge i think is how to implement real life flexibility features and how will it perform well just like any other desktop POS systems.

best luck to you sir.


Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  


  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2020 MyBB Group.