JP4024267B2 - Supplier guidelines system - Google Patents

Description

  The present invention relates to a supplier requirement system, and more particularly to a supplier requirement system that handles character information related to a supplier.

  Conventionally, in order to collect and manage information on customers and prospects for business (hereinafter referred to as business partners) in organizations of various types of business, manuals for business partners, business diaries, and customer lists are created by hand. Was. These supplier requirements are attached to the business promotion to the business partners, credit risk management of the credits to the business partners, takeover within the organization, various types of approval / circulation within the organization and approval. It was used.

  In recent years, with the development of information technology (IT), CRM (Customer Relationship Management) and the like have been introduced, and a mechanism for sharing transaction details with customers in the organization has been introduced. For example, a PC (Personal Computer) is distributed to a person in charge in the organization, the PC and a server in the organization are connected via a network, and the information of the business partner is stored in a DB (Data Base) provided in the server. Store. Then, in response to a request from the Web browser of the PC, the server determines the access right of the user of the Web browser and searches for necessary data from the DB. The server converts the search result into data using HTML (Hyper Text Markup Language) or the like, and transmits the data to a Web browser on the PC. By using such a server and a PC, information about a business partner is shared between persons in charge of distributing the PC.

  RDB (Relational Data Base) is widely used as a DB that cooperates with a Web server. The RDB is a DB that creates a plurality of tables corresponding to real-world entities and defines the relationship between the tables, and uses an SQL (Structured Query Language) statement to insert, update, search, etc. Perform data manipulation. In RDB, when handling a plurality of data for the same item (or attribute, field, column) from the point of data consistency, an upper limit number is set in advance and different item names are used, or a plurality of items may occur. Defines another table and associates it. For example, when managing group companies of business partners, there are a wide variety of business partners with 0 group companies and hundreds of business partners. To develop with RDB, a group company presence flag, a group company table, It is necessary to assign a sequence number of the group company. As described above, in the RDB, it is difficult to handle an entity in which the number of records for one item may be significantly different depending on a business partner, and its development is complicated.

  In the RDB, normalization is performed in order to perform a reliable search and avoid inconsistencies in data. In order to perform normalization, an item to be a key of the table is set as an essential input item, and a sequence number or the like is assigned when a plurality of items exist in the same item. If the number of arbitrary input items is increased and the degree of freedom of input is increased, it becomes difficult to execute an accurate and reliable search. Therefore, it has been difficult to increase the degree of freedom by reducing the required input items and to improve the workability and usability at the time of user input.

  In addition, simple memos and comments on information on business partners and their officers were easy to manage when handwritten, and it was easy to convey the situation. It has been difficult to construct a system that realizes the same ease of use as handwriting, because it is necessary to decide in advance whether or not it will occur or simply use it as a remark.

  Further, in the RDB, in order to increase the use efficiency of a data storage unit such as a hard disk and to increase the efficiency of search, it is necessary to predetermine a data type and a data length for all items. Therefore, there has been a certain limit to flexibly handle character information such as comments in the RDB.

  On the other hand, in order to share the description contents in the handwritten supplier guidelines etc. within the organization, it is necessary to copy and mail them with a copying machine or the like. In addition, in order to grasp the latest state of business partners, it is necessary to recreate business partners and the like at regular intervals. In other words, since the titles of business partners, manufactured products, and the like change, it is necessary to rewrite this part. However, at the time of renewal, in order to fill in a new form, useless work such as copying items that have not changed occurs. In addition, at the time of this renewal, there is a risk that the information content may change or be missed due to a mistake in posting by the person in charge at that time, and therefore this renewal work will be a heavy burden on paperwork including confirmation work. It was.

In addition, in the handwritten supplier guidelines, it is necessary to duplicate almost the same contents in other forms every time a business diary, various discussions, credit risk management, etc. are performed, which increases the administrative burden. When there are a large number of handwritten forms, it is cumbersome to manage which form is to be written and where the form is currently located. In order to know the contents already described, the investigation is performed again .
Its and, in the handwriting of customer terms and conditions, from such degree of skill and personality at the time of sentence expresses the situation of suppliers, there may necessarily not a homogeneous particle size of uniform information. Therefore, it is difficult to use a business partner form in order to extract a business partner with a certain situation or attribute, and when there are a large number of business partners, there is a certain situation from a paper form. Since it takes a lot of labor to extract the suppliers in the field, there is a limit to its use. Therefore, it has been difficult to share the contents described in the supplier guidelines with the organization.

Sato Shinichi, XML on SQL Server2000, Ohm Co., Ltd., March 23, 2001, 1st edition FACOM OS IV CIMS Manual (Main Customer Information System for Financial Institutions), Fujitsu Limited, January 1, 1984, 1st Edition Miyuki Oshige, Intro to File Maker II, BN Corporation, August 2, 1989, first edition By Sean McGrath, Quick Translation Co., Ltd., XML Development Example, ASCII Co., Ltd., June 21, 1999, first edition JP 2001-265916 A JP 2001-229315 A JP 2002-215777 A JP 2001-134695 A Japanese Patent Laid-Open No. 11-96209

  It is conceivable to use information of contents to be described as a supplier's guideline by creating a database and systematizing this supplier guideline. However, since the types and forms of suppliers are diverse, it is difficult to systematically handle abundant information similar to handwriting. Moreover, not only the sales history of products but also information on business partners' organizations, businesses, trends, etc., there are a lot of text information and there are entities and items that are not input depending on business partners. In addition, if the corporate personality (hereinafter referred to as personality) of business partners such as corporations and business individuals is different, the items handled will change, so modeling with RDB complicates entity relationships, and system development and operation And management cost will become large.

  In addition, for systematization of supplier requirements, it is desirable to have a mechanism that enables good extraction (lateral search) of suppliers that fall under the supplier's status, attributes, or characteristics. If it can be described arbitrarily, the accuracy of the horizontal search will be reduced.

  Moreover, it is necessary to deal with the point that the update frequency of information related to suppliers differs depending on each supplier and item. And when referring to information related to business partners on a terminal such as a PC, it is difficult to grasp the freshness of the information at what point in time and the information is still valid. Handling is required. However, when the content of an item is updated, it is difficult to automatically handle which range of data is confirmed as the latest by updating the item.

  Furthermore, when referring to information related to a business partner on a terminal, it is difficult to intuitively inform the user whether the data is in the middle of a business workflow or has been approved.

  Further, the burden of office processing due to duplicate handwriting on a form cannot be improved by simply systematizing individual tasks. In other words, if work such as inputting and registering the same content in each system is generated, it will not reduce the burden of paperwork due to duplicate description.

  Conventionally, when supplier requirements are renewed at regular intervals, the person in charge memorized and reviewed the status of business partners more strongly as a result of the copying work by this renewal. Systematization of supplier guidelines only refers to items other than the changes, and there is a possibility that the level of understanding of the situation of the supplier by the person in charge will be lower than in the case of copying by handwriting and renewal at the time of renewal Can also be assumed.

In this way, in systematization of supplier guidelines that have been performed by handwriting, as its problem , firstly, the relationship with other systems is organized, and secondly, the input of data with the same degree of freedom as handwriting and possible and references to, in the third, it is desirable to achieve both the maintenance of flexible handling and lateral search accuracy data.
In particular, the present invention intends to solve the above three problems while adopting XML technology for data storage.

<Object of invention>
The present invention provides a supplier requirements system capable of effectively utilizing data relating to a business partner stored while maintaining a flexible linkage with character data relating to a business partner and other systems. Objective.
In particular, the present invention enables flexible handling of data by adopting XML technology while utilizing data such as addresses updated in other systems, and data relating to the organization and business of suppliers with the same degree of freedom as handwriting. It is an object of the present invention to provide a supplier requirement system that can input and refer to

In the present invention, as a premise part of the present invention, a server connected to terminals and other systems via a network and a data storage unit for storing data processed by the server as XML data are provided.
The data storage unit includes a DTD that is a tag system definition file that defines an XML system and tags for hierarchizing the data items, a GUI definition file that defines an input display area in the terminal, and Tagged data tagged according to DTD is stored as the XML data, and an XML data DB retrieved from the server and the other system is provided.
Furthermore, the server displays the data in the input display area of the terminal by transmitting the data to the terminal. The server, on the other hand, receives data input, selected or edited by the user of the terminal in the input display area of the terminal, tags the data as defined by the DTD, and validates it by the XML parser. And the XML data subjected to the verification process is stored in the data storage unit.
Further, the server is a system that permits a search from the other system.

As a feature of the present invention, the present invention further includes an RDB in which the data storage unit manages basic attribute data of a corporation or an individual updated in the other system. The tag system definition file includes, as elements of the DTD based on the tag system definition for the XML data, a supplier requirement item I relating to a supplier organization and business, basic attributes, and an element group relating to the organization and business.
The basic attribute includes a CIF number that appears 0 times or 1 time that uniquely identifies a corporation or an individual, a name or name that appears 0 times or 1 time, and an address that appears 0 times or once.
Among the element groups related to this organization and business, each element group related to a corporation or an individual has basic attributes that appear once, and input display elements that become input and display items.
Among the element groups related to the organization and business, the element group other than the element group related to the corporation or the individual includes the input display element.
Further, the GUI definition file, the tissue and the components each related to the business, before SL has a table in the input display area of the terminal, as defined enterable in item of the respective table, between items in the respective tables The predetermined input impossibility is determined according to the derivation relationship between the derivation source item and the derivation destination item.
The server includes a display editing control unit and a storage control unit.
When the terminal user inputs data relating to a corporation or an individual related to the customer in the table, when the CIF number is input to the CIF number item that is the derivation source item, the display editing control unit In accordance with the definition of the GUI definition file, the name or name item and the address item, which are derivation destination items, cannot be input.
On the other hand, when the CIF number is not input but is input to the name or name item, it is not prohibited to input the address item.
And when the derivation is received from the terminal, the name or name and the address are derived with reference to the basic attribute data of the RDB and the CIF number as the derivation source, and the derivation destination item in the table The name or name and address are displayed.
Further, when the storage control unit stores the data of the supplier requirement I, a tag corresponding to each item is attached to each data, and data regarding the organization and business of the supplier for each CIF number is stored. The XML parser verifies whether the level and number of appearances defined in the tag system definition are satisfied, and stores the processed XML data when the data has validity in relation to the tag system definition It has a configuration of “Yes”. Thus, the above-described problem is to be solved.

In the first embodiment , main information processing contents such as a server are disclosed.
In the second embodiment, which is the main embodiment of the present invention , the essential data is XML data, and various functions relating to display editing are provided, thereby enabling data input and reference with the same degree of freedom as in handwriting. . In addition, Captures the basic character data about the customer from other systems to RDB, by a hierarchical data structure by X ML while encouraging a concise and clear understanding of the positioning of each item to the user, the input of character data Support is provided to achieve both the flexible handling of character data and the maintenance of the accuracy of the lateral search by the processing of the input impossible or the derivation depending on the presence or absence of the CIF number . Furthermore, the accuracy of the horizontal search is improved while facilitating the input by organizing codes indicating the relationship with the corporation or the individual having a relationship with the position or the business partner.

The present invention is, by its construction, the display editing control unit, a corporation or individual basic attribute data to be updated in a variety of other systems managed by RDB, in the et, the data for the organization and operations of the suppliers Control input and display . In the present invention, when the storage control unit stores the data of the supplier requirement I, each data is attached with a tag corresponding to each item, and data relating to the organization and business of the supplier for each CIF number Is verified by the XML parser to determine whether the data is valid in relation to the tag system definition. Store. That is, including the basic attribute data by the RDB data for organization and operations, that stores in the data storage unit such as a valid XML data tagged for XML. This ensures that the data suppliers Guideline I as XML data, while encouraging a concise and clear understanding of the meaning and positioning of each item to the user by the hierarchical data structure by XML, by supporting the input character data Thus, it is possible to achieve both the flexible handling of character data and the maintenance of the accuracy of horizontal search.
In the present invention according to claim 1, in particular, as an element of DTD , it has a supplier requirement I relating to a supplier's organization and business, a basic attribute, and an element group relating to the organization and business, and the basic attribute is It has a 0 or 1 appearing CIF number that uniquely identifies a legal entity or individual, a 0 or 1 appearing name or name, and a 0 or 1 appearing address. For this reason, the CIF number can be an arbitrary input item as XML data.
Among element groups related to the organization and business, element groups related to corporations or individuals (for example, elements having basic attributes as elements among the elements shown in FIG. 10) are input once and displayed as basic attributes. An input display element as an item, and an element group other than an element group related to a corporation or an individual among element groups related to the organization and business (for example, elements that do not have basic attributes as elements among the elements shown in FIG. 10) Has the input display element. For this reason, in each element, the CIF number can be set as an arbitrary input item while the basic attribute appears once.
And when the user of the terminal inputs data relating to a corporation or an individual related to the business partner in the table, the display editing control unit receives a CIF number in the CIF number item that is the derivation source item. In accordance with the definition of the GUI definition file, the name or name item and the address item, which are the derivation destination items, are disabled. For example, in paragraph 0077, the derivation destination item is grayed out. On the other hand, when the CIF number is not input but is input to the name or name item, it is not prohibited to input the address item.
And when the derivation is received from the terminal, the name or name and the address are derived with reference to the basic attribute data of the RDB and the CIF number as the derivation source, and the derivation destination item in the table The name or name and address are displayed. For this reason, if the CIF number is input, the basic attribute data of the RDB is fetched. On the other hand, if the name or name is input without inputting the CIF number, the CIF number can be an optional input item. This enables input with the same degree of freedom as handwriting.
In this way, with regard to the data related to the organization and business that are the supplier requirements I, for example, the elements shown in FIG. 10, such as officers, accounting officers, people from the Bank, major shareholders and major investors, etc. When the CIF number is entered for the officer, accountant, major shareholder, etc., the basic attribute data of the RDB updated by other systems is used. If the CIF number is not entered, the name or name entered is entered. Can be used. That is, while adopting the flexibility of XML using the CIF number as an arbitrary input item, it is possible to use the RDB data when it exists. As a result, it is possible to prompt the user to enter a flexible input similar to handwriting and to input an individual or corporation having a CIF number.
The invention according to claim 2 prompts the selection of the dependency relationship, displays the dependency relationship in the item, and uses the value of the dependency relationship code specified by the dependency relationship in the table as a key. Sorting is performed according to the code value, and the table is displayed on the terminal in the order sorted according to the dependency code value.
As a result, with regard to the relationship between the business partner and the individual or legal entity related to the organization and business, for example, for the title, etc., it is prompted to select a coded option instead of character data, and sort by this code . Therefore, by devising the order of the code numbers of the dependency relationship codes, it is possible to display more important elements from the top of the table and store them in that order while adopting XML without an order concept (paragraph 0095). ).

<First Embodiment>
FIG. 1 is a block diagram illustrating a configuration example according to the first embodiment. As shown in FIG. 1, a supplier summary system 4 according to the present embodiment includes a server connected to a terminal 1 and another system 40 via a network 2, and a data storage unit 3 that stores data processed by the server. And. The server includes an acquisition control unit 6 that acquires character data about the organization and business of the business partner and the main trends in the time series of the business partner from the other system 40, and a predetermined user interface definition. The character data acquired based on (GUI definition etc.) is displayed on the terminal 1, the organization data indicating the contents of the organization of the business partner, the business data indicating the business content, and the trend indicating the main trend of the business partner. And a display editing control unit 8 for controlling input and editing of comment data and the like.

  The server further stores character data automatically acquired from another system by the acquisition control unit 6 and character data input and edited in accordance with control by the display editing control unit 8 as essential data in an integrated system. A storage control unit 10 for storing in the unit 3 and the like is provided.

  The terminal 1 is a PC that can be used by headquarters and branch office users. Moreover, you may make it use portable terminals, such as a mobile telephone or PDA. The terminal 1 displays data transmitted from the server in accordance with data and programs transmitted from the server, and controls input of data to be transmitted to the server. Introduce an execution environment to the terminal, send a program to be executed on the terminal from the server to the terminal, and execute it on the terminal. Select and send input character data to the server. Moreover, the above mechanism may be realized by introducing a web browser to the terminal and transmitting / receiving HTML data or the like according to HTTP, or by introducing an application to all terminals and communicating with the server. It may be a mechanism.

  The network 2 is a communication line such as a LAN or WAN, and connects a PC and a server using a protocol such as TCP / IP. The data storage unit 3 is a nonvolatile memory such as a hard disk. When the data storage unit 3 viewed from the server is abstracted and handled as a resource or DB, DBMS or other data management software may be introduced into the data storage unit 3. In this case, the server can use the data storage unit 3 using a general data operation command such as SQL or a database access API. In the example shown in FIG. 1, the number of data storage units 3 is one, but they may be distributed or may be arranged at other locations via a network.

  In the case where the customer requirement system according to the present embodiment is used in a financial institution, as shown in FIG. 2, other systems include an online system 42 such as an account system and an information system, a financial analysis system 43, and a customer (debtor). Credit rating system 44A for qualitative and quantitative assessment of credit risk, etc., self-assessment system 44B for assessing assets of financial institutions such as loan balances (credits), and financing under any conditions A loan deliberation system (project management system) 45 for managing a workflow such as whether or not to perform, a business diary system 47 for managing business contents and reports of a person in charge at a sales department or a head office sales department, and the like.

  The acquisition control unit 6 acquires character data about the organization and business of the business partner and major trends in the time series of the business partner among the data input, examined and approved by the other system 40. . As shown in FIG. 1, the acquisition control unit 6 automatically acquires the conclusion approved in the workflow by the other system 40 or the character data as the main point of the result as the trend comment according to the attribute of the other system. A gist data acquisition function 7 may be provided. For example, the acquisition control unit 6 searches the DB of another system with an SQL sentence or the like, and inserts / updates the search result in the data storage unit 3. In online system 42 that performs account processing such as deposit and withdrawal to / from an account at a financial institution, a new operation may be defined on the online system 42 side in order to acquire data from a system other than RDB. A base DB that updates and manages the data stored in the online system 42 on a monthly basis may be constructed and used.

  The display editing control unit 8 displays the character data acquired based on a predetermined user interface definition (GUI definition or the like) on the terminal 1, and displays organization data indicating the content of the organization of the business partner and the business content. Controls the input and editing of business data to be displayed and trend comment data indicating the main trends of the business partner. When the data registered in accordance with the input and edit control is stored in the data storage unit 3, the display / edit control unit 8 also displays this data on the terminal. Examples of terminal display are shown in FIGS. As shown in FIG. 1, the display editing control unit 8 is provided with a function-specific function restriction control function for controlling the display / editing / deletion of each character data according to the authority of the user who uses the terminal 1. Also good.

  The storage control unit 10 integrates character data automatically acquired from another system by the acquisition control unit 6 and character data input and edited in the past or in accordance with control by the display editing control unit 8 in an integrated system. Is stored in the data storage unit 3 or the like as essential data. The “integrated system” is preferably a hierarchical structuring of the entire essential data. In addition, a systematic construction of entity relationships may be used. An example of using XML to perform hierarchical structuring will be described later as a second embodiment. The storage control unit 10 stores the essential data in the data storage unit 3 in an integrated system using a language or API for operating the database. In the example illustrated in FIG. 1, the storage control unit 10 includes a transmission control function that transmits a part or all of the essential data for each business partner to the other system 40 in response to a request from the other system 40. Data items handled by the supplier system are organized in an integrated system, data is collected from other systems 40, input and edited at the terminal 1, stored in an integrated manner, part or all of the data in the hierarchy Send to other systems with information such as structure added. For this reason, in this invention, the handling at the time of taking in essential data into RDB with another system, or displaying on a screen becomes easy. In this way, important information according to the use and attributes in other systems can be aggregated in the supplier requirements system, and the aggregated data can be transmitted to each other system.

  The supplier requirements system 4 according to the present embodiment aggregates important information according to the use and attributes in other systems and transmits the aggregated data to each other system. It can be positioned as the uppermost DB of character data to be processed. Position the supplier requirements system at the top level of the character DB, collect character data from other systems, and supply all or part of the system data to the other systems as systematic requirements data, eliminating duplicate descriptions and Usability can be increased. Since standard character data handling (interface) can be provided to other systems, the development load related to character data handling can be reduced and the development load can be kept stable while developing other systems. The necessary character data can be received from the supplier requirement system managed in the same manner. In addition, even if the data items are obtained from multiple other systems, the data is positioned in the structure / system as essential data. It is easy to maintain consistency.

  FIG. 2 is an explanatory diagram showing an example of cooperation between another system and a supplier requirements system when the supplier requirements system is used in a financial institution. The online system 42 manages the customer's basic attribute data such as a CIF number for identifying a business partner, a name or name, and an address on a daily basis from the necessity of managing an account. Further, these basic attribute data are stored in an RDB such as a base DB as monthly customer information. The supplier requirement system acquires basic attribute data from this base DB on a monthly basis. In addition, history data or the like of essential points may be transmitted for searching to the base DB. In addition, when working with the name identification process between companies related to financing (related name identification for related lenders) using the supplier system, the name identification results (group number and CIF number combination, etc.) should be sent to the online system. May be.

  The credit rating system 44A is a system that determines the credit rating of the business partner based on the evaluation of the financial status of the business partner and receives the approval of the headquarters. When dealing with ratings in the supplier requirements system, it is preferable to obtain rating data from this credit rating system. For example, since trend comments indicating supplier trends are managed in chronological order, rating changes after these trends may be displayed together with main trends in the supplier requirements system. In the credit rating work, data on the business position of the business partner, the type of business, the products handled, etc. are required. For this reason, the supplier requirements system 4 may transmit to the credit rating system the overview of the supplier, the result of company name identification, the presence / absence of the parent company or subsidiary, product information, etc. In addition, when a comment on the business position of a business partner or a comment regarding a manufactured product is input in the credit rating system 44A and finalized, it is preferable to automatically incorporate this comment information into the business partner system. .

  The financial analysis system 43 is a system that analyzes the financial state of a business partner who can obtain a financial statement from the necessity of financing, credit risk management, and the like. The average monthly sales, profit margin, etc. may be managed by an online system or may be managed by a financial analysis system. For this reason, you may make it acquire from the financial analysis system the average monthly sales of each supplier used by a supplier's essential point, the number of employees at the time of the account settlement of the supplier, etc. In addition, when a major shareholder or the like is changed at the time of financial registration, the necessary circulation may be performed in the workflow of the financial analysis system, and it may be automatically registered in the business partner system after approval.

  The self-assessment system evaluates assets such as loans from the viewpoint of credit risk management. Self-assessment is conducted twice a year in accordance with the bank closing date, and is classified into obligor categories such as normal, sensitive, and bankrupt depending on the obligor's situation, and the receivables are classified from class I. Classify by IV classification. Based on this classification, etc., allowance for doubtful accounts is calculated and the bank's asset status is reflected in the account settlement. In the work of classifying the debtors, the business type of the business partner, the position in the industry, the monthly sales for each product manufactured, etc. are also considered. For this reason, the industry code and average monthly quotient acquired from the online system 42 and the financial analysis system 43 are transmitted to the self-assessment system. In addition, in the self-assessment, an overview of the business partner is often attached. In this case, the essential data on the date of self-assessment is transmitted to the self-assessment system.

  With regard to this self-assessment, the applicant has developed an asset assessment system 44 for assessing assets at any time throughout the year, such as when the business condition of a business partner (debtor) changes or when a financial registration is made. And filed a patent application. The asset assessment system 44 issues a self-assessment work when there is a change in the business conditions of a business partner. This business condition change of the business partner is one of the main trends of business partners in the business partner requirement system 4. When there is a change in business conditions, through self-assessment work using the asset assessment system 44, the contents of the business condition changes of the business partners are accurately grasped, and examination is repeated through the workflow from the sales office to the audit department. Approved and credit rating and debtor classification are maintained or changed. The supplier requirement system 4 automatically acquires the approved self-assessment reason as a trend comment. In addition, the asset appraisal system 44 may automatically acquire the general condition of the debtor from the corresponding item of the supplier requirements.

  The loan appraisal system 45 makes a loan proposal to a business partner, or when a loan application is received from a business partner, sorts out the business condition of the business partner, and provides a workflow for approval / approval of loan conditions and availability. It is a system to manage. It is necessary to attach the supplier's guideline for the loan request. For this reason, the supplier requirement system transmits the requirement data at the time of making the loan request to the loan request system. If a loan policy is approved at the time of self-assessment, the loan policy or comment is made a part of the supplier guidelines, and the loan policy is sent from the supplier guide system to the loan approval system. May be. On the other hand, in the workflow controlled by the loan appraisal system 45, when the application for loan is refused and the request is abandoned, depending on the importance of the abduction, the transaction background or business promotion with the relevant business partner You may make it register into a supplier essential point system as a trend.

  The business diary system is a system for managing a sales promotion workflow such as a person in charge at a sales office reporting a business situation. The business diary system may manage sales, responses to DM shipments, etc. in cooperation with project management and loan appraisal systems. In this case, the progress of the business promotion is managed by the business diary system, etc., and the trend comment is made on the matters that have been concluded or not made as a result of the sales promotion, depending on the importance of the business promotion. May be automatically registered in the supplier's guidelines.

  In this way, the supplier requirements system 4 is positioned as the highest-level DB for handling character data, and as a system for registering character data that briefly indicates the main points when the workflow is completed and conclusions and results are obtained. Can be used. With regard to the handling of character data, when using the supplier requirement system 4 having such character, it is possible to easily handle the aggregation and distribution of character data indicating conclusions with respect to the character data handled by many systems while maintaining consistency. it can. In particular, since the supplier requirements system handles the items in an integrated system, it is easy to share character data with other systems, allowing users to handle consistent character data consistently across all systems. This can be realized without increasing the burden of

  When important character data is collected in the supplier's guideline system, it is possible to prevent the information from being lost and to refer to it at any time by operating a terminal such as a PC in order to confirm the contents. That is, by using the supplier requirement system, detailed work results in each system can be referred to as a list, and consistency with data of other systems can be maintained while preventing duplicate registration.

  As a business, it is possible to maintain the homogeneity and accuracy of comment information by establishing a consistent and stable business process of registering conclusions based on the workflows of other systems, and the systematic structure of essential data. As a part of the system and the mechanism that clearly shows the basis of the character data, it becomes easy to access the basis of the character data, and the supplier guideline system 4 is used as a window related to the supplier information. be able to. When such systematic and organized information accumulation is performed, it is possible to shorten the time taken over at a sales office or the like, and to effectively prevent the occurrence of takeover. In addition, since the workflow for obtaining a conclusion or the like is performed by another system, circulation or the like in the supplier guideline system becomes unnecessary.

  Referring to FIG. 1 again, the supplier guideline system 4 according to the present embodiment manages the main trend categories in which the server explicitly classifies the main trends in time series for the suppliers, and the main trends. A main trend category management unit 16 that controls sharing of categories with other systems is provided. “Explicit classification” means, for example, that the main trend classification is an indispensable input item in the customer trend record. Furthermore, as the main trend category, a category such as “others” where the type or attribute cannot be specified may not be provided.

  FIG. 3 shows examples of main trend category codes and major trend category names when used in financial institutions. In the example shown in FIG. 3, when trend comments are input according to the control of the display editing control unit 8 of the supplier requirement system 4, the categories to which the trend comments belong are arranged in advance. There are various modes for starting a loan transaction, but a trend comment on the start of a loan transaction always belongs to the main trend category of “start of the Bank's loan transaction” of 00190.

  The main trend category management unit 16 includes a type management function 18 for managing the type of the main trend category. As shown in FIG. 3, the major trend categories are as follows. Financial accounting basic types related to the basic matters, affiliated companies / facility types related to affiliated companies and business facilities, and risk management types related to credit risk related to receivables, etc. to the business partners. Further, as a type of main trend category, a main trend category belonging to a business promotion type related to business promotion to a business partner may be defined.

  FIG. 4 shows a GUI and an example of contents of a supplier system for handling trend comments. Hereinafter, examples of screens and business partners will be disclosed for explanation, but the contents are virtual examples and are not related to actual corporations or individuals.

  In the example shown in FIG. 4, transaction details handled by the supplier requirement system are displayed in the supplier trend table 100. The supplier trend table 100 has a plurality of supplier trend records (one line in the table) as a list display. The supplier trend record includes the date of occurrence, main trend category, and details (trend comment). ), Entry date, and entry person. In the example shown in FIG. 4, the display editing control unit 8 includes a main trend category mandatory input control function 20 that controls the main trend category as an essential input item for the trend comment input. Accordingly, all trend comments handled by the supplier requirement system 4 are assigned major trend categories. For this reason, trends that are not in the main trend categories are not described. By explicitly classifying trend comments according to major trend categories, the trend of business partners that do not fall under the major trend categories is not registered as unnecessary in the relevant supplier guidelines system. As a result, the granularity related to the importance of trend comments can be systematically enforced regardless of the user's skill, and uniform data accumulation can be achieved.

  In the example shown in FIG. 4, the date of occurrence of the loan transaction is October 1, 1960, and the trend of the business partner before the start of the transaction is registered on the same day. In the entry field, the store number and full name are displayed, but are omitted in the figure. Since then, only important matters defined in major trends such as receiver / account receivable accidents and establishment of business facilities have been registered. “Recipient” is a bill of exchange. In October 1970, there was a transfer, which is a change of the dealer. At this time, the entrants changed from the person in charge at the Nagano branch to the person in charge at the head office sales department. After that, the company was listed and established a subsidiary. The trend comment regarding the poor performance can be automatically acquired from the asset assessment system 44B when, for example, the asset assessment system 44B reexamines the debtor classification according to the poor performance.

  Further, as shown in FIG. 1, the main trend category management unit 16 may include a sub category management function 22 that manages each main trend category and more detailed main trend sub-categories belonging to the category. In this case, by using the main trend subcategory, the trend comment can be described more simply and shortly, and the relevance rate in the horizontal search can be further increased. Examples of sub-categories include the type and extent of deterioration in the surrounding situation, the level of poor performance, and applicable laws in filing legal proceedings.

  In a preferred example, the main trend category management unit 16 includes a type display control function 24 that controls the display of trend comments for each type of main trend category on the terminal 1. The type display function maintains and improves the skills of the person in charge and promotes accurate grasp of the status of business partners in a short time. For example, the type display control function 24 extracts and displays only the trend comments belonging to the risk management type and only the trend comments belonging to the type of organization / business transition. In the example shown in FIG. 4, two types of display, that is, all display and display of only the risk management type are provided.

  FIG. 5 is an explanatory diagram illustrating an example of a trend comment type display. Among the customer trend records shown in FIG. 4, there are two records to which the main trend category belonging to the risk management type is attached, that is, a receiver / account receivable accident and poor performance. The user compares the display of only this risk management type (management item) with the display of all indications, and grasps the trends of business partners in a short time and accurately by performing a detailed examination of the risk management items. be able to.

  In order to display only the management items, in the example shown in FIG. 3, a supplier trend record having a main trend category code of 10,000 or more and less than 20,000 is extracted. FIG. 6 is a flowchart illustrating an example of trend comment type display control. First, the trend comment group of the business partner stored in the data storage unit 3 is identified by identifying the CIF number that identifies the business partner to be displayed (step S1, supplier identification step). Subsequently, the type of the main trend category displayed on the terminal 1 is acquired (step S2), and the extraction range of the main trend category is set according to the type or the like (step S3, extraction range setting step). For example, if the management item display button shown in FIG. 4 is pressed, the type of main trend category to be displayed is the risk management type shown in FIG. 3, and the main trend category code to be extracted is 10,000 or more and less than 20,000. To do. Subsequently, the supplier trend is read for one record (one line) (step S4), and it is determined whether the main trend classification code of the supplier trend record is 10,000 or more and less than 20,000 (step S5). ). If it is within the range, it is added to the display target of the type. For example, it is stored in an array for screen display. Then, it is confirmed whether or not reading of all the records in the supplier trend table has been completed (step S7). If there is an unread record, the next record is set as a reading target (step S8).

  Steps S4 to S8 are repeated to extract all supplier records in the main trend category belonging to the extraction range set in the extraction range setting steps S2 and S3 (intra-range trend comment extraction step). Subsequently, the supplier trend record that is the type display target is displayed on the terminal 1 (step S9, extraction display control step).

  The configuration shown in FIG. 1 and the processing shown in FIG. 6 and the like can be realized by the CPU of the server executing a predetermined program. The server of the supplier summary system and the CPU (not shown) of the terminal perform various calculations according to a predetermined program (command). The CPU displays character data or the like on the screen of the terminal 1 according to various processing requests, and promotes input of trend comment data or the like.

