Information processing method, information processing program, and information processing apparatus

Abstract

This invention provides an information processing method, information processing program, and information processing device that enable more reliable verification of data accuracy and validity by having end-users other than approvers perform the verification. [Solution] The information processing method involves a computer that can access a storage unit that stores collected data and the status of the collected data. When the computer receives the collected data and a confirmation result indicating that the collected data has been confirmed, it stores the confirmation result in association with the collected data in the storage unit. The computer then receives approval / approval data for the collected data, and if the received approval / approval data indicates approval, it updates the status of the collected data to approved, even if the confirmation result associated with the collected data is not yet stored in the storage unit.

Description

Technical Field

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

Background Art

[0002] Patent Document 1 discloses a workflow system that enables a series of operations to be performed smoothly and quickly by allowing applicants, confirmers, approvers, and order receivers to grasp in advance the progress of operations related to application data.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Means for Solving the Problems

[0004] An information processing method according to an aspect of the present application is a computer capable of accessing a storage unit that stores collected data and the state of the collected data. When the computer receives the collected data and receives a confirmation result indicating that the collected data has been confirmed, the computer stores the confirmation result in the storage unit in association with the collected data. When the computer receives approval / rejection data of the collected data and the received approval / rejection data is approval, the computer performs a process of updating the state of the collected data to approved even if the confirmation result associated with the collected data is not stored in the storage 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 site that input the collected data.

[0007] In the above information processing method, if there is a parent group whose child group is the approval group, and the approval / rejection data indicating approval of the collected data is received from a user belonging to the child group, the parent group generates an approval task indicating that the parent group is the next approval group, and stores the generated approval task 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 based on the confirmation result is transmitted in association with the collected data.

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

[0010] An information processing program according to one aspect of this application receives the collected data from a computer that has access to a storage unit that stores the collected data and the state of the collected data. When it receives a confirmation result indicating that the collected data has been confirmed, it stores the confirmation result in association with the collected data in the storage unit. It also receives approval / approval data for the collected data, and if the received approval / approval data indicates approval, it updates the state of the collected data to approved, even if the confirmation result associated with the collected data is not stored in the storage unit.

[0011] An information processing device according to one aspect of this application is an information processing device that includes a control unit and is accessible to a storage unit that stores collected data and the state of the collected data, wherein the control unit receives the collected data and, upon receiving a confirmation result indicating that the collected data has been confirmed, stores the confirmation result in association with the collected data in the storage unit, receives approval / disapproval data for the collected data, and, if the received approval / disapproval data is approved, performs a process to update the state of the collected data to approved, even if the confirmation result associated with the collected data is not stored in the storage unit.

[0012] It should be noted that the above summary of the invention does not enumerate all of its features. Furthermore, subcombinations of these features may also constitute an invention. [Brief explanation of the drawing]

[0013] [Figure 1] This is an explanatory diagram showing an example configuration of the data collection system. [Figure 2] This is a block diagram showing an example of the hardware configuration for Server 1. [Figure 3] This block diagram shows the hardware configuration of user terminal 2. [Figure 4] This is an explanatory diagram showing examples of hierarchical structures across multiple companies. [Figure 5] This is an explanatory diagram showing an example from company DB121. [Figure 6] This is an explanatory diagram showing an example of site DB122. [Figure 7] This is an explanatory diagram showing an example of account DB123. [Figure 8] This is an explanatory diagram illustrating an example of the authorization role DB124. [Figure 9] This is an explanatory diagram showing an example of the site input DB125. [Figure 10] This is an explanatory diagram showing an example of approval DB126. [Figure 11] This is an explanatory diagram showing an example of verification DB127. [Figure 12] This is a flowchart showing an example of the login process. [Figure 13] It is a flowchart showing an example of the procedure of the submission process. [Figure 14] It is a flowchart showing an example of the procedure of the approval process. [Figure 15] It is a flowchart showing an example of the procedure of the extraction process. [Figure 16] It is a flowchart showing an example of the procedure of the confirmation process. [Figure 17] It is a flowchart showing an example of the procedure of the rollback process. [Figure 18] It is an explanatory diagram showing an example of the approval / confirmation screen. [Figure 19] It is an explanatory diagram showing another example of the approval / confirmation screen. [Figure 20] It is an explanatory diagram showing an example of the approval condition DB128. [Figure 21] It is a flowchart showing another example of the procedure of the extraction process.

Mode for Carrying Out the Invention

