New Release: SmartPOS Advanced POS-Integrated wih Adempiere

[smartjsp]

It is a pleasure to share with the open source community the availability the our first stable version available at: http://sourceforge.net/projects/smart-pos/, we have done a significant effort to improve the original OpenBravo POS, this time focused in business environments where the ERP data consistency is mandatory: transactions, ERP documents, inventory control (multiple units, list of prices (basic)), support for unstable network environments (asynchronous messaging, fail over, store & forward), and many functional enhancements and fixes for sales, reporting such as:

• Flexible design for multi-organization companies. Support to have 1 ERP (centralized) with multiple organizations(branches), and each organization with many POS stations (sharing 1 local database per organization) – ideal for restaurant chains
• Intelligent and Advanced asynchronous integration
• Synchronize most of the critical POS transactions (tickets, returns, inventory movements, payments) creating valid ERP documents in real time without manual processes
• Synchronize most of the critical data from the ERP to the POS: customer, product, taxes, list of prices, warehouse, categories, returns, countries, cities, locations, and much more in real time
• Powerful and flexible Inventory model based in ERP (Simplified) multiples prices, unit of measures and stock control
• Sales Window: Functional and GUI enhancements (tips, discounts, notes and much more)
• More Flexibility for Payments
• More secure and more control to minimize fraud (role and security analysis)
• Support complex business environments where network and server connections are unstable: using asynchronous messages, fail over, store & forward techniques from POS to ERP for real production environments
• Improved Daily reports & Auditing capabilities
• Additional Functionality to prevent fraud, maximize control and recover disaster quickly
• Enhanced Printing and Reporting
• Plus a lot of QA fixes applied to the original basic openbravo POS
• A complete list of new features is available in our wiki section.

A complete description of our new features is available at: https://sourceforge.net/p/smart-pos/wik ... tPOS10.pdf

You can get the full source code for both SmartPOS side and Adempiere (extensions and customizations) from our source forge location at: http://sourceforge.net/projects/smart-pos/

We also opened new communication channels (FAQ, wiki, forums, and documentation) there, and we will schedule local training session soon (stay tuned).

We hope the open source community enjoy our new SmartPOS release, performed by our SmartJSP development and functional teams.