Particularly in the present embodiment, the supplier trend display program includes the following commands.
A supplier identification command for specifying the supplier trend record group stored in the data storage unit 3 by specifying the CIF number for identifying the supplier to be displayed.
An extraction range setting command for acquiring the type or attribute of the main trend category displayed on the terminal 1 and setting the extraction range of the main trend category according to the type or the like.
An in-range trend comment extraction command for extracting a supplier trend record of a main trend category belonging to the extraction range set according to this extraction range setting command.
An extraction display control command for causing the terminal to display a supplier trend record group extracted according to the in-range supplier trend record extraction command.

  This supplier trend display program is stored in a recording medium 11 </ b> A such as a magnetic tape (MT) or disk, conveyed, and read by the disk drive 11. The supplier trend display program stored in the recording medium is read by the disk drive 11 and then stored in a program storage unit (not shown). Further, the program can be provided from another host device to the program storage unit via a communication line.

  When referring to a program as a “command to operate a CPU”, a command to operate the CPU only with each command and a command to operate the CPU depending on other programs such as an operating system stored in advance in the program storage unit Or both. Here, “operating system” is interpreted broadly. Includes transaction manager, database manager, execution environment, etc.

  In the example of accumulating trend comments relating to business promotion, a main trend category corresponding to the transaction history type of the main trend category may be added. In a preferred example, when trend comments relating to sales promotion are stored in relation to other types of trend comments, it is possible to generate supplier trends that are easy to register and reference and are easy to understand. In this example, the main trend classification management unit 16 registers the business promotion content related to the business partner trend indicated in the trend comment as the trend comment of the sales promotion type in association with the corresponding trend comment. A registration function 26 is provided. The trend-by-trend promotion result registration function 26 registers the contents of business promotion such as the execution of loans in relation to the trends of business partners classified into business development / variation and business facility installation.

  In a preferred example, the main trend classification management unit 16 may include a promotion result code management function 28 that manages trend comments of the sales promotion type with a promotion result code indicating the conclusion and non-success of the sales promotion result. Closing is when a loan agreement is established, and non-promise is a loan proposal, but the loan is not accepted by the customer, and the loan application review results and the conditions do not match. There is a case where it is determined that the execution of the system cannot be performed. The major trend category “Abandonment” is a category when it is determined that such loans cannot be executed. At that time, there is a strong meaning of a higher credit risk, such as the discovery of excessive powder on the financial statements. In such cases, the transaction is registered as a transaction history.

  FIG. 7 is an explanatory diagram illustrating an example in which a trend comment of a sales promotion type is associated with a main trend category of another type. In the example shown in FIG. 7, the trend of business partners, the contents and results of business promotion are described in the detailed comments. Then, between the detailed comment and the date of entry, the contract or non-contract of the result of business promotion is displayed. For example, at the start of the Bank's loan transaction on October 1, 1960, it was closed. At this time, a comment is written: “A bank fund transaction will be a parallel transaction from the start of one bank transaction. A hand loan of 10 million yen and a new contract for the time being opened”. On October 1, 1965, a new person in charge at the dealership promoted the business, and the construction of the factory and capital investment of 100 million yen were concluded (period 15 years). In April 1973, paying attention to the establishment of a subsidiary, “Promotion of working capital was promoted, but funds were raised from A Shinkin”, which was a breach of contract. In the example shown in FIG. 7, only these items can be displayed by depressing the promotion item display button.

  In the example shown in FIG. 3 and the like, the main trend categories for classifying trend comments have a hierarchical structure of a plurality of types and categories belonging to various types. In addition, when sub-partitions are used, there are three layers. This hierarchical handling can systematize the importance of customer trends. On the other hand, in the hierarchical structure, there is a case where one item wants to temporarily belong to another item. Further, if links regarding the grounds and relations of each item can be attached, the relationship with work result files and the like in other systems can be handled systematically. In such an example, as shown in FIG. 1, the main trend category belongs to the main trend category in which the main trend category management unit 16 classifies trend comment data about main trends in time series for business partners. A category tree structure management function 30 that manages a tree structure of a type, a main trend category, and a sub-category that is classified in detail within the main trend category, and the trend comment separately from the tree structure for each trend comment data It is preferable to provide a comment attribute management function 32 for managing a comment attribute for grouping data or a comment attribute related to the basis of the trend comment data.

  The category tree structure management function 30 manages major trend categories in three layers. The comment attribute management function 32 manages attribute information of each comment. If the file name of another system is stored as comment attribute information, the automatic registration of trend comments and the file name of the material on which the comment is based can be automatically registered in the supplier requirements system. Also, for example, when “business development / change” is the target (cause) of risk management, this trend comment can be included in the management item display by setting this attribute as the risk management type. In this example, in step S3 of FIG. 6, an extraction range is set for the code value of the main trend category code and the attribute information of the trend comment. For example, in the type display by depressing the promotion item display button shown in FIG. 7, the trend comment in which the promotion result code is registered as attribute information and the main trend category code belonging to the transaction history type shown in FIG. 3 are registered. Trend comments may be extracted and displayed. Further, the type display may be controlled only by the attribute information such as the display flag without using the code value of the main trend category. Further, the type display and the transmission of the type to another system can be realized with substantially the same function. Therefore, type transmission to other systems can be realized by using only the main trend classification, only attribute information, or using both.

Second Embodiment
In the second embodiment, an example will be described in which a supplier requirement system is constructed using a structured markup language (ML) such as XML (eXtensible Markup Language). XML is a document description format derived from SGML (Standard Generalized Markup Language), which simplifies SGML and is adapted for use on the Internet. In XML, by defining a document type definition (DTD), a tag system (tag set) corresponding to the use of data is used. By using the tag system, document types of elements and attributes can be defined. XML data is a text file that indicates the structure of a document with tags defined by DTD. Since XML is based on SGML, it is suitable for processing non-standard documents such as books and Web pages. For example, the length of data included in one item cannot be determined in advance, and it is difficult to manage a document in which the number of items changes with the RDB, but XML data is tagged text data. Therefore, character information can be handled flexibly.

  The tag system indicating the structure of the XML document is a hierarchical type. The hierarchical type has a tree structure in which, for example, an element of an organism includes animals, plants, and microorganisms, and an element of an animal includes species such as mammals and reptiles. The tree structure is useful for humans to understand the semantic content of the elements. On the other hand, the tree structure is easy for a computer in that data can be manipulated by accessing a parent-child relationship in which elements are nodes. XML data, which is a set of character data clearly defined in a hierarchical structure, is used not only for page markup but also for describing meta contents for managing various properties, exchanging data with RDB, and messaging can do. That is, the tag indicating the structure of the document is used for specifying the expression format on the page, specifying the attribute in the character data system as an element, and indicating the correspondence with the items in the RDB table.

  In the DTD that defines the tag system, the data type of elements is only character data. An XML document that correctly follows the specified DTD is said to be valid. A valid XML document conforms to the element name, hierarchy, order, and number of appearances such as whether the element is essential or optional as defined in the DTD.

  A software module that handles XML data is called an XML parser (XML processor). The XML parser parses the XML data and verifies the validity. The XML data whose validity has been verified follows a predetermined tag system. Examples of API (Application Programming Interface) for accessing the internal structure of XML data include DOM (Document Object Model) and SAX (Simple API for XML). DOM expresses XML data as a tree (DOM tree) composed of nodes of elements and character data. A valid XML data DOM tree follows the hierarchical definition by DTD. The DOM API is suitable for processing that sorts the elements of an XML document in a certain order, moves them to another place, or inserts new elements.

  XML is often used by Web applications that realize certain functions while transmitting and receiving data and programs between a server and a terminal. For this reason, XML parsers or the like having a function for verifying validity are object-oriented. Many have been developed for the Java language (registered trademark). In the Java development / execution environment, class hierarchies are already defined, and by using interfaces (also called protocols in other languages) without multiple inheritance, programs called modules and components Increases reusability and independence of parts. In the Java development environment, existing modules can be used for XML validation and the like. In the development of Web applications, particularly J2EE (Java 2 Platform, Enterprise Edition), the database, server, and terminal are conceptually and role-divided into three to five layers. For example, in J2EE, a Web layer that provides a presentation function for generating a GUI and an EJB layer that executes application logic can be separated. EJB (Enterprise Java Beans) is a component for business logic in J2EE. The EJB container, which is the execution environment of EJB, manages details such as transaction processing, security, and load balancing. You can concentrate on coding. For example, when EJB is used, distributed transactions are automatically supported, and even when a plurality of databases are used, transactions can be updated atomically. This means, for example, that it is possible to easily store the registration of data in the database of the supplier requirements system and the registration of data in the database of another system within one transaction.

  In J2EE, a terminal often uses a Web browser or a Java application equipped with a GUI. When using a Java application, using a Swing or a screen design tool using the GUI as a GUI makes it easy to define the GUI. The EJB maintains a session with the Java application of the terminal 1, and can receive an event such as a button press directly or via the presentation layer. The EJB instructs to change the display mode according to the event, calculates the composition ratio between elements, searches from the RDB using the input of the derivation source as a search key, operates the DOM tree, and performs a search result. Can be added as a derivation element, or the elements can be sorted. When sorting elements is considered a presentation problem, implement this sort in the presentation layer.

  Various methods have been proposed for storing XML data in a database. Mapping XML tags to RDB tables and storing them in RDB, storing XML data as huge text data, generating search indexes as side tables, and class hierarchy in object-oriented databases For example, a method of mapping XML data.

  In XML data operations, instead of using a DOM tree, the schema definition of complex records is performed, and XML data tags, Java objects, and database records can be converted to each other at any time. An execution environment is also provided. In addition, XML Schema is defined as a technique for making document type definition easier to use in XML-related technology. When XML Schema is used, the data type and the like can be verified by validating the XML data.

  In this embodiment, DTD, DOM tree, XML data is stored as text, and a database that can be searched by SQL using a side table, EJB by J2EE, GUI by Swing, applet executed by Web browser, Use techniques such as type checking using EJB, servlets, and applets, display editing control, and data fetching from other systems using RDB. Instead of DTD, DOM tree, SQL search, applet, and Web browser, XML Schema, complex record, XQuery, or a combination of Web browser and XSLT may be used. When the terminal is a portable terminal such as a PDA or a mobile phone, for example, in order to provide only a display, XML data may be converted into HTML by XSLT and transmitted.

  FIG. 8 is a block diagram illustrating a configuration example of the second embodiment. A supplier system according to the present embodiment includes a tag system definition file 50 that defines a tag system of a markup language (ML) that cooperates with an RDB, and a GUI definition file 52 that is predetermined for display and input on a terminal. , ML data DB (XML data DB in the example shown in FIG. 8) 54 for storing tagged data for each business partner tagged with the ML, and data updated at regular intervals in another system 40 A data storage unit 3 for storing the stored RDB 56 is provided.

  The tag system definition file 50 is, for example, a DTD file. GUI definition includes screen layout definition by Swing etc., data type defined in relation to table items (fields) used on each screen, definition of derivation relationship between items, display property data and display This is the relationship of buttons to be performed. For example, when the XML data DB 54 stores XML as a huge text file and uses the extension of the RDB to create a side table for search, a relatively flexible handling of increase / decrease in the number of items becomes possible. The RDB may be an RDB having a function of taking in data of an online system that uses a hierarchical data structure such as IMS.

  In the example shown in FIG. 8, the server captures from the other system 40 the display editing control unit 8 that controls the display and input of data about the organization and business of the business partner and main trends on the terminal according to the GUI definition. Data and data input from the terminal 1 are converted into tagged data based on the data item name in the RDB 56 or the tag system definition related to the GUI definition, and the tagged data is converted into integral data. And a storage control unit 10 for storing in the ML data DB.

  The display editing control unit 8 is a presentation group software group and an EJB that executes business logic. The storage control unit 10 uses an EJB component for storing XML data in the XML data DB 54, a parser module that performs verification by DTD before storage, and an API of the JDBC data DB 54 when using, for example, JDBC. DB54 driver or the like to be mapped to

  The display editing control unit 8 includes an input disabling control function 60 that controls items that cannot be input for each aspect of the supplier in accordance with the GUI definition and the aspect of the supplier. This function 60 performs control such that, for example, a corporation is not permitted to input a shop name field, while an individual business owner is permitted to input. As a result, all tags used with various personalities can be defined by one DTD, and the layout of the screen can be the same for the corporation and the individual business owner.

  In addition, the display editing control unit 8 obtains data updated in the other system 40 based on the tag system definition and derives the content of the derivation destination item from the input to the derivation source item based on the GUI definition. A derivation control function 62 is provided. Of the data updated by the other system 40, basic attribute data and basic loan attribute data acquired monthly from the online system 42 via the infrastructure DB are managed by the RDB with the CIF number as a key. For this reason, in various tables of the supplier requirements, in the record having the CIF number, the name or name, address, loan destination number, main transaction store, industry code, etc. can be derived from the CIF number.

  The derivation control unit 62 performs control for deriving a name or name that is a derivation destination item from a CIF number that is a derivation source item. In the derivation control, for example, in the presentation layer, when the derivation source item becomes active and the input is started, the derivation destination item is grayed out to make the input impossible. In the EJB layer, necessary item data is extracted from the RDB 56 using the CIF number as a search key, and inserted into the corresponding derivation destination item of the data edited for the DOM tree or screen display.

  The derivation control unit 62 further calculates the composition ratio. For example, when the number of issued shares of a business partner is known and the major shareholders and the number of shares held are registered in the supplier's guidelines, the shareholding ratio of each shareholder is calculated from the number of shares issued and the number of shares held by each shareholder. . The field for inputting the number of shares is the derivation source, and the field for displaying the shareholding ratio is the derivation destination. In actuality, when the derivation button is pressed or the registration button is pressed, data is received from the terminal 1 and the RDB 56 is searched and the ratio is calculated by the EJB on the server side.

  In a preferred example, the display editing control unit 8 includes an empty tag non-generation control function 64 that does not generate tagged data for items that are not input by the input impossibility control function 60 and items that are not input by the user. The non-input control function 60 allows a single DTD independent of personality to be used. Since the empty tag non-generation control function 64 does not generate tags for items that are not input, as a result, from the single DTD, the XML data of the individual business owner uses only the tags used for the personal business owner, The corporate XML data uses only tags used for the corporate body. For example, when the business partner is a corporation, the name of the shop is not input, so an empty tag for the name of the shop is not generated. For this reason, XML data similar to that for creating a DTD only for a corporation can be obtained. Thereby, construction of data transmission to other systems can be simplified.

  In the present embodiment, the display editing control unit 8 records the main trend in chronological order, and the essential I management function 66 for managing the reference and editing of the basic attributes, organization and business contents of the supplier as the essential I data. A requirement II management function 68 for managing trend comment reference and editing as requirement II data is provided. In order to collect information on business partners more broadly, for example, data relating to a guarantor may be managed as the essential item III, or data relating to a loan policy may be managed as the essential item IV. In the present embodiment, examples of DTD and GUI will be described for the essential points I and II.

  FIG. 9 is an explanatory diagram showing an example of a DTD used in the present embodiment. The description of DTD is by SGML. yoko2.dtd is the DTD of supplier requirements II. The element (ELEMENT) of supplier essential point II has a CIF number and a supplier trend. The + at the end of the supplier trend indicates that this element appears one or more times. If nothing is added at the end, it must be specified once.? Is 0 or 1 and * is 0 or more. No end and + are required items, and + and * can be written repeatedly on XML. ? And * may not appear. For this reason, the essential item II data is generated when one supplier trend is input for the supplier of the CIF number. The supplier trend may be entered repeatedly.

  The supplier trend includes the date of occurrence, main trend category code, major trend category name, detailed comment, entry date, store name, store name, store user ID, and store name. The detailed comment is a trend comment, and if the main trend category and the date of occurrence are entered, the essential point II data is registered even if no comment exists. An example of the essential item II data by this DTD is shown in FIG.

  yoko1.dtd is the definition of supplier requirements I. As the basic attribute, the industry code and the industry name are enclosed in parentheses in order to specify that the industry name is also required when the industry code is input. Since? Is added outside the parentheses, the number of appearances of the set of industry code and industry name is designated 0 times or once. As a customer, the base date, basic attributes, etc. are defined. This customer stores the data of the other system 40 in the RDB 56 and is the data acquired by the supplier requirement system. Data belonging to this customer cannot be entered. This customer tag definition is a definition for storing XML data history and the like. (Birth date | date of establishment) means either the date of birth or the date of establishment. For individuals, the former, for corporations, the latter. The Bank is the entity that uses this supplier system, and the Company is a customer. Examples of XML data for the essential item I are shown in FIGS.

  In the example shown in the figure, the tag is written in full-width Japanese for ease of understanding, but the software and programs are easy to handle alphabets and numbers, so in fact, English notation or Japanese Roman notation is used. Use it.

  In a preferred example, when the storage control unit 10 receives an instruction to store the history of the relevant item data, the storage control unit 10 updates the basic attribute data with the RDB data from the other system, and the essential item in which the basic attribute is updated. A history storage control function 78 that controls to store I data as history data of the essential item I is provided. The essential item I deals with items that are updated with the latest information such as officers, business details, and manufactured products. For this reason, the history storage control function 78 stores the history of the requirement I data for the business partners whose requirement I data has been updated during the year at a frequency such as once a year. In order to manage the history of the essential item I, the history creation date is defined as an element of the XML data itself in the history of FIG.

  In addition, when a supplier requirement is attached as a basis for self-assessment, the supplier requirement at the time of the assessment is required. And the data may be transmitted to another system using a function of storing the current item I data and item II data as a history. However, since the essential point II is for managing the trend of the business partner based on the date of occurrence, it itself is the latest data and is a history. For this reason, there is almost no reason to create a history with a certain frequency.

  Referring to FIG. 11, the CIF number and the date of occurrence are a fixed-length numeric string without a break. In the present embodiment, the XML data does not include a hyphen or the like, and a hyphen is inserted in the GUI definition as a kind of display data type. In yoko2.dtd, the supplier requirements have a unique CIF number and one or more supplier trends in parallel. Specification of document type by tag starts with <tag name> and ends with </ tag name>. This tag is defined by overlapping according to the hierarchy. For example, the main trend classification code belongs to the supplier trend, and the supplier trend belongs to the supplier guideline II. This hierarchy can be managed by a DOM tree having a tree structure. The relationship between the main trend category codes and the main trend category names is as shown in FIG.

  Referring to FIG. 12, the XML data of the supplier requirement I is updated after the CIF number. This order is the order in parentheses that defines the child element of the element of the supplier requirement I in FIG. The customer following the renewal is omitted here. The title subordinate relationship codes and the names of officers and the like list the relationships between the company (business partners) and officers in advance, and FIG. 21 shows an example. For representatives and the like, the representative right presence / absence code 1 is present, and 0 when there is no representative right. Not only the representation right but also the same handling in which all presence codes are set to 1 or 0 may be used.

