Hi @ARNDUP ,

I have checked your issue in a standard reference environment of our latest version of IFS Cloud (24R1). However, I did not encounter any noticeable slowness when searching with SSCC in Inventory Transaction History screen.

Could you kindly provide further details such as the product version that has this issue so that we can investigate further? Additionally, I would recommend you to update the system to the latest version since performance enhancements are being continually added with new releases and service updates.

Regards,
Kethaka

Hi @KethakaG;

We are in 22R2 SU17.

Note that we currently have 18M rows in the inventory_transaction_hist table after only 6 months in PRD.

Upgrading IFS is not planned right now. 

Regards 

Doing this from the old IEE client in Apps10 would show that searching for SSCC here would be a bad performance choice (see picture, the red and green arrow indicate the performance hint). Since this column is not saved in the database and is fetched using a function call.

I’ve would guess that the only way to get good performance in this case is to use the real key for handling unit which is the Handling Unit ID instead. Or maybe limit the possible number of records by narrowing the search with more values like Site or Part No perhaps.

Hi @Dario Zani; 

Thanks for you answer. Unfortunately, it is impossible for us to use the Handling Unit ID to do the searches. 

As a view can be made by joining several tables, don’t you think that adding SSCC in the view INVENTORY_TRANSACTION_HIST2 could be an improvement ? 

Thanks 

Regards 

Hi @ARNDUP 

I think you should bring this thru support if you want the experts to look at it, I just gave you some suggestions for workarounds.

Impossible sounds strange since its just an extra manual step you need to do every time you want to get the Handling Unit ID from the SSCC by opening the handling unit client and search for that SSCC, but yeah if this happens thousands times each day its a bit of a hassle to do that.

I’m not sure that it would be a good idea to join 2 of the largest tables together just so you would have SSCC searchable in a faster way, it would probably create more performance issues that help in this case. And just adding a function call to get SSCC in INVENTORY_TRANSACTION_HIST2 would be the exact same thing as it works now. Only idea would be too look at how INVENTORY_TRANSACTION_HIST3 is handling this with a so called in-line select for SSCC instead, that usually have a better performance than function calls, but not sure how much it would help in a search situation if its still not part of any index or saved directly in data source for  for INVENTORY_TRANSACTION_HIST.

But please take this thru our support.