Hello!
I was informed that as soon as a record hits the insert action in logic blocks it should have an NWID. However, when I try to use the NWID from the newly inserted record with a reference field of another insert (parent/child record) nothing populates. Is there a best practice of referencing/accessing the NWID of a newly inserted line in logic blocks?
Thank you!
@paul.villanueva @tom.m I thnk y’all touched on this a little during the summit last week if you have any insight. I think I saw us doing this through a variable in code before, but struggling to get it to work for me.
@ellen.kaufman where are you mapping the inserted nwid on the second input?
Into the text field nsCoxParentCore in another insert to the same table (ProcurementOrderDetail) @joe.graff
When you debug the logic block, do you see an nwid coming back from the inserted record? Is nsCoxParentCore a table lookup or just a plain text field?
Unfortunately the LB is on a workflow transition so I have not been able to hit the debug, but can set up a test LB to try if need be. The field is a plain text field which works in other scenarios where we set it from a fetch when the line already exists instead of being newly inserted.
If its possible, debugging would probably be useful. What youre doing should be valid
Unfortunately, I am unable to debug because of this ticket I just created Unable to see debug row action #431699
@joe.graff I have confirmed by writing a random string that his logic is getting hit and it is just not populating when I used the nwid from the insert. Should I write up a bug?
Yeah, if you could enter a bug for us to investigate that would be great, thanks
@joe.graff if the insert is associated with a temporary HD structure:
Would you also expect to get an nwId in that case?
Great catch @ian.p. @ellen.kaufman I should have clarified. When inserting to a temp table, you wont get any nwids back. Save HD is the only thing that will make these records “real” and cause them to have nwids.
Ah okay so then I am in a bit of a pickle here as I do want that connection between the two lines. What is the best practice here? Should I add additional saveHDs even if we are calling WritePurchaseOrders? Should I populate a temporary value and loop through again? Please let me know and thank you.
Or does it make sense to not use a temp table here and just create a new HD? I was not a part of the initial coding for this so will have to research the decision making, but would that be a valid approach?
Could you try linking them after the current save hd with an update action? Unfortunately there isnt anything to use to link them this way until the record has been committed to the database.
@ellen.kaufman I recommend the following:
Awaiting feedback on if using a New HD structure instead of a Temp HD structure is supported for WriteProcurementOrders as an alternative pathway.
Joe’s recommendation would also work, but to me that would mean making what looks to me like already an Inappropriate Intimacy code smell even more pungent.
Okay thank you both! I will wait to hear if using an New HD is valid as that would probably be the fastest change and we have pressing time for this feature, but if not look more into the other options.
New HD will present its own problems, particularly if you are performing the call without NATE turned on. Temp grants a lot of benefits for performance but has this drawback of not providing an nwId for immediate use.
Any of the above recommendations can work depending on circumstance, but every one feels like a workaround to a problem that probably shouldn’t exist.
Do you have multiple detail tables or just one? Are you trying to associate one detail line with another before calling the Procurement Orders API, and if so, what’s the use case for it? In other words, what is the goal of this development - we can determine an actionable solution from there.
Your problem could be solved with a trigger on the detail table that finds the detail it should associate to, but that relies on knowing which detail-detail relationship is necessary. If you have that information available before performing the call, you can just link the two detail records together in the temp HD structure using something like a CDA or other customized field. How best to do that or whether it’s even a good solution depends on the architecture and what your desired outcome is.
Hi Ross!
I could have multiple details in this case. The association between the parent and child line will be one to one though. I do not necessarily need the association before calling the PO API but there is no 100% definitive connection between the 2 lines if we do not insert in line with each other. Technically we could have multiples of the same parent and child and would have to rely on the item fields and line numbers if we do not have that connection from the initial insert.
