WonderPOS Developers Guide

 Please give your Impressions on the developers guide..

Overview of the system

A point of sale system for retail trade. Supports ESC/POS ticket printers, customer displays and bar-code scanners.

It uses a relational database as its persistent storage. HSQLDB is used by default but MySQL, Oracle and PostgreSQL are also supported.

It allows for the creation of multiple user accounts. Accounts are assigned roles in order to determine their capabilities. You can have as many roles as you need, but the default ones are Administrator, Manager, User and Guest.

The main application window is focused on the sales operation. The interface is designed to operate with a touchscreen so that a keyboard and mouse are not required for normal operation. On the other hand, it is possible to interact fully with the application using a keyboard and mouse without the use of a touchscreen.

The restaurant management features includes a visual display of tables which includes a visual cue to indicate which tables are occupied or free. It is easy to set up this layout to correspond to the physical layout of the restaurant.

There are administration options to manage users, set passwords and configure other aspects of the application.

There are management options to make closings, to manage products and to manage the organization of products into categories. It has reports and charts of products, closings and sales.

DBSourceManager

DBSourceManager is a java library that helps with database tasks related to development. Its most important feature is database independence. You will be able to focus in the development of database features and let DBSourceManager deal with the database implementations details.

DBSourceManager is based on DDLUtils and the database model used by DBSourceManager is an extension of the model used by DDLUtils. DDLUtils supports a large list of database engines but all the extensions created in DBSourceManager only work for Oracle and PostgreSQL.

The main goal of DBSourceManager is to aid the developer in the creation and maintenance of Database physical objects and data. The way this works is via an array of XML files which represent database physical objects, or table records. DBSourceManager contains utilities which allow the developer to export its objects into this XML files, and which allow modifications into these XML files to be moved into the database by updating it.

Therefore, the developer can focus on creating and changing its components (either in the database or in the XML files), and DBSourceManager can automatically move the changes in either place to the other.

Scripting Language

The scripting capabilities this release offers has the following benefits:

Simple scripting language very similar to Java and easy to learn.

No need to compile the POS. You only need the binary package.

Powerful object model. When writing a script for the POS you have access to all the POS objects methods and properties, and access to all the Java API.

Automatic deploy to all POS terminals. You only have to create the scripting functionalities in one terminal and all terminals connected to the same database will automatically use the scripting functionalities created.

Security. The execution of scripts is role based. You can allow or deny to execute scripting functionalities based on the user's role.

POS ERD

Wanda POS

Wanda POS is a fork of openbravo pos from version 2.30. It is different in that it comes with free Products and orders Synchronization buttons which are linked to the Idempiere ERP. This fork is meant for large business with multiple sales stations as it enables data asynchronously synchronization from a central source. Without a backend, it will be limited and poor in its data environment.

Wanda pos is a standalone application which is written in java. It has as backend database Postgresqul,Oracle,Derby,Mysql. When the system install in creates a database with the following schema.

The two tables that store the sales are:

   TICKETS (TICKETID, DATENEW, HOST, PERSON, PAYMENT, MONEY INTEGER)
   PRODUCTSOUT (TICKETID, TICKETLINE, PRODUCT, UNITS, PRICE)

One sale is one record in the table TICKETS and one or more records in the table PRODUCTSOUT.

POS Synchronization

The ERP Application or server can be entirely remote to the POS or be anywhere in the world that has broadband Internet access. As long as the POS and ERP system are connected to a web-enabled line, we have a perfect operational environment.

The ERP can also allocate each POS station as a virtual locator in its Warehouse Locators network

There is real-time synchronous web services as well as offline asynchronous messaging mechanisms. In our integration we took the asynchronous approach. Below is a class diagram that shows an overview of the synchronization:

How it works

We will be using JMS for integration to Idempiere and we will be using Apache's ActiveMQ implementation of it. The adapter class is MQClient. Now, with ActiveMQ or messaging technology even the POS can update without the ERP end to be up. As long as the ERP has deposited or updated the ActiveMQ (message queue) service which is somewhere else, again even remotely situated with its own web access. The ActiveMQ service from the Apache project is a MOM or message-oriented middleware. ACTIVEMQ has its own Derby database that can store the messages queue and when it is turned on again, its messages are still there.

That is called persistence. This allow the service to experience disruption or stopping due to electrical outage. If it has booted up again, it won’t need to be updated again by either the POS or ERP end. However that persistence option is controllable as some messaging strategies may not want persistence. At the moment we have turned it on within the code. Reason been that many POS stations may take a longer time to access it.

It uses the port 61613 (which is different from the JMS port) for Stomp-based communications. In order to send and receive messages using the Stomp protocol, the Java application must use the Stomp APIs provided by ActiveMQ.

Note that

queue-host could be at the remote jenkins.idempiere.com.
The pos locator name is set to “HQ Warehouse”.
IDempiere will produce the messages in its data model format.
IDempiere will consume the messages from Wandaa in its data model format.
Wandaa will consume the messages from IDempiere and convert it into its data model .
Wandaa will convert its data model to IDempiere and produce the messages for Idempiere .
All the messages will be represented in an XML format.
The producer code will put a message on the queue and exit.

In order to have the integration working, we are producing/consuming the data in the following XML format:

   <?xml version="1.0" ?> 
   <entityDetail> 
   <type>entity name</type> 
   <detail> 
   ..... 
   entity specific detail 
   ..... 
   </detail> 
   </entityDetail>

Coding rules

Java standards.