FIG. 14 to FIG. 20 are explanatory diagrams illustrating examples of screens of supplier requirements I. In the essential point I, two sections (pages) of an organization and a business are defined, and transitions are made by tabs. As the contents of the essential I data, the organization section that displays the contents of the organization, contact information, shop name, number of employees, officers, etc., accounting staff, bankers, capital, major shareholders (large investors), business facilities, related It has tables for loan name identification, other related parties, accounting offices, bank affiliated company usage status, and securities holding status. The business section for displaying the business content includes tables of average monthly sales, business content, manufactured products, special notes, fund settlement, sales destination, supplier, and homepage address. The special notes are comments on the business contents and the characteristics of the manufactured products, and comments on the status of the industry.
In the example shown in FIG. 14 and the like, the items that can be input and the entire update date are February 10, 2002, and the update date of data acquired from the RDB 56 is the end of the month before February. Day. About the essential point I, if the page of an organization and the page of a business are scrolled, the general general condition of the business partner can be grasped. For this reason, it can be handled that the updater is not the updater for the changed or added item, but has confirmed the entire essential item I data on February 10.

  The DTD hierarchy and the screen display hierarchy are different. The element definition of DTD is not a semantic content system, but collects data acquired from the RDB as a customer, and collects data related to an input customer as a customer and others. The DOM tree is generated at the DTD hierarchy. In the presentation layer, that is, the display editing control unit 8 may edit the data of the DOM tree structure into the above-described screen display system, and handle the data as screen display data in an array or the like. For example, an EJB that processes each table reads out necessary items from the DOM tree. In this embodiment, the average monthly quotient of the business partner is used in the average monthly quotient table, the business content table, the manufactured product table, and the sales destination table. Then, the storage control unit 10 constructs a DOM tree from the array or the like for the data displayed on the screen and edited, and stores it in the XML data DB 54 after verifying the validity.

  Since A Sangyo Co., Ltd. is a corporation, the name of the shop name cannot be entered. Fields that cannot be entered should be grayed out. Here, the upper left and lower right diagonal lines of the field (box for inputting each item) indicate that input is not possible. A black circle is added to the upper left of the CIF number field. This black circle indicates that the field is a derivation item. When you enter the CIF number of the president, such as an officer, your name and date of birth are derived. The derivation destination field is grayed out because it cannot be entered. This table of officers and the like is displayed for five records. However, when data of six or more records is registered, the contents after the sixth can be referred to by operating the right slider.

  In a preferred example, the display editing control unit 8 identifies a natural person such as an officer of our company when a business partner is our company, and a corporate or business individual such as a major shareholder (large investor) of the company and a sales destination. When the CIF number is managed as an arbitrary input item and the CIF number is input, the CIF number input support function 70 for deriving the name item and address item of the table from the CIF number as a derivation source is provided. Good.

  In the example shown in FIG. 14, Shiro Osaka, who is an executive officer or the like, does not have a CIF number, so his / her name is directly entered. In normal RDB, it is not possible to permit entry of items in the table without inputting a key value such as a CIF number. However, in this embodiment, the data structure is XML, and each item can be arbitrary. On the other hand, when a CIF number is input, derivation can be performed. By separating the definition of the tag system based on DTD and the business logic of derivation, the CIF number can be an optional input item, and flexible handling of derivation when input can be performed.

  In a preferred example, the display editing control unit 8 may include a dependency relationship management function 72. The subordinate relationship management function 72 includes the position items of the officers of the business partners, the relationship items between the business partners and the major investors in the business partners, and the related items between related lenders and other related business partners. The input of each item is managed using a dependency relationship code indicating the relationship to be used. Since the relationship of the individual or the corporation related to the business partner is registered using the dependency relationship code, the lateral search can be performed precisely. In the table of officers and the like shown in FIG. 14, the title can be selected by a combo box. In this case, among the dependency relationship codes shown in FIG. 21, items whose positions are flagged are set as position dependency relationship codes. The combo box prompts you to select from the list. A combo box is indicated by placing a downward black triangle in the field. In the combo box, contents other than the list cannot be input, so the information can be made uniform. Even in a combo box, a value can not be input according to the definition of DTD.

  The dependency codes shown in FIG. 21 are systematized in a certain order with the president, chairman, and vice chairman. A plurality of records for the same element of XML have no concept of sequence number or order in the DTD in the present embodiment. In the present embodiment, positions such as officers are coded, and the numbers of the dependency relationship codes are given in the order to be displayed. The arrangement of records of officers and the like (a plurality of identical elements in the XML data) is arranged in ascending order of dependency code. That is, in the present embodiment, the display editing control unit 8 includes a dependency code sorting function 74 that rearranges the records in the post column based on the value of the dependency relationship code. Accordingly, the items can be displayed in a predetermined order instead of the order of input and registration, and the visibility of items can be improved without assigning a sequence number or the like for each item. Then, when a senior managing director becomes the president, only the position column is reselected, and the display is updated to the optimum order by the sorting function 74 for each dependency code. This sort is a server function when performed by the server-side EJB, and a terminal function when executed by a terminal-side applet. In the example shown in FIG. 14 and the like, the sorting function 74 by dependency relationship code sorts the items in each table according to the dependency when the registration button is pressed.

  In the example shown in FIG. 21, the dependency relationship codes are flagged with corporations, individuals, and positions. Thereby, it is possible to have separate code systems for the subordinate relationship in the case of a corporation, the subordinate relationship in the case of an individual business owner, and the case of a position subordinate relationship. In this example, the display edit control unit 8 may include a dependency code generation function 76 that generates a dependency code for the personality according to the personality of the supplier.

  In the example shown in FIG. 15, the shareholding ratio is derived from the total and the number of shares held by each shareholder, with the number of shares held by the major shareholders (large investors) as the derivation source. This derivation is performed by EJB. In the example illustrated in FIG. 16, name management of related loan destinations is performed. At this time, the dependency code is used in relation to the Company. Since A Sangyo Co., Ltd. is a corporation, this relation is selected from the subordinate relation codes in which the corporation flag is 1 among the subordinate relations shown in FIG. Related loan name identification (group name identification) is useful for managing credit risk, ascertaining the details of guarantees, and identifying parties that are substantially the same. Particularly in this embodiment, since the correlation is organized using the dependency relationship code, the accuracy of credit risk management for the entire group can be improved. In addition, if the relationship between the Company and A Opto Device is a subsidiary, the A Op Device related lender can automatically add the opposite concept of the subsidiary to the A industry.

  The other related parties shown in FIG. 17 are, for example, companies that have no business with the Bank but are related to the Company. The Company's shares owned by the Bank in the case of securities holdings are cases where the entity using the supplier's requirements system owns the shares of the counterparty, and vice versa.

  In the business section shown in FIG. 18 and FIG. 19, the composition ratio of the business content is derived from the business content, the average monthly quotient for each business content, and the average monthly quotient total. For example, when the payment is made on the payment deadline, the payment is closed on the last day of the current month, and the payment is made on the 15th of the next month. The reason why there are two columns is that there are two settlement months when the payment date differs depending on the counterparty, or when the settlement is done twice a year (six months settlement). In the fund settlement in FIG. 10, the payment deadline month 1 / division code is a code representing the current month in the left column of the fund settlement table in FIG. In the example shown in FIG. 18, the bonus payment month 2 month code is 12, and the bonus payment month 2 month is December.

  19 and 20, the CIF number is an optional input item, and when it is input, it is used as a derivation source for the name, address, loan number, and the like. The main transaction store is derived from the loan number. The display edit control unit 8 derives the component ratio when the average monthly quotient for each sales point as viewed from the Company is input. The cash ratio is the value of what percentage of the deposits for sales is cash. Similarly, for the supplier, enter the cash ratio of the average monthly sales sold to the Company from the supplier within the range that the user knows. From the relationship between the average monthly quotient of this purchase, the cash ratio, and the fund settlement date, the demand for funds in January can be obtained. When the payment date is also registered as the fund settlement date, it is possible to analyze the cash flow and propose an optimal fund procurement. In addition, this actual situation can be referred to when calculating a normal working capital in the asset assessment.

  FIG. 22 is an explanatory diagram showing an example of display mode transition. As shown in FIG. 22, the display / edit control unit 8 makes it impossible to input and edit all items, and disables input and editing of items acquired from other systems and derivation destination items. An edit mode for allowing entry and editing of items, and a confirmation mode for prompting confirmation of registration with the displayed contents while sorting and displaying the contents of each table according to the edit result in the edit mode 82 in the item I 84. In the essential point II, a confirmation message 85 for prompting confirmation is displayed before registration or deletion.

  When the user logs in to the supplier requirement system or the loan support system including the same, the user inputs the CIF number and selects the requirement I or II. FIG. 23 is an explanatory diagram showing the relationship between the edit button to be displayed in each edit mode and the processing contents when an event of pressing the button is received. For example, select item I and press the open button. Then, a transition is made to the reference mode of item I. In the reference mode, the return button for transitioning to the selection screen, the point II button for transitioning to the reference mode of the point II, and the editing button for transitioning to the edit mode are handled. The edit button is displayed only when the user has editing authority, and the item II button is also displayed only when the user has the reference authority of item II. In the edit mode, gray-out is canceled for fields that can be input, and input and editing are enabled. When the back button is pressed, the edited content is discarded and the screen shifts to the item selection screen. When the registration button is pressed down in the edit mode, sorting is performed, and a transition is made to a confirmation mode in which the edited content is displayed on the screen in an uneditable state. In the confirmation mode, an inquiry is made as to whether or not registration is possible. When the Yes button is pressed, after confirmation in a confirmation dialog box or the like, the entire essential item I data including the editing result is updated to the XML data DB. When the undo button is pressed, the editing mode is restored while maintaining the editing result so far. When a transition is made between the requirement selection screen, the requirement I, and the requirement II, the CIF number already input is taken over. Accordingly, when the point I button is depressed with reference to the point I, the point is referred to the point II of the same supplier.

  In the example shown in FIG. 14 and the like, there is a delete check box at the left end of each table. When the record to be deleted is selected in the edit mode and the check box is turned on, when the registration button is pushed down and the mode is changed to the confirmation mode, the display edit control unit 8 selects the record in which the delete check box is turned on. Delete and display on screen for confirmation. If registered in this state, the checked record is deleted.

  FIG. 24 is a flowchart showing an outline from user login to display of essential data on the terminal. The supplier requirement system identifies the worker who has logged into the supplier requirement system based on the user ID (step S11). The user inputs the CIF number and selects the essential item I or II and presses the open button (step S12). The authority to refer to the supplier requirements is confirmed from the user ID or the like (step S13), and if there is an authority, data such as the basic attributes of the supplier is acquired from the RDB 56 for the supplier with the CIF number (step S14). Before and after this, the XML data is fetched from the XML data DB (step S15). Further, display control of buttons according to the user authority is performed (step S16), and the screen definition file based on the GUI definition and the captured data are combined and displayed on the terminal 1 (step S17).

  In the example of controlling whether or not editing is possible according to the user's authority, the display editing control unit 8 refers to the essential points I and II based on the relationship between the store number of the user and the store number of the partner store. A button display control function 90 for controlling display and non-display of an edit button for transmitting a message requesting a transition from the mode to the edit mode to the server is provided. FIG. 25 is an explanatory diagram showing an example of authority setting according to the relationship between the user's affiliated store number and the business partner's business store. The transaction store is a main transaction store or a transaction store when there are a plurality of transactions. The other store is a case where the store to which the user belongs is neither the main store nor a multi-transaction store. The headquarters is a review, audit, secretariat and other headquarters organizations. In the example shown in FIG. 25, only reference to the essential point I is permitted in the case of another store. Accordingly, the item II button is not displayed in the item I reference mode. The person in charge at the store can edit and delete items that are not allowed to be input by the GUI definition or the like. However, since the trend of suppliers is not intended to be deleted, a certain authority is required to delete the trend of suppliers. The headquarters can only refer to the essential points I and II.

  In the example of performing the access control shown in FIG. The access control function 92 by own store and other stores is that the required item I data and the required item II data are obtained when the store number of the user and the store number of the customer's store (the main store and the store in the case of multiple transactions) are the same. Allows browsing and editing. On the other hand, the access control function 92 by own store and other stores permits the reference I data to be referred to and edits the guide I data and the guide II when the store number of the user is different from the store number of the partner store. Disallow data browsing and editing.

  FIG. 26 is a flowchart illustrating an example of processing for determining user authority. When the supplier summary system identifies the worker who has successfully logged in (step S21), it subsequently checks whether the supplier has a loan number (step S23). Since the supplier requirement system accumulates information on suppliers who have a loanee number that can specify dealer information, a customer who does not have a loanee number is not subject to the preparation of the guideline. . The store information includes a store number or the like that identifies one or a plurality of business stores (transaction stores) that conduct business with the business partner. In addition, in the case of accumulating information on a destination with no transaction record such as a prospective customer, a loanee number is assigned to the prospective customer or this step S23 is reviewed. Subsequently, the store to which the user belongs is confirmed (step S24). If you are a headquarters user, you can only refer to it. On the other hand, in the case of a store, first, it is confirmed whether the selection of the essential item is I or II (step S25). In the case of the essential item I, when the store number of the user belongs and the store number of the business partner's store coincide with each other, an edit button is displayed (step S27), the reference and editing are permitted, and the mode is changed to the reference mode screen of the basic item I. To do. Under this condition, since reference and editing of the essential point II are permitted at the same time, the basic item II button is also displayed. On the other hand, in the case of inconsistency, since it is another store, editing is not allowed and reference is permitted. In this case, the reference item II button is not displayed because reference to the item I is not permitted.

  In the case of the essential point II, it is confirmed in step S28 whether or not it is another store, and if it is another store, reference is also impossible. Therefore, the transition from the supplier requirement selection screen to the requirement II screen is not performed. On the other hand, if the user's affiliation is a main store or a store with multiple store transactions, an edit button is displayed (step S29), reference and editing are permitted, and a transition is made to the reference mode screen of item II. . Under this condition, the reference I button is also displayed because reference and editing of the guideline I are permitted at the same time.

