Greetings,
First some background, we have a custom report for our flex packages that uses line items in dummy houses to differentiate between different number of shows in packages. Our patrons order a 4-show, 5-show, or 6-show package and are put into a dummy house and then later, once each show has a finalized run, they exchange seats from the dummy into an actual performance in a new order. The report is written to not count line items with the VTO or RET status so any packages that are returned, are removed from the report but those exchanged (VOO) are still counted.
Unfortunately, one woman ordered 2 subscriptions and actually exchanged seats in both into the actual performance so even after both orders were fully refunded, her original order with the dummy house (the one the report looks at) still has one lineitem with a VOO sli_status and the report is therefore counting this as a 1-show package (which does not exist) and the total numbers are slightly off.
Here is my questions, can anyone think of any negative impact to going into the back end and manually changing the sli_status of this one lineitem so that it is no longer counted in the report? I would put thorough order notes in to explain the change that was made for historical purposes, but I can't think of any real negative ramifications aside from confusion if someone ever tried to look up this order for some reason (hence the order notes). Anyone have any other thoughts?
Thanks!
I think the best approach here is update the code in that compiles the report to properly handle VOO and RET status to give you an accurate count. Updating the orders status and noting seems like a questionable practice in my opinion.
Thanks Travis, but the problem with changing the report code is that VOO is what the status shows once a performance is moved from the dummy house into a regular performance, so those lines still need to be counted. this is one exceedingly rare loophole and I am not sure what kind of code edit would fix this issue without removing the functionality of the report...do you have any suggestions?
Without seeing the code I don't think I can offer up more on how to improve your counting. However, I do think there are other approaches to counting and setup such as, using keywords or perf type on the perfs to indicate dummy vs real in conjunction with sli statuses. But, we use dummies for subs prior to the season and move them to real perfs while dealing with exchanges and still able to count accurately and indicate whether it is a dummy or real. If you want to send the SP and setup details, I can certainly take a peek at some point.
I agree with Travis. If nothing else you could just make an exception for that one order in the report code along the lines of sli_no <> your_sli_no
That would get out this one pesky ticket without having to mess with a data change.
Sean
Thanks Sean,
I think an exclusion of that one exception is a good alternative for now. I think the report will eventually need to be re-written as Travis mentioned, but that isn't a high priority at the moment and I need a temporary fix which I think this is.