Must Set User Defined Payment in PAYMENT OPT. & RECEIPT LANG

Make comments, ask questions, or just complain about the software on this site. Or comment on any educational software.
Please note that by clicking on links that may appear in these posts that you may be leaving the Dale Harris Educational Software website and that the content of those sites is the sole resposibility of the authors of those sites.

Moderators:daleadmin, Dale Harris, Alan, Andrew

Post Reply
User avatar
brucef2112
Forum Regular
Posts:336
Joined:Mon Mar 06, 2006 11:19 pm
Location:Broward County, Floriduhh
Contact:
Must Set User Defined Payment in PAYMENT OPT. & RECEIPT LANG

Post by brucef2112 » Mon Jan 27, 2014 12:04 am

Setting up a user defined payment option (the 6th item on the PAYMENT OPTIONS screen) will not print your text description on the printed receipt.
After setting up the user defined type in the PAYMENT OPTIONS, all locations in the program will use the text description you set under the Payment options, such as payment choice when closing a sale, or reviewing past sales with the VOID feature. BUT not on the printed receipt!

To get your user defined description to print on the receipt there is a second step that is not documented in the user manual.
After setting up the user defined payment type under the PAYMENT OPTIONS in the POSCONFG the second step is to go to RECEIPT LANGUAGE screen in the POSCONFG and update the USER DEFINED TENDERED field (on lower right of screen) to match the text value you set in the PAYMENT OPTIONS screen.

Sometimes I have solutions to correct problems I find in the software. And in this case, I have three that Dale may want to consider.

1. Creates tens and tens of minutes of work for Dale:
It may make sense that if a user defined type is created on PAYMENT OPTIONS screen, the program should automatically set the same value in the RECEIPT LANGUAGE setup. In that way, the program screens will match the printed receipts. And the user doesn't have to go to two different screens to "define" the custom payment.

2. Creates one minute of work for Dale:
The user manual section describing "Payment Option" should be updated to explain the complete setup of the user defined payment type.
1. Enter your text on Payment option screen for the 6th payment option.
2. Now go to the RECEIPT LANGUAGE screen and enter the same text of the USER DEFINED TENDERED field.

And then the RECEIPT LANGUAGE section should also be updated to include a warning about changing the USER DEFINED TENDERED field, if in fact the user has already created a User Defined Payment type back on the "Payment Option" screen.

3. Creates NO work for Dale:
After reading this, Dale thinks to himself, "I'll put this on the virtual 'think about it pile'." And then goes about enjoying the rest of his evening, just as if he had never read this post.

Thanks Dale!
Later,
Bruce

They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
Benjamin Franklin - Historical Review of Pennsylvania, 1759

cwathen
Forum Regular
Posts:35
Joined:Wed Apr 08, 2009 10:22 am

Re: Must Set User Defined Payment in PAYMENT OPT. & RECEIPT

Post by cwathen » Tue Jan 28, 2014 9:45 am

Thanks so much for this Bruce, I've come across this in the past couple of weeks when I started taking PayPal and added it as a user defined type, thought it was a bug which would never get fixed now the DOS version is being put out to pasture. Now my customer receipts no longer have to have 'User Defined Tendered' on them!

User avatar
brucef2112
Forum Regular
Posts:336
Joined:Mon Mar 06, 2006 11:19 pm
Location:Broward County, Floriduhh
Contact:

Re: Must Set User Defined Payment in PAYMENT OPT. & RECEIPT

Post by brucef2112 » Wed Jan 29, 2014 8:15 pm

aawww.....
I feel so good knowing that 'ones of people' appreciate me in the latter days of DHPOS.
*bruce drys a "happiness tear" from his eye*

I figured out the workaround solution last week but I originally reported this bug back in April of 2011 along with some 'gift card' issues. I guess it must have gotten lost in the frenzee to fix important gift card stuff that was really broken.

Glad it helped the 'ones of people' using the user defined payment option.

BTW I define mine as "Store Credit" (and have my register set to allow split payments). Its very rare but as a courtesy to customers who return sealed merchandise but don't have a receipt, I ring the RETURN with a payment type of "Store Credit" (minus any promotional sale discount in the last year for that item). I then rubber stamp down the back of the RETURN receipt several times with the store's rubber stamp and I initial it. Then give them the RETURN receipt which shows "STORE CREDIT TENDERED".
Last item on our Return Policy sign says: Store credits are good for one year. Lost Store Credits receipts are not our responsibility.


To use the Store Credit they have to give us the RETURN receipt showing Store Credit Tendered. The STORE CREDIT amount is then used as payment for whatever they buy. And if additional amount is due, they pay cash or credit for the rest. If they try and return the 'new' purchase (thinking they'll get all of it back because they now have a sales receipt) they of course will get a split payment REFUND equal to the Store Credit Tendered plus their original other payment method. At worst for me is, they have worked the system to get another years grace to buy something they really want. I've never had any of these extremes. Most of the time they come back later that day or the next week or so to redeem.

For my own sanity I also have "history" enabled on my register so I can also verify trans # dates and time using the 5.Void feature.

Bruce
Later,
Bruce

They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
Benjamin Franklin - Historical Review of Pennsylvania, 1759

Post Reply

Who is online

Users browsing this forum: No registered users and 33 guests