EP1440422A2

EP1440422A2 - Method and device for the computer-implemented processing of payment postings

Info

Publication number: EP1440422A2
Application number: EP02783085A
Authority: EP
Inventors: Martin Schroter; Rolf Haas; Roger Gutbrod; Hans-Dieter Scheuermann
Original assignee: SAP SE
Current assignee: SAP SE
Priority date: 2001-11-16
Filing date: 2002-11-18
Publication date: 2004-07-28
Also published as: US20050010512A1; ATE557364T1; WO2003042861A2; WO2003042861A8; WO2003042941A2; EP1440423A2; WO2003042941A8; AU2002358515A1; AU2002346840A1; EP1609088A2; EP1440423B1; WO2003042942A8; WO2003042942A2

Abstract

Method and apparatus for the computer implemented generation and administration of contracts between a supplier and one or more customers, wherein each contract consists of core data relating to a product which is the subject of the contract and one or more contractual components, the core data being stored in a first memory unit and the contractual components being stored in a second memory unit, and in order to draw up a contract a selection of core data is made and the contract is generated electronically of the selection made by automatically generating and depositing electronic references (links) to the selected core data and contractual components.

Description

Method and device for computer-implemented processing of payment items

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.

According to the invention, a method with the features of claim 1 and an apparatus with the features of claim 5 are proposed.

Accordingly, 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. According to the invention, 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. In particular, in the event of a mixed occurrence of errors that can be processed fully automatically and errors in which human decision support is to be used, depending on the composition an economical procedure is initiated automatically, in which, for example, the machine-processable errors are first processed before the process is passed on to an operator, or mechanical processing is initially dispensed with, since the error to be processed by the operator is so serious that it does not seem worthwhile to work on other errors before correcting this error.

In an advantageous embodiment, 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. As a result, according to the invention, the time spent by a specialist in error processing is significantly reduced, since all of the information required for error processing is provided directly or via a link.

In a particularly advantageous embodiment of the invention, 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.

The invention extends of course to computer programs comprising program code means that are adapted auszufuhren when the computer program on a computer erfindungsgemaßes method, and a computer readable Datentragermedien with abgespeicher it ^¬ th inventive computer programs and computer program products with such computer-readable Datentragermedien. Further advantages and refinements of the invention result from the description and the accompanying drawing.

It goes without saying that the features mentioned above and those yet to be explained below can be used not only in the combination indicated in each case, but also in other combinations or on their own without departing from the scope of the present invention.

The invention is shown schematically in the drawing using an exemplary embodiment and is described in detail below with reference to the drawing.

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.

The technical environment of the invention is first described below.

The applicant of the present patent application has carried out in-depth market and competition analyzes in cooperation with international banks and consulting firms, the results of which are reflected in the applicant's current software solutions and in the further development projects. Based on this cooperation, a target application landscape for banks has been developed in recent years, which is based on the needs of the international financial markets. The individual applications of this software architecture represent solutions and integral components of the so-called e-business solution mySAP Banking. Essentially, mySAP Banking can be divided into the areas of core banking, SEM for banks and CRM for banks.

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. In the following versions, 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".

The 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:

• Customer-centered and sales channel-neutral support of the sales / service processes.

• Quick response to system requirements for the mapping of new products.

• Possibility of integrating new business processes.

• Processing of contracts independent of product lines as well as uniform inventory management.

• Integration and consistency of internal and external accounting.

The following requirements are placed on the application landscape

• Flexible modernization of the application landscape over many years (depending on the investment cycle of the applications).

• Fast response options to changing business models (e.g. outsourcing, insourcing).

• Customer-specific expandability without modifying the standard solution.

• Support of different migration scenarios.

• Flexible integration into existing application Country ^¬ partnerships with banks.

• Reduction of interface complexity through integrated processing within the SAP application landscape.

From this follows for the desired application landscape: • The individual applications are interchangeable and expandable. In particular, individual applications must not be too extensive. In an integrated SAP system landscape, individual applications must be deactivated and third-party applications can be integrated.

• The bank decides on the desired range of standard functions by selecting the applications.

• Every application must be expandable so that integration into customer-specific application landscapes can be developed by SAP, by certified partners or by the customer himself.

