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
- Pos Commands and control structures
- 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.