[0014] Hereinafter, the present invention will be described through embodiments of the invention. However, the following embodiments do not limit the invention according to the claims. Also, not all combinations of features described in the embodiments are essential for the solution means of the invention.

[0015] In recent years, in companies, organizations, etc., there is a need to perform unified management and efficient information collection in groups of many related organizations, etc., and further, to perform confirmation and approval of the collected information among organizations, etc.

[0016] In this specification, the collected data is primarily non-financial data, particularly data related to sustainability. Non-financial data is categorized into governance, strategy, risk management, metrics, and targets. Metrics and targets include greenhouse gas emissions for each firm. Non-financial data is associated with identifying information that uniquely identifies a firm, such as a firm ID. Greenhouse gas emissions include, for example, carbon dioxide emissions. Carbon dioxide emissions include direct emissions, indirect emissions, and other indirect emissions. Greenhouse gas emissions may be derived by multiplying at least one use of electricity, water, oil, and gas by an intensity that represents the greenhouse gas emissions per unit of each use.

[0017] As non-financial data, companies may manage information on human rights measures and disaster risk measures related to the products and services they handle. Human rights measures may indicate whether measures are in place to prevent child labor in the manufacturing of products (including not only the assembly of the product itself, but also the assembly of components that make up the product, the processing of materials (including raw materials, etc.) that make up each component, and all other processes related to product manufacturing). Disaster risk measures may indicate whether measures are in place to prevent product manufacturing from being affected in the event of a disaster. In addition to non-financial data, financial data may also be included as collected data, and any other information that the end-user's company wishes to request from the relevant company may be included. For example, various types of damage calculation-based environmental impact assessments, environmental information such as product carbon footprints related to climate change, biodiversity, land use, and raw material procurement related to natural resources, hazardous materials, waste management, and waste such as packaging materials and home appliances related to waste disposal, contained chemical substances, air pollutants, water quality, and soil contamination related to environmentally regulated substances, and other environmental information such as technology, energy, noise, vibration, and odor may be included. Furthermore, information regarding society may include human rights related to human resources (child labor, forced labor, working hours, wages, labor rights, discrimination, etc.), labor management and occupational health and safety, human capital, safety and quality related to the safety of products and services, safety of each substance, privacy and data security, relationships with the community, diversity, equity and inclusion, well-being and engagement, compliance and ethics, and other information related to society. In addition, information regarding governance may include ethics and legal compliance related to corporate conduct, anti-corruption, risk management and disaster response, tax transparency, and other information related to governance. Information regarding due diligence may also be included.

[0018] Non-financial data may include the following information regarding environmental impact: the amounts of by-products, NOx, SOx, BOD, COD, etc. from each of the above-mentioned usage amounts, the impact areas such as air pollution, air pollution, hazardous chemicals, ozone depletion, acidification, noise, global warming, photochemical oxidants, eutrophication, resource consumption, ecotoxicity, fuel consumption, land use, etc., human health based on damage assessment, social projections, biodiversity, primary production, and other protected entities, and the amounts derived using unit consumption factors.

[0019] Direct emissions refer to carbon dioxide emissions (thousand tons of CO2) that fall under Scope 1 of so-called supply chain emissions. Indirect emissions refer to carbon dioxide emissions indirectly emitted by a company through energy purchases during a specified period (fiscal year, quarter, etc.). Indirect emissions refer to carbon dioxide emissions (thousand tons of CO2) that fall under Scope 2 of supply chain emissions. Other indirect emissions refer to carbon dioxide emissions from 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 tons of CO2) that fall under Scope 3 of supply chain emissions.

[0020] The reduction in carbon dioxide emissions represents the reduction from carbon dioxide emissions during the comparison period. The reduction may be shown separately for direct emissions, indirect emissions, and other indirect emissions. Non-financial data may include the percentage change in emissions (e.g., a 10% decrease compared to the previous year) rather than the reduction from the comparison period.

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

[0022] Figure 1 is an explanatory diagram showing an example configuration of the data collection system. The data collection system 100 includes a server 1 and a user terminal 2. Server 1 and user terminal 2 are connected to each other via a network N, enabling them to communicate with one another.

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

[0024] User terminal 2 is a terminal used by end users. End users are employees or staff of corporations, organizations, etc. Depending on their role and authority, end users may be called input personnel, approvers, verifiers, etc. In Figure 1, two user terminals 2 are shown, but there may be one or three or more.

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

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