Clear responsibility for applications

If one looks at central banking processes, various tasks and information needs can be derived from this. These different requirements are partially in conflict with each other and prevent the optimal design of individual solutions. For example, customer-centered process processing is the requirement of the sales and service organization for a solution. The cost-saving processing of contracts and accounts, however, is contract-oriented. Internal and external accounting in turn align the processes with legal and organizational conditions.

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:

• Technical communication (services)

• Business management

There are various solutions in the market for technical communication. They enable information to be exchanged between different databases in different formats.

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 interaction between applications and middleware is of strategic importance for SAP and is currently being actively promoted. The question of performance plays an important role in the analysis of technical feasibility.

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:

• Applications for customer-centered execution of sales and service processes.

• Applications for the implementation and control of trading processes.

• Applications for contract-centered, high-performance processing. • Applications for legally and organizationally induced data calculation and preparation for bank management.

• Applications for the central provision of data that optimally support the other areas without being managed there redundantly.

FIG. 1 shows a schematic diagram of a block diagram which represents a target application landscape for an account management according to the invention.

On the top level of the block diagram in FIG. 1, in the “Point of Sales & Services” field, there is the customer interface to the bank's sales and service point, such as the call center for telephone banking or a branch counter.

In the second level of the block diagram below, "CRM" stores data relating to the customer, operational data is data for existing customers, analytical data is data for new customer acquisition.

Finally, in the third level of the block diagram, contracts are concluded with customers under "Transaction Banking". These contracts concern accounts, loans, collateral, payment transactions, custody accounts, etc.

In the lowest level, the fourth Banksteue ^¬ is tion.

Each bank communicates with the markets and requires interfaces for this. Gel worth mop-border transactions and Geschaftsvorfalle are sequentially numbered gene ^¬ in the re ^¬ from this interface. They are of central importance for a bank because they also represent the appearance. Selbstver- These interfaces are diverse in terms of status. The following can be mentioned as essential interfaces:

• Personalized two-way communication: branches, call centers, processing offices and trading rooms. Documentation and, as a rule, confirmation of the communication results is necessary at this interface. This form of communication is usually very personnel and cost intensive.

• Personalized one-way communication: self-service terminals, Internet, telephone. Here, a party acts through data entry and receives a system-generated result. In this case, the bank is not represented by employees, but by the system reaction.

• System-driven two-way communication: electronic trading systems, clearing systems, payment systems, market data import, data exchange with credit agencies, reports to supervisory authorities. Here, bank employees only intervene manually in the event of malfunctions.

While payment systems have been continuously working on a system-driven data exchange for the past decades, an innovative change for customer service has only begun with the direct banks. The upheaval was accelerated by the Internet and, after the retail business (online banking), now also covers the wholesale community (eg processing letters of credit) and trading (eg auctioning of emissions; increasing number of electronic trading places). These new interfaces must be integrated into a bank's existing IT landscape. It is therefore sensible to decouple and encapsulate the sales channels in such a way that they can be quickly adapted to the rapidly changing trends. This fast response time can only be achieved if the front ends contain as little business logic as possible and are in a "sales channel neutral" application area.

All customer-initiated business incidents should be recorded in the frontends. This is the only way to use the synergies and process optimizations of a modern software solution. Furthermore, the organizational decision to allow the recording of certain business incidents directly by the customer is easier to implement (e.g. the now customary recording of payment orders at the self-service terminal or via internet or cell phone, ordering travel payment means etc.).

There is a network between the forms of communication. For example, telephone users can be connected to a call center with one click if they have problems entering data. Against this background, it is important so as to keep the data on all sales channels away on ei ^¬ nem uniform stand so that all employees about the activities and history are aware of the customer.

Customer Relationship Management (CRM) encompasses the entire range of analyzes, activities and documentation in the context of customer contacts. Thus, not only Verkaufspro ^¬ processes and relevant the associated marketing activities, but also services during the contract period. For SAP, CRM is more than a database of marketing data. It includes ope ^¬ rative processes with appropriate data storage. Lots In current market solutions, functions are available redundantly for each "channel". The immediate, sales channel-independent availability of business and sales functions is the goal of SAP in the context of CRM applications.

