Information processing method, information processing program, and information processing device

Abstract

An information processing method, an information processing program, and an information processing device are provided. [Solution] In a collection system in which a server and multiple user terminals are connected to each other via a network so that they can communicate with each other, the server 1, which is a computer that can access a memory unit that stores collected data and the status of the collected data, includes a data receiving unit 111 that receives the collected data, a memory unit that, when a confirmation result indicating that the collected data has been confirmed is received, associates the confirmation result with the collected data and stores it in the memory unit, and an update unit 115 that receives approval / non-approval data for the collected data and, if the received approval / non-approval data is approval, performs a process to update the status of the collected data to approved even if the confirmation result associated with the collected data is not stored in the memory unit.

Description

[Technical Field]

[0001] The present invention relates to an information processing method, an information processing program, and an information processing device. [Background technology]

[0002] Patent document 1 discloses a workflow system that enables applicants, verifiers, approvers, and contractors to carry out a series of tasks smoothly and quickly by allowing them to understand in advance the progress of work related to application data. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Laid-Open No. 2005-250611 Summary of the Invention [Means for solving the problem]

[0004] An information processing method according to one aspect of the present application includes a computer that can access a memory unit that stores collected data and the status of the collected data, and when the computer receives a confirmation result indicating that the collected data has been confirmed, stores the confirmation result in the memory unit in association with the collected data, receives approval / non-approval data for the collected data, and, if the received approval / non-approval data is approval, updates the status of the collected data to approved even if the confirmation result associated with the collected data is not stored in the memory unit.

[0005] In the above information processing method, when the collected data is received, an approval task including a group ID of an approval group that approves the collected data is generated, and the generated approval task is stored in the storage unit.

[0006] In the above information processing method, the approval group is an approval group associated with the base that inputs the collected data.

[0007] In the above information processing method, when there is a parent group whose child group is the approval group, and the approval / non-approval data indicating that the collected data is approved is received from a user belonging to the child group, the approval task indicating that the parent group is the next approval group is generated, and the generated approval task is stored in the storage unit.

[0008] In the above information processing method, when a request to transmit the collected data is received, the confirmation result stored in the storage unit or the number of confirmations calculated from the confirmation result is transmitted in association with the collected data.

[0009] In the above information processing method, when the approval / non-approval data for the collected data is a rejection, the confirmation result associated with the collected data is deleted from the storage unit.

[0010] An information processing program according to one aspect of the present application receives collected data in a computer that can access a memory unit that stores the collected data and the status of the collected data, and when a confirmation result indicating that the collected data has been confirmed is received, stores the confirmation result in the memory unit in association with the collected data, receives approval / non-approval data for the collected data, and if the received approval / non-approval data is approval, performs a process to update the status of the collected data to approved, even if the confirmation result associated with the collected data is not stored in the memory unit.

[0011] An information processing device according to one aspect of the present application is an information processing device that includes a control unit and is capable of accessing a memory unit that stores collected data and the status of the collected data, and when the control unit receives the collected data and a confirmation result indicating that the collected data has been confirmed, the control unit stores the confirmation result in association with the collected data in the memory unit, receives approval / non-approval data for the collected data, and if the received approval / non-approval data is approval, performs processing to update the status of the collected data to approved even if the confirmation result associated with the collected data is not stored in the memory unit.

[0012] The above summary of the invention does not list all of the features of the present invention, and subcombinations of these features may also be inventions. [Brief explanation of the drawings]

[0013] [Figure 1] FIG. 1 is an explanatory diagram illustrating an example of the configuration of a collection system. [Figure 2] 2 is a block diagram showing an example of the hardware configuration of the server 1. FIG. [Figure 3] FIG. 2 is a block diagram showing the hardware configuration of a user terminal 2. [Figure 4] FIG. 1 is an explanatory diagram illustrating an example hierarchy of multiple companies. [Figure 5] FIG. 2 is an explanatory diagram showing an example of a company DB 121. [Figure 6] FIG. 2 is an explanatory diagram showing an example of a base DB 122. [Figure 7] FIG. 10 is an explanatory diagram showing an example of an account DB 123. [Figure 8] FIG. 10 is an explanatory diagram showing an example of an authorized role DB 124. [Figure 9] FIG. 10 is an explanatory diagram showing an example of a base input DB 125. [Figure 10] FIG. 10 is an explanatory diagram showing an example of an approval DB 126. [Figure 11] FIG. 10 is an explanatory diagram showing an example of a confirmation DB 127. [Figure 12] 10 is a flowchart illustrating an example of a procedure for login processing. [Figure 13] 10 is a flowchart illustrating an example of a procedure for a submission process. [Figure 14] 10 is a flowchart illustrating an example of a procedure for approval processing. [Figure 15] 10 is a flowchart illustrating an example of an extraction process procedure. [Figure 16] 10 is a flowchart illustrating an example of a procedure for a confirmation process. [Figure 17] 10 is a flowchart illustrating an example of a procedure for a return process. [Figure 18] FIG. 10 is an explanatory diagram showing an example of an approval / confirmation screen. [Figure 19] FIG. 10 is an explanatory diagram showing another example of the approval / confirmation screen. [Figure 20] FIG. 10 is an explanatory diagram showing an example of an approval condition DB 128. [Figure 21] 10 is a flowchart illustrating another example of the procedure of the extraction process. DETAILED DESCRIPTION OF THE INVENTION

[0014] The present invention will be described below through embodiments of the invention, but the following embodiments do not limit the invention according to the claims. Furthermore, not all of the combinations of features described in the embodiments are necessarily essential to the solution of the invention.

[0015] In recent years, companies and organizations have come to need unified management and efficient information collection among groups of many related organizations, and to confirm and approve the collected information among the organizations.

