Compiere from the Source

Callout for Swing and WebUI

In Compiere, you use a Java Callout for "data entry consequences" - example - you select a business partner, which then populates business partner location and user as well as other specific default values like payment terms.  Without a Callout, the system would just set the dependent values (location, user) to null.  Consequently, Callouts are essential when you want to provide easy-to-use, interactive windows.

Callouts are available for Compiere for a long time and one of the reason for Compiere's success.  The ultimate objective is to have a single controller for Swing and the WebUI with one Callout API.  At this momemnt, you need to use platform specific code to create a callout.

As a example, I will use the situation to automatocally select a revenue recognition method after you selected a product - i.e. after you enter the product, the system checks if revenue recognition applies and selects the appropriate mathod, which you the could overwrite.  Revenue Recognition e.g. distributes the revenue you cannot recognize immediate, but over time.

Data Dictionary

After logging in as System Administrator, open window "Table and Column" - navigate to the table and column you want to enable - here you find the Callout flag and the Callout code.

Callout for Swing UI

The steps to create a Callout for the Swing UI are:

• Create a class which extends CalloutEngine
• Create a method with the following signature:
  public String justAnExample (Ctx ctx, int WindowNo, GridTab mTab, GridField mField, Object value, Object oldValue)
• Enter the fully qualified class.method name in the Data Dictionary Callout code for the column 

The business logic you provide here should be repeated on the model level to have the same experience/behavior if you were to enter/modify a record manually via UI or via API.

There are many examples for callouts in Swing - check classes like CalloutInvoice for a bit more complex logic or the class CalloutUser for basic information.

Callout for WebUI

The objective was to have all functionality in the model class, so you would just add a special setter method - example from MConversionRate:

@UICallout public void setMultiplyRate (String multiplyRateOld, String multiplyRateNew, int windowNo) throws Exception
{
  setMultiplyRate(convertToBigDecimal(multiplyRateNew));
}

You would then just convert the String to the correct data type using a static method and call a standard method.  This way, there is no need to replicate functionality on the model level as this is executed on the model level.

To enable the callout, you just select the Callout flag for the Column in the dictionary.

This approach is easy, if you are the owner of the object. If you want to extend an existing class, you have two options:

• If you create a component, you just enter your model package in your entity type and create in there your extension in your package - example:
  public class MOrder extends org.compiere.model.MOrder
• Use an external class (details below). You may want to select this option, if you don't want to create your own extension, e.g. because another component is alreay doing that - or becuase the change is simple

To create an external [external to the model class] WebUI callout, you just create a method in a class with a parameter-less constructor and add the fully qualified class.method name in the Data Dictionary Callout code for the column - example:

public void justAnExample (PO po, UIField field, String oldValue, String newValue)

Note that you can use the same class.method name for SwingUI and WebUI - here compiere.model.CalloutUser.justAnExample - as the parameters are different, it is easy to differentiate and allows to have the code in the same class. Note that you should use the ModelValidator to replicate the logic for the model level to achieve the same behavior via API.

Accounting Schemas and Default Accounts

In Compiere the accounts used for posting the accounting consequences of any document are defined as default accounts in the Accounting Schema.  A tenant may have multiple accounting schemata (one reason for this would be to have parallel accounting currencies).  This is to ensure that all necessary accounts are present and avoid any posting errors because required accounts are not provided.  It also means that  the person entering the document (e.g. Invoice) does not need to have any knowledge of how the accounting is done or at what level.

During Initial Tenant Setup the user provides the default accounts as a .csv file to the process.  The first (and therefore) primary Accounting Schema is created using these default accounts.  If all the default accounts are not provided then the Initial Tenant Setup process will fail.  The default accounts are then copied to the appropriate entities when a new entity record is created.  For example, when a new Business Partner Group is created the default accounts are copied for each Accounting Schema defined.  Then, when a new Business Partner is created, the default accounts are copied from the Business Partner Group selected for the Business Partner.  When a new Bank Account is created, the default accounts are copied from the Accounting schemata (as there is no intermediate entity like Business Partner Group).  For all entities with an 'Accounting' tab, records are never added to this tab.  The user can modify the default account values but cannot change the Accounting Schema. 

Web Store Management

Compiere can easily link to third party web stores, and also provides self-service and web store functionality.  In addition to the web store functionality of viewing and buying products, Compiere provided comprehensive account management functionality.  In addition to address management, the customer or vendor can view their orders, invoices, shipments / receipts and payments, pay any open order/invoice or create pre-payments as well as enter/manage (customer service) request.

To set up the web store, you need to configure the mail server (Compiere also supports TLS) and the credit card processor (support PayFlowPro out of the box and can be easily extended to support Authorize.net or any other payment processor).  We also recommend you set-up Apache as a front-end server for ease of security management security and access.

For ease of customization, the Compiere web store uses Java Server Page (jsp) technology designed to work easily with any browser.  The first level of customizations are cascading style sheets (css).  Prepackaged are three style-sheets: gardenworld.css, compiere.css, standard.css, but you could also reference any external style sheet.  This is done in the web store definition window in the application. There you also determine what functionality to expose (like Request for Quotation, Requests, ..) and what logo to display.  Here are also some additional options to add text or links in different predefined regions of the web store layout.

The next level of customization would be to modify the the jsp files.  Some reasons for this type of customization would be to change the content and sequence of the individual fields.  Example: show the available quantity of a product or to show a flag "in stock".  To do this, you would use the compiereWebStoreBase.war file in the /lib directory in the Compiere home.

The deployment of the web store is done during setup.  When executing RUN_setup, the compiereWebStoreBase.war file is then combined with the appropriate code file and the compiereWebStore.xml file to the compiereWebStore.ear file and automatically deployed to the application server.

Compiere support multiple tenants. So how can you create multiple web stores for a single Compiere instance?