[0027] The data reception unit 111 receives data to be collected 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 receives 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 reception unit 114 receives approval / approval data for the collected data. When the received approval / approval data indicates 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 composed of SRAM (Static Random Access Memory), DRAM (Dynamic Random Access Memory), flash memory, or a hard disk or SSD (Solid State Drive). The storage unit 12 temporarily stores data necessary for the control unit 11 to perform calculations. The storage unit 12 also stores programs 1P and various databases (DBs) necessary for the control unit 11 to perform processing. The storage unit 12 stores the company DB 121, branch DB 122, account DB 123, authorization role DB 124, branch input DB 125, approval DB 126, and confirmation DB 127. The various databases stored in the storage unit 12 may be stored on a database server or cloud storage different from server 1. Although not necessary in this embodiment, the storage unit 12 may also store the approval condition DB 128.

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

[0030] The reading unit 14 reads a portable storage medium 1a, including CD (Compact Disc)-ROM and DVD (Digital Versatile Disc)-ROM. The control unit 11 may read 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 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 program 1P from a semiconductor memory (not shown).

[0031] Figure 3 is a block diagram showing the hardware configuration of a user terminal. User terminal 2 consists of a notebook computer, panel computer, tablet computer, smartphone, etc. 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 bus B.

[0032] The control unit 21 has one or more arithmetic processing units such as CPUs, MPUs, and GPUs. The control unit 21 provides various functions by reading and executing programs 2P (programs, program products) stored in the storage unit 22.

[0033] The storage unit 22 is composed of SRAM, DRAM, flash memory, or a hard disk or SSD. The storage unit 22 temporarily stores data necessary for the control unit 21 to perform calculations. The storage unit 22 also stores the program 2P and various databases necessary for the control unit 21 to perform processing. The various databases 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. Alternatively, the control unit 21 may use the communication unit 23 to download 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 or 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 containing embedded non-financial data output by the server 1. Alternatively, the input unit 24 and the display unit 25 may be integrated to form a touch panel display. The user terminal 2 may also display information on an external display device.

[0036] Next, we will describe an example of a corporate group used when explaining the operation of the data collection system 100. In the following explanation, we assume that a corporate group consisting of multiple companies uses the data collection system 100 to collect data.

[0037] Figure 4 is an explanatory diagram showing an example of a hierarchy for multiple companies. In Figure 4, a group of companies with A (Itochu Shoji) at the top is shown. Hierarchy 1 shows the top company in the group, and in this case, it is only A (Itochu Shoji). Hierarchy 2 shows the companies directly below Hierarchy 1. Hierarchy 2 consists of two companies: B (Shokuhin Hanbai Co., Ltd.) and C (Kogyo Shigen Co., Ltd.). Hierarchy 3 shows the companies directly below Hierarchy 2. D (ABC Ham) and E (AB Foods) are directly below B (Shokuhin Hanbai Co., Ltd.). F (ABC Metal), G, and H are directly below C (Kogyo Shigen Co., Ltd.). Hierarchy 4 shows the companies directly below Hierarchy 3. I and J are directly below E (ABC Metal).

[0038] Figure 4 shows a hierarchical structure between companies, illustrating relationships such as, for example, holding companies, headquarters, subsidiaries, sub-subsidiaries, affiliates, and overseas offices, but is not limited to these. It may also include internal company groups (headquarters, business units, departments, etc.), such as hierarchical structures between departments, or connections between any other organization (associations, national and local governments, etc.). In other words, the hierarchical structure in the data collection system 100 may be a convenient hierarchical structure for data collection and does not have to perfectly match the dominance relationships between companies, organizations, or groups. In the hierarchical structure, the group directly above a given group is called the parent group. The group directly below a given group is called the child group.

[0039] In the example shown in Figure 4, the data collected by each company is approved by the company one level up, and then further approved by the company one level up. Ultimately, with A (Itochu Shoji)'s approval, the collected data becomes final approved data and is used by A (Itochu Shoji) and the rest of the corporate group.

[0040] Next, we will describe the database 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 hierarchy 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 hierarchy code column stores a hierarchy code that indicates the hierarchy in which the company is located. For example, the hierarchy code for ABC Ham is B01 / B010 / B0101. B0101 is the company ID for ABC Ham. B010 on the left, separated by a slash ( / ), indicates a company one level higher, Food Sales Co., Ltd. Further to the left of that, B01 indicates a company one level higher, Itochu Trading Co., Ltd. Since there is no code to the left of B01, it can be seen that Itochu Trading Co., Ltd. is at the top level. In this way, by generating a hierarchy code for a company (group) at a certain level, placing the company ID of that company after the hierarchy 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 hierarchy of many companies in a unified manner. The memo column is used to store notes and other information about the company. Note that the hierarchy code is an example of a group ID.