The following processes can be defined in operational CRM:

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. Depending on the business area (retail / wholesale), product (payment transaction / asset or liability business or commission business) or 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 following customer-centered and sales channel-neutral solutions are required in this application area to map the processes named above:

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.

Important processes:

• Conclusion and documentation of the contractual and pre-contractual customer agreements.

• Content and time monitoring of contractual and pre-contractual conditions and events (e.g. payment requirements; lack of legitimation; prolongation dates).

Market-related configuration of products takes place in product management. This process takes place in coordination with the processing area of a bank. The presentation of products in this application area concentrates on the market presentation of these products, ie on the variable forms that a customer can choose. The product must support the mass business in the retail business and ensure a uniform product portfolio and thus contract portfolio. The degrees of freedom of individual products are generally limited (for example, a savings letter usually only has the nominal amount and the term as optional parameters). In contrast to the Retailgeschaft Whole- is characterized salegeschaft of high degrees of freedom within the Pro ^¬ domestic product since the contractual arrangements must provide highly customized forms.

Important services:

• Configuration of the product parameters

• Product calculation Activities and contact management make it possible to record, monitor and control activities with the customer. Furthermore, all contacts with the customer are documented and can be evaluated according to various characteristics. The bank receives a "virtual" customer advisor who is available to all sales channels. For example, a complaint through the call center is also visible to the branch employees. This ensures a uniform level of information for all employees who are in contact with the customer. The customer activities about the internet must be integrated into contact management accordingly.

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:

• Customer segmentation and profiling

• Campaign management

• Database marketing

Corresponding solutions under trim the bank at the Pla ^¬ planning and implementation of marketing activities, started in segmentation and profiling of customers pass through to the planning, implementation and control of marketing campaigns. According to the invention, the CRM is of strategic importance in order to be able to offer complete solution competence.

Applications to support trading activities are characterized by high product specializations. These solutions are characterized by special know-how and short investment cycles. Some of the existing systems for the trading room still map back office processes. A clear cut makes it possible to process settlement and billing processes in a cost-reducing manner. Trading systems be ^¬ sit frequent rudimentary risk controls. In banks, there is an increasing requirement that the control instruments of overall bank management are made available directly in the trade area, adding value.

Important processes in this area are:

• Product configuration for the retail business

• Contract management for the retail business

• Limit management for trade (exposure management)

According to the invention, no trading system is provided, but the trading activities are monitored.

The following initial situation exists in the "Transaction Banking" area: The globalization of the banking market expresses, among other things, the intention of market participants for efficient company sizes. To the desired Skalierungsund specialization effects take full advantage, has triebs- in recent years, partly in-house, but also partly operational over-reaching separation of Ver ^¬ and transaction banking emerged. Outsourcing solutions are an example that the "transaction ^¬ bank" has as an independent business model success. However, Even if the processing in your own company is retained, attempts are made to optimize the processing of customer business through automation and centralization.

Banks are currently operating in their application landscapes with a large number of product or division-specific systems. The transactions are costly and not scalable. Standardization of processing processes and extensive product line neutrality in the banking business are essential requirements for this application area. The configuration of processing processes should be accelerated and made more flexible through product configurations. The possibilities of the expandability of the software are of crucial importance, especially considering the long investment cycle of 15-20 years in this business area.

For SAP, this application area makes a significant strategic contribution to process optimization in the international banking world. 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. In addition, 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. In operational CRM, 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.

Only legally valid contracts are kept in account management, i.e. Simulation transactions, offers and applications are outside the operational CRM.

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. In addition, 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.

Basically, 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 ^¬ erauftrag 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 (securities settlement / custody account 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:

• Name and address of the business partner

• Additional data depending on the business partner type (e.g. date of birth; legal form) for all application areas (e.g. industry key for marketing selections or reporting)

• relationships (eg borrower unit; Konzernstruktu ^¬ ren)

• Roll • Identification data

• Credit data / data from credit agencies / sconng results / marketing clusters

• Budget statement data or balance sheet analysis

• Total commitments

Relationships between business partners can be linked in a variety of ways. Functions are available for creating borrower and risk units.

Customers appear in defined roles towards a bank (e.g. account holder, borrower, guarantor). For this reason, the business partner application has the role of a customer as a supporting component.

The application area "Central Services" contains solutions that support the banking business of the other areas.

• Collateral management

• Output and input management / correspondence

• Market data, securities master data, info services

• Administrative services: authorizations, organizational units

Collateral management is of particular importance due to the Basel decisions on credit risk coverage. By differentiating collateral, a bank can optimize the capital backing and thus reduce borrowing costs. Furthermore, 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. There is currently hardly any solution on the market for this second aspect. But activities of a bank in the field of derivatives also require the documentation and management of self-provided collateral.

Collateral management is an important part of the overall solution.

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).

