3 New BlueBox PDA/Handheld Functions

BlueBox has had the addition of 3 new functions for handheld devices and PDA's.

These can be accessed via the Integration > PDA Functions module:

These functions are designed to run on a small-screen device with a built-in in-line 2D barcode scanner and will allow easy scanning of barcoded items for checking stock values, adjusting stock and receiving stock.

For the 'Receive Stock' Function there is a holding module that temprarily stores the scanned items until they are manually 'posted' into a live GRN document - this can be found in the top-menu of the 'PDA Functions' module:

Essentially this module provides access to the PDA URL which is /?pda - accessing this will launch the PDA functions:

 

Auto-adjusting Negative Stock upon GRN

When receiving stock via a GRN - Goods Received Note - in BlueBox ERP you have the option of auto-allocating the items to any Despatch Notes that have gone out within the past few hours where the stock was not available and therefore the items were marked as negative stock.

This effectively rectifies any stock that was shipped urgently before it could be recorded as received - and only happens when using the ePOS (Point of Sale) module which allows this to happen.

In order to enable this setting set the bbsetting as follows:

bb_procurement_goods_received_notes > bbsetting_grn_auto_adjust_negative_stock_within_x_hours

Set it to the number of hours prior to each GRN that you want to check for FNS Despatch Notes.
 - ie 24 would check for any DSP's that were issued within the past 24 hours whenever a GRN is captured.

Forced Non-stock (or Negative Stock) is recorded and viewed in the Forced Non-Stock Report - this report has an indicator at the top to show if the bbsetting is activated for the system or not.

When each item is auto-corrected it's value/qty in this report is reduced to zero and a link is provided to view the source GRN that performed the auto-correction. Note: these lines still remain in the FNS report so that audit trails can be done reflecting that an item was initially maked as FNS and later auto corrected.

Stopping Unwanted Page Requests

Sometimes our systems get bombarded with regular illegal page requests (probably a spider with terrible coding). In these instances it is preferable to be able to block this traffic before all the page resources are loaded.

For this purpose our Errors Module has been expanded to include an option to 'intercept and block at header' option - this is configured as follows:

The 'error message' field (normally used for part of the human-readable error message generated by system errors) is now used to specify the query_string being passed in the URL that is being used.

The 'intercept and block' setting must be set to yes:

Cron Job Manager in BlueBox

BlueBox now includes a Cron Job Manager which is a central resource for managing any scripts you want to automate in your BlueBox System.

The idea behind this tool is to provide a single point at which all regulary scripts are created and their activities and outputs are logged.

It can be found under Integration > Cron

In order to activate this module you will need to add the suggested line to the server's Cron File which will then trigger this engine, for example:

1 * * * * /usr/bin/wget -q -O /dev/null "http://www.sullycard.com/?class=bb_cron&method=run_cron&global[automate]=1"

This will run on the first minute of every hour, so your 'minute' settings (if used) will need to be 1 in order to trigger

Alternatively, use */5 * * * * to run it every 5 minutes, and your 'minute' settings can then be 0 or 5 or 10 or 15 etc

Or */15 * * * * to run it every 15 minutes etc.

It is suggested that the cron be left to run at the first minute past every hour (ie 1 * * * *) which will result in 24 ocurrences in a day.

Each time it runs it checks the list of entries in this new module and sees if it is appropriate to run each entry. Entries can be set to run on certain days of the month, days of the week, hours in the day and minutes in the hour. (Note that if you do set the value for 'minute' then your Cron File will need to be running at that minute in order for the script to trigger - so it is recommended to leave 'minute' blank and use the Cron File setting to run only on the first minute of every hour.)

Adding a Cron Job:

When adding an entry you will give it a name, and then select the class and function to run within the BlueBox System. You can also set various $global and $conf variables which will be passed to the system when it runs the function.

To restrict when your script runs you enter a combination of 

• Day of Month (1 to 31) - if set it will only run on this day each month
• Day of Week (Mon or Tue or Mon,Thu) - if set it will only run on these days each week
• Hour (1-23) - if set it will only run at this hour each day
• Minute (1-59) - if set it will only run at this minute each hour

So, to set a script to run daily at 1 minute past 3am:

And to set a script to run on Thursday and Saturday afternoons at 5 past 4pm:

 

You can enter email recipients to get a notification each time the script is run:

Lastly, you can pause a script which will stop it running while the pause is in place.

Mandrill Settings Manager In BlueBox

In BlueBox we now have a Mandrill Settings Manager which makes entering the settings required to switch to using Mandrill.com for outgoing email much easier:

Mandrill is a transactional email engine (one-to-one emails) and is the send-engine of MailChimp.com. One things that Mandrill provides is the ability to control the 'from address' validity, which you do by editing the domain settings with your domain registrar and setting up the DKIM & SPF Settings which tells the recipient mailbox that Mandrill is allowed to deliver emails 'from that address'.

BlueBox ePOS Integration with PaymentExpress PDQ/Chip-n-pin

BlueBox ePOS integrates with 3rd party PDQ/Chip-n-pin card payment solutions on a customer-requirement basis. However, we have standard plugins developed for Verifone and PaymentExpress. In this article we will run through installation and management of the PaymentExpress solution:

To enable taking card payments with PaymentExpress your till/s must have the setting for 'ccard merchantid' and 'ccard terminalid' set to 'paymentexpress'. Remember that this setting is cached when you load up BlueBox ePOS, so if you change it you will need to re-load the till-data in your current open session to get the setting loaded on the till.

You will also need to have the PaymentExpress terminal plugged in via USB into your till PC, and the PaymentExpress PC-client software installed and running as a service/tray application on the till PC.

Finally, you will need the BlueBox Websocket application installed on the till PC. This provides a vital bridge between the browser (BlueBox ePOS) and the PaymentExpress PC-client software and PDQ terminal. This can be donwloaded here and needs to be extracted into the folder c://bluebox_websocket_server (important). Once extracted into this folder follow the readme.txt file instructions to install it as a service on the till PC.

Once the above items are in place you will be ready to test out your integration with the PaymentExpress terminal.

To see whether BlueBox ePOS has detected the PaymentExpress setting as 'enabled' you can go to 'extra' > 'system' and, if enabled, a green 'Card Terminal' button will be displayed as follows:

To test the WebSocket connection click on 'Card Terminal' and you will see the card-payment interface/widget:

If the widget is gray/disabled as shown above, click on the 'Connect' button to send an 'open' message to the PaymentExpress client sofware.

If you don't get a response (spinner just spins) then your BlueBox Websocket is probably not running or has stopped. To check this you can view the Services listing on your PC to see if it is listed as 'BlueBox_Websocket_Server' - if you don't see it there then you'll need to go through the troubleshooting steps in the readme.txt file found in the folder for the websocket. If you do see it, and you still cannot connect to the PaymentExpress client software, you may need to restart/remove and re-install it.

Once you get a 'connected' message from your widget you will know that the connection is made and the two systems are talking to eachother.

Card payments and refunds are handled once you have an active sale loaded. You can capture a card payment by simply clicking on the 'Card' button while a sale is loaded, or by clicking on the Payment button and entering an amount to pay by card.

Similarly, with refunds, you simply load a 'refund sale' into the till and then click on 'Card' or 'Payment' (as described above) to make the refund onto the card.

Offline Data Management in BlueBox ePOS

BlueBox ePOS stores data offline to speed up sale processing and allow operating in non-connected times of the day.

Here is an overview of the process:

• BlueBox ePOS is a web-page which uses Javascript and an offline flat-file database to process sales without interacting with the server.
• When the ePOS page is loaded by FireFox, it checks for an offline flat-file database and if not found, tries to create a blank database.
• It then connects with the server (through a series of page refreshes) and establishes which till it is representing and which till-session it is currently running.
• If it does not find an open session it will challenge the user for an opening float and open up a new session by redirecting back to the server.
• Once a session is found and a blank offline database is created it will then start downloading the category and product info from the server and storing this offline. This is done in the background in 'pages' of 500 products and can be seen in the bottom right hand corner of the screen. (An optional optimisation setting restricts the number of products downloaded to only include the commonly sold items).
• If, while the product catalogue is downloading, a product is scanned or requested which has not yet been downloaded, the system will fall-back to searching the server for the sku_code. This also happens during the day if a sku_code is requested which cannot be found offline, perhaps because it did not qualify as a commonly sold item etc.
• As sales are made they are stored offline first, and then immeditely added to the sync-to-server queue. The queue is 'pushed' after each sale and will attempt to send the oldest transactions first. A number indicating the number of un-synced transactions is displayed just above the num/key-pad on the screen.
• If an error occurs while syncing the queue a small red counter will display just above the num/key-pad on the screen. The queue should automatically keep itself syncronised, but if for some reason ( ie data corruption of a sale etc) it gets blocked then there is a manual 'force sync' setting in the 'Sales History' section of the menu.