[0016] In this specification, the collected data is mainly non-financial data, particularly data related to sustainability. The non-financial data is categorized into governance, strategy, risk management, indicators, and targets. The indicators and targets include greenhouse gas emissions for each company. The non-financial data is associated with identification information that uniquely identifies the company, such as a company ID. The greenhouse gas emissions are, for example, carbon dioxide emissions. Carbon dioxide emissions include direct emissions, indirect emissions, and other indirect emissions. The greenhouse gas emissions may be derived by multiplying the usage amount of at least one of electricity, water, oil, and gas by a unit of consumption indicating the greenhouse gas emissions per unit of each usage amount.

[0017] Non-financial data may include information on human rights and disaster risk management measures related to the products and services a company handles. Human rights measures may indicate, for example, whether a company takes measures to prevent child labor in product manufacturing (including all processes related to product manufacturing, including not only the assembly and processing of the product itself, but also the assembly and processing of the components that make up the product, and the processing of the materials (including raw materials) that make up each component). Disaster risk measures may indicate whether a company takes measures to prevent disasters from affecting product manufacturing. Collected data may also include financial data in addition to non-financial data, and may include any other information that end-user companies want to request from related companies. For example, this may include various types of damage-calculating environmental impact assessments; environmental information on product carbon footprints related to climate change; natural resource information on biodiversity, land use, and raw material procurement; waste disposal information on hazardous substances, waste management, packaging materials, and home appliances; environmental information on chemical substances, air pollutants, water quality, and soil contamination; and other environmental information on technology, energy, noise, vibration, and odors. Regarding society, information may be included regarding human rights (child labor, forced labor, working hours, wages, labor rights, discrimination, etc.) related to human resources, labor management and health and safety, human capital, safety and quality related to product and service safety, safety of each substance, privacy and data security, relations with local communities, diversity, equity and inclusion, well-being and engagement, compliance and ethics, and other social information. Furthermore, regarding governance, information may be included regarding ethics and compliance with laws and regulations regarding corporate behavior, anti-corruption, risk management, disaster prevention, tax transparency, and other governance information. Information regarding due diligence may also be included.

[0018] The non-financial data may include the following information on environmental impacts: amounts of substances such as by-products, NOx, SOx, BOD, and COD from the amounts of each of the above-mentioned uses, air pollution, indoor air pollution, hazardous chemicals, ozone layer depletion, acidification, noise, global warming, photochemical oxidants, eutrophication, resource consumption, ecotoxicity, fuel consumption, land use, and other impact areas, as well as human health through damage assessments, social estimates, biodiversity, and protected targets such as primary production, derived from the amounts of each of the above-mentioned uses using a basic unit indicating the amount per unit of each use.

[0019] Direct emissions refer to carbon dioxide emissions (thousand t-CO2) that fall under Scope 1 of supply chain emissions. Indirect emissions refer to carbon dioxide emissions indirectly emitted by a company through energy purchases over a specified period (fiscal year, quarter, etc.). Indirect emissions refer to carbon dioxide emissions (thousand t-CO2) that fall under Scope 2 of supply chain emissions. Other indirect emissions refer to carbon dioxide emissions emitted by company activities that are not included in Scope 1 direct emissions or Scope 2 indirect emissions. Other indirect emissions refer to carbon dioxide emissions (thousand t-CO2) that fall under Scope 3 of supply chain emissions.

[0020] Carbon dioxide reductions refer to the reduction in carbon dioxide emissions from the comparable period. Reductions may be shown for direct emissions, indirect emissions, and other indirect emissions. Non-financial data may include the percentage change in emissions (e.g., a 10% decrease from the previous year) rather than the reduction from the comparable period.

[0021] (Embodiment 1) The collection system 100 according to the first embodiment provides confirmation and approval services for collected information.

[0022] 1 is an explanatory diagram showing an example of the configuration of a collection system 100. The collection system 100 includes a server 1 and a user terminal 2. The server 1 and the user terminal 2 are connected via a network N so that they can communicate with each other.

[0023] The server 1 stores data (collected data) collected by companies using the collection system 100. The server 1 transmits the stored collected data to the user terminal 2 in response to a request from the user terminal 2. The server 1 is composed of a server computer, a workstation, a PC (Personal Computer), etc. The server 1 may also be composed of a multi-computer consisting of multiple computers, a virtual machine virtually constructed by software, or a quantum computer. The functions performed by the server 1 may be distributed among multiple computers. Furthermore, the functions of the server 1 may be realized by a cloud service.

[0024] The user terminal 2 is a terminal used by an end user. An end user is an employee or staff member of a corporation or organization. Depending on their role and authority, the end user is called an input person, approver, or checker. In Figure 1, two user terminals 2 are shown, but there may be one or three or more.

[0025] 2 is a block diagram showing an example of the hardware configuration of the server 1. The server 1 includes a control unit 11, a storage unit 12, a communication unit 13, and a reading unit 14. Each component is connected by a bus B.

[0026] The control unit 11 has one or more arithmetic processing devices such as a CPU (Central Processing Unit), an MPU (Micro-Processing Unit), a GPU (Graphics Processing Unit), etc. The control unit 11 reads and executes a program 1P (program product) stored in the storage unit 12, thereby performing various information processing, control processing, etc. related to the server 1, and realizing functional units such as a data receiving unit 111, a data storage unit 112, a confirmation result storage unit 113, an approval receiving unit 114, and an update unit 115.

[0027] The data accepting unit 111 accepts collected data from the user terminal 2, etc. The data storage unit 112 stores the collected data in the storage unit 12. When the confirmation result storage unit 113 accepts a confirmation result indicating that the collected data has been confirmed, it stores the confirmation result in the storage unit 12 in association with the collected data. The approval accepting unit 114 accepts approval / non-approval data for the collected data. When the accepted approval / non-approval data is approval, the update unit 115 updates the status of the collected data to approved even if the confirmation result associated with the collected data is not stored in the storage unit.