In addition to the choice of output media, a high level of functionality is required in the control and preparation of paper-based correspondence. The key words here are: central print preparation; Forms and postage optimization.

The invention supports the correspondence-oriented data selection and preparation. Further processing in a printing and shipping line is carried out by special providers.

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.

These are solutions that provide information for several applications within a bank.

The "Administrative Services" services are used to properly organize banking operations.

The existing system landscapes have historically grown at most banks. Our operating systems play a central role and serve downstream Sy ^¬ stems often with already pre-calculated results. This often results in different results and a complicated reconciliation and coordination process. The timely basis for decision-making can no longer be created.

The requirements for bank management are therefore single source of the database and method consistency across all evaluation processes. In order to achieve the goal of coordinating data and methods, the systems of a bank have to be organized differently than before. In particular, there should be a clear cut between the operational systems and the applications of overall bank management. This relieves the operational systems of the downstream processes of the overall bank management and at the same time centralizes the processes. 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:

• accounting

• Profitability / controlling

• Active / passive control

• Risk controlling o Market risk / internal models o Credit / counterparty risk o Counterparty risk o Country risk

• Notification

• Limit management (analytical)

Transaction banking has the following central tasks:

• Control of money and stucco traffic

• Processing the contract portfolio

• Sales management and management of the legal inventory on the cash and stucco side)

The scope of the transaction banking solution is described below.

The functionality of the Transaction Banking in the Ge ^¬ the application landscape overall context embed, first addresses the following aspects:

• Processing options

• Leading data storage

• Product configuration and financial terms

editing options Transaction banking, as a separate application area, has the need to be processed directly. The reasons for this can be:

• Planning and limit management for quality assurance of the portfolio.

• Complaint processing, such as Gebuhrenkorrektur.

Inventory management processes, such as Processing and reconciliation of one-time accounts.

• Corrective measures due to incorrect or missing data import (e.g. value date corrections, booking corrections).

Traditionally one speaks of the account management as a supplement to the customer advisor. The invention is designed in such a way that the implementation of the account manager is possible. This role comprises the following two fields of work:

On the one hand, there are activities that have a direct external effect on the customer (e.g. limit reduction) and, on the other hand, activities that only affect the inventory "without customer contact" (e.g. one-time processing, data corrections).

There are two types of processing layers in transaction banking:

• Basic Maintenance Interface (BMI)

• Processing office (Account Management Office / AMO)

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.

These surfaces do not take into account customer organizational processes and processing optimizations.

The processing office (Account Management Office / AMO) 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 Officeaktivitaten to the central contact Manage ^¬ ment is transmitted, so that a fully kundenzen ^¬ trated view bank-wide possible.

Today, there are often processes in processing that do not belong in this area (eg opening a contract by post). In addition, market studies show that the aim of banks is to streamline many back office processes by 70-80% simply by shifting them to the customer, as is already possible in internet banking (e.g. opening a contract) , This is because processing is only as efficient as possible if the bank customer can initiate business transactions such as a card block or carry out the payment order disposition himself.

Leading data storage

In each application landscape there can only be one "master" for the data, to which other applications can directly access or receive periodic updates.

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.

The same applies to sales and balances. Therefore, data is provided for the account statements and for a data warehouse on this basis.

The extent to which applications must keep data redundant is largely determined by the performance requirements and depends on the customer-specific situation.

Product configuration and financial terms

product configuration

As shown in the target application landscape, 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. Here the product configuration is based on the marketing and sales needs.

• The mapping of the settlement product with all settlement-relevant control parameters within the transaction banking / account management.

A product compared to the market can be divided into several sub-products for processing.

