Retail:Developers Guide/DataAccess/Sales order processing and saving
Contents |
Introduction
The Openbravo Web POS main function is to allow the user to generate sales orders. Each "ticket" is actually a sales order, and it needs to be generated as such inside Openbravo. Thus, the Openbravo Web POS includes a sophisticated process which does just that.
Synchronization of orders
When the Web POS is operated, the user can generate tickets. These tickets are stored as sales orders inside the local database, in the web browser. When a ticket is paid, it is considered as "completed" from the POS point of view, and it can be sent to Openbravo.
If the POS is online, the tickets are then automatically sent to the backend. The backend then executes the ProcessOrders process, which essentially creates the Sales Order, and all associated documents (the Shipment, optionally the Invoice, and the necessary Payments) in Openbravo, and updates all necessary information (such as the stock for the affected products).
If the POS is offline, the tickets are stored in the local database until the connection is restablished. At that point, all the paid tickets which are pending to be sent, are sent to the ProcessOrders process, which processes them in a batch.
Documents and other data generated by the process
When a ticket is sent to Openbravo, several documents are generated there:
- The Sales Order: Obviously, a sales order is generated for the ticket. This sales order has exactly the same lines which the ticket has, for the same products, prices and taxes.
- The Shipment: : A shipment is generated for the sales order.
- The Sales Invoice: An invoice is generated if the user chose to invoice the receipt. This invoice lines which are virtually identical to the lines in the order.
- Payments: The process automatically generates the payment information and processes the payments.
- Stock: The process also automatically updates the stock of the affected products.
Performance of the process
This process has been designed with great care, to ensure that it has the best possible performance. Therefore, it can import orders several times faster than the old processes which were used to import orders from the old Openbravo POS versions. All extensions of this process should carefully consider every possible performance implication. The performance of this process is considered critical for the overall performance of a moderately large Openbravo retail installation.
Extending the ProcessOrder process
The process will automatically detect order attributes added by extensions to the Openbravo and Web POS modules, taking them into account when saving the order and all associated documents. Moreover, this process has been implemented in a way that is easy to modify and extend by developers.
Additional attributes and the ProcessOrder process
If a module extends the Order model (or any associated documents) adding new properties to the entities (ie. more columns to the database tables), the process will automatically detect and populate those properties. No other action needs to be taken by the developer.
Extending or modifying the behavior of the process
There is currently only one way to modify the behavior of the OrderLoader process, which is to add a hook to the main process.
Adding a hook to the main process
This method only requires the developer to add a Java class, which implements the OrderLoaderHook interface:
@ApplicationScoped public class OrderLoaderHookTest implements OrderLoaderHook { @Override public void exec(JSONObject jsonorder, Order order, ShipmentInOut shipment, Invoice invoice) throws Exception { // TODO Auto-generated method stub System.out.println("somebody is calling me"); } }
This interface contains a single method, which will receive the order, shipment, and invoice objects which have been created by the OrderLoader process. You are then free to modify those objects however you need.
This class will be automatically added and executed at the end of the order creation process.
Extending the OrderLoader process
In previous versions of Retail (earlier than 15Q3), it was somehow possible to also extend the OrderLoader class (although there were several problems, mainly in the way errors were handled). This is no longer possible at all, and classes which extend the OrderLoader will not be used by the Web POS synchronization process.
Back to Concepts