Regards
Pedro Rozo
Global SOA/BPM/Java/IT Consultant
MBA/Certified Enterprise Architect for Java Technology
http://www.smartjsp.com/smartpos
Project sponsored by (http://www.xpluk.com)

[smartjsp]

New SmartPOS demo with data and setup instructions for quick evaluation and testing = SmartPOS (Open Bravo Distro) + Adempiere ERP + ActiveMQ(secure) pre-configured and ready to go for testing: see more details here: http://smartjsp.com/smartpos-demo/Smart ... nsV1-0.pdf
http://smartjsp.com/smartpos-demo/

For questions, suggestions or positive feedback please use our forums at: https://sourceforge.net/projects/smart-pos/

Regards,

Pedro Rozo

[red1]

Good effort Pedro. I merged this post to the earlier one of the same topic. Just to keep things easier to find in a single thread.

Also you must mention the apps you are integrating from particularly OpenbravoPOS as needed in each and every important document where warranted. It is not just to respect the contributors are priceless rule, but it actually helps you back when people google for OpenbravoPOS ERP integration there is more chance they hit you when more are giving you gravity. Otherwise they will find my September 11 tutorial of which I do not need any further fame on.

I will mention in my youtube, and other blogs or threads on my OpenbravoPOS work that you have done something perhaps better on it.

[smartjsp]

Sure RedHuan, I just corrected the missing references to open bravo in our documents ...

Pedro Rozo.

[red1]

Yes this is also good to avoid confusion and filter the important deals to you. Many do not understand that they got more busy when they ignore fundamental info in their work. Users ending up battering us with questions and in the end after all that answering realised that they are not interested or not our target deals.

When we provide full disclosure even to the extent of how we want the deals to contact us, those who do are will usually be our deals no matter how little as long as the rest do not waste our precious time. I see you are already doing that with training ideas which will target a certain audience. Make your users fill in a profile form to get latest news from you via mailing list etc (just an idea in case you have better ones). And you can make that automatic with auto mailers such as this forum monitors. What i mean is do not do things that require more than necessary time. You are also free to use the twitter. Just put #ADempiere in your tweet and those who follows #ADempiere gets it.

Slowly your gravity and community of users will grow. You have to nurture them with kind watering. It takes time before the twigs bear thorns and then flowers and then fruit. I been doing this since 2003. It took me a long time and yet many people still doubt me at this juncture. But i am happy to continue this passion for the rest of my life. That is why i ask if this is your team's passion first before embarking on it.

If you love it, it does not matter if you fail.

[red1]

Pedro,
Actually i got a stupid question. For once let me play the local village idiot . This is just to clear my technical curiosity.

Question:

Why is it that you made the POS as a slave to the ERP and maintain it as a standalone as it was originally capable of?

[smartjsp]

Sure RedHuan.,no problem ...We had many reasons to have the POS as an Slave of the ERP here some of them.

1. The the inventory model, of the original OpenBravo POS is very basic, no multiple UOMs for example ... and basic reliability of the process during our tests was not good (too many opportunities for fraud) calculation and synchorization issues due to different precision levels (numbers) for prices and taxes ....if a basic sync is used ERP and POS number won´t be the same.
2. So the question for us was, If we already have a stable inventory engine with the ERP , it doesn´t make sense to create/modify a similar functionality in the POS ..then. let´s use the ERP as a master source of data, and disable that functionality in the POS and use the ERP as a master all the time. That minimize the sources for fraud, keep everything in sync with the master and minimize inventory changes in the future for the new SmartPOS.
3. To avoid fraud in restaurant branches ..from a security perspective, pricing changes, new products , taxes configuration shoudl be created in a ERP first and just there... the POS stations should create transaction (tickets, returns mainly) and just update customer information but all the other information should come from the ERP .... we talked with experts in retail POS (supermarkets) and that is the way that "non smart" IBM cashiers work in big supermarkets .... the just load all the ERP info to sell and if the connection is lost the can continue selling for some time .. (there is a maximum window of time) ... once the connection return the synchronize everything .... some of them just change pricing and other info every 24 hours.. in our case is real time..

Hope that helps ---

[red1]

OK.. thanks for the good explanation. I have a few more questions from your answers that need further clarification. For now there seems to be this one below.

1. You said above about 'if the connection is lost they can continue selling for some time..". Does that mean your POS can work offline and as standalone say for an hour?

I like to say that the integration proof of concept i did on OpenbravoPOS integration is in a way also what you stressed on above about security. In fact it is exactly that. Let me explain further. As a standalone, in spite of able to enter data, it need not do so except capturing the sales orders. Thus the sending of info back to the backend ERP is just those orders that are referring to what info originally came from the ERP.

Firstly the ERP populates the POS with regard to Customers, Products, Prices, Inventory Qty according to Locators. Then the individual POS picks up these information according to each Locator. Of course this POC does not have UOM yet or even tax synchronisation but i assume this is easy to extend as the framework is already understood and i document it as much as i could in the September 11 guide.

Then during POS operations, the cashier calls up those information and produce a Sales Order but does not introduce any new information to add onto the information originally obtained from the ERP. During end of day or anytime the POS synchronise back by sending only the Sales Order information. Such information is already rich enough as it contains:
1. Order header with BPartner (customer id) which will tell the ERP who the customer is and thus can verify all its properties such as credit line (for CRM or BonusPoints redemption reconciliation).
2. Order line with order qty (product id) which will tell the ERP what inventory at which locator has been consumed and thus maintained a virtual reference of all locators end of the day.

The ERP thus remains the sole arbiter of all information and not the locator POSes. Thus fraud cannot happen more here than there at your SmartPOS. I stumbled on such a concept of one way synching (actually I was lazy to try out the replication approach which is more complex as it is two way) in a contra flow manner (i.e. one way for one set of data and not both), and realised that the ERP is the 'master' in the end and the POS locators can actually burn down without worry once they uploaded their orders to the MQServer . (Oops did i say burn down? Hmm cant shake off the violent nature of my PDF tone ).

Are these assumptions correct?

If so, then I found this same approach (though we did not discuss our development plans prior to contributing) as yours and thus it is interesting to learn how we arrive at probably a similar idea and from there can see how further anyone using either contributions can contribute further.

[smartjsp]

Let.s go slowly , and compare main differences this promise to be an interesting chat.

1. Unless you disable the normal edit capabilities of openbravo to create products...modify prices ..taxes and other local imfo you are exposed to frauud with your local posand incosistencies with the erp
2. Unless you fix and rewrite calculations to be sure that they used the same data types than erp (that means pricses, taxes, discounts, tips and so on ) and precisión ---numbers will be different .at the end of the day ...
3 and here i have a question is your synchrization happening in real time all the time as well .? .. not just in batch at the of the day. ...we have both...because in restaurant for example info changes during the day, that migth create inventory issues as well
4.uoms simple. I disagree... you can try...it was a headache .for us... anticipated ny Adaxa in openbravo we would.l like to have an active. Dictionary to propagate simple field changes to windows, security, reports, and so ...unfortunately openbravo is not like that ..it is not as easy.. there is also impact in sales window..to combine uoms with múltiple prices...and so on.. a lot of fun...and co de ....traditional java co de without a dao pattern at least
5. We can operate 1 or 2 hours with the erp down ? sur e but once the erp is back...it will propagate central inevntory numbers again in real time...no batch processs... taking the outstanding messages in each local queue .because we implement the activemq Store and forward + failover + secuirty connection between the pos and erp...
6. Lastly we fixed alot of openbravo bugs.....we added interesting functionality to manage individual and global discounts... tipps..múltiples printers..- product routing to differentprinters from the erpand much more

Finally, just want to say that we target different markets... for some people your approach migth be enought...for others with exposesition to more risk and inventory complexity migth not ....that is the beauty of open source we can solve different market needs with the same tools..


Thanks for your feedback

Pedro Rozo