• The configuration of products for bank management. These products generally have a different granularity than the settlement products. The data budget is also geared to the evaluation needs and not to the processing requirements.

In the three main processes of banking, the product is different, with one exception: "The financial terms of the product". For this reason, the financial terms are shown in addition.

The product configuration ultimately spans all three application areas. A comprehensive coordination between the application areas is necessary as part of a new product implementation. Taking care of the Pro ^¬-products takes place in every area of its own:

In transaction banking, product maintenance takes place using Customizing. Authorization and release are secured using the SAP transport procedure.

The 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). The following are given in the interface: • the customer

• the product ID

• and the individual terms of the contract.

The connection to the processing (part) product is established by the product ID.

financial conditions

The financial conditions are the basis for the interest and fee calculations. As a result, they have a special meaning and must be available in every application area. Access as part of inventory management is critical. In order to guarantee the uniformity of the conditions beyond the limits of individual application areas, SAP provides the financial conditions of the account management via BAPIs to all other applications.

Figure 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.

It is conceivable that 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.

There can only be one "master" for all contract data in an application landscape. This "master" for the processing data lies in the account management. In addition, the processing of contracts is largely automated. This means that you know the current contract status (e.g. after prolongations). The contract data are made available at interfaces.

For your understanding, it should be mentioned that there is of course contract data that is managed in other applications and managed there as a "master" (e.g. Schufa license plate, authorization to dispose). The central anchor for merging all data is in operational CRM.

Important processes in account management are:

Creating, changing, prolonging, informed, canceling and dissolving contracts. Appropriate postings are also triggered. Two types of contracts are supported:

• Account contracts

• Card contracts (see below)

The support of other contracting parties is of course possible.

sales administration

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).

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.

System reactions are:

Booking, re-scheduling, post-processing, return, rejection, one-time booking.

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).

Central applications, such as standing order and payment order management, are also provided as additional functions (see previous versions).

The card solution uses the same components of product configurator, contract and financial terms as account management. Thus, 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). 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.

External job control systems can also be integrated.

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", and 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. In account management, 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.

For example, if a business partner registers a comparison, the Posting Lock Manager distributes the corresponding locks. So 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.

Due to the primary task of account management to manage the legal inventory, flexible reporting is available. There are also numerous lists, such as overdraft, balance and turnover lists. It is also possible to create lists for account and check blocks and Generate reconciliation balance lists for comparing payment balances.

The definition of further reports is flexible.

Accessory applications for account management from the perspective of the application landscape are:

Posting control of fice

• Dynamic limit determination

• Dunning / default interest

As already mentioned in the introduction, 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.

To make the payment items in Account Management on booking obstacles (blocking) and accounts for which there is ei ^¬ ner unauthorized overdraft, a re ^¬ gelwerk (posting control rules) to be scheduled according to. This customer-specific adjustable ^¬ regulations is managed ment in Account Manage ^¬. If necessary, information about payment items that are not explicitly rejected in response to the Posting Control Rules is sent to the Posting Control Office by means of a posting control order, where their further processing (disposition) takes place either automatically or manually. The maschi ^¬ nelle disposition (repetitor) comprises automatically re-submission of payment items for registering to the account management. Payment items for which only temporary booking Obstacles (eg limit problems) can be scheduled using the repetitor without manual intervention.

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.

Manual processing of payment items to be scheduled takes place on the Posting Control Desktop. In this partial solution, the role-based design and usability are of central importance. The dispatcher is supported by the access to MRP-relevant data in his decision either to finally process payment items (e.g. post actions, reject, etc.) or to transfer them to the automatic disposition.

Dynamic limit determination is a solution that is particularly necessary in automated mass business. This is a Zubehorapplikation 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 following reactions are possible within the rules for material disposition according to the invention:

1. Book

The item is posted to the account with an update of all objects involved. No posting control order is created.

2. Post processing

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.

3. Post-scheduling

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.

4. Reject

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.

5. Returns This reaction is only useful for recipient items. 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.

For example:

• A customer gives his liability insurance approval to collect his contributions via the direct debit procedure. When 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.

• A customer blocks a check. The check should be debited to the customer account. There should be an automated return. 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.

