Based on some findings I had in a customer scenario I just wanted to share same info on performance hints when using condition based org unit determination:
- Try to fill the org units compltly, even if not necessary: You may only need org units for the purchase org (or only for the execution org). However it is a good idea to fill both org units, in that case maybe with identical values. The background is, that the Before Save determinations try to complete incomplete org units, so if condition based org unit determination is active and either purchase OR exec org is missing, the detemrinaiton is called again. The background is that when doing the initial org-unit determination is executed the document might be incomplete and hence the condition does not have the input it needs Example: The condition used predecessor document info and the creation and the assignment of freight units are done in two steps, then the info is not available at creation time. In this case the org unit determination needs to fill up at save. In short: Try to maintain a Purchase and a exec org in the condition for org unit determination.
- Some of the TRQ-information can also be available in the Freight Unit, you may not have to navigate to the TRQ: The natural home of TRQ data is of course the TRQ. However some info is replicated into the Freight Unit Root, e.g. the TRQ category (Forwarding Order, OTR / DTR). Specifically in scenarios with many items the navigation to the TRQ is a bit costly (will become better with 9.5, as a sneek preview). If you have a Freight Order or Booking as starting point and the freight units are assigned directly to the freight order (no trailer or container unit involved), the most effective way to go to the FU_Root is the assoc ROOT->REQ_TOR
