SAP Collections and Disbursements (FS-CD)
Overview of FS-CD Master Data
© SAP AG 2014, Jochem Schueltke
1. SAP Collections and Disbursements (FS-CD)
The SAP for Insurance software application ‘Collections and Disbursements (FS-CD)’ provides proven functions to insurance companies and re-insurers for automated cash relevant posting and payment processing, in particular
· posting all to-be-paid receivables and payables that are insurance related,
· processing customer-initiated incoming payments (e.g. cheque, incoming bank transfer, or electronic fund transfer),
· creating insurer-initiated incoming payments (e.g. direct debit, debit memo procedure, credit card collection, or deposit account withdrawal),
· creating outgoing payments (e.g. outgoing bank transfer, electronic fund transfer, or money transfer to credit card),
· balancing (offsetting) receivables with payables through automatic account maintenance,
· managing depositaccounts, including automated withdrawal,
· posting and settling coinsurance premium shares, related commissions, and charges,
· posting and settling incoming or outgoing payments with third parties, which do collections or disbursements on behalf (e.g. Broker Collections and Submitting Receivables to Collection Agencies),
· creating and issuing correspondencethat is related to postings (e.g., invoice, account statement), payments (e.g. payment form, payment note, receipt, outgoing cheque, outgoing payment advice, direct debit notification), or to exceptions (e.g. reminder, dunning letter, return notice, deferral and installment planagreement), and
· Updating general ledger, based on summarized documents as well as reconciliation with financial accounting, considering all cash flow relevant insurance related receivables and payables as well as associated revenues (profits) and expenses (losses).
SAP Collections and Disbursements supports various lines of insurance business, insurances types, currencies, incoming and outgoing payment methods within one system. On the one hand it is designed for automated billing and payment handling, especially regarding high volume of transactions. On the other hand all master data and transactional (posting) data contain detailed attributes, especially to apply different legal and business rules. These rules can be configured customer-specific, utilizing reasoned SAP Customizing in combination with robust enhancement possibilities, if required.
2. FS-CD Master Data ensure fast and accurate high-volume processing
Different policy management systems, claims systems, commission systems, re-insurance systems and other calculating as well as operationally leading insurance systems can be integrated into one SAP Collections and Disbursement instance. For example different policy administration systems, claims management systems, commission systems, or re-insurance systems - used within a group of affiliated insurance companies - can be integrated into one and the same SAP FS-CD system and client.
Any feeder system can collaborate real-time (online) with FS-CD, mainly depending on its capabilities. Therefore SAP offers appropriate eSOA Enterprise Services for Insurance Billing and Payment, or alternatively classical Business Application Programming Interfaces (BAPIs), exposing Remote-Function-Call-enabled Function Modules (RFC). In addition these RFC Function Modules can be encapsulated into Web Services and exposed through Web Service Technologies in the Application Server (please see also ABAP Web Services).
In addition FS-CD includes powerful outbound interfaces named ‘Information Containers’, which can send structured information to different external systems, primarily for submitting FS-CD process results. These Information Containers are intended to transfer data back towards various feeder systems - either near-time, or scheduled automatically at a later point in time. FS-CD can also trigger external functions, which are provided by these feeder systems, if they are able to be ‘controlled remotely’ (e.g. they provide RFC Function Modules that can be called out of FS-CD).
But real-time integration and operation is not mandatory, but strongly recommended. Over and above FS-CD provides ‘traditional’ methods to transfer data, especially through file transfer via Direct Input.
Also mixed scenarios are broadly supported, which combine for example [A] real-time creation and maintenance of FS-CD Master Data, utilizing Enterprise Services or RFC Function Modules in combination with [B] classical file transfer, utilizing Direct Input for high-volume transactional data (so-called ‘Payment Plan Items’, please see Interface and Data Transfer Toolsand Payment Plan Interface).
Overall SAP Collections and Disbursements comprises high-performing mass processing. To guarantee extensive automation, while taking detailed legal and business rules into account, FS-CD provides meaningful Master Data, as follows:
II. FS-CD Contract Accountwith its relationship to Business Partner
III. FS-CD Insurance Object with its relationship to Business Partner
IV. FS-CD Payment Planassigned to an InsuranceObject-BusinessPartner-Relationship
On the strength of these Master Data FS-CD is able to process Transactional Data (Payment Plan Items) ‘autonomously’; presupposed that a feeder system delivered these Master Data and the Transactional Data (Payment Plan Items). Thereafter FS-CD doesn’t need to permanently call the relevant feeder system, or to be called from each feeder system for executing each and every transaction. Altogether these Master Data and Transactional Data guarantee self-reliant billing and payment processing, while minimizing data exchange with various feeder systems, and avoiding back and forth for business process control. Because of these Master Data hold powerful attributes to control FS-CD processes, they are named ‘Control Parameters’.
With respect to these control parameters FS-CD can handle transactional data accurately without ‘asking’ a feeder system over and over again, or without ‘getting told’ from a feeder system what and how to do for each and every transaction in particular.
When an FS-CD Documentis processed in any transaction or mass activity, the control parameters of the relevant ContractAccount-BusinessPartner-Relationship, InsuranceObject-BusinessPartner-Relationship, and – optionally – Payment Planare considered on principle. The direct impact of Master Data is already evident, when one or multiple Payment Plan Items are transformed into a posted Document.
Based on my experiences many consultants and customers often underestimated the power and flexibility of FS-CD Master Data. They tried and still are trying to control billing and payment processes primarily by transactional data; means through Payment Plan Item attributes, which are persisted in each Business Partner Line Item (within an FS-CD Document). In a couple of implementation projects this approach caused disproportional extra implementation effort as well as unnecessary complexity.
Thus being said, studying FS-CD Master Data including their Control Parameter is a valuable exercise, which charges off shortly.
3. FS-CD Master Data
3.1. Business Partner
Each posting and transaction in FS-CD is related to a particular Business Partner. Moreover the ID of a Business Partner is the primary key in almost all FS-CD tables, not only for Master Data, but also for Transactional Data (Postings). In terms of data modelling a ‘Business Partner’ is a business objects that belongs to the SAP software component with the same name ‘SAP Business Partner’.
In context of FS-CD all Business Partners are relevant that act as insurance-related debtors, creditors, payers, payees, or correspondence recipients with regards to billing, collections, or disbursements. In insurance terms these Business Partners are for instance: policy holders, alternative premium payers, insured, beneficiaries, group or collective insurance parties (e.g. employers, employees, or associations), agents, brokers, claimants, injured parties, service partners, doctors, hospitals, appraisers, adjusters, repair shops, rental car companies, towing services, partner insurers in co-insurance, re-insurers, and other payers or payees.
SAP Business Partner Master Datais essential from a business or legal perspective as well as from a technical point of view in FS-CD. All Business Partner data, which are utilized in any context of Collections and Disbursements, have to be persisted in the SAP component named SAP Business Partner. SAP Business Partner is a basic software application that is seamlessly integrated into all SAP for Insurance software components. SAP Business Partner must be installed, configured and used operationally within one and the same SAP System where SAP Collections and Disbursements (FS-CD) is also running.
The SAP Business Partner is the central SAP application for saving and managing all customer information. Business Partner can be created using the regular SAP User Interface (e.g. SAPgui, SAP NetWeaver Business Client, please see Dialog of SAP Business Partner), as well as through different interfaces (please see Maintaining SAP Business Partner Data, Replication and Synchronization of Business Partners, and SAP for Insurance - SAP ERP Central Component - Release 6.0 - Release Notes).
Thus being said, all required business partners and their attributes can be created and completely maintained ‘remotely’ from any external system or software application, which has appropriate capabilities. Overall it’s possible to operate SAP Business Partner in ‘slave’ mode, including entire data maintenance; means controlled by an external Non-SAP system, please see General Introduction to BAPIs (CA-BFA) and SAP Enterprise Services WIKI - Business Partner. In addition these ‘traditional’ BAPIs can be wrapped easily into Web Services and exposed through Web Service Technologies in the Application Server (please see also ABAP Web Services).
SAP delivers three different predefined Business Partner Categories: ‘Person’, ‘Organization’, and ‘Group’. In general a Business Partner can only be created in one of these three Categories. Subsequent Change - after creation - of an initially selected Category is not supported in standard.
Business Partner data include name and address, payment transaction data (e.g. bank details, payment or credit cards), supplementary data depending on the Business Partner Category (e.g. date of birth as personal data for a natural person, or legal form as company data for an organization), Business Partner Roles, legitimation data, creditworthiness, ratings, fiscal year information, partner numbers in external systems, and Business Partner Relationship(for example husband and wife, father and son, company holding and subordinated subsidiary, company and contact person).
A Business Partner can have multiple Business Partner Roles in parallel. With other words: you can assign different roles in parallel to one and the same Business Partner. Each Role can be time-independent, or time-dependent; means autonomously.
For technical reasons the role ‘Contract Partner (MKK)’ needs to be assigned to all Business Partners, which are relevant for FS-CD in general – independent from the fact whether they are debtors, creditors, payers, payees, or correspondence recipients. This can be done via default assignment, which is applied automatically, when a Business Partner is created.
Every Business Partner can have multiple Addresses in parallel, if required. Each address can have its own valid from date and valid to date. At least one address has to be maintained. If several valid addresses exist in parallel, only one of them can be marked and used as the Standard Address, at a certain point in time. An explicit move regarding the Standard Address is supported out of the box.
You can allocate a specific Address-Usage to an address, which can be configured project-specific. The assignment of an Address to a particular Address-Usage provides a valid from date and valid to date; means the usage can be made time-dependent.
A Business Partner of Category ‘Organization’ can be assigned to multiple Industries in parallel, but just one as the Standard Industry. It is possible to configure a customer-specific Industry System.
Cross all Categories a Business Partner can be identified by one or different several Identification Numbers (Identifiers) in parallel. SAP delivers several proposals of ID Types (e.g. passport), which can be configured and enhanced customer-specific. Per ID Type a dedicated validation check can be implemented. SAP delivers some sample validation checks.
You can assign a Tax Number, or if required several Tax Numbers in parallel to a certain Business Partner. Therefore SAP delivers some country-specific Tax Number Categories that provide appropriate validation checks accordingly, which can be enhanced customer-specific.
Furthermore SAP provides also a ‘Where-used List’ for business partners. It gives an overview where a Business Partner is used, in relation to other business objects (e.g. policy, claim, commission contract, contract account, re-insurance treaty) cross software components. The ‘Where-used List’ can be accessed either from the business partner master data, or using the SAPphone functions. From the list, one can branch to the various related business objects, to which the business partner is linked. It is possible to add customer-specific where-used relations and attributes without modification.
All Bank Details of a Business Partner (e.g. policy holder, premium payer, beneficiary, and claimant) are persisted within the Master Data of this partner. With other words: if a Business Partner holds several banking accounts in parallel, all of them are stored within his or her ‘Payment Transactions’ data (that are an essential part of Business Partner Master Data). Thus, the technical reference that points to a certain banking account of a particular business partner consists of both, the ID of this Business Partner and the ID of his or her Bank Detail.
The same principle applies to payment cards or credit cards; means all payment cards of a Business Partner are also stored within his or her Payment Transactions Master Data.
In general Bank Details and Payment Cards (Credit Cards) belong to a certain Business Partner, which shall be the holder of each bank account or credit card that is persisted within his or her Business Partner Master Data. With other words: if a husband is the policy holder - Business Partner ‘A’ - related to a certain policy, but his wife pays the premiums via direct debit (using her bank account), you must notstore her bank details within his Business Partner Master Data. Instead the wife has to be reflected as a separate Business Partner ‘B’, maybe with an appropriate Business Partner Relationship (e.g. has husband) to Business Partner ‘A’. Moreover the Business Partner ‘B’ must be assigned and utilized as an alternative Payer, together with the reference that points to her Bank Details (e.g. ‘0001’).
In this regard SAP provides a central data structure named ‘BUS_DI (Business Partner: Transfer structure)’ that contains all Business Partner related attributes. It corresponds to the RFC Function Module ‘ISCD_PARTNER_MAINTAIN’ to create and maintain Business Partner Master Data from any external system or software application. Please consider also the Business Partner Interface for Direct Input, which provides you with an overview.
3.2. Contract Account with Relationship to Business Partner (ContractAccount-BusinessPartner-Relationship)
The central place regarding all postings in FS-CD is the Contract Account; means all to be paid receivables and payables are posted on a Contract Account. It acts as a container for all FS-CD Documents. A Contract Account is the ‘hub’ to manage billing (invoicing), payment and clearing (offsetting) transactions, controlled by general Master Data attributes. In terms of data modelling a Contract Account is a business object that belongs to the SAP software component SAP Collection and Disbursements (FS-CD).
From a business perspective an FS-CD Contract Account is a universal ‘subledger account’ to post all cash flow relevant receivables, payables, incoming payments, outgoing payments, clearings, resets, and cancellations utilizing FS-CD Documents. In this context ‘universal’ means that an FS-CD Contract Account can be used for all lines of insurance business, and for all categories of receivables, payables, incoming payments, or outgoing payments – such as premiums, deposits, commission payables, claims payables, benefit payables, claw backs, subrogations, charges, taxes, or interests for instance. And it can be linked to all business partner categories, which are debtors, creditors, payers, or payees related to the entire insurance business.
In general a Contract Account can’tbe created autonomously, but must have a relationship to at least a Business Partner (ContractAccount-BusinessPartner-Relationship).
SAP provides several attributes within the Master Data on level of a Contract Account itself; means these control parameters are partner-independent (see cross-partner Control Parameters on Contract Account level). Technically these attributes are persisted in table ‘FKKVK - Contract Account Header’. Amongst other control parameters these are: Contract Account Category, Outside Account View, and Account Management.
The Contract Account Category is a control parameter that belongs to the cross-partner Contract Account Master Data (Contract Account Header). It defines contract accounts, which have the same fundamental characteristics. When a Contract Account is created, it is assigned to a Contract Account Category. You can’t assign another Contract Account Category to an existing Contract Account after it has been created.
The Outside Account View is a control parameter that belongs to the cross-partner Contract Account Master Data (Contract Account Header). It is a criteria for grouping items when Invoicing, and for the Payment Program. Following two view types are supported:
· Individual view
If Individual View is set as ‘Outside Account View’ the items that are posted on a Contract Account are grouped by each Insurance Object, so that an own invoice (using the Invoicing function) or direct debit, debit memo, and outgoing bank transfer (using the Payment Program) is created separately per Insurance Object with its Relationship to Business Partner. Thus, the Insurance Invoicing as well as the payment program considers the Insurance Object as a key differentiator.
This principle can be strengthened and applied also to other FS-CD transactions and further mass activities. Within Master Data of all InsuranceObject-BusinessPartner-Relationships, which are assigned to one and the same Contract Account, you can set the collections and disbursements parameters as well as the correspondence parameters ‘active’ on level of the Insurance Object. In this case the control parameters, which belong to the Master Data of an InsuranceObject-BusinessPartner-Relationship are decisive for steering FS-CD transactions and mass activities. Thus, the Insurance Invoicing as well as the Payment Program considers the Insurance Object (with its relationship to a Business Partner) as a key differentiator.
· Collective view
If Collective View is set as ‘Outside Account View’ all items that belong to a Contract Account are grouped on level of the Contract Account itself; means cross different Insurance Objects. Even if several Insurance Objects (with their Relationships to a Business Partner) are assigned to one Contract Account, you can create an invoice, direct debit, debit memo, or outgoing bank transfer that includes all items that are existing on this account. Thus, the Insurance Invoicing as well as the Payment Program considers the Contract Account (with its relationship to a Business Partner) as one unit.
Within Master Data of all InsuranceObject-BusinessPartner-Relationships, which are assigned to one and the same Contract Account, you can set the collections and disbursements parameters as well as the correspondence parameters ‘active’ on level of the Contract Account. In this case the control parameters, which belong to the Master Data of a Contract Account or a ContractAccount-BusinessPartner-Relationship are decisive for steering FS-CD transactions and mass activities.
In general each Contract Account must have a Contract Account Relationship with at least one Business Partner, which is the Holder of this Account. The appropriate Relationship Category ‘is Holder’ is intended for this case. Except Deposit Accounts you can assign several different Business Partners in parallel to one and the same Contract Account. That means multiple further Contract Account Relationships can exist with different other Business Partners in parallel, but these are based on the Relationship Category “is other Partner”.
Only one Business Partner can be the Holder of a Contract Account (Relationship Category). Of course the Holder of a Contract Account can change over time; means that the Contract Account Relationship ‘is Holder’ for this Contract Account can be switched to the ‘is other Partner’ Relationship Category regarding Business Partner ‘A’, if another Business Partner ‘B’ assumes the Contract Account Relationship ‘is Holder’ at the same time.
Thus being said, SAP provides various control parameters within the Master Data on level of a ContractAccount-BusinessPartner-Relationship; means differentiated per Business Partner that is related to a Contract Account.
Technically these attributes are persisted in table ‘FKKVKP - Contract Account Partner-Specific’. Amongst other control parameters these are <excerpt>: Company Code Group, Standard Company Code, Incoming Payment Method, Alternative Payer, Bank Details ID for Incoming Payments, Outgoing Payment Methods, Alternative Payee, Bank Details ID for Outgoing Payments, Own Bank Details, Alternative contract account for collective bills, Dunning Procedure, Dunning Strategy, Contract Account used for Payment Transactions, Authorization Group, Tolerance Group for Contract Account, Clearing Category for Clearing Postings, Clearing Restriction, and Correspondence Variant.
In this regard SAP provides a central data structure named ‘FKKVK_DI (Contract Account: Transfer Structure)’ that contains all General Data on level of a Contract Account itself (Header, cross-partner) as well as all attributes on level of its Relationship to a certain Business Partner. This structure corresponds to the RFC Function Module named ‘ISCD_ACCOUNT_MAINTAIN’ to create and maintain Contract Accounts with their Relationships to Business Partners from any external system or software application. Please see also the Contract Account Interface for Direct Input, which gives an overview.
Considering these different attributes and their impact on controlling FS-CD transactions and mass activities, it’s obvious that the more detailed control parameters belong to the ContractAccount-BusinessPartner-RelationshipMaster Data (not to the cross-partner Contract Account Master Data).
Master Data of a ContractAccount-BusinessPartner-Relationship can be changed automatically by certain business transactions. In this way, for example, a return (refusal) subsequent to a faulty direct debit (or debit memo procedure) can result in a temporary payment lock being set within this Master Data - to avoid processing of the next insurer-initiated incoming payment too soon, for instance when a payment run is scheduled on daily basis or twice a week. That’s a matter of FS-CD Customizing, which can be decided and implemented customer-specific.
3.3. Modelling Contract Accounts and Relationships
From an FS-CD perspective a Contract Accountis the entity to post and balance (offset) all open items, aggregate invoices or process payments that are initiated by the insurer (e.g. direct debit, outgoing bank transfer), or by the customer.
On the one hand it’s possible to clear open debit and credit items with each other automatically (based on detailed rules), which are posted on different Contract Accounts, if they belong at least to one and the same Business Partner.
On the other hand several fundamental prerequisites have to be fulfilled for supporting this approach, and also relevant control parameters must be identical in ContractAccount-BusinessPartner-Relationship Master Data and InsuranceObject-BusinessPartner-Relationship Master Data. For example, the Clearing Variant must not contain the Contract Account as a grouping or selection criteria. That’s very unusual in practice.
Leveraging FS-CD basic features you can control balancing (clearing, offsetting) of open items, invoicing, creation of correspondence, and payments (by payment program) straightforward within a Contract Account, in particular if the items are related to one and the same Business Partner. Therefore no extra Customizing or configuration effort is required.
In this regard modelling of Contract Accounts has high importance as well as high impact on FS-CD transactions and mass activities. Under this view angle one has to consider various aspects to decide for an appropriate Contract Account structure, such as:
· If a group of affiliated insurance companies consists of several legal entities (Company Codes) that could process collections and disbursements jointly: what aggregation is permitted cross companies? What separation is mandatory? Moreover, can one insurance company act on behalf of one or several other companies in collections and disbursements (e.g. the life insurance company collects also premium on behalf of the property and casualty insurance company)?
· How does an insurer – a single legal entity (Company Code) – organize its billing and payment processes overall, for instance strictly divided per line of business (e.g. separated in Life Insurance, Property and Casualty Insurance, and Health Insurance - if operated by one insurer), per individual insurance business versus group (collective) insurance business, or per customer segments (customer target groups)?
· What types of insurance related debits (receivables) and credits (payables) can be posted on one and the same Contract Account, based on legal and business rules? For instance: premium receivables, discount payables, charge receivables, commission payables, indemnity payables, claim expense payables, or benefit payables. What receivable types and payable types must not be posted on one and the same Contract Account in general?
· Which receivables and payables can be balanced (cleared, offset) automatically with each other, of course considering detailed clearing rules? In contrast which of these receivables and payables must not be balanced with each other, in general?
· How does an insurer want to aggregate invoices (bills), which are created based on posted open items in FS-CD, as far as allowed?
· How does an insurer want to summarize incoming payments or outgoing payments, which are initiated by the insurance company (e.g. direct debit, debit memo procedure, credit card collection, outgoing bank transfer), presupposed aggregation is legally permitted?
· How does an insurer receive payments, which are initiated by policy holders, premium payers, or other payers (e.g. by cheque, incoming bank transfer, or cash)? How are the bank accounts that the insurer holds are structured in this context?
· On what - segregated or aggregated - level does an insurer want to create invoices, payment notes, notes to payers, and other billing or payment relevant outbound correspondence in FS-CD?
· Does the insurer manage policies, which can contain several different subordinated contracts per policy?
· Is it possible that a certain Business Partner is the policy holder of several polices in parallel, which are all based on the same (sales) insurance product? If yes, is it mandatory to keep invoicing, clearing, and payment processing strictly separated by policy? Or is aggregation cross policies even welcome in such a case?
· What is the legally relevant Dunning level, if overdue premium receivables are not paid, or just partially paid (e.g. Business Partner, Policy, or Contract)? What is the maximum allowed ‘superordinated’ dunning level (e.g. all items for the combination of one Business Partner and one line of insurance business)?
· What is the link (reference) between a policy, or a contract and an associated claim?
· On what level an open premium receivable could be balanced automatically - based on rules - with a to-be-paid indemnity, benefit, or claim payable (that refer to the same policy or contract), if permitted? Or in which cases an automated clearing (offsetting) isn’t allowed, but could be processed manually?
All these aspects need to be considered, before FS-CD Master Data are modelled. Furthermore the capabilities of all feeder systems and data quality play a very important role in these regards. Accurate data is essential and required to derive suitable Contract Account Variants, even for scenarios that appear simple at first glance.
Structure and differentiation of Contract Accounts can deviate between several countries significantly, mainly according to law and justice. Furthermore it depends on customer-specific contractually agreements with policy holders (premium payers, insured, beneficiaries, claimants, etc.) as well as General or Special Terms and Conditions, if either more detailed segregated Contract Accounts, or more aggregated Contract Accounts are advisable.
For instance separate Contract Accounts per customer segment (e.g. private clients, small and medium enterprises, large enterprises) insurance types could be adequate (e.g. divided into Life Insurance, and Non-Life Insurance), if items have to be managed strictly separated. It could be also the case that a particular insurer, which is a ‘member’ of an affiliated group of insurance companies, is responsible only for one line of business. But the group of companies share one and the same Business Partner data commonly (cross lines of business). If these insurers process billing and payments independent from each other, separate Contract Accounts are strongly recommended.
Furthermore it can make sense to specify different Contract Accounts with separate Contract Account Categories, in terms of business purposes or legal insurance relationships, for instance:
(1) A ‘Premium Contract Account’ with relationship to a policy holder, an alternative premium payer, a collecting third party (e.g. agent, broker, or employer); It is intended only for premium receivables and payables (e.g. discounts, refunds, paybacks).
(2) A ‘Commission Contract Account’ with relationship to an intermediary (e.g. captive agent, independent agent, broker, affiliate, or affinity); It is intended only for commission and compensations payables.
(3) A 'Claim Contract Account’ with relationship to a policy holder, claimant, beneficiary, an injured party, a lawyer, a hospital, a clearinghouse, an accounting center, or a claim service partner; It is intended for claim, indemnity, or benefit payables as well as for reclaim or claw-back receivables (e.g. deductibles, retentions, franchises).
(4) A combined ‘Premium and Claim Contract Account’ with relationships to all relevant business partners mentioned before. In this context ‘combined’ means that one and the same Contract Account is used for premium receivables as well as for claims payables.
For instance there is a particular Contract Account mapped 1:1 to an FS-PM Policy and vice versa. This FS-PM Policy contains three subordinated FS-PM Contracts. Each of these three Contracts is reflected as an Insurance Object in FS-CD. Thus, there are three InsuranceObject-BusinessPartner-Relationships of type 'FS-PM Contract’, which come from SAP Policy Management (FS-PM), assigned to that Contract Account.
In addition there are two Claims in FS-CM. Each of these two Claims is reflected as an Insurance Object in FS-CD. Thus, there are two further InsuranceObject-BusinessPartner-Relationships, which come from SAP Claims Management (FS-CM). They are also assigned to this Contract Account. Maybe the first Claim belongs to Contract ‘#2’, and the second Claim belongs to Contract ‘#3’. Finally all these five InsuranceObject-BusinessPartner-Relationships are assigned to one and the same Contract Account.
Since all these five InsuranceObject-BusinessPartner-Relationships belong to one Policy, it’s possible to clear all debit and credit items with each other - automatically - according to legal and business rules, based on accurate FS-CD Clearing Control (if permitted). If some of these debit and credit entries must not be balanced with each other, one can consider precise rules per Clearing Step, considering the Clearing Type and the Clearing Variant on line item level, if necessary. Please be aware that the Clearing Variant is an attribute of the Master Data within the ContractAccount-BusinessPartner-Relationship. Thus, one can set a specific Clearing Variant per type of a policy (e.g. according to a Sales Product, or to a line of business).
Optionally such a Contract Account can be arranged on level of the Business Partner that is the Holder of this Account. In this case it’s a ‘Business Partner Contract Account’ for all policies and claims, cross lines of business (e.g. for ‘Pooling and Netting’).
(5) A ‘Third Party Collection Settlement Contract Account’ with relationship to a third party that collects premiums on behalf of the insurer (e.g. collecting captive agent, independent agent, broker, collection agency, or employer); It is intended for aggregated settlement of summarized receivables and payables as a result of third party collection, using FS-CD features and functions for Broker Collection or for Submitting Receivables to Collection Agencies.
(6) A ‘Co-Insurance Settlement Contract Account’ with relationship to other insurers that are partners in active or passive co-insurance; It is intended for co-insurance premium shares, claims or benefit shares, commission shares, and charges or expenses.
Usually the business object Contract Account is not known on part of feeder systems, not even the concept of a cash-flow oriented subledger account, including its relationship to a Business Partner.
Very often it’s challenging to convince the sovereigns of policy systems, claim systems, or commission systems to enhance their data model and processes accordingly, especially for seamless data exchange and bi-directional integration with FS-CD – even the entire organization will benefit from these adjustments.
Moreover it takes considerable extra effort to ‘carve out’ billing or collection and disbursement functions, which are inbuilt within home-made ‘monolithic’ policy systems, claim systems, or commission systems that maybe were developed many years ago. This exercise starts always with Master Data. Thus being said, the modelling of Contract Account needs to be done thoughtfully, and is not just an unimportant auxiliary implementation project task.
3.4. Insurance Object with Relationship to Business Partner (InsuranceObject-BusinessPartner-Relationship)
From a business and legal point of view the Insurance Object– together with the InsuranceObject-BusinessPartner-Relationship– is the most important reference in insurance business regarding billing and payments. An Insurance Object is also the ‘anchor’ for administering and controlling billing (invoicing), payment and clearing (offsetting) transactions on detailedMaster Data level. In terms of data modelling an Insurance Object is a business object that belongs to the SAP software component SAP Collection and Disbursements (FS-CD).
From a business and technical perspective an FS-CD Insurance Object is a lean ‘proxy object’. It reflects and persists an extract of all billing and payment relevant attributes, which are created and maintained within an original business object of type insurance policy, insurance contract, claim case, benefit case, commission contract, re-insurance treaty, deposit agreement, or third party collection contract (e.g. collection agreement with a broker or an agent that collects premiums on behalf of the insurer). With other words: different feeder systems manage polices, contracts, claims, benefit cases, commission contracts, or re-insurance treaties. These business objects contain – amongst other data – also billing and payment relevant attributes or basic characteristics, which are mirrored on part of FS-CD by an appropriate Insurance Object; means it represents a subset of the genuine business object for billing and payment purposes.
Therefore FS-CD provides in standard five predefined internal Insurance Object Categories, as follows:
I. 10 – Insurance contract (policy)
II. 20 – Broker contract (third-party collection agreement)
III. 30 – Commission contract
IV. 40 – Claim number
V. 50 – Deposit contract
The first internal Insurance Object Category ’10 - Insurance Contract (Policy)’ characterizes an insurance policy or contract in FS-CD, which is originally managed in a policy administration system like SAP Policy Management (FS-PM) for instance. In SAP Policy Management (FS-PM) the original business object is an FS-PM Policy, or an FS-PM Contract (that is configurable per Sales Product).
The second internal Insurance Object Category ’20 - Broker Contract (third-party collection agreement)’ describes an agreement between an insurance company and a third party (e.g. broker, agent, employer, affiliate, or association) that collects premiums on behalf of the insurer. These agreements are usually managed by other in-force business administration systems, often including a link to commission agreements (contracts) or to claim settlement agreements and authorities. If, and only if the legal and business content of such an agreement is very simple and restricted, it could be an option to implement it inside FS-CD; means as the leading system. Otherwise FS-CD provides a proxy of such an agreement, which is originally administered by an insurer-specific feeder system.
The third internal Insurance Object Category ’30 - Commission Contract’ characterizes an agreement between the insurer and an intermediary (e.g. broker, agent, financial service advisor, bank advisor, or affiliate) regarding commissions and incentives related to insurance business. Such a contract is usually administered by a commission system, like SAP for Incentive and Commission Management (FS-ICM) for instance. In SAP for Incentive and Commission Management (FS-ICM) the original business object has the same name ‘Commission Contract’ as its proxy in FS-CD.
The fourth internal Insurance Object Category ’40 - Claim Number’ describes a claim or benefit case, which is created and handled in an appropriate claims or benefits management system, like SAP Claims Management (FS-CM) for example. In SAP Claims Management (FS-CM) the original business object is a ‘Claim’, which is represented in FS-CD by its proxy ‘Claim Number’.
The fifth internal Insurance Object Category ’50 - Deposit Contract’ characterizes an agreement between an insurer and a policy holder, premium payer, or other party about payments, interest and withdrawal of a credit balance that is assigned to a specific Contract Account (Deposit Account). This Deposit Account is managed by the insurer. Regularly it’s used to consider advance payments for ‘financing’ upcoming recurring premiums, while granting interests on the remaining money - until it is consumed, or increased with another advance payment. Such a Deposit Account is always directly linked to an Insurance Object of Type ‘Deposit Contract’. FS-CD provides comprehensive features and functions to maintain Deposit Contracts in conjunction with Deposit Accounts. In addition FS-CD provides the Payment Method ‘Internal Clearing / Deposit Account’ out of the box. Overall FS-CD can be utilized as the leading system for managing Deposit Contracts and Deposit Accounts.
From a technical perspective the crucial table on level of the Insurance Object itself is ‘DIMAIOB (IO: Header Data for Insurance Object in FS-CD)’. Amongst other attributes it contains the External Insurance Object Category.
An Insurance Object can’t be created autonomously, it must have a Relationship with at least one Business Partner (InsuranceObject-BusinessPartner-Relationship). The Relationship itself doesn’t have a particular category or another differentiation characteristic in standard.
If an Insurance Object is linked to two or more Business Partners in parallel, all relationships are equivalent to each other; means they are not distinguished into ‘is Holder’ versus ‘is other Partner’.
FS-CD fully supports external number ranges to identify any Insurance Object. If an insurer has non-overlapping number ranges for different business object types (e.g. Business Partner, Policy, Contract, Commission Contract, Claim, etc.), then the original number can be used – and shall be used – as the ID of the Insurance Object. For example the original Policy Number of a policy, which is managed for instance in SAP Policy Management (FS-PM), can be utilized 1:1 as the identifier for the Insurance Object that represents this original policy as a proxy in FS-CD; means without prefix or suffix. Of course SAP strongly recommends to keep number ranges disjunctive, regarding all identifiers that are assigned to different business object types – especially if they will be represented by a proxy Insurance Object in FS-CD.
Regarding the InsuranceObject-BusinessPartner-Relationshipone of the fundamental tables is ‘DIMAIOBPAR (IO: InsuranceObject-BusinessPartner-Relationship in FS-CD)’. Almost all control parameters are persisted in this table like for instance: Dunning Variant, Correspondence Variant, Invoicing Type, Base Date for Invoicing Frequency, Payment Plan Key, Payment Option Key, Alternative Payer, Address Number for Alternative Payer, Incoming Payment Method, Bank Details ID for Incoming Payments, Alternative Payee, Address Number for Alternative Payee, Outgoing Payment Methods, Bank Details ID for Outgoing Payments, Clearing Account, Payment Card ID for Incoming Payments, or Payment Card ID for Outgoing Payments.
- In general an Insurance Object can have multiple relationships to various Business Partners in parallel. With other words: multiple relationships can exist between several different Business Partners and one and the same Insurance Object.
- Various InsuranceObject-BusinessPartner-Relationships (between one Insurance Object and different Business Partners) can be assigned to one Contract Account. At least one of these Business Partners (e.g. policy holder) must be linked to this Contract Account as its Holder, whereas each other Business Partner is just linked as other Partner.
- Alternatively, you can assign each InsuranceObject-BusinessPartner-Relationship to a separate Contract Account. This assignment doesn’t depend on the fact, whether the linked Business Partner is the Holder or just another Partner related to the Contract Account.
Thus, you can assign the Relationship between Insurance Object ‘IO-1’ and Business Partner ‘BP-1’ to the Contract Account ‘CA-2’, which has the HolderBusiness Partner ‘BP-2’. Then Business Partner ‘BP-1’ must be linked to the Contract Account ‘CA-2’ as other Partner(Contract Account Relationship Category).
Moreover you can allocate the Relationship Insurance Object ‘IO-1’ ↔Business Partner ‘BP-1’ to the Contract Account ‘CA-1’ and the second – parallel – Relationship between this Insurance and Business Partner ‘BP-2’ to the Contract Account ‘CA-2’.
In this context SAP provides a central data structure named ‘DIMA_A_DI (Structure for Insurance Object)’ that contains all general data on level of the Insurance Object itself (Header, cross-partner) as well as all attributes on level of its Relationship to a certain Business Partner. This structure corresponds to the RFC Function Module named ‘FSCD_INSOBJECT_MAINTAIN’ to create and maintain Insurance Objects with their Relationships to Business Partners from any external system or software application.
3.5. Modelling Insurance Objects and Relationships
In addition to the five predefined internal Insurance Object Categories you can define various meaningful external Insurance Object Categories customer-specific. Each of them has to be mapped to a dedicated internal Insurance Object Category in FS-CD Customizing. The internal Insurance Object Categories are predefined by SAP and fixed, please see paragraph “3.4Insurance Object with Relationship to Business Partner (InsuranceObject-BusinessPartner-Relationship)”. When initially creating an Insurance Object (with its relation to a Business Partner), an external Insurance Object has to be assigned. This assignment can’t be touched afterwards; means you can’t change or delete the external Insurance Object Category assignment within a particular existing Insurance Object.
At the latest when specifying external Insurance Object Categories you should also give attention to appropriate Contract Account Creation Rules. A Contract Account Creation Rule determines the way how a Contract Account is going to be created automatically by FS-CD itself, when an Insurance Object (with its relationship to a certain Business Partner) is created - whereas the creation of the Insurance Object is usually triggered by a feeder system. Overall Contract Account Creation Rules provide different approaches how Contract Accounts are structured, especially for assigning Insurance Objects either to different Contract Accounts, or to one and the same Contract Account (for example: all FS-PM Contracts that are mapped 1:1 as Insurance Objects in FS-CD, which belong to one super-ordinated FS-PM Policy that is mapped 1:1 as a Contract Account in FS-CD). Therefore several Contract Account Creation Rules consider the Contract Account Category or the external Insurance Object Category.
Segregation or aggregation of external Insurance Object Categories depend mainly on fundamental characteristics of the genuine business objects. Following two examples should illustrated this interdependency:
· 1stExample: direct distinction between different business object types
For instance a policy is created on part of an in-force business administration system initially as a ‘Homeowners Insurance Policy’ (as an instance of a defined insurance product). Subsequently it’s not possible to change the ‘type’ of this existing policy into ‘Private Auto Insurance Policy’ or ‘Accident Insurance Policy’ for instance, while keeping the identical policy number as before.
èIf this restriction is applicable in general, you can define a separate external Insurance Object Category in FS-CD Customizing per type of insurance product; means it reflects the original product differentiation, for example ‘HO - Homeowners Insurance Policy’, ‘PA - Private Auto Insurance Policy’, and ‘AI - Accident Insurance Policy’. Each of these externalInsurance Object Categories have to be mapped to the internal Insurance Object Category ’10 - Insurance contract’.
· 2ndExample: superordinated distinction between different business object types
For instance a policy is created on part of an in-force business administration system initially as an ‘Endowment Life Insurance Policy’ (as an instance of a defined insurance product). Subsequently it is possible to change the ‘type’ of this existing policy into ‘Term Life Insurance Policy’, while keeping one and the same policy number as before. Thus, an important characteristic of the policy can be changed on part of the policy system, despite one and the same policy number is used after this endorsement. Here, the initially underwritten policy isn’t terminated, but changed substantially and continued in a different shape.
èIn this case the highest level of - disjunctive - consistency at the policy system (and product definition) must be utilized for defining suitable external Insurance Object Categories in FS-CD. Of course they should be meaningful. If the highest level is ‘Life Insurance Policy’ for instance (where a change can be made in the policy system, while keeping the identical policy number as previously), then also for example ‘LI – Life Insurance Policy’ has to be defined and utilized as an external Insurance Object Category in FS-CD Customizing.
In this case ‘Life Insurance’ is the compatible super-ordinated term and also the appropriate external Insurance Object Category in FS-CD. It contains the two subordinated exchangeable products ‘Endowment Insurance’ and ‘Term Life Insurance’, and maybe further life insurance products. Under this prerequisite it doesn’t matter on part of FS-CD, if the policy is changed at the in-force business administration system basically - but carries on the same policy number as before. Considering a thoughtful mapping the external Insurance Object Category doesn’t need to be changed within the existing Insurance Object. (Otherwise this would harm SAP standard.)
Overall it’s valuable to define well thought external Insurance Object Categories, because they can be used to differentiate control parameters in each and every InsuranceObject-BusinessPartner-Relationshipeasily, and to populate them automatically when an Insurance Object is created (for instance: Dunning Variant, Correspondence Variant, Invoicing Type, Payment Plan Key, or Payment Option Key).
In many scenarios there is just one relationship required between an Insurance Object and a Business Partner. Depending on legal and business rules there is maybe just one policy holder that is identical to the premium payer; means only one Business Partner is assigned to a policy in all billing and payment relevant roles. In such a case one InsuranceObject-BusinessPartner-Relationship is sufficient.
In contrast to such an elementary scenario you can model complex scenarios differently, by leveraging the option to create and maintain multiple InsuranceObject-BusinessPartner-Relationships in parallel.
· 1stExample: One Policy is linked to two Business Partners (Debtors, Payers) in parallel
Imagine there is a Professional Liability Insurance Policy, reflected as an Insurance Object in FS-CD (e.g. using the external Insurance Object Category ‘Professional Liability Insurance Policy’).
It has a policy holder in form of a commercial partnership as one unit, represented by a specific Business Partner ‘A’ of Category ‘Group’. Additionally ‘A’ has Business Partner Relationships to two Business Partners ‘B’ and ‘C’ with Category ‘Person’.
Each recurring premium receivable shall be paid by these two different Business Partners ‘B’ and ‘C’ separately, divided by 70:30. The Policy Holder - Business Partner ‘A’ - doesn’t pay premiums. The first premium payer - Business Partner ‘B’ - gives the permission for Direct Debit (Debit Memo Procedure), and the second premium payer - Business Partner ‘C’ - provides his Credit Card details for insurer-initiated collection.
Both Premium Payers ‘B’ and ‘C’ are responsible for their premium shares on their own. Moreover they request billing and other correspondence separately (maybe by tax law reasons). Overall both Business Partners ‘B’ and ‘C’ are not just alternative Payers in parallel, but also debtors regarding their premium receivables. The policy admin system is able to manage these relationships and the percentage premium shares. Thus, it is easy to create and maintain three appropriate relationships in FS-CD for all Business Partners ‘A’, ‘B’ and ‘C’, of course linked to one and the same Insurance Object.
Consequently both Business Partners ‘B’ and ‘C’ will get their own invoices as well as other correspondences created out of FS-CD. And every payment run will separate all items (premium receivables) by different Business Partners, different Payment Methods for Incoming Payments, and Bank Detail for Business Partner ‘B’ as well as Credit Card for Business Partner ‘C’.
In such a case it could make sense that each of these three InsuranceObject-BusinessPartner-Relationships is assigned to one and the same Contract Account. The Holder of this Contract Account ‘CA-1’ is Business Partner ‘A’ (policy holder). In parallel both Business Partners ‘B’ as first premium payer and ‘C’ as second premium payer are attached to it each with other Partner. Then all documents are posted on one and the same Contract Account, but they are strictly distinguished by each Business Partner. Since the policy holder doesn’t pay premiums, there are no documents related to Business Partner ‘A’ in this case.
In contrast the Business Partner itself could be the decisive key for modelling separate Contract Accounts, depending on the perspective of an insurer. Following such an alternative approach the result would look totally different: each of these three Business Partners will have its own Contract Account ‘CA-A’, ‘CA-B’, and ‘CA-C’ with each of them as the Holder.
Moreover each of the three InsuranceObject-BusinessPartner-Relationships is assigned separately to one associated Contract Account; means ‘IO-PLI’ ↔‘BP-A’ is assigned to ‘CA-A’, ‘IO-PLI’ ↔‘BP-B’ is assigned to ‘CA-B’, and ‘IO-PLI’ ↔‘BP-C’ is assigned to ‘CA-C’. Therefore all items that belong to Business Partner ‘B’ as the 1st premium payer are posted on Contract Account ‘CA-B’, and all other items that belong to Business Partner ‘C’ as the 2ndpremium payer are posted on Contract Account ‘CA-C’. As long as the policy holder doesn’t pay premiums Contract Account ‘CA-A’ will be empty.
èThis example illustrates the flexibility of InsuranceObject-BusinessPartner-Relationships. The implemented model depends mainly on legal and business requirement, while considering the mapping of Business Partners (for instance: is a Business Partner ‘A’ created as a Group that represents the commercial partnership, including two Business Partner Relationships to ‘B’ and ‘C’, or not?). From this point of view the capabilities of the feeder system have also high impact. SAP Policy Management (FS-PM) supports both approaches described in this first example.
· 2ndExample: One claim is linked to multiple Business Partners in parallel
In FS-CD a claim is represented by an Insurance Object, often with multiple relationships to different Business Partners. Maybe there are several claim participants involved in parallel. Each of them will receive a benefit, claim or indemnity payment. From a legal perspective such a Business Partner is in many cases not just a Payee, but also a Creditor with its own entitlement.
Usually the insurer submits separate documents to these different payees, considering partner-specific postal or email addresses, when the claim is settled. On top each Business Partner may has its own preference how to get paid (e.g. Cheque, Bank Transfer, or credit transfer to a Payment Card). Even if all of them chose the same Payment Method ‘Bank Transfer’ (Electronic Fund Transfer), every Partner has of course his own bank details.
Thus, you will create one Insurance Object ‘IO-CLAIM1’ with a meaningful external Insurance Object Category that reflects the claim in FS-CD, including appropriate relationships to all relevant Business Partners.
It could be wise to create always a basic InsuranceObject-BusinessPartner-Relationship between the claim and the policy holder (here: Business Partner ‘H’) - independent from the fact, whether this Business Partner ‘H’ will receive a payment or not. This InsuranceObject-BusinessPartner-Relationship ‘IO-CLAIM1 ↔ BP-H’ can be utilized to determine the favored ContractAccount-BusinessPartner-Relationship.
If an insurer prefers a separate ‘Claim Contract Account’ that contains all claims of a policy holder for a certain line of business, then Business Partner ‘H’ is meant to be also the Holder of this specific Contract Account ‘CA-CLAIM’. All further Business Partners, which are linked to the representing Insurance Object ‘IO-CLAIM1’ as Creditors (Payees), will get
a) their own relationship to the same Contract Account ‘CA-CLAIM’ as other Partners, and
b) their own relationship to the Insurance Object ‘IO-CLAIM1’, which will be usually assigned to the Claim Contract Account ‘CA-CLAIM’ according to a).
As a result all claim payables will be posted on one and the same Contract Account ‘CA-CLAIM’, but strictly separated by different Business Partners. Each InsuranceObject-BusinessPartner-Relationship will hold its specific control parameters and can steer FS-CD transactions and mass activities accordingly. In particular different Outgoing Payment Methods and Bank Details or Credit Cards will be considered in FS-CD carefully, clearly separated per InsuranceObject-BusinessPartner-Relationship.
In contrast an insurer may opt for a universal mixed ‘Premiums and Claims Contract Account’, with the policy holder - Business Partner ‘H’ - as the Holder. In this case there an appropriate Contract Account already exists, originally created for handling policy-related premium receivables and incoming payments. This Account can also be utilized for postings and payments related to all associated claims.
Thus, every InsuranceObject-BusinessPartner-Relationship “IO-CLAIM1 ↔ BP-x” will be assigned to this existing Contract Account. BP- x means all Business Partners that are linked to this claim, such as policy holder and further Creditors or Payees. In total all postings are strictly differentiated by Business Partner as well as Insurance Object, even they are processed on one and the same Contract Account.
Additionally an extra Contract Account for ‘special’ Business Partners could be implemented as well, without interfering the regular model. For instance there are agents or brokers, which are mandated from an insurer to handle and settle claims on its behalf, at least focusing on claim settlement in advance; means prior to a comprehensive claim handling on part of the insurer (e.g. by a professional claim handler).
Of course, there are various legal and business restrictions to be considered, for example the broker ‘D’ is permitted to handle claims only in a specific line of business, if the policy holder is identical with the claimant and also with the payee, and no third-party indemnities are affected (e.g. like in liability insurance).
Therefore a dedicated ‘Settlement Contract Account’ could be appropriate for such a broker, which contains all InsuranceObject-BusinessPartner-Relationships between all relevant claims – reflected as Insurance Objects “IO-CLAIM-x” – and this Business Partner ‘D’. Consequently a different Contract Account Creation Rule comes into consideration, if a claim or an indemnity payable should be processed in FS-CD that refers to Business Partner ‘D’, where that broker is entitled to settle exactly this claim on behalf of the insurer.
Thus, the InsuranceObject-BusinessPartner-Relationship ‘IO-CLAIM-x↔ BP-D’ will be assigned to a specific Contract Account ‘CA-SZ’ with the broker as the Holder. It doesn’t matter, whether there are additional Business Partners linked to this claim or not, because each of them will have its separate InsuranceObject-BusinessPartner-Relationship “IO-CLAIM-x↔ BP-y” in parallel. All these Relationships can be assigned to the usual Contract Account based on the regular scheme, just this exception for the broker with a claim settlement mandate is administered differently on purpose via Settlement Contract Account ‘CA-SZ’. Holder of this Contract Account is the broker (Business Partner ‘D’).
èConsidering the impact of these different models, a thorough evaluation of legal and business consequences is required, upfront to the implementation. Depending on the line of business, the insurance product as well as law and justice, the last proposal could be efficient … but in other scenarios it wouldn’t. There is no ‘golden rule’ that fits for all scenarios. SAP Claims Management (FS-CM) supports all variants that are mention in this 2nd example.
· 3rdExample: A policy has an alternative Premium Payer (instead of the Policy Holder)
Depending on the country and the line of business one explicit alternative Payer can pay all premiums instead of the Policy Holder, which is contractually agreed. At the same time the Payer (Business Partner ‘P’) doesn’treplace the Policy Holder (Business Partner ‘H’) as a Debtor regarding premium receivables. ‘P’ is just paying, usually via Direct Debit (Debit Memo Procedure) or via Credit Card. Although these payments are initiated by the insurer, and ‘P’ is the relevant Business Partner, ‘H’ keeps still being responsible overall as the policy holder; means he will receive reminders or formal dunning notices (dunning letters) from the insurer, if premiums were not paid by the alternative Payer.
Therefore the insurer has to create a Business Partner that represents the alternative Payer, especially based on law and justice in all countries that belong to the Single Euro Payments Area (SEPA) for Direct Debit.
In many countries it’s notpermitted to add just another Bank Detail or Payment Card under the section ‘Payment Transactions’ of the policy holder’s Business Partner Master Data (by capturing the first name and family name of the alternative Payer in the field ‘Account Holder’ for a certain Bank Account, or in the field ‘Description’ for a certain Payment Card). Instead it’s mandatoryto create and maintain a separate Business Partner that reflects the alternative Premium Payer. Thus, the alternative Premium Payer is represented by its own Business Partner ID (e.g. Business Partner Number).
If just one alternative Premium Payer can be assigned to a policy (instead of the policy holder) at a particular time, and this Business Partner ‘P’ isn’t a separate debtor, an extra Relationship between him and the Insurance Object that reflects the policy is not required in parallel to the InsuranceObject-BusinessPartner-Relationship with the Policy Holder.
Instead the Relationship between the Business Partner ‘H’ (Policy Holder) and the Insurance Object ‘IO-POLICY’ is sufficient. It provides all necessary parameters to support this scenario. Within this Relationship ‘IO-POLICY ↔BP-H’ you can specify:
§ An Alternative Payer (Business Partner ID; here ‘P’ for instance)
§ An Address Number of the Alternative Payer
§ The Incoming Payment Method and
the Bank Details ID, or the Payment Card ID for Incoming Payments
Furthermore the alternative Payer can be assigned as an Additional Recipient of one or several selected Correspondence Types (e.g. Invoice, Dunning Notice, or Account Statement) under the section ‘Correspondence’ within the InsuranceObject-BusinessPartner-Relationship ‘IO-POLICY – BP-H’. Thereupon, the alternative Premium Payer – Business Partner ‘P’ – will get the same correspondence in copy as the Policy Holder, of course only for the selected types.
These powerful control parameters are supported throughout all FS-CD transactions and mass activities. But keep in mind that they support just one Business Partner as a Payer, which replaces the ‘original’ Partner only in this function.
Analogical control parameters are also available in standard for an alternative Payee, which can be specified within an InsuranceObject-BusinessPartner-Relationship, as follows:
§ An Alternative Payee (Business Partner ID)
§ An Address Number for Alternative Payee
§ The Outgoing Payment Methods and
the Bank Details ID, or the Payment Card ID for Outgoing Payments
For example SAP Policy Management (FS-PM) focuses on Premium Payers. The singular scenario - mentioned above - isn’tsupported by FS-PM in standard with regards to different Payers, because a separate InsuranceObject-BusinessPartner-Relationship per Premium Payer is much more flexible, considering backdated (retroactive) as well as to future changes, or multiple Premium Payers in parallel.
If another Premium Payer should be assigned with a valid from date in the past (e.g. triggered by a return subsequent to a direct debit, maybe because the previous payer diseased), or in the future, this can’t be reflected as such by changing just oneexisting InsuranceObject-BusinessPartner-Relationship itself historically. Please keep in mind that FS-CD Master Data are not based on a two-dimensional history concept. All attributes and control parameters are valid according to the date, which controls a certain FS-CD transaction or mass activity. Regarding FS-CD Master Data there is no time-dependency. It’s neither possible to change them with an effective date in the past, nor in the future.
Therefore it’s more generic to create an InsuranceObject-BusinessPartner-Relationship per Premium Payer. If a switch from a previous Payer (Business Partner ‘P1’) to a new Payer (Business Partner ‘P2’) must be reflected accurately in FS-CD, all original debit line items can be neutralized through posting ‘mirror’ credit line items related to Business Partner ‘P1’, and - additionally - by posting new appropriate line items related to Business Partner ‘P2’. If this method is applied, it doesn’t matter whether some items have already been paid or not, in either case correct debit as well as credit line items are posted toward the relevant Business Partner.
Depending on the technical capabilities of the feeder (administrative) system as well as on the integration platform, a ‘hand-in-hand approach’ can be implemented, which is fully supported on part of FS-CD. In this scenario the feeder system doesn’t persist any billing or payment relevant data. Instead it creates real-time an FS-CD Insurance Object with relationship to the respective Business Partner, and also maintains real-time all control parameters within this InsuranceObject-BusinessPartner-Relationship. Thus, there are no redundant Master Data that have to be replicated and kept in sync from the feeder system towards FS-CD. Overall the feeder system creates and maintains all InsuranceObject-BusinessPartner-RelationshipMaster Data, and doesn’t persist these attributes at its own. In addition the feeder systems reads all FS-CD Insurance Object attributes - real-time - for displaying them to a user on request (e.g. inquiry). Therefore extra navigation, dialogues and screens have been developed customer-specific on part of the feeder system in some implementation projects, to provide users with a unique and homogeneous user interface in Non-SAP environments.
Alternatively a ‘redundant approach’ is fully supported as well. In this common scenario the feeder system persists all data that are relevant for billing or payments at its own, as a part of the original business object (e.g. policy, claim, or commission contract). Additionally all these attributes are mapped and transferred to an adequate FS-CD Insurance Object, including its relationship to the respective Business Partner; means they are replicated from the feeder system towards FS-CD, and the feeder system keeps them in sync. Replication and synchronization can be implemented selectively in real-time mode or in batch-mode, depending on the capabilities of the feeder system and the integration environment.
3.6. Payment Plan assigned to an InsuranceObject-BusinessPartner-Relationship
SAP Collections and Disbursement facilitates functions to convert a total amount, which is valid for a specific period (e.g. premium receivable for a year), into partitioned payment plan items that are finally transformed into posted FS-CD Documents. Rules and options for scheduling and distributing the initial amount are controlled by a Payment Plan. It belongs to the Master Data of an InsuranceObject-BusinessPartner-Relationship.
As an additional option a Payment Plan can be used to create equal repetitive payment plan items, which are based on a specific Payment Plan Item as a ‘template’ and will recur per defined period repetitively (e.g. monthly, quarterly, or semiannually); means reproduced periodically with updated dates. Moreover you can also specify a deferral agreement to shift the due dates, which are provided by the feeder system for the original receivables or payables, according to an individually configured scheme that recurs each period.
These FS-CD capabilities can be used from any feeder system. For example a policy administration system calculates only yearly premium receivables, but customers (policy holders) ask for monthly, quarterly, or semiannually payment frequency. Or a claim system delivers just yearly annuity payables, but the outgoing payments should be distributed monthly, or quarterly.
A Payment Plan holds several control parameters. One of the basic characteristic is the Payment Plan Key, which determines
· how amounts set by payment plan items for an insurance relationship are distributed,
· how changes to payment plan items are to be processed,
· whether charges are to be posted, and
· which additional activities are to be executed when posting or changing payment plan items.
A second control parameter is the Payment Option. It represents a set of Payment Plan Keys that can consist of just one Payment Plan Key, or of multiple different Keys in parallel. Thus, a Payment Option specifies, which Payment Plan Keys are permitted overall and can be switched from one to another. Furthermore it determines one or several activities that are triggered, when the Payment Plan Key is changed.
It’s not mandatory to make use of the FS-CD Payment Plan features and functions, but a valuable option. If this option is used, the control parameters of an InsuranceObject-BusinessPartner-Relationship specific Payment Plan are applied to all relevant Payment Plan Items. Thus, each Payment Plan Items that belong to this InsuranceObject-BusinessPartner-Relationship is subject to the rules of a particular Payment Plan, which are mainly steered by the Payment Plan Key and the Payment Option mentioned above.
In this regard SAP provides a central data structure named ‘SVVSCPOS_B (Direct Input Structure of Payment Plans and Payment Plan Items)’ that contains all Data on level of a Payment Plan and on level of a Payment Plan Item. Thus, it’s a combined structure that includes all Payment Plan attributes as well as all Payment Plan Item attributes. This structure corresponds to the RFC Function Module named ‘ISCD_SCPOS_MAINTAIN’ to create and maintain Contract Accounts with their Relationships to Business Partners from any external system or software application. Please see also the Payment Plan and Payment Plan Item Interface for Direct Input, which provides you with an overview.
4. Overview of important Control Parameters within FS-CD Master Data
