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
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
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 incombination with robust enhancement possibilities, if required.
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 Business Technology Plattform (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 Data Transfer and 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:
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 Document is processed in any transaction or mass activity, the control
parameters of the relevant ContractAccount-BusinessPartner-Relationship, InsuranceObject-
BusinessPartner-Relationship, and – optionally – Payment Plan are 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.
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.
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 Editing of SAP Business Partner), as well as through different interfaces (please see Maintaining SAP Business Partner Data, Replication and Synchronization of Business Partners ).
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 APIs for Business Partner. In addition these ‘traditional’ BAPIs can be wrapped easily into Web Services and exposed through
Web Service Technologies (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 timedependent; 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.
Part 2 will continue with FS-CD Contract Account with its relationship to Business Partner.
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
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 deposit accounts, 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 correspondence that 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 plan agreement), 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 incombination with robust enhancement possibilities, if required.
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 Business Technology Plattform (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 Data Transfer and 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:
- Business Partner
- FS-CD Contract Account with its relationship to Business Partner
- FS-CD Insurance Object with its relationship to Business Partner
- FS-CD Payment Plan assigned 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 Document is processed in any transaction or mass activity, the control
parameters of the relevant ContractAccount-BusinessPartner-Relationship, InsuranceObject-
BusinessPartner-Relationship, and – optionally – Payment Plan are 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.
Master Data Model, Source SAP Fioneer
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.
FS-CD Master Data
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.
Business Partner, Source SAP Fioneer
SAP Business Partner Master Data is 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 Editing of SAP Business Partner), as well as through different interfaces (please see Maintaining SAP Business Partner Data, Replication and Synchronization of Business Partners ).
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 APIs for Business Partner. In addition these ‘traditional’ BAPIs can be wrapped easily into Web Services and exposed through
Web Service Technologies (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.
Natural Person, Source SAP Fioneer
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).
Relationships and Hierarchies, SAP
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 timedependent; 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.
Business Partner Roles and Validity of Roles, SAP
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.
Addresses and Usage of an Address, SAP
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.
Part 2 will continue with FS-CD Contract Account with its relationship to Business Partner.
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:
