*This post is locked for comments
Announcements
*This post is locked for comments
Hello Jim
While following up with my cases, I found this one ... Pretty old I guess :)
I am really curious to know how things went with you
Mahmoud,
Fantastic response! Thanks so much for testing! I'm just starting my testing on my test server this week. I will keep you up to date as to the progress. Thanks again!
Jim
How is the progress of this interesting issue
Looking forward to hearing your kind feedback
Hello Jim
As derived from the complexity of lot number tracking process in Dynamics GP, and the degree to which it is involved in several distribution modules such as purchasing, sales, inventory, manufacturing ..etc. The test has been limited only to POP, SOP and IV lots. The lot number tracking primary tables, on which all the modules depend for open cost layers is (IV00300), this tables retrieves primarily form (IV10200) for the items with lot number tracking option enabled, and available quantity on hand.
Other modules, stores historical lots and details since the open lot table (IV00300) get cleared out when the lot is consumed. I have followed the following testing criteria and here are my results:
USE TWO
INSERT INTO dbo.IV00300
( ITEMNMBR ,
LOCNCODE ,
DATERECD ,
DTSEQNUM ,
LOTNUMBR ,
QTYRECVD ,
QTYSOLD ,
ATYALLOC ,
UNITCOST ,
RCTSEQNM ,
VNDRNMBR ,
LTNUMSLD ,
QTYTYPE ,
BIN ,
MFGDATE ,
EXPNDATE
)
SELECT A.ITEMNMBR ,
A.TRXLOCTN AS LOCNCODE ,
A.DATERECD ,
A.DEX_ROW_ID AS DTSEQNUM ,
A.DEX_ROW_ID AS LOTNUMBR ,
A.QTYRECVD ,
A.QTYSOLD ,
0 AS ATYALLOC ,
A.UNITCOST ,
A.RCTSEQNM ,
A.VENDORID ,
0 AS LTNUMSLD ,
A.QTYTYPE ,
0 AS BIN ,
'1900-01-01 00:00:00.000' AS MFGDATE ,
'1900-01-01 00:00:00.000' AS EXPNDATE
FROM dbo.IV10200 AS A
LEFT OUTER JOIN dbo.IV00101 AS B
ON A.ITEMNMBR = B.ITEMNMBR
WHERE B.ITMTRKOP =3 AND A.QTYRECVD-A.QTYSOLD <> 0 AND A.RCPTSOLD <> 1
Furthermore, proceed with the usual reconciliation and check links as a must in such a case.
Finally, as I previously mentioned, I do not recommend this solution as a work around, but it would be application in case further testing is applied. For the mean time, you may proceed with creating a testing environment , and apply the testing scenario.
Keep me posted on your findings,
Looking forward to hearing what's hiding beneath your database records, since your it has gone through a lot and we never know how things would go with you :)
I shall do a full cycle test and keep you updated
I will get back to you shortly
Mahmoud,
I'm finally getting around to fixing this because our inventory control people want to do another round of changing non-tracked to lot-tracked. Regarding your original recommendation, I want to go with option 2 and create dummy lot numbers. Can you advise how to go about doing this? I know it's not the cleanest way of doing this, but if I could cut down the number of problems I have with turning on/off tracking so users can sell/receive, etc. it would be an enormous help.
Thank you in advance!
Jim
Mahmoud,
I presented the information to our inventory control team and they are going to make a decision on what to do. I think we're going to go the route of backing out all inventory. Once we complete, I'll give a follow up. For now, I'll confirm your answer.
Thanks!
JIm
Jim
Any updates regarding your case ?
When posting a sales transaction with items tracked by lot numbers, the sales transaction is moved to history immediately, while lot details are stored in SOP10201, These details remain in history even if a return for the sales transaction is made afterwards. Meanwhile, you need to take into consideration that the RMA will store lot details in SVC05255.
Never hesitate to share any further inquiries,
Mahmoud,
What do you know about items that were sold (SOP Docs moved to history) and then items are returned via RMA? Would you agree that those historical transactions would need to have a lot number assigned?
Jim
Almas Mahfooz
3
User Group Leader