Check Cashing POS (WEB or Desktop App)

We are looking for a top professional programming team to develope a Check Cashing based POS. Experience with POS is a big plus! This means that you have previously worked with taking data received by an attached device (scanners, printers, barcode, etc), injected into a DB and had information available to a user on the screen in realtime - the essence of a POS. Developer Requirements: Can come up with solutions to complicated programming issues. We are looking for problem solvers and progressive thinkers. If there are requirements that you feel can be enhanced, we need developers who can communicate that effectively. Ability to communicate in realtime via email, IM and telephone. Ability to accept shipments (printers, scanner) for development testing Environment: Prefer an open environment, one that will lend itself to future growth and expansion. Willing and open to consider alternate environments as they may be more feasible Development Environment (Option One): A. Windows + Apache + MySQL + PHP (possibly also: JavaScript, Ajax) B. Ability to create Browser Interfaces (like the many IE interfaces available today) C. Ability to Integrate Desktop Widgets/Components into the Browser Interface + These Widgets/Components are the cornerstone of the system since they will be communicating with the devices (scanners, printers, etc) directly and updating the Web Pages. The devices all have SDKs/APIs available. To get an idea of the "hybrid" solution I am talking about, please visit this url: [login to view URL] The sample above provides a general and good idea of the concept. If you are *unfamiliar* with Browser UI development, integrating toolbars, working with rendering engines like Gecko, IE and consolidating these technologies into a usable POS - then Option One is probably outside your level of expertise. If you have experienced with building new browser interfaces, toolbars, integrating controls to access desktop devices and services, please note that this is the preferred method for developing this POS and we would welcome the opportunity in speaking with you further regarding this. Development Environment (Option Two): This is certainly the standard and more cost effective solution A. .NET Framework 2.0 (VB, C++, etc) B. MSSQL as the storage engine (Alternate DBs considered) C. SDKs and APIs available for the devices. D. Ability to create a modular build of the POS. This will require the developer to be able to compile their code into modules and that each module can communicate and pass information effectively throughout to the core engine (GUI and Database). Here's an example: Core: GUI. This is what the user interacts with. Fields, queries, etc Core: DB (MSSQL, alternative DBs considered). Modules: Scanner, Printer, ID Reader, DB backups and other replaceable, upgradeable routines. Breaking the POS into a modular build, will allow deployment of new Scanners, printers and other devices. If a printer needs to be upgraded, it will be far easier to integrate a new module then it is too recompile the entire application later on. DB backups are also treated as a module. Routines dealing with backing up the DB, making information available across several DBs located in various stores will also be dealt as a module. To give you a better idea and a general summary of the project end result, the Check Cashing POS will be installed on several stores. Each store will run it's own server. Within each store, the employees will be network connected to their specific inHouse server. So we have a POS at each store. As transactions are processed, the information will be updated within each server. We are not just dealing with a single Check Cashing Store, however, but a chain of stores that need to share data and this is where routines as modules come into play. We initially plan on instituting a Central DB that will hold this information. Backsups of all store DBs will be done nightly to this central DB. Each store will also gather the information/transaction details and update their individual DBs. By morning, all transactions from the previous day will be available to all stores. This is a bit of a kludge, but internet access can be flaky at times and it makes real-time data sharing (or relying on a central DB to capture all data in real-time) too risky for this initial launch. So the DBs are updated nightly in this phase one. As as step in a future upgrade procedure, we can consider a level of real-time Data Sharing across all DBs. It is for this and reasons pointed above that routines such as these need to be written as modules. When we are ready to upgrade DB routimes, replace a scanner, deployment can be done much more effectively and often transparently. The above should provide you with a strong general idea of what we are trying to accomplish here. Questions are expected, so please PMB us so that we can move forward through this process. If you have alternative ideas you would like to share, by all means do so. As stated earlier, we are not looking for developers who think they may be able to handle this, we are interested in developers who are certain they can handle this and are already thinking of solutions, coming up with new ideas and thinking of obstacles that need to be overcome.