NYCPHP Meetup

[Tim Lieberman]

I don't care what POS, as long as I can hack it. 

In this particular instance (low volume, high-value retail/web 
transactions of unique items) what I really need is a very hackable 
inventory management database with *both* a POS interface as well as a 
web-store interface.

I can talk to POS vendors all day, and they just wave their hands around 
and say "sure we can integrate it with your web site", but it's always a 
lie.  The source is generally secret, oftentimes the internal database 
is not documented or even reasonably hackable.

Imagine you're selling masterpieces.  There is only one Mona Lisa, so 
you really don't want to get into a situation where someone buys on the 
web, and then someone else walks out of the shop with it before the POS 
polls the web site and discovers that the ML has been sold. 

Another application for the core database to support might be an 
in-store kiosk, so if you see things you like at location A, the kiosk 
can show you photos of items you can go see at location B if you're 
interested.

At the end of the day, I want *one* central DB of inventory, with at 
least some amount of (hackable) code that drives a POS interface and a 
web store interface.   I'm trying to avoid an integration kludge that 
sells one of those interfaces short.

If I can't find something useful, I might just do it from scratch and 
make it open.  It seems like it's going to be an increasingly common 
itch.  I've done plenty of web stores from the ground-up, but the 
point-of-sale stuff is what I'm more concerned about.

Note, that in this particular instance, it's no problem for the store to 
lose access to the POS in the event of a connection problem.  If the DSL 
goes out for a few hours or even a day, the chances of a collision 
between web & bricks is unlikely, and can be reconciled (low volume/high 
prices & margins).  If the sales staff need to just write up receipts, 
run credit cards manually, and take notes, they can log the information 
against the inventory later.  I guess that's what makes this not already 
a common need.  These guys don't care much about logging who did what, 
or tracking timecard info, etc.  They just want a POS solution that's 
better than their home-grown filemaker DB, and they want to be able to 
sell fancy stuff to rich people on the internet.  They want it to work 
most of the time, if not all of the time, and they want to avoid having 
to enter/reconcile inventory between two discrete systems.

Hope the detail helps, TIA for any pointers.

-Tim

CED wrote:
> What POS software? I've found Quickbooks to be pretty smoothy to script to.
>
> ----- Original Message ----- 
> From: "Tim Lieberman" <tim_lists at o2group.com>
> To: "NYPHP Talk" <talk at lists.nyphp.org>
> Sent: Sunday, July 22, 2007 11:41 PM
> Subject: [nycphp-talk] Integrated eCommerce/POS?
>
>
>   
>> Just thought I'd ask here.
>>
>> I'm looking for (open) tools to develop an integrated web-based store, 
>> and also a POS for the brick and mortar side of the business (two 
>> locations for an importer of specialty items and antiques).
>>
>> The client imports a bunch of high-end, mostly unique, items from the 
>> east.  Ideally, there would be a module for oscommerce or similar that 
>> wo0uld provide an interface tuned for POS activity.
>>
>> Anyone have any pointers?
>>
>> So far, google hasn't turned up much that looks promising.
>>
>> -Tim
>>
>> _______________________________________________
>> New York PHP Community Talk Mailing List
>> http://lists.nyphp.org/mailman/listinfo/talk
>>
>> NYPHPCon 2006 Presentations Online
>> http://www.nyphpcon.com
>>
>> Show Your Participation in New York PHP
>> http://www.nyphp.org/show_participation.php
>>
>>
>>     
>
> _______________________________________________
> New York PHP Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
>
> NYPHPCon 2006 Presentations Online
> http://www.nyphpcon.com
>
> Show Your Participation in New York PHP
> http://www.nyphp.org/show_participation.php
>
>