[0028] The storage unit 12 is configured with a static random access memory (SRAM), a dynamic random access memory (DRAM), a flash memory, or a hard disk or a solid state drive (SSD). The storage unit 12 temporarily stores data necessary for the control unit 11 to execute arithmetic processing. The storage unit 12 also stores a program 1P and various databases (DBs) necessary for the control unit 11 to execute processing. The storage unit 12 stores a company DB 121, a base DB 122, an account DB 123, an authority role DB 124, a base input DB 125, an approval DB 126, and a confirmation DB 127. The various DBs stored in the storage unit 12 may be stored in a database server or cloud storage different from the server 1. Although not required in this embodiment, the storage unit 12 may also store an approval condition DB 128.

[0029] The communication unit 13 communicates with the user terminal 2 via the network N. In addition, the control unit 11 may use the communication unit 16 to download the program 1P from another computer via the network N or the like and store it in the storage unit 12.

[0030] The reading unit 14 reads portable storage medium 1a including CD (Compact Disc)-ROM and DVD (Digital Versatile Disc)-ROM. The control unit 11 may read the program 1P from the portable storage medium 1a via the reading unit 14 and store it in the storage unit 12. Alternatively, the control unit 11 may download the program 1P from another computer via a network N or the like and store it in the storage unit 12. Furthermore, the control unit 11 may read the program 1P from a semiconductor memory (not shown).

[0031] 3 is a block diagram showing the hardware configuration of a user terminal. The user terminal 2 is configured with a notebook computer, a panel computer, a tablet computer, a smartphone, etc. The user terminal 2 includes a control unit 21, a storage unit 22, a communication unit 23, an input unit 24, and a display unit 25. Each component is connected by a bus B.

[0032] The control unit 21 has one or more arithmetic processing units such as a CPU, an MPU, a GPU, etc. The control unit 21 provides various functions by reading and executing a program 2P (program, program product) stored in the storage unit 22.

[0033] The storage unit 22 is configured with an SRAM, a DRAM, a flash memory, etc., or a hard disk, an SSD, etc. The storage unit 22 temporarily stores data necessary for the control unit 21 to execute arithmetic processing. The storage unit 22 also stores a program 2P and various DBs necessary for the control unit 21 to execute processing. The various DBs, etc. stored in the storage unit 22 may be stored in a database server or cloud storage.

[0034] The communication unit 23 communicates with the server 1 via the network N. The control unit 21 may also use the communication unit 23 to download the program 2P from another computer via the network N or the like and store it in the storage unit 22.

[0035] The input unit 24 is a keyboard and a mouse. The display unit 25 includes a liquid crystal display panel or an organic EL (electroluminescence) display panel, etc. The display unit 25 displays documents, etc., in which non-financial data output by the server 1 is embedded. The input unit 24 and the display unit 25 may be integrated to form a touch panel display. The user terminal 2 may display on an external display device.

[0036] Next, an example of a company group will be described, which will be used to explain the operation of the collection system 100. In the following description, it is assumed that a company group made up of multiple companies uses the collection system 100 to collect data.

[0037] Figure 4 is an explanatory diagram showing an example hierarchy of multiple companies. Figure 4 shows a group of companies with A (Itonaka Shoji) at the top. Layer 1 indicates the top company of the group of companies, and in this case it is only A (Itonaka Shoji). Layer 2 shows companies directly below Layer 1. Layer 2 consists of two companies: B (Food Sales Co., Ltd.) and C (Industrial Resources Co., Ltd.). Layer 3 shows companies directly below Layer 2. D (ABC Ham) and E (AB Foods) are shown to be directly below B (Food Sales Co., Ltd.). F (ABC Metals), G, and H are shown to be directly below C (Industrial Resources Co., Ltd.). Layer 4 shows companies directly below Layer 3. I and J are shown to be directly below E (ABC Metals).

[0038] FIG. 4 shows a hierarchical structure between companies, e.g., relationships between a holding company, headquarters, subsidiaries, sub-subsidiaries, affiliated companies, overseas offices, etc., but is not limited to this. It may also include a hierarchical structure between internal groups (headquarters, business divisions, departments, etc.) within a company, such as between departments, or it may show the connections between any other organizations (incorporated associations, national or local public entities, etc.). In other words, the hierarchical structure in the collection system 100 may be a hierarchical structure convenient for collecting data, and does not necessarily correspond exactly to the control relationships between companies, organizations, or groups. In a hierarchical structure, the group immediately above a certain group is called a parent group. The group immediately below a certain group is called a child group.

[0039] In the example shown in Figure 4, the data collected by each company is approved by the company one level above, and then approved by the company above it. With final approval by A (Itonaka Shoji), the collected data is used as final approved data within the corporate group, including A (Itonaka Shoji).

[0040] Next, we will explain the databases used by the collection system 100. Figure 5 is an explanatory diagram showing an example of the company DB 121. The company DB 121 stores information about companies. The company DB 121 includes a company ID column, a name column, a hierarchical code column, and a memo column. The company ID column stores a company ID that can uniquely identify a company. The name column stores the name of the company. The hierarchical code column stores a hierarchical code that indicates the hierarchical level at which the company is located. For example, the hierarchical code for ABC Ham is B01 / B010 / B0101. B0101 is the company ID for ABC Ham. B010 on the left side of the slash ( / ) indicates Food Sales Co., Ltd., a company one hierarchical level above. B01 to the further left of that indicates Itonaka Shoji, a company one hierarchical level above that. There is no code to the left of B01, so it can be seen that Itonaka Shoji is at the top level. In this way, by generating the hierarchical code of a company (group) at a certain level by placing the company ID of that company (group) after the hierarchical code of its parent company (parent group), it is possible to generate an infinite number of hierarchies while maintaining the links between companies, excluding physical constraints, etc., and to represent the hierarchies of many companies in a unified manner. The memo column stores reminders about companies. Note that the hierarchical code is an example of a group ID.

