Programming Overview

The Fieldpine Point of Sale system is an advanced highly customisable retail system. Customisation is optional and not required unless you want to alter the system operation. Almost every aspect of the system can be customised to allow full control and implement business specific logic. When we talk about "programming" in the Fieldpine system, this can range from simple visual changes for end users to writing complex handlers in low level languages.

The POS Engine provides the central control and also base functions. This essentially "is" the POS, with user interface screens and backend databases being used and controlled by this engine. The engine takes control of many of the key parts of a retail system including sale handling, auditing, integrity, automatic updates and the many other things that are involved. POS systems are much more complex internally than they appear.

The following is the range of areas that can be customised

Area	Usage	Details
UI Screens Checkout appearance and operation	Very Common	Alter UI files (text files) that contain commands to create and control screens and operational flow. Can also use embedded HTML and Javascript if you prefer Use XML definitions for popup data entry screens
Business Logic Checkout level operating controls	Quite Common	Use configuration menus for common config needs Write PosScript to override specific events during sale processing Write "C" event handlers to access more advanced event handling Use Talk To Fieldpine Interface for complete standalone interfaces
Hardware Interfacing Connecting retail devices to retail counters		Use Talk To Fieldpine API and write in any language
Mobile Apps		Write App and interface to eLink API. Use RetailAPI for customer level Apps
Custom Reports / Webpages	Common	Write HTML and Javascript report inside Gds or POS. Has access to all retail data Use eLink API to extract/upload data to other systems Use Excel Addin and retail formulas for adhoc reporting
Connecting eCommerce Website	Often	Use preselected click/configure interfaces Enable website to understand eCommerce interface Use full eLink API
Custom API
Messaging Control
Database Interface	Rare Advanced	Provide your own database interface DLL to integrate to non standard database engines
Function Replacement	Rare Advanced	Provide replacement code to override internal functions
Data Extraction	Common	Read exported database tables directly Write to supported tables for direct loading Use eLink API to extract/upload bulk data to/from other systems Use Head Office Events or eLink firehose API to get realtime data notifications
Support Integration

Internally, the POS application can be viewed as a giant state engine. Active sales exist and these are altered by the various of actions of the salesperson, and these actions in turn affect the internal sale and also future actions that can be taken. The illustration shows the broad overview of internal operation.

Green Stars indicate primary places the POS will be customised.

Yellow Stars are more advanced customised points used for advanced extensions or extending the system by ISVs

The User Interface defines how the system looks and feels to the user. These are written using a simple declarative system. This is a reatively high level abstract, you define that you want a "button" and how what it should do when pressed. This "action" will usually issue PosCommands or call PosScript to affect the Pos Engine. A button defined on a User Interface, when pressed, might issue the PosCommand "sale(add(...product details...))"

PosCommands is an interpreted control language that can affect many aspects of both the POS Engine and the User Interface. It abstracts away how something is done and provides a reasonably readable syntax of retail operations.

Pos Scripts are a more complex form of PosCommands that include flow control and some limited ability to call subroutines. Pos Scripts come in two types

1. Pos Commands and control structures
2. Mini "C" dynamically compiled and executed C programming language.

As the POS Engine processes commands it fires a number of events which can be caught and executed by your scripts. These range from simple handlers ( I am adding a new product to a sale ) to very advanced ( A hardware error has been detected ). You can override those events that are of interest to you.

At any time, the reference data and historic information can be accessed from the "data" space. This is a single call to retrieve information. This can be considered much like a database, but without needing to know exactly where data is stored. The data space contains both static reference information (eg product[23].description ) and dynamic information (eg activesale.customer.name ).

With the data space, you do not need to know where or how to retrieve information, eg the request for "activesale.customer.lastsale.date". Take the currentsale (activesale), select the customer being sold too, find their previous sale, and return the date this sale was performed. The retrieval automatically knows to avoid cash sale records, and obeys security policies.

Frequently Asked Questions

Is the POS Engine Open Source?

The main POS engine is closed source and the disadvantages outweigh the advantages at this time. The complexity of some operations coupled with the extreme diversity of retail operations might mean that the engine becomes too divergent in operation. We provide advanced hooks and programming APIs around the engine to cater for customer requirements.

Most retailers asking this question are usually asking for different reasons than truely wanting open source, some questions below may also be of interest.

In case of business failure (and we have been in this business for over twenty years and aren't funded by VC capital), source code would become available if no viable alternative was possible.

How stable is the POS Engine?

Very. We have businesses that are using 10+ year old versions of the code without issue. The engine itself is constantly changed using a continuous development process, but is carefully controlled with automated regression testing and other controls. The programmers know which areas are safe to change rapidly and which areas require full testing. The code also has a large number of control-gates so that new logic is usually disabled unless specifically enabled.

Is the POS Engine Free?

There are free versions for smaller retail operations, but in general a payment is required. This is changing constantly as we move towards a more "app" like structure and allow cloud backends.

Describe the POS Engine Code

The main POS Engine is largely written in C++, with some components written in alternative languages. The code base runs to several million source code lines. You can use whatever programming language you wish to interface to the system.

On the web side we tend to use native Javascript and HTML/CSS. Again, you can freely install and use any frameworks you wish.

Can I run on Linux, ASM.js etc?

The technical POS Engine itself currently requires Windows. A store often only requires one "Pos Engine" and you can use Linux or web browsers or Mobile Apps to communicate to this store server.

There was a Linux port created but this was dropped due to lack of retailer interest.

We cannot yet port the complete Pos Engine to ASM.js as the engine requires functionality not yet available in ASM.js

We can interface to Node.js

Parts of the PosEngine are being migrated to Android and libraries for retailers to create their own Apps are in the pipeline

Can I write my own POS using the PosEngine?

Yes. Some retail operations are too specialised for general purposes systems, but the cost of developing and maintaining a Retailer Specific POS can be high. There are a number of ways you can create your own POS and use the Fieldpine Engine to provide many of the harder, more risky or mundane aspects. Using the Fieldpine Engine implicitly gives you access to more devices and possibilties in the future.

The range of programming options ranges from simple changes all the way to complete "write your own program" type level.

Options exist for large retailers who wish to have dedicated staff at Fieldpine

Can I white label the POS or sell my customisations?

Generally speaking, you can release your modifications however you wish, but must not imply that Fieldpine endorse or support your application. The end customer still need to be running valid Fieldpine environments and licensing.

In a similar vein, if you have written an interface to a device or common 3rd party application you may sell these.