Integrating with Aloha

[Nibbler01]

We need to access Aloha data from an external proigram; the Aloha installation is based on flat-files, no SQL Server.
I noticed that after the End Of Day you obtain a copy of the data into a folder named with the business date; most of the information is then available as DBF files; apparently these files contain a copy of the restaurant "settings" (menu items, price...) but nothing about what happened (transactions, sales, payments..)
I noticed that the EOD produces also a file (TRANS..) which should contains the transactions; the file is not a DBF and in a binary format probably undocumented.
How do I extract sales information from this file? Are transactions stored somewhere else?

thanks

 

[bcconsultin]

The aloha key's purpose is to have the ability to grind everything together to produce reports. There are several companies out there that offer comm interfaces to be able to produce the results that you are seeking.
Another option if you are good with excel is to export the data into *.csv. Notice in your report window that there is an export setting, and then an option at the bottom to export. If you need more info, just let me know

Brad C.

 

[Nibbler01]

When you say "comm" interfaces do you mean "COM" (ActiveX) inteface? If so can you give me a link to one of those companies who can provide this?
The CSV solution would work except for the fact that I need an external program to initiate the export; I guess you need to manually interact with some Aloha tool UI to obtain the CVS file, correct?
About the flat files I see after the EOD operation (DBF files), can you confirm that the transactions info are not stored in any of the DBF files but is probabily contained in some binary (proprietary format) file?

thanks a lot!

 

[IndexRobert]

The TRANS.LOG is an encoded file that contains all the transactions during a day. A transaction is more than just a sale, it it basically everything that happens to the system, so also a transfer, clock-in or out and more. This file is grinded during the EOD to create a bunch of DBF files with all the transactions. these can be easily opened with any DBF utility or Access. The files are called gnd***.dbf, and one you might want to look at is gndsales.dbf.

Although these files are only created after the EOD, you can manually create them by running a report for the current day. You will notice a grind window when doing so.

Good luck

 

[Nibbler01]

I will look into these files, I think this is exactly what I was looking for, thanks!

your "good luck" actually scares me a little bit

 

[bcconsultin]

Your dealer can build you an auto report that exports or prints reports on the EOD. The file they use is called "WINHOOK". It is a little difficult to build, but it does work!
Comm interface is programs that Aloha partners build to interact directly with Aloha. A couple of them are Restar, Transmanager, and Crystal Reports.
Good luck is a good thing!

Brad C.

 

[Montana007]

Does Aloha charge a com license fee when a 3rd party (API) is integrated into the POS?

 

[posrescue]

Nibbler

The gnd*.dbf files should hold all the data you need except for "edited punches", (edits to clock-in and clock-out times made from the BOH). This info is in adjtime.dbf.

Data mining the gnd files is tough if you don't have a road map of the files. You should be able to get this from Radiant Systems. If they don't support your cause every Aloha dealer tech has access to this info...

 

[erock123]

This was in place before I joined here, but we get our POS data replicated into our SQLServer from Aloha Enterprise.
I am not sure of the charge, but if you do use the Aloha Enterprise, i would suggest contacting them.

Their Data model is a bit confusing but you can find all you need there.

 

[IndexRobert]

What erock123 mentions is really cool. There are not many companies that have the privilige of getting a SQL DB replicated from Enterprise...

Generally most companies just use the DBF version of Aloha. The GND files will be all you have access to then, and are generally more than you need. Multiple day reporting is tricky though, so it is generally a good idea (if you're into it) to upgrade to the SQL version. You can use SQL 2005 Express for this, and we use it to make reporting tools. It costs nothing extra, and is totally worth it if you want to do some cool reporting\interfaces.

By far the coolest thing is of course replicating the Enterprise DB, because then you have multi-store information in one DB. We do this with multi-currency customers, which is not yet really supported by Enterprise.