Much of the discussion below is very old!
Danie did develop some of this but it was specific to a customer and none of the work came back to webERP.

I have started to develop something using a compiled language called Genie. Genie is able to use the C libraries for Gtk+ and xmlrpc-c. So far I have been able to populate a local (sqlite) database with all the necessary data downloaded over the webERP xml-rpc api and have a sales screen that allows searching for items and searching for customers (when charging to a credit account).

The sales side is not complete and also the transmission back to webERP of the sales transactions over xml-rpc.

Looking at integrating this POS to EFTPOS - using Cadmus/Smartpay syncro-plus software would be quite expensive - in NZ the integration needs to be certified by the banking authorities $5k a pop. Then of course you have the ongoing costs of lisencing the use of syncro-plus software.

However, I have created a standalone POS that does not require full time connection to webERP that has completely interactive search and input as a desktop application that will open a cashdrawer and print receipts automatically - written in python - the code is available on

Some blurb about features and installation:

A windows binary installer is also available at

(( Forum Discussion))

Old Stuff - Specification

PosInterfaceSpecification Click Here for the specification.

Whiteboard Notes

* PosInterfaceSpecGUI About the GUI and Interface
* PosInterfaceSpecSecurity About the Access Control
* PosInterfaceSpecSalesman About Salesman and Commission
* PosInterfaceSpecAvailability About availability and handling of Groups and Combos
* PosInterfaceSpecDeliveries About deliveries and delivery based sales
* PosInterfaceSpecAccounts About payment handling, petty cash and banking
* PosInterfaceSpecCalc About calculations in regards to pricing, tax etc.

Whiteboard Discussion

* Calculation of one (fixed) sales tax and totaling

<PhilDaintree>This would be a POS function</PhilDaintree>

* Payment (Cash, Check., Charge), with an option for split payment types
($10 cash, $15 check)
This is where things get really complicated, depending on the warehouse
(location) from where you are selling, the customer you are using as your POS
customer (debtor) and the allocated price list. Availability also plays a
roll here, and it is incredibly complicated to handle assemblies and sales
kits (availability again, however we limited it to only one level deep in the
BOM for this reason).

<PhilDaintree>Not sure we want to worry about assemblies/kitsets since an item a customer carries to the checkout will not be either of these - assemblies/kitsets require packaging and are collections of multiple items - let not complicate this.
Another point - we don't need to worry about availability either since if a customer picked it up off the shelf then it is available. It is not available to the next person - subject of course to a squabble at the checkout
This is assuming we are in a retail store of some type:
An example of an assembly for instance is buy a cooldrink and get some sweet for free. This deal is only available while stocks last, i.e. if we ran out of either the sweet or the drink. (They call it a combo sale but it is the same thing !!no packaging required!!)
The kit sale is what they usually call a grouping which list a basket of products as one item and then expands on the invoice, these are for instace a 6 pack of beer, you could break the pack open and only take two if you wish (liqueur store) !!packaging here but its grouped rather than seen as individual!!.

