This post goes over basic customizing for the term deposit product. It assumes your company code and GL accounts already exist. There are many more nuances than what a blog post can explain but after reading this post the general idea should be clear. In the real world, you probably will end up using product 51A, the purpose of this post is to try to cover as much of the customization as possible as it gives the reader an opportunity to understand the full picture. I do not recommend you use this as a configuration guide for a productive system.
What is a term deposit?
Companies generally invest in term deposits to get a return on excess liquidities until the funds are required. The client and the bank agree on a term and rate upfront and short of paying a penalty or agreeing to a reduced rate, the amount won’t be available until maturity.
From a cash perspective, the client sends the bank the funds on the Term Start Date. On the Term End Date, the bank sends the funds back with interest.
Accounting for a term deposit
From an accounting perspective, the entries are as follow:
|Start Date||Investment Increase||Short Term Investment||Cash|
|Month End||Interest Accrual||Interest Receivable||Interest Income|
|Month End||Balance Sheet Revaluation (loss)||Unrealized FX Loss||Short Term Investment|
|Month End||Balance Sheet Revaluation (gain)||Short Term Investment||Unrealized FX Gain|
|Month End||Balance Sheet Revaluation (reset loss)||Short Term Investment||Unrealized FX Loss|
|Month End||Balance Sheet Revaluation (reset gain)||Unrealized FX Gain||Short Term Investment|
|End Date||Investment Decrease||Cash||Short Term Investment|
|End Date||Interest Receipt||Cash||Interest Receivable|
|End Date||Realized FX Gain||Short Term Investment||Realized Gain/Loss|
|End Date||Realized FX Loss||Realized Gain/Loss||Short Term Investment|
Before we can start customizing the product type, there are a few things to check. In FSCM-TRM-TM-General Settings-Organization: You have defined an appropriate Calculation Indicator and your company code is defined in “Define Company Code Additional Data”. You also have Portfolios and Traders defined; these fields are not mandatory but will be required by pretty much every customer for reporting purposes.
Define Company Code Additional Data
In FSCM-TRM-TM-General Settings-Accounting-Organization: You have defined at least one valuation area, an accounting code for the company code you want to use and assigned a valuation area and accounting principle to your accounting code. In this example, we will focus on US-GAAP in company code 1001.
Assign Accounting Codes and Valuation Area
This section is where you can enable parallel accounting. i.e. support US GAAP and IFRS at the same time as an example.
When you double click a line, you get to select settings that will impact the integration with FI.
“Accounting Principle” is a very important field as it indirectly controls which ledger group the “Accounting Code”/”Valuation Area” combination will post to. This assignment is defined in Financial Accounting (New)-Financial Accounting Global Settings (New)-Ledgers-Parallel Accounting-Assign Accounting Principle to Ledger Group.
With the housekeeping out of the way, we can finally start creating our new product type.
FCSM-TRM-TM-Money Market-Transaction Management-Product Types-Define Product Types The product type defines the financial instrument you are entering into. Examples of product types are Commercial Paper, Foreign exchange and Interest Rate Swap. One thing to note in TRM, is that for many objects there are categories and types. Types are customer defined and are the focus of customization. Categories are defined by SAP and effectively determine the boundaries of what is possible in TRM without enhancements. The product category for term deposits is 510. The standard programs will make assumptions based on this category and will pin down what processes are available in the financial transaction. As an example, you won’t be able to “knock-in” a term deposit, the developers at SAP have made that decision and that option will be greyed out in FTR_EDIT.
For many of the fields in customization, the F1 help is an invaluable tool. In some cases however, built in documentation is lacking and you will have to consult the SAP Note and knowledge base search site.
FCSM-TRM-TM-Money Market-Transaction Management-Transaction Types-Define Number Ranges Number ranges are defined for each company. Like number ranges elsewhere in customizing, it is a good idea to look at your overall requirements, what products you are trading, in what context (i.e. hedge accounting, cash management, etc.) and determine a numbering scheme that will make sense from a business perspective and potentially facilitate reporting. Transaction numbers are unique in the context of a company code. If your customer is coming from a different Treasury system, this may require some adjustment on their part as deal number is typically unique across all entities.
FCSM-TRM-TM-Money Market-Transaction Management-Transaction Types-Define Transaction Types Transaction types define the company’s position in the deal. For term deposits, you could have the option to invest or borrow. For Foreign exchange, you could select a spot or forward. For options, you could buy or sell. In this example, we will setup our product as an investment only.
The processing category determines if settlement (approval) is required. If you don’t select “Automatic posting release”, flows have to be release with TI90 before they can be posted. This function can be useful when the customer wants individual cash flows to be confirmed with the bank before being posted/paid. The “Permit premium/discount” switch allows for the initial payment amount to be different from the notional amount on which the interest will be calculated.
FCSM-TRM-TM-Money Market-Transaction Management-Flow Types-Define Flow Types Flow types are defined for the cash flows (actual or notional). Some flow types will be directly assigned to the transaction type as they cannot be derived from transaction information. As examples, the initial investment amount has to be a flow type because the system could not possibly derive it based on deal information. Fees and charges that are not based on a notional amount are another example. The front office person has to enter this information. As you will see later, there are other objects for derived cash flows such as interest flows, repayment or notional based fees. We still have to create these flow types, but they don’t have to be directly assigned to the transaction type. If you think back to the product category we used (510), there are certain flow type assigned to specific flow categories that have to be defined in order for the product to work. If you are missing mandatory flow types, SAP won’t let you create the transaction. By extension, if you add a flow type that the product category wasn’t built to handle, the system won’t know what to do with it and the result are unlikely to be what you were hoping for. In our simple example, we need principal increase, principal decrease, final repayment and interest. We assume there are no charges or amortization of those charges.
Assign flow types to Transaction Type
FCSM-TRM-TM-Money Market-Transaction Management-Flow Types-Assign Flow Type for transaction type As mentioned earlier, only flow types that are not derived need to be assigned directly. In our case, this is investment increase and decrease. Final repayment will be derived from the balance outstanding on maturity and interest is derived based on the principal and interest rate in the interest period.
FCSM-TRM-TM-Money Market-Transaction Management-Flow Types-Derived Flows You can use derived flows when a cash flow amount is based on another cash flow. Withholding tax is a great example. In some countries, interest payments will be paid short as tax will be withheld.
FCSM-TRM-TM-Money Market-Transaction Management-Update Types-Define Update Types and Assign Usages Update type is a key concept in TRM. You define update types for various usages. In this scenario, we will have update types for each flow types. In this context, the update types are used to integrate with the Financial Accounting module and to update the position components. Based on each product category, SAP will keep track of various position components. Position management is a topic for another blog post. Stay tuned! We need update types for each of our flow type. We will need more update types but we will come back to them as required. Because our example only handles investing in a term deposit, we will only require update types in compatible directions. If we also had borrowings, we would have twice as many to handle the opposite direction for every flow type.
All of our flow types are assigned to the “Transaction Management” usage
Assign Flow Types to Update Types
FCSM-TRM-TM-Money Market-Transaction Management-Update Types-Assign Flow Types to Update Types This step should be self-explanatory. For each flow type/direction combination, you assign an update type. You will need different update type for each combination as update type will drive the accounting postings and have a different impact on the position components.
FCSM-TRM-TM-Money Market-Transaction Management-Condition Types-Define Condition Types Condition types define the flows that are derived based on transaction or position information. The best example is interest. Interest is calculated based on an amount outstanding and a rate for a period of time. The Interest Condition defines the parameters to be used in the interest calculation. In our example, we need 2 condition types: final repayment and interest. The product category will expect certain condition types. As an example, product category 510 expects a condition with category 12 (Final Repayment) defined. If that condition is not assigned, an error will occur on deal creation. Also note that the “Generated Flow Type” is implicitly assigned to the transaction type once the condition type has been assigned in the next step. Assigning it in the “Assign Flow Type for transaction type” activity is redundant.
Assign Condition Types to Transaction Type
FCSM-TRM-TM-Money Market-Transaction Management-Condition Types-Assign Condition Types to Transaction Type Once again, this step is self-explanatory. It makes the link between the condition types we created and our transaction type.
FCSM-TRM-TM-Money Market-Transaction Management-Position Indicator-Define Generation of Subledger Position Indicator The position indicator is where TRM tracks internal positions. In the context of our example, there isn’t much to worry about and having the position indicator created automatically should work for the majority of use cases.
Default General Valuation Class
FCSM-TRM-TM-Money Market-Transaction Management-Assign General Valuation Class We won’t use this activity this time around. Just keep in mind that this is where you would select a default value in cases where multiple GVC are available for a transaction type.