Show TOC

Object documentationCards

 

Business object in Account Management (FS-AM) that maps a contract to which various objects are assigned, such as:

  • Business partner

  • Conditions

  • Account details

 

You can create a card contract for any type of cards.

  • Credit cards (such as Visa card or Euro card)

  • Debit cards (such as EC card or bank card)

  • Other cards with and without payment function

Note Note

The term Card Contract is used as a synonym for card in Account Management (FS-AM), particularly to emphasize the contract character.

End of the note.

Structure

Card contracts are based on a card product. The card product is based on the product category Card. Each product category has certain attributes and contract elements assigned to it. In this way, the product category limits the functions and descriptive characteristics. The product further restricts the functions and attributes by the settings made in Customizing.

If the product does not allow changes to card contract attributes, the card contract has to adopt all the default values from the card product. These restrictions are useful in mass transactions, rather than for individual business.

Contract Architecture Objectives

The contract architecture has the following objectives:

  • Map any contracts between contract partners

  • Flexible structure, to avoid having to differentiate between the different lines of business (debit cards, credit cards, or bank cards).

  • Restriction to the parts relevant for processing.

  • Target group: Employees with varying levels of qualification (such as sales employees, product managers).

  • The bank can decide whether or not to use the SAP user interface.

Methods

You can process objects in Account Management (FS-AM) using the following channels:

  • Dialog

  • Business Application Programming Interface (BAPI)

  • Direct Input (DI)

Integration

The card contract receives essential information through its assignment to a product and an organizational unit.

Relationship Between Card Contract and Product

A card contract is based on a card pool product, and this is based on the product category Card Contract. The attributes and contract elements used in the product category "Card Contract" define the scope of functions and the descriptive characteristics. Product groups group together multiple products.

The card contract product can enable further differentiation in the card contract itself. If it does not allow changes, the card contract must adopt all the default values from the card contract product. These restrictions are useful in retail banking, rather than for individual business.

For more information about product definition, see Product Management (FS-AM-PR).

Relationship Between Card Contract and Organizational Unit

The Contract Manager is important for a contract. You assign this when you create the contract. The system generates the following data using this contract managing organizational unit:

  • Bank Posting Area

  • Default value for Contract Calendar 1

Note Note

Under certain circumstances, you can change the contract manager. For more information, see Changing the Contract-Managing Organizational Unit.

End of the note.
Relationship Between Card Contract and Business Partner

From a business perspective, a card contract is related to at least three business partners:

  • Customer(s)

  • Bank

  • Processor

In Account Management, the card contract explicitly only recognizes the customer or customers and the processor as business partner. The relationship to the bank exists implicitly, via the relevant organizational unit.

A business partner can be a natural person, an organization, or a group, such as a married couple. Relationships can exist between business partners. Example: The business partner Mr. and Mrs. Miller (as married couple) are related to the business partner Mrs. Miller and the business partner Mr. Miller.

You can create and edit business partners and their roles in SAP Business Partner for Financial Services. This must be before you create the contract. Then you assign all business partners belonging to the card contract in their relevant roles (such as card holder, authorized card user) to the card contract.

Note Note

You can store the processor in the product.

End of the note.
Linked Accounts Relationship (Account-Card)

You use the linked accounts relationship if a card is assigned to an account and cannot exist without the account. Advantage: When you create the account, you can also create one or more accounts, and the system makes the plausibility checks between the account and the card at the same time.

Example Example

You can use the linked account relationship to map a savings account with a savings card.

End of the example.
Linked Accounts Relationship (Card-Account)

This contract element maps the linking of multiple accounts to one card. The card is the main contract to which main payment details are assigned. A reference account is assigned to these payment details. All other participant accounts added to the card have equal status. You can make postings to all participant accounts. You lock an card using the account number.

In addition and depending on the following attributes, you can define which participant account of a linked accounts (card-account) relationship you wan the system to use for a transaction:

  • Communication route

  • Account product group

  • Primary account

  • Currency

Example Example

A card holder can manage multiple accounts with one card (such as print statement, withdraw cash). Depending on the communication route via which an external payment system reports a turnover to the bank, the system always uses the participant account defined for this:

A customer wishes to manage four accounts with one card and address a particular account, depending on the communication route. To do so, he/she uses the card X_ACC that is based on the product BCLA and is used as the main contract for the linked accounts relationship. Four account contracts (account A, account B, account C, and account D) participate in the contract relationship.

Depending on the situation in which a customer carries out a transaction with the card, the system accesses one or another of the four accounts:

  • If the customer wishes to pay a bill in a hospital with the card, the system debits account A:

    • Account product: Domestic currency

    • Account product group: GIRO

    • Communication route: POS/Hospital

  • If the customer withdraws cash at one of the bank's ATMs, the system debits account B:

    • Account product: ODP

    • Account product group: GIRO

    • Communication route: Bank's ATM

Since account A and account B belong to the same account product group GIRO, only one of the two accounts can be the primary account. In the example, account A is the primary account.

  • If the customer carries out a bank transfer at an online terminal or wishes to pay in a shop, the system debits account C.

    • Account product: Time deposits

    • Account product group: SALE

    • Communication route: POS/shop, terminal

  • If the customer withdraws cash at an external ATM, the system debits account D:

    • Account product: Foreign currency

    • Account product group: SPAR

    • Communication route: External ATM

End of the example.
Transfer Rules

This contract element generates the linked accounts relationship. In this way, customers can transfer cash from one account to another account in the contract relationship with one card. Using transfer rules, you define the contracts and assigned product groups between which a transfer is possible.

Example Example

A customer has a current (checking) account and a savings account at a bank that he/she manages with a credit card. Both accounts are assigned to the card as participants. At the ATM, the card holder transfers the amount of EUR 1,000 from the savings account to the checking account.

End of the example.