[0041] FIG. 6 is an explanatory diagram showing an example of the base DB 122. The base DB 122 stores information about bases. Bases are assumed to be branches, sales offices, factories, etc. Bases are organizations that have a grasp of much of the collected data. The base DB 122 includes a base ID column, a hierarchy code column, a base name column, a country column, a company ID column, a business column, an area column, and a base type column. The base ID column stores a base ID that can uniquely identify a base. The hierarchy code column stores a hierarchy code that indicates the position of a base in a hierarchical structure. The base name column stores the name of the base. The country column stores the name of the country in which the base is located. The country column may store a country code specified in ISO 3166-1. The company ID column stores the company ID of the company to which the base belongs. The business column stores the business type of the base, such as a business office or factory. The area column stores the region in which the base is located. In the example shown in FIG. 6, Tokyo is not included in the Kanto area, so the area of ​​the Tokyo sales office is Tokyo, not Kanto. The base type column stores the type of base, for example, directly under the head office, other than the head office, etc.

[0042] FIG. 7 is an explanatory diagram showing an example of the account DB 123. The account DB 123 stores account information and end user information. The account DB 123 stores an ID column, a display name column, an email address column, an account type column, an approval authority column, a confirmation authority column, a company ID column, and a role column. The ID column stores an ID that can uniquely identify an end user. The display name column stores the account name, such as the end user's job title or name. The email address column stores the end user's email address. The account type column stores the account type. For example, the type can be overall management authority, overall authority, individual authority, or input person.

[0043] Overall management authority is the authority to manage accounts within a corporate group and the authorization roles corresponding to each account. Overall authority has limitations compared to overall management authority. For example, overall authority does not allow adding accounts or authorization roles. Individual authority indicates that authority is set for each account. An input person refers to the account of an end user who is only responsible for inputting collected data, and the range of input that can be performed can be set. Account types are not limited to those mentioned above and may include any other account types. Furthermore, names are not limited to these and may be other names such as main body administrator, main body employee, subsidiary employee, field person, etc.

[0044] The approval authority column stores whether or not the end user has the authority to approve collected data. The confirmation authority column stores whether or not the end user has the authority to confirm collected data. Approval authority and confirmation authority can be omitted if they are uniquely determined by account type. The company ID column stores the company ID of the company to which the end user belongs. If the authority set for an account is defined by an authority role, the role column stores the identifier of the authority role, in this case the name. In the example shown in Figure 7, for an account whose "Account Type" is "Individual Authority," authority roles are set in the role column to control authority. "Including subsidiaries" and "Company only" shown in Figure 7 are examples of fixed authority roles that cannot be changed. "Including subsidiaries" is an authority that indicates that if the company to which the end user corresponding to the account belongs has subsidiaries, the end user will inherit the authority they have at their company to subsidiaries as well. "Company only" indicates that the authority granted to the end user corresponding to the account is valid only for the company to which they belong.

[0045] FIG. 8 is an explanatory diagram showing an example of the authorized role DB 124. The authorized role DB 124 stores roles that define authority. A role indicates the function of an account, the authority of the account is defined by the role, and the server 1 controls the account. The authorized role DB 124 includes a company ID column, a role 1 column, a role 2 column, and a role 3 column. The company ID column stores the company ID. The role 1 column stores the authority of role 1. The role 2 column stores the authority of role 2. The role 3 column stores the authority of role 3. In FIG. 8, the value of the role column may be, for example, the name of the information item (greenhouse gas emissions, activity volume of activities involving greenhouse gas emissions, water usage, etc.) as an item indicating the authority for the specific information item.

[0046] In the example shown in Figure 8, one authority is assigned to each role. "Editable" indicates that editing of collected data is permitted. "Viewable" indicates that viewing of collected data is permitted, but editing is not permitted. "No authority" indicates that access to collected data is not permitted.

[0047] FIG. 9 is an explanatory diagram showing an example of the base input DB 125. The base input DB 125 stores collected data input at a base. The base input DB 125 includes a base ID column, a hierarchical code column, a year column, a month column, a data type column, a section column, an item column, a type column, a unit column, a value column, and a submission column. The base ID column stores the base ID. The hierarchical code column stores the hierarchical code assigned to the base. The year column stores the target year of the collected data. The month column stores the target month of the collected data. The data type column stores the data type. The section column stores a data classification lower than the data type. The item column stores a name indicating the data. The type column stores the type of the input value. The unit column stores the unit of the input value. The value column stores the input value. The submission column indicates whether the collected data has been submitted. For example, a value of 0 in the submission column indicates that the data has not been submitted, and a value of 1 in the submission column indicates that the data has been submitted. Once the collected data has been submitted, it can be confirmed by a reviewer and approved by an approver. Submissions are made by data type, and confirmation and approval are also made by data type.

[0048] A new record is created in the base input DB 125 by an administrator of each corporate group, or an end user with overall management authority as an account type, setting the data to be collected for each base. The value in the value column is set to blank, and the value in the submission column is set to "not submitted."

[0049] FIG. 10 is an explanatory diagram showing an example of the approval DB 126. The approval DB 126 stores approval tasks and approval history for collected data. An approval task refers to the work of approving collected data. The approval DB 126 includes a base ID column, a hierarchical code column, a year column, a month column, a data type column, an approval hierarchical column, an approver ID column, an approval date and time column, and a result column. The base ID column stores the base ID of the base where collected data to be approved or approved was entered. The hierarchical code column stores the hierarchical code assigned to the base. The year column stores the target year of the collected data. The month column stores the target month of the collected data. The data type column stores the data type of the collected data. The approval hierarchical column stores the hierarchical code of the hierarchical level at which approval should be given or the hierarchical level at which approval was given. The approver ID column stores the user ID of the end user who gave the approval. The approval date and time column stores the date and time of approval. The result column stores the result. When the approver approves, approval is stored in the result column. When the approver sends back, return is stored in the result column. In the case of a record indicating an approval task, the values ​​in the approver ID column, approval date and time column, and result column are blank or a fixed value indicating that the task has not been approved ("none" in the example of FIG. 10).

