WO2011055574A1 - 見積購買業務装置、見積購買業務方法及び見積購買業務プログラム - Google Patents

見積購買業務装置、見積購買業務方法及び見積購買業務プログラム Download PDF

Info

Publication number
WO2011055574A1
WO2011055574A1 PCT/JP2010/062597 JP2010062597W WO2011055574A1 WO 2011055574 A1 WO2011055574 A1 WO 2011055574A1 JP 2010062597 W JP2010062597 W JP 2010062597W WO 2011055574 A1 WO2011055574 A1 WO 2011055574A1
Authority
WO
WIPO (PCT)
Prior art keywords
purchasing
purchasing department
department
information indicating
category
Prior art date
Application number
PCT/JP2010/062597
Other languages
English (en)
French (fr)
Inventor
康信 杉浦
貴宏 吉田
信人 古賀
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Publication of WO2011055574A1 publication Critical patent/WO2011055574A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions

Definitions

  • the present invention relates to an estimated purchase business apparatus, an estimated purchase business method, and an estimated purchase business program.
  • Non-Patent Documents 2 and 3 There are also businesses that provide systems for companies that do not have such a purchase processing system and undertake estimation / purchase operations (for example, Non-Patent Documents 2 and 3).
  • Patent Document 1 cannot reduce the management cost by sharing a single system among a plurality of companies. Furthermore, with the technologies of Non-Patent Documents 1 and 2, other companies cannot request a quote from a company regarding a request related to the purchase of goods or services of a certain company. In addition, depending on the person in charge of purchasing goods and services, determine the scope of the department (internal or external) to request a quote from the supplier, and to other departments depending on the circumstances of the department once determined. , It is not possible to get a substitute for a request for a quote from a contractor.
  • the present invention can acquire a department that requests a quote from a contractor and other departments that can be substituted within a range that can be shared by a plurality of companies and determined according to the person in charge of the request.
  • An object of the present invention is to provide an estimate purchase business apparatus that can be used.
  • the estimate purchase business apparatus of the present invention is a request manager based on a category indicating whether or not a purchasing department has to be determined in the enterprise according to a requester and a classification code indicating a product or service related to the request.
  • the purchasing department to request a quotation is determined in and outside the company to which the person belongs.
  • another purchasing department that can replace the purchasing department is acquired for each request.
  • another purchasing department is acquired based on the priority order between the purchasing departments and the association between the purchasing department set in advance and the other purchasing department.
  • (B) is a figure which shows an example of the estimate request item confirmation screen which concerns on this embodiment.
  • (A) is a figure which shows an example of the estimation process screen (for substitution) which concerns on this embodiment.
  • (B) is a figure which shows an example of the estimation process screen (for confirmation) which concerns on this embodiment.
  • the estimated purchase business system 1 will be described with reference to FIG.
  • the estimated purchase business system 1 includes an estimated purchase business device 2 and a user terminal device 3, which are connected by a network 4.
  • the estimated purchase business apparatus 2 is a general computer and includes a central control device 11, a main storage device 12, an auxiliary storage device 13, a communication device 14, an input device 15, and an output device 16. These are connected to each other by a bus.
  • the auxiliary storage device 13 stores a user attribute master 31, a category code master 32, a purchasing department control master 33, a purchasing department attribute master 34, and estimate data 35 (details will be described later).
  • the login management unit 21, the purchasing department selection unit 22, the purchasing department setting control unit 23, and the purchasing department switching execution unit 24 are programs. Thereafter, when the subject is described as “XX section”, the central controller 11 reads out each program from the auxiliary storage device 13 and loads it into the main storage device 12, and then the function of each program (detailed later). Shall be realized.
  • the user terminal device 3 is a general computer, and includes a communication device 41, a central control device 42, a main storage device 43, an auxiliary storage device 44, an input device 45, and an output device 46. These are connected to each other by a bus.
  • FIG. 1 there are a plurality of companies, a plurality of business partners, and a single estimate purchasing business apparatus 2.
  • One or a plurality of user terminal devices 3 exist in each company and business partner, and a user (detailed later) can access the estimated purchase business device 2 via the user terminal device 3.
  • a company is a purchasing entity of goods or services (hereinafter sometimes simply referred to as “products”), and a business partner is an entity that sells products.
  • the enterprise has one or more “offices”, and the “office” further has one or more “departments”. Then, by specifying “enterprise”, “office” and “department”, one department is specified.
  • the person in charge of requesting goods and the person in charge of purchasing belong to one of the departments.
  • the sales person in charge of the product belongs to one of the business partners. These requesters, purchasers, and salespeople are collectively referred to as “users”.
  • the user operates the user terminal device 3.
  • a department to which a user who is a person in charge of purchase belongs is called a “purchasing department”.
  • the “purchasing department” is specified by a combination of “enterprise”, “office” and “department”.
  • the configuration is such that there is one estimated purchase business device 2.
  • the estimated purchase business device 2 may be divided into a plurality of cases. For example, there may be one or more devices that store programs and one or more devices that store a master or the like.
  • the user attribute master 31 will be described with reference to FIG.
  • a password is stored in the password field 102
  • a company code is stored in the company code field 103
  • a business office code is stored in the business office code field 104 in association with the user ID stored in the user ID field 101.
  • the part code column 105 stores a part code
  • the user authority column 106 stores a user authority
  • the purchaseable product group code column 107 stores a purchaseable product group code.
  • the user ID in the user ID column 101 is an identifier that uniquely identifies the user.
  • the user ID corresponds to “information indicating the person in charge of request” and “information indicating the person in charge of purchase”.
  • the password in the password field 102 is a personal identification password or number that is input when the user uses the user terminal device 3.
  • the company code in the company code column 103 is an identifier that uniquely identifies the company.
  • the “company information” corresponds to the company code.
  • the establishment code in the establishment code column 104 is an identifier that uniquely identifies the establishment within a certain company.
  • the department code in the department code column 105 is an identifier that uniquely identifies a department within a certain office.
  • the “information indicating the purchasing department” corresponds to a combination of the company code, the office code, and the department code.
  • the user authority in the user authority column 106 is a word indicating the authority given to the user.
  • “Requester” indicates that the user can make a request for purchasing a product (hereinafter, simply referred to as “request”) to a user who is a purchaser.
  • “Purchaser” indicates that the user can request a quote from the user who is the sales representative of the business partner in response to a request from the user who is the requester. It is also possible to provide a user authority of “sales representative”. In this case, the combination of “company code”, “business office code”, and “department code” specifies the department to which the user who is the sales representative at the business partner belongs. However, in this embodiment, it is assumed that the user authority is either “request person” or “purchaser person”.
  • the purchaseable product group code in the purchaseable product group code column 107 is an identifier that uniquely identifies a product or service group (purchasable product group) that can be requested by the requester.
  • the purchaseable product group may be a group indicating a user of the product, such as “inside the company”, “to the group”, and “outside the group”. Further, it may be a group indicating a place where the product is used, such as “factory supplies” and “office supplies”. That is, the contents of the group are not limited as long as the purchaseable product group is set so that one purchaseable product group is determined if the user is determined.
  • the purchaseable product group is set only for the user who is the person in charge of the request. In a company where personnel changes are drastic, one group of items that can be purchased may be determined for each combination of company code, office code, and department code (that is, for each department) (in this embodiment, it is set as such). (Fig. 2)).
  • a company whose company code is “COM-1” has one office, and its office code is “J-1”. Further, the one office has three parts, and the part codes thereof are “B-1”, “B-2”, and “B-3”. Eventually, a company whose company code is “COM-1” has three departments.
  • the category code master 32 will be described with reference to FIG.
  • a purchaseable product group name is stored in the purchaseable product group name column 112 and a category code is stored in the category code column 113 in association with the purchaseable product group code stored in the purchaseable product group code column 111.
  • a category name is stored in the category code master 32.
  • the purchaseable product group code in the purchaseable product group code column 111 is the same as the purchaseable product group code in FIG.
  • the purchaseable product group name in the purchaseable product group name column 112 is the name of the purchaseable product group described above.
  • the category code in the category code column 113 is an identifier that uniquely specifies information (category) indicating whether or not the purchasing department must be determined within the company to which the requester belongs. For example, there are two categories: “deployment within a company (tenant)” and “cross-company (tenant)”. Here, “deployment within a company (tenant)” indicates that a purchasing department must be determined within the company to which the requested department belongs. “Between companies (tenants)” indicates that a purchasing department can be determined regardless of the inside or outside of the company to which the requested department belongs.
  • the category name in the category name column 114 is the name of the category described above.
  • the following (1) and (2) can be understood from the entire records 181 to 183 in FIG. (1)
  • the purchasing department can be determined regardless of the inside / outside of the company to which the department that performed the transaction belongs (other companies may request a quotation from a business partner).
  • (2) When there is a request for in-house or group-oriented products (such as purchasing consumables used in-house or in a company in the capital line), within the company to which the department that made the request belongs The purchasing department must be determined.
  • the correspondence between the purchaseable product group (code) and the category (code) can be arbitrarily set. Further, in FIG.
  • the category (code) can also be set for each user who is a requester. Furthermore, the correspondence between the purchaseable product group (code) and the category (code) can also be set by changing with time.
  • the purchasing department control master 33 will be described with reference to FIG.
  • the category code field 121 has a category code
  • the classification code field 122 has a classification code
  • the inter-purchasing department priority field 123 has a category code.
  • the purchasing department company code field 124 the purchasing department company code field 125 is the purchasing department company code field 125
  • the purchasing department office code field 125 is the purchasing department department code field 126 is the purchasing department department code field.
  • subordinate purchasing department company code field 127 contains the subordinate purchasing department company code
  • subordinate purchasing department office code field 128 contains the subordinate purchasing department office code
  • subordinate purchasing department department code field 129 contains the subordinate purchasing department department code. Is remembered.
  • the rule ID in the rule ID column 120 is an identifier that uniquely identifies a record in the purchasing department control master 33.
  • the category code in the category code column 121 is the same as the category code in FIG.
  • the classification code in the classification code column 122 is information indicating a product or service to be purchased. This classification code is a concept different from the purchaseable product group and category, and is an item such as “safety shoes”, for example. Smaller items such as “boots” included in “safety shoes” and “size boots” included in “boots” may be used as the classification code. It is assumed that the user knows which classification code the product desired by the user corresponds to.
  • the classification code “@” indicates “all classification codes”.
  • the inter-purchasing department priority in the inter-purchasing department priority column 123 is a priority indicating which candidate is preferentially selected as a purchasing department among the purchasing department candidates.
  • a plurality of purchasing departments may fall under the processing of searching the purchasing department control master 33 using the category code and the classification code as a search key.
  • a purchasing department with a higher priority small number is selected with priority over other purchasing departments (details will be described later).
  • the rules for setting the order of priority among purchasing departments differ depending on the category code. In the case of the category code “MC-1”, the category code, the classification code, and the purchasing department company code are set as 1, 2, 3,. In the case of the category code “MC-2”, the records are set as 1, 2, 3,...
  • the purchasing department company code in the purchasing department company code column 124 is a company code of a company to which a department that can be a purchasing department belongs.
  • the purchasing department establishment code in the purchasing department establishment code column 125 is an establishment code of an establishment to which a department that can be a purchasing department belongs.
  • the purchasing department department code in the purchasing department department code column 126 is a department code of a department to which a department that can be a purchasing department belongs.
  • the subordinate purchasing department company code in the subordinate purchasing department company code column 127 is a company code of a company to which a department that can become a subordinate purchasing department (immediately described later) belongs.
  • the subordinate purchasing department office code in the subordinate purchasing department office code column 128 is an office code of an office to which a department that can become a subordinate purchasing department belongs.
  • the subordinate purchasing department part code in the subordinate purchasing department part code column 129 is a department code of a department to which a department that can become a subordinate purchasing department belongs.
  • a candidate in a purchasing department (when the company cannot become a purchasing department due to lack of know-how, etc.) and requests a quotation from a business partner in place of another purchasing department candidate Can be entrusted.
  • An alternative purchasing department is called a “subordinate purchasing department”.
  • When setting a subordinate purchasing department for a certain purchasing department it is not necessary to consider the priority order between purchasing departments. However, for the sake of simplification, in this embodiment, if the priority of a certain purchasing department is “p”, the sub-purchasing department priority of the subordinate purchasing department is set to “p ⁇ 1”. .
  • the subordinate purchasing department company code in the column 127, the subordinate purchasing department establishment code in the column 128, and the subordinate purchasing department department code in the column 129 are set to records whose inter-purchasing department priority in the column 123 is larger than “1”. Yes.
  • One subordinate purchasing department is defined for each purchasing department. That is, for each purchasing department, “which purchasing department can be replaced by itself to become a purchasing department” is defined.
  • all records in the purchasing department control master 33 are searched using the category code “MC-1”, the classification code “CL-1”, and the purchasing department company code “COM-1” as search keys.
  • the record 192 is naturally applicable.
  • the classification code “@” stored in the classification code column 122 of the record 191 indicates “all classification codes” as described above, and is equivalent to being stored as “CL-1”. To do.
  • a department identified by a combination of a purchasing department company code, a purchasing department establishment code, and a purchasing department department code in these records is a candidate that can be a purchasing department.
  • the purchasing department identified by the combination of “COM-1”, “J-1” and “B-1”, and “COM-1”, “J-2” and “B-1” Two of the purchasing departments identified by the combination are candidates.
  • the purchasing department specified by the combination of “COM-1”, “J-1” and “B-1” is selected. If the purchasing department cannot be a purchasing department for some reason, the purchasing department specified by the combination of “COM-1”, “J-2” and “B-1” can be substituted for itself. Can be entrusted to become a purchasing department. This is because “COM-1”, “J-1”, and “B-1” are stored in the columns 127 to 129 of the record 192.
  • all records in the purchasing department control master 33 are searched using the category code “MC-1”, the classification code “CL-3”, and the purchasing department company code “COM-1” as search keys.
  • the record 194 and the record 195 are naturally applicable.
  • the classification code “@” stored in the classification code column 122 of the record 191 indicates “all classification codes” as described above, and is equivalent to being stored as “CL-3”. To do.
  • a purchasing department specified by a combination of “COM-1”, “J-1”, and “B-1” is selected. If the purchasing department cannot be a purchasing department for some reason, the purchasing department specified by the combination of “COM-1”, “J-4” and “B-1” can be substituted for itself. Can be entrusted to become a purchasing department. This is because “COM-1”, “J-1”, and “B-1” are stored in the columns 127 to 129 of the record 194. On the other hand, it is assumed that a purchasing department specified by a combination of “COM-1”, “J-5”, and “B-1” is selected. If the purchasing department cannot be a purchasing department for some reason, it cannot be entrusted to another purchasing department instead of becoming a purchasing department. This is because neither the record 191 nor the record 194 stores “COM-1”, “J-5”, and “B-1” in the columns 127 to 129.
  • all records in the purchasing department control master 33 are searched using the category code “MC-2” and the classification code “CL-1” as search keys.
  • the record 196, the record 197, and the record 198 correspond. This is because the code “@” stored in the classification code column 122 of the record 196, the record 197, and the record 198 indicates “all classification codes” and is stored as “CL-1” as described above. It is.
  • the priority between the purchasing departments in the record 196 is “1”
  • the priority between the purchasing departments in the record 197 is “2”
  • the priority between the purchasing departments in the record 198 is “3”, which is higher.
  • a purchasing department specified by a combination of “COM-7”, “J-1”, and “B-1” in the record 196 having the purchasing department priority can be selected.
  • the purchasing department attribute master 34 will be described with reference to FIG.
  • the purchasing department attribute master 34 is associated with a combination of a purchasing department company code in the purchasing department company code field 132, a purchasing department office code in the purchasing department office code field 133, and a purchasing department part code in the purchasing department part code field 134.
  • the purchasing department company name column 135 is the purchasing department company name
  • the purchasing department office name column 136 is the purchasing department office name
  • the purchasing department department name column 137 is the purchasing department department name
  • the purchasing department manager name stores the names of persons in charge of purchasing departments.
  • the purchasing department company code in the purchasing department company code column 132 is the same as the purchasing department company code in FIG.
  • the purchasing department office code in the purchasing department office code column 133 is the same as the purchasing department office code in FIG.
  • the purchasing department part code in the purchasing department part code column 134 is the same as the purchasing department part code in FIG.
  • the purchasing department company name in the purchasing department company name column 135 is the name of the company to which the purchasing department belongs.
  • the purchasing department establishment name in the purchasing department establishment name column 136 is the name of the establishment to which the purchasing department belongs.
  • the purchasing department establishment name in the purchasing department name column 137 is the name of the department to which the purchasing department belongs.
  • the purchasing department manager name in the purchasing department manager name field 138 is the name of the purchasing manager in the purchasing department.
  • the company name of the purchasing department specified by the combination of the company code “COM-1”, the business office code “J-1”, and the department code “B-1” is “Company 1”.
  • the establishment name is “establishment 1”, the department name is “department 1”, and the person in charge is “in charge A”.
  • This example was given for the sake of simplicity, but in reality, existing proper nouns such as “XX Corporation”, “Tokyo Office”, “Procurement Department”, and “Ichiro Tanaka” are stored. Will be.
  • the estimate data 35 will be described with reference to FIG.
  • the estimated data 35 is associated with the estimated ID stored in the estimated ID field 141, the requested user ID field 142 is the requested user ID, the classification code field 143 is the classification code, and the product name field 144 is the product name.
  • the desired quantity column 145 has a desired quantity
  • the unit field 146 has a unit
  • the desired delivery date field 147 has a desired delivery date
  • the rule ID field 148 has a rule ID
  • the purchasing department company code field 149 has a purchasing department.
  • the company code is stored in the purchasing department office code column 150, and the purchasing department department code column 151 stores the purchasing department department code.
  • the estimate ID in the estimate ID column 141 is an identifier that uniquely identifies a request from the person in charge of the request.
  • the requested user ID in the requested user ID column 142 is the user ID of the user who made the request.
  • the classification code in the classification code column 143 is the same as the classification code in FIG.
  • the product name in the product name column 144 is the name of the product related to the request.
  • the desired quantity in the desired quantity column 145 is the quantity of the product related to the request.
  • the unit in the unit column 146 is a unit of the desired quantity.
  • the desired delivery date in the desired delivery date column 147 is a date indicating the delivery deadline of the requested product.
  • the rule ID in the rule ID column 148 is the same as the rule ID in FIG.
  • the purchasing department company code in the purchasing department company code column 149 is the same as the purchasing department company code in FIG.
  • the purchasing department establishment code in the purchasing department establishment code column 150 is the same as the purchasing department establishment code in FIG.
  • the purchasing department code in the purchasing department code field 151 is the same as the purchasing department code in FIG.
  • One record of the estimate data 35 corresponds to one request from a requester.
  • a user whose requested user ID is “U0001” made a request to purchase “10 books” “test estimate request file” by “20091010”;
  • the classification code including the product name “test estimate request file” is “CL-1”.
  • the purchasing department that requests a quote from a business partner is a department identified by the combination of “COM-1”, “J-1”, and “B-1”.
  • the purchasing department is determined based on the record of the purchasing department control master 33 whose rule ID is “R001”. In this way, the estimate data 35 stores the purchase department in association with each request.
  • the processing procedure includes a request processing procedure for determining purchasing department candidates in response to a request from a requester, and a purchaser determines a request for which a quote should be requested, and substitutes itself as necessary. There is an estimate processing procedure for final determination of other purchasing departments.
  • the estimation processing procedure is executed on the assumption that at least one record of the estimation data 35 is created as a result of the request processing procedure being executed at least once.
  • step S ⁇ b> 301 the login management unit 21 of the estimated purchase business device 2 accepts login. Specifically, the login management unit 21 first displays a login screen (not shown) on the output device 46 of the user terminal device 3 and accepts that the user inputs a user ID and a password. Second, the login management unit 21 confirms that a record having the received combination of user ID and password exists in the user attribute master 31. When the existence cannot be confirmed, a message such as “password is wrong” is returned to the user terminal device 3 to prompt re-input. Third, the user attribute master 31 is searched using the received user ID as a search key, and the company code, user authority, and purchaseable product group code of the corresponding record are acquired.
  • step S302 the login management unit 21 determines whether or not the user authority is “request person”. Specifically, when the user authority acquired in step S301 is “request person” (step S302 “YES”), the login management unit 21 proceeds to step S303. In other cases (step S302 “NO”), the process proceeds to step S304.
  • step S ⁇ b> 303 the purchasing department selection unit 22 of the estimated purchase business device 2 transmits a request menu screen (not shown) to the user terminal device 3.
  • step S ⁇ b> 304 the purchasing department selection unit 22 transmits an error message to the user terminal device 3.
  • the error message may be something like "I don't have authority to request".
  • the request processing procedure is terminated.
  • a program that displays a button for guiding to another process for example, “estimation process procedure” described later
  • the request processing procedure itself may be terminated.
  • step S305 the purchasing department selection unit 22 receives a classification code and the like. Specifically, the purchasing department selection unit 22 first accepts that the user presses an “execution request” button (not shown) on the request menu screen. Second, an estimate request item creation screen 51 (FIG. 9A) is displayed on the output device 46 of the user terminal device 3. Third, the user accepts input of a classification code, a product name, a desired quantity, a unit, and a desired delivery date on the estimate request item creation screen 51. It is assumed that when the user presses the “estimate request creation” button 61, these input data are transmitted from the user terminal device 3 to the estimate purchase business device 2.
  • the classification code and unit a plurality of options may be displayed in the selection boxes 62 and 63, and one of the options may be selected by the user. Further, the purchasing department selection unit 22 may confirm whether or not the correspondence between the input product name and the classification code is correct. In this case, it is assumed that a table indicating the correspondence between the product name and the classification code is stored in the auxiliary storage device 13.
  • the purchasing department selection unit 22 acquires purchasing department candidates. Specifically, the purchasing department selection unit 22 first searches the category code master 32 using the purchaseable product group code acquired in step S301 as a search key, and acquires the category code of the corresponding record. Second, the purchase department control master 33 is searched using the acquired category code and the classification code received in step 305 as a search key, and all corresponding records are acquired. Third, if the category code acquired in “first” is “MC-1”, the record acquired in “second” is stored in the purchasing department company code column 124 with the company code acquired in step S301. Filter to records you have. If the category code acquired in “first” is “MC-2”, no narrowing is performed. Fourth, from the record acquired in “Second”, or when the narrowing is performed in “Third”, the record having the lowest number of priorities among purchasing departments is acquired from the narrowed-down record. .
  • step S307 the purchasing department selection unit 22 presents a purchasing department. Specifically, the purchasing department selection unit 22 firstly acquires the category code, the purchasing department company code, the purchasing department office code, and the purchasing of the record of the purchasing department control master 33 acquired in “fourth” of step S306. Get department code. Second, using the combination of the acquired purchasing department company code, purchasing department office code and purchasing department department code as a search key, the purchasing department attribute master 34 is searched, and the purchasing department company name and purchasing department office of the corresponding record are searched. Name, purchasing department name, and purchasing department manager name. Third, the estimate ID is numbered. Fourth, an estimate request item confirmation screen 52 (FIG. 9B) is displayed on the output device 46 of the user terminal device 3.
  • the quotation ID and the data input by the user to the quotation request item creation screen 51 are displayed.
  • the “purchasing department information” 65 displays the purchasing department company name, the purchasing department establishment name, the purchasing department department name, and the purchasing department manager name acquired in “second”. The user confirms the purchasing department information 65. Fifth, it accepts that the user presses the “estimate request confirmation” button 72.
  • step S308 the purchasing department selection unit 22 creates a record of the estimate data 35. Specifically, the purchasing department selection unit 22 first creates a new record of the estimate data 35. Second, the estimate ID numbered in step S307 is stored in the estimate ID column 141 of the new record, and the user ID received in step S301 is stored in the request user ID column 142. Third, the classification code, product name, desired quantity, unit, and desired delivery date received in step S305 are stored in the classification code field 143, the product name field 144, the desired quantity field 145, the unit field 146, and the desired delivery date field 147, respectively. To do.
  • the rule ID of the record of the purchasing department control master 33 acquired in “fourth” of step S306 is stored in the rule ID column 148.
  • the purchasing department company code, the purchasing department office code, and the purchase acquired in the “first” of step S307 are added to the purchasing department company code field 149, the purchasing department office code field 150, and the purchasing department department code field 151. Each department code is stored. Thereafter, the request processing procedure is terminated.
  • step S401 the login management unit 21 of the estimated purchase transaction apparatus 2 accepts a login. Specifically, the login management unit 21 first displays a login screen (not shown) on the output device 46 of the user terminal device 3 and accepts that the user inputs a user ID and a password. Second, the login management unit 21 confirms that a record having the received combination of user ID and password exists in the user attribute master 31. When the existence cannot be confirmed, a message such as “password is wrong” is returned to the user terminal device 3 to prompt re-input. Thirdly, the user attribute master 31 is searched using the received user ID as a search key, and the company code, establishment code, department code, and user authority of the corresponding record are acquired.
  • step S ⁇ b> 402 the login management unit 21 determines whether the user authority is “purchaser”. Specifically, when the user authority acquired in step S401 is “purchaser” (step S402 “YES”), the login management unit 21 proceeds to step S403. In other cases (step S402 “NO”), the process proceeds to step S404.
  • step S403 the purchasing department setting control unit 23 of the estimated purchasing business apparatus 2 transmits a purchasing menu screen (not shown) to the user terminal apparatus 3.
  • step S ⁇ b> 404 the purchasing department setting control unit 23 transmits an error message to the user terminal device 3.
  • the error message may be, for example, “You do not have the authority to purchase”.
  • the estimation processing procedure is terminated.
  • a program that displays a button that leads to another process for example, the “request processing procedure” described above
  • the estimation processing procedure itself may be terminated.
  • step S405 the purchasing department setting control unit 23 acquires a record of the estimate data 35. Specifically, the purchasing department setting control unit 23 first searches the estimate data 35 using the combination of the company code, the office code, and the department code acquired in step S401 as a search key, and finds all corresponding records. get.
  • step S406 the purchasing department setting control unit 23 accepts selection of a record of the estimate data 35 to be processed. Specifically, the purchasing department setting control unit 23 first displays a screen (quotation request item list screen (not shown)) for displaying all the records acquired in step S405 on the output device 46 of the user terminal device 3. To display. Second, it accepts that the user selects one arbitrary record from the estimate request item list screen. Assume that a table similar to the configuration of the estimate data 35 is displayed on the estimate request item list screen. Then, for example, the user selects an arbitrary part of an arbitrary record with the input device 45 such as a mouse.
  • the input device 45 such as a mouse.
  • step S407 the purchasing department setting control unit 23 acquires candidates for purchasing departments that can be substituted. Specifically, the purchasing department setting control unit 23 firstly uses the rule ID of the record of the estimate data 35 selected in step S406 (hereinafter may be referred to as “processing target record”) as a search key as a purchasing department. The control master 33 is searched and the corresponding record is acquired (the acquired record may be hereinafter referred to as “reference record”).
  • processing target record the rule ID of the record of the estimate data 35 selected in step S406
  • the control master 33 is searched and the corresponding record is acquired (the acquired record may be hereinafter referred to as “reference record”).
  • processing is performed by dividing into cases as follows.
  • the category code of the reference record is “MC-1”
  • records satisfying the following conditions are extracted from the records in the purchasing department control master 33 at the same time.
  • -The purchasing department company code is the purchasing department company code in the standard record.
  • -The classification code is the classification code of the record to be processed.
  • the subordinate purchasing department company code, subordinate purchasing department establishment code, and subordinate purchasing department department code are the purchasing department company code, purchasing department establishment code, and purchasing department department code of the standard record, respectively.
  • step S408 the purchasing department setting control unit 23 determines whether there are a plurality of alternative purchasing department candidates that can be substituted. Specifically, the purchasing department setting control unit 23 determines that there are a plurality of combinations of the purchasing department company code, the purchasing department establishment code, and the purchasing department department code acquired in “third” in step S407 (step S408 “YES”). ) Proceeds to step S409. In other cases (step S408 “NO”), the process proceeds to step S410. Note that at least one combination exists.
  • step S409 the purchasing department setting control unit 23 accepts selection of an alternative purchasing department. Specifically, the purchasing department setting control unit 23 first displays an estimation processing screen (for replacement) 53 (FIG. 10A) on the output device 46 of the user terminal device 3. In the estimate request information 66 on the estimate process screen (for replacement) 53, the estimate ID, product name, and classification code of the record to be processed are displayed. Second, the purchasing department attribute master 34 is searched using the combination of the purchasing department company code, the purchasing department office code, and the purchasing department department code acquired in “third” in step S407, and the purchase of the corresponding record. Get a combination of department company name, purchasing department establishment name, and purchasing department department name. There are a plurality of such combinations.
  • step S410 the purchasing department setting control unit 23 accepts confirmation of alternative purchasing departments. Specifically, the purchasing department setting control unit 23 first displays an estimate processing screen (for confirmation) 54 (FIG. 10B) on the output device 46 of the user terminal device 3. The estimate request information 70 on the estimate process screen (for confirmation) 54 displays the estimate ID, product name, and classification code of the record to be processed. Second, it accepts that the user presses a “quote request from supplier” button 71.
  • step S411 the purchasing department switching execution unit 24 of the estimated purchasing business apparatus 2 updates the estimated data 35. Specifically, when the purchase department switching execution unit 24 accepts that the “request processing” button 68 is pressed in step S409, first, the purchase department company name, the purchase department, The purchasing department attribute master 34 is searched by using the combination of the business office name and the purchasing department department name as a search key, and the purchasing department company code, purchasing department office code, and purchasing department department code of the corresponding record are acquired. Second, the purchasing department company code, the purchasing department establishment code, and the purchasing department department code of the processing target record are respectively set to the purchasing department company code, the purchasing department establishment code, and the purchasing department department code acquired in “First”. Update. If it is accepted in step S409 or step S410 that the “quote request from supplier” buttons 69 and 71 are pressed, nothing is done. Thereafter, the estimation processing procedure is terminated.
  • a requester and a purchaser can share one estimate purchase business system across a plurality of companies, and the same department is purchased for each requester who makes a request. It can be determined whether or not to ask for. Further, the purchasing department can entrust a request for quotation to another purchasing department when it does not have the purchasing know-how. Therefore, it is possible to easily improve the efficiency of estimate purchase operations, accumulate know-how for purchase, and check the inside.
  • step S306 the record of the purchasing department control master 33 having the lowest purchasing department priority is acquired.
  • it is also possible to acquire all the records whose purchase department priority is “1 + m (m 1, 2, 3,...)” Or less.
  • a plurality of purchasing department candidates are acquired, and the processing in steps S307 and S308 is performed for a plurality of purchasing departments.
  • the “second” processing in step S407 may be changed as follows.
  • processing is performed by dividing into cases as follows.
  • (1) When the category code of the reference record is “MC-1”, records satisfying the following conditions are extracted from the records in the purchasing department control master 33 at the same time.
  • -The purchasing department company code is the purchasing department company code in the standard record.
  • -The classification code is the classification code of the record to be processed.
  • the purchasing department company code, purchasing department establishment code, and purchasing department department code are the subordinate purchasing department company code, subordinate purchasing department establishment code, and subordinate purchasing department department code of the standard record, respectively.
  • the present invention is not limited to the above-described embodiment, and can be modified without departing from the gist of the present invention.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

