Structure of Transactions in FSCD
Insights into the structure of main transactions and sub transactions in FSCD.
A transaction is a combination of main and sub-transactions. These combination determines the business process and is used for controlling the business process in the FSCD system. For e.g you can define the FSCD system to collect premium as cash or cheque. Likewise while making the claims payout you can define the payout in terms of transactions as one time claim payout or recurring payouts.
Thus with the help of main transaction and sub transaction the FSCD system recognizes the request for the business transaction.
The main transaction controls the determination of receivables and payable accounts.
You can view them in the table TFKHVO. You will have to define the values in Customizing to reflect in this table.
The sub-transaction controls revenue account determination, determination of the tax determination code, and of information about any additional accounts (business area, CO account assignment data).
You can view them in the table TFKTVO.
Maintaining the Main and Sub Transactions
A user is free to define new entries in this table for use for transactions not defined as ‘internal’ to FSCD. Internal Transactions shall be explained later in detail. These additional main and sub entries can be used in general ledger account determination.
You can also define whether the amount entered can be negative or positive. All postings in FSCD contain information on the business transaction in the main and sub transactions. You can assign additional attributes to the transactions in Customizing.
These attributes are copied in the business partner item when the posting is made and can influence the insurance business transactions.
You can also distinguish between the different receivable types by using different main and sub transactions in the document.
In the below e.g. I have defined my main transaction for Premium by giving the main transaction code as 1000 and in the similar way I can define the main transaction for claims payout as 2000.
Now in the sub transaction section I have defined sub transactions for every main transaction as shown below.
It is very important to note that these transactions are characterized by debit / credit.
The sub transaction is also required for the revenue account determination. This enables you to allocate different revenue accounts to one business transaction (i.e main transaction) by defining special sub transactions. It is also possible to allocate different revenue accounts for each company code and division.
The business area and sales/purchase tax code are defined in revenue account. Further account assignment characteristics (such as cost and profit centers) can be saved there using the CO account assignment key.
Internal transactions are those transactions which take place within FSCD.
The main examples of these transactions are charges, interest, payments on account, clarification postings, and so on. These main and sub transactions thus serve to provide parameters needed for the posting of these ‘internal’ transactions.
This function links each item with a main transaction to which several sub transactions are assigned.
For example (with reference to the below screenshots) , there is a main transaction “Charge” and associated sub transactions “dunning charge”, “return charge”, “return charge 1”, “return charge 2”, “correspondence charge”, “installment plan charge”, and so on.
Thus main transactions and sub transactions are used to identify items based on their type (such as interest and charge) as well as the business process from which they originated (payments, account statements, and so on).
Internal transactions are hard coded and are reserved by the FSCD system. Where as external transactions are user defined. For some of the transactions (shown in the above screenshots) which are internal can be assigned to the external transactions.
It is great that you publish some insides about SAP Collection and Disbursement (FS-CD) in SAP SCN. That's highly appreciated.
In addition I would recommend to explain some more FS-CD basics, especially regarding Main Transaction Keys and Sub Transaction Keys, which are crucial.
The most important structure that contains all attributes of an FS-CD Payment Plan Item is "SVVSCPOS_B" (Direct Input Structure of Payment Plan Items). The two most important tables in this regard are "VVSCPOS" (Payment Plan Item) and "VVSCITEM" (Bill Scheduling: Scheduling Document), from my point of view.
Any feeder system (e.g. FS-PM Policy Management, FS-ICM Commission Management, FS-CM Claims Management, FS-RI Re-Insurance Management) has to transfer every single to be paid receivable or payable - according to the attributes of the structure "VVSCPOS_B" - as a Payment Plan Item to FS-CD.
With other words: any to be paid premium receivable, premium-related discount payable, commission (remuneration) payable, indemnity payable, benefit payable, claim expense payable, clawback receivable, re-insurance treaty premium receivable (or payable), co-insurance share premium payable has to be transformed into a Payment Plan Item, and has to be transferred as such to FS-CD. The same principle applies to taxes (e.g. premium-based insurance taxes), or other receivables or payables that are insurance relevant.
Within FS-CD each Payment Plan Item is utilized to create an FS-CD Document, which can consist of one or mulitple Business Partner Line Items - as well as one or multiple General Ledger (revenue/expenses, or profit/loss) Items. In addition FS-CD offers strong Payment Plan features to distribute for example an annual Payment Plan Item according to the agreed Payment Frequency (e.g. monthly, quarterly, etc.).
Amongst further attributes the Main Transaction and Sub Transaction Keys are very powerful (and flexible) to control various Business Transactions, Processes, and Mass Activities in FS-CD. Therefore FS-CD provided different Posting Areas (for example see transaction "FQC0", and table "TFK033C"), where Main Transaction and Sub Transaction are decisive. The flow looks like: (1) Payment Plan Item > (2) Scheduling Item, if a Payment Plan exists > (3) FS-CD Document with one Document Header, one or mulitple Business Partner Line Items, and one or multiple General Ledger Items.
Please be aware that each Payment Plan Item FS-CD provides two pairs of Main Transaction (HVORG) and Sub Transaction (TVORG) Key fields:
HVORG: Main Transaction for Line Item
TVORG: Subtransaction for Document Item
OPHVORG: Main Transaction for Line Item
OPTVORG: Subtransaction for Document Item
This fact has high importance and impact. One the one hand you can define rough Main and Sub Transaction Keys for the Business Partner Line Item side, while leveraging Item Summarization (defined in FS-CD Customizing "Define Item Summarization Categories"), usually together with Item Grouping. On the other hand you can keep the General Ledger Item side very detailed, with fine granular differentiation on purpose.
Coming back to the FS-CD Business Transactions, Processes, and Mass Activities: almost all of them are controlled by the Main and Sub Transaction keys on part of the Business Partner Line Item side. Thus being said, overall one has to consider all perspectives cross FS-CD processes, mainly:
From this point of view it is valuable to elaborate on these two pairs of Main and Sub Transaction Keys carefully. In my opinion the provided FS-CD Sample Customizing, which is delivered together with the software in standard, doesn't fulfill fundamental requirements.
Sorry, it was built more than 15 years ago - at a point in time, when SAP didn't have FS-PM Policy Management, FS-ICM Commission Management, FS-CM Claims Management, or FS-RI Re-Insurance Management ... and didn't have sufficient operational insurance knowledge and experience with FS-CD (because it was a new component). I am even sorrier to say that this FS-CD Sample Customizing, which works properly from a technical view angle, has not been revised and reworked meanwhile.
From my point of view it would be a significant improvement, if SAP could get well thought productively used pairs of Main and Sub Transaction Keys from different insurance companies - with reasons and (legal or business) explanations, why they have been defined in this manner.