[0050] FIG. 11 is an explanatory diagram showing an example of the confirmation DB 127. The confirmation DB 127 stores a confirmation history. The confirmation history is a history of checking whether there are any errors in the content of collected data entered at a location. The confirmation DB 127 includes a location ID column, a hierarchical code column, a year column, a month column, a data type column, a confirmation hierarchical column, a checker ID column, and a confirmation date and time column. The location ID column stores the location ID of the location where the checked collected data was entered. The hierarchical code column stores the hierarchical code assigned to the location. The year column stores the target year of the collected data. The month column stores the target month of the collected data. The data type column stores the data type of the collected data. The confirmation hierarchical column stores the hierarchical code of the hierarchical layer where the confirmation was performed. The checker ID column stores the user ID of the end user who performed the confirmation. The confirmation date and time column stores the date and time of the confirmation.

[0051] Next, the information processing performed by the collection system 100 will be described. FIG. 12 is a flowchart showing an example of the procedure for login processing. The end user operates the user terminal 2 to display a login screen. The step of displaying the login screen is omitted in FIG. 12. The end user inputs the ID and password given to them on the login screen. The control unit 21 of the user terminal 2 transmits a login request including the input ID and password to the server 1 (step S1). The control unit 11 of the server 1 receives the login request (step S2). The control unit 11 sets permissions according to the end user (step S3). The control unit 11 searches the account DB 123 using the received ID as a key to acquire the account type, the presence or absence of approval authority, and the presence or absence of confirmation authority of the account assigned to the end user. The control unit 11 also acquires a role as necessary. If the acquired role is not a fixed role, the control unit 11 searches the authorized role DB 124 to acquire the corresponding authority details. The control unit 11 generates a screen according to the acquired authority details. The control unit 11 controls the data to be displayed on the dashboard screen according to the authority details. The control unit 11 switches between displaying and hiding menu items according to the authority content. The control unit 11 switches between activating and deactivating menu items. The control unit 11 also switches between displaying and hiding buttons according to the authority content. The control unit 11 switches between activating and deactivating buttons to be displayed. The control unit 11 sends the generated screen to the user terminal 2 (step S4). The control unit 21 of the user terminal 2 receives the screen (step S5). The control unit 21 displays the screen (step S6) and ends the process.

[0052] FIG. 13 is a flowchart showing an example of the procedure for the submission process. It is assumed that the person in charge of inputting has completed logging in before the submission process is executed. The person in charge of inputting inputs the collected data. The control unit 21 of the user terminal 2 accepts the data (step S11). The person in charge of inputting issues a submission instruction. The control unit 21 sends the submission instruction to the server 1 (step S12). When the end user has completed data input for all items included in one data type, they can issue a submission instruction for that data type. The control unit 11 of the server 1 receives the submission instruction (step S13). The control unit 11 updates the data (step S14). The control unit 11 updates the submission column of the corresponding record in the base input DB 125 to "submitted". The control unit 11 generates an approval task (step S15). The control unit 11 generates an approval task based on the hierarchical code string of the record updated to "submitted" and stores it in the approval DB 126. If the hierarchical code of the approval task to be stored is B01 / B010 / B0101 / C0102, the approval hierarchical level will be the higher level, B01 / B010 / B0101. The values ​​of the approver ID column and the approval date and time column of the approval task are "none". The control unit 11 sends an email to the approver (step S16). The control unit 11 acquires the company ID of the company to which the approver should belong from the approval hierarchical level. If the approval hierarchical level is B01 / B010 / B0101, the company ID is B0101. The company to which the approver should belong is an example of an approval group. The control unit 11 searches the account DB 123 and identifies an account with approval authority from the accounts of the acquired company ID. The control unit 11 acquires the email address of the identified account, creates an email addressed to the acquired email address, and sends it. The email may be sent to multiple recipients. The control unit 11 generates a screen showing that the collected data of the submitted data type has been submitted, and sends it to the user terminal 2 of the person in charge of inputting (step S17). The control unit 21 of the user terminal 2 receives the screen (step S18), and displays the screen (step S19), and the process ends.

[0053] Since collected data can be submitted on a data type basis, an email is sent each time a data is submitted, but this is not limited to this. An email may be sent after the collected data to be entered for all set data types has been submitted.

[0054] In step S16, an email may be sent to a confirmer in addition to the approver. The confirmer sends the email to an account with confirmation authority at the same level as the approver. In this embodiment, approval and confirmation are carried out separately, so an email may be sent to a confirmer at a higher level than the approver. However, if the approver does not approve the collected data and returns it to the person in charge of input, the confirmation history is reset. Therefore, even if a confirmer at a higher level than the approver proceeds with the confirmation, it may be in vain. It is important to consider this point when defining operational rules.

[0055] 14 is a flowchart showing an example of the procedure for approval processing. It is assumed that the approver has completed logging in before the approval processing is executed. The approver selects approval from a menu. The control unit 21 of the user terminal 2 transmits a transmission request for collected data awaiting approval to the server 1 (step S31). The control unit 11 of the server 1 receives the transmission request (step S32). The control unit 11 extracts the collected data to be approved (step S33).

