Point of Sale

[Andreas Pauley]

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?

Regards,
Andreas

 

[Peter Hansen]

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.

Do you have information about the interface to the ERP back end?
It could be anything just about anything...

The project will include development to ensure that the features they
require are included in the open-source POS system.

I read that as "will include automated acceptance tests", but perhaps
you meant something else?

Can you recommend anything that I can use?

There's a good chance you'll need to use PySerial, if the
cash registers are connected via RS-232, but beyond that
there's not much to say without more info. I believe I
heard somebody talking about a Python POS system before
in this newsgroup, but I'm not sure: check the archives?

-Peter

 

[Cameron Laird]

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?

 

[Andreas Pauley]

.
.
.
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

 

[Andreas Pauley]

Do you have information about the interface to the ERP back end?
It could be anything just about anything...

See my reply to Cameron.

I read that as "will include automated acceptance tests", but perhaps
you meant something else?

Actually I just mean that I'm not looking for a 100% feature-fit, if I get
a 70% fit I'll jump in and develop the other 30%.

There's a good chance you'll need to use PySerial, if the
cash registers are connected via RS-232, but beyond that
there's not much to say without more info. I believe I
heard somebody talking about a Python POS system before
in this newsgroup, but I'm not sure: check the archives?

Thanks, I'll keep PySerial in mind.
Up to now I've googled a bit, and looked at Sourceforge projects.
(I also did a search on the 51664 messages in my local Python-list folder)

At the moment I found a POS in GNU Enterprise, a project named "custom"
and another project named "Auto Auction".
I'm not sure what the features of each system are, I'm busy checking them
out one by one.
Then there's also 3 or 4 Python systems which haven't released any files
yet.
Currently I'm evaluating GNU Enterprise.

Regards,
Andreas

 

[Evan Simpson]

If the network is down each POS station should still be able to function
without interruption.

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.

You may want to check out the Spread Toolkit, at www.spread.org, whose
Python wrapper lives at http://www.python.org/other/spread/doc.html.
It's used by the Zope Replication Service, for example.

Cheers,

Evan @ 4-am

 

[Cameron Laird]

.
.
.

Actually I just mean that I'm not looking for a 100% feature-fit, if I get
a 70% fit I'll jump in and develop the other 30%.

.
.
.
I keep winning contracts where something is a 70% fit, and
all I have to do is finish the other 85%.

 

[Andreas Pauley]

You may want to check out the Spread Toolkit, at www.spread.org, whose Python
wrapper lives at http://www.python.org/other/spread/doc.html. It's used by
the Zope Replication Service, for example.

Cheers,

Evan @ 4-am

Thanks a lot, I need components like these desperately.

I've also seen ICE from ZeroC (www.zeroc.com) and OSE
(http://ose.sourceforge.net/browse.php?group=python-manual&entry=modules.htm)

I haven't tried any of them yet, will have to do that a bit later.

Andreas

 

[Anwar Ulhaq]

feedback

I haven't tried any of them yet, will have to do that a bit later.

Andreas[/QUOTE]

17/11/2010: Hi Andreas, I'm in more or less same situation as you described above. I wonder if you have any feedback on this project. Anwar