POS for Tzu Chi, consider linking with Intuit Quickbooks Phreedom

• Drupal-6: UberPOS is a point-of-sales system built on top of the Drupal and Ubercart
• Drupal-7: Commerce Point of Sale This module is the successor to UberPOS, which provided similar functionality for the Ubercart E-Commerce system. Not recommended for production yet.
• Phreedom: Phreedom ERP
  • Phreedom 3.4 release candidate 1 is now available for download from www.sourceforge.net!  Phreedom is the base for additional modules but comes with:
  • Contacts module
  • Inventory
  • Payment (Elevon Merchant Processing, Check, Direct Debit, COD)
  • PhreeBooks Accounting
  • PhreeForm report generator
  • PhreeHelp (manual and query system)
  • Shipping Module (FedEx, Flat Rate, Per Item, Table Rate and Free Ship)
  • The download section has been revamped for easier navigation of available add-on modules, language packs, shipping methods, payment methods and dashboards
  • test site: http://12.208.166.163/PhreedomERP (login: tcnwadmin, pass: phone)
• Feature Q&A:

1. Chinese/English interface?
2. Barcode scanner?
3. SOAP connecting to QuckBooks

Resources:

1. QuickBooks PHP DevKit
2. The Power of Drupal Ecommerce with Ubercart
3. QuickBooks Integration Wiki
4. QuickBooks Web Connector

Specification written by Brother Shyh-Pei on 5/9/2013

1. POS for the shop (we all know that).
2. Separation of POS and QB - from the fear of POS might mess up her QB inventory.
3. The inventory from POS can be easily merged into QB (currently done weekly) after verification.
4. POS should be foolproof to make it less likely volunteers who are afraid of hi-tech (or even lo-tech) stuffs can feel less threaten by it.
5. Chat with Brother Vincent, as he seems to give Sister Even the impression that he fully understand Sister Even's concern on #4 above.

1. as per your request, I'll leave this to whoever volunteer who is going to work on this project to discuss with Sister Even.
2. I don't think she has exactly what it should looks/feels like - her major concern is whether the users can deal with the system.

1. Develop the front end first - a standalone frontend that generate report at the end of the day (or end of each volunteer's shift) . This makes the whole existing accounting procedure remains pretty much the same, and she can verify the data before the data is manually input into QB.
2. The frontend thus can be tested by her and shop volunteers - this is kind like feedback cycle where we check their usage and finding problems, bugs, annoyances, incovenience, etc. And even the POS check out flow, mistake correction, etc. We can make adjustments to make the system be really a help to the shop instead of something that's gets in the way...
3. Once we make the frontend really works for them, we then can investigate how to merge the daily report into QB "electronically" instead of manually. This basically requires us to study QB's API to see how to achieve that.
4. If the POS system we developed is really good that we can address Sister Even's fear of volunteers making mistakes mess up her inventory data, then we can think about realtime update of the inventory system. (I think this is unlikely to happen, but I just list it anyway).
5. If 4 is not a go, then we will need to see if we can improve 3 above to make it possible for Sister Even to verify data, correct mistakes, and merge data into QB thur an application instead, so all she needs to do is click click click... and done... :-)