Aloha Spooling question

[specs919]

How do you set up the FOH terminals to automatically spool the CCs if they can't communicate with the BOH?

I thought if you just adjust the aloha.ini file of the master terminal to:

spooling=true
floor down=999.99

Is there more to it? Because the CCs are still giving my the "D/S error" message.

 

[coorsman]

If set up correctly you should just have to stop pos processing in edc. That would create the spooling marker file on the master terminal.

 

[DTSMAN]

My opinion:
No operation wants automatic spooling in Aloha.

What happens is, when the slightest hic-cup happens and spools a single credit card, or more, they could be easily be lost when the system comes out of spooling, and no one would know without having to audit all the CC receipts nightly. If you turn on spooling for a period of time, then the closing manager knows what to look for before batching. Also, these same reasons I don't recommend auto batching.
There are users out there that have created scripts that make these processes happen, but my company would never support nor recommend them.

Bo

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

http://www.redgreen.com

 

[SwampGas]

We use automatic spooling. The only time our managers know if EDC is offline is because we cannot accept debit during offline mode.

With the newer versions of EDC you have settings in the EDC.INI for deciding auto spooldown based on a count of successful or failed network pings.

The part we like is after a network connection is restored, and EDC can ping a server after a set number of tries, then EDC automatically turns itself back on. Only way it would not is if the manager manually turned EDC to offline mode. Our fix for that is I have a special program that runs 15 minutes before EOD that will turn EDC back on if it was manually set to offline.

[System]
CheckNetwork=1
CheckNetworkTimeout=10
CheckNetworkComputerAddress=208.69.32.231
PingInterval=25
PingCount=4

The settings represent the following:
CheckNetwork - Check for network 1=yes.
CheckNetworkTimeout - Time to wait for response during test.
CheckNetworkComputerAddress - IP address of server to test.
(For franchise sites we enter the IP address of Google.com)
(For corporate sites, we have them ping our firewall).
PingInterval - Wait time between pings.
PingCount - Number of success or failed pings in a row to make network decision.


As you can tell there are different theories. I like it, and have this in all sites (Including franchise), and there are others do not like it. The bottom line, it's your personal choice. There's good arguments on both sides of the fence.



MegabyteCoffee.com

 

[alohaakamai3]

I am with DTSMAN, as we have discussed this on this very forum before, probably 2 or more years ago.

We do typically leave it on by default- newer version of Aloha tell you that the card was processed off-line, so it's not so bad. But you do run a risk, especially in those rare but annoying situations where it does hiccups or pops on and off. It doesn't happen all the time, but cards can and do get lost.

There is one main reason we leave it set for automatic and it's a pretty good one. IF your fileserver dies, has a power supply failure, HD failure, loose connection, etc- and you have to use redundant mode during a busy dinner rush - you'll have no way to enable spooling and refresh the terminals, so they will lose credit card functionality, which sucks. (At this point, there only choice will be to go to each keyboard with a terminal and manually edit the Aloha.ini to turn spooling on- which can be a huge pain)

 

[SwampGas]

Maybe it's the older versions of EDC that I am unfamiliar with, but we have never lost a credit card due to a WAN outage or a flaky WAN connection. We may not poll the batch, but we do not lose credit card transactions. If that was an issue and Radiant couldn't fix it, the POS would be $hit-canned for a better product in a second.

Testing for multiple pings to ensure the connection isn't bouncing up and down may be the answer before turning EDC on or off, but as a company we would rather take a credit card offline than deny a guest a payment option. -I'd even risk losing a credit card auth once in a great while than deny a guest where one bad experience could keep them from coming back. Our business is mostly credit and debit.

When EDC hangs because the POS doesn't auto-spool, the managers freak out and panic and call the helpdesk. Our managers are busy running the location, and they will not remember every troubleshooting issue and how to handle it. -We have the quick fixes manual and post-it style notes, but they don't use them. Just humans being humans. We strive to make the POS as transparent as possible in the means that the managers and staff just use it.


MegabyteCoffee.com

 

[DTSMAN]

With Aloha, it was a known fact that if you lost your internet connection, turned off POS processing and went into spool down, and if some one turned POS processing back on without the internet connection being established, then ala-kzam, all the spool files disappeared and the closing manager sat there keying them in manually.
I have been out of the Aloha loop for a while, but, yea, that was a common thing 1+ years ago.

Bo

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

http://www.redgreen.com

 

[SwampGas]

The issue you are describing sounds somewhat familiar with the issue of not having EDC registered under an Administrator account, but having it registered as the localsystem account. I remember hearing there were three types of problems if localsystem account was used to register EDC.

I've had Aloha rolled out for 6 years now. Never once had this issue. Maybe it was our staging and overall configuration, or the version we started out on. But never have we lost a single credit card transaction because of spooldown issues.


MegabyteCoffee.com