Claude featherstone - Clarification on “WRONG ORDER” figures in the Error Report

Lisa and Joey,

I wanted to follow through give some full closure on the cause and solution to the WRONG ORDER discrepancy.

When we first deployed this local database and began looking into it, immediately a discrepancy surfaced that made all of the data look like messy and inaccurate. The data itself was not inaccurate, but a large number of invoices were being flagged around “WRONG ORDER.”

Root cause:

• Some Item lines carry ITM.RETCODE
• Code 3 is looked up in RETCODES.DBF → text WRONG ORDER
• The database rebuild stores that as retcode / return_reason on sale items
• Error / returns reporting was treating any non-blank retcode as a reject/return, i.e. Ret Code 3.

So, these figures were so far above what we actually refunded it was causing a lot of confusion. At the end of the day, this was caused by a tag that was appended and applied in the supply-chain order process, RETCODE === 3 was being appended to large number of invoices, and our local database rebuild was treating every invoice with that code as a real reject/return.

As a result, legitimate orders were being counted as Wrong Order, which inflated the total and made the figure look like refund volume when it was a false flag.

We have corrected Insights so RET Code 3 is counted only on actual return documents. We know what an actual return looks like, so we won’t miss anything legitimate. Real refunds and other reject reasons are unchanged.

I can walk through this later this afternoon, however I wanted to send out a follow-up to this erroneous issue, and let you know guys know that we have resolved this.

Looking forward to the 1pm demo today.

Thank you,

Russell Dwyer