【解決手段】本発明の見積購買業務装置（２）は、要求担当者に応じて購買部門を企業内部で決定しなければならないか否かを示すカテゴリ及び、要求に係る商品又はサービスを示す分類コードに基づいて、要求担当者が属する企業内外において、見積を依頼する購買部門を決定する。　また、カテゴリ、分類コード及び購買部門に基づいて、要求毎に、購買部門に代替し得る他の購買部門を取得する。この際、購買部門間の優先順位及び予め設定された購買部門と他の購買部門との関連付けに基づいて、他の購買部門を取得する。

Description

見積購買業務装置、見積購買業務方法及び見積購買業務プログラム
　本発明は、見積購買業務装置、見積購買業務方法及び見積購買業務プログラムに関する。
　企業が、商品、サービス等を購買する場合、効率化、購買ノウハウの蓄積、内部牽制等を目的として、商品やサービスの購買に係る要求を行う部署と、その要求に係る商品やサービスについて、実際に業者に対して見積を依頼する部署とを別組織とすることが多い。
　このような企業内での区別を前提とした購買処理システムの例として特許文献１の技術が開示されている。特許文献１の技術では、「申請者」から商品購買の要求を受けた「資材」部署が、商品の販売業者である「取引先」へ見積依頼を行う。そして、ある「資材」部署は、より多くの購買ノウハウを有する他の「資材」部署に対して、「取引先」への見積依頼を代替して行ってもらうことができる。
　また、このような購買処理システムを有さない企業向けに、システムを提供し、見積・購買業務を請け負うビジネスも存在する（例えば、非特許文献２、３）。
特開２００３－１０８８２６号公報（請求項４等）
住友電工情報システム株式会社、"楽々ProcurementII"、[online]、[平成２１年９月２４日検索]、インターネット<URL:http://www.sei-info.co.jp/products/products_pro_k.html> ソフトバンクＢＢ株式会社、"間接材購買サービスPurchase One"、[online]、[平成２１年９月２４日検索]、インターネット<URL:http://www.softbankbb.co.jp/distribution/purchaseone/index.html>
　しかしながら、特許文献１の技術では、複数の企業で１つのシステムを共有し、管理コストを軽減することはできない。さらに、非特許文献１、２の技術では、ある企業の商品やサービスの購買に係る要求について、他の企業が業者に対して見積を依頼することはできない。さらに、商品やサービスの購買に係る要求担当者に応じて、業者に対して見積を依頼する部署の範囲（社内又は社外）を決定すること、一旦決定された部署の都合により、他の部署に、業者に対する見積の依頼を代替してもらうことはできない。
　そこで、本発明は、複数の企業が共同利用することが可能であって、要求担当者に応じて決定される範囲内で、業者に対し見積を依頼する部署及び代替し得る他の部署を取得することができる見積購買業務装置等を提供することを目的とする。
　本発明の見積購買業務装置は、要求担当者に応じて購買部門を企業内部で決定しなければならないか否かを示すカテゴリ及び、要求に係る商品又はサービスを示す分類コードに基づいて、要求担当者が属する企業内外において、見積を依頼する購買部門を決定する。
　また、カテゴリ、分類コード及び購買部門に基づいて、要求毎に、購買部門に代替し得る他の購買部門を取得する。この際、購買部門間の優先順位及び予め設定された購買部門と他の購買部門との関連付けに基づいて、他の購買部門を取得する。
　本発明によれば、複数の企業が共同利用することが可能であって、要求担当者に応じて決定される範囲内で、業者に対し見積を依頼する部署及び代替し得る他の部署を取得することができる見積購買業務装置等を提供することが可能になる。
本実施形態に係る見積購買業務システムの構成図である。 本実施形態に係るユーザ属性マスタの一例を示す図である。 本実施形態に係るカテゴリコードマスタの一例を示す図である。 本実施形態に係る購買部門制御マスタの一例を示す図である。 本実施形態に係る購買部門属性マスタの一例を示す図である。 本実施形態に係る見積データの一例を示す図である。 本実施形態に係る要求処理手順のフローチャートである。 本実施形態に係る見積処理手順のフローチャートである。 （ａ）は、本実施形態に係る見積依頼案件作成画面の一例を示す図である。（ｂ）は、本実施形態に係る見積依頼案件確認画面の一例を示す図である。 （ａ）は、本実施形態に係る見積処理画面（代替用）の一例を示す図である。（ｂ）は、本実施形態に係る見積処理画面（確認用）の一例を示す図である。
　以降、本発明を実施するための形態（「本実施形態」という）を、図等を参照しながら詳細に説明する。
　（見積購買業務システム）
　図１に沿って、見積購買業務システム１を説明する。
　見積購買業務システム１は、見積購買業務装置２及びユーザ端末装置３を有し、これらは、ネットワーク４によって接続されている。
　見積購買業務装置２は、一般的なコンピュータであり、中央制御装置１１、主記憶装置１２、補助記憶装置１３、通信装置１４、入力装置１５及び出力装置１６を有する。これらはバスによって相互に接続されている。
　補助記憶装置１３は、ユーザ属性マスタ３１、カテゴリコードマスタ３２、購買部門制御マスタ３３、購買部門属性マスタ３４及び見積データ３５（詳細後記）を格納している。
　ログイン管理部２１及び購買部門選択部２２、購買部門設定制御部２３及び購買部門切替実行部２４はプログラムである。以降、「○○部は」と主体を記した場合は、中央制御装置１１が、補助記憶装置１３から各プログラムを読み出し、主記憶装置１２にロードしたうえで、各プログラムの機能（詳細後記）を実現するものとする。
　ユーザ端末装置３は、一般的なコンピュータであり、通信装置４１、中央制御装置４２、主記憶装置４３、補助記憶装置４４、入力装置４５及び出力装置４６を有している。これらはバスによって相互に接続されている。
　図１の実施形態においては、複数の企業、複数の取引先及び１つの見積購買業務装置２が存在する。それぞれの企業及び取引先内には、１又は複数のユーザ端末装置３が存在し、ユーザ（詳細後記）は、ユーザ端末装置３を介して、見積購買業務装置２にアクセス可能である。
　企業とは、商品又はサービス（以降纏めて単に「商品」ということがある）の購買主体であり、取引先とは商品の販売主体である。
　企業は、１又は複数の「事業所」を有しており、「事業所」はさらに１又は複数の「部」を有している。そして、「企業」、「事業所」及び「部」を特定することによって、１つの部署が特定される。
　商品の要求担当者及び購買担当者は、いずれかの部署に所属することになる。商品の販売担当者は、いずれかの取引先に所属することになる。これらの要求担当者、購買担当者及び販売担当者を、まとめて「ユーザ」という。ユーザは、ユーザ端末装置３を操作する。そして、購買担当者であるユーザが所属する部署を「購買部門」と言う。「購買部門」は、「企業」、「事業所」及び「部」の組合せにより特定される。
　図１では、見積購買業務装置２が１台存在する構成とした。しかしながら、見積購買業務装置２は、複数の筐体に分かれた構成であってもよい。例えば、プログラムを格納する１又は複数の装置と、マスタ等を格納する１又は複数の装置が存在するものとしてもよい。
（ユーザ属性マスタ）
　図２に沿ってユーザ属性マスタ３１を説明する。
　ユーザ属性マスタ３１には、ユーザＩＤ欄１０１に記憶されたユーザＩＤに関連付けて、パスワード欄１０２にはパスワードが、企業コード欄１０３には企業コードが、事業所コード欄１０４には事業所コードが、部コード欄１０５には部コードが、ユーザ権限欄１０６にはユーザ権限が、購買可能品グループコード欄１０７には購買可能品グループコードが、記憶されている。
　ユーザＩＤ欄１０１のユーザＩＤは、ユーザを一意に特定する識別子である。「要求担当者を示す情報」及び「購買担当者を示す情報」には、当該ユーザＩＤが相当する。
　パスワード欄１０２のパスワードは、ユーザが、ユーザ端末装置３を使用する際に入力する本人認証用の暗証文字又は数字である。
　企業コード欄１０３の企業コードは、企業を一意に特定する識別子である。「企業を示す情報」には、当該企業コードが相当する。
　事業所コード欄１０４の事業所コードは、ある企業内において、事業所を一意に特定する識別子である。
　部コード欄１０５の部コードは、ある事業所内において、部を一意に特定する識別子である。
　「購買部門を示す情報」には、当該企業コード、事業所コード及び部コードの組合せが相当する。
　ユーザ権限欄１０６のユーザ権限は、ユーザに与えられた権限を示す語である。
　「要求担当者」は、そのユーザが、購買担当者であるユーザに対して、商品を購買して欲しいという要求（以下単に「要求」ということがある）を行えることを示す。
　「購買担当者」は、そのユーザが、要求担当者であるユーザからの要求に応じて、取引先の販売担当者であるユーザに対して、見積を依頼できることを示す。
　なお「販売担当者」というユーザ権限を設けることも可能である。この場合、「企業コード」、「事業所コード」及び「部コード」の組合せは、取引先での販売担当者であるユーザが所属する部署を特定することになる。しかしながら、本実施形態では、ユーザ権限は「要求担当者」及び「購買担当者」のいずれかであるものとする。
　購買可能品グループコード欄１０７の購買可能品グループコードは、要求担当者による前記要求が可能な商品又はサービスのグループ（購買可能品グループ）を一意に特定する識別子である。
　購買可能品グループは、例えば、「社内向け」、「グループ向け」及び「グループ外向け」のように、その商品の使用者を示すグループであってもよい。また、「工場用品」及び「事務所用品」のように、その商品の使用場所を示すグループであってもよい。つまり、購買可能品グループは、ユーザが決定されれば１つの購買可能品グループが決定されるように設定されているものであれば、グループの内容そのものは限定されない。そして、購買可能品グループは、要求担当者であるユーザに対してのみ設定されるものとする。
　なお、人事異動の激しい企業などでは、企業コード、事業所コード及び部コードの組合せ毎（すなわち部署毎）に１つの購買可能品グループが決まるようにしてもよい（本実施形態ではそのように設定している（図２））。
　まず、図２の行１６１～１６８に注目する。
　企業コードが「ＣＯＭ－１」である企業は、１つの事業所を有しており、その事業所コードは「Ｊ－１」である。さらにその１つの事業所は、３つの部を有しており、それらの部コードは、「Ｂ－１」、「Ｂ－２」及び「Ｂ－３」である。
　結局、企業コードが「ＣＯＭ－１」である企業は、３つの部署を有していることになる。
　「ＣＯＭ－１」、「Ｊ－１」及び「Ｂ－１」の組合せで特定される部署には、ユーザが４人所属しており、それらのユーザＩＤは、「Ｕ０００１」、「Ｕ０００２」、「Ｕ０００３」及び「Ｕ０００４」である。
　ユーザＩＤが「Ｕ０００１」、「Ｕ０００２」及び「Ｕ０００３」であるユーザのユーザ権限は「要求担当者」であり、購買可能品グループコードは「Ｇ－１」である。ユーザＩＤが「Ｕ０００４」であるユーザのユーザ権限は「購買担当者」であり、購買可能品グループコードは設定されていない。すなわち、当該部署は、「購買担当者」であるユーザと「要求担当者」であるユーザを両方有している。
　「ＣＯＭ－１」、「Ｊ－１」及び「Ｂ－２」の組合せで特定される部署には、ユーザが２人所属しており、それらのユーザＩＤは、「Ｕ０００５」及び「Ｕ０００６」である。
　ユーザＩＤが「Ｕ０００５」及び「Ｕ０００６」であるユーザのユーザ権限は「要求担当者」であり、購買可能品グループコードは「Ｇ－２」である。当該部署には、「購買担当者」であるユーザは存在しない。
　「ＣＯＭ－１」、「Ｊ－１」及び「Ｂ－３」の組合せで特定される部署には、ユーザが２人所属しており、それらのユーザＩＤは、「Ｕ０００７」及び「Ｕ０００８」である。
　ユーザＩＤが「Ｕ０００７」及び「Ｕ０００８」であるユーザのユーザ権限は「購買担当者」であり、購買可能品グループコードは設定されていない。当該部署には、「要求担当者」であるユーザは存在しない。
　次に、図２の行１６９～１７２に注目する。詳細な説明は、前記と同様なので省略するが、ここで重要なことは、企業コードが「ＣＯＭ－２」である企業は、企業コードが「ＣＯＭ－１」である企業とは別の企業であるということである。
　図２に示される５つの部署（（１）レコード１６１～１６４、（２）レコード１６５及び１６６、（３）レコード１６７及び１６８、（４）レコード１６９及び１７０、（５）レコード１７１及び１７２）が所属する企業は、複数（この場合２つ）である。そして、それら５つの部署のうち、少なくとも１人の購買担当者であるユーザが所属する３つの部署（（１）レコード１６１～１６４、（３）レコード１６７及び１６８、（４）レコード１６９及び１７０）は、「購買部門」となり得る。
（カテゴリコードマスタ）
　図３に沿ってカテゴリコードマスタ３２を説明する。
　カテゴリコードマスタ３２には、購買可能品グループコード欄１１１に記憶された購買可能品グループコードに関連付けて、購買可能品グループ名欄１１２には購買可能品グループ名が、カテゴリコード欄１１３にはカテゴリコードが、カテゴリ名欄１１４にはカテゴリ名が、記憶されている。
　購買可能品グループコード欄１１１の購買可能品グループコードは、図２の購買可能品グループコードと同様である。
　購買可能品グループ名欄１１２の購買可能品グループ名は、前記した購買可能品グループの名称である。
　カテゴリコード欄１１３のカテゴリコードは、要求担当者の所属する企業内で前記購買部門を決定しなければならないか否かを示す情報（カテゴリ）を一意に特定する識別子である。
　カテゴリとしては、例えば、「企業（テナント）内展開」及び「企業（テナント）跨り」の２つがあるものとする。
　ここで、「企業（テナント）内展開」は、要求を行った部署が所属する企業内で購買部門を決定しなければならないことを示す。
　「企業（テナント）跨り」は、要求を行った部署が所属する企業の内外に拘わらず購買部門を決定できることを示す。
　カテゴリ名欄１１４のカテゴリ名は、前記したカテゴリの名称である。
　図３の例では、購買可能品グループコードは３つ存在し（「Ｇ－１」、「Ｇ－２」及び「Ｇ－３」）、カテゴリコードは２つ存在する（「ＭＣ－１」及び「ＭＣ－２」）。
　購買可能品グループ名が「社内向け」であり、購買可能品グループコードが「Ｇ－１」である購買可能品グループは、カテゴリ名が「企業（テナント）内展開」であり、カテゴリコードが「ＭＣ－１」であるカテゴリに対応している。
　購買可能品グループ名が「グループ向け」であり、購買可能品グループコードが「Ｇ－２」である購買可能品グループもまた、カテゴリ名が「企業（テナント）内展開」であり、カテゴリコードが「ＭＣ－１」であるカテゴリに対応している。
　購買可能品グループ名が「グループ外向け」であり、購買可能品グループコードが「Ｇ－３」である購買可能品グループは、カテゴリ名が「企業（テナント）跨り」であり、カテゴリコードが「ＭＣ－２」であるカテゴリに対応している。
　図３のレコード１８１～１８３全体から、次の（１）及び（２）のことがらが分かる。
（１）グループ外向けの商品について要求があった場合（資本系列外の企業に対してある製品を納入するために、その製品の製造に必要な部品を購買するような場合）は、その要求を行った部署が属する企業の内外に拘わらず購買部門を決定できる（他社が取引先に対して見積を依頼することになってもよい）。
（２）社内向け又はグループ向けの商品について要求があった場合（自社内及び資本系列内の企業内で使用する消耗品を購買するような場合）は、その要求を行った部署が属する企業内で購買部門を決定しなければならない。
　購買可能品グループ（コード）とカテゴリ（コード）との対応は、任意に設定可能である。
　また、図２において、購買可能品グループ（コード）の設定を、要求担当者であるユーザ毎に行えば、カテゴリ（コード）の設定もまた、要求担当者であるユーザ毎に行える。
　さらに、購買可能品グループ（コード）とカテゴリ（コード）との対応を、時期的に変化させて設定することもできる。
（購買部門制御マスタ）
　図４に沿って購買部門制御マスタ３３を説明する。
　購買部門制御マスタ３３には、ルールＩＤ欄１２０に記憶されたルールＩＤに関連付けて、カテゴリコード欄１２１にはカテゴリコードが、分類コード欄１２２には分類コードが、購買部門間優先順位欄１２３には購買部門間優先順位が、購買部門企業コード欄１２４には購買部門企業コードが、購買部門事業所コード欄１２５には購買部門事業所コードが、購買部門部コード欄１２６には購買部門部コードが、従属購買部門企業コード欄１２７には従属購買部門企業コードが、従属購買部門事業所コード欄１２８には従属購買部門事業所コードが、従属購買部門部コード欄１２９には従属購買部門部コードが記憶されている。
　ルールＩＤ欄１２０のルールＩＤは、購買部門制御マスタ３３のレコードを一意に特定する識別子である。
　カテゴリコード欄１２１のカテゴリコードは、図３のカテゴリコードと同様である。
　分類コード欄１２２の分類コードは、購買対象の商品又はサービスを示す情報である。
　この分類コードは、購買可能品グループ及びカテゴリとは別の概念であり、例えば「安全靴」のような品目である。
　「安全靴」に含まれる「長靴」、「長靴」に含まれる「サイズ○の長靴」のようにさらに細かな品目を分類コードとしてもよい。ユーザが要求したい商品が、どの分類コードに対応しているかは、ユーザに知られているものとする。
　なお、分類コード「＠」は、「全ての分類コード」を示すものとする。
　購買部門間優先順位欄１２３の購買部門間優先順位は、購買部門の候補の間でどの候補が購買部門として優先して選択されるかを示す優先順位である。
　後記するように、カテゴリコード及び分類コードを検索キーとして購買部門制御マスタ３３を検索する処理を行う際に、複数の購買部門が該当することがある。このとき、該当した購買部門のなかで、優先順位の高い（数字が小さい）購買部門が他の購買部門に優先して選択される（詳細後記）。
　購買部門間優先順位は、カテゴリコードによって設定の規則がことなる。カテゴリコード「ＭＣ－１」の場合は、カテゴリコード、分類コード及び購買部門企業コードを共通にするレコードのなかで、１、２、３、・・・のように設定される。カテゴリコード「ＭＣ－２」の場合は、カテゴリコード及び分類コードを共通にするレコードのなかで、１、２、３、・・・のように設定される。
　購買部門企業コード欄１２４の購買部門企業コードは、購買部門となり得る部署が所属する企業の企業コードである。
　購買部門事業所コード欄１２５の購買部門事業所コードは、購買部門となり得る部署が所属する事業所の事業所コードである。
　購買部門部コード欄１２６の購買部門部コードは、購買部門となり得る部署が所属する部の部コードである。
　従属購買部門企業コード欄１２７の従属購買部門企業コードは、従属購買部門（直ちに後記）となり得る部署が所属する企業の企業コードである。
　従属購買部門事業所コード欄１２８の従属購買部門事業所コードは、従属購買部門となり得る部署が所属する事業所の事業所コードである。
　従属購買部門部コード欄１２９の従属購買部門部コードは、従属購買部門となり得る部署が所属する部の部コードである。
　購買部門制御マスタ３３のあるレコードのカテゴリコードが「ＭＣ－１」である場合、当該レコードの購買部門企業コードと従属購買部門企業コードは同一である。
　ある購買部門の候補が（ノウハウ不足等の理由により自らが購買部門となれない場合等に）、他の購買部門の候補に対して、自らに代替して取引先に対して見積を依頼することを委託することができる。代替される購買部門を「従属購買部門」と言う。
　ある購買部門に対してその従属購買部門を設定する場合に、購買部門間優先順位を考慮する必要はない。ただし、単純化のため、本実施形態においては、ある購買部門の優先順位を「ｐ」とすると、その従属購買部門の購買部門間優先順位は「ｐ－１」となるように設定している。したがって、欄１２７の従属購買部門企業コード、欄１２８の従属購買部門事業所コード及び欄１２９の従属購買部門部コードは、欄１２３の購買部門間優先順位が「１」より大きいレコードに設定されている。
　従属購買部門は、購買部門毎に１つ定義される。すなわち、購買部門毎に「どの購買部門から委託があれば自らが代替して購買部門となり得るか」、が定義される。
　以下に、購買部門制御マスタ３３のデータ構造をより明らかにするために、購買部門を決定する処理、及び、代替する購買部門を決定する処理の例を説明する。これらの処理の詳細は、フローチャートに沿ってさらに詳細に後記する。
　第１の例として、企業コードが「ＣＯＭ－１」である企業に所属し、ユーザＩＤが「Ｕ０００１」である要求担当者が、分類コードが「ＣＬ－１」である商品について要求を行った場合を説明する。この場合、カテゴリコード「ＭＣ－１」、分類コード「ＣＬ－１」及び購買部門企業コード「ＣＯＭ－１」を検索キーとして購買部門制御マスタ３３のすべてのレコードを検索する。
　レコード１９２は当然該当する。レコード１９１の分類コード欄１２２に記憶されている分類コード「＠」は、前記したように「全ての分類コード」を示し、「ＣＬ－１」と記憶されているに等しいので、レコード１９１も該当する。
　これら該当したレコードの購買部門企業コード、購買部門事業所コード及び購買部門部コードの組合せが特定する部署が購買部門となり得る候補である。具体的には、「ＣＯＭ－１」、「Ｊ－１」及び「Ｂ－１」の組合せで特定される購買部門、及び、「ＣＯＭ－１」、「Ｊ－２」及び「Ｂ－１」の組合せで特定される購買部門の２つが候補となる。
　しかしながら、レコード１９１の購買部門間優先順位は「１」であり、レコード１９２の購買部門間優先順位は「２」であるので、より高い購買部門間優先順位を有するレコード１９１の「ＣＯＭ－１」、「Ｊ－１」及び「Ｂ－１」の組合せで特定される購買部門が選択されようにもできる。
　「ＣＯＭ－１」、「Ｊ－１」及び「Ｂ－１」の組合せで特定される購買部門が選択されたとする。当該購買部門が何らかの理由で自ら購買部門となり得ない場合は、「ＣＯＭ－１」、「Ｊ－２」及び「Ｂ－１」の組合せで特定される購買部門に対して、自らに代替して購買部門となることを委託できる。なぜならば、レコード１９２の欄１２７～１２９には、「ＣＯＭ－１」、「Ｊ－１」及び「Ｂ－１」が記憶されているからである。
　第２の例として、企業コードが「ＣＯＭ－１」である企業に所属し、ユーザＩＤが「Ｕ０００１」である要求担当者が、分類コードが「ＣＬ－３」である商品について要求を行った場合を説明する。この場合、カテゴリコード「ＭＣ－１」、分類コード「ＣＬ－３」及び購買部門企業コード「ＣＯＭ－１」を検索キーとして購買部門制御マスタ３３のすべてのレコードを検索する。
　レコード１９４及びレコード１９５は当然該当する。レコード１９１の分類コード欄１２２に記憶されている分類コード「＠」は、前記したように「全ての分類コード」を示し、「ＣＬ－３」と記憶されているに等しいので、レコード１９１も該当する。結局、「ＣＯＭ－１」、「Ｊ－１」及び「Ｂ－１」の組合せで特定される購買部門、「ＣＯＭ－１」、「Ｊ－４」及び「Ｂ－１」の組合せで特定される購買部門、及び、「ＣＯＭ－１」、「Ｊ－５」及び「Ｂ－１」の組合せで特定される購買部門の３つが候補となる。
　しかしながら、レコード１９１及びレコード１９５の購買部門間優先順位は「１」であり、レコード１９４の購買部門間優先順位は「２」であるので、より高い購買部門間優先順位を有するレコード１９１の「ＣＯＭ－１」、「Ｊ－１」及び「Ｂ－１」の組合せで特定される購買部門並びにレコード１９５の「ＣＯＭ－１」、「Ｊ－５」及び「Ｂ－１」の組合せで特定される購買部門が選択されるようにもできる。さらに、同じ購買部門間優先順位の間では、「＠」よりも「ＣＬ－Ｘ」を有する購買部門が優先して選択されるようにもできる。また、「ＣＬ－Ｘ」よりも「＠」を有する購買部門が優先して選択されるようにもできる。
　「ＣＯＭ－１」、「Ｊ－１」及び「Ｂ－１」の組合せで特定される購買部門が選択されたとする。当該購買部門が何らかの理由で自ら購買部門となり得ない場合は、「ＣＯＭ－１」、「Ｊ－４」及び「Ｂ－１」の組合せで特定される購買部門に対して、自らに代替して購買部門となることを委託できる。なぜならば、レコード１９４の欄１２７～１２９には、「ＣＯＭ－１」、「Ｊ－１」及び「Ｂ－１」が記憶されているからである。
　一方、「ＣＯＭ－１」、「Ｊ－５」及び「Ｂ－１」の組合せで特定される購買部門が選択されたとする。当該購買部門が何らかの理由で自ら購買部門となり得ない場合は、他の購買部門に対して、自らに代替して購買部門となることを委託できない。なぜならば、レコード１９１、レコード１９４のいずれも、欄１２７～１２９に「ＣＯＭ－１」、「Ｊ－５」及び「Ｂ－１」が記憶されていないからである。
　第３の例として、企業コードが「ＣＯＭ－２」である企業に所属し、ユーザＩＤが「Ｕ０００９」である要求担当者が、分類コードが「ＣＬ－１」である商品について要求を行った場合を説明する。この場合、カテゴリコード「ＭＣ－２」及び分類コード「ＣＬ－１」を検索キーとして購買部門制御マスタ３３のすべてのレコードを検索する。
　レコード１９６、レコード１９７及びレコード１９８が該当する。なぜなら、レコード１９６、レコード１９７及びレコード１９８の分類コード欄１２２に記憶されているコード「＠」は前記したように「全ての分類コード」を示し「ＣＬ－１」と記憶されているに等しいからである。結局、「ＣＯＭ－７」、「Ｊ－１」及び「Ｂ－１」の組合せで特定される購買部門、「ＣＯＭ－８」、「Ｊ－１」及び「Ｂ－１」の組合せで特定される購買部門並びに「ＣＯＭ－９」、「Ｊ－１」及び「Ｂ－１」の組合せで特定される購買部門の３つが候補となる。
　しかしながら、レコード１９６の購買部門間優先順位は「１」であり、レコード１９７の購買部門間優先順位は「２」であり、レコード１９８の購買部門間優先順位は「３」であるので、より高い購買部門間優先順位を有するレコード１９６の「ＣＯＭ－７」、「Ｊ－１」及び「Ｂ－１」の組合せで特定される購買部門が選択されるようにもできる。
　「ＣＯＭ－７」、「Ｊ－１」及び「Ｂ－１」の組合せで特定される購買部門が選択されたとする。当該購買部門が何らかの理由で自ら購買部門となり得ない場合は、「ＣＯＭ－８」、「Ｊ－１」及び「Ｂ－１」の組合せで特定される購買部門に対して、自らに代替して購買部門となることを委託できる。なぜならば、レコード１９７の欄１２７～１２９には、「ＣＯＭ－７」、「Ｊ－１」及び「Ｂ－１」が記憶されているからである。
（購買部門属性マスタ）
　図５に沿って、購買部門属性マスタ３４を説明する。
　購買部門属性マスタ３４には、購買部門企業コード欄１３２の購買部門企業コード、購買部門事業所コード欄１３３の購買部門事業所コード及び購買部門部コード欄１３４の購買部門部コードの組合せに関連付けて、購買部門企業名欄１３５には購買部門企業名が、購買部門事業所名欄１３６には購買部門事業所名が、購買部門部名欄１３７には購買部門部名が、購買部門担当者名欄１３８には購買部門担当者名が、記憶されている。
　購買部門企業コード欄１３２の購買部門企業コードは、図４の購買部門企業コードと同様である。
　購買部門事業所コード欄１３３の購買部門事業所コードは、図４の購買部門事業所コードと同様である。
　購買部門部コード欄１３４の購買部門部コードは、図４の購買部門部コードと同様である。
　購買部門企業名欄１３５の購買部門企業名は、購買部門が所属する企業の名称である。
　購買部門事業所名欄１３６の購買部門事業所名は、購買部門が所属する事業所の名称である。
　購買部門部名欄１３７の購買部門事業所名は、購買部門が所属する部の名称である。
　購買部門担当者名欄１３８の購買部門担当者名は、購買部門における購買担当者の氏名である。同一の購買部門に購買担当者が複数いる場合は、複数の氏名が記憶される。
　例えば、図５のレコード２０１は、企業コード「ＣＯＭ－１」、事業所コード「Ｊ－１」及び部コード「Ｂ－１」の組合せが特定する購買部門の企業名は「企業１」であり、事業所名は「事業所１」であり、部名は「部１」であり担当者名は「担当Ａ」あることを示している。
　単純化のためにこのような例を挙げたが、実際には、「○○株式会社」、「東京事業所」、「調達部」、「田中一郎」のような実存する固有名詞が記憶されることになる。
（見積データ）
　図６に沿って、見積データ３５を説明する。
　見積データ３５には、見積ＩＤ欄１４１に記憶された見積ＩＤに関連付けて、要求ユーザＩＤ欄１４２には要求ユーザＩＤが、分類コード欄１４３には分類コードが、商品名欄１４４には商品名が、希望数量欄１４５には希望数量が、単位欄１４６には単位が、希望納期欄１４７には希望納期が、ルールＩＤ欄１４８にはルールＩＤが、購買部門企業コード欄１４９には購買部門企業コードが、購買部門事業所コード欄１５０には購買部門事業所コードが、購買部門部コード欄１５１には購買部門部コードが、記憶されている。
　見積ＩＤ欄１４１の見積ＩＤは、要求担当者からの要求を一意に特定する識別子である。
　要求ユーザＩＤ欄１４２の要求ユーザＩＤは、要求を行ったユーザのユーザＩＤである。
　分類コード欄１４３の分類コードは、図４の分類コードと同様である。
　商品名欄１４４の商品名は、要求に係る商品の名称である。
　希望数量欄１４５の希望数量は、要求に係る商品の数量である。
　単位欄１４６の単位は、希望数量の単位である。
　希望納期欄１４７の希望納期は、要求に係る商品の納入期限を示す年月日である。
　ルールＩＤ欄１４８のルールＩＤは、図４のルールＩＤと同様である。
　購買部門企業コード欄１４９の購買部門企業コードは、図４の購買部門企業コードと同様である。
　購買部門事業所コード欄１５０の購買部門事業所コードは、図４の購買部門事業所コードと同様である。
　購買部門部コード欄１５１の購買部門部コードは、図４の購買部門部コードと同様である。
　見積データ３５の１つのレコードは、要求担当者からの１つの要求に対応している。例えばレコード２１１を参照すると、以下のことがらが分かる。
（１）要求ユーザＩＤが「Ｕ０００１」であるユーザが、「１０冊」の「テスト見積依頼用ファイル」を「２００９１０１０」までに購買して欲しい旨の要求を行ったこと、
（２）商品名「テスト見積依頼用ファイル」を含む分類コードは「ＣＬ－１」であること、
（３）当該要求を受けて、取引先に対し見積を依頼する購買部門は、「ＣＯＭ－１」、「Ｊ－１」及び「Ｂ－１」の組合せが特定する部署であること、
（４）ルールＩＤが「Ｒ００１」である購買部門制御マスタ３３のレコードに基づき、購買部門が決定されたこと。
　このように、見積データ３５には、要求毎に購買部門が関連付けて記憶される。
（処理手順）
　以降、処理手順について説明しつつ、並行してユーザ端末装置３の出力装置４６に対し表示される画面についても説明する。
　処理手順には、要求担当者からの要求に応じて購買部門の候補を決定する要求処理手順と、購買担当者が、見積を依頼すべき要求を決定し、必要に応じて、自らに代替する他の購買部門を最終決定する見積処理手順とがある。見積処理手順は、要求処理手順が少なくとも１回実行された結果、見積データ３５のレコードが少なくとも１つ作成されていることを前提として実行される。
（要求処理手順）
　図７に沿って、要求処理手順を説明する。
　ステップＳ３０１において、見積購買業務装置２のログイン管理部２１は、ログインを受け付ける。
　具体的には、ログイン管理部２１は、第１に、ユーザ端末装置３の出力装置４６に対してログイン画面（図示せず）を表示し、ユーザがユーザＩＤ及びパスワードを入力するのを受け付ける。
　第２に、ログイン管理部２１は、受け付けたユーザＩＤとパスワードの組合せを有するレコードが、ユーザ属性マスタ３１に存在することを確認する。存在が確認できない場合は、「パスワードが違います」のようなメッセージをユーザ端末装置３に返し、再入力を促す。
　第３に、受け付けたユーザＩＤを検索キーとして、ユーザ属性マスタ３１を検索し、該当したレコードの企業コード、ユーザ権限及び購買可能品グループコードを取得する。
　ステップＳ３０２において、ログイン管理部２１は、ユーザ権限が「要求担当者」であるか否かを判断する。
　具体的には、ログイン管理部２１は、ステップＳ３０１において取得したユーザ権限が「要求担当者」である場合（ステップＳ３０２“ＹＥＳ”）は、ステップＳ３０３に進む。それ以外の場合（ステップＳ３０２“ＮＯ”）は、ステップＳ３０４に進む。
　ステップＳ３０３において、見積購買業務装置２の購買部門選択部２２は、要求メニュー画面（図示せず）をユーザ端末装置３に送信する。
　ステップＳ３０４において、購買部門選択部２２は、エラーメッセージをユーザ端末装置３に送信する。
　エラーメッセージは、例えば「要求できる権限がありません」のようなものであってよい。その後、要求処理手順を終了する。
　なお、他の権限を有する者が利用できる他の処理（例えば後記する「見積処理手順」）に誘導するボタンを表示し、当該ボタンが押下されるのを受け付けると、他の処理を実行するプログラムを起動し、要求処理手順自体は終了することとしてもよい。
　ステップＳ３０５において、購買部門選択部２２は、分類コード等を受け付ける。
　具体的には、購買部門選択部２２は、第１に、ユーザが要求メニュー画面の「実行リクエスト」ボタン（図示せず）を押下するのを受け付ける。
　第２に、見積依頼案件作成画面５１（図９(ａ)）をユーザ端末装置３の出力装置４６に表示する。
　第３に、ユーザが、見積依頼案件作成画面５１に対し、分類コード、商品名、希望数量、単位及び希望納期を入力するのを受け付ける。ユーザが「見積依頼作成」ボタン６１を押下すると、これらの入力データが、ユーザ端末装置３から見積購買業務装置２に送信されるものとする。
　なお、分類コード及び単位は、選択ボックス６２、６３に複数の選択肢が表示され、その選択肢の１つをユーザが選択するようにしてもよい。さらに、購買部門選択部２２は、入力された商品名と分類コードとの対応関係が正しいか否かを確認するようにしてもよい。この場合、商品名と分類コードとの対応関係を示す表が補助記憶装置１３に格納されているものとする。
　ステップＳ３０６において、購買部門選択部２２は、購買部門の候補を取得する。
　具体的には、購買部門選択部２２は、第１に、ステップＳ３０１において取得した購買可能品グループコードを検索キーとしてカテゴリコードマスタ３２を検索し、該当したレコードのカテゴリコードを取得する。
　第２に、取得したカテゴリコード及びステップ３０５において受け付けた分類コードを検索キーとして、購買部門制御マスタ３３を検索し、該当したすべてのレコードを取得する。
　第３に、「第１」において取得したカテゴリコードが「ＭＣ－１」であった場合は、「第２」において取得したレコードを、ステップＳ３０１において取得した企業コードを購買部門企業コード欄１２４に有するレコードに絞り込む。「第１」において取得したカテゴリコードが「ＭＣ－２」であった場合は、絞り込みは行わない。
　第４に、「第２」において取得したレコードから、又は「第３」において絞り込みが行われた場合は当該絞り込まれたレコードから、購買部門間優先順位が一番小さい数字であるレコードを取得する。
　ステップＳ３０７において、購買部門選択部２２は、購買部門を提示する。
　具体的には、購買部門選択部２２は、第１に、ステップＳ３０６の「第４」において取得した、購買部門制御マスタ３３のレコードのカテゴリコード、購買部門企業コード、購買部門事業所コード及び購買部門部コードを取得する。
　第２に、取得した購買部門企業コード、購買部門事業所コード及び購買部門部コードの組合せを検索キーとして、購買部門属性マスタ３４を検索し、該当したレコードの購買部門企業名、購買部門事業所名、購買部門部名及び購買部門担当者名を取得する。
　第３に、見積ＩＤを採番する。
　第４に、ユーザ端末装置３の出力装置４６に見積依頼案件確認画面５２（図９（ｂ））を表示する。見積依頼案件確認画面５２の「見積依頼情報」６４には、見積ＩＤ及びユーザが見積依頼案件作成画面５１に対して入力したデータが表示される。「購買部門情報」６５には、「第２」において取得した購買部門企業名、購買部門事業所名、購買部門部名及び購買部門担当者名が表示される。ユーザは、購買部門情報６５を確認する。
　第５に、ユーザが「見積依頼確認」ボタン７２を押下するのを受け付ける。
　ステップＳ３０８において、購買部門選択部２２は、見積データ３５のレコードを作成する。
　具体的には、購買部門選択部２２は、第１に、見積データ３５の新たなレコードを作成する。
　第２に、新たなレコードの見積ＩＤ欄１４１にステップＳ３０７において採番した見積ＩＤを、要求ユーザＩＤ欄１４２にステップＳ３０１において受け付けたユーザＩＤを記憶する。
　第３に、分類コード欄１４３、商品名欄１４４、希望数量欄１４５、単位欄１４６及び希望納期欄１４７に、ステップＳ３０５において受け付けた分類コード、商品名、希望数量、単位及び希望納期をそれぞれ記憶する。
　第４に、ステップＳ３０６の「第４」において取得した、購買部門制御マスタ３３のレコードのルールＩＤを、ルールＩＤ欄１４８に記憶する。
　第５に、購買部門企業コード欄１４９、購買部門事業所コード欄１５０及び購買部門部コード欄１５１に、ステップＳ３０７の「第１」において取得した、購買部門企業コード、購買部門事業所コード及び購買部門部コードをそれぞれ記憶する。
　その後、要求処理手順を終了する。
（見積処理手順）
　図８に沿って、見積処理手順を説明する。
　ステップＳ４０１において、見積購買業務装置２のログイン管理部２１は、ログインを受け付ける。
　具体的には、ログイン管理部２１は、第１に、ユーザ端末装置３の出力装置４６に対してログイン画面（図示せず）を表示し、ユーザがユーザＩＤ及びパスワードを入力するのを受け付ける。
　第２に、ログイン管理部２１は、受け付けたユーザＩＤとパスワードの組合せを有するレコードが、ユーザ属性マスタ３１に存在することを確認する。存在が確認できない場合は、「パスワードが違います」のようなメッセージをユーザ端末装置３に返し、再入力を促す。
　第３に、受け付けたユーザＩＤを検索キーとして、ユーザ属性マスタ３１を検索し、該当したレコードの企業コード、事業所コード、部コード及びユーザ権限を取得する。
　ステップＳ４０２において、ログイン管理部２１は、ユーザ権限が「購買担当者」であるか否かを判断する。
　具体的には、ログイン管理部２１は、ステップＳ４０１において取得したユーザ権限が「購買担当者」である場合（ステップＳ４０２“ＹＥＳ”）は、ステップＳ４０３に進む。それ以外の場合（ステップＳ４０２“ＮＯ”）は、ステップＳ４０４に進む。
　ステップＳ４０３において、見積購買業務装置２の購買部門設定制御部２３は、購買メニュー画面（図示せず）をユーザ端末装置３に送信する。
　ステップＳ４０４において、購買部門設定制御部２３は、エラーメッセージをユーザ端末装置３に送信する。
　エラーメッセージは、例えば「購買できる権限がありません」のようなものであってよい。その後、見積処理手順を終了する。
　なお、他の権限を有する者が利用できる他の処理（例えば前記した「要求処理手順」）に誘導するボタンを表示し、当該ボタンが押下されるのを受け付けると、他の処理を実行するプログラムを起動し、見積処理手順自体は終了することとしてもよい。
　ステップＳ４０５において、購買部門設定制御部２３は、見積データ３５のレコードを取得する。
　具体的には、購買部門設定制御部２３は、第１に、ステップＳ４０１において取得した企業コード、事業所コード及び部コードの組合せを検索キーとして、見積データ３５を検索し、該当したレコードをすべて取得する。
　ステップＳ４０６において、購買部門設定制御部２３は、処理すべき見積データ３５のレコードの選択を受け付ける。
　具体的には、購買部門設定制御部２３は、第１に、ステップＳ４０５において取得したすべてのレコードを表示する画面（見積依頼案件一覧画面(図示せず）)をユーザ端末装置３の出力装置４６に表示する。
　第２に、ユーザが、見積依頼案件一覧画面から、１つの任意のレコードを選択するのを受け付ける。
　見積依頼案件一覧画面には、見積データ３５の構成と同様の表が表示されるものとする。そして、ユーザは、例えば任意のレコードの任意の部分をマウス等の入力装置４５によって選択するものとする。
　ステップＳ４０７において、購買部門設定制御部２３は、代替し得る購買部門の候補を取得する。
　具体的には、購買部門設定制御部２３は、第１に、ステップＳ４０６において選択された見積データ３５のレコード（以下「処理対象レコード」と言うことがある）のルールＩＤを検索キーとして購買部門制御マスタ３３を検索し、該当したレコードを取得する（取得したレコードを、以下「基準レコード」と言うことがある）。
　第２に、以下のように場合分けをして処理を行う。
　（１）基準レコードのカテゴリコードが「ＭＣ－１」である場合は、購買部門制御マスタ３３のレコードの内から、以下の条件を同時に満たすレコードを抽出する。
・購買部門企業コードが、基準レコードの購買部門企業コードであること。
・分類コードが、処理対象レコードの分類コードであること。
・購買部門間優先順位が、基準レコードの「購買部門間優先順位＋ｎ（ｎ＝１,２,３,・・・）」以下であること。ｎは、「１,２,３,・・・」のうちの任意の値を設定できる。
・従属購買部門企業コード、従属購買部門事業所コード及び従属購買部門部コードが、それぞれ、基準レコードの購買部門企業コード、購買部門事業所コード及び購買部門部コードであること。
　（２）基準レコードのカテゴリコードが「ＭＣ－２」である場合は、購買部門制御マスタ３３のレコードの内から、以下の条件を同時に満たすレコードを抽出する。
・分類コードが、処理対象レコードの分類コードであること。
・購買部門間優先順位が、基準レコードの「購買部門間優先順位＋ｎ（ｎ＝１,２,３,・・・）」以下であること。ｎは、「１,２,３,・・・」のうちの任意の値を設定できる。
・従属購買部門企業コード、従属購買部門事業所コード及び従属購買部門部コードが、それぞれ、基準レコードの購買部門企業コード、購買部門事業所コード及び購買部門部コードであること。
　第３に、「第２」において抽出したレコードの購買部門企業コード、購買部門事業所コード及び購買部門部コードの組合せを取得する。
　ステップＳ４０８において、購買部門設定制御部２３は、代替し得る購買部門の候補が複数あるか否かを判断する。
　具体的には、購買部門設定制御部２３は、ステップＳ４０７の「第３」において取得した購買部門企業コード、購買部門事業所コード及び購買部門部コードの組合せが複数ある場合（ステップＳ４０８“ＹＥＳ”）は、ステップＳ４０９に進む。それ以外の場合（ステップＳ４０８“ＮＯ”）は、ステップＳ４１０に進む。なお、組合せは少なくとも１つは存在する。
　ステップＳ４０９において、購買部門設定制御部２３は、代替し得る購買部門の選択を受け付ける。
　具体的には、購買部門設定制御部２３は、第１に、見積処理画面（代替用）５３（図１０（ａ））をユーザ端末装置３の出力装置４６に表示する。
　見積処理画面（代替用）５３の見積依頼情報６６には、処理対象レコードの見積ＩＤ、商品名及び分類コードが表示される。
　第２に、ステップＳ４０７の「第３」において取得された購買部門企業コード、購買部門事業所コード及び購買部門部コードの組合せを検索キーとして購買部門属性マスタ３４を検索し、該当したレコードの購買部門企業名、購買部門事業所名及び購買部門部名の組合せを取得する。この組合せは複数存在する。そして、取得されたすべての組合せを見積処理画面（代替用）５３の選択ボックス６７に対して選択肢として表示する。
　第３に、ユーザが、選択ボックス６７から１つの選択肢を選択し、「処理を依頼」ボタン６８を押下するのを受け付ける。又は、ユーザが「処理を依頼」ボタン６８を押下することなく、「取引先に見積依頼」ボタン６９を押下するのを受け付ける。「処理を依頼」ボタン６８の押下があると、選択された購買部門企業名、購買部門事業所名及び購買部門部名の組合せが見積購買業務装置２に返送される。
　ステップＳ４１０において、購買部門設定制御部２３は、代替し得る購買部門の確認を受け付ける。
　具体的には、購買部門設定制御部２３は、第１に、見積処理画面（確認用）５４（図１０（ｂ））をユーザ端末装置３の出力装置４６に表示する。
見積処理画面（確認用）５４の見積依頼情報７０には、処理対象レコードの見積ＩＤ、商品名及び分類コードが表示される。
　第２に、ユーザが、「取引先に見積依頼」ボタン７１を押下するのを受け付ける。
　ステップＳ４１１において、見積購買業務装置２の購買部門切替実行部２４は、見積データ３５を更新する。
　具体的には、購買部門切替実行部２４は、ステップＳ４０９において、「処理を依頼」ボタン６８が押下されるのを受け付けている場合は、第１に、送信された購買部門企業名、購買部門事業所名及び購買部門部名の組合せを検索キーとして購買部門属性マスタ３４を検索し、該当したレコードの購買部門企業コード、購買部門事業所コード及び購買部門部コードを取得する。
　第２に、処理対象レコードの、購買部門企業コード、購買部門事業所コード及び購買部門部コードを、「第１」において取得した購買部門企業コード、購買部門事業所コード及び購買部門部コードにそれぞれ更新する。
　ステップＳ４０９又はステップＳ４１０において「取引先に見積依頼」ボタン６９、７１が押下されるのを受け付けている場合は、何も行わない。
　その後、見積処理手順を終了する。
（実施形態での作用・効果）
　以上説明した実施形態によれば、複数の企業に跨って、要求担当者及び購買担当者が、１つの見積購買業務システムを共有でき、要求を行った要求担当者毎に、購買部門を同一企業内に求めるか否かを決定できる。さらに、購買部門は、自らに購買ノウハウがない等の場合、他の購買部門に見積依頼を委託することができる。よって、見積購買業務の効率化、購買ノウハウの蓄積、内部牽制等が容易に行える。
（変形例）
　前記した要求処理手順のステップＳ３０６の「第４」においては、購買部門間優先順位が一番小さい購買部門制御マスタ３３のレコードを取得するものとした。しかしながら、このとき、購買部門間優先順位が「１＋ｍ（ｍ＝１,２,３,・・・）」以下であるレコードをすべて取得することとしてもよい。この場合、購買部門の候補は複数取得され、ステップＳ３０７及びステップＳ３０８の処理は複数の購買部門について行われることになる。
　この場合、ステップＳ４０７の「第２」の処理を以下のように変更してもよい。
　『第２に、以下のように場合分けをして処理を行う。
　（１）基準レコードのカテゴリコードが「ＭＣ－１」である場合は、購買部門制御マスタ３３のレコードの内から、以下の条件を同時に満たすレコードを抽出する。
・購買部門企業コードが、基準レコードの購買部門企業コードであること。
・分類コードが、処理対象レコードの分類コードであること。
・購買部門間優先順位が、基準レコードの「購買部門間優先順位±ｎ（ｎ＝１,２,３,・・・）」以下であること。ｎは、「１,２,３,・・・」のうちの任意の値を設定できる。
・購買部門企業コード、購買部門事業所コード及び購買部門部コードが、それぞれ、基準レコードの従属購買部門企業コード、従属購買部門事業所コード及び従属購買部門部コードであること。
　『（２）基準レコードのカテゴリコードが「ＭＣ－２」である場合は、購買部門制御マスタ３３のレコードの内から、以下の条件を同時に満たすレコードを抽出する。
・分類コードが、処理対象レコードの分類コードであること。
・購買部門間優先順位が、基準レコードの「購買部門間優先順位±ｎ（ｎ＝１,２,３,・・・）」以下であること。ｎは、「１,２,３,・・・」のうちの任意の値を設定できる。
・購買部門企業コード、購買部門事業所コード及び購買部門部コードが、それぞれ、基準レコードの従属購買部門企業コード、従属購買部門事業所コード及び従属購買部門部コードであること。』
　このような処理を行えば、従属購買部門から、購買部門に対して代替を依頼できるだけでなく、購買部門から従属購買部門に対しても代替を依頼することができる。
　本発明は、前記した実施形態に限定されることなく、本発明の主旨を逸脱しない範囲で、変更実施が可能である。
　１　　　見積購買業務システム
　２　　　見積購買業務装置
　３　　　ユーザ端末装置
　４　　　ネットワーク
　１１　　中央制御装置（制御部）
　１２　　主記憶装置（記憶部）
　１３　　補助記憶装置（記憶部）
　１４　　通信装置
　１５　　入力装置
　１６　　出力装置
　２１　　ログイン管理部
　２２　　購買部門選択部
　２３　　購買部門設定制御部
　２４　　購買部門切替実行部
　３１　　ユーザ属性マスタ
　３２　　カテゴリコードマスタ
　３３　　購買部門制御マスタ
　３４　　購買部門属性マスタ
　３５　　見積データ
　４１　　通信装置
　４２　　中央制御装置
　４３　　主記憶装置
　４４　　補助記憶装置
　４５　　入力装置
　４６　　出力装置
　５１　　見積依頼案件作成画面
　５２　　見積依頼案件確認画面
　５３　　見積処理画面（代替用）
　５４　　見積処理画面（確認用）

