Aloha Multiple Sites menu/items changes

[LDigital]

I have a client that has 5 restaurants that would like to be able to do one price change or one menu change at the restaurant he is at and drop the ITM.DBF, MOD.DBF, SUB.DBF, MENU.DBF to the NEWDATA Directory at the other locatations. All verisons are 5.3.29 except one and I will upgrade that location to match all the others. Anyone see any problems doing this the owner does not want to spend the money for Aloha Enterprise at this time.

Thanks for Your Help!

 

[bigblok403]

I would drop the .cdx and .tdx files for the corresponding files as well or do a database upgrade at each site after dropping the files, otherwise there should be no problem with doing this.

 

[jjr2144]

I WOULD MAKE SURE YOU ALSO DROP IN THE CAT.DBF, CIT.DBF, PRO.DBF, AND CMP.DBF

 

[sanfranqsr]

Hi -
I do this all of the time. Easiest way to make sure you get all of the files is to check the dates of the files in NEWDATA. Any file with the new date (save for the *.ini) gets copied over. I also copy over panel and button changes.

I use a WEBDAV drive, copy the new files to it, then use logmein at the remote sites to bring the new DB files over. I have thought about setting up a batch file on each machine to make it quicker but have never bothered.

Let me know if you need more information.

 

[alohaakamai3]

There are also programs like QSR that are designed to push the menu changes made on one system, to all the others.

I am sure the techie solution mentioned above can indeed be done, but there is always a chance for error and other problems. I they actually have 5 restaurants and do this regularly, then software of this type may actually be worth looking into... especially if it's something they'd like the ability to do often.

 

[pasupport]

Or you could use Aloha Enterprise to do this.
With Enterprise you can not only set pricing but also price ranges. The range give the local restaurant a little movement based on local competition. Also you can plan changes in advance and have them take effect everywhere when you are ready.

 

[SwampGas]

If this is a small mom-and-pop type concept, and all sites are exactly the same (Pricing, menu's etc.) then just copying the DBF files you need from the newdata directory is fine. Don't copy the CDX and TDX files. Just run a database upgrade.after you drop the DBF files in.

Mixing versions of the database files you mentioned mix quite well between POS versions, and besides, as long as you run a database upgrade after the files are dropped in, everything will be fine.


Aloha Enterprise isn't designed to be a full menu maintenance piece. It can do simple changes only.

The CDM (Central Data Management) product will do this much better.

There are other companies, such as Xpient that has a solution called WebEDM that does an awesome job of managing multiple sites (Even Aloha POS).

Radiant has a new service originally called AEM that is similar to Xpient's webEDM now. -This product I believe will be part of Enterprise eventually.

 

[alohatech2]

If you mix versions, I recommend that you make the parent changes on the lowest version and drop that into the rest of the stores. As always, run a database upgrade afterward.

 

[SwampGas]

Though Radiant recommends going from the highest version down. DBUP for the lower versions will take care of the rest.

 

[alohatech2]

Okay, more detail...

The direction you go depends on whether the newer version has new columns that you need updated. If you aren't concerned with new columns (which translates to new fields and settings), going from old to new doesn't hurt and might even go more smoothly.

One member of Radiant staff has stated to me that they don't support downgrading dbfs, although it can work.

My concern does come from situations that involve more than just the dbfs (involving trans logs and EDC), so it's probably fine either way you go.

 

[SwampGas]

The person you spoke to at Radiant support is wrong. The aloha program totally supports downgrades. It has to, especially when utilizing saved data in the dated subdirectories that were saved on earlier versions from when a POS was upgraded. You don't upgrade all the dated subs.

If you know how the CDM product works then you know you CDM has to use the highest version. DBFDIFF will create the record change including all additional fields. If there are any additional fields in the DBF file, they are kicked out by DBUP or procrecs.exe

Moving trans.log is the basically the same, you just have to run grind on the final version using the force upgrade argument. In the more current releases grind will perform an auto upgrade. Also grind and grindq can replace using the old fixlog utility since grind now has trans.log repair built in. -I know the support ready tools are much nicer, but in a pinch, grind can now do alot more than it did before.


Alohatech, you are pretty sharp with Aloha. I have an opening..If you are in Texas.