Voided order still in work tables

(0) Share

Report

Posted on by Community Member

The company I am currently working in is has Sales Order Processing Setup configured to Track Voided Transactions in History.

A user has reported a voided order still showing up on an open order report. When I investigated the order I noticed it still resides in the SOP10100 and SOP10200 tables. The VOIDSTTS column is set to 1 and it has a value for TRXSORCE.

I have tried running check links for the sales module and Reconcile - Remove Sales Documents (Remove Completed Documents) for the individual order number. The order still has not moved to history.

Any suggestions on what I can try or investigate next?

*This post is locked for comments

I have the same question (0)

All responses (11)

Answers (2)

Suggested answer

KirkLivermont 5,985 on at

Like (0)

Report

Steve,

I have seen something similar when the user doesn't properly close out of GP after voiding the document. Can you have the user log into GP, open the sales transaction entry window, and then close it? I suspect the void journal will print after this.

Regards,

Kirk

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Unfortunately this did not work. We opened and closed the window and no journal printed. We also tried to pull up the order but it just says it is voided.

Was this reply helpful? Yes No
Beat Bucher GP Gee... 28,058 Moderator on at

Like (0)

Report

Hi Steven,

Have you checked if the voided SO shows up in the historical tables too ? that would be SOP30200 & SOP30300..

I use the following script to check the data against a specific SOP document

use XYZ

declare @inv as varchar (21)

declare @cust as varchar (15)

set @inv = 'INV000872'

set @cust = '%'

print @inv

select sopnumbe, custnmbr, cstponbr, docdate, voidstts,prstadcd, * from sop10100

where sopnumbe like @inv and custnmbr like @cust --and voidstts = 0

select * from sop10200

where sopnumbe like @inv --and custnmbr like @cust

select sopnumbe, custnmbr, cstponbr, docdate, voidstts,prstadcd,* from sop30200

where sopnumbe like @inv and custnmbr like @cust --and voidstts = 0

select * from sop30300

where sopnumbe like @inv --and custnmbr like @cust

select * from sop10106

where sopnumbe like @inv

select * from sop10107

where sopnumbe like @inv

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

It only exists in the SOP10100 and the SOP10200. No entries found in any of the other tables you have listed in your script. At this point having the log of it in history isn't even that important. The order is tiny in relation to most our other sales. I just need to get it out of the work tables. What are the potential ramifications of just deleting the 1 record each of the SOP tables?

Was this reply helpful? Yes No
Suggested answer

Beat Bucher GP Gee... 28,058 Moderator on at

Like (0)

Report

Have you tried to set the VOIDSTTS field value back to 0 and try to delete the Sales Order from within GP..

As you said, Checklinks and reconcile didn't produce any significant result, so try that.

Take a full backup first of your company DB and set the flag back to 0.

Then see if you can delete in GP or Void it another time..

I've seen cases in 2013 where a posted SOP document would not set the void status, tough it was voided properly in GP, and showing as such in the inquiry window, but in the table, the value would still be 0.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

I have restored to a test company and set the VOIDSTTS field back to 0. When I attempt to pull up the sales transaction, it says "This document has been posted". But it cannot be found in the Posted Transactions window. I decided to try and also set the TRXSORCE to <blank>. Once I did this I was able to pull up the sales transaction entry and delete the record. The only thing that concerns me is where that TRXSORCE may be referenced. If the order never truly posted anywhere then the number may not show up anywhere. I guess check links would catch it if it were a problem.

Was this reply helpful? Yes No
Heather Roggeveen 9,146 on at

Like (1)

Report

Hi Steve

If you have inventory, and this order had inventory on it, you may need to run reconcile against your inventory. Check to see if anything is "allocated" and if so, if it is a valid record.

Cheers

Heather

Was this reply helpful? Yes No
Verified answer

L Vail 65,271 on at

Like (2)

Report

steve,

When I run into things like this, the first thing I normally do is to search the entire database for the document string. I use a FREE tool called APEXSQL search. It's FABULOUS and FREE! By using this tool I can easily identify all of the tables including the document of question. I typically have to end up adjusting something in SQL and the APEX Search tool will give you a lot of confidence that there isn't some speck of data that will come by and bite you in the rear. If you do any SQL work, it's a must have for any consultant.

Kind regards,

Leslie

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

WOW! Thank you Leslie, this is indeed a wonderful tool. I have found this value only exists in SOP10100 and SOP30100. I have also determined it is not allocating any quantity. I think it will be safe to continue with the plan to clear the VOIDSTTS and TRCSORCE columns using SQL then delete the order via GP.

Was this reply helpful? Yes No
Verified answer

Community Member on at

Like (0)

Report

Just wanted to post here what I finally did in case anyone reading is interested. After running several tests in a test environment I ended up setting VOIDSTTS to 0 and TRXSORCE to <blank> in SOP10100. Next I deleted the entry for the same TRXSORCE value in the SOP30100. GP then allowed me to void the document through the client and it moved to history. I did notice the void journal did not pop up until I closed the window as described by Kirk earlier in this thread. I am pretty confident the inconsistency was cause by the original user who processed the void. I will be doing some further training to avoid this in the future.

Was this reply helpful? Yes No