Claims (12)

  1. 　企業に所属する要求担当者からの、商品又はサービスの購買を依頼する要求に対して、前記商品又はサービスの見積を依頼する購買部門を複数の企業に所属する購買部門の候補のなかから決定する見積購買業務装置であって、
    　前記要求担当者を示す情報に関連付けて、前記要求担当者による前記要求が可能な商品又はサービスのグループである購買可能品グループを記憶したユーザ属性マスタと、
    　前記購買可能品グループに関連付けて、前記要求担当者の所属する企業内で前記購買部門を決定しなければならないか否かを示すカテゴリを記憶したカテゴリコードマスタと、
    　前記要求に含まれる購買対象の商品又はサービスを示す分類コード及び前記カテゴリの組合せに関連付けて、所属する企業を示す情報を含む前記購買部門を示す情報を記憶した購買部門制御マスタと、
    　を格納した記憶部と、
    　前記分類コード及び前記要求担当者を示す情報を前記要求として受け付け、
    　前記受け付けた要求における要求担当者を示す情報に基づいて前記ユーザ属性マスタを検索し購買可能品グループを取得し、
    　前記取得した購買可能品グループに基づき前記カテゴリコードマスタを検索しカテゴリを取得し、
    　前記取得したカテゴリ及び前記受け付けた要求に含まれる分類コードに基づいて前記購買部門制御マスタを検索し１つ又は複数の購買部門を示す情報を取得する制御部と、
    　を備えること、
    　を特徴とする見積購買業務装置。
  2. 　前記記憶部は、
    　前記要求に関連付けて、前記取得した購買部門を示す情報を記憶した見積データを格納し、
    　前記ユーザ属性マスタには、購買担当者を示す情報に関連付けて、前記購買担当者が所属する購買部門を示す情報も記憶されており、
    　前記制御部は、
    　前記購買担当者を示す情報を受け付け、
    　前記受け付けた購買担当者を示す情報に基づいて前記ユーザ属性マスタを検索し購買部門を示す情報を取得し、
    　前記取得した購買部門を示す情報に基づいて前記見積データを検索し前記要求を取得し、
    　前記取得した要求毎に、前記要求に含まれる分類コード、前記取得したカテゴリに基づいて前記購買部門制御マスタを検索し１つ又は複数の購買部門を示す情報を取得すること、
    　を特徴とする請求の範囲第１項に記載の見積購買業務装置。
  3. 　前記購買部門制御マスタには、前記カテゴリ及び前記分類コードの組合せに関連付けて、複数の購買部門間の優先順位が記憶されており、
    　前記制御部は、
    　前記取得したカテゴリ及び前記分類コードに基づいて前記購買部門制御マスタを検索し１つ又は複数の購買部門を示す情報を取得する際に、前記購買部門間の優先順位に基づいて、所定の数の購買部門を取得すること、
    　を特徴とする請求の範囲第２項に記載の見積購買業務装置。
  4. 　前記購買部門制御マスタには、前記カテゴリ及び前記分類コードの組合せに関連付けて、前記購買部門に代替して購買部門となることが予定されている他の購買部門を示す情報とが記憶されており、
    　前記制御部は、
    　前記取得したカテゴリ及び前記分類コードに基づいて前記購買部門制御マスタを検索し１つ又は複数の購買部門を示す情報を取得する際に、
    　取得する購買部門を、前記購買部門及び前記他の購買部門に限定すること、
    　を特徴とする請求の範囲第３項に記載の見積購買業務装置。
  5. 　企業に所属する要求担当者からの、商品又はサービスの購買を依頼する要求に対して、前記商品又はサービスの見積を依頼する購買部門を複数の企業に所属する購買部門の候補のなかから決定する見積購買業務装置を用いた見積購買業務方法であって、
    　前記見積購買業務装置の記憶部は、
    　前記要求担当者を示す情報に関連付けて、前記要求担当者による前記要求が可能な商品又はサービスのグループである購買可能品グループを記憶したユーザ属性マスタと、
    　前記購買可能品グループに関連付けて、前記要求担当者の所属する企業内で前記購買部門を決定しなければならないか否かを示すカテゴリを記憶したカテゴリコードマスタと、
    　前記要求に含まれる購買対象の商品又はサービスを示す分類コード及び前記カテゴリの組合せに関連付けて、所属する企業を示す情報を含む前記購買部門を示す情報を記憶した購買部門制御マスタと、
    　を格納し、
    　前記見積購買業務装置の制御部は、
    　前記分類コード及び前記要求担当者を示す情報を前記要求として受け付け、
    　前記受け付けた要求担当者を示す情報に基づいて前記ユーザ属性マスタを検索し購買可能品グループを取得し、
    　前記取得した購買可能品グループに基づき前記カテゴリコードマスタを検索しカテゴリを取得し、
    　前記取得したカテゴリ及び前記受け付けた要求に含まれる分類コードに基づいて前記購買部門制御マスタを検索し１つ又は複数の購買部門を示す情報を取得すること、
    　を特徴とする見積購買業務方法。
  6. 　前記記憶部は、
    　前記要求に関連付けて、前記取得した購買部門を示す情報を記憶した見積データを格納し、
    　前記ユーザ属性マスタには、購買担当者を示す情報に関連付けて、前記購買担当者が所属する購買部門を示す情報も記憶されており、
    　前記制御部は、
    　前記購買担当者を示す情報を受け付け、
    　前記受け付けた購買担当者を示す情報に基づいて前記ユーザ属性マスタを検索し購買部門を示す情報を取得し、
    　前記取得した購買部門を示す情報に基づいて前記見積データを検索し前記要求を取得し、
    　前記取得した要求毎に、前記要求に含まれる分類コード、前記取得したカテゴリに基づいて前記購買部門制御マスタを検索し１つ又は複数の購買部門を示す情報を取得すること、
    　を特徴とする請求の範囲第５項に記載の見積購買業務方法。
  7. 　前記購買部門制御マスタには、前記カテゴリ及び前記分類コードの組合せに関連付けて、複数の購買部門間の優先順位が記憶されており、
    　前記制御部は、
    　前記取得したカテゴリ及び前記分類コードに基づいて前記購買部門制御マスタを検索し１つ又は複数の購買部門を示す情報を取得する際に、前記購買部門間の優先順位に基づいて、所定の数の購買部門を取得すること、
    　を特徴とする請求の範囲第６項に記載の見積購買業務方法。
  8. 　前記購買部門制御マスタには、前記カテゴリ及び前記分類コードの組合せに関連付けて、前記購買部門に代替して購買部門となることが予定されている他の購買部門を示す情報とが記憶されており、
    　前記制御部は、
    　前記取得したカテゴリ及び前記分類コードに基づいて前記購買部門制御マスタを検索し１つ又は複数の購買部門を示す情報を取得する際に、
    　取得する購買部門を、前記購買部門及び前記他の購買部門に限定すること、
    　を特徴とする請求の範囲第７項に記載の見積購買業務方法。
  9. 　企業に所属する要求担当者からの、商品又はサービスの購買を依頼する要求に対して、前記商品又はサービスの見積を依頼する購買部門を複数の企業に所属する購買部門の候補のなかから決定する見積購買業務装置としてコンピュータを機能させる見積購買業務プログラムであって、
    　前記見積購買業務装置の記憶部に対して、
    　前記要求担当者を示す情報に関連付けて、前記要求担当者による前記要求が可能な商品又はサービスのグループである購買可能品グループを記憶したユーザ属性マスタと、
    　前記購買可能品グループに関連付けて、前記要求担当者の所属する企業内で前記購買部門を決定しなければならないか否かを示すカテゴリを記憶したカテゴリコードマスタと、
    　前記要求に含まれる購買対象の商品又はサービスを示す分類コード及び前記カテゴリの組合せに関連付けて、所属する企業を示す情報を含む前記購買部門を示す情報を記憶した購買部門制御マスタと、
    　を格納させ、
    　前記見積購買業務装置の制御部に対し、
    　前記分類コード及び前記要求担当者を示す情報を前記要求として受け付け、
    　前記受け付けた要求担当者を示す情報に基づいて前記ユーザ属性マスタを検索し購買可能品グループを取得し、
    　前記取得した購買可能品グループに基づき前記カテゴリコードマスタを検索しカテゴリを取得し、
    　前記取得したカテゴリ及び前記受け付けた要求に含まれる分類コードに基づいて前記購買部門制御マスタを検索し１つ又は複数の購買部門を示す情報を取得する処理を実行させること、
    　を特徴とする見積購買業務プログラム。
  10. 　前記記憶部に対し、
    　前記要求に関連付けて、前記取得した購買部門を示す情報を記憶した見積データを格納させ、
    　前記ユーザ属性マスタには、購買担当者を示す情報に関連付けて、前記購買担当者が所属する購買部門を示す情報も記憶されており、
    　前記制御部に対し、
    　前記購買担当者を示す情報を受け付け、
    　前記受け付けた購買担当者を示す情報に基づいて前記ユーザ属性マスタを検索し購買部門を示す情報を取得し、
    　前記取得した購買部門を示す情報に基づいて前記見積データを検索し前記要求を取得し、
    　前記取得した要求毎に、前記要求に含まれる分類コード、前記取得したカテゴリに基づいて前記購買部門制御マスタを検索し１つ又は複数の購買部門を示す情報を取得する処理を実行させること、
    　を特徴とする請求の範囲第９項に記載の見積購買業務プログラム。
  11. 　前記購買部門制御マスタには、前記カテゴリ及び前記分類コードの組合せに関連付けて、複数の購買部門間の優先順位が記憶されており、
    　前記制御部に対し、
    　前記取得したカテゴリ及び前記分類コードに基づいて前記購買部門制御マスタを検索し１つ又は複数の購買部門を示す情報を取得する際に、前記購買部門間の優先順位に基づいて、所定の数の購買部門を取得する処理を実行させること、
    　を特徴とする請求の範囲第１０項に記載の見積購買業務プログラム。
  12. 　前記購買部門制御マスタには、前記カテゴリ及び前記分類コードの組合せに関連付けて、前記購買部門に代替して購買部門となることが予定されている他の購買部門を示す情報とが記憶されており、
    　前記制御部に対し、
    　前記取得したカテゴリ及び前記分類コードに基づいて前記購買部門制御マスタを検索し１つ又は複数の購買部門を示す情報を取得する際に、
    　取得する購買部門を、前記購買部門及び前記他の購買部門に限定する処理を実行させること、
    　を特徴とする請求の範囲第１１項に記載の見積購買業務プログラム。