[0041] Figure 6 is an explanatory diagram showing an example of the location DB122. The location DB122 stores information about locations. Locations are assumed to be branches, sales offices, or factories. Locations are organizations that have a large amount of information about the collected data. Location DB122 includes columns for location ID, hierarchy code, location name, country, company ID, business, area, and location type. The location ID column stores a location ID that can uniquely identify a location. The hierarchy code column stores a hierarchy code that indicates the location of the location in the hierarchical structure. The location name column stores the name of the location. The country column stores the name of the country where the location is located. The country column may also store the country code specified in ISO 3166-1. The company ID column stores the company ID of the company to which the location belongs. The business column stores the business type of the location, for example, a business office, a factory, etc. The area column stores the region where the location is located. In the example shown in Figure 6, Tokyo is not included in the Kanto area, so the area of ​​the Tokyo sales office is Tokyo, not Kanto. The "Location Type" column stores the type of location, such as "directly under headquarters" or "outside headquarters."

[0042] Figure 7 is an explanatory diagram showing an example of Account DB123. Account DB123 stores account information and end-user information. Account DB123 stores the following columns: ID column, Display Name column, Email Address column, Account Type column, Approval Authority column, Verification Authority column, Corporate ID column, and Role column. The ID column stores an ID that uniquely identifies the 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 could be Global Administrator, Global Authority, Individual Authority, or Input Person.

[0043] Global management privileges allow you to manage accounts within a corporate group and manage the corresponding permission roles for each account. Global privileges have limitations compared to global management privileges. For example, with global privileges, you cannot add accounts or permission roles. Individual privileges indicate that permissions are set for each account. An input user account refers to an end-user account that is only responsible for inputting collected data, and the scope of input they can perform can be set. Account types are not limited to those mentioned above and may include any other account types. Similarly, names are not limited to these and may include other names such as main administrator, main employee, subsidiary employee, or field staff.

[0044] The Approval Permission column stores whether or not the user has the authority to approve the collected data. The Verification Permission column stores whether or not the user has the authority to verify the collected data. Approval and verification permissions may be omitted if they are uniquely determined by the account type. The Company ID column stores the company ID of the company to which the end user belongs. The Role column stores the identifier, in this case the name, of the permission role if the permissions set for the account are defined by an permission role. In the example shown in Figure 7, the design is such that permission control is performed by setting an permission role in the Role column for accounts where the "Account Type" is "Individual Permission". "Include Subsidiaries" and "Company Only" shown in Figure 7 are examples of fixed permission roles that cannot be changed. "Include Subsidiaries" is an permission that indicates that if the company to which the end user corresponding to the account belongs has subsidiaries, the end user will inherit the permissions they have in their own company from the subsidiaries. "Company Only" indicates that the permissions granted to the end user corresponding to the account are valid only in the company to which they belong.

[0045] Figure 8 is an explanatory diagram illustrating an example of the Authority Role DB124. The Authority Role DB124 stores roles that define permissions. A role indicates the role of an account, and the role defines the permissions of an account, allowing Server 1 to control the account. The Authority Role DB124 includes a Corporate ID column, a Role 1 column, a Role 2 column, and a Role 3 column. The Corporate ID column stores the Corporate ID. The Role 1 column stores the permissions of Role 1. The Role 2 column stores the permissions of Role 2. The Role 3 column stores the permissions of Role 3. In Figure 8, the values ​​in the Role column may be, for example, the names of information items that indicate permissions for specific information items (e.g., greenhouse gas emissions, activity level of activities involving greenhouse gas emissions, water usage, etc.).

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

[0047] Figure 9 is an explanatory diagram showing an example of the site input DB125. The site input DB125 stores the collected data entered at each site. The site input DB125 includes columns for site ID, hierarchy code, year, month, data type, section, item, type, unit, value, and submission. The site ID column stores the site ID. The hierarchy code column stores the hierarchy code assigned to the site. The year column stores the target year for the collected data. The month column stores the target month for the collected data. The data type column stores the data type. The section column stores data classifications lower than the data type. The item column stores the name that represents the data. The type column stores the type of the entered value. The unit column stores the unit of the entered value. The value column stores the entered value. The submission column indicates whether the collected data has been submitted or not. For example, a value of 0 in the submission column indicates that it has not been submitted, and a value of 1 in the submission column indicates that it has been submitted. Once the collected data has been submitted, it can be reviewed by a verifier and approved by an approver. Submissions should be made on a per-data-type basis, and verification and approval should also be done on a per-data-type basis.