The split payments is where we ran into a problem as well. Banking needs to be
improved on the system as the cash drawer is also a petty cash account and so
is the drop safe. This is the only way to handle order balancing in the end.
Cash can be allocated directly to the order, however the credit card
transaction was a problem. For that an additional field or special handling
of the reference field because the name of the customer is not connected
correctly on a POS system since the cutomer is POS not Joe blocks ("Front
Counter" in your case).

> <PhilDaintree>This would be a POS function</PhilDaintree>
> Later, the selection of customer other than "Front Counter" would be a
> bonus, but is not required.
In my country this is an requirement now, but the main thing to concider here
is that in WebERP a customer can have a separate price list and on top of that
can have selected pricing on specific items. Do you intend to honer that or
will you decide to simply use one price list. Also keep in mind the fact that
a customer can have his own currency. The defaultlocation of the POS customer
or any other customer for that matter is ignored and instaid the warehouse
location is used. This makes the from and to locations the same as far as tax
is concerned and the only difference here is the tax level. One thing we do
not handle yet is the separate summation of different tax levels, also we do
not have a receipt string for each tax level. Generally they have to be
listed separately and items need to be marked according to the tax that is
applicable, here by us we use a * and # for that but then we only have 3
levels of tax (VAT Excluded, Zero Rated VAT and VAT at 14%) we actually have
to report on the last two to the government.

> I *think* that's all I'll need on the POS side. Returns and inventory
> control can be handled in webERP. (The POS station will have a Web
> Browser.) What am I missing?
> <PhilDaintree>Well this maybe the fun bit..... wrt webERP integration. The POS
> system needs to populate the Cart Object - see includes/
> and send this to webERP - a script in webERP needs to take this data
> verify and make the sale happen with order and invoice.
This is correct, once again some rpc methods required, however I faced a
problem with this as there need to be difference in how the invoice works,
mostly the invoice information needs to be passed back and the POS system
must have some mechanism for handling that data, WebERP will simply mark the
order as invoiced. This is needed because the POS printer does not print
fancy laser stuff, and it only has 20/40 columns. I've written an Object
under free pascal and a special root process to handle that type of printing
under linux, but still the problem is Print It Yourself with the correct
information provide by WebERP.

> We may need to add a couple of fields into this object to deal with the
> payment integration - I am thinking amount and method - or perhaps an array of amounts and methods for split payments. Perhaps the POS
> configuration would tell us where cash is banked to and this data come
> accross too. webERP would create the entries for
This is needed to handle bank recon against the orders (for the checks and
credit cards), I think correct me if I am wrong.
> - sales order - referenced to the Front Counter - or whatever customer is
> chosen as the account to enter POS through.
> - sales order details - ref sales orders, with all the line items on the
> sale - debtortrans - customer transaction for the invoice referenced to the
> order - gl trans for the total amount of the sale
> - salesanalysis by customer, item, sales area etc etc as usual for webERP
> sales
> - debtortrans for the receipt
> - banktrans for the receipt of dosh
> - gl trans for the receipt
> - custallocs for the allocation of the dosh vs the invoice
> most of this is a copy of the sql from ConfirmDispatch_Invoice.php if
> isset($_POST['Process']) code plus some from receipts .... I'd like to help
> with this if you want me to. I just need this Cart object - with the
> payment fields metnioned above populated together with the LineItems array
> populated and dispatched to webERP by some convenient protocol of your
> choice.
> This would be great to get a fully webERP integrated POS system
> </PhilDaintree>

I am trying to get us there, but some work remains on the rpc side, data
exchange side, and especially the banking side. (security handling and
accessing other information is now available. still need to expose it though)
also access to customer information is required as in at least our country,
you can not claim you VAT back unless you provided your personal details, new
customers therefore is created with a copy of the POS customers information
(location, pricelist, currency, etc.)
I would have thought this is unusual - the customer in NZ/Australia/UK is certainly not quizzed on who they are there is an exchange of smiles and EFTPOS/Credit card/Cheque details, thats all
<DanieBrink>This is a Tax Security/Check thing stops Tax evasion. Will not be too surprized if it pop's up somewhere else as well.</DanieBrink>

People pay for deliveries out of the till so the petty cash must be right I
would think. Also as soon as there are more than a certain amount of cash in
the till it gets dropped, this need to be reckoned as well as most of the
theft happens there. Camaras can check the till, but can usually not see the
drop safe clearly.

As far as our own POS system goes, we are about 70% on the way, but we need
some interfacing with weberp as well. As a side note we also need commissions
working and hierarchical sales categories specifically for POS and osCommerce.

<DickStins (2005-01-23 17:09:49)>
You need a queueing system at server site and at client site per pos.
This for submitting transactions and synchronising stock both ways (when one pos sold something then the stock should be adjusted at every other pos) and synchronizing price changes, new items, .....
Implicit requires this a local pos database.
I don't think we need to worry about availability - just recording the sales in webERP and retreiving pricing and item details from webERP. I agree that the POS system is a client application which requires set up for operators, till settings, EFTPOS setup integration etc. all locally not inside webERP
<DanieBrink> See above about assemblies ( combos ) and kitsets ( groups )</DanieBrink>

<DickStins (2005-01-23 17:09:49)>
You need this, because a pos system should be of very high availability.
When network connections are broken, you need still to be able to help your customers without correcting it manually in the pos system/weberp.
How are you going to treat situations when two pos' sold the same item (should be only possible when the network connection has been disabled for a while?)

I think DickStins hit the problem/nail on the nose/head. I tried to solve it in my own postgres system by transcribing the cart functionality to the database. This meant that all carts everywhere, even eCommerce, was aware of reserved quantities at the same location. I think we might need to do the same here again.

It needs to work something like this.
Carts need to be created and they must have a lifetime connected to them after which they will be ignored/removed, however as is needed on POS and eCommerce systems an Cart must be storable as well, this is done by assigning a reference code to it for retrieval purposes. The lifetime is then adjusted, to however long you are prepared to reserve the stock.

It is now simple to adjust the availability calculation functions to keep tract of the carts as well (some nifty functionality is required with kits).

This idea has the additional benefit that all carts no matter whether inside WebERP, POS, eCommerce or some third party system will be sure to keep each other in mind (no clash). Of Cause, this suggest that an interface needs to be provided to view/load/delete a cart. Also you need a system by which an Administrator or simular type rights can delete carts without notification to free up stock in the store. And of cause if we are working with serialized items and it is placed in a cart where it already exist in another it needs to be removed from that other.

This would probably become core functionality.

One thing to note is that this would be come the quote system and from here an order and then whatever.

One other thing we were struggling with was that the customer required us to have different delivery addresses and people for groups of items as well as different delivery dates. May be we could do this with the cart which would then split in to more than one order as required by the system.

<PhilDaintree>I wouldn't have thought there would be any issue with delivery addresses since the reality of POS is that it is pickup only? Also delivery dates, its delivered as the customer takes the stuff out the door isn't it - I might be confused about the situations where POS is used - could it be paid for now and delivered later - in which case availability is an issue as are delivery addresses and dates - in this situation maybe a webERP terminal/browser would do the trick - with a scanner on the quick entry screen.
This is true, however I am also trying to solve the problem of eCommerece at the same time, why implement two systems if one will do.
However a wine shop, gift shop, flower shop or any business that specialize on deliveries need this, payment up-front with slip however.

If the POS is running outside webERP (not connected) why not just export a stock list & pricelist, sell the items, adjust stock at the end of day & post totals to the cost of sales & sales & Petty Cash & Bank. Then this would be all the functionality needed I think.

This is a legitimate alternative and possibly better - maybe the POS system could make a log of transactions which could be uploaded daily to werbERP.
A delivery address thing would require more than just a POS terminal - you'd be into a keyboard et al.
I feel the same way, If you want simple POS integration, this is the best option. It also allows other simple (not being mean) POS system to integrate as well.
If you want crushingly powerfull, do it the other way and export as mush functionality as possible also link directly against WebERP no caching of data. It allows for some really powerfull future stuff (JIT for instace)

Better yet, I/we do both.
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki