I'm glad to add this document from Jochem Schueltke to blogs.sap.com. It was released in SCN and is still valid, but not refer to BRIM. I have updated some links and did some minor changes. I split the document in parts.
© SAP AG 2014, Jochem Schueltke
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 detailed Master 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:
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-Relationship one 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.
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, crosspartner) 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.
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 chapter "Insurance 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:
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-BusinessPartnerRelationship easily, 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.
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.
Part 4 will continue with FS-CD Payment Plan assigned to an InsuranceObject-BusinessPartner-Relationship.
More information about FS-CD:
Please check also the Q&A section for FS-CD.
- Part 1: Overview and Business Partner
- Part 2: FS-CD Contract Account with its relationship to Business Partner
- Part 3: FS-CD Insurance Object with its relationship to Business Partner
- Part 4: FS-CD Payment Plan assigned to an InsuranceObject-BusinessPartner-Relationship
SAP Collections and Disbursements - Overview of FS-CD Master Data
© SAP AG 2014, Jochem Schueltke
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 detailed Master 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:
- 10 – Insurance contract (policy)
- 20 – Broker contract (third-party collection agreement)
- 30 – Commission contract
- 40 – Claim number
- 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-Relationship one 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, crosspartner) 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.
Business Partner with multiple Insurance Objects, SAP
Insurance Object with multiple Business Partner Relationships, SAP
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 chapter "Insurance 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:
- 1st Example: 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’. - 2nd Example: 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-BusinessPartnerRelationship easily, 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.
- 1st Example: 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’ ↔‘BPB’ 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. - 2nd Example: 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 partnerspecific 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.
- 3rd Example: 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 mandatory to 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
- A SEPA Mandate reference
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 PaymentsFor example SAP Policy Management (FS-PM) focuses on Premium Payers. The singular scenario - mentioned above - isn’t supported 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.
2 Business Partners linked to 1 Insurance Object: 1 Contract Account, SAP
2 Business Partners linked to 1 Insurance Object: 2 Contract Accounts, SAP
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.
Part 4 will continue with FS-CD Payment Plan assigned to an InsuranceObject-BusinessPartner-Relationship.
More information about FS-CD:
- SAP ERP: Collections and Disbursements
- SAP S/4HANA: Collections and Disbursements
- SAP S/4HANA Cloud, private edition: Collections and Disbursements
Please check also the Q&A section for FS-CD.
- SAP Managed Tags:
