(new
OpenBravoPOS Distro) Advanced
Asynchronous Integration with Author: Pedro Rozo.
Content
1. What business functionality are we looking for? ...........................................................................2
2. Preliminary Research: What was available in the open source arena ? ........................................3
(new
OpenBravoPOS Distro) Advanced
Asynchronous Integration with Author: Pedro Rozo.
Here we are after some months of research and development looking for a complete open source POS
solution capable to synchronize its inventory, customer and sales transactions with our Adempiere ERP
backend.
Support many (n) restaurant branches with multiple POS connected in an asynchronous fail over
model with one (1) ERP for restaurant chains (each restaurant might have different products).
POS should use only products, categories, taxes, units, customer info and prices defined in the ERP,
no manual overriding should be allowed in the front end POS.
Batch and Real time synchronization: Batch should be supported for initialization of the POS and
emergencies, but any change on the ERP and any change on the POS (for the scope of the
integration) should be sent and processed in the other side.
And also de almost-standr features such as: Complete Touch screen support
Support for many POS printers: thermal, dot, EPSON and so son.
Print to multiple (> 8) printers for orders routing (bars, kitchens, salad stations, patio, and so on)
(new
OpenBravoPOS Distro) Advanced
Asynchronous Integration with Author: Pedro Rozo.
We also asked in the Adempiere forums for previous experiences about it but not much feedback was
received, just some comments were received from Adaxa team regarding some previous integration
experience two years ago, they gave us some warnings because we might need a significant integration
effort to accomplish our goal; we appreciated their comments but at the end of the day we didnt really find a
contribution or starting point to reuse, so we decided to start from a plain OpenBravo POS 2.3.2 and
Adempiere back in July 2011.
3. Design Considerations
Note: Just when we were finishing our first development phase we discovered that Red1 was working in a
POS-ERP integration as well sponsored by SYSNOVA, but from a couple of emails that we sent back and
forth, although we planned to use similar tools in our solutions, the scope of Red1 was focused for end-
users without any important enhancement to the POS engine itself, so his scope would not be enough for
our business requirements. (no support for mltiple units, multiple prices, fraud control, real time sync,
failover and a lot of existente QA issues for openbravo pos) and we were about to finish our main integration
tasks, so we didnt have opportunity to contribute to each other job to much. Then neither we used red1
code nor red1 contribution used our source code.
To be more clear, one of the main differences of our approach were to allow the POS to support a product
model (product, units, prices, an customer) as closest as possible to the ERPs product model due to the
risk of manual manipulation of the information in this industry.
This means that our new POS solution should not use products, units, categories, or customer if they are
not defined in a ERP solution..., yes, it is mandatory to have an ERP, if you dont have an ERP, our
modified POS (SmartPOS) doesnt allow to create items, categories, and so on... and that is one of the main
(new
OpenBravoPOS Distro) Advanced
Asynchronous Integration with Author: Pedro Rozo.
business requirements to control prices, products, inventory and transaction with a good level of security
and prevent and minimize risk of data manipulation. On top of that is the reliability of the inventory, we want
to trust in the ERP inventory not in the POS inventory.
Other topic where we have done a significant effort is to fix and integrate a lot of quality fixes to the original
OpenBravo POS 2.3.2, we integrated more than 50 fixes and new functionality, some of them coming from
the OpenBravo POS forums like the multiple printer support for instance and blocking access to not stable
or not required reports and functionality for a slave POS to guarantee that the Master ERP manage the
information properly.
To be clear and honest we found OpenBravo POS flexible and with a lot of potential, but key features for our
business requirements and real production environments were missing. Then after these months of
development+QA we want to share what we consider a new distribution of Open bravo POS that we call:
SmartPOS, our open source POS distro based in open bravo 2.3.2, but focused in the medium size
business of retail industry where the ERP back end, security, fraud control and so on is required (not
optional).
SmartPOS - Advanced Asynchronous Integration with Adempiere ERP http://www.smartjsp.com 4
Project Developed by Project Sponsored by
(new
OpenBravoPOS Distro) Advanced
Asynchronous Integration with Author: Pedro Rozo.
(new
OpenBravoPOS Distro) Advanced
Asynchronous Integration with Author: Pedro Rozo.
Is SmartPOS an new Open Bravo POS Fork ? We prefer to call it a specialized POS distro (slave)
integrated with Adempiere ERP (master) using an asynchronous approach (ActiveMQ).
Will you publish a source code repository ? sure .....just leave us some time to rest after our recent
production releases :)
Would this SmartPOS be ready for end-users to deploy with a single button or installer ? No... we
have to be honest with you, you need good knowledge about the Adempiere ERP (required), your
asynchronous platform (ActiveMQ), and to understand your POS requirements to have a fully
operational solution, at this point this is not a solution for end users.
Will you plan to release a POS version without ERP ? Not for now.
Is this a release ready for production ? To be honest with you, we have done a significant effort to
have a stable release, our focus was restaurant industry (currently it is working in four (4) restaurants
of a same chain) it is real production, many customers, different locations, but it is part of a huge
POS+ERP implementation with more than 12 restaurants) then it might not work for all the
industries or for your particular reality..., I would suggest and intensive set of tests with the right data
and configuration before planning any production release in your particular environment. Or to
contact us to hire some professional help for specific integration topics.
(new
OpenBravoPOS Distro) Advanced
Asynchronous Integration with Author: Pedro Rozo.
Following data is coming from the ERP and the user can not modify it within the POS
o customers
o tickets
o returns
o units of measure
o payment forms
Enhanced end-of-the-day reports with credit card totals, and payment form total
(new
OpenBravoPOS Distro) Advanced
Asynchronous Integration with Author: Pedro Rozo.
(new
OpenBravoPOS Distro) Advanced
Asynchronous Integration with Author: Pedro Rozo.
Security optimized using role capabilities and removing editing functionality for data coming from the
ERP
Asynchronous logic (JMS) sending XML messages thru TCP/IP connections to an ActiveMQ
server. a fully operational embedded ActiveMQ instance (independent thread) is created within the
SmartPOS to manage a store-and-forward model. That allow to store any outgoing messages in a
local queue if the ERP when the network/server fails, once the connection come back the Activemq
Fail over + store and forward functionality will synchronize SmartPOS and AdempiereERP.
Massive synchronization: available to populate your POS databases from the ERP, this process is
usually performed by an admin user, without any customers in the POS system
Real time synchronization(automatic without any manual intervention) any time ERP information
changes an xml message is sent to updated (1-n) POS, any time POS info transactions are made
new xml messages are sent to the ERP.
Parametric configuration: JMS configuration, remote organization ERP id, reports and so on can be
configured using the resources of the pos (XML files editable with the product GUI)
Enhanced logging capabilities: SmartPOS create a new log file to record any message and error
related with the ERP synchronization process.
Advanced functionality: A customer can be created in the SmartPOS, and as a result a business
partner, location and user will be created in the ERP. (only scenario when we support creation of
data in the POS side)
(new
OpenBravoPOS Distro) Advanced
Asynchronous Integration with Author: Pedro Rozo.
(new
OpenBravoPOS Distro) Advanced
Asynchronous Integration with Author: Pedro Rozo.
(new
OpenBravoPOS Distro) Advanced
Asynchronous Integration with Author: Pedro Rozo.
(new
OpenBravoPOS Distro) Advanced
Asynchronous Integration with Author: Pedro Rozo.
With the ERP these are the main considerations to have in mind:
1. Create a company with at least one (1) organization (take note of the internal company ID and org
ID), each org ID will map each restaurant (branch) for synchronization purposes
3. Create a product category called: POS (capital letters), after that you can create you product
categories and assign the POS category as parent of yours, only those products belonging to the
product categories whose parent category is: POS will be synchronized to the POS.
Each product should have a product category whose parent category is POS, products without
these categories wont be synchronized.
Each product should have at least one (1) unit and unit conversion allowing the POS to convert
units when is selling.
5. Create customers with at least one (1) location and basic user (contact) info, location is
mandatory. All the customers will be synchronized with the POS
ERP Limitations - As many of you know, Adempiere doesnt support to assign multiple prices per unit of
measure (UOM), which is supported is a conversion factor formula that can recalculate the prices, but this
alternative for some industries like this doesnt really work, because not all the prices all proportional for
instance: the price of a cup of wine is not proportional to the price of the bottle of wine (it common to have
expensive cops of wine ), so the assignment of prices to units is mandatory.
We were checking the Adempiere ERP forums regarding solutions and workaround without much luck, so at
the end of the day the way that we solve this limitation in Adempiere was :
(new
OpenBravoPOS Distro) Advanced
Asynchronous Integration with Author: Pedro Rozo.
For the POS products we will create a price list (sell) called POS,
Next, for each Unit of Measure (UOM) we will create a price version (associated with the previous
price list ) , as price version name we will use the same of the UOM name.
Next for each product and UOM, we will populate the three prices: limit, standard and list.
During the synchronization process we will send the units and prices per product to the new tables in
the POS, and any changes in prices, and so on will be updated thru individual xml messages
managed by the model validator classes.
Finally, we spend a good amount of time creating the ERP documents that should support transactions
happening in the POS side, how is that, let me show you:
(new
OpenBravoPOS Distro) Advanced
Asynchronous Integration with Author: Pedro Rozo.
To be in sync with the Adempiere architecture and our business reality, we required an open source
Asynchronous framework/platform with support for multiple clients-server products, based in java, with multi-
platform support, fail over functionality and good development community behind; so we starting evaluating
some ESB solutions such as: Apache service mix, mule and others, but although they looked good from the
architecture and development perspective in terms our timing restrictions they didnt fit our business
priorities.
Then instead of this ideal ESB approach we decided to use Apache AciveMQ as JMS/integration platform
due to the shorter learning curve, stability and good documentation for our purpose. Let me clarify that we
still plan to design and to create some ESB connectors to replace our current approach as a long term
solution, but for now this is the way to go.
(new
OpenBravoPOS Distro) Advanced
Asynchronous Integration with Author: Pedro Rozo.
Class/Component Descriptions
MBPartner.Table_Name MBPartnerLocation.Table
MLocation.Table MProductPrice.Table
MStorage.Table MWarehouse.Table
MUser.Table MUOM.Table
MUOMConversion.Table MTaxCategory.Table
MTax.Table MPaymentTerm.Table
com.smj.util.SynchronizePOS Regular java class, called from a jms client when the
POS request a full data synchronization
(new
OpenBravoPOS Distro) Advanced
Asynchronous Integration with Author: Pedro Rozo.
We deliver solutions for distributed environments applying agile practices and open standards.
Experts with: Integration, Technical Architecture, Virtual Training, Agile multi-platform development, Open
Source Infrastructure and middle-ware .
A Canadian and Colombian company with successful projects delivered for: Panam, U.S.A, Spain,
Canada and Colombia
We have been implementing and customizing Adempiere ERP and SmartPOS for different customers such
as: cell resellers, restaurants, health and oil industries in the last year and a half. As Adempiere citizens we
are also contributing with different topics such as: eclipse project templates, Panama localization,
SmartPOS integration and soon advanced financial reporting.