Hi,

We have a mixed cart... meaning download items and boxed items. We also get many incomplete orders that show as Open, but show False as status because someone did not complete their PayPal purchase. And all these False PayPal attempts are showing up in our product reports, throwing things way off.

We do not want reports filtered by <> cancelled because that is not accurate, and we can't have someone manually go in and change each sale to Cancelled (that is not practical for an automated cart).

The Product Summary sales report should ONLY look at APPROVED or True for the status, which would give us an accurate report. Or, Status <> 'Cancelled'  AND Smith_PayHist.Status <> 'false'... or more easily done,  WHERE... AND (PayHist.Status = 'APPROVED' or PayHist.Status = 'true').

Now all our sales reports are very inaccurate. Is there anything you all can suggest to make the reports accurate asides from manually going through any failed PayPal sale and converting them to cancelled?

This is quite important....

Thanks,

Steve

Hi Kevin,

Thanks for the reply...

Why could you just not base the report by joining the PayHist table and use APPROVED OR TRUE as the 2 values for the report? That would be 100% safe. I can only imagine how many are paying out false royalties to vendors, etc, based on this, or spending extra money on accounting time. I really think it is important to fix.

I see the stored procedure but I just do not know how to do the join code to add the PayHist table to the query and using the Approved and True flag as the value to allow it to be calculated. This is much more safe than using simpy Canceled as the filter.

I think one way I can try to fix this is to run a query under a timer at the server that checks the cart every so often... maybe every 15 minutes, that automatically adds Cancelled to the table on any order that is not converted to true maybe after 20 minutes.

But I can still see many getting false reports unless they go through all sales manually before running a report or by manually running their own query on the server or something. I really think you should change the query so all reports are accurate for everyone.

Or maybe you could just tell me the line to replace in some of the queries to Join in the PayHist table so we can change it ourselves if required.

I have to admit I know know basis SQL syntax... not inner joins and things like that.

Thanks,

Steve