PCT/JP2010/062597 2009-11-09 2010-07-27 見積購買業務装置、見積購買業務方法及び見積購買業務プログラム WO2011055574A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2009255637A JP5134611B2 (ja) 2009-11-09 2009-11-09 見積購買業務装置、見積購買業務方法及び見積購買業務プログラム
JP2009-255637 2009-11-09

Publications (1)

Publication Number Publication Date
WO2011055574A1 true WO2011055574A1 (ja) 2011-05-12

Family

ID=43969814

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2010/062597 WO2011055574A1 (ja) 2009-11-09 2010-07-27 見積購買業務装置、見積購買業務方法及び見積購買業務プログラム

Country Status (2)

Country Link
JP (1) JP5134611B2 (ja)
WO (1) WO2011055574A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013010416A1 (zh) * 2011-07-21 2013-01-24 腾讯科技（深圳）有限公司 展示商品搜索结果的方法及系统
WO2020156227A1 (zh) * 2019-01-28 2020-08-06 阿里巴巴集团控股有限公司 商品对象信息处理方法、装置及电子设备
CN115358517A (zh) * 2022-07-11 2022-11-18 欧冶工业品股份有限公司 多用户多基地的采购计划多级分员配置策略方法和系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003016327A (ja) * 2001-07-04 2003-01-17 Nec Corp 商品購買方法及び購買システム並びに購買プログラム
JP2003108826A (ja) * 2001-09-28 2003-04-11 Hitachi Ltd 購買業務処理システム及び処理方法
JP2004288035A (ja) * 2003-03-24 2004-10-14 Osaka Gas Co Ltd 電子購買システム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003016327A (ja) * 2001-07-04 2003-01-17 Nec Corp 商品購買方法及び購買システム並びに購買プログラム
JP2003108826A (ja) * 2001-09-28 2003-04-11 Hitachi Ltd 購買業務処理システム及び処理方法
JP2004288035A (ja) * 2003-03-24 2004-10-14 Osaka Gas Co Ltd 電子購買システム

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013010416A1 (zh) * 2011-07-21 2013-01-24 腾讯科技（深圳）有限公司 展示商品搜索结果的方法及系统
WO2020156227A1 (zh) * 2019-01-28 2020-08-06 阿里巴巴集团控股有限公司 商品对象信息处理方法、装置及电子设备
CN115358517A (zh) * 2022-07-11 2022-11-18 欧冶工业品股份有限公司 多用户多基地的采购计划多级分员配置策略方法和系统