Next, a lock for preventing data inconsistency due to multiple writing to the XML data DB or the like will be described. In this example, the server permits simultaneous multiple references by a plurality of users for the same business partner, and performs exclusive control in edit mode so that a plurality of users do not enter the edit mode for the same business partner at the same time. A lock control unit 94 is provided. As shown in FIG. 22 and the like, in this embodiment, reference and editing are clearly separated. Even if many users refer to it at the same time, there is no need to lock it because writing is not performed. On the other hand, if one user transitions to the edit mode and then allows other users to edit, double writing occurs and one update is discarded. For this reason, in this embodiment, while permitting multiple access for reference, the edit mode is registered in the confirmation mode or locked in units of CIF numbers until editing is interrupted by returning to the selection screen. It was.
Since the edit mode is clearly defined and all edits such as addition, update, and change are disabled at the time of reference, exclusive control can be performed when transitioning to the edit mode and at the time of registration after completion of editing. In this embodiment, by handling the access from the other system to the data storage unit 3 of the supplier requirement system in the same manner as in the reference mode, complicated processing such as exclusive control between systems and design such as database duplication are avoided. be able to.

  Further, in a Web application using J2EE or the like, it can be assumed that a terminal such as a PC crashes, the session with the terminal is forcibly disconnected, and only the state where the lock is secured remains in the server.

  In the example illustrated in FIG. 8, the lock control unit includes a lock acquisition control function 96, a lock release control function 97, and a lock availability determination function 98. In this example, it consists of the CIF number of the business partner, the user ID of the user who acquires (acquires) the lock, the start time which is the current time, and the end time obtained by adding the predetermined maximum lock time to the start time. The lock management information is stored in the RDB, and the lock management information is referenced to determine whether or not lock is possible. At this time, the lock management information is used to determine whether or not the user is locked, and when the maximum lock time has elapsed, the lock is forcibly released without any operation from the terminal. Thus, confusion due to the forced termination of the terminal can be avoided.

  The lock availability determination function 98 is such that the lock end time of the lock management information identified by the CIF number of the business partner to be determined for lock is later than the current time, and the user ID in the lock management information is If they are different, it is determined that the lock has been acquired.

  Specifically, as shown in FIG. 27, when the lock acquisition control function 96 shifts to the edit mode (step S41), the lock is acquired by the other users in the main item data of the customer of the CIF number. It is determined based on the lock management information (step S42). If the lock has not been acquired, after confirming that there is no own lock management information (step S43), the lock management information is written (step S44). If there is own lock management information, the end time of the lock information is updated (step S45).

  If there is a locked user in step S42, the user IDs in the lock management information are compared to confirm whether or not the user is himself. If the terminal is forcibly terminated and the edit button is pressed down after the restart and before the lock end time, the terminal is locked. If it is own lock, the lock information is updated (step S50), the XML data is locked, and the edit mode is started.

  Following step S44 or S45, the lock information is checked again, and it is determined whether there is another user who has written the lock information at the same timing. If the other party reads the lock information in step S42 immediately after step S42 until the completion of step S44, there is another user. In the opposite case, there are other users who precede. If there is no other user, the lock is acquired and the mode is changed to the edit mode. On the other hand, if there is another user, the user with the earlier lock start time or the other user is selected by other methods (step S47). If another user is selected, the lock end time is updated and the lock is released (step S48). In steps S48 and S49, if another user has already acquired the lock, editing may be disabled and a message indicating that multiple access has occurred may be displayed on the terminal.

  As shown in step S28, the lock release control function 97 locks the content data of the CIF number by the other user when the edited contents are registered (steps S61 and 62). Is determined based on the lock management information (steps S42 to S50). If the lock has not been acquired (step S63), the registration process is permitted and the end time of the lock management information of the CIF number is updated to the current time after registration (step S64). On the other hand, when the lock has been acquired by another user and the lock is impossible, the editing result cannot be registered, and the editing is interrupted by a return button or the like. At this time, a message indicating that multiple access has occurred may be displayed on the terminal. If it is determined in step S62 that the interruption has occurred, the lock end time is updated to the current time, and the lock is released.

  FIG. 29 is an explanatory diagram showing an example of the GUI of the supplier essential point II. The GUI of the essential item II displays the trend comments in a time series and the supplier trend table 100 that cannot be changed only by display, the existing trend comments in the reference mode, and the existing trend comments in the edit mode. A display / input / edit area 102 is provided as an input work area for editing and new trend comments. Since the supplier trend is not character data to be edited in principle, the supplier trend table 100 does not allow editing. New trend comments are entered in the display / input / edit area.

  As shown in FIG. 23, in the edit mode in the essential point II, clear, add, change, and delete buttons are arranged in the vicinity of the display / input / edit area 102. When the user inputs the date of occurrence, selects a main trend category, enters details (trend comments), and presses the add button, the contents entered in the area 102 are reflected in the supplier trend table. FIG. 30 shows a state in which the confirmation message regarding whether to reflect is registered by depressing the Yes button and the mode is returned to the reference mode. This area 102 is also used for displaying a portion that cannot be displayed in the supplier trend table 100.

  In the supplier trend table 100, records of supplier trends are sorted using the date of occurrence as a sorting key. For this reason, for example, when major trends in several years ago are found and comments about the trends are entered, the date of occurrence is set to several years ago, so that the date of occurrence is independent of the entry / registration order. Sorted in order. XML data is generated and stored in this rearranged state.

  Even within a branch, you may get information that should be limited to the person in charge and their supervisor. For example, information such as executing M & A on a date that is coming soon needs to be handled with care. On the other hand, at the moment of the announcement date, various actions are required. In such a case, if the date of occurrence is registered as a future date, the date is taken as the ban date, and it is displayed at the stage when that date is reached, the main points are already on the same day. And can use the information immediately within the organization. Requirement II in the supplier requirements system is for registering important business trends that occurred in the past. As an exception to the mechanism for registering past results, the introduction of a mechanism such as bans. If the display edit control unit 8 inputs a future date in the display / input / edit area 102 and registers the trend comment data of the future date, the display edit control unit 8 applies to a user group that is not permitted by the user or the like. As for the display, a ban prohibition designation registration control function 99 is provided which performs control not to display a trend comment on the future date until the future date arrives.

  FIG. 31 is a block diagram illustrating an example of a supplier requirements system including an analysis control unit. In this example, the server stores a tag system definition file 50 that defines a tag system in the markup language (ML) for the requirements of the business partner, and XML data that stores tagged data for each business partner tagged with ML. Data storage unit 3 for storing the DB 54 and the organization and business of the business partners defined by the tag system definition file 50 and the essential data on the related items such as the sales customers and / or suppliers of each business partner A display editing control unit 8 that controls display and input on the terminal 1 in accordance with the GUI definition file 52 is provided. For items related to sales partners, etc., for business partners where both sales and suppliers are registered, in each of the items in both tables, only one of the customers or suppliers is registered. Is an item in one of the tables. That is, when referring to a sales destination and / or a supplier, it is both or either one. The server also includes a storage controller 10 that converts the item data into tagged data based on the definition of the tag system, and stores the tagged data in the XML data DB 54 as integral item data.

  In the example shown in FIG. 31, in particular, the server extracts information related to the relationship between the business partners from the essential data stored by the storage control unit 10 using the item of the related item such as the seller as a search key. It has. The analysis control unit generates analysis data by lateral search using the item data accumulated using the supplier item system shown in FIG. 1 or FIG. The essential data is a collection of character data and codes whose meaning is defined by the tag hierarchy definition, and is therefore a basic material for credit risk management, sales promotion, and development of new services. Conventionally, in the example where the supplier's guideline was described in the form, due to problems such as the storage location of the form paper, it is used for work such as extracting a certain business partner across sales offices and analyzing the relationship between business partners Took a lot of work. In the example shown in FIG. 8 and the like, the essential item I data can be accessed at both the own store and other stores, and therefore analysis across sales offices can be easily performed.

  In the example shown in FIG. 31, related items such as sales destinations are particularly useful in the tag system and GUI definition shown in FIGS. 9 and 14. That is, as the tag system, the CIF number of the subject matter itself, and the CIF number of the seller etc. when the seller and / or supplier (seller etc.) are attached, If the CIF number is not attached to the seller, etc., the name or name and address of the seller, etc., and the sales amount or purchase amount for each seller, etc. regarding sales or purchase to the seller, etc. It is good to have. Here, the CIF number is a unique number that uniquely identifies the customer and the name or name and address.

  In the example illustrated in FIG. 31, the analysis control unit 110 includes a general-purpose search function 114 that searches for a dependency relationship of a business partner in a search target range using a CIF number, a name, a name, and an address as search keys. The general search function 114 may use the general search system 48 of the other system 40. In this case, the essential data is transmitted to the general-purpose search system 48 and the search is performed by the general-purpose search system 48. When general-purpose search based on supplier requirements data becomes possible, if there is a sudden increase in the credit risk of the bank's business partner or a party without business with the bank, there is a transaction with a party whose credit risk has suddenly increased. Customers can be extracted. For example, it is possible to extract a list of business partners who are dealing with credit risk increased or a related business partner. Traditionally, if you are in a fund settlement route such as currency exchange, you could grasp to a certain extent where the credit risk increased and where the transaction was, but in the fund settlement data you can definitely identify where the transaction is. Difficult, accurate and broad extraction was difficult. In the example shown in FIG. 31, a general search can be performed based on a CIF number when there is a CIF number, and based on character data such as a name or name and an address when no CIF number is input. Higher accuracy and wider extraction are possible. The ratio of the average monthly sales of sales may also be used as a secondary search key.

  As an example of general-purpose search in relation to sales promotion, for example, good companies that do not have transactions with the Bank have no supplier requirements and it is difficult to grasp the business relationship. By searching for the destination, it can be used for bill discount promotion. In addition, when a certain business partner has “PC display” for a manufactured product, it is also possible to search for a destination having “PC display” data for the product name of the supplier and use it for sales media.

  FIG. 32 is an explanatory diagram showing an example of a correlation diagram of sales / purchase relationships of business partners. In this example, the industry A shown in FIG. In order to generate the correlation diagram as shown in FIG. 32, the analysis control unit includes a correlation diagram generation function 116. This function 116 extracts the sales / purchase relationship between business partners in the search target range based on the CIF number of the business partners and the contents of the related items such as the business partners. The same sales destinations are aggregated, and a definition file illustrating sales / purchase relationships is generated.

  FIG. 33 is a flowchart showing an example of correlation diagram generation processing by the correlation diagram generation function 116. Here, the industry A shown in FIG. 14 and the like is set as the first hierarchy, and the purchase / sales relationship is extracted for three hierarchy levels. In correspondence with FIG. 32, the correlation diagram generation function 116 first reads the name of the target business partner, the type of business, the group name of the related lenders, the main transaction store, the average monthly quotient, payment related information, and the like (step S81). . In the example shown in FIG. 32, the correlation diagram generation function 116 is centered on the name of the industry A, and the supplier box in which the group name is located in the upper left, the main trading store is located in the upper right, the industry name is located in the lower left, and the average monthly sales is placed below it. Is generated. In addition, since payment has items of a closing date and a payment date, if it is input to the essential I data, payment related information is added to the upper left of the supplier box.

  Subsequently, the correlation diagram generation function 116 extracts the direct sales destination of the A industry as the second hierarchy (step S82). In the example shown in FIG. 32, only the B industry corresponds to FIG. Since B industry was extracted for the first time in this process (step S83), the sales and purchase relationship, the composition ratio of the average monthly quotient, and the product name are defined for drawing. For example, the source of the arrow is the supplier and the tip of the arrow is the purchaser, and the product name and the composition ratio of the average monthly quotient are placed at the end of the arrow. In the example shown in FIG. 32, the sales of the A industry to the B industry are printed circuit boards, which is 50% of the average monthly sales (4,000 million yen). In FIG. 32, the arrows on the right side of the supplier box are other values in the component ratio items of the supplier table and the seller table.

  Subsequently, the extraction of the seller and the supplier is repeated through the loop of steps S86 and S87. When the extraction of the second tier (B industry, sales 2 and sales 3) of the A industry seller and the second tier (purchasing 1 and purchase 2) of the supplier is completed, whether or not all the tiers are completed Is confirmed (step S88). In this case, since the third level is extracted, the first business partner is selected as the target business partner among the sales and vendors of the second level already extracted in step S89. For example, with the purchase 1 as the target business partner, the business type code of the purchase 1 and the like are read (step S81), and the sales destination is further extracted (step S82). For the industries other than the A industry, the description of the average monthly sales etc. in FIG. 32 is omitted. Assuming that A industry is stored as the sales destination of the item I data of the purchase 1 (s1, first supplier), the A industry has already been extracted, and is collected in step S84. When the purchase 2 (s2) is extracted, it is assumed that the A industry is not stored as the sales destination of the purchase 2. In this case, the arrow from the purchase 2 to the A industry may be a dotted line on the purchase 2 side. The purchase 2 has a sales destination 1 (s2_b1, a buyer 1 of a supplier 2) as a sales destination.

  When the extraction of the second-tier supplier is completed, the second-tier sales destination is subsequently extracted. If industry A is stored as a supplier in the essential data I of industry B (b1, the first of buyers), it is collected in step S84. As a supplier of B industry, “b1_s2 (supplier 2 of buyer 1)” and the like are extracted in addition to A industry. In the example shown in FIG. 32, the suppliers of the B industry are the same as the suppliers of the purchase 2 and are therefore consolidated. Subsequently, information on the third hierarchy is extracted. The supplier (S1_1) of Purchase 1 did not have a CIF number and had no information. One of the customers of B Industry is a general company. In addition, one of the customers of purchase 1 (s1) was Group A. When the extraction and aggregation processing is completed for all layers, the correlation definition file is written out, editing with other application software is urged, or direct drawing or printing is performed (step S90).

  When the correlation diagram illustrated in FIG. 32 is generated by the processing shown in FIG. 33, etc., from the relationship of the composition ratio of the average monthly sales among the business partners, the business position of the business partners and the target business partners for the sales business Can be confirmed. As shown in FIG. 32, when a correlation diagram is generated according to a distribution route centering on a certain customer, the supply chain of the manufactured product is clearly indicated, and a proposal for cost reduction can be made. Furthermore, it is possible to grasp the fund demand schedule for accounts receivable and the like based on the average monthly quotient, the composition ratio, and the payment due date and payment date information. In this case, you may make it use a cash ratio etc. together. Further, payment for sales, payment date for each payee (supplier), and the like may be handled. In this way, when paying attention to the flow of funds, the direction of the arrow in the correlation diagram is the same as the flow of funds, and is the opposite direction to the example shown in FIG. Good.

  The correlation diagram makes it clear at a glance which business partners need and how much working capital is needed, and makes it easier to carry out the contents of business promotion appropriate for the business partners considered. Further, since the same business partners are aggregated using a CIF number, a name or a name, etc., it is possible to visually grasp the actual state of the business. In addition, if the correlation diagram shown in FIG. 33 is grasped, it is possible to immediately grasp the influence or the like when the credit risk of a certain supplier suddenly increases.

  As shown in FIG. 32, the search range of the correlation diagram is a purchase / sales hierarchy in several stages from a focused business partner, a group relationship in a certain industry is extracted, and a relationship from a certain raw material to a final product is expressed. Various correlation diagrams according to various purposes, such as extraction, can be generated from data organized and stored in the supplier requirements system. For example, when there is a raw material with a large price movement, by grasping a series of distributions and correlations of business partners who use the raw material as a product, we investigate in advance the impact of changes in the surrounding situation, such as a sharp rise in raw material costs. , Credit risk management accuracy can be dramatically improved.

  Referring to FIG. 31 again, the data storage unit 3 includes an RDB 56 that stores basic attribute data such as a CIF number, a name, a name, and an address that are updated every other period in another system. When the CIF number is input to the record of the table for registering the corporation, the individual, or the private business owner displayed on the terminal 1, the display editing control unit 8 refers to the basic attribute data and stores the CIF number. A CIF number derivation function 70A for deriving basic attributes to corresponding records is provided. As a result, in the supplier essential data, the name and address of the supplier can be updated at the same time centering on the CIF number, and therefore, the aggregation process for creating the correlation diagram is facilitated.

  In addition to the essential I and essential II data, the essential data includes the loan policy that indicates the Bank's policy regarding future loans, and the general search function 114 enables the extraction of the destinations that have a certain loan policy or more. Also good. In order to make the extraction and search by the analysis control unit 110 precise and useful, the main trend in which the display editing control unit 8 explicitly classifies trend comments describing major trends using the major trend classification code. A division management function 16A may be provided. This facilitates the extraction of business partners that fall under the main trend category of trend comments. For example, we extract business partners of a specific industry with entries in major trends related to overseas business, and immediately after arriving at a certain sales office, changes in directors, etc. It is possible to perform processing such as extracting a list of business partners in which comments are entered.

  The display edit control unit 8 uses the dependency code in the table of the officers of the organization, affiliated companies, major shareholders (major investors), sellers of the suppliers, suppliers, etc. In the example provided with the dependency relationship management function 72 that prompts the classification, it is possible to execute a detailed search using the code with more detailed correlation diagrams and influence levels.

