Run Grind File Multiple Times? 2

[blurngr]

Is it possible to run the Aloha grind process more than once per day? IE, we'd like to get sales data and labor data out of the system, say, 4 - 6 times per business day.

How would we go about doing this?

Thanks!

 

[SwampGas]

Yes.

But are you really talking about multiple polling cycles per day, or just running a grind multiple time for custom reports you are using? And, if so, what are you using for polling? Aloha enterprise hosted solution or something else?

MegabyteCoffee.com

 

[blurngr]

We're using our own custom software ... which we use to interface to Micros, Dinerware, Restaurant Manager, POSitouch, and a few others, but Aloha continues to give us the fits

Basically, our product is a service that sits and waits for the grind files to appear, and then processes them as needed. Ideally, and we can with the other POS providers, we could get the data as needed.

All we really need are the labor / time punches, and the sales data to provide some good over-the-air reporting capabilities. No custom reports.

Radiant hasn't been real helpful in allowing our customer to run the grind files more than once ... I didn't know if it was even possible.

 

[SwampGas]

Radiant or a reseller not helping?

You can run grind anytime you want. There is a list of arguments you can pass to define what you need more specifically. This is available on their Knowledge base site.



MegabyteCoffee.com

 

[blurngr]

Megabyte ... thanks for your pointers. Radiant Corporate. Large national franchisee.

Knowledge base? Is it public, with a URL?

Thanks!

 

[SwampGas]

Well, this customer, if they are large and dealing with Radiant directly, most likely they have access to the knowledge base site already. They can provide you the info.

It's not public (anonymous access), but if you are a registered third party developer with them, you would probably have access.

Once grind runs, the gnd* files will always exist. Your app should call grind when needed and when the exit response is detected, you should then re-read the files you need.


MegabyteCoffee.com

 

[blurngr]

Thanks for your help! I think with this information we should be able to do what we need to do.

 

[DTSMAN]

I don't know alot about the internal workings of the software, but I do know that the information you seek is easily obtained through a FOH terminal's manager screen without creating grind files.(labor, sales, server sales, etc.)
If you figure out how that does it, maybe you can do the same without having to worry about the grind function????

Maybe?

Bo

Remember,
If the women don't find you handsome,
they should at least find you handy.
(Red Green)

http://www.redgreen.com

 

[blurngr]

Bo,

Thanks for your insight ... yes, I believe they get that information directly from their database (in the DATA/ folder)? However, it's even less documented than the grind files, and Radiant seems to have an issue with people poking around inside of the actual database.

Unfortunately, our integration options are grind files or buying the COM interface for a cool $25k, then our customers get to pay $500 per store, per year, to Radiant. This creates more problems than it solves, I think.

Needless to say, when someone asks for our POS recommendation, it's not Radiant very often. But, for the time being, they're one of the big fish in a bigger pond, and we have customers who use their products.

 

[SwampGas]

Writing your routine to kick a grind and read the gnd* files is fairly straightforward, and besides, the COM SDK is not needed nor would provide the information you need.

We've written many apps that use the sdk and that utilize the gnd* files. Maybe Bo has written an app that works differently than mine.

Also, the com licensing is not 500 dollars per site per yeat. Its 500 dollars to license and activate it if needed. Some com calls are available without licensing.


MegabyteCoffee.com

 

[blurngr]

Megabyte,

Thanks for chiming in. My last conversation w/ Radiant about the licensing for the COM was about 15 months ago, but I was told there would be an annual, per-site license. Maybe something has changed, or I was misinformed?

I was unaware that there were any COM calls that were available without the license. That's very interesting.

I agree that kicking a grind process is pretty straightforward, nothing too arduous about it. It is a bit more of a hassle to deal with than simply reading straight out of a database, as we do with every other vendor.

As for the COM interface ... we'd like to move that direction at some point, as we'd like to be able to insert a work / labor schedule. Thus far, doing it without the COM interface hasn't work too well.

 

[SwampGas]

Many of the other POS systems are using a relational database already -Configuration center is the first step in moving the sites to this. Aloha is moving in that direction, but you got to understand, there is a massive wide variety of versions and hardware out there, and just moving to relational database all at once would not be good for business. Plus, alot of what they do with their architecture is what makes them practically one of the top dogs in the group.

All the data we poll from all sites goes into a SQL database from our own self-hosted Aloha enterprise system, so we use this information unless the app needs to be read and used at the store/local level only.

You wouldn't need the COM interface either to insert data into the labor scheduler. It doesn't have a hook for the scheduler that I recall.

There is a maintenance fee with the COM licensing per location, but it's not even close to 500 dollars. Even the Aloha POS software uses COM calls on it's own to simplify functions all the time. Just no one realizes it.

