1. Documentation
  2. Release Notes

POS Gateway & POS Transaction API Release Notes

Getting Started
What's New
Integration Options
Authenticating with OAuth
System Status
Identity and Access Management
Single Sign-On & SAML
Outbound Federation
Federated Authentication
Troubleshooting & FAQs
Glossary
Platform
Workforce Management
Fourth Inventory for Hotels
Fourth Inventory for Restaurants

Overview

This page explains the changes that have happened to our POS Gateway specification and POS Transaction API since the beginning of 2019.

These Release Notes are up-to-date at the time of the release. Further improvements or corrections to our API documentation will normally occur in the guides and references only:

If you have already integrated with Fourth and would like to be kept abreast of API changes via email, please fill in this form.

Breaking change notification

20th August 2023

As part of its ongoing commitment to the security of its customer’s information, Fourth will be updating its platform to require all connections to use TLS 1.2 or higher from 9 January 2024. Older versions of TLS will be retired.

TLS is the encryption method used to secure communications over HTTPS. This will have no impact on SFTP connections.

31 March 2020 — HTTPS now supported for POS Transaction API

For the POS Transaction API.

The POS Transaction API now supports HTTPS connections. We highly recommend using HTTPS when submitting data using this API for both new and existing integrations.

Please note that new integrations MUST using HTTPS; existing integrations can continue to use HTTP until further notice.

7 Jan 2020 — Change to the maximum file limit size allowed

Updated the file limit to 30 MB of data of unzipped data.

If you need to load files larger than this (generally to load in historical data) please contact us. Our mutual customer can provide contact details for the Fourth customer .

11 Nov 2019 — Update to the MajorGroupDesc requirements

For the POS Gateway specification.

Updated the description for MajorGroupDesc. If your customer is using Fourth Adaco, each value must be prefixed with a two-digit number between 01-99. The numbers should be unique. For example:

  • 01-Food
  • 02-Beverages
  • 03-Retail

20 Oct 2019 — Clarification of UnitId, Converted, and other fields

For the POS Gateway specification.

Revised documentation:

  • Clarified that any times sent in should be for the transaction time, not for when a tab closed.
  • Unless otherwise advised by Fourth, please leave the UnitId field blank. Entering values in this field can cause issues with processing the data. Instead, the SiteLocationCode field should have the identifying codes for stores, cafes, restaurants or other physical locations.
  • Converted (Conv) fields must have the same values as the related, non-converted field. For example, the value of ListPrice and ListPriceConv must be the same. Note that you must still continue to include both fields.

13 Sep 2019 — Additional VOID_WASTE options, up to VOID_WASTE11, now available

For the POS Gateway specification.

New transaction type variants are available for VOID_WASTE. The list of options is now:

  • VOID_WASTE
  • VOID_WASTE2
  • VOID_WASTE3
  • VOID_WASTE4
  • VOID_WASTE5
  • VOID_WASTE6
  • VOID_WASTE7
  • VOID_WASTE8
  • VOID_WASTE9
  • VOID_WASTE10
  • VOID_WASTE11 — reserved for waste that is outside of a sale.

To support this, the DeductionDesccolumn is now required for VOID_WASTE transaction types.

VOID_WASTE is used for items that are voided after preparation, where the item reduces the stock available. An example is a cocktail that has been prepared but is returned because the customer did not like it. This void category impacts both the stock (raw ingredients used) and the labor (as someone had to prepare the cocktail).

There are eleven VOID_WASTE variants. This allows our mutual customer to differentiate between what caused a VOID_WASTE transaction. For example, they could be used to indicate:

  • VOID_WASTE2 — food or beverages voided because there was a mistake during ordering.
  • VOID_WASTE3 — food or beverages voided because the diner did not like the taste.
  • VOID_WASTE4 — food voided due to contamination from the kitchen (e.g. meat on a vegetarian pizza).
  • VOID_WASTE5 — staff meals
  • etc...

Please work with our mutual customer and the Fourth CSM team to decide the meaning of each VOID_WASTE variant.

The variants are all exported to Fourth Inventory. In the rest of the Fourth Platform, such as Fourth Analytics, the variants are aggregated to a single variant: VOID_WASTE.

18 Feb 2019 — Change to the VOID_WASTAGE transaction type.

For the POS Gateway specification.

The transaction type: VOID_WASTAGE has been renamed to VOID_WASTE.

Existing integrations can continue to use VOID_WASTAGE.

There is no change to the behaviour of the field.