Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR 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; CALCULATING OR 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; CALCULATING OR 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; CALCULATING OR 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; CALCULATING OR 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; CALCULATING OR 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; CALCULATING OR 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; CALCULATING OR 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; CALCULATING OR 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 the computer-implemented management of financial processes and in particular for the generation and management of contracts, preferably contracts in connection with financial services.
• contracts between a provider and one or more customers are generated and managed using a computer.
• the contracts to be generated and managed consist of core data for a contractual product and consist of one or more contract components, the core data being stored in a first storage unit and the contract components being stored in a second storage unit.
• a selection of core data is made and a selection of contract modules is made, and the contract is generated electronically on the basis of the selection made by automatic generation and storage of electronic references (links; so-called pointers) to the selected core data and contract modules.
• a so-called contract framework is provided, which helps to minimize the amount of data to be managed.
• GUID Global Unified ID
• I- dentification a contract with all the ingredients, that can be clearly linked to external data, whereby the external data can then also change without a link or link being lost. Coupled with a deposit of several, preferably three, holiday calendars, this results in a system that can be linked worldwide, in which domestic and foreign bookings can be made in particular by means of only one system.
• Procedural limits can be set by the bank itself.
• the basis of the error concept according to the invention is a uniform representation of the errors originating from individual contract modules.
• a selection of the core data and a subsequent selection of the contract modules is carried out, with the basis of the selected core data, which contains information and rules relating to the contractual product, automatically checking the admissibility of the selection of individual contract modules.
• This measure according to the invention makes it possible to automatically check the admissibility of the composition of individual contract modules when the contract is being designed. In order for the In ⁇ entfallt wall to the further testing of a landscaped contract.
• the procedure according to the invention enables information and rules relating to the subject matter of the contract products, to carry out a central product configuration.
• changes to the core data and / or the contract modules are carried out in the respective central storage unit.
• This measure according to the invention minimizes the maintenance outlay, since changes in individual contract modules (for example, changes due to changes in the law) do not have to be carried out in every individual contract of existence, but can take place centrally.
• a change in the core data and thus the properties of the contractual products can also be changed centrally with effect for all existing and future contracts.
• the centrally made changes to the core data and / or the contract modules are assigned time and / or date details which indicate when a change should become valid. In this way, upcoming changes (e.g. changes to the law from the following year) can be made in advance and will be implemented automatically from the defined later point in time.
• changes in the core data and / or contract modules are recorded over time and stored by means of links. This measure allows changes to be tracked and a contract history to be created.
• a so-called contract framework is thus provided, with which the interaction between the outside world, the contract to be concluded and the contractual product is made possible on the basis of so-called core data and contract components. Any contracts between contracting parties can be mapped.
• the invention is used in the field of finance, ie the provider is preferably a financial service provider such as a bank, and the contractual products are financial products such as checking accounts, savings accounts, credit cards, check cards etc.
• An essential aspect of the invention is not to differentiate between different (product) sectors (such as giro, savings, credit etc.), but to allow a flexible structure through the central product configuration in the core data, which in particular also allows mixed forms, which is not possible with the current state of the art.
• central functions are created by the contract framework for all contract modules and specializations (in the core data), such as time dependency, approval, change documents, direct input, control of the contract, jumps, product changes, copying contracts, central field modifications, authorization, blocking ,
• the contract is clearly identified with an identification, in particular an identification number.
• an identification in particular an identification number.
• This is preferably a globally unique identification (GUID, Global Unified ID).
• the contract which in the end consists of a link or link table, controls the "communication" with the product and ensures that all contract elements receive the properties defined in the product (i.e. in core data).
• the contract receives the central attributes
• three holiday calendars can be stored, which is particularly advantageous when calculating the value date of a booking.
• a (booking) day is considered a public holiday if it is stored as a public holiday in one of the calendars.
• the preferably three holiday calendars are the calendars, which are valid in the area of the organizational unit that manages the contract, the contracting party and the contract maintenance.
• the contract module checks after contract generation whether the data taken over from the contractual product has been changed or not, and causes a link from product to contract module to be saved in a contract link table which contains the link between contract and contract module, if none Change was made, or a saving of the change as a new entry in a contract module table is prompted if a change has been made.
• the invention extends of course to computer programs comprising program code means that are adapted pointed toward the computer program on a computer erfindungsgeterrorismes method and germedien computer readable tragermedien with stored thereon inventive computer programs and computer program products with such computer-readable ⁇ . Further advantages and refinements of the invention result from the description and the accompanying 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 illustrates in a schematic block diagram the embedding of the contract framework according to the invention in a usage environment.
• FIG. 7 illustrates in a schematic block diagram the structural structure of the contractual framework according to the invention.
• Figure 8 illustrates in a schematic block diagram the interaction of the components product, contract and contract module.
• Figure 9 is an illustration of the mapping structures.
• FIG. 10 shows a data model according to the invention.
• FIG. 11 shows a development workbench for developing the business data tool according to the invention in a schematic representation.
• FIG. 12 illustrates the dialog flow in the business data tool according to the invention.
• Figure 13 illustrates the direct entry process
• FIG. 14 illustrates the structure according to the invention oriented towards a contract module.
• FIG. 15 shows a sequence sequence according to the invention when creating a contract.
• Applications are information systems that solve a business primary task and are operational on their own. They hold the data and functions for solving the primary task, i.e. they are closely related activities.
• An application communicates via defined interfaces.
• An application is usually a buyable solution. Examples are the products Account Management, Profit Analyzer and Risk Analyzer.
• 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 limit determination and scoring models) and have their own investment cycle independent of the core applications. This will create a larger xibility guaranteed in the adaptation to changing business policy goals.
• 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 building systems. 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. Customer-specific additions can be connected in a further shell based on BTEs (Business Transaction Events) or BADIs (Business Add-Ins) or use of BAPIs (Business Application Programming Interfaces).
• BTEs Business Transaction Events
• BADIs Business Add-Ins
• BAPIs Business Application Programming Interfaces
• 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.
• Each application must be expandable in such a way that it can be integrated into customer-specific application landscapes.
• Applications communicate via public interfaces. Direct access to applications is not permitted. This ensures that data can be exchanged transparently between applications. A consistent database is guaranteed within an application. Unexpected risks due to unknown links and access can be minimized.
• This communication structure enables direct data exchange between applications via public interfaces or indirect data exchange via public interfaces and business middleware.
• 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 a clear conception of the process control is necessary for reinvestments in these areas.
• 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. Not shown is the area that contains applications that banks need for the processing of their secondary processes, such as human resources management, asset accounting, material management, etc.
• 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.
• the bank control is located in the lowest fourth level.
• 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 contracts can be of any complexity. An example is a loan agreement with repayment by life insurance and a guarantee from a castle. If the contract data is called up, it contains a selection of processing-related information that is supplemented by sales and service-oriented data. These contracts can be processed via several applications, i.e. 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.
• 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 Information level guaranteed for all employees who are in contact with the customer. Customer activities via the Internet must be integrated accordingly in contact 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:
• CRM is of strategic importance in order to be able to offer complete solution competence.
• the Transaction Banking application area contains the main components of payment transactions, account management (processing and inventory management), securities settlement and custody account management (processing and inventory management).
• Account management is responsible for processing the legal portfolio in the sense of of money flows, i.e. 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 Saidenmitigaen.
• the balances and sales items are kept in currency, i.e. kept unrated.
• the inventory is the basis for external accounting, i.e. that the contract and sales data held here form the database for preparing the balance sheet.
• 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 card is processed by a provider and travel insurance at a partner.
• the processing functionality means that automated prolongations 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 administration and execution of standing orders is an additional application in payment transactions (payment order and standing order are within the account management).
• payments order and standing order are within the account management.
• this is also conceivable to do this as a supplementary component within Account Management (e.g. rebooking within 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 in As a rule, several inventory management systems are located in this application area.
• the peculiarity of stucco management is that in the area of 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 an essential intangible asset for ede 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:
• 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. By differentiating collateral, a bank can optimize the capital backing and thus reduce borrowing costs. Furthermore, knowledge of the collateral and its value date is a source for the acquisition of new creations. Collateral is usually recorded when the contract is initiated and concluded and is initiated from operational CRM. Collateral is released as part of the contract processing.
• the management of collateral comprises firstly Safe ⁇ units that takes the bank and on the other collateral that the Bank itself. There is currently hardly any solution on the market for this second aspect. But need a bank's activities in the field of derivatives also the documentation and control of self-provided collateral.
• 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 is located as a central service in the operational CRM.
• the "Administrative Services" services are used for the proper organization of banking operations.
• the existing system landscapes have historically grown at most banks.
• the operative systems play a central role here and often supply downstream systems with 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.
• bank management requirements for bank management are therefore single source of the database and method consistency across all evaluation methods.
• the systems of a bank have to be organized differently than before.
• the data required by the operational systems is made available at a data interface.
• the Basic Main tenance Interface is a surface for processing individual functions.
• This surface allows manual interventions in the otherwise largely automated processing. All functions in this area thus have a 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 ensures the 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 (e.g. disposition orders). Crucial for an office integration is cross-application access to functions and data for the processing of business incidents. Furthermore, the results of the offline activities are to be transmitted to the central contact management so that a fully customer-centered view is possible across the bank.
• 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:
• 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.
• 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 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 directly from the trans saction Banking accessed the contract and changed data. 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.
• Balance-based payment monitoring is conceivable, e.g. controls the receipt of funds in the course of a time deposit or the payment in installments for 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-specific, it can be determined 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. term monitoring for renewal cards).
• central applications such as the management of orders and payment orders, are provided as additional functions (cf. previous versions).
• 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).
• SAP wants to keep the option open to process credit card accounts on the revenue side in the medium term.
• the card administration must be a solution that can be used optionally by the customer, ie 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 exclusive of one 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, i.e. he sets locks that are triggered by business incidents (posting lock events) and removes them after the underlying event has expired. 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 and determines Posting Lock Events from various input channels (back office, call center or counter systems and credit agencies) - according to its rules - the response of the system.
• the solution runs in operational operations (receiving and processing events) largely without manual intervention.
• possible forms of blocking procedures are the contract blocking (the contract as a whole and the blocking of partial functions), the blocking 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.
• 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.
• 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.
• Posting Control Rules Payment items that encounter booking obstacles (blocks) and accounts in which an unauthorized overdraft occurs are scheduled according to a set of rules (Posting Control Rules). This customer-specific, adjustable set of rules is managed in Account Management. 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. Automatic disposition (repetitor) includes the automatic resubmission of payment items for posting to Account Management. Payment items for which there are only temporary obstacles to posting (e.g. 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.
• Dynamic limit determination is a solution that is particularly necessary in automated mass business. This is an accessory application for account management that enables the individual bank to automatically set limits for the customer based on defined rules and input parameters.
• 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.
• FIG. 5 shows a summary of the structure of the core application Account Management using a schematic block diagram.
• the link table stores the assignment between the contract and the contract modules. Any number of assignments and the function of the assignment can be saved between the contract and the contract modules.
• the assignments are time-dependent. Release and change documents are also saved here.
• Various attributes are key fields for the link identification and time stamp, the contract identification, the name of the Contract module, identification for the module table etc.
• contract module is to be understood as the sum of the code of a contract module, that is to say the coding which the contract module data and its process logic represent, for example, in dialog or store in the contract module table.
• the contract module table is / are the database table (s) of the contract module (naturally does not apply to contract modules without their own database table).
• Contract building data is the data of a contract module that is assigned to a contract. The data is normally stored in one row of the contract module table but also contract modules in which the data takes up several lines, and other contract modules do not have a contract module table at all, but contract module data do.
• Each contract component is in turn encapsulated in its own development class, which leads to decoupling.
• the contract modules in account management can be used across product types, so that fields that belong to a common (business) topic are grouped into a contract module.
• generic contract modules and product type-specific contract modules (account contract modules, card contract modules, card community contract modules, account pool contract modules, etc.).
• properties are of a general nature, such as the connection of the business partner, the contract conditions, limits, payment details, notice periods, correspondence requirements, related contracts, contract purpose, contract name and the like. included, while attributes such as bank statement, account closure, general ledger update, posting blocks, debit orders, balance confirmation, basic account data, alias names etc. are stored for the product type-specific contract modules.
• Link product module or in short “product link” (cf. FIG. 10).
• This entity belongs to the “contract” package and not to the separate product configurator 10.
• the function of the product link is to create an assignment between a product (or a product version) and contract modules and to enable contract modules that do not make changes to the specifications of the product to not have to make any additional entries in the associated contract module table.
• pointers to the contract module data belonging to a product version are stored (i.e. a link between the product and an associated contract module and its attributes).
• pointers are transferred to the contract module so that they can be saved in the contract module link table.
• the contract then points to the same contract module data as the product. There are thus product links between the product and the contract modules and contract links between the contract and the contract modules.
• the invention enables the creation of "contracts via contracts", ie joint contracts such as card associations and the like can be managed as one contract.
• Contracts and contract modules are application data (in contrast to the products and product attributes, which are so-called customization data) that cannot be transported.
• the table of links between the product and the contract module data is therefore an application table, since no contract module data can be created when you create or configure a product, and therefore no link can be created between the product and the contract module data.
• the product when a contract is created by a contract module, the product is not called directly, but instead the product link is called up and the contract module is linked to contract module data.
• the contract module checks whether the data transferred from the product has been changed. If this is the case, the changed data is saved as a new entry in the contract module table. If the data has not been changed, however, only the link (product to contract module data) is saved in the contract link table (contract to contract module data), with the note that the contract is not the "owner" of the contract module data.
• the contract module table remains unchanged.
• the product link table is still empty. If the product link notices that it has not yet saved any links to this product or to this product version, it asks the contract modules concerned to get their "default values" from the associated product, to save them and to return a link to the stored data
• the links or links to the entries - the product link remembers in its own lmktable .. Then, upon request, it gives the links to the individual contract modules as described.
• Changing a contract is an individual change, i.e. Contract module data will be changed with a new entry in the corresponding contract structure table and a new link in the contract link table.
• the contract When creating a contract (cf. FIG. 15), the contract calls the product link with "with". If the product link determines that it still has no links to this product version, it calls the relevant contract modules with "SetDefault”. The contract modules then get their default values from the product with "GetDefault”, save them and give them the link back to the product link. In the further course, the individual contract modules get their links with "Get” from the product link. This means that the "SetDefault” and "GetDefault” processes shown in bold in FIG. 15 only appear when a contract is first created for a specific product or a certain product version.
• ISDST distribute data to participating application
• DSAVB collect data when the application is owned
• the “easy” product (version 1) is created and tested in the customer's customizing system.
• the first contract (No. 1) for the product "easy” is created The contract tells the product link that it should prepare for the product "easy” (call the Init API)
• the product link determines that there are no links to the "easy” product. It now calls up all contract modules with set_defaults-API, including the general ledger data. The general ledger data now fetches its default values from the "easy” product, save them and generate a key for this (HB_1). They return the key to the product link.
• the product link stores all links between the "easy” product and the contract modules.
• the contract modules call up the product link in order to get a link to their data.
• the "General ledger data” contract module calls up the product link with Get_API and receives the HB_1 key.
• the "General ledger data" contract module transfers its key HB_1 to the contract link table and tells it that it is not the contract (but the product) that is the owner of the data.
• the product link gets the links of this product in its buffer
• the contract modules call up the product link in order to get a link to their data.
• the "General ledger data” contract module therefore calls up the product link with Get API and receives the HB 1 key.
• the product link gets the links of this product in its buffer
• the contract modules call up the product link in order to get a link to their data.
• the "General ledger data” contract module calls up the product link with Get_API and receives the HB_1 key.
• the "General ledger data” contract module saves the changed data under a new key (HB_2) and informs the contract link table of the new key and tells it that the contract is the individual owner of this data

Landscapes

• Business, Economics & Management (AREA)
• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Accounting & Taxation (AREA)
• Physics & Mathematics (AREA)
• Finance (AREA)
• Strategic Management (AREA)
• General Business, Economics & Management (AREA)
• Economics (AREA)
• Marketing (AREA)
• General Health & Medical Sciences (AREA)
• Tourism & Hospitality (AREA)
• Health & Medical Sciences (AREA)
• Development Economics (AREA)
• Human Resources & Organizations (AREA)
• Audiology, Speech & Language Pathology (AREA)
• Computational Linguistics (AREA)
• General Engineering & Computer Science (AREA)
• Artificial Intelligence (AREA)
• Entrepreneurship & Innovation (AREA)
• Technology Law (AREA)
• Operations Research (AREA)
• Data Mining & Analysis (AREA)
• Primary Health Care (AREA)
• Quality & Reliability (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)

Applications Claiming Priority (3)

Publications (1)

Family

ID=23294112

Family Applications (3)

Family Applications After (2)

Country Status (5)

Cited By (1)

Families Citing this family (12)

Family Cites Families (1)

• 2002
  • 2002-11-18 AU AU2002346840A patent/AU2002346840A1/en not_active Abandoned
  • 2002-11-18 WO PCT/EP2002/012923 patent/WO2003042942A2/fr not_active Application Discontinuation
  • 2002-11-18 WO PCT/EP2002/012920 patent/WO2003042941A2/fr not_active Application Discontinuation
  • 2002-11-18 AT AT02792774T patent/ATE557364T1/de active
  • 2002-11-18 EP EP02791689A patent/EP1609088A2/fr not_active Withdrawn
  • 2002-11-18 WO PCT/EP2002/012924 patent/WO2003042861A2/fr not_active Application Discontinuation
  • 2002-11-18 AU AU2002358515A patent/AU2002358515A1/en not_active Abandoned
  • 2002-11-18 EP EP02783085A patent/EP1440422A2/fr not_active Ceased
  • 2002-11-18 EP EP02792774A patent/EP1440423B1/fr not_active Expired - Lifetime
• 2004
  • 2004-05-17 US US10/846,865 patent/US20050010512A1/en not_active Abandoned

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events