Freeze Dry Australia

Freeze Dry Australia (FDA), is one of Australia’s only freeze-dried petfoods manufacturers. Based in Victoria, they provide their own food recipes in-house, as well as offering contract manufacturing for other pet food suppliers internationally. Their daily operations include receiving raw foods from multiple suppliers, safe storage of ingredients, as well as processing recipes, freeze drying, storing and dispatching stock.

The project was launched with the provision of all paper forms currently used by FDA. This included:

• Equipment Maintenance
• Daily Temperatures
• Cleaning Schedule
• Daily Batch Processing
• Batch Number Registry
• Calibration
• Delivery Record

The initial consultation was completed by viewing all paper & word documents used by FDA above, and list out each process and transpose each item of information across all forms, into a form field which can be recorded digitally. We then went through understanding the purposes of the project with the team at FDA, with what the goals of the project were. The main goal was to be able to cut down on the time spent filling in paperwork, as well as save time during their bi-annual food safety audit by automatically collating all information. Other goals included:

• Accessible across multiple devices including a PC for the office, a tablet for warehouse staff and for mobile phones if on the road and needing to query some information
• Being nationally accessible; Being able to access their data remotely for staff working remotely
• Mitigating as much risk as possible for human error by limiting and prioritising access to data

Once the goals were in place, we went ahead and provisioned the hosting plan and set a subdomain to allow the new portal to be easily accessible from a web browser. We had chosen to build the platform on WordPress due to its enormous community-driven support, its accessibility, robustness, security and flexibility. Many custom portals, CRMs and other ERP systems can frequently be bespoke-built, however once completed, are very rigid and updates/changes can be costly and time-consuming; WordPress enabled the functionality of a fully-fledged ERP system without the rigidity.

We then re-created the paper forms in HTML forms, and checked with FDA that all information was suitable and as it should be. A number of minor adjustments were made on form fields to limit potential human error, such as changing plain text fields into radio button or checkbox fields, to limit the information that could be entered in the form. Examples include changing Equipment Name on the maintenance form from a plain text field into a Dropdown field, which enabled consistency across form entries.

In order for FDA to run more autonomously with their portal, a number of supplementary forms were created which were named ‘Admin Options’. These are a more bespoke form which are a series of smaller, more basic forms, which has its entries populate fields in other forms checkboxes, radio buttons and dropdowns. So for example:

1. A new ingredient, Chicken Necks is being used for a new recipe. FDA admin staff can enter a simple form Ingredients with a single plain text field on it, called Ingredients. This form is only visible to user roles ‘Admin’
2. When staff are recording a delivery received to the warehouse, they can enter this into their inventory. The Inventory form has a dropdown field, Ingredients, which has its dropdown options populated by the Ingredients form, as well as a number field to record the quantity, and other dynamic, self-populating fields such as Date (which automatically records the current date by default), the User (which enters the logged in users username, which cannot be edited)

The project was completed using a total of approximately 800 unique fields which incorporated a number of ‘admin only’ fields to populate multi-select fields for staff.

Once the forms and all fields were created, we had to create the ‘View’ functions. These are views which enable staff to see what data is entered, and display in a user-friendly, and mobile responsive manner. The front-end views had to be a bespoke, branded solution as there is no ERP form solution which was suited specifically to the food services industry. To achieve this display, we were able to create a custom PHP script which would display form entries on a HTML webpage. From here, each form entry was assigned a series of div classes. To ensure that pages loaded quickly and that the web design of the portal was completed with W3C best practice in mind, all forms div classes used universal CSS classes. This ensured that CSS loading time was minimal, and by using the CSS @media rule, we were able to specify alternate font sizes, spacing and appearance across three different device sizes (Mobile up <600px, Tablet 601px-1000px, Desktop >1000px)

After the frontend views of all form entries were created, we had to be able to create a way of filtering information; as some entries were completed daily (Such as the cleaning schedule), whereas other forms were only entered if and when required (Such as glass/brittle plastics register). Instead of scrolling through long lists of old information, we had to be able to quickly search through previous entries when looking for information. In addition to this, we wanted to be able to create a filtering function which would be easily replicated across potential future updates to minimise future cost of updates. We were able to achieve this in three steps:

1. Creating a bespoke PHP script filter_var() which is preloaded across every page BEFORE any form entries are loaded, to validate HTML information
2. Setting the PHP filter based on a URL Parameter, which is by adding a question mark (?) after a webpage URL (Such as inventory/?supplier=suppliera&item=itemb&staff=staffc
3. Creating a supplementary form with filterable options, which does not store entries, and on form submit, will display the URL along with filtered URL parameters.

By using this method, it allowed FDA to be able to create a new form, a supplementary filter form, with no additional bespoke scripts to be built beyond the initial filter_var() script.

The last task to be completed for this project was the Audit function. The goal was to minimise the time spent running an audit and collating information for the auditor. By using the above functions and scripts, we were able to create an incredibly robust auditing system for FDA by running through the below steps:

• Create a basic webpage called ‘Audit’, which has a two field form, displaying a ‘Date From’ field, and a ‘Date To’ field
• On submission of the above form, this form submission redirects to a page ‘Audit Report’, which includes basic tables of all data entered on the portal
• The data on ‘Audit Report’ is validated and filtered, based on the entry date of each form entry. This is entries which are greater_than_or_equal_to the ‘DateFrom’ URL parameter, and are less_than_or_equal_to the ‘DateTo’ URL parameter.
• This enables FDA to be able to enter a ‘Date From’ and a ‘Date To’ to filter all form entries, which are displayed in HTML tables and filtered by date on the ‘Audit Report’ page
• On the ‘Audit Report’ page is a ‘Print to PDF’ button, which prints the audit off by using a browser PDF print script, which can then be provided to the auditor.

Once the project was completed, we ran a Pen Test on the portal to ensure there were no known vulnerabilities on the portal, and FDA was provided a copy of the Data Fidelity Security E-book to provide staff and stakeholders. The estimated project time was 70 hours for completion and we were able to complete over a period of six weeks, including a number of minor revisions and feedback from FDA on accessibility, function and appearance.