The POS generates a number of events at various stages of processing. You are able to handle these events to control precise behaviour. For simple changes, you can handle the events in PosScript. However, larger and more complex handling is sometimes better handled in a high level language. For example, PosScript cannot easily read external databases or create network links, while the TTF interface can.
Registering to Receive Events
In your INIT call, encode the event numbers you wish to receive.
// ************* Build my registration call FieldpinePacket Reg = Fdl.NewPacket("INIT"); // Set overview information about this program Fdl.SetString(Reg, FIELDPINE_REGISTER_COMPANYNAME, "Your Company Name"); Fdl.SetString(Reg, FIELDPINE_REGISTER_VERSION, __DATE__ " " __TIME__); // Set that we are capable of talking to multiple processes, not just one Fdl.SetInt(Reg, FIELDPINE_REGISTER_APP_TYPE, MULTIPLE_USERS); // Set the parameter saying we are wanting to do pricing for everything // This will be called a lot, every modification, however small, to the items being purchased Fdl.SetInt(Reg, FIELDPINE_REGISTER_HANDLE_EVENTS_SYNC, FIELDPINE_EVENT_PRICE_ALL_SALE); // Change the above to list the events you are interested in. // You can register for multiple events but you must explicitly name each event you want // Send it to the POS and release the memory Fdl.SimpleSend(Reg); Fdl.FreePacket(Reg);
Sending and Processing Events
When the POS calls your event handler your code needs to respond quickly. You are being called while a retail sale is in progress and the operator will be scanning and weighing items rapidly, often without watching the screen.
When an event is sent to TTF applications, the following logic is used.
- The POS reaches a point where an event can be sent. It checks to see which TTF interfaces are online and builds a list of those interested in the event.
- It creates an EVNT packet and sends this, in parallel, to all handlers wishing to receive it
- Handlers can register as sync or async, and include a wait timer.
- The POS will wait up to "wait timer" for each sync registered event. Your code is expected to respond inside the timer window you specified.
- If you do not respond, the POS will continue processing. If you are not going to respond, such as ignoring this event, you should send an empty response (for sync handlers) to stop the POS from waiting.
- If you are an async handler, the POS will not wait.
A sync handler is one that requests the POS pause while this processing is undertaken. Or where the handler will always be responding. The event "can I add xyz to this sale?" would typically be a sync handled event as the POS needs to know the answer now.
An async handler is one that can allow the POS to continue internal processing. The event "Set line price" can be async if you wish. Prices on lines can be changed by your interface at any time so you can respond later.
When an event is sent to a handler it includes reference information (request id and request RVV). This information allows the POS to know when and where the event was sent to you. You can respond later than your timeout window and the POS will check to see if this response is still acceptable or it conditions have changed. Consider the following flow
- The teller scans product 123 and adds it to the sale with price $2 each.
- TTF fires an event to your code, but for some reason your code does not respond immediately
- The teller scans product 456 and adds it to the sale.
- Your event handler now responds saying "price of 123 should be $1.50 each"
The POS is able to determine that the event you are responding too is still valid for the first saleline (product 123) and so applies it.
Do not assume that you will receive all events, you should but do not design around requiring it. Treat each event as standalone. Do not cache information from one event to another, there is no guarantee that the overall state of the system has not changed between seperate event calls.
An event packet has the packet type "EVNT" and has a standard talk to Fieldpine header.
|f110||RequestId||A unique token identifying this request|
|f111||Request RVV||A sequence identificaiton value that is used to mark the state of the system when this event was generated|
|f120||EventNo||The event number being sent in this packet|
A reply packet has the packet type "REEV" (REply to EVent)
|f200||Command||A reply status indicating main action to be taken. Events that allow a handler to specify yes/no operation return the overall command in this field. 1=Yes, 0=No|
|160||FIELDPINE_EVENT_PRICE_ALL_SALE||Called after sale modifications are almost fully completed and allows your handler to adjust the prices based on the whole sale state. You should only use this event if your pricing is dependant on different lines, such as kit handling.|
|200||FIELDPINE_EVENT_SALELINE_PRE_ADD||The system is about to add an item to a sale. This event can block this from occuring.|