[0048] Records in the location input DB125 are created when an administrator of each company group, or an end user with global administrative privileges in their account type, sets the data to be collected for each location. The value column is empty, and the value of the submission column is set to not submitted.

[0049] Figure 10 is an explanatory diagram showing an example of the approval DB126. The approval DB126 stores the approval tasks and approval history of collected data. An approval task refers to the business of approving the collected data. The approval DB126 includes columns for location ID, hierarchy code, year, month, data type, approval hierarchy, approver ID, approval date and time, and result. The location ID column stores the location ID of the location where the collected data to be approved or approved was entered. The hierarchy code column stores the hierarchy 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 approval hierarchy column stores the hierarchy code of the hierarchy to be approved or the hierarchy to which approval was performed. The approver ID column stores the user ID of the end user who approved. The approval date and time column stores the date and time of approval. The result column stores the result. When an approver approves, the result column stores the approval. When an approver rejects the data, the result column stores the rejection. For records representing approval tasks, the values ​​in the Approver ID, Approval Date & Time, and Result columns will be blank or fixed values ​​indicating that the task is not approved (e.g., "None" in the example in Figure 10).

[0050] Figure 11 is an explanatory diagram showing an example of the Verification DB127. The Verification DB127 stores the verification history. The verification history is a record of verifications to ensure that there are no errors in the content of the collected data entered at each location. The Verification DB127 includes columns for Location ID, Hierarchy Code, Year, Month, Data Type, Verification Hierarchy, Verifier ID, and Verification Date and Time. The Location ID column stores the Location ID of the location where the verified collected data was entered. The Hierarchy Code column stores the hierarchy code assigned to that 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 Verification Hierarchy column stores the hierarchy code of the hierarchy that was verified. The Verifier ID column stores the user ID of the end user who performed the verification. The Verification Date and Time column stores the date and time of verification.

[0051] Next, the information processing performed by the collection system 100 will be explained. Figure 12 is a flowchart showing an example of the login process. The end user operates the user terminal 2 to display the login screen. The step of displaying the login screen is omitted in Figure 12. The end user enters the ID and password provided on the login screen. The control unit 21 of the user terminal 2 sends a login request including the entered 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 the permissions according to the end user (step S3). The control unit 11 searches the account DB 123 using the received ID as a key and obtains the account type, whether or not the end user has approval authority, and whether or not they have confirmation authority. It also obtains the role as needed. If the obtained role is not a fixed role, it searches the permission role DB 124 and obtains the corresponding permission details. The control unit 11 generates a screen according to the obtained permission details. The control unit 11 controls the data to be displayed on the dashboard screen according to the permission details. The control unit 11 switches the display / hide status of menu items according to the permissions. The control unit 11 switches the active / inactive status of menu items. The control unit 11 also switches the display / hide status of buttons according to the permissions. The control unit 11 switches the active / inactive status of 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 terminates the process.

[0052] Figure 13 is a flowchart illustrating an example of the submission process procedure. It is assumed that the data entry person has completed logging in before the submission process is executed. The data entry person enters the collected data. The control unit 21 of user terminal 2 receives the data (step S11). The data entry person issues a submission instruction. The control unit 21 sends the submission instruction to server 1 (step S12). Once the end user has completed data entry for all items included in a data type, they can issue a submission instruction for that data type. The control unit 11 of 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 site 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 column of the record updated to submitted and stores it in the approval DB 126. If the hierarchy code of the approval task to be stored is B01 / B010 / B0101 / C0102, the approval hierarchy will be the higher level B01 / B010 / B0101. The values ​​in 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 obtains the company ID of the company to which the approver should belong from the approval hierarchy. If the approval hierarchy 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 the account with approval authority for the account with the obtained company ID. The control unit 11 obtains the email address of the identified account, creates an email addressed to the obtained email address, and sends it. There may be multiple recipients for the email. The control unit 11 generates a screen indicating 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 input (step S17). The control unit 21 of the user terminal 2 receives the screen (step S18). The control unit 21 displays the screen (step S19) and terminates the process.

[0053] Since collected data can be submitted on a per-data-type basis, an email will be sent each time a submission is made, but this is not the only way. For all configured data types, an email may be sent after all the required collected data has been submitted.

