After some days of fixing (minimizing luggage) the code to handle strictly POS, but powered by iDempiere in the rear, i am ready to commit this as entirely new forks and maintain them as such. It follows my policy of separation of concern. Let each layer does its job best - POS just capture sales, and ERP does the heavy intel. CAVEAT: My pos version is more specific to simple restaurants/cafes connected to an ERP. For higher uses, the Ghintech version will be the direction.
Nevertheless i give a full cycle of running to ascertain nothing is broken. Here is a screen to show Cash Closing after a series of tests:

- CloseCashRefund.png (44.74 KiB) Viewed 24766 times
Note that it can handle contract catering accounts. Here is a sample Credit (Debt) payment receipt been generated to a contract client on credit:

- POSCredit.png (66.72 KiB) Viewed 24766 times
I managed to test the import to be intact on the ERP server side. It even consolidate the importing into a single customer header order since the last process.
I have made the ActiveMQ reading to be more meaningful. Here is a retest on already imported message to get the expected response.

- XMLFeedback.png (18.72 KiB) Viewed 24633 times

- GoodFeedback.png (20.02 KiB) Viewed 24628 times
(This is a pending work in progress) as menu items are ordered, it is the resultant raw material that is finally affected and the restaurant need not do the stock ordering again.
Here is a checklist on the extras of how this POS Integration is done differently:1. There is pragmatic and less transfer of info to and fro. Just sending list of Cashiers, Customers, Products, Pricings and StockQtys though sent is not important. Thus we need not keep sending stock qtys. Its integration with the ERP will resolve that via replenishments.
1.2 The ERP side receipt likewise consolidate auto-sent POS orders. What is vital are material consumption for replenishments.
2. The Import Queue To Order directly as Sales Orders, its status as InProgress and TargetDocType preset to POS Order or OnCredit (if debt) (Make sure PaymentTermSchedule is valid as in example of 50%/50%)
3. Particularly for restaurants, the products sent are part of the Menu Engineering (using BOM template) as parent and at the server side, there will be a 'raw materials' process to convert the sold 'parents' into BOM children such as rice, sugar, flour, veg, milk, coffee, etc!
In this way it becomes a powerful full cycle ERP that makes stock-checking update redundant. The raw materials are moved to the POS virtual locator and upon process, becomes consumed to trigger replenishment as set in its reorder rules. Of course there will be inaccuracy and thus the replenishment calculation will buffer some fraction for error and atuned as time and experience goes on as to the accuracy of the menu engineering templates.
The nett effect is POS franchisees have minimal extra paper work or stock checking.
Maintenance & Security Aspects:1. I have removed any core changes or overloading of iDempiere models, introduced by Ghintech. The POSIntegration is further reduced from other features added such as CreditMemo and resend Orders handling. I feel it is best handled outside the POS environment. The POS should be purely for fast and efficient gathering of POS activity. When you open POS Integration menu you will see only two simple items - Export to Queue, and Import Queue to Orders. That is it.
1.2 However we must thank Ghintech for their contribution which improve the synch from POS to MQ with automatic timer. It is now set to 1 minute in the Orders-Minute tag in the Openbravo.properties. This looks practical because at POS side, the users might be lazy or too busy to manage sending back orders. But i am not taking their Cash Closing back to ERP. Let those be handled at POS stations respectively. ERP should be just to gather total sales, (nett with refunds) and credit totals. I weigh this against the sheer need of maintanability. Usually developers overload code and leave them badly commented or designed. In the end, we ended up with lots of time wasting and even lost of productivity. I prefer things to remain as unperturbed, elegant as they are. This integration is purely to fulfil 80% of the biggest needs and leave the rest to workarounds or localised extensions.
Previously the same happened in Cameroon when i taught there and introduced my Openbravo POS integration for them to improve. Their WandaPOS ended up adding on Android interface that began to bog down and became unwieldy. So it is no surprise they do not make the light of day. If there is any specific important feature set to add on it should be a separate regime for the sake of sanity.
1.3 I also simplified the Import to Orders. First there is no longer going thru the I_Order stage. Synch back is done directly to Sales Orders. I also consolidated similar Customer headers. Walk-ins will be bunched into one big Standard Sales Order at every synch. If you do not synch for whole day and synch only once, you will find your your POS sales in one single huge order for per POS Locator. That should be fine, because HQ are not expected to micro manage and POS locations still keep their respective details.
2. I done my best (and still improving when there is new discovery) to avoid technical mistakes during use. For example if there is sudden outage and breakdown and some orderlines are duplicated, the ERP side will detect them and avoid rewriting the same lines.
3. Intending for simple multiple cafes setup, I am a fan of WebServices. I am very impressed with Apache Active Message Queue, as it is very light to setup and stays alone on the cloud. This makes both the POS and ERP side out of the grid. It is simplistic, minimalist and asynchronous, which should be a favorite in remote areas. I also reduce the payload of each XML packet. This is very elegant to me. The Active MQ is just a post office that you drop your packages and forget. On your ERP side, you do not get visitors. They do not call you, you call the post office up to get your mail. And its only one way. I am also dropping the sending by POS of new customer and cashier details. I feel they can be sent separately to ERP thru other means. Leave POS to do what it does best. Learn from Larry Ellison's folly with the Sun/Oracle Thin Client project which crashed due to Larry's constant adding on. In fact, Eduardo Gil of Ghintech complained to me his clients in Panama is getting more bogged down and they are moving towards web-services. He told me he will publish his soon and i will provide links to it.
So i hope users will differentiate between this and Ghintech's that resolves much accounting needs of big malls and Latin America fiscal printing control. We still work closely together sharing ideas and agreed to focus on separate but complementary ends.