Nwid on logic block inserts

No-Code Platform
21

I do like the idea of adding an insert to the trigger instead of relying on inserting these details at this portion of the flow. That would give me access to the ID and require less updates in different places if this call is made externally for the same item scenario (core parent and core charge). Thank you for the suggestion!

22

The WriteProcurementOrders API should be able to handle a New HD or Temp HD structure.

1 Like
23

Thank you all for your feedback, I am going to test out various options to see what the best solution is here. I think using a new hd vs temp would be the most straightforward but recognize this would increase Inappropriate Intimacy in the code.

24

Would inserting details on the post insert trigger so the parent is always aligned with the child break WriteProcurementOrders? What I anticipate happening is the ‘real’ insert would happen within WritePOs and then adding an additional insert would still get looped through in the WritePO call, but not sure.

25

Something to test and determine how it works given your chosen implementation, but generally:

  • If you call WriteProcurementOrders with an HD structure and insert a detail record on the pre-insert trigger over ProcurementOrderDetail,
    • If NATE is on, the API will not recognize the existence of the newly-inserted detail
    • If NATE is off, the API could see the new detail depending on timing of interactions and processing of a new Fetch Detail Records, but this is not likely

Inserting a record to a table while in a trigger over that table is nuanced and I believe what Ian was referring to. I wouldn’t not personally recommend this approach.
I believe that usage of a New HD structure is not what Ian was referring to as being problematic - that is absolutely a known and accepted solution, it just comes with some other ramifications that should be understood during testing.

New HD is still the preferred approach if applicable.

If performance is absolutely key or a New HD will not work for some reason, my recommendation is still to use a custom field that links two details together before fetching each other and linking via trigger. This solves the problem of not knowing which records must be linked. My original question regarded multiple detail tables, not just multiple records, but it sounds like that isn’t the case.

26

I decided to just use a new HD instead of a temp HD after talking to the team and understanding the original necessity for a temp table is no longer in play. Thank you everyone for you input it is much appreciated!!

1 Like