704n2 Bug in Sales Reprints, another in Return Receipts

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:
704n2 Bug in Sales Reprints, another in Return Receipts

Post by brucef2112 » Sat Mar 12, 2011 11:27 pm

Dale,
I found two items to check on. These are related to the printed receipts.
1. At the bottom of Return Receipts the method of payment back to the customer is not shown. ie CASH, CREDIT, DEBT,.......
It just shows a Total amount without any info about the payback type, such as found at the bottom of a Sales receipts.

Code: Select all

             sox in a box
           anywhere but here
             123-123-1234

=======================================
---------------------------------------
TRAN     ASSOCIATE                 TIME
0011                              21:28
0-13-----------------------------------
---------------------------------------
  STOCK NUMBER DESCRIPTION        PRICE
             1 item one                
 T1   -1    at     1.00ea.        -1.00
---------------------------------------
      -1    
              SUB TOTAL           -1.00
     TAX1  at  6.000%           -0.06
              TOTAL TAX           -0.06
                  TOTAL           -1.06
---------------------------------------
             CHANGE DUE            0.00
         Thanks a bunch!!!!!!!
               03-12-2011
Looking at the receipt or if looking in the jurnal, one doesn't know if this was given as Cash, Credit, Debit, or traded for a $1 cat.

2. A REPRINT of any receipt shows an incorrect CHANGE DUE amount. Reprinted SALES will show a negative value. For Reprinted VOIDS, PAYOUTS, and RETURNS it shows a positive value. If the transaction was paid with exact change, the CHANGE DUE is usually equal to a negative signed value of the tendered amount instead of zero.
To make it interesting, here is an example of a Sale with cash back on a credit card.
Sales Receipt on Left, REPRINT of Receipt on Right:

Code: Select all

                                           SALE REPRINT
            sox in a box                             sox in a box
           anywhere but here                        anywhere but here
             123-123-1234                             123-123-1234

=======================================    =======================================
---------------------------------------    ---------------------------------------
TRAN     ASSOCIATE                 TIME    TRAN     ASSOCIATE                 TIME
0002                              21:20    0002                              21:20
0-2------------------------------------    0-2------------------------------------
---------------------------------------    ---------------------------------------
  STOCK NUMBER DESCRIPTION        PRICE      STOCK NUMBER DESCRIPTION        PRICE
             2 item two                                 2 item two                
 T1   77    at     2.00ea.       154.00     T1   77    at     2.00ea.       154.00
---------------------------------------    ---------------------------------------
      77                                         77    
              SUB TOTAL          154.00                  SUB TOTAL          154.00
     TAX1  at  6.000%            9.24             TAX1  at  6.000%            9.24
              TOTAL TAX            9.24                  TOTAL TAX            9.24
                  TOTAL          163.24                      TOTAL          163.24
---------------------------------------    ---------------------------------------
              CASH BACK           20.00                  CASH BACK           20.00
            GRAND TOTAL          183.24                GRAND TOTAL          183.24
        CREDIT TENDERED          183.24            CREDIT TENDERED          183.24
             CHANGE DUE           20.00                 CHANGE DUE         -163.24
         Thanks a bunch!!!!!!!                    Thanks a bunch!!!!!!!
               03-12-2011                                 03-12-2011

If you look at the transaction on the VOID screen it is OK. This only shows if you actually REPRINT the receipt.


This may have been around for a while. But for testing/verifying I found these two issues using a fresh install of version 704n2.
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

User avatar
daleadmin
Forum Owner
Posts:1279
Joined:Tue Dec 30, 2003 9:47 pm

Re: 704n2 Bug in Sales Reprints, another in Return Receipts

Post by daleadmin » Thu Mar 17, 2011 6:55 pm

Bruce,

I have fixed issue #1 by changeing "IF PAYBY(A) > 0..." to "IF PAYBY(A) <> 0..." Pretty simple once I figured it out.

IT'S NOT A BUG, IT'S A FEATURE, Chapter 76, something about trombones?

The second problem was even easier to fix. Reprints will no longer print the "Change Due." Sometimes the simpliest solutions are the best.