[0054] In step S16, an email may be sent to the verifier in addition to the approver. The verifier should send the email to an account with the same level of verification authority as the approver. In this embodiment, approval and verification are performed separately, so an email may also be sent to a verifier at a higher level than the approver. However, if the approver does not approve the collected data and returns it to the data entry person, the verification history will be reset. Therefore, it may be pointless for a verifier belonging to a higher level than the approver to proceed with the verification. It is important to establish operational rules that take this point into consideration.

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

[0056] Figure 15 is a flowchart showing an example of the extraction process procedure. The control unit 11 of Server 1 obtains 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 obtains the authority role from the authority role DB 124. The control unit 11 obtains the collected data awaiting the approver's approval (step S52). The control unit 11 obtains the site ID and data type of the collected data awaiting the approver's approval from the approval DB 126. The control unit 11 uses the site ID and data type as search keys to obtain the actual collected data awaiting approval from the site input DB 125. The control unit 11 obtains 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 Figure 14, the control unit 11 creates an approval screen that includes the status for each data type (step S34). The status may include whether or not it has been confirmed, the number of times it has been confirmed, 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 approve by 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 sends the approval (indicated) 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 another level to be approved (step S42). The control unit 11 refers to the level code of the approval level and determines whether there is an even higher level. If the control unit 11 determines that there is a higher level, it determines that there is another level to be approved. If the control unit 11 determines that there is no higher level, it determines that there is no next level to be approved. If the control unit 11 determines that there is no next level to be approved (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 that the approval of the collected data of the approved data type has been completed. If the control unit 11 determines that there is another level to be approved (YES in step S42), it generates an approval task (step S43). The control unit 11 sends an email to the end user who needs 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 display to the approver indicating that the approval has been completed. The control unit 21 of the user terminal 2 receives and displays the updated screen (step S46). The control unit 21 then terminates the process.

[0058] Figure 16 is a flowchart showing an example of the confirmation process procedure. The verifier selects "Confirm" from the menu. The control unit 21 of user terminal 2 sends a request to send the data to be confirmed to server 1 (step S61). The control unit 11 of server 1 receives the transmission request (step S62). The control unit 11 obtains the verifier's authority from account DB 123 (step S63). If the verifier's authority is set by an authority role, the control unit 11 obtains the authority role from authority role DB 124. The control unit 11 obtains the collected data that the verifier is confirming (step S64). The control unit 11 creates a confirmation screen (step S65). The confirmation screen may also include the confirmation history of the target collected data. The control unit 11 sends the confirmation screen to user terminal 2 (step S66). The control unit 21 of user terminal 2 receives the confirmation screen (step S67). The control unit 21 displays the confirmation screen (step S68). The verifier confirms the collected data to be confirmed on the confirmation screen and enters the confirmation. The verifier may refer to the confirmation history and confirm only the collected data that has not yet been confirmed by anyone. The control unit 21 receives the confirmation input and sends a confirmation to the server 1 (step S70). The control unit 11 of the server 1 receives the 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 the updated screen and sends the created screen to the user terminal 2 (step S73). The updated screen includes a display to the verifier indicating that the confirmation is complete. The control unit 21 of the user terminal 2 receives and displays the updated screen (step S46). The control unit 21 terminates processing.

[0059] Figure 17 is a flowchart illustrating an example of the procedure for returning data for review. On the approval screen, the approver checks the collected data for each data type and, if they determine that the data should be returned, they input a return. The approver may also determine the destination of the return, which may be the data entry person or the approval level immediately below. The control unit 21 of user terminal 2 receives the return (step S91). The control unit 21 sends the site ID and data type of the collected data to be returned to server 1 (step S92). The control unit 11 of 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 returned the data 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 preferable that the deletion be a logical deletion rather than a physical deletion. The control unit 11 generates a task for the returned data (step S96). The control unit 11 determines whether the returned data is for an input person and whether re-entry of the collected data is required (step S96). If the control unit 11 determines that re-entry 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 site input DB 125 to not submitted. The control unit 11 proceeds to step S100. If the control unit 11 determines that re-entry 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 sends 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). The control unit 21 displays the approval screen (step S102) and terminates the process.