MegabyteCoffee.com

 

[blurngr]

MegaByte,

Again ... thanks for your insight! I don't suppose you'd be willing to do some "consulting" with us to help with the labor scheduling portion? It's the last bit that we need (we're pulling sales, employees, positions, and all of the other information we need).

Certainly can understand the relational side of things, and moving slowly. Radiant's not there yet with the relational DB, however, they are approaching it better than some vendors (I know of one vendor who is pulling their DBF and placing the whole file as a BLOB into a SQL server ... talk about missing the point).

 

[SwampGas]

I'll try to answer any questions you have. I am currently tied up on a rollout of an app of mine that is keeping me up all nights monitoring the installations since it affects changing network settings remotely via the app.

MegabyteCoffee.com

 

[blurngr]

Megabyte,

Would it make sense to continue here, or to start a new thread?

In short, what we're doing is:

- Reading through the grind process (which we now launch directly), and getting the EMP.DBF, POS.DBF, etc... files to pull the employees, positions, and sales. This is done, thanks to your help here.

- Our users build a schedule (and other items) on our website. This works just fine and dandy.

- Now, we'd like to insert some schedule rules back into Aloha, to prevent scheduled staff from clocking in before their shift starts (with a grace period, if possible), or later than their shift ends (ditto the grace period) without some sort of manager approval.

- The enforcement should also prevent non-scheduled staff.

We're not quite sure where to begin. Perhaps some questions for you:

1. This appears to require pushing data into the SCHDSHIFT.DBF file in the DATA directory. Is that where we should be looking?

2. Where can we configure the grace period and/or enforcement? Is this something we can push programatically, or something the end-user will need to do?

3. Our current Aloha clients don't have the Aloha schedule module. Is the schedule module required to do this enforcement?

4. Is there a better way to do this?

Thanks! Happy to start a new thread, if it makes sense.

 

[SwampGas]

The Aloha basic scheduler should be available. I never thought this was an extra to turn on. I am using their Advanced labor scheduler, but either one can control clock-in's and manager overrides if needed - as long as the use scheduler option is turned on.

I will have to look at the files and verify the fields you will need, but it sounds like you are right on it, other than having the option to utilize the scheduler for employees.

MegabyteCoffee.com

 

[blurngr]

Thanks for looking into this! I don't know where the basic scheduler would be, or how my clients would go about turning it on.

 

[alexander00pr]

1. This appears to require pushing data into the SCHDSHIFT.DBF file in the DATA directory. Is that where we should be looking?

-When inserting employee shift data, it should be placed in YYYYMMDD.SCH file created in %Iberdir%\Data folder. The *.SCH can be opened by a DBF editor and is named after the First Calendar Day of company week configured in Aloha Manager. Normally your custom app would need emp.dbf, job.dbf and gndsales etc.(gndsales, gnd labor summary) among other. You can also use dbup2 or dbup3 to sum several days into only one dbf file to perform calculation.

2. Where can we configure the grace period and/or enforcement? Is this something we can push programatically, or something the end-user will need to do?

-It should be by the end-user in aloha.ini. It can be done by a batch file for this, using a find and replace tool but this depend on the Aloha version installed (Labor, breaks, and enforcement rules has been modified a bit in latest releases). This setting are in Maintenace > Store Setting > Labor and under Clocking punctuality, Use Manager is unscheduled etc. Jobcode has to be configured to not ignore labor schedule.

3. Our current Aloha clients don't have the Aloha schedule module. Is the schedule module required to do this enforcement?4. Is there a better way to do this?Thanks! Happy to start a new thread, if it makes sense.

-No. Basic Labor Schedule will work for enforcement of labor rules. I don't simply waste Manager time entering a Schedule in Aloha basic Schedule if they had to use another software or excel spreadsheet to actually do the labor by Sales projection, P&L etc. For that is the Advanced Labor or Menulink.

You can find me on MegabytesForum if you want to discuss further.

 

[blurngr]

We're finally getting to the point of implementing this (the rest of our Aloha integration is working and stable for several months now). I think the steps for us are pretty straightforward:

1. Our users will create a schedule on our web interface.
2. We'll then create a DBF file in %Iberdir%\Data called YYYYMMDD.SCH
3. In this file, we'll put the schedule
4. Managers will need to set up their punctuality that they require.

That seems pretty straightforward. Unfortunately, our Aloha customers at the moment are using AlohaQ, and don't seem to have the YYYYMMDD.SCH files.

What's the format for this file? How would I go about having one of our customers create one?

Also, alexander00pr's response says:
"and is named after the First Calendar Day of company week configured in Aloha Manager" ... what does this mean?

I thought the file was supposed to be named YYYYMMDD.SCH

Thanks!


--
Anthony