In article <email@example.com>, DevilsPGD
> In message <firstname.lastname@example.org>
> email@example.com (Robert Bonomi) wrote:
>>> Sure. However, since the customer can request cash back it's another
>>> way to steal. The cashier fakes problems scanning an item, punches in
>>> the amount manually as cash, and gives the customer the item.
>>> The customer isn't over charged, so has no reason to complain.
>>> The cashier's till is now over -- Now she just needs to grab the cash
>>> at some point during the transaction.
>> No, the till is _not_ over. Punching in the amount as 'cash due'
>> instead of scanning the item, is no different than scanning the item
>> itself, as far as the cash balance in the till goes. The *only*
>> difference is in the store 'inventory', where the proper item was
>> -not- deducted from the count.
> I wasn't clear enough ... Not "Punches the amount as cash from the
> customer", I meant "punches in a cash back request for the same
AH. Of course, almost all even semi-current computerized
cash-register implementations _will_not_ let you do that, *during*
charged item entry. It has to be done at the end of the transaction.
*after* the total has been calculated/displayed, _and_ the 'payment
type' has been selected. And, a 'cash back' request is valid _only_
on a credit/debit/ATM card transaction. There is no need for it, on a
'cash' or 'check' transaction, because the 'cash back' is automatic,
based on the over-payment recorded.
And, on the 'card' transactions, 'cash back' is almost always itemized
separately on the actual 'card transaction' (_not_ the cash-register)
Just *one* of the reasons you get that _second_ piece of paper, that
is the 'carbon' from the one you _signed_.
Also, most 'newer' register systems won't do a 'cash back' request,
*at*all*, unless the _customer_ keys in the amount on the keypad
> In essence a cash back request means the customer is purchasing cash
> from the till. This gets the cash out of the till (and into the
> cashier's pocket), plus of course it screws up inventory.
> Another twist would be to activate a $20 gift card instead of ringing
> up a purchase of just over $20. This would be more likely to get
> caught though, since you then have to spend the gift card at some
Not terribly practical. Requires (a) bypassing the scanner with the
$20 item, (b) having the 'unregistered' card _in_hand_ at the
opportune moment, (c) *scanning* (or swiping) the card, *and* making
the appropriate entries on the register keyboard.
>> [TELECOM Digest Editor's Note: You make it sound as though local
>> acceptance of local C of C gift certificates is going to be a major,
>> massive processing operation in a small town like ours. You make it
>> sound as though joining the local C of C in a small town to show
>> support of other community merchants and share tips, ideas, etc is
>> going to cause a major outlay for Walmart. You make it sound as though
>> any modicum of customer service and goodwill is going to have an
>> effect on their 'lower prices'.
> Unfortunately doing anything unique / "local" will probably cost more
> money in the bureaucracy of accounting for the C of C gift
> certificates then they could possibly bring in.
Exactly. The 'hard dollar' cost of that 'special handling' is far
higher than the possible 'intangible' good will generated.
>> Walmart does have its own gift 'certificates' in the form of prepaid
>> plastic credit cards, branded in their own name, in the 6011 series
>> of numbers. Those are processed like credit card sales at the cash
>> register, and must cost them something to process.
> As a general rule those cards make money due to administration fees
> that let Walmart keep the leftover money if a card gets lost or
> destroyed, or otherwise goes unused. Plus, like all gift certificate
> type programs, it gets the money out of the customer's hand sooner,
> which means Walmart can invest the money now.
> The cost to manage the cards shouldn't be substantial.
There is a NON-TRIVIAL, *one-time*, already 'sunk', cost for the
programming to support in-house-issued gift cards. Spread across
_all_ the stores, and _all_ the gift cards sold. Over the entire
lifetime of the software. On a 'per card' basis, that cost is 'close
enough' to zero, as to not matter.
The 'labor' for handling the in-house card, when presented, is, for
all practical purposes, equivalent to that required for any other form
of payment. No additional burden there.
There is a bit of a cost in querying/updating the gift card database.
It is, however, miniscule. The cost of purchasing the disk storage
for say, 100 *million* cards is on the order of $50. Per card, this
is _way_ down in the noise -- even if the system is being used at
only, say =one=percent= of capacity.
Unlike actual _paper_, the 'gift cards' are practically free of cost
to the store.
[TELECOM Digest Editor's Note: I did not realize it was so expensive
and impractical for Walmart to offer any customer service. It makes
me glad I did not stop in this afternoon (Friday) to do any shopping
after my visit to my hairdresser. You see, I forgot to take along my
cell phone, so I would have had to impose on Bob Donaldson or one
of his customer service people to call the cab to come pick me up.
I would have hated to put them to that extra expense. PAT]