[0060] Next, we will explain the screen displayed on user terminal 2. Figure 18 is an explanatory diagram showing an example of the approval / confirmation screen. The approval / confirmation screen d01 includes the approval target tab d011, the confirmation target tab d012, the site list tab d013, the list table d014, and the approval button d015. When the approval target tab d011 is selected, the collected data to be approved is displayed by data type. The screen when the approval target tab d011 is 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 when the confirmation target tab d012 is selected corresponds to the confirmation screen described above. When the site list tab d013 is selected, a list of the status of collected data for each site is displayed. The list table d014 is a list corresponding 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 table d014 and the approval button d015 is operated, the collected data of the selected data type is approved. When the "Target for Review" tab d012 is selected, the "Approval" button d015 becomes a "Confirmed" button. When the "Location List" tab d013 is selected, the button equivalent to the "Approval" button d015 is not displayed.

[0061] Figure 18 shows the screen when the Approval Target tab d011 is selected. At this time, the list table d014 includes columns for checkboxes, data type, status, number of locations with input, confirmation, and operation. Checking the checkbox for the data type you want to approve and operating the approval button d015 will approve the collected data of the selected data type. Note that items that are not ready for approval cannot be checked. The status column shows the status of the collected data. Statuses include, for example, "In Input," "Submitted," or "Awaiting Approval." "In Input" indicates that a location is inputting the collected data. "Submitted" indicates that the location has completed inputting the collected data and submitted it. Submitted collected data is displayed as "Awaiting Approval" on the approval screen. The confirmation column shows information related to the confirmation of the collected data. The count indicates the number of times the collected data has been confirmed for each data type. The number of locations indicates the number of locations that have confirmed the collected data for each data type. Selecting the three dots in the operation column displays a pull-down menu. From this pull-down menu, you can check the collected data and the comments attached to the collected data. You can also send the data back for review. When a document is returned for revision, it is sent back to a lower-level approver or data entry person. If it is sent back to a lower-level approver, they can either reapprove it after adding comments or send it back again. It may be possible to allow the revision to be sent back to the data entry person even if the approver sending the revision is not directly above them in the hierarchy.

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

[0063] The approval / confirmation screen d01 includes the approval target tab d011, the confirmation target tab d012, the location list tab d013, the list table d016, and the confirmed button d017. The list table d016 includes checkbox columns, company name columns, data type columns, status columns, number of entered locations columns, confirmation columns, and operation columns. Checking the checkbox for the data type you want to confirm and operating the confirmed button d017 will confirm the collected data for the selected data type. Note that items that are not in a state where they can be confirmed cannot be checked. The status column shows the status of the collected data. Statuses include, for example, "Waiting for processing," "Under review," or "Confirmed." "Waiting for processing" indicates that the input of the collected data has not been completed, or that the input has been completed but has not been submitted. "Under review" indicates that the data is in a state where the confirmer can review it. The confirmer can perform the review operation at any time until the collected data is final approved. "Confirmed" indicates that the confirmer has performed the review. The confirmation column shows information related to the confirmation of the collected data. The "Count" column indicates the number of times the collected data was checked for each data type. The "Number of Locations" column indicates the number of locations where the collected data was checked for each data type. Selecting the three dots in the operation column displays a pull-down menu. From this pull-down menu, you can check the collected data and the comments attached to the collected data.

[0064] The status column is a dropdown menu, and by using this menu, you can change the status from "Under Review" to "Reviewed." Additionally, by selecting "Return" from the same dropdown menu, you can request the person responsible for data entry to resubmit the document.

[0065] As described above, this embodiment provides the following effects. By separating confirmation and approval, it becomes possible to approve collected data even if it has not been confirmed, that is, even if the confirmation result is not stored in the confirmation DB 127. As a result, the operation of the collection system 100 makes it possible to finalize the approval of collected data that has never been confirmed. Companies that do not want such an outcome will need to establish operational rules to address this. Therefore, by displaying the number of confirmations and the number of locations that have confirmed the data on the approval / confirmation screen, it is possible to prevent the final approval of collected data that has never been confirmed. In addition to the number of confirmations and locations, it may also be possible to output a confirmation history that shows which level of verifier confirmed the data and when. Furthermore, according to this embodiment, by separating approval and confirmation, it is possible to set the account DB 123 so that end users have confirmation authority but no approval authority. In other words, by having end users other than approvers perform the confirmation, it becomes possible to more reliably confirm the accuracy and legitimacy of the data.

[0066] (Embodiment 2) In Embodiment 1, the verification and approval of collected data were separated, but it is conceivable that there may be a need to ensure that the data is verified by the time approval is granted at a specific approval level, for example, through the data collection system 100. In this embodiment, it is possible to attach conditions for approval when performing approval at a set level.