Also Published As

Publication number Publication date
JP5134611B2 (ja) 2013-01-30
JP2011100365A (ja) 2011-05-19

Similar Documents

Publication Publication Date Title
TWI391870B (zh) 購買操作系統、購買操作處理方法及購買操作處理程式產品
JP5502251B1 (ja) 帳票データ管理サーバ、および帳票データ管理プログラム
WO2013114442A1 (ja) 携帯端末管理サーバ、および携帯端末管理プログラム
WO2013146075A1 (ja) 情報提供装置、情報提供方法、プログラム、情報記憶媒体及び情報提供システム
JP5134611B2 (ja) 見積購買業務装置、見積購買業務方法及び見積購買業務プログラム
AU2011253858B8 (en) Providing package products
US11403363B2 (en) Search system, method, and program for restricting results based on conflicts
US20040049444A1 (en) Trade supporting method and system
JP5575969B1 (ja) データ管理サーバ、およびデータ管理プログラム
JP2020194284A (ja) レコメンド装置、レコメンド方法、及びレコメンドプログラム
JP2006259858A (ja) 出品管理システムおよび出品管理用コンピュータ・プログラム
US20130006922A1 (en) Database, data management server, and data managing program product
KR102432067B1 (ko) 운영규칙을 이용하여 인테리어 소품 조합 기능을 가지는 웹 서비스를 제공하는 방법 및 서버
JP7346756B2 (ja) 調達管理システム、調達管理システムのコンピュータプログラム、及び調達管理システムの制御方法
JP2019028784A (ja) 名刺情報管理システム、名刺情報管理装置、名刺情報管理方法及びプログラム
WO2002005162A1 (fr) Systeme de vente de marchandises
JP2012252678A (ja) 部品選択支援システム
JP2011128963A (ja) プレゼンテーション資料兼チラシ提供システム
US20060271375A1 (en) Project information providing system and project information providing method
JP2020109562A (ja) リフォーム工事見積システム
JP2024107554A (ja) 調達管理システム、調達管理システムのコンピュータプログラム、及び調達管理システムの制御方法
JP2023007105A (ja) 分割発注支援サーバー及び分割発注支援プログラム
JP6463216B2 (ja) 電子カタログ提供装置、電子カタログ提供方法、及び、電子カタログ提供プログラム
JP6557987B2 (ja) 出力制御プログラム、出力制御方法および出力制御装置
JP2001331556A (ja) 部品情報管理システムおよび部品情報管理方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10828135

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 10828135

Country of ref document: EP

Kind code of ref document: A1