Point of Sale

[Andreas Pauley]

On Thu, 27 Jan 2005, Cameron Laird wrote:

> In article <mailman.1429.1106831269.22381.python-list at python.org>,
> Andreas Pauley  <andreasp at qbcon.com> wrote:
>> Hi,
>>
>> My company has given me a rather cool project:
>> I have to provide them with an open-source python-based point-of-sale /
>> cash register system that can integrate with their existing ERP backend.
>>
>> The project will include development to ensure that the features they
>> require are included in the open-source POS system.
>>
>> Can you recommend anything that I can use?
> 			.
> 			.
> 			.
> Research.  I think you're expecting an answer of the "I used
> open-source openPOS project, and it worked great for me", but
> I suspect all that is premature.  What does POS mean to you?
> What are your platform constraints?  Does your company have
> expectations about how POS will work?  What access (CORBA?
> RMI?  SOAP? ...) is there to the ERP?

Very well, I guess a little more detail would help.

Platform: Cross-platform, although deployment would typically be done on 
Linux.
My company typically expects that each POS station will have it's own 
database with all sales items and other info on it.
The maintenance of sales items, prices etc. should however be done at a 
central location, and then be replicated to each POS station.
The reason for this is that we will typically deploy such a system in 
deep-dark-africa where stable network connectivity cannot be taken for 
granted.
If the network is down each POS station should still be able to function 
without interruption.

These requirements is probably not available in a typical POS system, but 
I'm hoping for a general POS front-end for which I can develop a custom 
backend to plug in.
At the moment the current POS system uses an inhouse developed message 
queing system to communicate with the ERP/Retail backend. A POS station 
submits each transaction (and other relevant messages) to a local queue, 
from where it is sent to the back-end system. If the network is down the 
messages just stay queued until the network is back up again.
The central backend system uses the same queing technique to submit price 
updates etc. to each POS station.

I'm not sure what protocol will be used to communicate with the backend.
I might have SOAP available.
The backend is written using Appservers from Progress Software Corporation 
(a proprietary database company).
The Progress developers would probably be willing to help, so I'm 
relatively positive that we'll be able to figure out a solution there.

The user interface for the current system is character-based.
For the new POS we should ideally be able to use different user-interfaces 
that all access the same business logic, although I would primarily focus 
on a non-mouse driven GUI interface.

I hope the above answers your question, if not feel free to ask again.

Regards,
Andreas Pauley