Menu item types classify each item in R365 as a Menu Item, Modifier, or Unknown based on how that item appears in POS sales ticket data.
Every menu item carries a type that shapes how R365 manages depletion rules for that item. The type reflects whether an item sells as a primary ordered item on a POS ticket (called Menu Items, such as a bacon cheeseburger) or as an add-on or adjustment to a main ticket item (called Modifiers, such as extra cheese, no bacon, add avocado). Unknown items are menu items whose sales pattern has not yet produced a clear type from available sales data.
Type is assigned automatically by the system during migration from existing POS sales history and from incoming POS sales tickets after migration. All menu items, including those created manually, remain Unknown until POS sales ticket data provides a clear type. If a menu item or modifier has a clear parent / child relationship, it will import as its correct type.
When menu items and POS items are classified, it ensures that sales, recipes, and menu item reporting maintain accuracy. Additionally, this helps menu admins manage depletion accurately and interpret the state of items on the Menu Items page.
Menu Item and Modifier Types
Menu Item and Modifier are the two resolved types in R365. Both types support full depletion rule management. The system assigns these types automatically from POS sales ticket data. No manual type selection is available.
Menu Item is the type for an item that sells as the primary ordered item on a POS ticket. At the point of sale, a Menu Item-type record appears as the main item on the ticket rather than as an attachment to another item. The system determines this by comparing ticket data fields at migration and from ongoing sales tickets.
Modifier is the type for an item that sells as an add-on or customization attached to another item on a POS ticket — for example, a sauce, a size selection, or a topping. The system distinguishes a Modifier from a Menu Item based on whether the POS ticket record places the item as a child of a parent item.
Important Note About Naming Rules
A modifier and a menu item cannot share the same name. The system treats same-named records as the same item regardless of type, and prevents duplicate names across types.
On the Menu Items page, the Type column appears in the table and shows the type of each item. The type also appears in the record header when viewing an individual menu item record.
How Type Is Assigned
Type is assigned automatically by the system through two paths: during migration from existing POS sales history, and from ongoing POS sales tickets after migration.
During migration
The system looks back at the last 30 days of POS sales ticket history to determine the type of each existing POS item. For each item, it evaluates whether sales tickets consistently show the item as a primary ordered item, consistently show it as an add-on to another item, or show a mix of both patterns:
Consistently appears as a primary item across the 30-day window → type is set to Menu Item
Consistently appears as an add-on across the 30-day window → type is set to Modifier
Appears as both primary and add-on across the 30-day window → type is set to Unknown
No sales ticket history in the 30-day window → type is set to Unknown
The linked menu item's type is set to match the POS item's type. Menu item IDs do not change during migration, and existing sales tickets remain linked to their original menu item records.
Type-based depletion accuracy begins at the migration date. Historical sales data is not recalculated after migration — sales recorded before migration continue to reference the original menu item without type-based depletion adjustments.
From ongoing sales tickets
After migration, the system evaluates each new incoming POS sales ticket and assigns or updates menu item types accordingly. This includes menu items created manually after migration — those items remain Unknown until the first POS sales ticket linked to them arrives and provides a clear type. When a ticket's type signal conflicts with the current type on an already-resolved menu item, the system follows the transition logic covered in Type Transitions.
Unknown Menu Items
Unknown is a system-assigned type that indicates R365 cannot determine a clear, consistent type for a menu item from the available sales ticket data. An item with an Unknown type is a valid state the system uses to maintain depletion continuity while the type remains unresolved.
System-managed depletion rules on Unknown items
When a menu item's type is Unknown, the system automatically creates two depletion rules for that item under the hood to cover both possible type states. These rules are not shown in the UI — the record displays the standard recipe picker instead. Depletion continues accurately regardless of how the item is sold while its type is unresolved.
Resolving the Unknown state
The Unknown state resolves automatically when a sales ticket arrives with a clear, non-conflicting type data. No manual action is required to trigger resolution. When earlier resolution is needed, the following option is available:
Split POS items: Remove one POS item from the menu item and link it to a different menu item. When same-named POS items point to different menu items, the system no longer attempts to auto-link them together, and the conflict source is removed.
Type Transitions After Menu Item Migration
After migration, the system updates menu item types dynamically as new POS sales tickets arrive. When a sales ticket contains a type that conflicts with the current type on the linked menu item, the system's response depends on the complexity of the depletion rules already on that item.
When the menu item has a simple rule:
A simple rule has exactly one condition (either "if menu item is [name]" or "if modifier is [name]”). When a conflicting ticket arrives and the menu item has a simple rule, the system links the new POS item to the same menu item, transitions the menu item's type to Unknown, and automatically adds the second system-managed rule.
When the menu item has a complex rule:
A complex rule has more than one condition or is one of multiple rules on the same menu item. When a conflicting ticket arrives and the menu item has a complex rule, the system creates a new menu item of the appropriate type with no rules defined. The existing menu item is not modified.
The type transition cycle:
Once a menu item is in the Unknown state with both POS item types linked, subsequent sales tickets can briefly resolve and re-enter the Unknown state as the cycle progresses. The cycle continues until the following user-initiated breakpoints is reached:
Split POS items: Remove one POS item from the menu item and link it to a different menu item. Existing logic in R365 prevents same-named POS items from being auto-linked once they point to separate menu items, stopping the cycle for this item.
The type transition cycle does not result in data loss. Menu item IDs and their historical sales ticket associations are preserved throughout the transition process. Type changes apply going forward from the point of the transition.
R365 Best Practice
R365 recommends that if a menu item has been in an Unknown state for an extended period, review the POS item linking on that record. Items where a single name maps to both primary and add-on sales patterns often benefit from being split into two separate menu items (one of each type) for cleaner depletion tracking.