JP5086719B2 - Contract creation device and contract creation method - Google Patents

Description

  The present invention relates to a contract document creation apparatus and a contract document creation method suitable for application to support creation of a contract document when, for example, an image forming apparatus is sold.

  Conventionally, for example, the contract type concluded between the sales company of the image forming apparatus and the customer includes a sales contract involving the sale of goods, maintenance of the purchased goods (regular inspection for the customer, parts Hardware maintenance contracts that do replacement (also referred to as maintenance), kit contracts that sell equipment without a hardware maintenance contract, spot contracts that perform maintenance when sold-out equipment fails, image formation There is a performance contract that counts the number of printed sheets of an apparatus or the like. In preparation for concluding these contracts, sales representatives at sales companies look for the optimal contract documents from the cabinet, their desks, and the contract format database that the sales company has, and create contracts by hand. Was. The sales representative brought the prepared contract to the customer, explained the contract, and handed the contract to the customer to conclude the contract.

Patent Document 1 includes special and unjustified contract contents by making it possible to determine whether the contract contents are standard or not even if the contractor does not have specialized knowledge about the contract. Techniques that support the determination of whether or not are disclosed.
JP 2002-230467 A

  By the way, as the types of image forming apparatuses and service contents increase, the types of contracts required also increase. Moreover, the contents to be described in the contract are also complicated. Furthermore, there are hundreds of different contract formats depending on the contract content, depending on the contract type, equipment to be sold, and the like.

  In addition, a sales person who does not know the details of the contract sometimes creates a contract with an inappropriate contract. In this case, although the contract contents differ depending on the contract type, the contract with the incomplete description is formally authorized. If such a contract exists, the sales representative not only has to perform unnecessary work to confirm whether the contents are correct, but also a problem of default of the contract to the customer may occur. For this reason, it has been required to reduce the types of contracts and simplify the creation of contracts.

  In addition, the management of contracts due to differences in contract type (contract form) has not been performed properly. For example, even if a contract for a certain product is concluded, if the combination of contract types in the contract is inappropriate, the customer must conclude the contract again. Such trouble not only hinders the efficiency of business, but may lead to a decrease in customer satisfaction.

  The most important thing in business negotiations with customers is to specify and agree what the products and services they provide are specifically. Considering the types of products and services provided to customers and the types of contracts required for agreements, breach of agreements with customers due to mistakes can be a fatal problem.

  The present invention has been made in view of such a situation, and an object thereof is to simplify the format of a contract.

The present invention selects a negotiation ID that uniquely identifies the negotiation content, a customer ID that uniquely identifies the customer, a contract classification ID that identifies the type of contract, and a commodity code that uniquely identifies the commodity, For the contract associated with one or more negotiation IDs that uniquely identify the contract ID, contract information that can create a contract is recorded in the record of the contract table that is selected by specifying the contract ID that uniquely identifies the contract.
Then, based on the contract information specified by specifying the contract ID, a contract document is created by selectively combining template files having a predetermined format.

  By doing in this way, it becomes possible to create a contract based on a contract template determined according to the contract type.

  According to the present invention, since the contract template is determined according to the contract type, there is an effect that it is possible to easily create a contract with an appropriate clause and clause selected for each contract type.

  Hereinafter, an embodiment of the present invention will be described with reference to the accompanying drawings.

FIG. 1 is a schematic diagram showing the entire device management system as an example of the present embodiment.
The device management system 101 of this embodiment includes several web servers 102 and 103, a database server (hereinafter “DB server”) 104, and a number of client PCs 105, 106, and 107 that access these servers.
The in-house LAN 109 constitutes a TCP / IP network mainly composed of known private IP addresses, and covers all group companies.
The client PC 105 is a typical personal computer and operates a web browser (not shown) for accessing the web server 102.
The web server 102 is separated and distributed for each group company or for each business in charge.

The client PC 105 accesses the web server 102.
The web server 102 accesses the DB server 104.
That is, the web server 102 provides a user interface for accessing the DB server 104 to the client PC 105.

The web servers 102 and 103 and the DB server 104 are distributed for the purpose of load distribution, safety ensuring, etc., and for facilitating the construction such as duplexing for safety ensuring.
Of course, when the scale of the system is small, these can be integrated.

FIG. 2 is a functional block diagram showing details of the web server 102 and the DB server 104.
The web server 102 includes a web server program 202 and many cgi (Common Gateway Interface: a mechanism for a web server to start a program in response to a request from a web browser).
Each cgi includes an employee authentication cgi 203 for authenticating an employee who can access the in-house LAN 109, and a cgi for creating an html document for creating various user interfaces.
The DB server 104 includes a number of tables that store various data and play a central role in the device management system 101. FIG. 2 shows a part thereof. A detailed description of the table group will be described later (see FIG. 3).
The DB server 104 constitutes a well-known SQL (language specialized for operation of a relational database) server.

FIG. 3 is a schematic diagram partially extracting field names of a table group included in the DB server 104.
The employee table 302 is a table centered on an employee ID that uniquely identifies the employee. In addition to the “employee ID”, the field includes a field indicating the employee “name” and “affiliation”. Although not shown, a hash value of a password is also included, and is used for employee login authentication and the like.
An employee who visits a customer company and concludes a contract is also referred to as a “sales representative”.

The customer company table 303 is a table centering on a customer ID that uniquely identifies a customer company. In addition to “customer ID”, the field includes a field indicating “customer company name”. When a desired customer company name is displayed on the display screen of the client PC 105, the value of the “customer company name” field is acquired from this table.
The customer contact person table 304 is a table centering on the contact person ID for uniquely identifying the customer contact person. In addition to the “person in charge ID”, there are a “person in charge name” of the customer person in charge and a “customer ID” field for identifying the customer company.
The customer installation destination table 305 is a table centered on an installation destination ID that uniquely identifies an installation location (installation destination) when installing a device sold to a customer. In addition to “installation destination ID”, there are “installation location” and “customer ID” fields.

The negotiation table 306 is a table centering on the negotiation ID that uniquely identifies the negotiation. Create a new record when a salesperson starts a business deal with a customer. The field
・ In addition to "Business negotiation ID"
・ As one of the detailed contents of the negotiation, the “negotiation date” that indicates the date when the negotiation was started,
・ "Negotiation status" indicating the progress of negotiations and the results (provisional contract, contract establishment, contract failure, etc.)
・ "Customer ID" in the customer company table,
・ "Contact ID" in the customer contact table,
・ "Employee ID" in the employee table
Exists.

The contract table 307 is a table centering on a contract ID for uniquely identifying a contract. Create one new record per contract. The field
・ In addition to “Contract ID”,
-"Contract Type ID" indicating the type of contract,
-As one of the details of the contract, "Contract Date" indicating the date the contract was created,
-"Contract status" indicating the progress of the contract and its results (provisional contract, contract establishment, contract failure, etc.)
・ "Issuance count status" for storing the number of officially issued contracts
・ "Parts code" indicating the parts that make up the contract,
-"Template code" indicating the template file determined for each part of the contract,
-"Contract document image file" which is converted into electronic data by using a scanner to capture a contract signed by a customer
Exists.

  The business negotiation contract table 308 is a table composed of a pair of “business negotiation ID” and “contract ID” that describes a one-to-many relationship between a business negotiation and a contract. That is, a plurality of contracts can be generated for one business negotiation. Due to the presence of this table, it is possible to refer to the negotiation ID from the contract ID and vice versa.

  The forbidden condition table 309 is a table that describes combinations of products and services that cannot be sold together in an estimate created when a salesperson proceeds with a business negotiation. The combinations of “product codes” in the product basic information table 312 described later or “service codes” in the service basic information table are listed.

The closing date condition table 310 is a table describing contract conditions relating to the closing date of work for checking the counter of the image forming apparatus or the like. The field
-"Contract ID" that indicates which contract the device belongs to,
・ "Product code" that identifies the device,
・ In addition to the serial number of the device (hereinafter referred to as “machine number”)
・ As one of the details of the contract, `` Condition date condition '' indicating the condition of the closing date,
・ "Priority" indicating the priority of "Condition date"
Exists.

The contract type table 311 is a table that lists contract types. The fields include “contract type ID” and “contract type name”.
The contract types include “sales contract”, “hardware maintenance contract”, “performance contract”, “kit contract”, “spot contract”, and “purchase order”. Detailed examples of contracts created by these contract types will be described later.

The product basic information table 312 is a table centering on a product code for uniquely identifying a product. In addition to a “product code” for identifying each product, there are a “product name” field, a “product detailed information” field, and the like.
The service basic information table 313 is a table centered on a service code that uniquely identifies a service. In addition to the “service code” for identifying each service, there are a “service name” field, a “service detailed information” field, and the like.
The product etc. configuration table 315 is a table composed of a set of “service code” and “product code” describing a one-to-many relationship between services and products.
For example, under the name “Safety Pack”, a service including the maintenance service of personal computers and the provision of virus protection software products can be considered. Thus, since some services include products, such a table is provided.

  The contract product etc. table 314 is a table composed of a set of “contract ID” and “product code” or “service code” describing a one-to-many relationship between a contract and a product or service. That is, a plurality of products or services can be generated for one contract. This table includes fields such as “machine number” and “installation destination ID”.

The device management table 316 is a table that plays a core role in this embodiment.
Each device (product) is uniquely identified by the “product code” and “machine number”, and the date and status information of “the lifetime of the device”, from the delivery of the device to the customer, to the disposal or recycling of the device. This is a table that is recorded and managed one by one. The field
・ In addition to `` product code '' and `` machine number ''
"Contract ID" in the contract table 307 indicating the contract to which this device belongs,
"Installation ID" of the customer installation table 305 indicating the location where this device is installed,
-"Equipment operation status" indicating the status of this equipment, "Equipment logistics status", and "Date" recording the status information
Exists.

The counter confirmation log table 317 is a table that mainly stores a numerical value of a “counter” that is built in the image forming apparatus and is incremented with each use. The image forming apparatus is configured such that the usage amount is charged according to the number of uses, that is, the number of sheets consumed by the copy output. Therefore, the value of the counter built in the image forming apparatus is confirmed and recorded in the counter confirmation log table 317 on the closing date determined every month. The field
・ In addition to `` product code '' and `` machine number ''
"Contract ID" in the contract table 307 indicating the contract to which this device belongs,
・ "Counter value",
・ "Counter status" indicating the status of the counter value acquisition
Exists.

The contract template table 318 is a table for recording a part code for identifying a template part necessary for the contract and a template code for identifying the template. A contract template corresponding to the part code and the template code is recorded in the contract template table 318 as a template file.
The contract is created by combining the five parts described below. However, there are parts that are required in one contract but not required in another contract. These five parts are also referred to as “basic patterns”.
・ "Cover": A part that expresses the contractual relationship between A and B.
・ "Basic provisions": Parts that express "basic provisions" necessary for sales.
“Service clause”: a part that expresses a “basic clause” for added value such as a maintenance service, not a thing (for example, an image forming apparatus or a PC).
-“Contract fee”: A part that expresses the price at the time of estimation.
“Maintenance details”: When a maintenance service is contracted, a part that expresses what the service is to be performed on.

The contract type combination prohibition table 319 is a table that prescribes contract types of inappropriate combinations when creating a contract.
There are multiple types of contracts. Among them, there are contract types for which combinations are prohibited. For example, hardware maintenance contracts, kit contracts, and spot contracts are prohibited from being combined. As a prohibition condition, a combination of contract type IDs is recorded in the following fields.
・ "First Contract Type ID"
・ "Second Contract Type ID"
The first and second contract type IDs include contract type IDs corresponding to (hardware maintenance contract, kit contract), (hardware maintenance contract, spot contract), and (kit contract, spot contract). It is recorded.

[Contract creation support]
The creation of a contract document performed by the device management system 101 roughly follows the following processing.
First, after creating an estimate and presenting it to the customer, the customer determines whether or not to introduce the content and answers the sales person.
Depending on the product configuration created in the quotation, selectable contract combinations are presented in menu items on the contract creation support screen.
When the customer selects desired contract contents, information necessary for creating a contract document, particularly flag information groups indicating various conditions, is recorded in the contract table 307. Then, necessary contract templates are selectively read out and a contract is automatically created.
Further, the condition information of the contract created at this time is written in the closing date condition table 310 depending on the device to be sold, and is used for the counter confirmation reminding process using the counter confirmation log table 317.
In the present embodiment, processing from display of menu items on the contract creation support screen to creation of a contract is performed.

[Details of contract creation support function]
FIG. 4 is a block diagram focusing on the contract creation support function in the device management system 101 of this embodiment. In the present embodiment, by selecting a format designated at the time of contract conclusion, a contract in which appropriate contents according to the contract device and contract type can be created.

  The client PC 105 includes an input unit 105 b that accepts input of characters and numbers from a keyboard, an optical reading unit 105 c that optically reads an issued contract, and an interface that transmits and receives html documents to the contract creation web server 402. A communication interface 105 d that is a liquid crystal display, a display unit 105 e that displays a contract creation screen described later, and an output unit 105 f that outputs image data of the created contract to a printer (not shown) attached to the client PC 105. , Is composed of. An example of a contract printed from an external printer via the output unit 105f will be described later. The contract creation screen includes an estimate information registration screen 1100, a quote display screen 1200, a product basic edit screen 1300, an option selection screen 1600, and a performance service selection screen 1610, which will be described later.

  A sales representative 401 who works at the sales company can access the contract creation web server 402 installed at the sales company by operating the client PC 105. A sales representative 401 who can create a contract is authenticated with the user ID and password input on the client PC 105 by an authentication cgi (not shown) of the contract creation web server 402.

The contract creation web server 402 performs predetermined processing in response to an access request (HTTP request message) coming from the client PC 105.
Depending on the contents of the predetermined processing, various tables stored in the DB server 104 are accessed such as data acquisition or writing in accordance with the SQL standard. An arrow line extending from the contract creation cgi 404 to each table corresponds to this. Although these are conceptual lines, actually, as shown in FIG. 1, the web server 102 and the DB server 104 are connected to the in-house LAN 109, and these access operations indicated by arrows are performed through the in-house LAN 109. .

The contract creation web server 402 includes a web server program 202 and a contract creation cgi 404. Although many cgi exist in addition to this, only those directly related in the present embodiment are extracted and described in FIG.
The web server program 202 constitutes an HTTP server. In response to a client request (HTTP request message) coming through the in-house LAN 109, which is a TCP / IP network, an HTML document and an execution result of cgi are transmitted in the form of an HTTP response message. An example is Apache (http://www.apache.org/).

The contract creation cgi 404 creates an html document that can be decoded by the web browser of the client PC 105.
Further, the contract creation cgi 404 includes a function of an SQL client, accesses each table of the DB server 104, and acquires desired data.

  As described above, the DB server 104 constitutes a well-known SQL server. In FIG. 4, in order to clarify the table handled by the contract creation cgi 404, the program part of the SQL server is not shown. The actual DB server 104 includes a combination of an interactive database engine program that interprets and executes an input SQL language and a data file group that constitutes a table.

FIG. 5 is a block diagram for explaining the function of the contract creation cgi 404 in the contract creation web server 402.
An html document creation unit 501 that creates an html document converts a contract creation screen (to be described later) and image data of the contract into an html document and sends it to the client PC 105 as an html message.
The item selection unit 502 that acquires data necessary for each item constituting the contract creation screen acquires necessary information from the customer company table 303, the negotiation table 306, the contract table 307, the contract type table 311 and the like. Further, the contract document creation cgi 404 refers to the contract type combination prohibition table 319 and controls so as not to create a contract document of a prohibited combination.

Items input via the contract creation screen displayed on the client PC 105 are converted into an html document by the control unit 105 a of the client PC 105, and an html message is transmitted to the contract creation web server 402.
The html document receiving unit 504 of the contract creation web server 402 receives this html message. Based on the received html message, the contract creation unit 603 that creates a contract checks the contents of the input items. If there is no error in all items, the contract creation unit 503 reflects the contract contents in the contract table 307 and selects a template file of parts necessary for the contract from the contract template table 318.
Then, the contract document creation unit 503 creates a contract document file reflecting the contract contents based on the selected template file, and transmits the contract document file to the client PC 105.
The client PC 105 outputs the received contract document file to the printer. As a result, the contract is issued as a document.

  The contracts created in this embodiment include a sample contract issued at the estimation stage and a contract issued officially. In a contract issued officially, a code (for example, a value combining alphanumeric characters) indicating the number of times of issuance is displayed in the header of the contract. The sales representative can know how many times the contract contents have been modified by the code representing the number of times of issuance.

FIG. 6 is a conceptual diagram showing the relationship between the fields of each table in the DB server 104 of FIG.
The contract creation cgi 404 searches the negotiation table 306 by using the negotiation ID with which the negotiation with the customer has been established as a key, and obtains various information related to the negotiation.
Next, the contract creation cgi 404 searches the business negotiation contract table 308 with the business negotiation ID, and obtains one or more contract IDs of the corresponding contracts.
Next, the contract creation cgi 404 searches the contract table 307 by contract ID and obtains various information related to the contract.
Next, the contract creation cgi 404 searches the contract type table 311 with the contract type ID to obtain various information related to the contract type.
Next, the contract creation cgi 404 searches the contract template table 318 using the part code and the template code, and obtains a format file for creating the contract. At this time, a basic pattern file is obtained.
Further, the contract creation cgi 404 searches the contract product etc. table 314 with the contract ID,
・ One or more product codes or service codes
・ Get one installation ID.

Next, the contract creation cgi 404 searches the product basic information table 312 using the product code to obtain various information related to the product.
Then, the contract creation cgi 404 searches the customer installation destination table 305 with the installation destination ID, and obtains various information relating to the installation destination.
Next, the contract creation cgi 404 refers to the contract type combination prohibition condition table 319 with the contract type ID, and checks whether the combination of the contract type IDs combined with one contract ID is appropriate. If the combination of the contract type ID for one contract ID is inappropriate, the creation of the contract related to the contract type ID is prohibited.
In this way, the contract creation cgi 404 can acquire data in a state where the information of each table is linked, and can create contract data.

FIG. 7 is a flowchart showing a processing example of the client PC 105 that creates a contract and the contract creation web server 402.
The sales representative performs an item check using a check list (not shown) in advance in order to start creating the contract. Here, in order for a sales person to issue a contract, a contract according to the contents of the negotiation is determined, and a list of items necessary for issuing the contract is referred to as a check list.
After the item check by the sales representative, the client PC 105105 is activated, connected to the contract creation web server 402, and after performing a predetermined user authentication procedure, the following contract creation process is started.

  First, the client PC 105 makes an acquisition request for a contract creation screen (step S1). The contract creation web server 402 transmits a contract creation screen as an html document to the client PC 105 (step S2).

  The client PC 105 displays the received contract document creation screen on the display unit 105e (step S3), and selects a contract type (step S4). The contract type selected by the client PC 105 is transmitted as a contract type ID to the contract creation web server 402 (step S5).

  The contract creation web server 402 refers to the contract type combination table 319 and checks the possible combinations of contract type ID for each contract ID (step S6). The contract creation web server 402 transmits the check result to the client PC 105 (step S7).

  Then, predetermined items are input from the input unit of the client PC 105 (step S8). When necessary items are input, the client PC 105 transmits the input items to the contract creation web server 402 (step S9).

  The contract creation web server 402 checks the contents of the received input item (step S10). If the contents of the input item are valid, “OK” is notified to the client PC 105 (step S11). In order to issue the contract, the client PC 105 changes to the “confirmation mode” and notifies the contract creation web server 402 of “confirmation” (step S12). Here, the state where it is not necessary to correct the input item and the contract can be issued is referred to as a “determined mode”.

  Subsequently, the contract document creating web server 402 reads the contract document template table 318 and the like, and creates contract document image data (step S13). Then, the contract document image data is transmitted to the client PC 105 (step S14).

  The client PC 105 displays the received contract image data on the display unit 105e (step S15). Then, a contract is issued through the printer connected to the client PC 105 (step S16). If the contract to be issued is formal, the contract creation web server 402 is notified of the number of formal contracts issued (step S17).

  Next, the client PC 105 optically reads the officially issued contract with a seal, signature, etc. from the customer using a scanner or the like (step S18). The read contract document image file is transmitted to the contract document creation web server 402 (step S19) and stored in the contract table 307 based on the contract ID.

FIG. 8 is a flowchart illustrating an example of a contract creation process performed by the client PC 105.
First, a contract creation screen is displayed on the display unit 105e of the client PC 105 (step S21). Next, the user inputs a contract ID on the contract creation screen (step S22). When a new contract is created, the contract ID is automatically entered. On the other hand, the user selects and inputs a contract ID when displaying the contract details of the contract being created.
Then, in response to key input from the input unit, the contract content is input to the necessary items on the contract creation screen (step S22).

  Then, the contract type of the contract created by the user is selected (step S23). The information on the selected contract type is sent to the contract document creating web server 402, and the combination of contract types is checked. Based on the check result received from the contract creation web server 402, it is determined whether or not the combination of contract types is valid on the contract creation screen (step S24).

  If the combination of contract types is not valid, the process returns to step S23, and reselection of a combination of valid contract types is prompted. On the other hand, if the combination of contract types is valid, input of necessary items is prompted on the contract creation screen (step S25).

  Then, the contract image data is displayed on the display unit 105e (step S26), and it is determined whether or not the contract is officially issued (step S27). If all the contents are not entered in the necessary items, a sample contract is issued (step S28). The sample contract is a contract issued in a state where all items are not satisfied, and the contract is not concluded even if the sample contract is delivered to the customer representative.

When all the contents are entered in the necessary items, the process for officially issuing the contract is entered. At this time, since the mode is changed to the “determined mode” (step S29), it is impossible to easily change the input contents in a later process.
However, even in the middle of the contract, the person in charge of the client company can refer to the sample contract and grasp the image of the contract. For the issued sample contract, a contract ID is issued and stored in the contract table. For this reason, it is possible to re-display or reprint the input content of the sample contract document from the contract ID on the display unit 105e of the client PC 105.

Then, the contract is officially issued (step S30). The issuance of the contract or sample contract is performed by a printer (not shown) connected to the client PC 105 or the in-house LAN.
The number of times the contract is officially issued is recorded in the contract and is notified to the contract creation web server 402 through the communication line (step S31), and the contract creation process is terminated.

FIG. 9 is a flowchart illustrating an example of a contract creation process performed by the contract creation web server 402.
First, the contract creation screen is transmitted as an html document to the client PC 105 (step S41). Then, the input item is received from the client PC 105 (step S42). The contract creation web server 402 checks the contents of the received input item (step S43).

If there is an error in the input item, the client PC 105 is notified of the content of the error (step S49), prompts for correction input, returns to the processing in step S42, and waits for input item reception. After the correction input, the item check is performed again.
If there is no error in the input items, a change notification of “confirmed mode” is received from the client PC 105 (step S45), and the contract form is officially started in the state changed to the confirmed mode (step S46).

The contract creation web server 402 determines whether or not the contract has been officially issued (step S46). Whether or not it has been issued can be determined by referring to the issue count status in the contract table 307.
If the contract has not been issued, the contract is issued (step S47), and the issuance count status is set to “issued” (step S48). At this time, the issuance count “1” is stored in the issuance count status.

If the contract has been issued, the contract creation web server 502 determines whether or not the estimate information is to be modified (step S50).
If it is not correction of the estimate information, an input screen for allowing the sales person to input the reason for reissuing is created and transmitted to the client PC 105. Then, the reason for reissuance is received from the client PC 105 (step S51). Thereafter, reissuance of the contract is approved (step S52), and the issuance count incremented by “1” is stored in the issuance count status.

On the other hand, if it is determined in the determination step S50 that the estimate information is to be corrected, the client PC 105 is notified of reissue for re-estimation (step S53). Thereafter, the contract is reissued (step S52), and the issuance count incremented by “1” is stored in the issuance count status.
Then, the contract creation web server 402 records the entered contract information in which the contract information capable of creating the contract is updated to the record specified by the contract ID regardless of whether the contract is issued or reissued (step S54), the process is terminated. Note that the contract information may be recorded when the sample contract is issued.

Here, the configuration and type of the contract created in the present embodiment will be described with reference to FIG.
FIG. 10A is a table in which five basic parts that are templates of contracts determined for each contract type and names of contracts are stored. The contract is created by combining basic parts according to the contract type.
FIG. 10 shows that, for example, the sales contract is composed of three parts: “cover”, “basic clause”, and “contract fee”.
Further, it is indicated that the hardware maintenance contract is composed of five parts of “cover”, “basic clause”, “service clause”, “contract fee”, and “details for maintenance”.
A combination of a sales contract and a hardware maintenance contract, a combination of a sales contract and a kit contract, etc. are possible. However, combinations of hardware maintenance contracts and kit contracts, combinations of kit contracts and spot contracts, and combinations of hardware maintenance contracts and spot contracts are prohibited.
The contract creation web server 402 refers to the contract type combination table 319 to prevent a contract from being created with a combination of prohibited contract types when creating a contract.

FIG. 10B is an example of a “cover” part, and there are two types of “cover” parts: “A-B type” and “A-B's agent type”.
FIG. 10C shows an example of the “basic clause” part. The “basic clause” part includes “transaction clause”, “P / C contract clause + (personal information)”, “kit contract clause”, “ There are four types of “spot contract clauses”.
FIG. 10D is an example of a “service clause” part. The “service clause” part includes “hardware maintenance”, “soft maintenance”, “performance charge and calculation method thereof, target machine / installation location” There are three types of "special provisions regarding remote services and provisions regarding printer / scanner units".
FIG. 10E shows an example of a “contract fee” part. The “contract fee” part has one type of “basic”.
FIG. 10F is an example of a “maintenance target detail” part, and the “maintenance target detail” part has one type of “for hardware”.

In the contract, in addition to the Party B type concluded between the company to which the customer (A) and the sales representative (B) belong, there is a Party B type in which a broker (B) is present.
In addition, a machine maintenance service charge collected from a customer as a price for a performance (a system for performing periodic maintenance and failure repair) is referred to as P / C (Performance Charge).
In addition, a system that performs maintenance / inspection / repair within a contract valid period of several years after delivery by purchasing a dedicated consumable kit (for example, toner) from a customer or a contract thereof is referred to as a kit contract.

Here, a configuration example of a contract creation screen for creating each contract will be described.
FIG. 11 is an example of an estimate information registration screen 1100 for creating a sales contract.
The estimate information registration screen 1100 is a screen that is displayed as an initial screen for creating a contract, and is used for temporarily registering a contracted device and service and estimating a necessary amount in the initial stage of the contract.

The estimate information registration screen 1100
An estimate simulation screen 1101 for calculating the estimated amount of the product scheduled to be contracted;
A product description screen 1102 that displays a list of product codes, quantities, estimated amounts, etc. of the contracted products;
A trade-in statement screen 1103 that displays processing costs for trade-in of old-type equipment installed at the customer's office;
Expense details screen 1104 for displaying instruction fees for device operation,
And a maintenance details screen 1105 for displaying maintenance conditions and the like.

In the upper part of the estimate information registration screen 1100, menu items 1101a for performing various applications and examinations for creating a contract are displayed. Here, when the menu item 1101a is selected, an estimate display screen 1300 (see FIG. 12) is displayed.
Further, a menu item 1102a for adding / changing / deleting product details is displayed on the product detail screen 1102. Here, when the menu item 1102a is selected, a product basic edit screen 1300 (see FIG. 13) is displayed.

FIG. 12 is a display example of a quote display screen 1200 that transitions when the menu item 1101a on the estimate information registration screen 1100 is selected.
On the estimate sheet display screen 1200, a screen image of the estimate sheet is displayed in response to the contents input on the estimate information registration screen 1100.
In the estimate display screen 1200, the estimated amount column cannot be changed, but the installation location of the device, the company name of the customer, etc. can be changed. When these items are input, an estimate sheet (not shown) can be printed. The printed estimate is given to the customer.

FIG. 13 is a display example of the product basic editing screen 1300 that transitions when the menu item 1102a on the estimate information registration screen 1100 is selected.
Product basic edit screen 1300
A product description screen 1301 for displaying the name, number, etc. of the product to be contracted;
A maintenance details screen 1302 for displaying a maintenance contract for the product;
It includes an overhead statement screen 1303 for displaying an instruction fee for operating the device.
The product basic editing screen 1300 includes menu items 1301a and 1302a for changing product details and a menu item 1301b for changing the option configuration of the product.

When the menu item 1301a at the top of the product details screen 1301 or the menu item 1302a at the top of the maintenance details screen 1302 is selected, the screen transitions to the details addition screen 1304.
The item addition screen 1304 is a screen on which addition or deletion of products that can be configured on the item specification screen 1301 or the maintenance details screen 1302 is performed.
In this way, on the product basic editing screen 1300, it is possible to add, change, and delete products for which a contract is made one by one. The product input on the product basic edit screen 1300 is reflected on the estimate information registration screen 1100.
A sales contract 1400 and a hardware maintenance contract 1500 are created in response to the input contents of the product basic edit screen 1300. However, the sales contract 1400 is a contract created when no maintenance contract is made. The hardware maintenance contract 1500 is a contract created when receiving a maintenance service associated with a product to be bought and sold.

FIG. 14 is a configuration example of the sales contract 1400.
As shown in the pattern table 1401, the sales contract 1400 includes three parts: a cover part 1402a, a basic clause part 1402b, and a contract fee part 1402c.
In addition, since the maintenance work does not occur only by buying and selling the cover part 14a and the device, the service clause part and the maintenance target detailed part are not necessary.

FIG. 15 is a configuration example of the hardware maintenance contract 1500.
As shown in the pattern table 1501, the hardware maintenance contract 1500 includes five parts: a cover part 1502a, a basic provision part 1502b, a service provision part 1502c, a contract fee part 1502d, and a maintenance target detail part 1502e.
The hardware maintenance contract includes purchased and sold equipment and contents for maintaining the equipment.

FIG. 16 is a display example of an option selection screen 1600 and a performance service selection screen 1610 that transition when the menu item 1301b of the product basic editing screen 1300 is selected. The performance refers to a service associated with the product, and the service is identified from the service basic information table 313 by the service code.
The option selection screen 1600 is a screen for selecting an option associated with the contracted product. For example, when an image forming apparatus is contracted, a sorter attached to the image forming apparatus, a service pack with a maintenance contract, and the like are selected.
The performance service selection screen 1610 is a screen for selecting a time zone for accepting maintenance and accepting means (Tel, Fax, etc.) when a service pack of a maintenance contract is selected.

  By selecting input items on the option selection screen 1600 and the performance service selection screen 1610, a performance contract is created.

FIG. 17 is a configuration example of a performance contract.
As shown in the pattern table 1701, the hardware maintenance contract 1700 includes three parts: a cover part 1702a, a basic provision part 1702b, and a service provision part 1702c.
The performance contract is a billing contract for each performance in addition to the basic fee, and these billing contents are included in the service clause part 16c. For this reason, contract fee parts and maintenance target detail parts are not required.

  According to the present embodiment described above, the contract is created by combining the necessary templates for the contract simply by clarifying the contents of the negotiation using the contract creation screen. In this way, it is possible to find the optimal clauses and combinations of clauses and support the creation of a contract with the appropriate contract details, so even a sales person who is not familiar with the contract format, There is an effect that a contract in an appropriate format can be easily created.

  In addition, by issuing a sample contract at the time of estimation, the image of the contract can be shown to the customer. For this reason, the customer can easily understand the contents of the contract by describing the sample contract. In addition, since the contract is automatically generated, there is an effect that omission of description of the contract is reduced, and time and effort for checking the contents can be reduced.

  In addition, it is possible to issue a contract combining appropriate contract types in a state in which it is checked whether the combination of contract types is appropriate. For this reason, there is an effect that customer satisfaction is improved and business efficiency is promoted.

  In addition, a contract image file obtained by optically reading a contract created for each contract ID and contract type ID is stored. As a result, the contract can be managed with data. For this reason, compared with the case where the contract is managed in writing, it is not necessary to secure a storage space, and the search efficiency of the contract is improved.

  Note that the customer-related information, the contract template, and the like may be stored in the client PC so that the contract created on the spot may be presented to the customer when visiting the customer's office.

  The embodiment of the present invention has been described above. However, the present invention is not limited to the above-described embodiment, and other modifications may be made without departing from the gist of the present invention described in the claims. It goes without saying that application examples are included.

1 is a schematic diagram illustrating an entire device management system according to an embodiment of the present invention. It is a functional block diagram which shows the detail of a web server etc. and DB server. It is the schematic which extracted a part of field name of the table group contained in DB server. It is a block diagram which shows the example of a contract preparation support function among the apparatus management systems of this embodiment. It is a block diagram explaining the function of contract preparation cgi. It is a conceptual diagram which shows the relationship of the field of each table in DB server. It is a sequence diagram which shows the example of a contract creation process of a client PC and a contract creation web server. It is a flowchart which shows the example of a contract preparation process of a client PC. It is a flowchart which shows the example of a contract creation process of a contract creation web server. It is explanatory drawing which shows the structure and kind of each contract. It is explanatory drawing which shows an estimate information registration screen. It is explanatory drawing which shows a quote display screen. It is explanatory drawing which shows a goods basic edit screen. It is explanatory drawing which shows the structural example of a sales contract. It is explanatory drawing which shows the structural example of a hardware maintenance contract. It is explanatory drawing which shows an option selection screen and a performance service selection screen. It is explanatory drawing which shows the structural example of a performance contract.

Explanation of symbols

  DESCRIPTION OF SYMBOLS 101 ... Equipment management system, 102, 103 ... Web server, 104 ... DB server, 105, 106, 107 ... Client PC, 109 ... In-house LAN, 202 ... Web server program, 203 ... Employee authentication cgi, 302 ... Employee table , 303 ... customer company table, 304 ... customer staff table, 305 ... customer installation destination table, 306 ... negotiation table, 307 ... contract table, 308 ... negotiation contract table, 309 ... prohibition condition table, 310 ... deadline condition table, 311 ... Contract type table, 312 ... Product basic information table, 313 ... Service basic information table, 314 ... Contract product etc. table, 315 ... Product etc. configuration table, 316 ... Device management table, 317 ... Counter confirmation log table, 318 ... Contract Template table, 3 9 ... Contract type combination prohibition table, 401 ... Salesperson, 402 ... Contract creation web server, 404 ... Contract creation cgi, 502 ... Item selection section, 503 ... Contract creation section, 1100 ... Estimate information registration screen, 1200 ... Estimate display screen, 1300 ... Product basic editing screen, 1400 ... Sales contract, 1500 ... Hardware maintenance contract, 1600 ... Option selection screen, 1610 ... Performance service selection screen, 1700 ... Performance contract

Claims (6)

A customer company table that stores customer IDs that uniquely identify customers;
An opportunity table including an opportunity ID that uniquely identifies the contents of the opportunity,
A contract type table storing a contract type ID for identifying the contract type;
A contract template table in which a part code and a template code for uniquely identifying a template file having a predetermined format are stored;
Product basic information table that stores product codes that uniquely identify products,
For one or more contracts associated with one record in the negotiation table, a contract ID that uniquely identifies the contract, the contract type ID, the customer ID, the product code, the part code, and the template code are A stored contract table;
Select the negotiation ID, the customer ID, the contract type ID, and the product code, and record the contract information for creating a contract in the record of the contract table selected by specifying the contract ID. An item selection section to be
Based on the contract information specified by specifying the contract ID, the template file is read out from the contract template table, and the template file is combined to create a contract.
The contract creation unit issues the contract in a record stored in the contract table identified by the contract to be created and the contract ID when items necessary for the issuance of the contract are satisfied. A contract creation apparatus that records a number of times and creates a sample contract in which the number of times of issuance is not recorded when items necessary for issuance of the contract are not satisfied . Furthermore,
It has a basic service information table that stores service codes that uniquely identify service products,
The item selection unit selects a service code from the service basic information table, records contract information related to the service product in a record specified by specifying the contract ID,
The contract according to claim 1, wherein the contract creation unit reads the template file from the contract template table based on the service code, and creates a contract by combining the template files. Document creation device. An optical reading unit that optically reads the created contract and creates contract image data,
The contract table, characterized by recording the contract image data, contracts creating apparatus according to claim 1. The contract creation apparatus according to claim 3 , wherein the contract type includes a sales contract, a hardware maintenance contract, a kit contract, a spot contract, and a performance contract. The contract template table includes a cover, a basic clause, a service clause, a contract fee, and a maintenance target specification as basic parts, and a template file for the basic part is stored. 3. Contract creation apparatus according to 3 . Select the negotiation ID that uniquely identifies the negotiation contents, the customer ID that uniquely identifies the customer, the contract classification ID that identifies the contract classification, and the commodity code that uniquely identifies the commodity, and uniquely identify the negotiation contents. Recording contract information capable of creating a contract in a record of a contract table selected by specifying a contract ID that uniquely identifies the contract for a contract associated with one or more negotiation IDs;
Combining a template file having a predetermined format based on the contract information specified by specifying the contract ID, and creating a contract,
In the step of creating the contract, the items stored in the contract table specified by the contract to be created and the contract ID when the items necessary for issuing the contract are satisfied are recorded in the contract The contract creation method is characterized in that when the items necessary for issuance of the contract are not satisfied, a sample contract that does not record the number of issuance is created.

Images