[0056] 15 is a flowchart showing an example of the procedure for extraction processing. The control unit 11 of the server 1 acquires the approver's authority from the account DB 123 (step S51). If the approver's authority is set by an authority role, the control unit 11 acquires the authority role from the authority role DB 124. The control unit 11 acquires collected data awaiting approval from the approver (step S52). The control unit 11 acquires the site ID and data type of the collected data awaiting approval from the approval DB 126. The control unit 11 uses the site ID and data type as search keys to acquire the entity of the collected data awaiting approval from the site input DB 125. The control unit 11 acquires confirmation data for the collected data awaiting approval from the confirmation DB 127 (step S53). The control unit 11 returns the process to the caller.

[0057] Returning to FIG. 14, the control unit 11 creates an approval screen including a status for each data type (step S34). The status may include whether confirmation has been completed, the number of confirmations, etc. The control unit 11 sends the created screen to the user terminal 2 (step S35). The control unit 21 of the user terminal 2 receives the screen (step S36). The control unit 21 displays the screen (step S37). The approver selects the collected data to be approved for each data type. The control unit 21 accepts the selection (step S38). The approver performs the approval operation. The control unit 21 accepts the approval and transmits approval (that it has been granted) to the server 1 (step S39). The control unit 11 of the server 1 receives the approval (step S40). The control unit 11 updates the approval history (step S41). The control unit 11 stores the approver's ID in the approver ID column of the corresponding record in the approval DB 126. The control unit 11 stores the current date and time in the approval date and time column of the corresponding record. The control unit 11 determines whether there is a next hierarchical level that requires approval (step S42). The control unit 11 references the hierarchical level code of the approval level to determine whether there is a higher hierarchical level. If the control unit 11 determines that there is a higher hierarchical level, it determines that there is a next hierarchical level that requires approval. If the control unit 11 determines that there is no higher hierarchical level, it determines that there is no next hierarchical level that requires approval. If the control unit 11 determines that there is no next hierarchical level that requires approval (NO in step S42), it proceeds to step S45. At this time, the control unit 11 may store, in the base input DB 125 or the like, information that approval of the collected data of the approved data type has been completed. If the control unit 11 determines that there is a next hierarchical level that requires approval (YES in step S42), it generates an approval task (step S43). The control unit 11 sends an email to the end user who is to approve (step S44). The control unit 11 generates an updated screen and sends the created screen to the user terminal 2 (step S45). The updated screen is a screen that includes a message to the approver that approval has been completed. The control unit 21 of the user terminal 2 receives and displays the updated screen (step S46), and the control unit 21 ends the process.

[0058] FIG. 16 is a flowchart showing an example of the confirmation process procedure. The confirmer selects confirmation from the menu. The control unit 21 of the user terminal 2 transmits a request to transmit the data to be confirmed to the server 1 (step S61). The control unit 11 of the server 1 receives the transmission request (step S62). The control unit 11 acquires the authority of the confirmer from the account DB 123 (step S63). If the authority of the confirmer is set by an authority role, the control unit 11 acquires the authority role from the authority role DB 124. The control unit 11 acquires the collected data to be confirmed by the confirmer (step S64). The control unit 11 creates a confirmation screen (step S65). The confirmation screen may include a confirmation history of the target collected data. The control unit 11 transmits the confirmation screen to the user terminal 2 (step S66). The control unit 21 of the user terminal 2 receives the confirmation screen (step S67). The control unit 21 displays the confirmation screen (step S68). The confirmer confirms the collected data to be confirmed on the confirmation screen and inputs a confirmation. The confirmer may refer to the confirmation history to confirm only collected data that has not yet been confirmed by anyone. The control unit 21 accepts the confirmation input and transmits confirmation to the server 1 (step S70). The control unit 11 of the server 1 receives confirmation (step S71). The control unit 11 updates the confirmation history (step S72). The control unit 11 creates and stores a new record in the confirmation DB 127. The control unit 11 generates an updated screen and transmits the created screen to the user terminal 2 (step S73). The updated screen is a screen that includes a message to the checker that confirmation has been completed. The control unit 21 of the user terminal 2 receives and displays the updated screen (step S46). The control unit 21 ends the processing.

[0059] FIG. 17 is a flowchart showing an example of the procedure for the return process. The approver checks the collected data for each data type on the approval screen, and if they determine that the data should be returned, they input a return. The approver may decide to return the data to the person in charge of inputting the data or to the approval level immediately below. The control unit 21 of the user terminal 2 accepts the return (step S91). The control unit 21 transmits the site ID and data type of the collected data to be returned to the server 1 (step S92). The control unit 11 of the server 1 receives the site ID and data type (step S93). The control unit 11 updates the approval DB 126 based on the received site ID and data type (step S94). The control unit 11 stores the ID of the approver who performed the return in the approver ID column of the corresponding record in the approval DB 126. The control unit 11 stores the current date and time in the approval date and time column of the record. The control unit 11 stores the return in the result column of the record. The control unit 11 deletes the confirmation history stored in the confirmation DB 127 based on the received site ID and data type (step S95). It is desirable that the deletion be logical rather than physical. The control unit 11 generates a task for the returned data (step S96). The control unit 11 determines whether the returned data is to be input by the person in charge of input and whether re-input of the collected data is required (step S96). If the control unit 11 determines that re-input is required (YES in step S96), it updates the returned collected data to "not submitted" (step S97). The control unit 11 updates the value of the submission column of the corresponding record in the base input DB 125 to "not submitted." The control unit 11 proceeds to the process at step S100. If the control unit 11 determines that re-input is not required (NO in step S96), it generates an approval task for the returned approval hierarchy (step S98). The control unit 11 stores the generated task in the approval DB 126 (step S99). The control unit 11 transmits an approval screen with the updated status of the returned data type to the user terminal 2 (step S100). The control unit 21 of the user terminal 2 receives the approval screen (step S101), displays the approval screen (step S102), and ends the process.

