Aloha - Purging Old, Unused Menu Items

[bufftrek]

I work for an independent company that integrates with POS software to collect sales information. I have some experience working with databases but it has mostly been Micros - I am unfamiliar with Aloha's database structure so I'm hoping to glean some answers/insight/direction!

In short, I have a client that is a franchised operation but got their initial Aloha DB from their corporate office. This entailed getting a bloated DB with a lot of unnecessary menu items. They have asked me to go through and purge them as their provider is wanting to charge them $800-$1,000 for a days worth of work (I was told this amount by the provider). I was told that the DB is unprotected and have yet to start digging around.

Long story short, will it be a simple process to have a script determine which items have not been sold since their opening day(within 14 months) and set those respective names to a blank value?
Thank you for any and all of your assistance, I have always had great success in past posts and try to learn from you guys as much as possible!

 

[AlohaRoss]

Purging items from Aloha can be a bit tricky.
we would need to know if you are using the legacy version or newer sql based? As the process is not the same.
You can run a product mix for 14 months, but that would not show you what modifier.
You could run a menu item report by number, it will show what is on each submenu and modifier group.
After you have figured out from those reports what you need, then there is the process for removing the items from the database. Since all items have to be in a sales category, and usually at least 1 other non sales category, you need to remove them from those categories.
Then you can start to delete by just hitting delete as long as you have the correct rights on each item you want to remove. it the items are all in the same range, it is possible to delete a range of items but all the numbers need to be in order.

800 to 1000 for a company to do this in not that high as you see its a lot of work to do.


AlohaRoss

http://www.needalohahelp.com

 

[bufftrek]

It is the newer SQL based Aloha.

What do you mean by a product mix would not show me modifiers?
I have a Menu Item Report by Number on hand.

Where is the necessity of me determining what they do and don't need? They have a number of items that have not been rang in for 14 months now - that seems like a determinate factor for me. The issue is that most of these items are not available to the staff on the temernial's GUI so they are simply sitting in the DB doing nothing. Since it is SQL based, can I not systematically begin removing all of these items based on whether or not they have been used within a specified date range?

I am not a vendor so I do not know what the typical hourly rate it for this service. Thanks for you assistance in this matter - I'm excited to being getting my feet wet with Aloha!

 

[AlohaRoss]

The newer version is a bit easier to delete, change the view to the full table view, click on rows and hit delete. Remember to verify data often to you don't remove something on a modifier screen by mistake.

Any particular reason to remove the items. They are always nice to have around when you want to add a new item, just rename it, change the routing and mods if needed and you are done

AlohaRoss

http://www.needalohahelp.com

 

[bufftrek]

I understand I can manually delete the items, I was hoping to automate the process based on set criteria and see if anybody has any experience with it.
Thanks for the heads up on perpetually verifying data!

I have been asked to remove data for a number of reasons by the client - for me I see a run of items with poor categorization that is only going to become compounded over time.

Quick question, if I were to try some things, are all new changes made (that I have spoken of thus far) contained within \NEWDATA?
Could I simply copy this folder with an alternate name, change the current \NEWDATA to \NEWDATA_OLD and the new folder to \NEWDATA, make any changes that I would like to make and revert to the original folder if the resultant changes are unwanted?

 

[AlohaRoss]

that used to work on the old version, the sql is a bit different. nos you see why they charge so much.

AlohaRoss

http://www.needalohahelp.com

 

[TheMagicJBone]

Hang on a sec; if this is just the new Aloha Manager, you could remove the items once you figure out what you need to keep and what can be thrown out. But if this is CFC, they're just going to pop back up the next day (or sometime thereabouts). As you said, the items are just sitting in the DB doing nothing. Is getting rid of something that's doing nothing worth either risking the integrity of the database (if new Aloha Manager), or risking wasting a whole bunch of time that gets paved over when the next day starts (if CFC)?

If the problem is clutter in the UI, you should be able to filter the display to restrict it to items relevant to that store. If it's clutter in your application, you should be able to filter your SQL queries about the same way.

You say you've been asked by the client to remove items for a number of reasons. The community here would be able to give you more and better help if we knew more about what those reasons are, and the big picture the client is trying to achieve by them. There might be a better way to that goal, there might be an easier goal, and there might be both. Ask them, tell us, we'll figure something out.


And no, the changes aren't made only to newdata. They are populated to the DBFs there, but after being made to the SQL database. So a backup of newdata wouldn't help you there. You'd need to backup the SQL database first, change stuff, test, and maybe restore. Rather than get that deep into it, I'd create a dummy item, let it sit for a couple days to populate to all the different spots in which it's stored (SQL, data, newdata, FOH), then delete just that and see what happens; also see if it's back the next day.

 

[bufftrek]

Thanks for responding! So, at first glance Aloha Manager is operating out of BOOTDRV\CFC\. I read up on this as it is new to me (been that long since poking around in Aloha) as well as looking over some of the settings. As it stands, it appears that not only myself, but all of the managers and owner have a security setting that doesn't allow the deletion of menu item records so that lends more to corporate dictating how their menu is set up.

With all of that being said, I did make a few changes the previous week (I only get a chance to get in here twice a week) and I'm not seeing any evidence that they reverted back. These were simple changes like what items were modified by as I didn't want to start off with any drastic changes without first seeing their effect over the course of a week.

The client is in the process of bringing on new management and wants them to take the time to familiarize themselves with more BOH operations in Aloha. Unfortunately, the current level of organization for menu items is not the typical protocol that I have seen for my other Aloha clients. He would prefer a base of what their items are currently and then build from there. Finally, when it comes to adding new items, there is virtually no 'spacing' between records in his system which is currently leading them in a direction of adding items in other places so that they are not logically sequential.

Thank you for the current advice, I have created a test item per your suggestion and will be back in on Friday to remove that item and see what happens.