[0067] Figure 20 is an explanatory diagram showing an example of the approval conditions DB128. The approval conditions DB128 stores approval conditions for each company. That is, when a company becomes an approval group, the approval conditions DB128 stores the conditions under which the collected data can be approved. The approval conditions DB128 includes a company ID column and a condition column. The company ID column stores the company ID. The condition column stores the conditions under which approval can be performed.

[0068] Figure 21 is a flowchart showing another example of the extraction process. As explained with reference to Figure 15, the extraction process is the process of extracting the collected data that the approver needs to approve. The control unit 11 of Server 1 obtains 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 obtains the authority role from the authority role DB 124. The control unit 11 obtains the collected data awaiting the approver's approval (step S112). The control unit 11 obtains the site ID and data type of the collected data awaiting the approver's approval from the approval DB 126. The control unit 11 uses the site ID and data type as search keys to obtain the actual collected data awaiting approval from the site input DB 125. 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 are approval conditions (NO in step S113), it obtains determination data to determine the approval conditions (step S114). The determination data is, for example, the number of confirmations. At this time, the control unit 11 obtains confirmation data from the confirmation DB 127 and calculates the number. Using the determination data, the control unit 11 narrows down the collected data awaiting approval to only those that match the approval conditions (step S115). The control unit 11 obtains confirmation data for the collected data awaiting approval from the confirmation DB 127 (step S116). If confirmation data has already been obtained in step S114, the process is skipped. The control unit 11 returns the process to the caller.

[0069] In this embodiment, it is possible to attach conditions for approval when granting approval. While the above description assumes that approval conditions can be set on a company-by-company basis, this is not limited to that. Different conditions may be applied to multiple levels within the same company. For example, when approval is performed at multiple levels within a company, approval conditions may be attached to one level while not being attached to others. Alternatively, approval conditions may be attached to all levels, but their content may differ.

[0070] Although the present invention has been described above using 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 or improvements can be made to the above embodiments. It will be clear from the claims that such modified or improved forms may also be included in the technical scope of the present invention.

[0071] It should be noted that the execution order of operations, procedures, steps, and stages in the devices, systems, programs, and methods shown in the claims, specifications, and drawings is not explicitly stated as "before," "prior to," etc., and that these can be implemented in any order unless the output of a previous process is used in a later process. Even if the operation flow in the claims, specifications, and drawings is described using phrases such as "first," "next," etc. for convenience, it does not mean that it is essential to perform the operations in that order.

[0072] Furthermore, aspects of each embodiment can be embodied in whole or in part by a computer. As an example of such a computer, a program installed on such a computer can cause the computer to function as an operation associated with an apparatus according to an embodiment of the present invention, or as one or more "parts" of such apparatus. Alternatively, the program can cause the computer to execute such operation or one or more "parts." The program can cause the computer to execute a process or a stage of such process according to an embodiment of the present invention. Such a program may be executed by the CPU to cause the computer to execute a particular operation 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 Unit 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: Branch Database 123: Account DB 124: Permission Role DB 125: Site Input DB 126: Approval DB 127: Confirmation DB 128: Approval condition DB 13: Communications Department 14: Reading section 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 the collected data and the state of the collected data, The aforementioned collected data is received, When a confirmation result indicating that the collected data has been verified is received, the confirmation result is stored in the storage unit in association with the collected data. The data on whether the collected data is approved or not will be received. If the received approval / rejection 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 method that performs processing.

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

3. The aforementioned approval group is the approval group that corresponds to the location where the collected data was entered. The information processing method according to claim 2.

4. If there is a parent group whose child group is the aforementioned approval group, and the parent group receives approval / rejection data indicating approval of the collected data from a user belonging to the child group, the parent group generates the approval task indicating that it is the next approval group. The generated approval task is stored in the storage unit. The information processing method according to claim 2 or 3.

5. When a request to transmit 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 / rejection data for the collected data is rejected, 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 the storage unit that stores the collected data and the state of the collected data. The aforementioned collected data is received, When a confirmation result indicating that the collected data has been verified is received, the confirmation result is stored in the storage unit in association with the collected data. The data on whether the collected data is approved or not will be received. If the received approval / rejection 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 comprising a control unit and having access to a storage unit that stores collected data and the state of the collected data, The control unit, The aforementioned collected data is received, When a confirmation result indicating that the collected data has been verified is received, the confirmation result is stored in the storage unit in association with the collected data. The data on whether the collected data is approved or not will be received. If the received approval / rejection 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