If you are already using version 7.04n you can just download this file http://dhpos.com/pos.exe

or a full download from http://keyhut.com/pos3.htm

The POS.EXE file will be version 7.04n3

Dale

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

Re: 704n3 Bug Return w/Cash Back Enabled

Post by brucef2112 » Thu Mar 17, 2011 11:19 pm

Dale, checked it. Looks good. Nice fix! You are amazing,..able to fix a ton of bad with a single "<" key stroke! :lol:

BUT While testing the print/reprint fix I came across a great feature that could be included on the next MENSA intelligence quiz.
No one be intimidated. Everyone can play along!

First, set your POS to allow cash back on credit card payments. For extended play be sure to enable all forms of payments.

Now go to Returns and ring up a return for something.
Now choose pay by Credit. You'll be prompted for Credit Cash Back amount, enter a value greater than the return total. Before you hit [Enter]. What do you think the result is?....... I answered "potato".

If your POS is configured to not allow Multiple forms of payment per sale.
Hit [Enter] to accept the default amount the POS calculated you are then asked for a different amount to be credited to the credit card. Even though it really should be an amount charged to the credit card.

If your POS is set to allow Multiple forms of payment per sale then you are prompted for additional 'return payment' type (other than cash).
However there is no correct combination that finishes the sale with the proper cash back and proper charge to credit card for a return with cash back. Even if you pick DEBIT as the second payment type it does prompt on screen for a payment amount but the answer is still potato. (Q. did any member of MENSA try selecting CHECK as the second payment method for the balance?)

AT SOME POINT OF CONTINUING TO HIT [ENTER] (accepting the default amounts POS provides) IT WILL CLOSE THE RETURN WITH THE ORIGINAL AMOUNT. HOWEVER THE SALES PERSON MAY NOT SEE THAT THE CASH BACK WAS REMOVED AND IN TURN IT IS NOT RECORDED ON THE CLOSEOUT SCREEN AS CASH GIVEN BACK. A PROBLEM BECAUSE THEY MAY HAVE HANDED THE CASH OVER THINKING THE TRANSACTION WAS COMPLETED AS THEY THOUGHT.

I would say the fix is; There is no cash back with a return. Cash back to a customer is a courtesy during a PURCHASE. So the program should not prompt for cash back during a Return to a credit card. But then again I don't get out much as I've only visited earth, so others may disagree.

Dale, what is important is to ensure the crazy calculations that are occurring on the Return Screen with cash back aren't effecting or called somewhere else that may not be as obvious but still cause calculation errors.

By no means a big issue but a similar looping of 'Amount Due' is found if a customer (or customer and their shopping friends) uses 2 credit cards to pay. If they want to pay X amount on one CC and the balance on another (or friends) after entering the X amount the POS offers the balance due. But if you hit [enter] to accept the balance due it then reverts back to asking for the original X amount. The short of it is that the POS cannot do two cc as payment. only cc and another form.

Obviously the current solution to two CC is to process the second card for the amount shown and just enter in the grand total amount to close the sale in the POS. I only bring this up because it may be something to look at while considering the Cash Back thing above.

The best of luck to you Dale if you choose to fix the code to calculate a charge to the CC instead of an amount to be credited to credit card when doing a return with cash back!!!


Ohh and I like the BINGO game thats included with ver 704n3!!! :lol: Simple & FUN game!! but not F4 compliant :roll:


[Bruce turning to chapter 76]
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

User avatar
daleadmin
Forum Owner
Posts:1279
Joined:Tue Dec 30, 2003 9:47 pm

Re: 704n2 Bug in Sales Reprints, another in Return Receipts

Post by daleadmin » Fri Mar 18, 2011 7:25 pm

Bruce,

The BINGO.EXE program was not supposed to be in there, oops. But you can use it anyway.

I see your point about not asking for cash back on a return. I have fixed the program to not do that. Also while I was there I changed the program to not ask for approval for a restricted item being returned.

As far as using 2 credit cards on the same sale, that is not going to happen. Same with using a credit and debit card on the same sale. Life is harsh.