FIG. 1 is a block diagram illustrating a configuration example according to the first embodiment. FIG. 2 is an explanatory diagram showing the relationship of each system regarding handling of character data. FIG. 3 is an explanatory diagram showing an example of main trend categories. FIG. 4 is an explanatory diagram showing an example of a GUI for trend comments. FIG. 5 is an explanatory diagram showing an example of a trend comment type display. FIG. 6 is a flowchart illustrating an example of trend comment type display control. FIG. 7 is an explanatory diagram illustrating an example in which a trend comment of a sales promotion type is associated with a main trend category of another type. FIG. 8 is a block diagram illustrating a configuration example of the second embodiment. FIG. 9 is an explanatory diagram showing an example of a DTD used in the present embodiment. FIG. 10 is an explanatory diagram showing an example of the DTD following FIG. FIG. 11 is an explanatory diagram showing an example of the xml data of the essential item II in the example shown in FIG. FIG. 12 is an explanatory diagram showing an example of the xml data of the essential item I in the examples shown in FIGS. 9 and 10. FIG. 13 is an explanatory diagram showing an example of xml data following FIG. FIG. 14 shows the structure of the user view based on the GUI definition and the table of the I section corresponding to the xml data shown in FIG. 11 and FIG. It is explanatory drawing which shows the example of a display. FIG. 15 is an explanatory view showing a display example of each table of the bank originator, capital, and major shareholder (major investor) in the organizational block in the essential item I data. FIG. 16 is an explanatory diagram showing a display example of each table of the business facility of the organizational section and the related loan destination name identification in the essential item I data. FIG. 17 is an explanatory diagram showing a display example of each table of the other related destinations of the organizational block, the accounting office, the bank affiliated company usage status, and the securities holding status of the essential item I data. FIG. 18 is an explanatory diagram showing a display example of each table of average monthly sales of business sections, business contents, special notes, industry status, manufactured products, and funds settlement in the item I data. FIG. 19 is an explanatory diagram showing a display example of each table of manufactured products, sales destinations, and suppliers in the business section in the essential item I data. FIG. 20 is an explanatory diagram showing a display example of each table of the supplier and the homepage of the business section in the essential item I data. FIG. 21 is an explanatory diagram showing an example of the code system of the dependency relationship code. FIG. 22 is an explanatory diagram showing an example of display mode transition. FIG. 23 is an explanatory diagram showing the relationship between buttons and processing contents. FIG. 24 is a flowchart showing an outline from user login to display of essential data on the terminal. FIG. 25 is an explanatory diagram showing the relationship between the user authority and accessible display modes. FIG. 26 is a flowchart illustrating an example of processing for determining user authority. FIG. 27 is a flowchart illustrating an example of the lock availability determination process and the lock acquisition process. FIG. 28 is a flowchart illustrating an example of the lock release process. FIG. 29 is an explanatory diagram showing an example of the editing mode in the essential point II. FIG. 30 is an explanatory diagram showing an example after registration in the essential point II. FIG. 31 is a block diagram illustrating a configuration example including an analysis control unit. It is explanatory drawing which shows an example of the correlation diagram produced | generated by the analysis control part. It is a flowchart which shows an example of the processing content of a correlation diagram production | generation function.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 Terminal 2 Network 3 Data storage part 4 Business partner system 6 Acquisition control part 8 Display edit control part 10 Storage control part 16 Main trend classification management part

