Table of Contents

POS Configuration

This section explains how POS partners should configure their systems to interact effectively with UEAT's Open API. Proper configuration ensures accurate menu synchronization, order processing, and status updates.

Overview

POS systems must be configured to align with UEAT’s data structure and operational flows. This includes mapping brand and location identifiers, setting up endpoints, and ensuring compatibility with UEAT’s menu and order models.

Below is a documentation-ready explanation you can use on the Configuration page to clearly explain how Brands, Locations, and Menus relate to each other in the POS Integration Open API. I’ve written it in a way that is explicit for POS partners and easy to map to their internal models.

Brand and Location Mapping

Instead of a strict hierarchy, UEAT uses a role-based location model.

  • There is no explicit brandId
  • locationId is the only top-level identifier
  • A single locationId may play two roles:
    1. Menu owner (brand representative)
    2. Order-fulfillment location

Hierarchy Overview

UEAT uses the following hierarchy:

Location (Menu Owner / Brand Reference)
├── Menu
│   └── Shared with other Locations
└── Orders (optional)

Location (Order Fulfillment)
├── Uses Menu from a Menu Owner Location
└── Receives Orders

Location A (menu source)
├── Menu
├── Orders
└── Shares Menu with:
    ├── Location B (orders only)
    └── Location C (orders only)

Location Roles

A UEAT locationId may be configured to act as:

1. Menu Owner Location

A Menu Owner Location is responsible for:

  • Sending menu data to UEAT
  • Acting as the source of truth for menu structure
  • Propagating the menu to one or more other locations

This location effectively represents the brand-level menu definition, even though no explicit brandId exists.

2. Order Fulfillment Location

An Order Fulfillment Location:

  • Receives orders from UEAT
  • Uses a menu provided by another locationId
  • Does not send menu data itself

A location may act as both a Menu Owner and an Order Fulfillment Location.

A Menu contains categories, items, modifiers, and pricing rules.

Key characteristics:

  • Menus are created under a specific locationId.\ This locationId may act as the menu owner and propagate its menu to other locations.
  • A single menu can be:
    • Assigned to one location, or
    • Shared across multiple locations
  • Locations can apply:
    • Availability schedules
    • Item-level enable/disable rules

This separation allows UEAT to:

  • Reuse menus across multiple locations
  • Support centralized menu management for chains
  • Avoid menu duplication when POS data is identical

Integration Guidelines for POS Partners

When configuring the integration:

  1. Identify the Menu Owner Location - Choose the locationId that will send menu data - This location acts as the brand reference for menu propagation

  2. Create or resolve Order Fulfillment Locations - Each POS store maps to a unique locationId - Locations may receive menus from another locationId

  3. Configure Menu Propagation - Assign the menu from the menu owner location - Ensure all connected locations reference the correct menu source

    If the POS Hierarchy is not compatible with this configuration, this should be discussed at the qualification session

For a Ghost kitchen configuration, see the Ghost Kitchen Use Case.

Configuration Parameters – Service Mapping

To correctly route orders and apply the appropriate business rules, POS partners must map UEAT services to their equivalent POS service or order type.

Different services (e.g. dine‑in, take‑out, delivery platforms) often behave differently in the POS:

  • Pricing and taxes
  • Preparation flow
  • Fulfillment method
  • Printing and kitchen routing

UEAT relies on service mapping to ensure that each incoming order is processed using the correct POS configuration.

A single item must not be present more than once in a menu .

Example to avoid :

{  
	"id": "I1014_1test",  
	"name": "Burger test",  
	"type": "item",  
	"prices": [  
		{  
			"service": "takeout",  
			"price": 9.49  
		},  
		{  
			"service": "delivery",  
			"price": 11.49  
		},  
		{  
			"service": "delivery",  
			"price": 11.49  
		},  
		{  
			"service": "takeout",  
			"price": 9.49  
		}  
	],  
	"availability": "available"  
}

Service Concept

In UEAT, a Service defines the operational context under which an order is placed and processed.
It determines how the order behaves in the POS: fulfillment flow, preparation logic, routing, pricing, and printing.

UEAT supports both standard services and generic services to ensure compatibility with a wide range of POS capabilities and advanced or hub‑specific scenarios.

Standard Services

Standard services represent well‑known, first‑class order types supported natively by UEAT.

Examples include:

  • Take Out
  • Delivery
  • Eat In
  • On the Go
  • Table
  • Room Service
  • Office

These services are explicitly defined in UEAT and are always sent as part of the order payload. POS partners are expected to map each standard UEAT service to an equivalent POS order type.

Example:

UEAT Service POS Order Type
Take Out Takeout
Delivery OnlineOrderingDelivery
Eat In DineIn

Generic Services

In addition to standard services, UEAT provides Generic Services.

A Generic Service is a high‑level, flexible service classification used to support:

  • Exceptional workflows
  • POS‑specific constraints
  • Centralized ordering hubs
  • Scenarios not fully covered by standard UEAT services

Generic services allow UEAT to route an order using a generic service identifier, while still letting the POS determine the exact operational behavior.

GenericServiceType

Generic services are identified using a GenericServiceType value.

  • Values 1–4
    May be used for general partner‑specific mappings.

  • Values 5–9
    Are conventionally reserved for Hub scenarios.

⚠️ Important
Generic services do not replace standard services.
They act as an extension mechanism when standard service types are insufficient or ambiguous for POS processing.

Example Generic Service Mappings

Based on the UEAT configuration page:

UEAT Generic Service POS Mapping Example
Generic Service 1 OnlineOrderingCounter
Generic Service 2 OnlineOrderingCounter
Generic Service 5 (Hub) Takeout
Generic Service 9 (Hub) OnlineOrderingCounter
Generic Service 10 OnlineOrderingDelivery

Validation & Testing

  • Confirm that each Menu POS Configuration returns the correct menu.
  • Validate that orders are routed to the correct location.
  • Test configuration changes in the testing environment before deploying to production.

Best Practices

  • Log configuration changes for traceability.

Proper POS configuration is essential for a smooth integration and reliable operations with UEAT’s platform.