[0060] Next, the screens displayed on the user terminal 2 will be described. FIG. 18 is an explanatory diagram showing an example of the approval / confirmation screen. The approval / confirmation screen d01 includes an approval target tab d011, a confirmation target tab d012, a base list tab d013, a list d014, and an approval button d015. When the approval target tab d011 is selected, the collected data to be approved is displayed by data type. The screen with the approval target tab d011 selected corresponds to the approval screen described above. When the confirmation target tab d012 is selected, the collected data to be confirmed is displayed by data type. The screen with the confirmation target tab d012 selected corresponds to the confirmation screen described above. When the base list tab d013 is selected, a list of the status of collected data for each base is displayed. The list d014 corresponds to the selected tab. The approval button d015 is a button that is displayed when the approval button d015 is selected. When the data type to be approved is selected in the list d014 and the approval button d015 is operated, the collected data of the selected data type is approved. When the confirmation target tab d012 is selected, the approval button d015 becomes a confirmed button. When the base list tab d013 is selected, the button corresponding to the approval button d015 is not displayed.

[0061] Figure 18 shows the screen when the Approval Target tab d011 is selected. The list d014 includes a checkbox column, a data type column, a status column, a number of locations where data has been entered, a confirmation column, and an operation column. Checking the checkbox for the data type you want to approve and pressing the approval button d015 marks the collected data of the selected data type as approved. Note that items that cannot be approved cannot be checked. The status column indicates the status of the collected data. Examples of statuses include "Inputting," "Submitted," or "Waiting for Approval." "Inputting" indicates that the location is currently entering the collected data. "Submitted" indicates that the location has completed entering the collected data and submitted it. Submitted collected data is displayed as "Waiting for Approval" on the approval screen. The confirmation column displays information regarding the confirmation of the collected data. The number of times the collected data has been confirmed for each data type. The number of locations indicates the number of locations where the collected data has been confirmed for each data type. Selecting the ellipsis in the operation column displays a pull-down menu. From this pull-down menu, you can confirm the collected data and any comments added to it. You can also send it back. When a document is sent back, it is returned to an approver at a lower level than the approver or to the person in charge of input. If it is returned to an approver at a lower level, the approver can either re-approve it by adding a comment or send it back again. It is also possible to make it possible for the approver who sends back the document to the person in charge of input even if they are not at the level immediately above the person in charge of input.

[0062] Fig. 19 is an explanatory diagram showing another example of the approval / confirmation screen. Fig. 19 shows the screen that is displayed when the confirmation target tab d012 is selected on the approval / confirmation screen d01 shown in Fig. 18. It includes a location list tab d013, a list d014, and an approval button d015. The following explanation will mainly focus on the differences from Fig. 18.

[0063] The approval / confirmation screen d01 includes an approval target tab d011, a confirmation target tab d012, a location list tab d013, a list table d016, and a confirmed button d017. The list table d016 includes a checkbox column, a company name column, a data type column, a status column, a number of entered locations column, a confirmation column, and an operation column. Checking the checkbox for the data type you want to confirm and operating the confirmed button d017 confirms the collected data for the selected data type. Note that items that cannot be confirmed cannot be checked. The status column indicates the status of the collected data. Examples of statuses include "Waiting for processing," "Confirming," or "Confirmed." "Waiting for processing" indicates that the collected data entry has not been completed, or that the entry has been completed but not submitted. "Confirming" indicates that the confirmer can confirm the data. The confirmer can confirm the data at any time until the collected data is finally approved. "Confirmed" indicates that the confirmer has confirmed the data. The confirmation column displays information regarding the confirmation of the collected data. The number of times indicates the number of times the collected data was checked for each data type. The number of locations indicates the number of locations where the collected data was checked for each data type. When you select the ellipsis in the operation column, a pull-down menu will appear. From this pull-down menu, you can check the collected data and any comments attached to the collected data.

[0064] The status column is a pull-down menu, and by operating this pull-down menu, the status can be changed from "Checking" to "Checked." Also, by selecting "Return" from the pull-down menu, it is possible to request the person in charge of input to resubmit the data.

[0065] As described above, this embodiment provides the following advantages. By separating confirmation and approval, collected data can be approved even if it has not been confirmed, i.e., even if the confirmation result is not stored in the confirmation DB 127. As a result, the operation of the collection system 100 may result in final approval of collected data that has never been confirmed. Companies that do not want this outcome can establish operational rules to address this. Therefore, by displaying the number of confirmations and the number of locations where confirmations have been performed on the approval / confirmation screen, it is possible to prevent final approval of collected data that has never been confirmed. It is also possible to output a confirmation history that indicates not only the number of confirmations and the number of locations, but also the level of the person who confirmed the data and when. Furthermore, according to this embodiment, by separating approval and confirmation, the account DB 123 can be configured to grant end users confirmation authority but not approval authority. In other words, by having end users other than the approver confirm the data, it is possible to more reliably confirm the accuracy and validity of the data.

[0066] (Embodiment 2) In the first embodiment, confirmation and approval of collected data are separated, but there may be a desire to ensure that confirmation has been completed by the time approval is given at a specific approval level in the collection system 100. In this embodiment, when approval is given at a set level, it is possible to set conditions for approval.

[0067] FIG. 20 is an explanatory diagram showing an example of the approval condition DB 128. The approval condition DB 128 stores approval conditions for each company. In other words, when a company becomes part of an approval group, the approval condition DB 128 stores the conditions under which collected data can be approved. The approval condition DB 128 includes a company ID column and a condition column. The company ID column stores company IDs. The condition column stores the conditions under which approval can be made.

