Ordering Stack was designed from the very beginning as a platform that enables easy integration with virtually any POS/EPOS system (including Oracle Micros, commonly used in restaurant chains). The system features a flexible product model capable of handling most complex product types, such as combo meals, pizzas, half-and-half pizzas, half-burgers with multiple add-ons, and more.
The model is perfectly suited to be mapped onto the product models of the POS system we aim to integrate with. This document outlines how such an integration can be implemented and how data related to menus, product details, pricing, and orders flows between systems. Integration mechanisms for other areas—such as promotions or loyalty systems—will be described in a separate document.
In a typical integration scenario, there are three main areas of data exchange:
1) Menu / Products / Prices
2) New Orders
3) Statuses of Previously Submitted Orders
In our view, the best approach is to create two independent components for this purpose: Menu Importer and Local Agent.
The diagram below illustrates the data flow:
1. Importing Menu Definitions from the POS System
The Menu Importer module is responsible for retrieving the full menu definition and transferring it to the Ordering Stack platform. This module should be deployed in a location with access to the API (or database) from which product data, prices, and other attributes can be fetched. All retrieved data is transformed into JSON documents and sent to the Ordering Stack Menu API. The importer module can be run on a scheduled basis or on demand. All activities are logged in case a review of the import status is needed.
Once the menu import module has completed its task, it is possible to manually add additional product information. This functions as an extra layer of product description, overriding data imported from the source POS system. It can include additional details missing in the POS system, such as images or videos of the product, allergen information, or product categorization. Importantly, any subsequent data import from the POS system will not overwrite these manually added product details.
2. Sending a Placed Order from Ordering Stack to the POS System
The following description assumes a scenario where the restaurant uses a locally installed POS system. The Ordering Stack platform uses the POS API to transmit newly placed orders to the POS. This requires the installation of a local module (Local Agent) on a computer within the restaurant’s local network that has access to the POS API. The Local Agent establishes a connection with the Ordering Stack servers.
3. Order Status Update
The Ordering Stack Local Agent regularly polls for the status of previously submitted orders. If the status of any order has changed, the Local Agent sends the updated status to the Ordering Stack server.
Integration with Oracle Micros
Ordering Stack can operate with restaurants that have a locally installed POS system (Micros RES 3700). This works exactly as described above.
If the restaurant chain uses Micros Enterprise Manager (EM), the Menu Importer module must be installed in a location with read-only access to the EM database.
If EM is not used, one of the databases in a selected restaurant serves as the menu data source.
In the case of Micros 3700, the user must manually enrich the imported product data with additional attributes such as images, descriptions, tags, and category assignments. These manually added details will not be overwritten during subsequent imports.
Pushing orders from the central Ordering Stack system to the local Micros 3700 instance requires both the installation of Oracle Micros Transactional Services for Micros (Res POS API) and the Ordering Stack Local Agent in each restaurant.
The Local Agent, installed in the local restaurant network, connects to the Ordering Stack servers, receives all new orders, and then uses the Res POS API to inject them into the local Micros instance.
If the local status of an order changes, the Local Agent sends the updated status back to the central system.
This configuration supports all ordering channels, including web app, mobile app, and kiosks. Orders from any of these sources are pushed to the local POS system in the restaurant as if they had been entered directly at the POS terminal.
All of this is done while ensuring menu consistency and price accuracy, in alignment with the configuration of the restaurant’s POS system.
The Ordering Stack integration with Micros is illustrated in the diagram below:
Integration with MICROS KDS or Ordering Stack KDS
In the described scenario, the kitchen uses MICROS KDS, but it is also possible to implement the Ordering Stack KDS. To deploy such a configuration, ISL scripts and the SIM/PSM module must be utilized, and they need to be connected to each instance of the MICROS POS system.
- ISL (Interface Scripting Language) is a scripting language used to automate operations within the MICROS POS system.
- SIM/PSM is a technique that enables integration with external libraries and applications, extending the capabilities of the MICROS system.
For each new order, a dedicated ISL script is triggered. This script retrieves the order definition and all items on the receipt. It then invokes the SIM/PSM module, which connects to the Ordering Stack server and sends the order data. On the Ordering Stack side, the order is passed to the appropriate KDS system and processed like any other order — with the exception that it is marked as one that should not be sent back to MICROS.
Instead of analyzing the MICROS API documentation on your own, you can rely on our expertise and deep knowledge of MICROS internal mechanisms. We have been working with MICROS 3700 for over six years, and our deployments support brands such as Pizza Hut, KFC, Burger King, Starbucks, and Costa Coffee.
The system operates in environments with very high order volumes daily, demonstrating its reliability and scalability.
