How to configure your Enterprise in Micros Simphony?
Micros Simphony (1) is often described as an “Enterprise” level Point of Sale system, but what does that mean? While Micros Simphony can be used to run a small coffee shop or corner restaurant, it really shines in multi-restaurant environments that require complex structures. Some great examples are franchise restaurants, casinos, cruise ships, and stadiums.
Regardless of the size of the restaurant you are managing, you will need to configure your enterprise properly in order for your operations to run smoothly. In this article, I will cover how to configure and maintain your enterprise properly, the different levels and inheritance, and configuring permissions.
Configuring your Enterprise can get quite complicated, luckily for you, we have a fantastic Facebook community of like-minded individuals that can answer all your questions! Join for free below!
Micros Simphony Enterprise Levels
While there can be only one Enterprise for each EMC account, Simphony can support an unlimited number of Properties, Revenue Centers, and Zones.
These are the four levels we find in Simphony:
- Revenue Center (RVC)
This structure allows managers to configure Properties and Revenue Centers individually while still allowing total control and centralized reporting.
In the example below, there are three properties, each one containing one or two revenue centers:
Each of the four levels in EMC contains different modules. While most modules can be found at all levels in Simphony, like menu items and discounts, some are specific to a particular level. Hardware programming like workstations and printers, for example, can only be found at the property level because they will be unique to each location.
Allowing certain modules to be programmed at multiple levels is great for individual control when needed, but it can also cause issues and confusion when not managed properly. Take menu items as an example: if you have some programmed at the enterprise level, others at the property, and even some at the RVC level, it will make maintenance a nightmare. This can be further exacerbated when you have multiple people making changes in EMC and no pre-determined plan on where to program the different modules.
There is no right and wrong answer to the question: “Where should I program my menu items”, it all depends on your particular situation, which is why enterprise planning and maintenance is very important. Even if your system is several years old and everything is already programmed, it’s best to have a plan for making changes moving forward, so the situation doesn’t get any worse.
Common Enterprise configurations
1. Single Property Environment
If you have just one property and a few Revenu Centers, it’s best to program everything at the enterprise level when possible. If there are no plans to add another restaurant in the future, or if all the restaurants will have identical menus, it’s easier to add everything at the highest level possible.
2. Multi Property Environments
If your enterprise contains multiple restaurants, and they are all different, it’s a good idea to program items at the property level. You will have to be careful when choosing the record numbers for the menu items, they cannot overlap between properties. Reporting is done by the record number, so if you have a hamburger at position 105 in one property and pasta at the same position in another property, the reporting numbers will show together when running an enterprise report.
A good way to prevent this is by enabling Option bit #15 in the Enterprise Parameters Module (Check for Duplicate Menu Item Object Numbers). Select it to prevent users from entering duplicate menu item object numbers in the EMC unless the Allow Duplicate Obj# option is enabled in the Roles module.
3. Advanced Multi Property Environments
If your enterprise has multiple property chains where several restaurants are similar to each other, you can use zones to group them together. You can create separate zones for menu items, taxes, or anything else that might be the same between the restaurant groups. An example would be the “Florida Tax Zone”, where you configure sales taxes for all the restaurants located in the state of Florida.
Inheritance and Overides
As I mentioned before, some modules can be found at multiple levels in Simphony, so how does the system know which programming to use? That’s where inheritance and overrides come in. This concept is a bit counterintuitive and complex, so I will do my best to clarify it.
In Simphony, the information flows down from the top level (enterprise) to the bottom (RVC). Information added at the enterprise level flows down and is inherited by the property level and further down by the RVC. But what happens if we have an exception and need to make a change for a price at just one of the properties? That is where we can add an override. The inherited information will be removed, and we can make changes as needed.
Once an override is created at the property or RVC level, the enterprise configuration will be ignored. So making overrides is needed sometimes, but if you make too many of them at different levels, it will be very difficult to keep track of all of them, and maintaining the database will be very difficult. That’s why I always recommend as few overrides as possible.
To help with this, EMC has the Zone/Location field and the Inheritance Type field that will show which information is being used. There are several options here:
Defined Here, No Override: This status indicates the record is defined in the location of the module that is open. The record does not override another record. It is possible that another record overrides this record. (EMC is not aware of records below the current location.)
Inherited: This status indicates the record is defined in another location and it is inherited in the current module and location.
Defined Here, Overriding: This status indicates the record is defined in the location of the module that is open. The record overrides another record from a higher location.
Now that we understand how Inheritance and Overrides work, here are some examples of how the information flows when it comes to menu items.
It’s important to know that the workstation will use the information found at the lowest level, the RVC level, be it Inherited or Defined there.
Scenario 1: No Overrides Exist
In our first example, we define our menu items at the Enterprise level, and no overrides exist. The Workstation will use the Enterprise Level configuration.
The enterprise menu item configuration (orange) flows down to the property, RVC, and finally, the Workstation.
Scenario 2: Override at Property Level
In the second scenario, we define our menu items at the Enterprise level and create an override at the property level. The Workstation will use the Property Level configuration.
The enterprise menu item configuration (orange) cannot flow down to the property because of the override. When you create an override, you cut the connection to the level above.
The Property menu item configuration (green) flows down to the RVC, and that is what the Workstation will use.
Scenario 3: Override at Property & RVC Level
In the third scenario, we define our menu items at the Enterprise level and create an override at the property level and the RVC level. The Workstation will use the RVC Level configuration.
The enterprise menu item configuration (orange) cannot flow down to the property because of the override. Similarly, the Property Level Configuration cannot flow down because of the second Override at the RVC level. Both connections are cut.
The RVC menu item configuration (blue) flows down to the Workstation directly.
Scenario 4: Override at the RVC Level only
In the final scenario, we define our menu items at the Enterprise level and create an override at the RVC level. The Workstation will use the RVC Level configuration.
The enterprise menu item configuration (orange) will flow down to the property level, but it cannot flow down further because of the Override at the RVC level.
The RVC menu item configuration (blue) flows down to the Workstation directly.
No matter what changes we make to the levels above, the workstation will still read the RVC level configuration. So if you find yourself making changes in EMC and they don’t show on the workstation when testing, an override somewhere might be the culprit.
The Zone level can be added between the Enterprise and Property or between the Property and RVC, adding another level of complexity. The same rules apply to the information flow.
Creating Overrides in EMC
Now that we have a very good understanding of the Levels and Overrides let’s take a look at how we can create them in Simphony.
We will take a menu item as an example because that is where 99% of our overrides will be done.
I will open the Menu Item Maintenance module at the RVC level (Restaurant, in my case) and select the prices sub-tab. The goal is to change the price of my breakfast item, “Two Eggs” from the Inherited price of $8 to the new price of $10.
Right-click the rectangle at the beginning of the row, and select “override record” -> “use existing record”.
For more information on making changes to your menu, check out my article on Menu Items.
This will “push” the inherited record out of the way and create a “copy” at the RVC level of that same price. This override mechanism will be important later when we talk about removing the override.
Notice that the line will change from gray to white, and we will be able to change the price.
If you only need to change the price of a menu item, it’s important that you only create the override for the price, not de master record or definition.
Because of that overriding mechanism I described earlier, the inherited record is pushed out of the way, and a copy is created in its place. If you do decide to create an override for the definition, you will need to re-create a new price record. This is because the original definition (which contained the price record attached to it) was pushed out of the way, and a copy was created only for a new definition (no price record).
Many times, managers want to change the SLU or Print Class of a menu item and create an override for the definition record. After making the change and saving, they go to the workstation and find the menu item is gone or does not work anymore. This is because it’s missing a critical component, the price record, which will need to be recreated.
The same applies if you create an override to the master record, you will need to create a new definition and price record.
Removing Overrides in EMC
In order to remove overrides in EMC, we need to delete the record. I know this sounds counter-intuitive, but recall the override mechanism we discussed earlier. If we delete the copy we created at the RVC level, the inherited information will move back and take its place.
So right-click the end of the row and select the Delete option, and the record will become inherited once more.
For more details check out the video below.
Configuring Roles in EMC
If you find yourself not being able to create or remove overrides from the EMC, you don’t have the proper permissions in Roles.
You will have to ask the System Manager to increase your role to Property Expert or allow your current role to add and remove overrides.
You can do this in the Roles module -> EMC Modules.
You will need to be able to add, override, edit and delete items either in all the modules in Simphony or the individual modules you need to work with(i.e. Menu Item Maintenance).
If you are looking for comprehensive Simphony Training, we have a complete online course and support platform. More details below.
Now it's your turn!
I hope you enjoyed my article on how to configure your Enterprise, levels, and overrides, and you found it useful when configuring your system.
- Do you have any other questions on how to configure your enterprise?
- Do you have many overrides in your system?
- What are the most common overrides you find yourself using?
- Let me know in the comments bellow!