Claims (5)

A server connected to the terminal and other systems via a network, and a data storage unit for storing data processed by the server as XML data,
The data storage unit, a DTD is a tag system definition file that defines a systematic and XML tags stratifying items of the data, and the previously constant meth GUI definition file input display area in the terminal, the DTD Storing the tagged data tagged in accordance with the XML data DB and retrieving the XML data DB retrieved from the server and the other system ,
The server, the data to display the data in the input table display region of the terminal by sending to the terminal,
On the other hand, the data input, selected or edited by the user of the terminal in the input display area of the terminal is received, the data is tagged as defined by the DTD, and the validity verification process by the XML parser And storing the verified XML data in the data storage unit,
In a predetermined system in which the server permits a search from the other system,
The data storage portion has a RDB that manages the basic attribute data of the individual or entity to be updated Te to the other system,
The tag system definition file is an element of the DTD according to the tag system definition for the XML data.
Supplier requirements I relating to the organization and business of the supplier, basic attributes, and elements related to the organization and business,
The basic attribute has a 0 or 1 appearing CIF number that uniquely identifies a legal entity or individual, a 0 or 1 appearing name or name, and an 0 or 1 appearing address;
Among the element groups related to the organization and business, each element group related to a corporation or an individual has basic attributes that appear once and input display elements that are input and display items.
Among the element groups related to the organization and business, the element group other than the element group related to the corporation or the individual has the input display element.
The GUI definition file has a table in the input display area of the terminal for each element related to the organization and business, and the derivation between items in each table as a definition that input is impossible in the items of each table. According to the derivation relationship between the original item and the derivation destination item has a predetermined input impossibility,
The server
A display editing control unit and a storage control unit;
The display editing control unit
When the user of the terminal inputs data relating to a corporation or an individual related to the customer in the table,
When a CIF number is input to the CIF number item that is the derivation source item, the name or name item that is the derivation destination item and the address item are disabled according to the definition of the GUI definition file.
When the CIF number is not entered and entered in the name or name field, the address field is not disabled,
When receiving derived from the terminal, by referring to the basic attribute data of the RDB derives said said name or designation of the CIF number as Derived From Address is in the licensee item in the table Display the name or name and address,
When the storage control unit stores the data of the supplier requirement I, a tag corresponding to each item is attached to each data, and the data on the organization and business of the supplier for each CIF number is the tag. Whether the hierarchy defined in the system definition and the number of appearances are verified by the XML parser, and when the data has validity in relation to the tag system definition, the processed XML data is stored Customer requirements system characterized by The data storage unit
For a legal entity or individual related to the business partner to be entered, a dependency code that pre-encodes the relationship with the business partner, and a dependency that identifies the dependency code,
The display control unit
When the item of the table input by the user of the terminal is defined as a dependency by the GUI definition file, the user is prompted to select a dependency, and the dependency is displayed on the item.
Upon receiving a confirmation from the terminal, in the table, as a key value of the dependent relationship code which is determined by the corresponding dependencies, and sorting according to the value of the dependency code, the dependency code values Display the table on the terminal in the order sorted according to
The storage control unit
2. The supplier requirements system according to claim 1 , wherein the XML data is stored in the sorted order . The display editing control unit
Receiving an operation on the edit button or an operation on the registration button displayed on the terminal, changing the display mode of the terminal,
The display editing control unit includes, as the display mode, a reference mode that disables input and editing to the items in the input display area, an editing mode that allows input and editing to the items in the input display area, It is provided with a confirmation mode that prompts confirmation of registration with the displayed contents while sorting and displaying the contents of each element by the editing result in the editing mode,
The display editing control unit
When displaying in the reference mode, an edit button operated to change to the edit mode is displayed,
When displaying in the edit mode, a registration button for changing to the confirmation mode is displayed.
The display editing control unit
Each element input in the editing mode is sorted using the key value of the element as a key, displayed on the terminal for confirmation to the user without input editing,
3. The supplier requirements system according to claim 2 , wherein the storage control unit stores the items in the sorted order when confirmed by the user . The tag system definition file is an element group related to the organization and business of the DTD based on the tag system definition for the XML data.
  Have a sales partner for the business of the customer,
  Each of the sellers has the basic attribute that appears once,
  The server
  An analysis control unit is provided for searching for the sellers of the suppliers in the search target range stored in the XML data DB using the CIF number or the name or name as a search key, and extracting a list of the searched suppliers. 3. The supplier requirement system according to claim 1 or 2, characterized in that: The tag system definition file is an element group related to the organization and business of the DTD based on the tag system definition for the XML data.
Have a supplier and a supplier for the business of the customer,
Each of the seller and the supplier has a basic attribute that appears once, a transaction amount that appears once or once, and a product name that appears zero or once.
The server includes an analysis control unit,
This analysis control unit
When the CIF number of the target business partner and the number of hierarchies are specified, the seller and supplier of the business partner in the search target range stored in the XML data DB are searched using the CIF number as a search key. And a determination process for determining whether the searched business partner is the same as any of the business partners already searched,
When they are not the same, the name or name of the basic attribute of the searched business partner, the transaction volume, and the product name are read from the XML data DB and searched for the target business partner that is the search source. A definition process for defining the read data for drawing, together with a sales purchase relationship that becomes an arrow between the business partner,
When it is the same, it comprises an aggregation process that aggregates by defining the sales purchase relationship for drawing,
The analysis control unit
After the search for the seller and supplier of the target supplier is completed,
The search process, determination process, definition process, and aggregation process are repeated with the searched next-tier business partner as the target business partner, and the repetition is repeated until the number of levels is completed, so that the specified 3. The supplier requirement system according to claim 1 or 2, wherein a definition file that is a correlation diagram of the target supplier is generated.

Images