6. Redirection

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. In the event that the redirection to a one-time account takes place, a posting control order is created for the posting control office.

For some business incidents, it is necessary not to make the booking on the original account of the item. but to redirect the payment item to internal accounts. This can be done automatically using the Posting Control Rules. If a redirection to an account is to take place, an account must be entered when specifying the reaction "redirect".

Within the Posting Control Rules, an account symbol is stored for the previously described accounts at the reaction "redirect". This account symbol is replaced in a subsequent step by a real account number. This procedure has the following advantages:

- Simplification of changing an account by changing it at a central point in Customizing. The Posting Control Rules do not have to be changed.

- Transparency of the influencing factors when finding the account

The defined account symbol is differentiated using the following fields:

• Bank country and sort code

• Currency

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.

For example:

The following entry is stored in the Posting Control Rules.

Blocked guaranteed redirection damage control card payment

The "Damage settlement" account symbol is replaced by the following entries:

<=> Damage settlement branch 1, DEM account 4711 ^■ => Damage settlement branch 2, DEM account 4712 ^■ => Damage settlement *, DEM account 4713 ^■ => Damage settlement *, EUR account 0815

If an account symbol is stored in the redirection reaction, redirection to the specified account takes place automatically. The original recipient details (account number, bank code, bank country) are recorded at the payment item.

If an account symbol is stored in the postprocessing or postprocessing reactions, the specified account is passed on to the downstream Posting Control Office for information purposes.

reaction basis

At the moment (as of TRBK Giro 2), business management requirements for the "return" and "reject" reactions can be defined in Customizing. In the "Return" response, the assignment of the field controls the attributes for the execution of the return (see "Return" specification). In the "reject" reaction, the reason is reported back to the ZVS and can be evaluated there. Reason for reaction can be entered in the rule entries for the primary as well as for the follow-up reaction. Entries for the follow-up reactions can be entered the Po ^¬ sting Control Office for final processing passed. If a downstream Posting Control Office was able to transfer the transferred item to a processing account, an account symbol for the proposal account is stored here.

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 Erstre ^¬ 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.

Handling formal errors

If a formal error or a system error occurs during the processing of an item, this overrides the rules for material disposition. The processing of the item is canceled and the cause of the error is recorded.

This does not apply to all errors that can be identified during the formal examination. Following He ^¬ results of the formal examination did not go generally to ei ^¬ ner rejection of the payment item from account Manage ^¬ ment, but may in the posting control rules by depositing rule entries are scheduled: α tests on the posting date: for deficiencies resulting from this

Examination can be made using the Posting Control

Rules are done. α Checks for the existence or status of the account in the AM: For client items, errors from this check lead to rejection of the payment item. However, recipient and sales items can be redirected to one-time accounts using the Posting Control Rules if the one-time processing is carried out in AM and the one-time account determination is therefore stored in Customizing.

Determination of the valid rule

• The determination of the valid rule takes place using the following scheme:

In general, fully qualified access has priority over unqualified access. The key is generalized (dequalified) in the following order:

7. Channel

8. Posting control group

9. Product

10. Transaction type group

11. Item type

12. Type of error

This means that access is first carried out with a fully qualified key. If a corresponding entry is found here, this is the valid one. '→ -If not, access is performed without the Channel field. If an entry is found here, this is the valid one.

"→ - If not, the access is carried out without the errors channel and posting control group (dispo group). If an entry is found here, this is the valid one. Etc.

Example: The following is set in the Posting Control Rules:

This setting ensures that an automated return takes place only for everyone accounts

• The valid response to several valid rules is determined as follows:

One or more different error messages (or error types) 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:

Reject has priority over return has priority over redirection has priority

Post-processing has priority over post-processing has priority over booking

If no error in the objects firmly ^¬ identified and found no entry in the rules for bookings, the item is posted.

At least all the data are offered that are only known during sales processing. The interface to the Posting Control Office (which data is accepted and saved) is described in the "Posting Control Office" specification. All error messages that were determined during sales processing are offered to a downstream Posting Control Office for information purposes by means of a disposition order (Postmg control order). The same applies to error messages that have already been transferred by the application system via interfaces.

Reference to the generated turnover

As before, items are generated in sales processing with the various status values. In addition, a disposition order is created, which should initiate further processing of the sales / account.

