In our previous blog Tip #5, we discussed Auxiliary Jobs that control transaction processing in SimCorp Dimension. In this piece, we will take a closer look at the transaction process and give you some tips and tricks we hope you find will useful.
The first part we will look at is what is called State Control in SCD. This allows you to control which fields are mandatory and which ones should be closed for input. The list of fields can easily become very large and challenging to maintain. Rather than listing all fields that should be mandatory or closed, you can make an exception list:
1) Create one line with the field in question
2) Leave the window field empty
3) Set closed or mandatory to (Always).
Then add lines for each window that should not be mandatory/closed. This is especially useful for model portfolios which you need for all transactions but is not applicable for cash transactions. An example would look like this:
On the transaction itself, you have the option to assign default values. This can be done on a user level in ‘Field Properties’ or on a user group level in ‘Default Values’ (right-click on a field to access these options). This is a great way to save time when testing or when manually entering data. But please note, the defaults only work when entering data manually in the windows, they do not work in create windows or in DFS imports.
One of the more advanced parts of defaults is the Conditional Default Value Formulas. These are defined similarly to the defaults described above. This allows you to define more advanced rules for your defaults using formulas. You can look up static data or partner data to determine what the value of a transaction-free code should be, adjust the date if certain conditions are met, define rules per portfolio, and much more. Again, as with regular defaults, this also does not work for transactions generated automatically in the ‘create-windows’. There is one exception to this which was introduced last year (2021): when maturing futures and forwards, these formulas work if the field is specified in ‘Transaction Options’ under the ‘Fields’ tab.
When opening a Dealer window, the option to ‘Show Deleted Transactions’ is not set by default. So if you are researching deleted (canceled) trades, remember to set this option on all the dealer screens you use. Often lower environments are refreshed from PROD, so it might be a good idea to do this once in PROD (if you have access), so it propagates down to the lower environments when these are refreshed.
This brings us to our last part: deleting transactions in bulk. You can of course load the transactions you want to delete in the single transaction window and press ctrl + D for each record, which is very inefficient if you have more than a couple of them. One option is the ‘Transaction Status’ window. Once you have defined the transaction you want to delete (either using segments or selecting them after the load), simply go under the functions menu and select ‘Delete Transaction’. This is very straightforward and is optimized for efficient deleting. By efficient we mean that it considers reversal chains, so it deletes the oldest transaction first and respects tax lots. However, if you have large volumes of transactions that need to be deleted, you can easily end up in a ‘workspace full’, and adding more workspace might not solve the problem. Instead, you can add your ‘Transaction Status’ window to multiple batch jobs, split by transactions and/or portfolio segments and that way create a parallel process to delete the data. Be careful to ensure there are no overlaps between the batch jobs, otherwise, you can end up with database locks which will just stall the process.
Please share with us any questions and suggestions you have regarding this topic in the comments.