If you are using version 7.04n? you can download this after making a backup of your current file. http://dhpos.com/pos.exe This file is version 7.04n4.

Dale

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

Re: 704n2 Bug in Sales Reprints, another in Return Receipts

Post by brucef2112 » Fri Mar 18, 2011 10:35 pm

Dale, Thanks for the quick reply and fix!
As far as using 2 credit cards on the same sale, that is not going to happen. Same with using a credit and debit card on the same sale.
The multi payment method of Credit with Debit should be left alone. Don't break what has been working fine. Just as selecting any combination of the other payment methods are allowed. Credit and Debit are valid multi payment methods that work fine together. This includes return transactions. [EDITED - Although the POS Manual (pdf version) says on page 38 that Credit and Debit can't be used together, the program does allow this and has for some time now. I've used it before and it works just fine]

For the 2 credit card thing, nothing is really broken.
It just displays results that are a bit quirky as a salesperson tries to finish a cc sale if given two credit cards. The amount due turns into an endless loop of the final payment amount prompts if the user enters the balance due on the second cc payment instead of the Original Sales Total.

Example of the prompts work correct when closing a sales transaction using Cash and Credit Card.
Say total is $53.35.
1) Press [+] to Total. (payment options are displayed)
2) You Press 3. Credit. (prompted with 'Enter the Charge to CREDIT Card' and $53.35 is the default value pre-entered)
3) Enter in $20 and hit enter. (Total due now shows $33.35 and payment options are displayed again)
4) You Press 1. Cash. (prompted with 'Enter the cash tendered amount'.and $33.35 is the default value pre-entered)
5) You Hit [Enter] to accept the $33.35. (screen shows CHANGE zero but now prompts for Cash amount again with $33.35 pre-entered again)
6) If you hit [Enter] again the sale closes and goes to next sale. This asking for Cash amount a second time is a bit quirky but if you know to just hit the enter key again to get to the next sale all is OK we'll just move on.

Now try a customer with 2 credit cards.
Steps 1, 2, and 3 are the same (same results)
4) You Press 3. Credit as the second payment method. (Total Due shows $33.35 but you're prompted with 'Enter the Charge to CREDIT Card' and $53.35 is the default value pre-entered)
By looking at the Totals summary on the right side of screen one would expect to enter $33.35 and the program would close the sale as the second amount would leave a balance of zero.
However, this is where you can get the program to continue to loop. if you enter the $33.35 and hit enter it doesn't close the sale it prompts back again but prompting with the original $20 amount. Until you accept the default Original Total amount of $53.35 the sale will not close and go on to the next. Its not intuitive with the other info displayed as AMOUNT DUE. I'm not suggesting that anything be changed. I just want to point out that this is a bit quirky.

Another quirky scenario is seen if you try the first example on top except choose the CASH as the first payment. And Credit as the second.
After working through steps 1-4 , at STEP 5 the register is now prompting you for a CASH amount a second time.
I'm just pointing out that this a a bit quirky to be prompting for a cash amount after I've already tendered the balance of the total sales amount on the credit card.

This two credit card payment isn't reserved for just 1 or 2 crazy customers during the year.
People get Visa/Master cards with prepaid values as gifts, even companies use these prepaid V/M cards to fulfill their rebate offers. So there bunches of these pre-paid cards that regular people have and want to use up first before using their own credit cards. So, if the customer has one of these cards with x amount on it. Say they've been using it and the balance is $22.87. They make a purchase in my store which Totals $53.35. The POS system aside, we humans want to apply the $22.87 to the Total due and find the balance that should be charge to the customers other credit card. In the POS program it isn't an intuitive process based what the screen shows for Total applied, Total Due and the amount prompted for.

Again, I'm not calling for change. I'm just pointing out that the processing of multi payments and even the order in which they are entered can become a bit quirky or just doesn't have an intuitive flow based on what is presented on screen at a particular time.

[tested with version 704n3 , with multi payment method allowed]

thinkabou'it? fugettabou'it? lets move on?

nite
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 31 guests