[0068] FIG. 21 is a flowchart showing another example of the procedure for the extraction process. As described with reference to FIG. 15, the extraction process is a process for extracting collected data to be approved by an approver. The control unit 11 of the server 1 acquires the approver's authority from the account DB 123 (step S111). If the approver's authority is set by an authority role, the control unit 11 acquires the authority role from the authority role DB 124. The control unit 11 acquires collected data awaiting approval from the approver (step S112). The control unit 11 acquires the site ID and data type of the collected data awaiting approval from the approver from the approval DB 126. The control unit 11 acquires the entity of the collected data awaiting approval from the site input DB 125 using the site ID and data type as search keys. The control unit 11 refers to the approval condition DB 128 and determines whether or not there are approval conditions for the company to which the approver belongs (step S113). If the control unit 11 determines that there are no approval conditions (NO in step S113), the process proceeds to step S116. If the control unit 11 determines that there is an approval condition (NO in step S113), it acquires judgment data for judging the approval condition (step S114). The judgment data is, for example, the number of confirmations. At this time, the control unit 11 acquires the judgment data from the confirmation DB 127 and calculates the number. The control unit 11 uses the judgment data to narrow down the collected data awaiting approval to only that which matches the approval condition (step S115). The control unit 11 acquires the confirmation data for the collected data awaiting approval from the confirmation DB 127 (step S116). Note that if the confirmation data has already been acquired in step S114, the process is skipped. The control unit 11 returns the process to the caller.

[0069] In this embodiment, when approval is given, it is possible to set conditions for approval. In the above description, approval conditions can be set on a company-by-company basis, but this is not limiting. Different conditions may be set at multiple levels within the same company. For example, when approval is given at multiple levels within a company, approval conditions may be set at one level but not at another level. Furthermore, approval conditions may be set at all levels, but the contents of the conditions may be different.

[0070] Although the present invention has been described above using the embodiments, the technical scope of the present invention is not limited to the scope described in the above embodiments. It will be apparent to those skilled in the art that various modifications and improvements can be made to the above embodiments. It is clear from the claims that such modifications and improvements can also be included within the technical scope of the present invention.

[0071] It should be noted that the execution order of each process, such as operations, procedures, steps, and stages, in the devices, systems, programs, and methods shown in the claims, specifications, and drawings is not specifically stated as "before," "prior to," etc., and that the processes can be performed in any order unless the output of a previous process is used in a later process. Even if the operational flow in the claims, specifications, and drawings is described using "first," "next," etc. for convenience, this does not mean that the processes must be performed in this order.

[0072] Furthermore, aspects of each embodiment may be embodied in whole or in part by a computer. As an example of such a computer, a program installed on the computer may cause the computer to perform operations associated with an apparatus according to an embodiment of the present invention or to function as one or more "parts" of the apparatus. Alternatively, the program may cause the computer to execute the operations or one or more "parts." The program may cause the computer to execute a process or steps of the process according to an embodiment of the present invention. Such a program may be executed by a CPU to cause the computer to perform specific operations associated with some or all of the blocks in the flowcharts and block diagrams described herein. [Explanation of symbols]

[0073] 100: Collection System 1: Server 11: Control section 111: Data reception department 112: Data storage unit 113: Confirmation result storage unit 114: Approval Reception Department 115: Update section 12: Storage section 121: Corporate DB 122: Base DB 123: Account DB 124:Authorization Role DB 125: Base input DB 126: Approval DB 127: Confirmation DB 128: Approval condition DB 13: Communications Department 14: Reading unit 16: Communications Department 1P: Program 1a: Portable storage medium 2: User terminal 2P: Program 21: Control unit 22: Storage section 23: Communications Department 24: Input section 25:Display section B: Bus N: Network

Claims

1. a computer that can access a storage unit that stores collected data and a state of the collected data; Accepting the collected data; When a confirmation result indicating that the collected data has been confirmed is received, the confirmation result is stored in the storage unit in association with the collected data; Accepting approval / disapproval data for the collected data; If the received approval / non-approval data indicates approval, the status of the collected data is updated to approved even if the confirmation result associated with the collected data is not stored in the storage unit. Information processing method for processing.

2. When the collected data is received, an approval task including a group ID of an approval group that will approve the collected data is generated; The generated approval task is stored in the storage unit. The information processing method according to claim 1 .

3. The approval group is an approval group that corresponds to the base station that inputs the collected data. The information processing method according to claim 2 .

4. When a parent group exists in which the approval group is a child group, and when the approval / non-approval data indicating that the collected data is approved is received from a user belonging to the child group, the approval task is generated, indicating that the parent group is the next approval group; The generated approval task is stored in the storage unit.

4. The information processing method according to claim 2 or 3.

5. When a transmission request for the collected data is received, the confirmation result stored in the storage unit or the number of confirmations calculated based on the confirmation result is transmitted in association with the collected data. The information processing method according to any one of claims 1 to 3.

6. If the approval / non-approval data for the collected data is a rejection, the confirmation result associated with the collected data is deleted from the storage unit. The information processing method according to any one of claims 1 to 3.

7. A computer that can access a storage unit that stores collected data and the status of the collected data. Accepting the collected data; When a confirmation result indicating that the collected data has been confirmed is received, the confirmation result is stored in the storage unit in association with the collected data; Accepting approval / disapproval data for the collected data; If the received approval / non-approval data indicates approval, the status of the collected data is updated to approved even if the confirmation result associated with the collected data is not stored in the storage unit. An information processing program that performs processing.

8. An information processing device including a control unit and capable of accessing a storage unit that stores collected data and a state of the collected data, The control unit Accepting the collected data; When a confirmation result indicating that the collected data has been confirmed is received, the confirmation result is stored in the storage unit in association with the collected data; Accepting approval / disapproval data for the collected data; If the received approval / non-approval data indicates approval, the status of the collected data is updated to approved even if the confirmation result associated with the collected data is not stored in the storage unit. An information processing device that performs processing.

Images