Item #1:
Ability to make an exchange on a single screen, instead of the current "return and then sell" process that now exists.
Item #2:
Ability for the "Employee Sales" report to function much like the current Total Sales report, e.g., specify a date or date range for which to search for an employees sales. We pay bonuses and spiffs based on sales targets and it would be really useful to be able to look up an employee's sales history instead of having to dig through the paperwork at the end of a month.
thanks for any consideration given.
dave
two items for the "think about it" pile...pretty p
Moderators:daleadmin, Dale Harris, Alan, Andrew
-
- Forum Regular
- Posts:19
- Joined:Wed Mar 03, 2004 9:09 pm
-
- Forum Regular
- Posts:71
- Joined:Wed Mar 23, 2005 8:48 pm
- Location:Charlotte, NC
- Contact:
As easy as that sounds...
Try getting DHPOS to allow you to set the quantity to -1. Even though it sounds like a great idea, it usually ends up throwing a number off somewhere.
If memory serves, on the old BMI terminals I once worked... To refund an item you would hit [Refund] then scan/enter the item normally. I think it just added the "-" to the quantity, but when the reports ran at the end of the day it was classified as a refund transaction. If you were to refund an item, then ring it up in the same order (yes, I realize that's refered to as an "exchange" by most people) it was still classified as a refund, and therefore the transaction total would be counted under refunds. This looked great on paper, and would make the refund average look good for the day, but we never really got credit for the sale part of that transaction. Do this a few hundered times, and you really do loose out in the totals. If they figured out we did a "exchange" by the aformentioned process they'd give us an ear full, and once I became the store accountant, I was the ear full giver. If we did need to do an "exchange" we'd have to first refund the item, cash out the sale, then ring up the new item, key the refund total in as cash, then settle the balance with the customer. Was it a somewhat unnecessary step? Yes....and no. I think the system is fine the way it is.
I like the idea of merging the screens together, maybe make one of the unused "F" keys the "Refund/Payout" key, and have one universal sales screen.
While we're on the subject, what about this for an idea? Back in my days of Customer Affairs/Accounting...after a refund was completed, and tendered out, the system would then print a refund slip, looked something like this...
*** STORE REFUND***
_Ryan_______________
Associate
_Bob_Dole___________
Mgmt. Aproval
----------------------------
Reason for refund:_____
_Customer_didn't_need_
_any_more_corn,_or___
_tomatoes._Parents_no_
_longer_able_to_eat.___
-----------------------------
<insert refunded items>
0216259630 1x3.29 -3.29
BIG CAN O' CORN
0263250926 3x1.69 -3.39
BIG CAN O' TOMATOES
Total -6.68
Tax -.21
Refund Total -6.89
Cash -6.89
Balance 0.00
Trx 26051260460156015603
-------------------------------
_LIZZY_BORDEN________
Customer Signature
_123_456_7890__________
Customer Phone Number
(Of course the Associate Name, Mgmt Aproval, Reason, Customer info didn't print, but I'm kinda bored today, so I thought I'd add them for a more "realistic effect"...and the fact I'm bored)
Now ofcourse the "middle" portion was all justified, and the amounts lined up. That portion of the receipt looked identical to the "transaction" portion of the regular reciept. Minus the headers and footers. How feasable is this Dale? I would think it's easy enough, simular to the mini-receipt that pops out for sales checks....just a bit more text up top, and down below. Maybe something for a day when X-charge get you down. Take your mind off of PIN pads, card readers, interfacing software in general.
Oh yeah, and I finally decided to register my screen name. Woo Hoo!
Have fun! Peace, Love, and Lolipops!
-Ryan :-)
If memory serves, on the old BMI terminals I once worked... To refund an item you would hit [Refund] then scan/enter the item normally. I think it just added the "-" to the quantity, but when the reports ran at the end of the day it was classified as a refund transaction. If you were to refund an item, then ring it up in the same order (yes, I realize that's refered to as an "exchange" by most people) it was still classified as a refund, and therefore the transaction total would be counted under refunds. This looked great on paper, and would make the refund average look good for the day, but we never really got credit for the sale part of that transaction. Do this a few hundered times, and you really do loose out in the totals. If they figured out we did a "exchange" by the aformentioned process they'd give us an ear full, and once I became the store accountant, I was the ear full giver. If we did need to do an "exchange" we'd have to first refund the item, cash out the sale, then ring up the new item, key the refund total in as cash, then settle the balance with the customer. Was it a somewhat unnecessary step? Yes....and no. I think the system is fine the way it is.
I like the idea of merging the screens together, maybe make one of the unused "F" keys the "Refund/Payout" key, and have one universal sales screen.
While we're on the subject, what about this for an idea? Back in my days of Customer Affairs/Accounting...after a refund was completed, and tendered out, the system would then print a refund slip, looked something like this...
*** STORE REFUND***
_Ryan_______________
Associate
_Bob_Dole___________
Mgmt. Aproval
----------------------------
Reason for refund:_____
_Customer_didn't_need_
_any_more_corn,_or___
_tomatoes._Parents_no_
_longer_able_to_eat.___
-----------------------------
<insert refunded items>
0216259630 1x3.29 -3.29
BIG CAN O' CORN
0263250926 3x1.69 -3.39
BIG CAN O' TOMATOES
Total -6.68
Tax -.21
Refund Total -6.89
Cash -6.89
Balance 0.00
Trx 26051260460156015603
-------------------------------
_LIZZY_BORDEN________
Customer Signature
_123_456_7890__________
Customer Phone Number
(Of course the Associate Name, Mgmt Aproval, Reason, Customer info didn't print, but I'm kinda bored today, so I thought I'd add them for a more "realistic effect"...and the fact I'm bored)
Now ofcourse the "middle" portion was all justified, and the amounts lined up. That portion of the receipt looked identical to the "transaction" portion of the regular reciept. Minus the headers and footers. How feasable is this Dale? I would think it's easy enough, simular to the mini-receipt that pops out for sales checks....just a bit more text up top, and down below. Maybe something for a day when X-charge get you down. Take your mind off of PIN pads, card readers, interfacing software in general.
Oh yeah, and I finally decided to register my screen name. Woo Hoo!
Have fun! Peace, Love, and Lolipops!
-Ryan :-)
Walmart and Target systems work the same....
way as DHPOS, in that it processes the return first and then a new sale has to be rung up. Granted, there are other retailers that take the "Exchange and Sale" route, but I think it has more to do with transaction tracking than anything else.
- Dale Harris
- Forum Owner
- Posts:1171
- Joined:Sun Dec 28, 2003 10:19 pm
- Location:Chicago
- Contact:
Vendor stock numbers
Just enter the stock number with characters other than numbers into the "Vendor stock number" Then if you set it up using the "Vendor list" feature of the POSCONFG.EXE program, you can press [*] when asked for a stock number when ringing up a sale and you can enter the vendor stock number instead.
Dale
Who is online
Users browsing this forum: No registered users and 161 guests