The following fields must be transferred so that the MRP order can reference the generated items:

• system

• Client

• the application system (here: Account Management (AM) / possible other systems: payment system)

• Identification of the payment item

• Position of the payment item

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:

• In most cases, the reaction "postprocessing" (items not yet posted) requires an examination of the item

• The response "subsequent buying" (item is already booked ge ^¬) requires a follow-up assessment of the item and / or the account feedback

The feedback to the feeder system should be carried out for each item at the following level:

→ rejected (reasons based on test objects)

→ Booked

→ Post-dispatching (reasons based on test objects)

Required because execution confirmations are required for certain target-related bookings (EDIFACT / FINPAY)

→ Postprocessing (reasons based on the test objects)

The following example of the need for feedback was given here. A standing order is deleted if there is a "no cover" error for 3 months. This is not the case for other blocks.

→ Return (reasons based on the test objects)

→ Redirected (reasons based on test objects)

→ In addition, the formal errors' account not available 'and technical errors' must be included in the feedback

The reactions of the Posting Control Rules to return codes are assigned as follows:

In the case of an automatic booking check, according to the invention, when an error occurs, rules called "Posting Control Rules" which automatically trigger preset (customer-specific) sequences.

During the booking check, all check items according to the invention are checked (in a departure from the prior art, where an exit from the check routine occurs with the first error message), and all errors are collected. This allows a weighting of the total errors found in the context of a booking check with regard to the relevance of the individual errors.

If automatic processing is not possible, as can be the case, for example, when the name is checked because the names do not match, the process is submitted to the Posting Control Office module. 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.

The distribution of orders in Posting Control Office he ^¬ follows to preset criteria, depending on the qualifications and the demands of the test. When the screen is opened, a check is carried out to determine whether the error is still present, for example whether there is one Cover is given again. This is ensured by the so-called 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.

Furthermore, 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.

There is also a link between the lock management and the Posting Control Office, so that the automatic check can clarify why a lock has occurred. Locking reasons can be called up directly from the so-called Posting Lock Manager (preferably on the screen display using the tab selection).

In addition, a modification-free extension by customer-specific blocking objects is possible, and there is an automatic check by an additional "inspector" who feeds the result into the system according to the invention. This allows, for example, the central deposit of a garnishment.

Claims

claims

1.Procedure for the computer-implemented processing of payment items which have the object of a cash movement in an account, in which a check sequence runs automatically when a payment item is received and, if at least one error occurs, an error sequence is determined from an error routine directory using an error routine, all of which in one Given errors occurring in the given payment item are fed collectively to the error routine, the error routine is weighted as part of the error routine, and suitable error sequence measures are initiated as a function of a result of the error weighting.

2. The method according to claim 1, in which the fault follow-up measures are carried out fully automatically.

3. The method as claimed in claim 1, in which an operator is provided with a display which is designed on the basis of the result of the error weighting in the individual case and which comprises the data necessary for processing a given error.

4. The method of claim 1, wherein 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.

5. Device for computer-implemented processing of payment items that have a cash movement in an account to the object, with a test device for automatically running through a test sequence upon receipt of a payment item, and with a collecting device for collecting the errors occurring in a given payment item, all collected errors being fed to an error routine device after the test, and if at least one error occurs by means of an error routine, an error sequence is determined from an error routine directory, and the error routine device carries out a weighting of the errors that have occurred and, depending on a result of the error weighting, initiates suitable error sequence measures.

6. The device according to claim 5, in which the failure measures are carried out fully automatically.

7. The device according to claim 5, with an output device, wherein on the output device, a display based on the result of the error weighting in the individual case is output, which comprises the data necessary for processing a given error.

8. The device according to claim 5, with a resubmission device, the resubmission device automatically resetting the payment item in the event of an error for a predetermined period of time and after this period of time for re-examination in the test device.

On a computer auszufuhren 9. Computer program product comprising a computer readable medium and a program stored on the computer readable medium of the computer program with program code means which corres ^¬ are suitable when the computer program a method according to any one of claims 1 to. 4

10. Computer program with program code means which are suitable for executing a method according to one of claims 1 to 4 when the computer program runs on a computer.