Menu Schemas

Full schema descriptions can be found here

Both menu schema types share the following:

• Schedule Management: Detailed weekly schedule support with multiple time slots per day
• Holiday Handling: Flexible holiday definitions with recurring and specific date options
• Tax Management: Global tax definitions with item-level application

Menu Schema V1

Overview

The V1 menu schema implements a straightforward, hierarchical structure for representing menu data. While intuitive and easy to understand, this schema can be memory-intensive due to its nested approach and potential data redundancy.

Schema Structure

Core Components

The schema consists of several key entities organized in a hierarchical structure:

DspLocationMenuEventDataDto
├── Menus[]                # Top-level containers
├── Categories[]           # Groups of related items
├── Items[]                # Individual products
├── Variations[]           # Different versions of items
├── ModifierGroups[]       # Customization options for items
├── Modifiers[]            # Specific modifications
└── NestedModifierGroups[] # Nested customization options

Key Features

1. Direct Object References: Each entity (menu, category, item, etc.) contains its complete data structure
2. Nested Hierarchy: Follows a natural menu organization pattern
3. Self-Contained Objects: Each object contains all its relevant data without relying on external references (except for tax IDs)

Data Organization

• Menus: Top-level containers that include categories and scheduling information
• Categories: Groups of related items (e.g., "Appetizers", "Main Courses")
• Items: Individual products with variations and modifier options
• Modifier Groups: Customization options for items
• Holidays & Taxes: Stored at the root level for global access

Memory Considerations

Memory Intensive Aspects

1. Data Duplication: Common modifiers or variations may be repeated across multiple items
2. Deep Nesting: Complex items with multiple modifier groups and nested modifiers create deep object structures
3. Complete Object Storage: Each entity stores its full data structure, leading to larger payload sizes

Use Cases

This schema is well-suited for:

• Simple menu structures
• Small to medium-sized menus
• Scenarios where direct access to complete object data is prioritized over memory efficiency
• Development environments where memory optimization is not a primary concern

Additional Features

• Pricing: Supports multiple currencies and price points through variations
• Modifier Rules: Configurable rules for modifier selection and pricing

Implementation Notes

• All monetary values are stored in lowest denomination (cents)
• Currency codes follow ISO 4127 standards
• Time slots support overnight hours (crossing midnight)
• Tax rates can be marked as inclusive or exclusive

Menu Schema V2

Overview

The V2 menu schema implements an association-based structure that significantly reduces payload size through the use of references and centralized data storage. This schema introduces important optimizations and new features like modifier price overrides, while maintaining all the functionality of V1.

Schema Structure

Core Components

The schema uses a flat structure with associations:

DspLocationMenuEventDataV2Dto
├── Menus[] # Top-level containers
├── Categories[] # Centralized category definitions
├── ItemFamilies[] # Groups of related items
├── Items[] # Centralized item definitions
├── ModifierGroups[] # Centralized modifier group definitions
└── Modifiers[] # Centralized modifier definitions

Key Optimizations

1. Reference-Based Associations: Uses IDs to reference related entities instead of nesting complete objects
2. Centralized Data Storage: Stores each entity type in its own array at the root level
3. Reduced Redundancy: Common elements are defined once and referenced multiple times

New Features

Modifier Price Overrides

A significant enhancement in V2 is the ability to override modifier prices based on context:

1. Item-Specific Pricing: Modifiers can have different prices when applied to specific items

   • Example: Adding cheese might cost more on a large pizza vs. a small pizza
   • Implemented through ItemModifierOverride array
   • Maintains price consistency with size variations

2. Menu-Specific Overrides: Items can have different prices and availability in different menus

   • Controlled through type MenuSpecificItemOverride
   • Supports price variations across different menus
   • Includes activation control on a per menu basis (is_active)

Item Families

• Introduces the concept of item families for better organization
• Groups related items with shared characteristics
• Contains common attributes like:
  • Description
  • Images
  • Modifier groups
  • Tax assignments
  • Alcohol designation

Data Organization

Hierarchical References

1. Menus reference Categories (category_ids)
2. Categories reference Item Families (item_family_ids)
3. Item Families reference:
   • Items (item_ids)
   • Modifier Groups (modifier_group_ids)
4. Modifier Groups reference:
   • Modifiers (modifier_ids)
   • Override Rules for specific contexts
5. Modifiers can reference nested Modifier Groups (nested_modifier_group_ids)

Override System

• Item Level: Modifier price overrides based on specific items (ex different item sizes)
• Menu Level: Item price and availability overrides per menu (ex dinner menu has higher prices than a lunch menu)
• Modifier Group Level: Rule overrides based on parent context (ex Some items may have rule set of max modifiers allowed)

Memory Efficiency

1. Reduced Duplication: Common elements stored once and referenced
2. Flat Structure: Minimizes nesting depth
3. Efficient Updates: Modifications to shared elements automatically reflect across all references

Implementation Considerations

• All monetary values remain in lowest denomination
• Maintains ISO 4127 currency code standards
• Preserves V1 functionality while adding new features
• Backwards compatible with appropriate data transformation