WO2003042942A2 - Verfahren und vorrichtung zur computerimplementierten verarbeitung von zahlungsposten - Google Patents

Verfahren und vorrichtung zur computerimplementierten verarbeitung von zahlungsposten Download PDF

Info

Publication number
WO2003042942A2
WO2003042942A2 PCT/EP2002/012923 EP0212923W WO03042942A2 WO 2003042942 A2 WO2003042942 A2 WO 2003042942A2 EP 0212923 W EP0212923 W EP 0212923W WO 03042942 A2 WO03042942 A2 WO 03042942A2
Authority
WO
WIPO (PCT)
Prior art keywords
error
account
payment
management
processing
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/EP2002/012923
Other languages
English (en)
French (fr)
Other versions
WO2003042942A8 (de
Inventor
Martin Schroter
Rolf Haas
Roger Gutbrod
Hans-Dieter Scheuermann
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
SAP SE
Original Assignee
SAP SE
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by SAP SE filed Critical SAP SE
Priority to EP02783085A priority Critical patent/EP1440422A2/de
Priority to AU2002346840A priority patent/AU2002346840A1/en
Publication of WO2003042942A2 publication Critical patent/WO2003042942A2/de
Publication of WO2003042942A8 publication Critical patent/WO2003042942A8/de
Anticipated expiration legal-status Critical
Priority to US10/846,570 priority patent/US7636874B2/en
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/166—Editing, e.g. inserting or deleting
    • G06F40/174—Form filling; Merging
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/166—Editing, e.g. inserting or deleting
    • G06F40/186—Templates
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/40—Processing or translation of natural language
    • G06F40/55—Rule-based translation
    • G06F40/56—Natural language generation
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or payments
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/12—Hotels or restaurants

Definitions

  • the present invention relates to a method and a device for computer-implemented processing of payment items, which has the object of a money movement in an account.
  • an automatic Error Check is performed a payment item, wherein at least the occurrence of an error by an error routine (posting control rules) an error sequence, ie a response to the occurred Def ⁇ ler, is determined.
  • an error routine posting control rules
  • all errors occurring in a given payment item are fed to the error routine in order to carry out a weighting of the errors that have occurred and, depending on a result of the error weighting, to initiate suitable error sequence measures.
  • This approach is based on the knowledge that many of the errors that may occur in connection with a payment item can be processed automatically, and that the error handling tent is significantly reduced with a weighted procedure.
  • an operator is provided with a display based on the result of the error weighting in the individual case, for example via a computer workstation.
  • the display is designed to include the data necessary to process a given error.
  • the payment item is automatically reset for a predetermined period of time in the event of an error and is checked again after this period.
  • FIG. 1 shows a target application landscape according to the invention in a schematic block diagram.
  • Figure 2 also shows a schematic block diagram of the components of the account management according to the invention.
  • FIG. 3 shows a schematic block diagram of the interaction of the components according to the invention within sales processing (where DispoOffice stands for Posting Control Office, DispoRules for Posting Control Rules, Posting Events for Posting Control Events or Posting Locks and DispoEvent Handler for Posting Lock Manager).
  • FIG. 4 shows a schematic block diagram of the structure of the posting lock office according to the invention.
  • FIG. 5 shows a schematic block diagram of an overview of the structure of the core application account management.
  • FIG. 6 schematically illustrates the flow logic according to the invention within sales processing using a flowchart.
  • FIG. 7 shows a schematic block diagram of the inventive incorporation of disposition rules in a barrier landscape.
  • Applications are information systems that solve a primary business task and can be used on their own. They hold the data and functions for the solution of the primary tasks, ie they are bundled in activities that are closely related to each other.
  • a Applica ⁇ tion communicates via defined interfaces.
  • An application is usually a buyable solution. Examples are the products Account Management, Profit Analyzer and Risk Analyzer.
  • applications are divided into core applications and accessory applications:
  • Core applications are the formative applications of the application landscape. Accessory applications are supplementary applications that expand the functional scope of core applications (also several). They perform special tasks (examples are the determination of limits and scan models) and have their own investment cycle independent of the core applications. This ensures greater flexibility in adapting to changing business objectives.
  • the application landscape of the e-business solution mySAP Banking describes the essential applications that are necessary for the operation of the banking business.
  • the applications have a business-logical connection.
  • the “technical architecture” describes the link between applications using middleware.
  • the “application architecture” describes the business content of individual applications and the logical interplay of individual application modules. The blocks are called “components”.
  • SAP applications are based on a shell model: At the core is the solution for the international use of the software, in addition, country-specific solutions are offered. Customized supplements can be connected in another dish based on BTEs (Business Transaction Events) or BADIs (Business Add-Ins) or use of BAPI (Business Application Pro ⁇ Gramming interfaces). The following requirements are placed on applications by financial institutions and banks:
  • the bank decides on the desired range of standard functions by selecting the applications.
  • Applications communicate via public interfaces. Direct access to applications is not permitted. This ensures that data can be exchanged transparently between applications. Within an application consistent Since ⁇ tenbasis ensured. Unexpected risks due to non ⁇ known per shortcuts and access can be minimized.
  • This communication structure is an immediate one Data exchange between applications via public interfaces or indirect data exchange via public interfaces and business middleware possible. For example, the Posting Control Office can communicate with Account Management via public interfaces; the data exchange can also take place via middleware with its own business intelligence.
  • the middleware is a central element for realizing an application landscape.
  • the middleware can perform two tasks:
  • the business management of business events requires a set of rules. This is defined as a business rule.
  • Cross-application process knowledge is required to define the business rules.
  • Elements of the business rules are process objects that initiate the call of business objects in the individual applications.
  • Example "contract creation” Here, for example, the business objects business partner, contract, card product are addressed.
  • the depiction of front ends and back ends with the help of middleware is a common practice Therefore, when reinvesting in these a clear conception of the process control is necessary.
  • This construction also allows a gradual migration with successive activation of new applications.
  • the structure of the target application landscape shows "key functional areas" with which the banking management solution fields can be mapped. Within such an “area” there can be several applications. The area that contains applications that banks need to handle their secondary processes, such as human resources management, asset accounting, material management, etc., is not shown.
  • the basis for this structure is the goal of defining application areas at a high level, which serves a specific main purpose. This allows applications to be derived and clear responsibilities to be defined. Redundant applications and functions can be avoided.
  • the landscape is characterized by the following main tasks:
  • FIG. 1 shows a schematic diagram of a block diagram which represents a target application landscape for an account management according to the invention.
  • CRM stores data relating to the customer
  • operational data is data for existing customers
  • analytical data is data for new customer acquisition.
  • Personalized one-way communication self-service terminals, Internet, telephone.
  • a party acts through data entry and receives a system-generated result.
  • the bank is not represented by employees, but by the system reaction.
  • CRM Customer Relationship Management
  • Sales processes are focused on the acquisition of new business deals, on the one hand from the customer base, and on the other hand through the acquisition of new customers.
  • product payments transaction / asset or liability business or commission business
  • customer group this process is complex, risky and profitable.
  • Service processes include customer support during the contract life cycle. Key points include: blocking requests for cards, address changes, complaints.
  • the contract management supports the creation of applications and offers as well as the conclusion of the contract including correspondence and electronic files.
  • the contract management shows customer-centered the contractual agreements between the bank and the customer.
  • the contract can get any com ⁇ complexity.
  • One example is called by a castle stem a loan agreement with repayment through life insurance and Safe Stel ⁇ development.
  • If the contract data are called up, they contain a selection of processing-related information that is related to sales and service dated data are supplemented.
  • These contracts can be processed via several applications, ie the relationships between individual contracts or partial contracts are documented over the entire term. Customer-centered sales and service processes have their "anchor" in the contracts of contract management.
  • the application area "Analytical CRM” comprises the analysis processes for exploiting business and customer potential and their transfer into operational implementation (e.g. marketing measures).
  • Analysis processes form an essential aspect of efficient customer relationship management. This includes processes such as cost information for controlling service, marketing and sales campaigns, customer-specific key figures for determining further customer potential, information about competitor products, etc.
  • Primary tasks of analytical CRM are:
  • the Transaction Banking application area contains the main components of payment transactions, account management (processing and inventory management), securities set elements and custody account management (processing and inventory management).
  • Account management is responsible for handling the legal portfolio in terms of cash flows, ie it provides information about the bank's claims and liabilities to third parties.
  • the inventory management of the account management is the source for account statements and balance reports.
  • the balances and sales items are kept strictly currency, ie unrated.
  • the inventory is the basis for external accounting, which means that the contract and sales data held here form the data basis for preparing the balance sheet.
  • the (partial) contracts are processed in Account Management. Partial contracts because a customer contract can be distributed across several processing applications due to its complexity. For example.
  • a product can consist of a "salary account with credit card and travel insurance". While the salary account is managed in account management, the cards are processed by a provider and travel insurance by a partner.
  • the processing functionality means that automated rollovers or contract settlements take place. For operational CRM, this means that the current contract status must be known from the processing inventory.
  • Payment systems are traditionally country-specific solutions.
  • the payment transaction system takes over the formal checking and, if necessary, the consolidation and distribution of sales within the routes and formats used by the bank (internal and external routing).
  • Payment systems traditionally work in the so-called batch process.
  • dialog entry of payment orders is necessary, which can trigger immediate real-time booking in Account Management (additional application in payment transactions).
  • Highly perfor- mance-based communication must be ensured between payment systems and account management.
  • the management and execution of the application duration is within the scope of the present invention, an additional application in the payment (payment order and Dau ⁇ erquo are within the account management system). All- However, it is also conceivable to do this as a supplementary component within the account management (eg rebooking within the account management).
  • the Transaction Banking application area contains, in addition to the solutions described above for the money side, solutions for securities transactions and derivative financial transactions. It can therefore be assumed that there are usually several inventory management systems in this application area.
  • the peculiarity of the stucco administration is that in the area of the customer business it is an inventory management that does not affect the balance sheet.
  • the business partner solution is a central application for storing and managing all customer information. This solution is very closely linked to the solutions for operational and analytical CRM. Due to the process link, the business partner is maintained as part of these processes.
  • the business partner data represent a significant intangible asset for each bank, the value of which is determined by the quality of the data.
  • the business partner application merges the customer data of a bank across all applications. The most important data are:
  • Relationships between business partners can be linked in a variety of ways. Functions are available for creating borrower and risk units.
  • the application area "Central Services” contains solutions that support the banking business of the other areas.
  • Collateral management is of particular importance due to the Basel decisions on credit risk coverage.
  • a bank can optimize the capital backing and thus reduce borrowing costs.
  • the knowledge of which is uncertainties about the Si ⁇ and their drawdown a source for acquisition-on of recreated.
  • the acquisition of collateral he ⁇ usually follows in contract negotiations and concluding contracts and is initiated from the operational CRM. Collateral is released as part of the contract processing.
  • the management of collateral comprises, on the one hand, collateral that the bank accepts and, on the other hand, collateral that the bank provides itself.
  • the output management / outgoing correspondence application is a solution for optimal communication with the customer.
  • Different media such as mail, fax or email are required. There may be dependencies between the media. Furthermore, legal information deadlines must be observed (e.g. written account closure).
  • the invention supports the correspondence-oriented data selection and preparation. Further processing in a printing and shipping line is carried out by special providers.
  • the input management For input management / incoming correspondence heard the "Electronic File", and the general Verknüp ⁇ fung of documents to the objects contract Geschaftspart- ner, etc.
  • the input management is located as a central service in the operational CRM.
  • the "Administrative Services” services are used to properly organize banking operations.
  • bank management requirements for bank management are therefore single source of the database and method consistency across all evaluation processes.
  • the systems of a bank have to be organized differently than before.
  • the data required by the operational systems are made available at a data interface.
  • Bank management affects not only individual institutions, but entire groups. Especially for the group-wide Steue ⁇ tion bring uniformity and transparency of methods and their representations of great benefit. According to the invention, the following specialist areas are integrated into overall bank control:
  • Inventory management processes such as Processing and reconciliation of one-time accounts.
  • the Basic Maintenance Interface is a surface for processing individual functions.
  • This surface allows manual intervention in the anson ⁇ most highly automated processing. All func ⁇ nen from this area so that a grout surface. An approval process ensures revision-compliant processing. A release tool that is integrated in the system in the individual applications is suitable for this.
  • This surface is provided by default and the authorization profiles for these workplaces can be defined by the user as roles, so that each user has a menu that exactly corresponds to his system requirements.
  • the processing office ensures process-controlled, i.e. workflow-supported processing of business incidents. There are various role-based forms within the office.
  • the control is supported by customer-specific settings of the SAP workflow and the associated release procedure (4 to 8 eyes principle). In comparison to the Basic Maintenance Interface, these offices have their own data storage (for example, disposition orders). Crucial for an office integration is cross-application access to functions and data for the processing of business incidents. Furthermore, the results are the Office2011itaten to the central contact Manage ⁇ ment is transmitted, so that a fully Acczen ⁇ trated view bank-wide possible.
  • the master for the partial contracts that are to be processed lies in account management, i.e. the valid contract dates and conditions are stored there.
  • product configuration is a central topic of a modern, future-oriented solution.
  • the product configuration takes place under three different aspects: • The product configuration in operational CRM.
  • the product configuration is based on the marketing and sales needs.
  • a product compared to the market can be divided into several sub-products for processing.
  • connection between the operational CRM and transaction banking is carried out at the plant of a specific contracted fine ⁇ ges with a client via a public interface (BAPI).
  • BAPI public interface
  • connection to the processing (part) product is established by the product ID.
  • SAP provides the financial conditions of the account management via BAPIs to all other applications.
  • FIG. 2 uses a block diagram to illustrate the components of "Account Management".
  • Account Management has a structure that is neutral to the product lines. The development initially focuses on payment transaction products and services as well as passive and active products in retail banking.
  • the contract component is designed as a framework. It is therefore conceivable to use it as a central service for all applications in the target application landscape.
  • the contract and his future and framework can be ⁇ tig used as a central service for all applications in the target application landscape.
  • the contract manages all transaction-relevant master data in the account management via contract modules. Contracts use products as a template. The contract is aimed at extremely high-performance processing in bulk business.
  • Released contracts are usually passed on from the feeder systems to contract management via an interface (BAPI). During the contract period, however, it can be expected that the contract will also be accessed directly from Transaction Banking and data will be changed. Special contracts such as Contracts for one-time accounts are created directly in Account Management. The contract knows the released and not released condition.
  • BAPI interface
  • the essential value creation of account management lies in the mapping and processing of transaction data.
  • the solution must be high-performing and incur low costs. Further requirements for the solution are real-time processing and 7 x 24 hour availability.
  • the sales management posts the individual sales in real time and controls a flexible balance update. The movements are shown on the account. Individual sales are payment items (half sales), the basis of which are payment orders on the one hand and internal settlements on the other (e.g. interest charges). In addition, cash flows can be calculated and processed. Account management has an interface for accepting payment items (BAPI).
  • BAPI payment items
  • Sales management has no open item management with corresponding line item clearing. It is a payment on balances lungsuberwachung base conceivable, for example, the on ⁇ gang of funds in the course of time deposit or installment controls on loans.
  • Incoming payment items are checked for blocks and limits as part of material planning.
  • a set of rules (Posting Control Rules) flexibly controls the reaction of the system based on specified parameters. For example, customer be determined on a group-specific basis whether sales should be scheduled or rejected directly.
  • the individual turnover is also the basis for the general ledger handover.
  • the data is also used to create a bank statement.
  • the sales update is true and without valuations.
  • Orders describe the actions that the account management should carry out immediately or in the future. This means that orders can be monitored in an appointment file. These orders can change one or more objects.
  • Account management processes orders. Examples are “contract cancellation” and “set block”. These orders are initiated from the outside via interfaces or internally by the application itself (e.g. appointment monitoring for renewal cards).
  • the card solution uses the same components of product configurator, contract and financial terms as account management.
  • account management uses the same components of product configurator, contract and financial terms as account management.
  • the administration of cards is a specialization of the general contract.
  • the integration of card management into account management is necessary because there are close links between cards and accounts (e.g. EC card, debit card).
  • par- SAP also wants to keep the option open to process credit card accounts on the revenue side in the medium term.
  • the card administration must represent a solution that can be used optionally by the customer, i.e. the card management must be switched off within the account management. Furthermore, the card management should be expandable in the medium term so that it can be used as a standalone solution if there is a corresponding need on the market. According to today's experience, there is a need for an account management system including and also for card administration. There are no requests for card administration alone.
  • the account management has a central financial statement administration for periodic work (eg end-of-day processing).
  • periodic work eg end-of-day processing
  • the bank is given the greatest possible flexibility when planning jobs.
  • Periodic work summarizes the functions that have to be carried out repeatedly on a certain date. These include the closing work cash concentration, account closing, interest compensation, account statement, the processing of orders, the daily closing including the updating of the bookers and reporting. Before the final work is carried out, the booking cut is made. Then all bookings are made with the following current date.
  • the Posting Lock Manager is responsible for temporary booking locks, ie it sets locks that are triggered by business incidents (Posting Locks) and releases them after the underlying event has expired back on. Locks that are defined a priori on the product are not part of this component.
  • Figure 3 shows a block diagram to illustrate the interaction within the sales processing with the participation of the so-called "Posting Lock Manager”
  • Figure 4 shows a schematic block diagram of the structure of the so-called "Posting Control Office”.
  • the Posting Lock Manager accepts posting locks from various input channels (back office, call center or counter systems and credit bureaus) and determines - according to its rules - the reaction of the system.
  • the solution runs in operational operations (receiving and processing events) largely without manual intervention.
  • possible forms of blocking processes are the contract block (the contract as a whole and the block of partial functions), the block of cards in the portfolio as well as checks and other payment transaction forms.
  • the central business partner block which extends across all customer accounts, can be set on the business partner.
  • this rule can e.g. lead to an overdraft and direct debit block on all accounts and a block on all cards of the business partner concerned.
  • This set of rules can be expanded to meet customer requirements.
  • Accessory applications for account management from the perspective of the application landscape are:
  • accessory applications complement or support the function or task of one or more core applications.
  • the Posting Control Office is an additional application for account management that is used to dispose of payment items for which a block or an unauthorized overdraft was found when an attempt was made to post.
  • the duration and frequency of the resubmission as well as the final reaction (e.g. rejection) in the event of unresolved or newly emerging booking obstacles can be set.
  • Dynamic limit determination is a solution that is particularly necessary in automated mass business. This is a Zubehorap bearing for account management that allows the individual bank to put au ⁇ tomatically due to defined rules and limits Inputparame- delight the customer.
  • the dynamic limit determination is programmed by the customer or in customer projects according to individual needs.
  • the limit determination communicates with inventory management, the business partner and the operational CRM.
  • This accessory application is responsible for extrajudicial dunning processes.
  • Figure 5 shows a summary overview of using a schematic block diagram showing the structure of Kernappli ⁇ cation Account Management.
  • Figure 6 shows a schematic representation of a flow logic within the sales processing of payment items with rules for disposition.
  • the item is posted to the account with an update of all objects involved. No posting control order is created.
  • the item is "attached" to the account; the transaction figures in the account are not updated.
  • a posting control order is created for the posting control office.
  • the item is posted to the account with an update of all objects involved.
  • a posting control order is created for the posting control office.
  • This response is intended for client items.
  • the item is not accepted by the sales processing and is returned to the calling application.
  • Here will return to which the test object transfer to the Ac ⁇ count management (AM) has failed. No posting control order is created.
  • the response initiates an automated return. For this automated return, it must be determined which return reason is used. The reason for the return determines whether the return is visible or invisible, ie visible to the customer in the account statement or not.
  • the direct debit is redeemed, the account has a debit posting block.
  • the direct debit is automatically returned. In this case, the customer account must be booked so that he is informed that his premium has not been redeemed.
  • the check should be debited to the customer account.
  • the bank has determined that the customer will not see this burden.
  • the booking and the automated return are invisible in the account statement. No correspondence with the customer is initiated.
  • the item is not posted to the original target account, but redirected due to the rules.
  • the account to be addressed is supplied by separate account determination, which is described in the following chapter.
  • a posting control order is created for the posting control office.
  • Redirection accounts can thus be defined depending on the currency and "organizational unit" of the payment item to be redirected. Only those items are then posted to a specified redirection account whose transaction currency corresponds to the account currency and which corresponds to the combination of bank country and bank key stored in Customizing.
  • redirection to the specified account takes place automatically.
  • the original recipient details (account number, bank code, bank country) are recorded at the payment item.
  • the response for a downstream Posting Control Office is stored here if the number of resubmissions or the deadline has expired.
  • a so-called follow-up response in the rule entry is only useful if the Clearre ⁇ actions "redirecting" is set (on a one-time account) or post-processing. In these cases, a Posting- control job is created and the set follow-up - The reaction can be carried out by the repetitor in the Posting Control Office. For the follow-up reactions "reject" and "return”, a reason must be entered in the rule entry.
  • One or more different error messages can be determined from each object, so that several rules can be determined by the algorithm described above.
  • the valid reaction is determined by prioritizing the reactions found. The following applies here:
  • the response determined by the disposition rules must be transferred to the Posting Control Office, since the type of processing is derived from this. For example:
  • the feedback to the feeder system should be carried out for each item at the following level:
  • Posting Control Office represents a user-friendly screen workstation, the screen structure of which depends on the determined error. For example, in the aforementioned Namenspru- fung directly and automatically displays a selection of possible rich ⁇ term name. Until now, correcting an error that cannot be remedied as part of an automatic process had to be carried out completely manually from the screen of the account turnover by the person responsible responsible independently collecting the information necessary to resolve the error that occurred.
  • Posting Control Repetitor which checks a faulty booking every day for a given period. For this purpose, it is set which types of errors (eg overdrafting of the account) are repeatedly checked over the adjustable period of time if there is a certain probability that the error will only occur temporarily (ie there will be coverage again on the first of the month).
  • An operator working on the process on the screen can also manually refer the process to the Posting Control Repetitor.
  • blocks can be set according to the invention which have an effect on the booking check, such as, for example, check blocking, deterioration in creditworthiness, credit card blocking.
  • the system allows automatic monitoring of deadlines for time restrictions, such as a check or credit card block that can be lifted again after 12 months.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • General Business, Economics & Management (AREA)
  • Marketing (AREA)
  • Tourism & Hospitality (AREA)
  • Development Economics (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • General Engineering & Computer Science (AREA)
  • Human Resources & Organizations (AREA)
  • Artificial Intelligence (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Computational Linguistics (AREA)
  • Technology Law (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Quality & Reliability (AREA)
  • Operations Research (AREA)
  • Data Mining & Analysis (AREA)
  • Primary Health Care (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Telephonic Communication Services (AREA)
  • Facsimiles In General (AREA)
  • Electrotherapy Devices (AREA)
  • Steroid Compounds (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Verfahren und Vorrichtung zur computerimplementierten Verarbeitung von Zahlungsposten, die eine Geldbewegung auf einem Konto zum Gegenstand haben, bei dem bei Eingang eines Zahlungspostens automatisch eine Prüfabfolge abläuft und bei Auftreten mindestens eines Fehlers mittels einer Fehlerroutine eine Fehlerfolge aus einem Fehlerroutinenverzeichnis ermittelt wird, wobei sämtliche in einem gegebenen Zahlungsposten auftretenden Fehler gesammelt der Fehlerroutine zugeführt werden, im Rahmen der Fehlerroutine eine Gewichtung der aufgetretenen Fehler erfolgt und abhängig von einem Ergebnis der Fehlergewichtung geeignete Fehlerfolgenmassnahmen veranlasst werden.

Description

Verfahren und Vorrichtung zur computerimplementierten Verarbeitung von Zahlungsposten
Die vorliegende Erfindung betrifft ein Verfahren und eine Vorrichtung zur computerimplementierten Verarbeitung von Zahlungsposten, die eine Geldbewegung auf einem Konto zum Gegenstand hat.
Erfindungsgemaß werden ein Verfahren mit den Merkmalen des Anspruchs 1 und eine Vorrichtung mit den Merkmalen des Anspruchs 5 vorgeschlagen.
Demnach erfolgt eine automatische Fehlerprufung eines Zahlungspostens, wobei bei Auftreten mindestens eines Fehlers mittels einer Fehlerroutine (Posting Control Rules) eine Fehlerfolge, d.h. eine Reaktion auf den aufgetretenen Feh¬ ler, ermittelt wird. Erfindungsgemaß werden dabei samtliche in einem gegebenen Zahlungsposten auftretenden Fehler gesammelt der Fehlerroutine zugeführt, um eine Gewichtung der aufgetretenen Fehler vorzunehmen und abhangig von einem Ergebnis der Fehlergewichtung geeignete Fehlerfolgenmaßnahmen zu veranlassen. Diesem Vorgehen liegt die Erkenntnis zugrunde, daß viele der im Zusammenhang mit einem Zahlungsposten möglicherweise auftretenden Fehler automatisch bearbeitet werden können, und daß bei einem gewichteten Vorgehen die Fehlerbearbeitungszelt deutlich verringert wird. Insbesondere kann im Falle eines gemischten Auftretens von Fehlern, die vollautomatisch bearbeitet werden können, und Fehlern, bei denen auf menschliche Entscheidungsunterstut- zung zurückzugreifen ist, abhangig von der Zusammensetzung der Fehler bzw. Fehlerarten automatisch ein ökonomisches Vorgehen eingeleitet werden, bei dem bspw. zunächst die maschinell bearbeitbaren Fehler bearbeitet werden, bevor der Vorgang an eine Bedienperson weitergegeben wird, oder auf eine maschinelle Bearbeitung zunächst verzichtet wird, da der von der Bedienperson zu bearbeitende Fehler derart gravierend ist, daß es nicht lohnend erscheint, vor einer Behebung dieses Fehlers andere Fehler zu bearbeiten.
In vorteilhafter Ausgestaltung wird einer Bedienperson eine auf der Grundlage des Ergebnisses der Fehlergewichtung im Einzelfall gestaltete Anzeige, bspw. über einen Bildschirmarbeitsplatz, bereitgestellt. Die Anzeige ist derart gestaltet, daß sie die zur Bearbeitung eines gegebenen Fehlers notwendigen Daten umfaßt. Dadurch wird erfindungsgemaß die Zeit, die ein Sachbearbeiter mit der Fehlerbearbeitung verbringt, deutlich reduziert, da samtliche zur Fehlerbearbeitung notwendigen Informationen direkt oder per Link bereitgestellt werden.
In besonders vorteilhafter Ausgestaltung der Erfindung wird der Zahlungsposten bei einem aufgetretenen Fehler automatisch für eine vorgegebene Zeitspanne zurückgesetzt und nach Ablauf dieser Zeitspanne erneut geprüft.
Die Erfindung erstreckt sich selbstverständlich auch auf Computerprogramme mit Programmcodemitteln, die dazu geeignet sind, bei Ablauf des Computerprogramms auf einem Computer ein erfindungsgemaßes Verfahren auszufuhren, sowie auf computerlesbare Datentragermedien mit darauf abgespeicher¬ ten erfindungsgemaßen Computerprogrammen und auf Computerprogrammprodukte mit derartigen computerlesbaren Datentragermedien. Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und der beiliegenden Zeichnung.
Es versteht sich, daß die vorstehend genannten und die nachstehend noch zu erläuternden Merkmale nicht nur in der jeweils angegebenen Kombination, sondern auch in anderen Kombinationen oder in Alleinstellung verwendbar sind, ohne den Rahmen der vorliegenden Erfindung zu verlassen.
Die Erfindung ist anhand eines Ausfuhrungsbeispieles in der Zeichnung schematisch dargestellt und wird im folgenden unter Bezugnahme auf die Zeichnung ausfuhrlich beschrieben.
Figur 1 zeigt in schematischer Blockdarstellung eine er- findungsgemaße Ziel-Applikationslandschaft .
Figur 2 zeigt ebenfalls in schematischer Blockdarstellung die Komponenten des erfindungsgemaßen Account Managements .
Figur 3 zeigt in schematischer Blockdarstellung das Zusammenspiel der erfindungsgemaßen Komponenten innerhalb der Umsatzverarbeitung (wobei DispoOffice für Posting Control Office, DispoRules für Posting Control Rules, Dispo Events für Posting Control Events bzw. Posting Locks und DispoEvent Handler für Posting Lock Manager steht) .
Figur 4 zeigt in schematischer Blockdarstellung den Aufbau des erfindungsgemaßen Posting Lock Office.
Figur 5 zeigt in schematischer Blockdarstellung eine U- bersicht über die Struktur der Kernapplikation Account Management. Figur 6 veranschaulicht in schematischer Darstellung anhand eines Flussdiagramms die erfindungsgemaße Ablauflogik innerhalb der Umsatzverarbeitung.
Figur 7 zeigt in schematischer Blockdarstellung die er- findungsgemaße Einbindung von Dispositionsregeln in eine Sperrenlandschaft.
Zunächst wird im folgenden das technische Umfeld der Erfindung beschrieben.
Die Anmelderin der vorliegenden Patentanmeldung hat in Zusammenarbeit mit internationalen Banken und Beratungshau- sern eingehende Markt- und Wettbewerbsanalysen durchgeführt, deren Ergebnisse sich in den heutigen Softwarelosungen der Anmelderin und in den Weiterentwicklungsprojekten widerspiegeln. Auf Grundlage dieser Zusammenarbeit wurde in den letzten Jahren eine Ziel-Applikationslandschaft für Banken entwickelt, die sich an den Bedurfnissen der internationalen Finanzmärkte orientiert. Die einzelnen Applikationen dieser Softwarearchitektur stellen Losungen und integrale Losungsbestandteile der sogenannten e-business so- lution mySAP Banking dar. Im wesentlichen laßt sich mySAP Banking in die Bereiche Core Banking, SEM für Banken und CRM für Banken unterteilen.
Applikationen sind Informationssysteme, die eine betriebswirtschaftliche Primaraufgabe losen und für sich allein einsatzfahig sind. Sie halten die Daten und Funktionen zur Losung der Primaraufgäbe, d.h. sie bundein in einem engen fachlichen Zusammenhang stehende Aktivitäten. Eine Applika¬ tion kommuniziert über definierte Schnittstellen. In der Regel stellt eine Applikation eine kaufbare Losung dar. Beispiele sind die Produkte Account Management, Profit Ana- lyzer und Risk Analyzer. In den folgenden Ausfuhrungen werden Applikationen in Kernapplikationen und Zubehorapplikationen gegliedert:
Kernapplikationen sind die pragenden Applikationen der Ap- plikationslandschaft . Zubehorapplikationen sind ergänzende Applikationen, die den Funktionsumfang von Kernapplikationen (auch mehreren) erweitern. Sie erfüllen Spezialaufgaben (Beispiele sind die Limitermittlung und Scoπngmodelle) und verfugen über einen eigenen Investitionszyklus unabhängig von den Kernapplikationen. Hierdurch wird eine größere Flexibilität in der Anpassung an sich verändernde geschaftspo- litische Ziele gewahrleistet.
Die Applikationslandschaft der e-business solution mySAP Banking beschreibt die wesentlichen Applikationen, die für das Betreiben des Bankgeschäftes notwendig sind. Die Applikationen stehen in einem betriebswirtschaftlich-logischen Zusammenhang.
Die "Technische Architektur" beschreibt die Verknüpfung zwischen Applikationen durch eine Middleware. Die "Applikationsarchitektur" beschreibt den betriebswirtschaftlichen Inhalt einzelner Applikationen und das logische Zusammenspiel einzelner Applikationsbausteine. Die Bausteine werden als "Komponenten" bezeichnet.
Die Applikationen der SAP sind nach einem Schalenmodell aufgebaut: Im Kern befindet sich die Losung für den internationalen Einsatz der Software, ergänzend hierzu werden landerspezifische Losungen angeboten. Kundenindividuelle Ergänzungen können in einer weiteren Schale auf Basis von BTEs (Business Transaction Events) bzw. BADIs (Business Add-Ins) oder Nutzung von BAPIs (Business Application Pro¬ gramming Interfaces) angeschlossen werden. Folgende Anforderungen werden seitens Finanzinstituten und Banken an Applikationen gestellt:
• Kundenzentrierte und vertriebswegeneutrale Unterstützung der Sales-/Service-Prozesse .
• Schnelle Reaktionsmoglichkeit bei Systemanforderungen für die Abbildung von neuen Produkten.
• Integrationsmoglichkeit neuer Geschaftsprozesse .
• Produktspartenneutrale Abwicklung von Vertragen sowie einheitliche Bestandsführung.
• Integration und Konsistenz von interner und externer Rechnungslegung .
Folgende Anforderungen werden an die Applikationslandschaft gestellt
• Flexible Modernisierung der Applikationslandschaft über Jahre hinweg (in Abhängigkeit vom Investitionszyklus der Applikationen) .
• Schnelle Reaktionsmoglichkeiten auf sich ändernde Geschaftsmodelle (z.B. Outsourcing, Insourcing) .
• Kundenindividuelle Erweiterungsfahigkeit ohne Modifikation der Standardlosung.
• Unterstützung von unterschiedlichen Migrationsszenarien.
• Flexible Integration in bestehende Applikationsland¬ schaften bei Banken.
• Reduzierung der Schnittstellenkomplexitat durch integrierte Verarbeitung innerhalb der SAP- Applikationslandschaft .
Daraus folgt für die angestrebte Applikationslandschaft: • Die einzelnen Applikationen sind austauschbar und erweiterbar. Insbesondere dürfen einzelne Applikationen nicht zu umfangreich sein. In einer integrierten Systemlandschaft der SAP müssen einzelne Applikationen deaktiviert und fremde Applikationen integriert werden können .
• Die Bank entscheidet durch die Auswahl der Applikationen über den gewünschten Umfang an Standardfunktionen.
• Jede Applikation muß so erweiterbar sein, daß eine Integration in kundenindividuelle Applikationslandschaften durch die SAP, von zertifizierten Partnern oder auch vom Kunden selbst entwickelt werden kann.
Eindeutige Zuständigkeit von Applikationen
Betrachtet man zentrale Bankprozesse, so lassen sich hieraus verschiedene Aufgaben und Informationsbedurfnisse ableiten. Diese unterschiedlichen Anforderungen stehen teilweise in Widerspruch zueinander und verhindern die optimale Ausgestaltung einzelner Losungen. So ist eine kundenzentrierte Prozeßbearbeitung die Anforderung der Vertriebsund Service-Organisation an eine Losung. Die kostensenkende Abwicklung von Vertragen und Konten erfolgt hingegen vertragsorientiert. Die interne und externe Rechnungslegung richtet die Prozesse wiederum an rechtlichen und organisatorischen Bedingungen aus.
Applikationen kommunizieren über öffentliche Schnittstellen (Public Interfaces) . Direkte Zugriffe auf Applikationen sind nicht zulassig. Hierdurch ist gewährleistet, daß der Datenaustausch zwischen Applikationen transparent erfolgen kann. Innerhalb einer Applikation ist eine konsistente Da¬ tenbasis gewahrleistet. Unerwartete Risiken aufgrund unbe¬ kannter Verknüpfungen und Zugriffe können minimiert werden. Durch diese Kommunikationsstruktur ist ein unmittelbarer Datenaustausch zwischen Applikationen über öffentliche Schnittstellen oder ein mittelbarer Datenaustausch über öffentliche Schnittstellen und eine betriebswirtschaftliche Middleware möglich. Beispielsweise kann das Posting Control Office über öffentliche Schnittstellen mit dem Account Management kommunizieren; der Datenaustausch kann aber auch über eine Middleware mit eigener Business-Intelligenz erfolgen.
Die Middleware ist ein zentrales Element zur Verwirklichung einer Applikationslandschaft. Die Middleware kann zwei Aufgaben erfüllen:
• Technische Kommunikation (Services)
• Betriebswirtschaftliche Steuerung (Business Rules)
Für die technische Kommunikation gibt es verschiedene Losungen im Markt. Sie ermöglichen den Informationsaustausch zwischen verschiedenen Datenbanken in unterschiedlichen Formaten.
Die betriebswirtschaftliche Steuerung von Geschaftsvorfallen erfordert ein Regelwerk. Dieses wird als Business Rule definiert. Zur Ausprägung der Business Rules ist applikati- onsubergreifendes Prozeßwissen erforderlich.
Elemente der Business Rules sind Prozeßobjekte, die den Aufruf von Businessobjekten in den Einzelapplikationen initiieren. Beispiel „Vertragsanlage": Hier werden z.B. die Businessobjekte Geschäftspartner, Vertrag, Kartenprodukt angesprochen. Die Abbildung von Frontends und Backends mit Hilfe von Middleware ist eine weitgehend gangige Praxis. Aber die Unterstützung von Backend-Prozesssen zwischen Applikationen ist hier ebenfalls notwendig und noch wenig ausgeprägt. Deshalb ist bei Reinvestitionen in diesen Be- reichen eine klare Konzeption der Prozeßsteuerung erforderlich.
Diese Konstruktion erlaubt auch eine stufenweise Migration mit sukzessiver Aufschaltung neuer Applikationen.
Für SAP hat das Zusammenspiel von Applikationen und Middleware eine strategische Bedeutung und wird derzeit aktiv gefordert. Im Rahmen der Analyse der technischen Machbarkeit spielt die Frage der Performance eine wichtige Rolle.
Die Struktur der Ziel-Applikationslandschaft zeigt „key functional areas", mit denen die bankbetriebswirtschaftlichen Losungsfelder abgebildet werden können. Innerhalb einer solchen „area" können mehrere Applikationen liegen. Nicht dargestellt ist jener Bereich, der Applikationen enthalt, die Banken für die Abwicklung ihrer Sekundarprozesse benotigen, wie beispielsweise Personalwirtschaft, Anlagenbuchhaltung, Materialverwaltung etc.
Grundlage für diese Struktur ist das Ziel, Applikationsbereiche (areas) auf einer hohen Ebene zu definieren, die einem bestimmten Hauptzweck dient. Hierdurch lassen sich Applikationen ableiten und klare Zuständigkeiten definieren. Redundante Applikationen und Funktionen können vermieden werden. Geprägt ist die Landschaft von folgenden Hauptaufgaben:
• Applikationen zur kundenzentrierten Durchfuhrung von Sales- und Serviceprozessen.
• Applikationen zur Durchfuhrung und Kontrolle von Handelsprozessen .
• Applikationen zur vertragszentrierten hochperformanten Abwicklung. • Applikationen zur rechtlich und organisatorisch induzierten Datenkalkulation und -aufbereitung für die Banksteuerung .
• Applikationen zur zentralen Bereitstellung von Daten, die die anderen Bereiche optimal unterstutzen, ohne dort redundant gefuhrt zu werden.
Figur 1 zeigt in schematischer Darstellung ein Blockdiagramm, das eine Ziel-Applikationslandschaft für eine erfin- dungsgemaße Kontoverwaltung darstellt.
In der obersten Ebene des Blockdiagramms der Figur 1 befindet sich bei dem Feld „Point of Sales & Services" die Kundenschnittstelle zu der Verkaufs- und Servicestelle der Bank, wie beispielsweise dem Callcenter bei Telefonbanking oder einem Filialschalter.
In der darunter liegenden zweiten Ebene des Blockdiagramms werden unter „CRM" den Kunden betreffende Daten gespeichert, operative Daten sind dabei Daten zu bestehenden Kunden, analytische Daten sind Daten zur Neukundenakquise .
In der dritten Ebene des Blockdiagramms schließlich werden unter „Transaction Banking" Vertrage mit Kunden geschlossen. Diese Vertrage betreffen Konten, Darlehen, Sicherheiten, Zahlungsverkehr, Depots usw.
In der untersten vierten Ebene befindet sich die Banksteue¬ rung.
Jede Bank kommuniziert mit den Markten und benotigt hierfür Schnittstellen. Aus dieser Schnittstelle werden in der Re¬ gel wertschopfende Geschäfte und Geschaftsvorfalle gene¬ riert. Sie sind von zentraler Bedeutung für eine Bank, da sie auch das Erscheinungsbild repräsentieren. Selbstver- standlich sind diese Schnittstellen vielfaltig. Als wesentliche Schnittstellen können genannt werden:
• Die personalisierte Zwei-Wege-Kommunikation: Filialen, Callcenter, Abwicklungs-Office und Handels- raume. An dieser Schnittstelle ist eine Dokumentation und in der Regel die Bestätigung der Kommunikationsergebnisse notwendig. Diese Form der Kommunikation ist in der Regel sehr personal- und kostenintensiv.
• Die personalisierte Ein-Weg-Kommunikation : SB-Terminals, Internet, Telefon. Hier agiert eine Partei durch Dateneingabe und erhalt ein systemerzeugtes Ergebnis. In diesem Falle ist die Bank nicht durch Mitarbeiter repräsentiert, sondern durch die Systemreaktion.
• Systemgetriebene Zwei-Wege-Kommunikation: elektronische Handelssysteme, Clearingsysteme, Zahlungsverkehrs-systeme, Marktdateneinspielung, Datenaustausch mit Auskunfteien, Meldungen an Aufsichtsbehörden. Hier erfolgt ein manueller Eingriff durch Bankmitarbeiter nur bei Störungen.
Wahrend im Zahlungsverkehr schon in den letzten Jahrzehnten kontinuierlich an einem systemgetriebenen Datenaustausch gearbeitet wurde, hat für die Kundenbetreuung erst mit den Direktbanken ein innovativer Umbruch begonnen. Durch das Internet wurde der Umbruch beschleunigt und erfaßt nach dem Retailgeschaft (Online-Banking) nun auch das Wholesalege- schaft (z.B. Akkreditivabwicklung) und den Handel (z.B. Versteigerung von Emissionen; Zunahme elektronischer Handelsplatze) . Diese neuen Schnittstellen müssen in die bestehende IT- Landschaft einer Bank integriert werden. Deshalb ist es sinnvoll, die Vertriebskanale so zu entkoppeln und zu kapseln, daß eine Anpassung an die sich schnell wandelnden Trends zeitnah möglich ist. Diese schnelle Reaktionszeit ist nur erreichbar, wenn möglichst wenig betriebswirtschaftliche Logik in den Frontends enthalten ist und in einem „vertriebswegeneutralen" Applikationsbereich liegt.
In den Frontends sollten sämtliche kundeninitiierten Ge- schaftsvorfalle erfaßt werden. Nur so sind Synergien und Prozeßoptimierungen einer modernen Softwarelosung nutzbar. Ferner ist die organisatorische Entscheidung, die Erfassung bestimmter Geschaftsvorfalle direkt durch den Kunden zuzulassen, leichter realisierbar (z.B. die inzwischen übliche Erfassung von Zahlungsauftragen am SB-Terminal oder über Internet bzw. Handy, die Bestellung von Reisezahlungsmitteln etc. ) .
Zwischen den Kommunikationsformen besteht eine Vernetzung. So können beispielsweise Telefonnutzer bei Problemen der Dateneingabe über einen Klick zu einem Callcenter weiterverbunden werden. Vor diesem Hintergrund wird es um so wichtiger, die Daten über alle Vertriebswege hinweg auf ei¬ nem einheitlichen Stand zu halten, so daß alle Mitarbeiter über die Aktivitäten und die Historie des Kunden informiert sind.
Customer Relationship Management (CRM) umfaßt die gesamte Breite an Analysen, Aktivitäten und Dokumentationen im Rahmen von Kundenkontakten. Somit sind nicht nur Verkaufspro¬ zesse und die zugehörige Marktbearbeitung relevant, sondern auch Services wahrend der Vertragsdauer. CRM ist für SAP mehr als eine Datenbank mit Marketingdaten. Es umfaßt ope¬ rative Prozesse mit entsprechender Datenhaltung. Viele Funktionen sind in derzeitigen Marktlosungen redundant für jeden „Channel" vorhanden. Eine unmittelbare, vertriebska- nalunabhangige Verfügbarkeit von Geschäfts- und Vertriebsfunktionen ist das Ziel der SAP im Rahmen der CRM- Applikationen .
Im operativen CRM können folgende Prozesse definiert werden:
Vertriebsprozesse (Salesprozesse) sind fokussiert auf die Akquisition neuer Geschäftsabschlüsse, zum einen aus dem Kundenbestand heraus, zum anderen durch Gewinnung neuer Kunden. Je nach Geschaftsfeld (Retail-/Wholessale) , Produkt (Zahlungsverkehr/Aktiv- oder Passivgeschäft bzw. Provisi- onsgeschaft) oder Kundengruppe ist dieser Prozeß unterschiedlich komplex, risiko- und ertragreich.
Serviceprozesse beinhalten die Kundenbetreuung wahrend des Vertragslebenszyklusses . Stichpunkte sind u.a.: Sperrwunsche von Karten, Adreßanderungen, Reklamationen.
Zur Abbildung der voranstehend benannten Prozesse sind folgende kundenzentrierte und vertriebswegeneutrale Losungen in diesem Applikationsbereich notwendig:
Das Vertragsmanagement unterstutzt die Antrags- und Angebotserstellung sowie den Vertragsabschluß inkl. Korrespondenz und elektronischer Akte. Das Vertragsmanagement zeigt kundenzentriert die vertraglichen Vereinbarungen zwischen Bank und Kunde auf. Die Vertrage können eine beliebige Kom¬ plexität erhalten. Als Beispiel sei hier ein Kreditvertrag mit Tilgung durch eine Lebensversicherung und Sicherstel¬ lung durch eine Burgschaft genannt. Werden die Vertragsda¬ ten aufgerufen, so enthalten sie eine Auswahl abwicklungs- relvanter Informationen, die um Vertriebs- und serviceori- entierte Daten ergänzt sind. Die Abwicklung dieser Vertrage kann über mehrere Applikationen erfolgen, d.h. die Beziehungen zwischen einzelnen Vertragen oder Teilvertragen werden über die gesamte Laufzeit dokumentiert. Kundenzentrierte Sales- und Serviceprozesse haben ihren „Anker" in den Vertragen des Vertragsmanagements.
Wichtige Prozesse:
• Abschluß und Dokumentation der vertraglichen und vorvertraglichen Kundenvereinbarungen .
• Inhaltliche und zeitliche Überwachung von vertraglichen und vorvertraglichen Bedingungen und Ereignissen (z.B. Auszahlungsvoraussetzungen; fehlende Legitimation; Prolongationstermine) .
Im Produktmanagement erfolgt die marktbezogene Konfiguration von Produkten. Dieser Prozeß erfolgt in Abstimmung mit dem Abwicklungsbereich einer Bank. Die Darstellung von Produkten in diesem Applikationsbereich konzentriert sich auf die Marktprasentation dieser Produkte, d.h. auf die variablen Ausprägungen, die ein Kunde wählen kann. Das Produkt muß im Retailgeschaft das Massengeschaft unterstutzen und ein einheitliches Produktportfolio und damit Vertragsportfolio gewahrleisten. Die Freiheitsgrade einzelner Produkte sind in der Regel begrenzt (z.B. hat ein Sparbrief in der Regel nur den Nominalbetrag und die Laufzeit als wahlbare Parameter) . Im Gegensatz zum Retailgeschaft ist das Whole- salegeschaft von hohen Freiheitsgraden innerhalb des Pro¬ duktes geprägt, da die vertraglichen Vereinbarungen sehr individuelle Ausprägungen ermöglichen müssen.
Wichtige Services:
• Konfiguration der Produktparameter
• Produktkalkulation Das Aktivitäten- und Kontaktmanagement ermöglicht es, Aktivitäten mit dem Kunden zu erfassen, zu überwachen und zu steuern. Ferner werden samtliche Kontakte mit dem Kunden dokumentiert und können nach verschiedenen Merkmalen ausgewertet werden. Die Bank erhalt einen „virtuellen" Kundenbetreuer, der allen Vertriebskanalen zur Verfugung steht. Z.B. ist eine Reklamation durch das Callcenter auch den Filialmitarbeitern sichtbar. Hierdurch ist ein einheitlicher Informationsstand für alle Mitarbeiter, die mit dem Kunden in Kontakt sind, gewahrleistet. Die Kundenaktivitaten über das Internet sind in das Kontaktmanagement entsprechend zu integrieren .
Der Applikationsbereich „Analytisches CRM" umfaßt die Analyseprozesse zur Ausschopfung von Geschäfts- und Kundenpotentialen und ihre Überführung in die operative Umsetzung (z.B. Marketingmaßnahmen).
Analyseprozesse bilden einen wesentlichen Aspekt eines effizienten Customer Relationship Managements. Dazu gehören Prozesse wie etwa Kosteninformationen zur Steuerung von Service-, Marketing- und Vertriebsaktionen, kundenspezifische Kennzahlen zur Ermittlung weiterer Kundenpotentiale, Informationen zu Wettbewerberprodukten etc. Primaraufgaben des analytischen CRM sind:
• Kundensegmentierung und -profilierung
• Kampagnen-Management
• Database-Marketing
Entsprechende Losungen unterstutzen die Bank bei der Pla¬ nung und Durchfuhrung von Marketingmaßnahmen, begonnen bei der Segmentierung und Profilierung von Kundenbestanden bis zur Planung, Durchfuhrung und Kontrolle von Marketing- Kampagnen . Das CRM ist erfindungsgemaß von strategischer Bedeutung, um eine vollständige Losungskompetenz anbieten zu können.
Applikationen zur Unterstützung von Handelsaktivitaten sind durch hohe Produktspezialisierungen gekennzeichnet. Spezielles Know-how und kurze Investitionszyklen prägen diese Losungen. Teilweise bilden die bestehenden Systeme für den Handelsraum Back-Office-Prozesse noch mit ab. Ein klarer Schnitt ermöglicht es, Abwicklungs- und Abrechnungsprozesse kostendegressiv verarbeiten zu können. Handelssysteme be¬ sitzen häufige rudimentäre Risikokontrollen. In Banken wird zunehmend die Anforderung gestellt, daß die Steuerungsinstrumente der Gesamtbanksteuerung direkt wertschopfend im Handelsbereich zur Verfugung gestellt werden.
Wichtige Prozesse in diesem Bereich sind:
• Produktkonfiguration für das Handelsgeschäft
• Vertragsmanagement für das Handelsgeschäft
• Limitmanagement für den Handel (Exposuremanagement)
Erfindungsgemaß wird kein Handelssystem bereitgestellt, sondern die Überwachung der Handelsaktivitaten vorgenommen.
Im Bereich "Transaction Banking" liegt folgende Ausgangslage vor: Die Globalisierung des Bankenmarktes bringt u.a. die Intention der Marktteilnehmer nach effizienten Betriebsgroßen zum Ausdruck. Um die angestrebten Skalierungsund Spezialisierungseffekte voll ausnutzen zu können, hat sich in den letzten Jahren eine teils innerbetriebliche, teils aber auch betriebsubergreifende Separation von Ver¬ triebs- und Transaktionsbank herausgebildet. Outsourcing- Losungen sind ein Beispiel dafür, daß die „Transaktions¬ bank" als eigenständiges Geschaftsmodell Erfolg hat. Doch auch bei einer Beibehaltung der Abwicklung im eigenen Unternehmen wird versucht, über Automatisierung und Zentralisierung die Abwicklung der Kundengeschafte zu optimieren.
Derzeit operieren Banken in ihren Applikationslandschaften mit einer Vielzahl von produkt- bzw. spartenspezifischen Systemen. Die Abwicklungen sind kostenintensiv und nicht skalierbar. Vereinheitlichung von Abwicklungsprozessen und weitgehende Produktspartenneutralitat im Rahmen des Bankgeschäfts sind wesentliche Anforderungen an diesen Applikationsbereich. Die Konfiguration von Abwicklungsprozessen soll durch Produktkonfigurationen beschleunigt und flexibili- siert werden. Die Möglichkeiten der Erweiterbarkeit der Software sind insbesondere unter Berücksichtigung des langen Investitionszyklusses von 15-20 Jahren in diesem Geschäftsbereich von entscheidender Bedeutung.
Für die SAP leistet dieser Applikationsbereich einen wesentlichen strategischen Beitrag zur Prozeßoptimierung in der internationalen Bankenwelt. Der Applikationsbereich Transaction Banking enthalt als wesentliche Bestandteile Zahl ungsverkehr , Accoun t Management (Abwicklung und Bes tandsführung) , Wertpapierset tlemen t und Depotverwal tung (Abwickl ung und Bes tandsführung) .
Dem Account Management obliegt die Abwicklung des juristischen Bestandes i.S. von Geldstromen, d.h. es gibt Auskunft über die Forderungen und Verbindlichkeiten der Bank gegenüber Dritten. Die Bestandsführung des Account Managements ist die Quelle für Kontoauszuge und Saldenmitteilungen. Die Salden und Umsatzposten werden wahrungsrein, d.h. unbewer- tet gehalten. Der Bestand ist die Grundlage für die externe Rechnungslegung, d.h. daß die hier gehaltenen Vertrags- und Umsatzdaten die Datenbasis für die Bilanzerstellung bilden. Ferner erfolgt im Account Management die Abwicklung der (Teil-) Vertrage . Teilvertrage deshalb, weil sich ein Kundenvertrag durch seine Komplexität auf mehrere Abwicklungsapplikationen verteilen kann. Bspw. kann im operativen CRM ein Produkt aus einem „Gehaltskonto mit Kreditkarte und Reiseversicherung" bestehen. Wahrend das Gehaltskonto im Account Management verwaltet wird, erfolgt die Kartenabwicklung durch einen Provider und die Reiseversicherung bei einem Partner. Die Abwicklungsfunktionalitat bedeutet, daß automatisierte Prolongationen oder Vertragsabrechungen erfolgen. Das bedeutet für das operative CRM, daß es vom Abwicklungsbestand die aktuellen Vertragsstande erfahren muß.
Im Account Management werden nur rechtsgültige Vertrage gefuhrt, d.h. Simulationsgeschafte, Angebote und Antrage liegen außerhalb im operativen CRM.
Zahlungsverkehrssysteme sind herkommlicherweise landesspezifische Losungen. Das Zahlungsverkehrssystem übernimmt das formale Prüfen und ggf. das Verdichten und Verteilen von Umsätzen innerhalb der von der Bank genutzten Leitwege und Formate (internes und externes Routing) .
Zahlungsverkehrssysteme arbeiten herkommlicherweise im sogenannten Batchverfahren. Ergänzend ist eine Dialogerfassung von Zahlungsauftragen notwendig, die die sofortige Re- al-Time-Buchung im Account Management auslosen kann (Zusatzapplikation im Zahlungsverkehr) . Zwischen Zahlungsverkehrssystemen und Account Management ist eine hoch perfor- mante Kommunikation sicherzustellen.
Grundsatzlich ist im Rahmen der vorliegenden Erfindung die Verwaltung und Ausfuhrung von Dauerauftragen eine Zusatzapplikation im Zahlungsverkehr (Zahlungsauftrag und der Dau¬ erauftrag liegen innerhalb des Account Managements) . Aller- dings ist es auch denkbar, dies als eine ergänzende Komponente innerhalb des Account Management auszufuhren (z.B. Umbuchung innerhalb des Account Managements) .
Der Applikationsbereich Transaction Banking enthalt neben den voranstehend beschriebenen Losungen für die Geldseite auch Losungen für Wertpapiergeschafte und derivate Finanztransaktionen. Somit kann davon ausgegangen werden, daß in der Regel in diesem Applikationsbereich mehrere Bestands- fuhrungssysteme liegen. Bei der Stuckeverwaltung (Wertpa- piersettlement / Depotverwaltung) besteht die Besonderheit, daß es sich im Bereich des Kundengeschafts um eine Bestandsführung handelt, die nicht bilanzwirksam ist.
Die Geschaftspartnerlosung ist eine zentrale Applikation zur Speicherung und Verwaltung samtlicher Kundeninformationen. Diese Losung ist sehr eng verknüpft mit den Losungen zum operativen und analytischen CRM. Aufgrund der Prozeß- verknupfung wird der Geschäftspartner im Rahmen dieser Prozesse gepflegt. Die Geschaftspartnerdaten stellen für jede Bank einen wesentlichen immateriellen Vermogenswert dar, dessen Wert durch die Qualität der Daten bestimmt wird.
Die Geschäftspartner-Applikation fuhrt anwendungsubergrei- fend die Kundendaten einer Bank zusammen. Die wichtigsten Daten sind:
• Name und Anschrift des Geschäftspartners
• Ergänzende Daten in Abhängigkeit des Geschäftspartner- Typs (z.B. Geburtsdatum; Rechtsform) für alle Applikationsbereiche (z.B. Branchenschlussel für Marketingselektionen oder Meldewesen)
• Beziehungen (z.B. Kreditnehmereinheit; Konzernstruktu¬ ren)
• Rollen • Legitimationsdaten
• Bonitatsdaten/Daten von Auskunfteien/Sconng-Ergeb- nisse/Marketingcluster
• Daten der Haushaltsrechnung oder Bilanzanalysen
• Gesamtobligo
Beziehungen zwischen Geschäftspartnern können vielfaltig miteinander verbunden werden. Für die Bildung von Kreditnehmer- und Risikoeinheiten sind Funktionen vorhanden.
Kunden treten in definierten Rollen gegenüber einer Bank auf (z.B. Kontoinhaber, Kreditnehmer, Bürge). Aus diesem Grund hat die Geschäftspartner-Applikation die Rolle eines Kunden als tragenden Bestandteil.
Der Applikationsbereich "Zentrale Services" enthalt Losungen, die das bankwirtschaftliche Geschäft der anderen Bereiche unterstutzen.
• Sicherheitenverwaltung
• Output- und Inputmanagement/Korrespondenz
• Marktdaten, Wertpapierstammdaten, Info-Dienste
• Administrative Dienste: Berechtigungen, Organisationseinheiten
Die Sicherheitenverwaltung erhalt durch die Basler Beschlüsse zur Kreditrisikounterlegung eine besondere Bedeutung. Durch differenzierte Zurechnung von Sicherheiten kann eine Bank die Eigenkapitalunterlegung optimieren und somit Kreditkosten senken. Ferner ist die Kenntnis über die Si¬ cherheiten und deren Valutierung eine Quelle zur Akquisiti- on von Neugeschaffen. Die Erfassung von Sicherheiten er¬ folgt in der Regel bei Vertragsanbahnung und -abschluß und wird aus dem operativen CRM initiiert. Die Freigabe von Sicherheiten erfolgt im Rahmen der Vertragsabwicklung.
Die Verwaltung von Sicherheiten umfaßt einerseits Sicherheiten, die die Bank entgegennimmt und andererseits Sicherheiten, die die Bank selbst stellt. Dieser zweite Aspekt ist derzeit in kaum einer Losung am Markt vorhanden. Aber Aktivitäten einer Bank im derivativen Bereich benotigen auch die Dokumentation und Steuerung selbst gestellter Sicherheiten .
Die Sicherheitenverwaltung ist ein wichtiger Bestandteil der Gesamtlosung.
Die Applikation Output-Management/ausgehende Korrespondenz stellt eine Losung für die optimale Kommunikation mit dem Kunden dar. Hierbei sind verschiedene Medien wie Postweg, Fax oder Email gefordert. Zwischen den Medien können Abhängigkeiten bestehen. Ferner sind gesetzliche Informationsfristen zu beachten (z.B. schriftlicher Kontoabschluß).
Neben der Wahl der Output-Medien ist eine hohe Funktionalitat bei der Steuerung und Aufbereitung der papiergebundenen Korrespondenz notwendig. Stichworte sind hier: Zentrale Druckaufbereitung; Formularwesen und Portooptimierung.
Die Erfindung unterstutzt die korrespondenzorientierte Datenselektion und -aufbereitung. Die Weiterverarbeitung in einer Druck- und Versandstraße wird von Spezialanbietern durchgeführt .
Zum Input-Management/eingehende Korrespondenz gehört die Funktion „Elektronische Akte", sowie die generelle Verknüp¬ fung von Dokumenten zu den Objekten Vertrag, Geschaftspart- ner, etc. Das Input-Management ist als zentraler Service im operativen CRM angesiedelt.
Hier handelt es sich um Losungen, die innerhalb einer Bank Informationen für mehrere Applikationen zur Verfugung stellen .
Die Services "Administrative Dienste" dienen der ordnungsgemäßen Organisation des Bankbetriebes.
Die bestehenden Systemlandschaften sind bei den meisten Banken historisch gewachsen. Dabei spielen die operativen Systeme eine zentrale Rolle und beliefern nachgelagerte Sy¬ steme oft mit schon vorgerechneten Ergebnissen. Hierdurch entstehen oft unterschiedliche Ergebnisse und ein kompliziertes Uberleitungs- und Abstimmungsverfahren. Die zeitnahe Entsche dungsgrundlage kann nicht mehr erstellt werden.
Anforderung an die Banksteuerung sind deshalb Single Source der Datenbasis und Methodenkonsistenz über alle Auswer- tungsverfahren. Um das Ziel der Abgestimmtheit von Daten und Methoden zu erreichen, sind die Systeme einer Bank anders zu organisieren als bisher. Insbesondere ist ein klarer Schnitt zwischen den operativen Systemen und den Anwendungen der Gesamtbanksteuerung zu ziehen. Dies entlastet die operativen Systeme von den nachgelagerten Prozessen der Gesamtbanksteuerung und zentralisiert gleichzeitig die Prozesse. Die von den operativen Systemen erforderlichen Daten werden an einer Datenschnittstelle zur Verfugung gestellt.
Die Banksteuerung betrifft nicht nur einzelne Institute, sondern ganze Konzerne. Gerade für die konzernweite Steue¬ rung bringen Einheitlichkeit und Transparenz der Methoden sowie deren Darstellungen einen hohen Nutzen. Folgende Fachbereiche werden erfindungsgemaß in eine Gesamtbanksteuerung integriert:
• Bilanzierung
• Profitability/Controlling
• Aktiv-/Passivsteuerung
• Risiko Controlling o Marktrisiko/Interne Modelle o Kredit-/Adressausfallrisiko o Kontrahentenrisiko o Landerrisiko
• Meldewesen
• Limitmanagement (analytisch)
Das Transaction Banking hat folgende zentrale Aufgaben:
• Steuerung des Geld- und Stuckeverkehrs
• Abwicklung des Vertragbestandes
• Umsatzverwaltung und Fuhren des juristischen Bestandes geld- und stuckeseitig)
Der Losungsumfang des Transaction Banking wird im folgenden beschrieben.
Um die Funktionalitat des Transaction Banking in den Ge¬ samtzusammenhang der Applikationslandschaft einzubetten, wird zunächst auf folgende Aspekte eingegangen:
• Bearbeitungsmoglichkeiten
• Fuhrende Datenhaltung
• Produktkonfiguration und Finanzkonditionen
Bearbeitungsmöglichkeiten Das Transaction Banking hat als eigener Applikationsbereich die Notwendigkeit, direkt bearbeitet werden zu können. Die Gründe hierfür können sein:
• Disposition und Limitmanagement zur Qualitätssicherung des Bestandes.
• Reklamationsbearbeitung, wie z.B. Gebuhrenkorrektur.
• Bestandsfuhrungsprozesse, wie z.B. Bearbeitung und Abstimmung von CpD-Konten.
• Korrekturmaßnahmen aufgrund falscher oder fehlender Da- teneinspielung (z.B. Valutakorrekturen, Buchungs- Korrekturen) .
Traditionell spricht man von der Kontoführung als Ergänzung zum Kundenbetreuer. Die Erfindung ist derart gestaltet, daß die Implementierung des Kontofuhrers möglich ist. Diese Rolle umfaßt folgende zwei Arbeitsfelder:
Zum einen sind es Aktivitäten, die direkt nach außen zum Kunden wirken (z.B. Limitherabsetzung), und zum anderen Aktivitäten, die sich „ ohne Kundenkontakt,, nur auf den Bestand auswirken (z.B. CpD-Bearbeitung, Datenkorrekturen).
Es werden vorliegend zwei Arten von Bearbeitungsschichten im Transaction Banking unterschieden:
• Basic Maintenance Interface (BMI)
• Abwicklungs-Office (Account Management Office/AMO)
Bei dem Basic Maintenance In terface handel t es sich um eine Oberflache für die Bearbeitung einzelner Funktionen.
Diese Oberflache erlaubt manuelle Eingriffe in die anson¬ sten weitestgehend automatisierte Abwicklung. Alle Funktio¬ nen aus diesem Bereich verfugen damit über eine Oberflache. Ein Freigabeverfahren gewahrleistet eine revisionsgerechte Bearbeitung. Hierfür ist ein Freigabetool geeignet, das sy- stemseitig in die einzelnen Anwendungen eingebunden ist.
Diese Oberflache wird standardmäßig zur Verfugung gestellt und die Berechtigungsprofile für diese Arbeitsplätze können vom Anwender als Rollen definiert werden, so daß jedem Anwender ein Menü zur Verfugung steht, das genau seinen Erfordernissen an das System entspricht.
Diese Oberflachen berücksichtigen keine kundenorganisatorischen Prozesse und Abwicklungsoptimierungen.
Das Abwickl ungs-Offi ce (Account Management Office/ AMO) gewahrleistet die prozeßgesteuerte, d.h. workflow-unter- stutzte Bearbeitung von Geschaftsvorfallen . Innerhalb des Office gibt es verschiedene rollenbasierte Ausprägungen.
Die Steuerung wird durch kundenindividuell einstellbare Vorgaben des SAP Workflow und damit verbundene Freigabeverfahren (4- bis 8-Augen-Prinzip) unterstutzt. Diese Offices verfugen im Vergleich zum Basic Maintenance Interface über eine eigene Datenhaltung (z.B. Dispositionsauftrage). Entscheidend für eine Officeeinbindung ist ein applikations- ubergreifender Zugriff auf Funktionen und Daten für die Bearbeitung der Geschaftsvorfalle. Ferner sollen die Ergebnisse der Officeaktivitaten an das zentrale Kontaktmanage¬ ment übermittelt werden, damit eine vollständig kundenzen¬ trierte Sicht bankweit möglich ist.
Heute liegen in der Abwicklung häufig Prozesse, die nicht in diesen Bereich gehören (z.B. Vertragseroffnung auf Postweg) . Ergänzend zeigen Marktstudien, daß es das Ziel von Banken ist, viele Back-Office-Prozesse um 70-80% alleine dadurch zu verschlanken, daß sie auf den Kunden selbst verlagert werden, wie es bereits im Internet-Banking möglich ist (z.B. Vertragseroffnung) . Denn möglichst effizient wird die Abwicklung erst dann, wenn der Bankkunde selbst Geschafts- vorfalle wie bspw. eine Kartensperre initiieren oder die Zahlungsauftragsdisposition selbst durchfuhren kann.
Führende Datenhaltung
In jeder Applikationslandschaft darf es für die Daten nur einen „Master" geben, auf den andere Applikationen direkt zugreifen oder periodische Updates bekommen.
Der Master für die Teilvertrage, die abgewickelt werden sollen, liegt im Account Management, d.h. die gültigen Vertragsdaten und Konditionen sind dort hinterlegt.
Gleiches gilt für die Umsätze und Salden. Deshalb erfolgt auf dieser Basis die Datenbereitstellung für die Kontoauszuge und für ein Data Warehouse.
Inwieweit Applikationen Daten redundant halten müssen, wird stark von den Performance-Anforderungen bestimmt und hangt von der kundenindividuellen Situation ab.
Produktkonfiguration und Finanzkonditionen
Produktkonfiguration
Wie in der Ziel-Applikationslandschaft dargestellt, ist die Produktkonfiguration ein zentrales Thema einer modernen zu- kunftsfahigen Losung. Die Produktkonfiguration erfolgt dabei unter drei unterschiedlichen Aspekten: • Die Produktkonfiguration im operativen CRM. Hier ist die Produktkonfiguration an den Marketing- und Vertriebsbedurfnissen orientiert.
• Die Abbildung des Abwicklungsproduktes mit allen abwicklungsrelevanten Steuerungsparametern innerhalb des Transaction Banking/Account Managements.
Ein Produkt gegenüber dem Markt kann hier in mehrere Teilprodukte für die Abwicklung aufgeteilt werden.
• Die Konfiguration von Produkten für die Banksteuerung. Diese Produkte haben in der Regel eine andere Granula- ritat als die Abwicklungsprodukte. Auch der Datenhaushalt ist an den Auswertungsbedurfnissen und nicht an den Abwicklungsanforderungen ausgerichtet.
In den drei Hauptprozessen des Bankgeschäftes ist das Produkt unterschiedlich ausgeprägt, mit Ausnahme eines Bereiches: „Die Finanzkonditionen des Produktes". Aus diesem Grund werden die Finanzkonditionen ergänzend dargestellt.
Die Produktkonfiguration erstreckt sich letztlich über alle drei Applikationsbereiche. Es ist eine übergreifende Abstimmung zwischen den Applikationsbereichen im Rahmen einer neuen Produktimplementierung notwendig. Die Pflege der Pro¬ dukte erfolgt in jedem Bereich für sich:
Im Transaction Banking findet die Produktpflege über das Customizing statt. Berechtigung und Freigabe sind über das Transportverfahren der SAP gesichert.
Die Verbindung zwischen dem Operativen CRM und dem Transaction Banking erfolgt bei der Anlage eines konkreten Vertra¬ ges mit einem Kunden über eine öffentliche Schnittstelle (BAPI). In der Schnittstelle werden mitgegeben: • der Kunde
• die Produkt-ID
• sowie die individuellen Vertragsauspragungen.
Durch die Produkt-ID wird die Verbindung zu dem Ab- wicklungs (teil) produkt hergestellt.
Finanzkonditionen
Die Finanzkonditionen sind Grundlage für die Zins- und Gebuhrenberechnungen. Dadurch haben sie eine besondere Bedeutung und müssen in jedem Applikationsbereich zur Verfugung stehen. Performancekritisch ist der Zugriff im Rahmen der Bestandsführung. Um die Einheitlichkeit der Konditionen u- ber die Grenzen einzelner Applikationsbereiche hinaus zu garantieren, stellt SAP die Finanzkonditionen des Account Managements über BAPIs allen anderen Applikationen zur Verfugung.
Figur 2 veranschaulicht anhand eines Blockdiagramms die Komponenten des „Account Managements". Das "Account Management" hat eine produktspartenneutrale Struktur. Im Fokus der Entwicklung liegen zunächst Zahlungsverkehrsprodukte und -Services sowie Passiv- und Aktivprodukte des Retail Banking.
Die Vertragskomponente ist als Framework konzipiert. Daher ist es denkbar, sie als zentralen Service für alle Applikationen der Zielanwendungslandschaft einzusetzen.
Es ist denkbar, daß der Vertrag und sein Framework zukunf¬ tig als zentraler Service für alle Applikationen der Ziel- anwendungslandschaft eingesetzt werden kann. Der Vertrag verwaltet im Account Management über Vertragsbausteine alle abwicklungsrelevanten Stammdaten. Vertrage nutzen Produkte als Vorlage. Der Vertrag ist auf eine äußerst performante Abwicklung im Massengeschaft ausgerichtet.
Freigegebene Vertrage werden in der Regel aus den Vorsystemen an das Vertragsmanagement über eine Schnittstelle (BAPI) weitergegeben. Wahrend der Vertragslaufzeit kann aber damit gerechnet werden, daß auch direkt aus dem Transaction Banking heraus auf den Vertrag zugegriffen und Daten geändert werden. Besondere Vertrage wie z.B. Vertrage für CpD-Konten werden direkt im Account Management angelegt. Der Vertrag kennt den freigegebenen und nicht freigegebenen Zustand.
Für alle Vertragsdaten kann es in einer Applikationslandschaft nur einen „Master" geben. Dieser „Master" liegt für die Abwicklungsdaten im Account Management. Außerdem erfolgt die Abwicklung von Vertragen weitgehend automatisiert. Das heißt hier kennt man die aktuellen Vertragszu- stände (z.B. nach Prolongationen). Die Vertragsdaten werden an Schnittstellen zur Verfugung gestellt.
Zum Verständnis sei erwähnt, daß es naturlich auch Vertragsdaten gibt, die in anderen Applikationen verwaltet werden und dort als „Master" gefuhrt werden (z.B. Schufa- Kennzeichen, Verfugungsberechtigung) . Der zentrale Anker zum Zusammenfuhren aller Daten liegt im operativen CRM.
Wichtige Prozesse im Account Management sind:
Anlegen, Andern, Prolongieren, Kundigen, Stornieren und Auflosen von Vertragen. Hierbei werden auch entsprechende Buchungen angestoßen. Es werden zwei Ausprägungen von Vertragen unterstutzt:
• Kontenvertrage
• Kartenvertrage (s. unten)
Die Unterstützung weiterer Vertragsparteien ist selbstverständlich möglich.
UmsatzVerwaltung
In der Abbildung und Abwicklung von Bewegungsdaten liegt die wesentliche Wertschopfung des Account Managements. Die Losung muß hoch performant sein und geringe Kosten verursachen. Weitere Anforderungen an die Losung sind Realtime- Verarbeitung und 7 x 24 Stunden Verfügbarkeit.
Die Umsatzverwaltung bucht in Echtzeit die Einzelumsatze und steuert eine flexible Saldenfortschreibung . Die Abbildung der Bewegungen erfolgt am Konto. Einzelumsatze sind Zahlungsposten (Halbsatze), deren Grundlage einerseits Zahlungsauftrage und anderseits interne Abrechnungen (z.B. Zinsbelastung) sind. Ergänzend können Cash flows berechnet und weiterverarbeitet werden. Das Account Management hat eine Schnittstelle zur Annahme von Zahlungsposten (BAPI).
Die Umsatzverwaltung kennt keine offene Postenverwaltung mit entsprechendem Einzelpostenausgleich. Es ist eine Zah- lungsuberwachung auf Saldenbasis denkbar, die z.B. den Ein¬ gang von Geldern im Zuge einer Festgeldanlage bzw. der Ratenzahlung bei Krediten steuert.
Eingehende Zahlungsposten werden im Rahmen der materiellen Disposition auf Sperren und Limite geprüft. Ein Regelwerk (Posting Control Rules) steuert flexibel die Reaktion des Systems anhand vorgegebener Parameter. So kann z.B. kunden- gruppenspezifisch bestimmt werden, ob ein Umsatz nachdisponiert oder direkt abgewiesen werden soll.
Systemreaktionen sind:
Buchen, Nachdisponieren, Nachbearbeitung, Ruckgabe, Abweisen, CpD-Buchung.
Der Einzelumsatz ist auch Basis für die Hauptbuchubergabe . Ferner dienen die Daten der Kontoauszugserstellung. Die Umsatzfortschreibung ist wahrungsrein und ohne Bewertungen.
Auftrage beschreiben die Aktionen, die das Account Management sofort oder zukunftig ausfuhren soll. Das heißt, Auftrage können in einer Termindatei überwacht werden. Diese Auftrage können ein oder mehrere Objekte verandern.
Das Account Management verarbeitet Auftrage. Beispiele sind „Vertragsauflosung" und „Sperren setzen". Initiiert werden diese Auftrage von außen über Schnittstellen oder intern durch die Applikation selbst (z.B. Terminuberwachung für Erneuerungskarte) .
Als Zusatzfunktionen sind außerdem zentrale Anwendungen, wie die Dauerauftrags- und Zahl ungsa uftragsverwal tung, vorgesehen (vgl. voranstehende Ausfuhrungen).
Die Kartenlosung nutzt dieselben Komponenten Produktkonfi- gurator, Vertrag und Finanzkonditionen wie das Account Management. Somit handelt es sich bei der Administration von Karten um eine Spezialisierung des allgemeinen Vertrages. Die Integration der Kartenverwaltung in das Account Management ist notwendig, da es enge Verknüpfungen zwischen Karten und Konten gibt (z.B. EC-Karte, Debit-Card) . Insbeson- dere will sich SAP die Option offen halten, mittelfristig Kreditkartenkonten auch umsatzseitig abzuwickeln.
Die Kartenadministration muß eine Losung darstellen, die vom Kunden optional eingesetzt werden kann, d.h. die Kartenverwaltung muß innerhalb des Account Managements abschaltbar sein. Ferner sollte die Kartenverwaltung mittelfristig so weit ausbaufähig sein, daß sie als Einzellosung eingesetzt werden kann, wenn entsprechender Bedarf am Markt entsteht. Nach heutigen Erfahrungen besteht Bedarf an einem Account Managementsystem inklusive als auch exklusive einer Kartenadministration. Anfragen für eine alleinige Kartenadministration liegen noch nicht vor.
Das Account Management verfugt über eine zentrale Abschlußverwaltung für periodische Arbeiten (bspw. Tagesendverar- beitung) . Die Bank erhalt bei der Einplanung der Jobs größtmögliche Flexibilität. Unter periodischen Arbeiten sind die Funktionen zusammengefaßt, die zu einem bestimmten Termin wiederkehrend ausgeführt werden müssen. Dazu gehören die Abschlußarbeiten Cash Concentration, Kontenabschluß, Zinskompensation, Kontoauszug, die Abarbeitung von Auftragen, der Tagesabschluß einschließlich der Fortschreibung der Bucher und Reporting. Bevor die Abschlußarbeiten durchgeführt werden, wird der Buchungsschnitt vorgenommen. Danach erfolgen alle Buchungen mit dem folgenden Tagesdatum.
Externe Systeme zur Jobsteuerung können ebenfalls eingebunden werden.
Der Posting Lock Manager (Sperrverwaltung) ist zustandig für temporare Buchungssperren, d.h. er setzt Sperren, die durch Geschaftsvorfalle (Posting Locks) ausgelost werden, und hebt diese nach Ablauf des zugrundeliegenden Events wieder auf. Sperren, die a priori am Produkt definiert werden, sind nicht Teil dieser Komponente.
Figur 3 zeigt ein Blockdiagramm zur Veranschaulichung des Zusammenspiels innerhalb der Umsatzverarbeitung unter Beteiligung des sogenannten „Posting Lock Managers", und Figur 4 zeigt in schematischer Blockdarstellung die Struktur des sogenannten „Posting Control Office".
Der Posting Lock Manager nimmt von verschiedenen Eingangs- kanalen (Back Office, Callcenter- oder Schaltersystemen und Auskunfteien) Posting Locks entgegen und bestimmt - gemäß seinen Regeln - die Reaktion des Systems. Die Losung lauft im operativen Betrieb (Entgegennahme und Verarbeitung von Events) weitgehend ohne manuelle Eingriffe ab. Im Account Management sind mögliche Ausprägungen von Sperrvorgangen die Vertragssperre (der Vertrag insgesamt sowie die Sperrung von Teilfunktionalitaten) , die Sperre von Karten im Bestand sowie von Schecks und anderen Zahlungsverkehrsvordrucken. Am Geschäftspartner kann die zentrale Geschafts- partnersperre, die sich über alle Konten des Kunden erstreckt, gesetzt werden.
Meldet beispielsweise ein Geschäftspartner Vergleich an, so verteilt der Posting Lock Manager entsprechende Sperren. So kann diese Regel z.B. zu einer Uberziehungs- und Lastschriftensperre auf allen Konten und einer Sperre aller Karten des betroffenen Geschäftspartners fuhren. Dieses Regelwerk ist kundenspezifisch erweiterbar.
Bedingt durch die Primaraufgabe des Account Management, den juristischen Bestand zu fuhren, steht ein flexibles Repor- ting zur Verfugung. Dazu zahlen zahlreiche Listen, wie z.B. Uberziehungs-, Salden- und Umsatzlisten. Ebenso ist es möglich, Listen für Konto- und Schecksperren zu erstellen und Abstimmsaldenlisten zum Abgleich der Zahlungsverkehrssalden zu erzeugen.
Die Definition von weiteren Reports ist flexibel möglich.
Zubehör-Applikationen zum Account Management aus Sicht der Applikationslandschaft sind:
• Posting Control Of fice
• Dynamische Limitermittlung
• Mahnen/Verzugs zins
Wie einleitend bereits erwähnt, erganzen bzw. unterstutzen Zubehör-Applikationen die Funktion bzw. Aufgabe einer oder mehrerer Kernapplikationen.
Das Posting Control Office ist eine Zusatzapplikation zum Account Management, die der Disposition von Zahlungsposten dient, bei denen beim Buchungsversuch eine Sperre oder eine ungenehmigte Überziehung festgestellt wurde.
Zahlungsposten, die im Account Management auf Buchungshindernisse (Sperren) und Konten treffen, bei denen es zu ei¬ ner ungenehmigten Überziehung kommt, werden gemäß einem Re¬ gelwerk (Posting Control Rules) disponiert. Dieses kunden¬ spezifisch einstellbare Regelwerk wird im Account Manage¬ ment verwaltet. Gegebenenfalls werden Informationen zu Zahlungsposten, die als Reaktion auf die Posting Control Rules nicht explizit abgewiesen werden, mittels eines Dispositionsauftrags (Posting Control Order) an das Posting Control Office ausgesteuert, wo ihre weitere Bearbeitung (Disposition) entweder maschinell oder manuell erfolgt. Die maschi¬ nelle Disposition (Repetitor) umfaßt die automatische Wiedervorlage von Zahlungsposten zur Buchung an das Account Management. Zahlungsposten, für die nur temporare Buchungs- hmdernisse (z.B. Limitprobleme) vorliegen, können mit Hilfe des Repetitors ohne manuelle Eingriffe disponiert werden .
Dauer und Häufigkeit der Wiedervorlage sowie die Endreaktion (z.B. Abweisen) bei nicht beseitigten oder neu auftretenden Buchungshindernissen sind einstellbar.
Die manuelle Bearbeitung von zu disponierenden Zahlungsposten erfolgt am Posting Control Desktop. In dieser Teillosung ist die rollenbasierte Ausgestaltung und Usability von zentraler Bedeutung. Der Disponent wird durch den Zugriff auf dispositionsrelevante Daten in seiner Entscheidung unterstutzt, Zahlungsposten entweder abschließend zu bearbeiten (Aktionen u.a. buchen, abweisen etc.) oder an die maschinelle Disposition zu übergeben.
Die dynamische Limitermittlung ist eine Losung, die insbesondere im automatisierten Massengeschaft erforderlich ist. Es handelt sich hierbei um eine Zubehorapplikation zum Account Management, die es der einzelnen Bank ermöglicht, au¬ tomatisch aufgrund von definierten Regeln und Inputparame- tern Limite beim Kunden zu setzen.
Die dynamische Limitermittlung wird vom Kunden bzw. in Kundenprojekten nach individuellem Bedarf ausprogrammiert. Die Limitermittlung kommuniziert mit der Bestandsführung, dem Geschäftspartner sowie dem operativen CRM.
Diese Zubehorapplikation ist zustandig für außergerichtliche Mahnprozesse.
Figur 5 zeigt zusammenfassend im Überblick anhand einer schematischen Blockdarstellung die Struktur der Kernappli¬ kation Account Management. Figur 6 zeigt in schematischer Darstellung eine Ablauflogik innerhalb der Umsatzverarbeitung von Zahlungsposten mit Regeln zur Disposition.
Folgende Reaktionen sind innerhalb des Regelwerkes zur materiellen Disposition erfindungsgemaß möglich:
1. Buchen
Der Posten wird am Konto unter Fortschreibung aller beteiligten Objekte gebucht. Es wird kein Posting-Control- Auftrag erstellt.
2. Nachbearbeitung
Der Posten wird am Konto „angehängt"; die Verkehrszahlen am Konto werden dabei nicht fortgeschrieben. Es wird ein Posting-Control-Auftrag für das Posting Control Office erstellt.
3. Nachdisposition
Der Posten wird am Konto unter Fortschreibung aller beteiligten Objekte gebucht. Es wird ein Posting-Control-Auftrag für das Posting Control Office erstellt.
4. Abweisen
Diese Reaktion ist für Auftraggeberposten vorgesehen. Der Posten wird durch die Umsatzverarbeitung nicht akzeptiert und an die rufende Anwendung zurückgegeben. Hierbei wird zurückgeben, an welchem Prufobjekt die Übergabe an das Ac¬ count Management (AM) gescheitert ist. Es wird kein Posting-Control-Auftrag erstellt.
5. Rückgaben Diese Reaktion ist nur für Empfangerposten sinnvoll. Die Reaktion initiiert eine automatisierte Ruckgabe. Für diese automatisierte Ruckgabe muss festgelegt werden, welcher Ruckgabegrund verwendet wird. Über den Ruckgabegrund ist festgelegt, ob die Ruckgabe bspw. sichtbar oder unsichtbar, d.h. im Kontoauszug für den Kunden ersichtlich oder nicht, erfolgt.
Beispiel :
• Ein Kunde erteilt seiner Haftpflichtversicherung die Genehmigung seine Beitrage über das Lastschriftenverfahren einzuziehen. Zum Zeitpunkt der Einlösung der Lastschrift weist das Konto eine Sollbuchungssperre auf. Die Lastschrift wird automatisch zurückgegeben. In diesem Fall muss über das Kundenkonto gebucht werden, damit er über die Nichteinlösung seiner Prämie informiert ist.
• Ein Kunde sperrt einen Scheck. Der Scheck soll dem Kundenkonto belastet werden. Es soll eine automatisierte Ruckgabe erfolgen. Die Bank hat festgelegt, dass der Kunde von dieser Belastung nichts sieht. Die Buchung und die automatisierte Rückgabe erfolgen im Kontoauszug unsichtbar. Es wird keine Korrespondenz mit dem Kunden angestoßen .
6. Umlenkung
Der Posten wird nicht auf das ursprungliche Zielkonto gebucht, sondern bedingt durch das Regelwerk umgelenkt. Das anzusprechende Konto wird durch eine separate Kontenfindung geliefert, die im folgenden Kapitel beschrieben wird. Für den Fall, dass die Umlenkung auf ein CpD-Konto erfolgt, wird ein Posting-Control-Auftrag für das Posting Control Office erstellt.
Für einige Geschaftsvorfalle ist es erforderlich, die Buchung nicht auf dem Ursprungskonto des Postens durchzufuh- ren, sondern den Zahlungsposten auf interne Konten umzuleiten. Dies kann maschinell mithilfe der Posting Control Rules erfolgen. Falls eine Umlenkung auf ein Konto erfolgen soll, so ist bei der Angabe der Reaktion „Umlenken" ein Konto zu hinterlegen.
Innerhalb der Posting Control Rules wird für die zuvor beschriebenen Konten an der Reaktion „Umlenken" ein Kontensymbol hinterlegt. Dieses Kontensymbol wird in einem nachgelagerten Schritt durch eine reale Kontonummer ersetzt. Dieses Vorgehen hat folgende Vorteile:
- Vereinfachung der Änderung eines Kontos durch Änderung an einer zentralen Stelle des Customizings . Die Posting Control Rules müssen nicht geändert werden.
- Transparenz der Einflußfaktoren bei der Findung des Kontos
Das definierte Kontosymbol wird unter Einbeziehung folgender Felder differenziert:
• Bankland und Bankleitzahl
• Währung
Es lassen sich somit Umlenkkonten in Abhängigkeit von Währung und „Organisationseinheit" des umzulenkenden Zahlungspostens definieren. Es werden dann nur diejenigen Posten auf ein angegebenes Umlenkkonto gebucht, deren Transaktionswährung der Kontowährung entspricht und die der im Customizing hinterlegten Kombination aus Bankland und Bank- schlussel entsprechen.
Beispiel :
Innerhalb der Posting Control Rules ist folgender Eintrag hinterlegt.
Figure imgf000040_0001
Gesperrte garantierte Umlenkung SchadensreguKarte Zahlung lierung
Das Kontosymbol „Schadensregulierung" wird durch folgende Eintrage ersetzt:
<=> Schadensregulierung Filiale 1 , DEM Konto 4711 ■=> Schadensregulierung Filiale 2 , DEM Konto 4712 ■=> Schadensregulierung * , DEM Konto 4713 ■=> Schadensregulierung * , EUR Konto 0815
Falls bei der Reaktion Umlenkung ein Kontensymbol hinterlegt ist, so findet automatisch eine Umlenkung auf das angegebene Konto statt. Die ursprunglichen Empfangerangaben (Ktonr., BLZ, Bankland) werden am Zahlungsposten festgehalten .
Falls bei den Reaktionen Nachbearbeitung oder Nachdisposition ein Kontensymbol hinterlegt ist, so wird das angegebene Konto zu Informationszwecken an das nachgelagerte Posting Control Office weitergereicht.
Reaktionsgrund
Zur Zeit (Stand TRBK Giro 2) können aufgrund betriebswirtschaftlicher Anforderungen für die Reaktionen „Ruckgabe" und „Abweisen" im Customizing Grunde definiert werden. Bei der Reaktion „Ruckgabe" steuert die Belegung des Feldes die Attribute für die Ausfuhrung der Ruckgabe (s. Spezifikation „Rückgabe") . Bei der Reaktion „Abweisen" wird der Grund an das ZVS zuruckgemeldet und kann dort ausgewertet werden. Reaktionsgrunde können in den Regeleintragen jeweils für die Primär- als auch für die Follow-up-Reaktion hinterlegt werden. Eintrage zu den Follow-up-Reaktionen werden dem Po¬ sting Control Office für die abschließende Verarbeitung weitergereicht . Falls ein nachgelagertes Posting Control Office eine Umbuchung des ubergebenen Posten auf ein Bearbeitungskonto durchfuhren konnte, so wird hier ein Kontensymbol für das Vorschlagskonto hinterlegt.
Hier wird die Reaktion für ein nachgelagertes Posting Control Office hinterlegt, falls die Anzahl der Wiedervorlagen bzw. die Frist abgelaufen ist. Eine sogenannte Follow-up- Reaktion im Regeleintrag ist nur sinnvoll, wenn die Erstre¬ aktionen „Umlenken" (auf ein CpD-Konto) oder Nachbearbeitung eingestellt ist. In diesen Fallen wird ein Posting- Control-Auftrag erstellt und die eingestellte Follow-up- Reaktion kann im Posting Control Office durch den Repetitor ausgeführt werden. Für die Follow-up-Reaktionen „Abweisen" und „Ruckgabe" müssen im Regeleintrag Grunde hinterlegt werden.
Behandlung von formalen Fehlern
Falls innerhalb der Verarbeitung eines Postens ein formaler Fehler bzw. ein Systemfehler auftritt, so übersteuert dieser die Regeln zur materiellen Disposition. Die Verarbeitung des Postens wird abgebrochen, die Fehlerursache wird festgehalten.
Dies betrifft nicht samtliche Fehler, die im Rahmen der formalen Prüfung festgestellt werden können. Folgende Er¬ gebnisse der formalen Prüfung fuhren nicht generell zu ei¬ ner Abweisung des Zahlungspostens durch das Account Manage¬ ment, sondern können in den Posting Control Rules durch die Hinterlegung von Regeleintragen disponiert werden: α Prüfungen auf das Buchungsdatum: Für Fehler aus dieser
Prüfung kann eine Auswertung über die Posting Control
Rules erfolgen. α Prüfungen auf das Vorhandensein bzw. den Status des Kontos im AM: Bei Auftraggeberposten fuhren Fehler aus dieser Prüfung zur Abweisung des Zahlungspostens. Empfanger- und Umsatzposten können aber mithilfe der Posting Control Rules auf CpD-Konten umgelenkt werden, wenn die CpD-Bearbeitung im AM erfolgt und deshalb die CpD-Kontenfindung im Customizing hinterlegt ist.
Ermittlung der gültigen Regel
• Die Ermittlung der gültigen Regel findet mittels des folgenden Schemas statt:
Generell gilt, daß ein vollqualifizierter Zugriff vor einem unqualifizierten Zugriff Vorrang hat. Die Generalisierung (Dequalifizierung) des Schlüssel erfolgt in der Reihenfolge:
7. Channel
8. Posting-Control-Gruppe
9. Produkt
10. Vorgangsartengruppe
11. Postenart
12. Fehlerart
Das heißt, es wird zuerst ein Zugriff mit einem vollqualifizierten Schlüssel durchgeführt. Falls hier ein entsprechender Eintrag gefunden wird, so ist dies der gültige . '→-Falls nicht, so wird der Zugriff ohne das Feld Channel durchgeführt. Falls hier ein Eintrag gefunden wird, so ist dies der gültige.
"→- Falls nicht, so wird der Zugriff ohne die Fehler Channel und Posting-Control-Gruppe (Dispogruppe) durchgeführt. Falls hier ein Eintrag gefunden wird, so ist dieser der gültige. Usw.
Beispiel: In den Posting Control Rules sei eingestellt:
Figure imgf000044_0001
Durch diese Einstellung wird erreicht, daß nur bei Je- dermannkonten eine automatisierte Ruckgabe erfolgt
• Die gültige Reaktion bei mehreren gültigen Regeln wird folgendermaßen ermittelt:
Aus jedem Objekt können eine oder mehrere verschiedene Fehlermeldungen (bzw. Fehlerarten) ermittelt werden, so dass durch den zuvor beschriebenen Algorithmus mehrere Regeln ermittelt werden können. Die gültige Reaktion wird durch eine Priorisierung der gefundenen Reaktionen ermittelt. Hier gilt:
Abweisen hat Vorrang vor Rückgabe hat Vorrang vor Umlenkung hat Vorrang vor
Nachbearbeitung hat Vorrang vor Nachdisposition hat Vorrang vor Buchen
Wird bei einer Buchung kein Fehler in den Objekten fest¬ gestellt und kein Eintrag im Regelwerk gefunden, so wird der Posten gebucht.
Es werden mindestens alle die Daten angeboten, die nur während der Umsatzverarbeitung bekannt sind. Die Schnittstelle zum Posting Control Office (welche Daten angenommen und gespeichert werden) wird in der Spezifikation „Posting Control Office" beschrieben. Alle Fehlermeldungen, die wahrend der Umsatzverarbeitung ermittelt wurden, werden mittels eines Dispositionsauftrages (Postmg-Control-Auftrag) einem nachgelagerten Posting Control Office zu Informationszwecken angeboten. Gleiches gilt bei Fehlermeldungen, die bereits durch das anwendende System über Schnittstellen übergeben wurden.
Referenzιerung zum erzeugten Umsatz
Innerhalb der Umsatzverarbeitung werden wie bisher Posten mit den verschiedenen Statusauspragungen erzeugt. Zusatzlich wird ein Dispositionsauftrag erzeugt, der eine weitere Bearbeitung des Umsatzes/Kontos initiieren soll.
Damit der Dispositionsauftrag auf den erzeugten Posten re- ferenzieren kann, müssen folgende Felder übergeben werden:
• System
• Mandant
• das anwendende System (hier: Account Management (AM) / mögliche andere Systeme: Zahlungsverkehrssystem)
• Identifizierung des Zahlungspostens
• Position des Zahlungspostens
Die durch die Regeln zur Disposition ermittelte Reaktion muß dem Posting Control Office übergeben werden, da sich hieraus die Art der Bearbeitung ableitet. Beispiel :
• Die Reaktion „Nachbearbeitung" (Posten bislang nicht gebucht) erfordert in den meisten Fallen eine Betrachtung des Postens
• Die Reaktion „Nachdisposition" (Posten ist bereits ge¬ bucht) erfordert eine Nachbetrachtung des Postens und/oder des Kontos Rückmeldung
Die Rückmeldung an das Vorsystem soll pro Posten auf folgender Ebene erfolgen:
→ Abgewiesen (Gründe auf Basis der Prüfobjekte)
→ Gebucht
→ Nachdisposition (Gründe auf Basis der Prüfobjekte)
Erforderlich, da für bestimmte zielseitige Buchungen Ausführungsbestätigungen verlangt werden (EDIFACT/FINPAY)
→ Nachbearbeitung (Gründe auf Basis der Prüfobjekte)
Hier wurde folgendes Beispiel für die Notwendigkeit der Rückmeldung gegeben. Ein Dauerauftrag wird gelöscht, falls 3 Monate der Fehler „keine Deckung" vorliegt. Bei anderen Sperren ist dies nicht der Fall.
→ Rückgabe (Gründe auf Basis der Prüfobjekte)
→ Umgelenkt (Gründe auf Basis der Prüfobjekte)
→ Zusätzlich sind hier die formalen Fehler , Konto nicht vorhanden' und technischer Fehler' bei der Rückmeldung aufzunehmen
Eine Zuordnung der Reaktionen des Posting Control Rules zu Returncodes ergibt sich wie folgt:
Figure imgf000046_0001
Bei einer automatischen Buchungsprufung greifen somit er- findungsgemaß bei Auftreten eines Fehlers „Posting Control Rules" genannte Regeln, die automatisch voreingestellte (kundenspezifische) Folgen triggern.
Bei der Buchungsprufung werden erfindungsgemaß samtliche Prüfungsposten durchgeprüft (in Abkehr vom Stand der Technik, wo bereits bei der ersten Fehlermeldung ein Ausstieg aus der Prüfungsroutine erfolgt), und alle Fehler werden gesammelt. Dies gestattet eine Gewichtung der insgesamt ermittelten Fehler im Rahmen einer Buchungsprufung bezuglich der Relevanz der einzelnen Fehler.
Sollte eine automatische Bearbeitung nicht möglich sein, wie dies beispielsweise bei einer Namensprufung aufgrund nicht übereinstimmender Namensangaben der Fall sein kann, so wird der Vorgang in das Posting Control Office-Modul abgegeben. Posting Control Office stellt einen benutzerfreundlich gestalteten Bildschirmarbeitsplatz dar, dessen Bildschirmaufbau abhangig von dem ermittelten Fehler erfolgt. So wird beispielsweise bei der erwähnten Namenspru- fung direkt und automatisch eine Auswahl an möglichen rich¬ tigen Namen angezeigt. Bisher mußte das Korrigieren eines Fehlers, der im Rahmen eines automatischen Ablaufs nicht behebbar ist, ausgehend von der Bildschirmanzeige des Kontoumsatzes vollständig handisch erfolgen, indem der zustandige Sachbearbeiter selbständig die zur Losung des aufgetretenen Fehlers notwendigen Informationen zusammensammelte.
Die Verteilung der Auftrage in Posting Control Office er¬ folgt nach voreingestellten Kriterien, abhangig von der Qualifikation und dem Anspruch der Prüfung. Beim Offnen des Bildschirms wird eine Nachprüfung vorgenommen, ob der Fehler überhaupt noch vorliegt, also ob beispielsweise eine Deckung wieder gegeben ist. Dies wird durch den sogenannten Posting Control Repetitor gewahrleistet, der über einen gegebenen Zeitraum täglich eine fehlerhafte Buchung prüft. Hierzu wird eingestellt, welche Arten von Fehlern (bspw. Überziehung des Kontos) über den einstellbar gegebenen Zeitraum wiederholt überprüft werden, wenn eine gewisse Wahrscheinlichkeit besteht, daß der Fehler nur temporar auftritt (also wieder gegebene Deckung bspw. am Monatser- sten) . Eine den Vorgang am Bildschirm bearbeitende Bedienperson kann ggf. den Vorgang auch manuell an den Posting- Control-Repetitor verweisen.
Des weiteren können erfindungsgemaß Sperren gesetzt werden, die eine Auswirkung auf die Buchungsprufung haben, wie beispielsweise Schecksperrung, Bonitatsverschlechterung, Kreditkartensperrung. Das System gestattet eine automatische Terminuberwachung zur zeitlichen Begrenzung von Sperren, wie beispielsweise eine nach 12 Monaten wieder aufzuhebende Scheck- oder Kreditkartensperrung.
Ebenfalls ist eine Verknüpfung zwischen der Sperrenverwaltung und Posting Control Office gegeben, damit im Rahmen der automatischen Prüfung eine Klarung erfolgen kann, warum eine Sperrung erfolgt ist. Sperrgrunde können direkt aus dem sogenannten Posting Lock Manager abgerufen werden (in der Bildschirmanzeige vorzugsweise über Kartenreiteraus- wahl) .
Darüber hinaus ist eine modifikationsfreie Erweiterung durch kundenspezifische Sperrobjekte möglich, und es erfolgt eine automatische Abprufung durch einen zusatzlichen „Prüfer" der das Ergebnis in das erfindungsgemaße System speist. Dies gestattet beispielsweise die zentrale Hinterlegung einer Pfändung.

Claims

Patentansprüche
1. Verfahren zur computerimplementierten Verarbeitung von Zahlungsposten, die eine Geldbewegung auf einem Konto zum Gegenstand haben, bei dem bei Eingang eines Zahlungspostens automatisch eine Prufabfolge ablauft und bei Auftreten mindestens eines Fehlers mittels einer Fehlerroutine eine Fehlerfolge aus einem Fehlerroutinenverzeichnis ermittelt wird, wobei samtliche in einem gegebenen Zahlungsposten auftretenden Fehler gesammelt der Fehlerroutine zugeführt werden, im Rahmen der Fehlerroutine eine Gewichtung der aufgetretenen Fehler erfolgt und abhangig von einem Ergebnis der Fehlergewichtung geeignete Fehlerfolgenmaßnahmen veranlaßt werden.
2. Verfahren nach Anspruch 1, bei dem die Fehlerfolgenmaßnahmen vollautomatisch durchgeführt werden.
3. Verfahren nach Anspruch 1, bei dem einer Bedienperson eine auf der Grundlage des Ergebnisses der Fehlergewichtung im Einzelfall gestaltete Anzeige bereitgestellt wird, die die zur Bearbeitung eines gegebenen Fehlers notwendigen Daten umfaßt.
4. Verfahren nach Anspruch 1, bei dem der Zahlungsposten bei einem aufgetretenen Fehler automatisch für eine vorgegebene Zeitspanne zurückgesetzt und nach Ablauf dieser Zeitspanne erneut geprüft wird.
5. Vorrichtung zur computerimplementierten Verarbeitung von Zahlungsposten, die eine Geldbewegung auf einem Konto zum Gegenstand haben, mit einer Prüfeinrichtung zum automatischen Durchlaufen einer Prufabfolge bei Eingang eines Zahlungspostens, und mit einer Sammeleinrichtung zum Sammeln der m einem gegebenen Zahlungsposten auftretenden Fehler, wobei sämtliche gesammelten Fehler nach der Prüfung einer Fehlerroutineneinrichtung zugeführt werden, wobei bei Auftreten mindestens eines Fehlers mittels einer Fehlerroutme eine Fehlerfolge aus einem Fehlerroutinenverzeichnis ermittelt wird, und die Fehlerroutineneinrichtung eine Gewichtung der aufgetretenen Fehler vornimmt und abhangig von einem Ergebnis der Fehlergewichtung geeignete Fehlerfolgenmaßnahmen veranlaßt.
6. Vorrichtung nach Anspruch 5, in der die Fehlerfolgenmaßnahmen vollautomatisch durchgeführt werden.
7. Vorrichtung nach Anspruch 5, mit einer Ausgabeeinrichtung, wobei auf der Ausgabeeinrichtung eine auf der Grundlage des Ergebnisses der Fehlergewichtung im Einzelfall gestaltete Anzeige ausgegeben wird, die die zur Bearbeitung eines gegebenen Fehlers notwendigen Daten umfaßt.
8. Vorrichtung nach Anspruch 5, mit einer Wiedervorlage- emπchtung, wobei die Wiedervorlageemrichtung den Zahlungsposten bei einem aufgetretenen Fehler automatisch für eine vorgegebene Zeitspanne zurücksetzt und nach Ablauf dieser Zeitspanne zur erneuten Prüfung in die Prufemrich-
Figure imgf000050_0001
9. Computerprogrammprodukt mit einem computerlesbaren Medium und einem auf dem computerlesbaren Medium gespeicherten Computerprogramm mit Programmcodemitteln, die dazu ge¬ eignet sind, bei Ablauf des Computerprogramms auf einem Computer ein Verfahren nach einem der Ansprüche 1 bis 4 auszufuhren.
10. Computerprogramm mit Programmcodemitteln, die dazu geeignet sind, bei Ablauf des Computerprogramms auf einem Computer ein Verfahren nach einem der Ansprüche 1 bis 4 auszufuhren .
PCT/EP2002/012923 2001-11-16 2002-11-18 Verfahren und vorrichtung zur computerimplementierten verarbeitung von zahlungsposten Ceased WO2003042942A2 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP02783085A EP1440422A2 (de) 2001-11-16 2002-11-18 Verfahren und vorrichtung zur computerimplementierten verarbeitung von zahlungsposten
AU2002346840A AU2002346840A1 (en) 2001-11-16 2002-11-18 Method and device for the computer-implemented processing of payment postings
US10/846,570 US7636874B2 (en) 2001-11-16 2004-05-17 Method and apparatus for computer-implemented processing of payment entries

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US33147001P 2001-11-16 2001-11-16
US60/331,470 2001-11-16

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US10/846,570 Continuation US7636874B2 (en) 2001-11-16 2004-05-17 Method and apparatus for computer-implemented processing of payment entries

Publications (2)

Publication Number Publication Date
WO2003042942A2 true WO2003042942A2 (de) 2003-05-22
WO2003042942A8 WO2003042942A8 (de) 2003-11-13

Family

ID=23294112

Family Applications (3)

Application Number Title Priority Date Filing Date
PCT/EP2002/012923 Ceased WO2003042942A2 (de) 2001-11-16 2002-11-18 Verfahren und vorrichtung zur computerimplementierten verarbeitung von zahlungsposten
PCT/EP2002/012924 Ceased WO2003042861A2 (de) 2001-11-16 2002-11-18 Verfahren und vorrichtung zur computerimplementierten generierung und verwaltung von vertr�gen
PCT/EP2002/012920 Ceased WO2003042941A2 (de) 2001-11-16 2002-11-18 Verfahren und vorrichtung zum computerimplementierten verarbeiten von elektronischen zahlungsaufträgen

Family Applications After (2)

Application Number Title Priority Date Filing Date
PCT/EP2002/012924 Ceased WO2003042861A2 (de) 2001-11-16 2002-11-18 Verfahren und vorrichtung zur computerimplementierten generierung und verwaltung von vertr�gen
PCT/EP2002/012920 Ceased WO2003042941A2 (de) 2001-11-16 2002-11-18 Verfahren und vorrichtung zum computerimplementierten verarbeiten von elektronischen zahlungsaufträgen

Country Status (5)

Country Link
US (1) US20050010512A1 (de)
EP (3) EP1609088A2 (de)
AT (1) ATE557364T1 (de)
AU (2) AU2002346840A1 (de)
WO (3) WO2003042942A2 (de)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070055653A1 (en) * 2005-09-02 2007-03-08 Guerra Currie Anne-Marie P System and method of generating automated document analysis tools
US20070055696A1 (en) * 2005-09-02 2007-03-08 Currie Anne-Marie P G System and method of extracting and managing knowledge from medical documents
US20070055670A1 (en) * 2005-09-02 2007-03-08 Maycotte Higinio O System and method of extracting knowledge from documents
EP1801744A1 (de) * 2005-11-23 2007-06-27 Ubs Ag Computer-implementiertes System zur Erzeugung, Bearbeitung und Verwaltung von strukturierten Datensätzen
EP1798673A1 (de) * 2005-11-23 2007-06-20 Ubs Ag Computer-implementiertes System zur Erzeugung, Bearbeitung und Verwaltung von strukturierten Datensätzen
EP1798672A1 (de) * 2005-11-23 2007-06-20 Ubs Ag Computer-implementiertes System zur Erzeugung, Bearbeitung und Verwaltung von strukturierten Datensätzen
US20070265853A1 (en) * 2006-04-03 2007-11-15 Hall David R Database Mechanism
WO2009036398A2 (en) * 2007-09-13 2009-03-19 Siemens Product Lifecycle Management Software Inc. System and method for a product definition
US20100042520A1 (en) * 2008-08-12 2010-02-18 27804Branch Banking and Trust Company System and method for an electronic lending system
US20180053164A1 (en) * 2008-08-12 2018-02-22 Branch Banking And Trust Company Method for Retail On-Line Account Opening With Early Warning Methodology
WO2012048234A2 (en) 2010-10-07 2012-04-12 Morgan Stanley System and method for risk monitoring of rated legal entities
US11514511B2 (en) * 2020-03-24 2022-11-29 Saudi Arabian Oil Company Autonomous bidder solicitation and selection system
DE102022204489A1 (de) 2022-05-06 2023-11-09 Robert Bosch Gesellschaft mit beschränkter Haftung System und Verfahren zum Erstellen einer Kostenkalkulation

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030023539A1 (en) * 2001-07-27 2003-01-30 Wilce Scot D. Systems and methods for facilitating agreement definition via an agreement modeling system

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Keine Recherche *

Also Published As

Publication number Publication date
EP1440423B1 (de) 2012-05-09
EP1440422A2 (de) 2004-07-28
WO2003042861A2 (de) 2003-05-22
AU2002346840A1 (en) 2003-05-26
ATE557364T1 (de) 2012-05-15
WO2003042941A8 (de) 2003-11-13
AU2002358515A1 (en) 2003-05-26
WO2003042861A8 (de) 2004-12-16
EP1609088A2 (de) 2005-12-28
US20050010512A1 (en) 2005-01-13
EP1440423A2 (de) 2004-07-28
WO2003042941A2 (de) 2003-05-22
WO2003042942A8 (de) 2003-11-13

Similar Documents

Publication Publication Date Title
AU2011200605B2 (en) Methods and systems for managing risk managment information
Agrawal Corporate governance objectives of labor union shareholders: Evidence from proxy voting
WO2004032005A2 (de) Verfahren zur automatischen integrierten belegablage bei der protokollierung von geschäftsvorfällen
WO1999067749A1 (de) Anwendungsübergreifendes arbeitszeitblatt
DE10297684T5 (de) System zur Unterstützung der Verbesserung des Geschäftsgewinns
WO2003042942A2 (de) Verfahren und vorrichtung zur computerimplementierten verarbeitung von zahlungsposten
KR20160058062A (ko) 사회적 기업 erp 시스템
US7636874B2 (en) Method and apparatus for computer-implemented processing of payment entries
Kamau et al. Currency risk impact on the financial performance of multilateral banks
Kirabo et al. Strategic innovation, a contemporary management practice on performance of telecommunication companies in Rwanda
US20160012535A1 (en) Data Processing System and Method for Deriving and Publishing Knowledge of Registered Investment Advisors and Related Entities and People
DE69911208T2 (de) System zur simulation eines geschäftsprozesses
KR20050059969A (ko) 인터넷을 이용한 경영정보제공 시스템 및 그 방법
Wescott E-government: enabling Asia-Pacific governments and citizens to do public business differently
DE112020006013T5 (de) Ein system zur investitionsförderung und verfahren dafür
Kirabo et al. Strategic alliance management practice and performance of telecommunication companies in Rwanda
EP1457909A2 (de) Verfahren zur Ermöglichung eines Unternehmenswechsels
WO2005048049A2 (en) Asset allocation, rebalancing, and investment management system
EP1546963A1 (de) Verfahren und system zur automatischen speicherung von betriebswirtschaftlichen daten
Bielefeld Automation and Digitalization in Financial Accounting and Auditing
DE202022104317U1 (de) System zum Verwalten und Nachverfolgen eines wiederverwertbaren Rohstoffs
Vladimirovna et al. Analysis of financial market trends in the company Ericsson Nikola Tesla plc.. In terms of breaking out of the economic crisis with reference to the code of corporate governance
Kubíčková et al. Family Firms And Financial Literacy
Farrell et al. Civilian Personnel: Additional Guidance and Consistent Data Reporting Could Help Improve the Marine Corps' Budget Management
Sapovadia Critical Analysis of Accounting Standards vis-à-vis Corporate Governance Practice in India

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SC SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LU MC NL PT SE SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

WWE Wipo information: entry into national phase

Ref document number: 2002783085

Country of ref document: EP

121 Ep: the epo has been informed by wipo that ep was designated in this application
D17 Declaration under article 17(2)a
WWE Wipo information: entry into national phase

Ref document number: 10846570

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 2002783085

Country of ref document: EP

WWR Wipo information: refused in national office

Ref document number: 2002783085

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 2002783085

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP