We have an invoice, but noticed some wrong quantities on it. We want to transfer the invoice back to an order and then transfer to invoice again. How can I do this? Thanks.
Once it is an Invoice, you cannot transfer it back to an order. The only thing I think you can do is post it, return it and reorder it.
Leslie Vail, CPA, MVP, MCT, MCITP, MCP, MCITSASCI, Inc. * PO Box 600965 * Dallas, TX 75360 * 972-814-8550 * email@example.com
Is this the only way? Or can we change the SQL tables to achieve the wanted result?
We only need to be pointed to the right tables.
What do I need to post? How can I do that? It's already an invoice.
By post, I meant post the invoice you have, process a return against that invoice and then re-enter it with the right numbers.
Now, doing it from the back end. hmm Everything will be in the SOP work tables, the SOP1XXXX tables. The header, that indicates the document type sits in SOP10100 type 2 is an order, 3 is an invoice.
You would also need to change the document type ID so that it matched a valid Order type. I've never done, nor even thought about doing this. It's an intriguing possibility. I might have to play with this one.
Well, this will be my final feat for the night (morning). Here's what I did to change and invoice back to an order and then transfer it back to an invoice. Mind you, this was an experiment on my part because you posed an interesting question. Not something I can recommend for real life.
SOP10100 (SOP header record)
SOPTYPE = 2
DOCID = STDORD (this is a Fabrikam doc ID)
USDOCID2 = STDINV (this is a Fabrikam doc ID for the Invoice)
SOPSTATUS = 1
SOP10200 (SOP line records)
SOP10101 (Sales Commissions)
SOP10102 (Sales Distributions)
SOP10105 (Sales Taxes)
SOP10107 (SOP User Defined)
You would need to look at each of the tables in the SOP WORK series (at least) to make sure there wasn't anything else you need to change. I used a SQL statement that searched the database for the invoice number so that I could tell which tables it lived in.
I transferred it and posted it. Inventory decremented correctly and my master numbers still work. I've probably forgotten something big, but neither check links nor reconcile had a spat at me.
So, in conclusion, you could go for it and bet the bank, or just post it, return it, and redo it. Doing it through the 'back end' goes against all things good and fine in the GP world (but it did transfer and post :))
Hi Leslie and Along,
Looks like you were successfully able to change the document back to an order! That is good news!
The only question I have is what happened to the original order? Did the order go to history when you transferred it to an invoice? If so I'm guessing when you transfer the document back to an invoice, when the document you manipulated (now an order) tries to move to history it might just error out on you stating the there is a duplicate. So before you move the order to an invoice you might want to check the SOP30200 and SOP30300 for that original order. If it's there you might want to delete it from history (as well as any other associated tables) so you don't have issue when transferring.
The only other workaround to this whole thing would have been to transfer the invoice to a backorder and then the backorder to an order. The document number would be different, but at least it would be back to an order that you could change.
Hope this is helpful!
The original order went to history when it was originally transferred to the invoice. The Invoice itself was turned into an order. When that order (former invoice) is transferred to an invoice it will go into history. The risk on duplicates is if they had a numbering scheme that would cause the numbers to cross.
As for using a backorder, heck, where's the sport in that <grin>?
Is there any possibiity of bumping into this 'NEW' order number in the future. Let's say it was originally order number 1000 which got turned into invoice 10,000. Now 10,000 now exists as an order number and will be turned into invoice 20,000. I could see what the sequence numbers could start bumping into one another.
Richard E. Wheeler 2013 MVP
MS Dynamics GP Support
www.rbsolutions.com Revered Business Solutions Ballston Lake, NY 518-877-0763 x10
That is what I meant by "The risk on duplicates is if they had a numbering scheme that would cause the numbers to cross."
In my world, the numbering sequences don't collide, they have different prefixes. But, yes, that is a risk.
Other Microsoft Sites
I'm a Customer
I'm a Partner
Use the official Twitter tags:
#MSDYNCOMM | #CONV13