Hello!
I'm running into an issue where several of our returns are unable to be invoiced resulting in the following error:
I've checked the Lot ID field on that item and all other items on this sales order to ensure it's not blank. It's not. The Return Lot ID field is also filled in on each item. I don't understand why I'm getting this error message if the field IS specified? Has anyone else encountered this problem?
*This post is locked for comments
It sounds like you have a good handle on it. It can be pretty uncomfortable doing this kind of surgery on a system, even when you're extra familiar with the data. I was glad to see you copied your LIVE environment in order to test out the changes. Often missing RecId's in what is otherwise a reliably continuous sequence also gives me a lot of confidence that I'm on the right track.
Glad I could help. Please mark as answered once you feel like the issue is resolved, or if you think this discussion could help others in the future.
I don't know much about ReturnInventTransOrigin either and honestly had trouble finding a good description of it online. At first I was concerned that the RecId I suspected was associated with that field but then several of the records leading up to this one did have InventTransOrigin and ReturnInventTransOrigin set to the same value.
Basically, the record causing the problem was a production order. Still not entirely sure why it's causing issues with our invoicing of returns. But I went to InventTransOriginProdTable and looked for the production order in question. It did not exist on this table, there was gap in the Production Order Id numbering AND in the RecId numbering where this record should have been. So I figured a new record needed to be constructed there, the record on InventTransOrigin seemed to already exist, and the record on InventTrans existed just with InventTransOrigin set to 0.
I copied our LIVE environment to our TEST environment to comfortably test this theory out. It seemingly fixed the issue and I tested sales orders, production orders, purchase orders etc. to check if I inadvertently messed something else up. Everything still seems okay so that's exciting!
Going to do a little bit more testing of typical workflows to make sure nothing's gone awry but I do believe this is the solution. Let me know if anything I did here raises a red flag for things to go wrong. I can't think of anything.
Yes, InventTrans.InventTransOrigin should point to InventTransOrigin.RecId. It's interesting that you already have an InventTransOrigin record with a RecId that you suspect was on the InventTrans record originally. Is it possible it's the correct InventTransOrigin record? Does it point to the proper return order?
I'm not familiar with the ReturnInventTransOrigin field.
Do you perhaps have an old backup you could restore into a test machine, and inspect these records at a point where they hopefully still exist and are valid?
Okay, great. So I thought I had everything figured out. I followed the sequence leading up to my InventTransOrigin record of 0. The number that would be next (5643413187) actually appears in the ReturnInventTransOrigin field. I also found a record in the InventTransOrigin table with 5643413187 as the RecId. Am I incorrect in thinking that the InventTransOrigin RecId should be the same value as the InventTrans InventTransOrigin value? I've been pouring through this data trying to determine what actually needs to be fixed and this seems odd to me.
If you want the sales order to work (to invoice), the InventTrans record will need to point back to a valid InventTransOrigin record, with a valid InventTransOriginSalesLine record, and all the correct fields (like ReferenceCategory and ReferenceId). It won't be enough to simply populate an InventTransOrigin number on the InventTrans record itself unless it points to valid records that are still there (seems unlikely).
I have been forced to do this kind of repair in the past. The InventTransOrigin record must exist also, and there aren't all that many fields to an InventTransOrigin record so they're not hard to reconstruct either. But, one of those fields is InventTransId, so you should ideally be able to link that back to some type of inventory movement, such as a sales order. Then you can supply the InventTransId, ReferenceCategory, and ReferenceId properly on the InventTransOrigin record. Then, you will also need an InventTransOriginSalesLine record, assuming it's attached to a SalesLine (notice how there are a bunch of different InventTransOrigin* tables).
But, I do think you're on the right track.
Okay, yes, I see. The debugger did confirm my suspicion that one of the records pulled up in the SQL query is what's causing the error. To remedy the InventTransOrigin of 0, am I right to assume that I need to put what would have been the correct number sequence into that field instead of the 0? Following the sequence, it would be 5643413187 and it doesn't look like that is being used for InventTransOrigin by any other record in the table.
As suspect, you're splitting an InventTrans record that has an InventTransOrigin of 0, it would seem.
Presumably now you know exactly which record, since the debugger would show you that if you walked up the call stack a bit.
I continued tinkering with it and was able to get the debugger to come up. Here is a screenshot of most of the call stack.
I also see a modified date and time in the debugger of 3/18 at 1:48:36 pm. When I check the SQL query you provided, the two entries that appear (and are seemingly unrelated to that specific sales order as far as the ITEMIDs go) as having InventTransOrigin = 0 have that exact modified date and time and as well.
Yep, I'm in the group and the debugger will pop up in other parts of AX but not this method.
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
#1
André Arnaud de Cal...
291,269
Super User 2024 Season 2
#2
Martin Dráb
230,198
Most Valuable Professional
#3
nmaenpaa
101,156
Share
Report
All responses (
Answers (