Provision calculation system
The payment calculation system addresses the challenge of calculating transportation expenses for employees with multiple employers by using route information and usage records to accurately determine daily expenses, enhancing precision and reducing administrative complexities.
Patent Information
- Application Number
- JP2024101744
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2024-06-25
- Publication Date
- 2025-04-09
- Estimated Expiration
- 2043-09-27
AI Technical Summary
Existing systems struggle to accurately calculate transportation expenses for employees who belong to multiple employers, as they fail to account for daily variations in route usage.
A payment calculation system that acquires route information and usage records for each employer, allowing for the calculation of transportation expenses based on the specific routes used by employees, even if they work for multiple employers.
Enables precise calculation of transportation expenses for employees with multiple work affiliations, ensuring accurate payments based on actual route usage, thereby reducing administrative burdens and errors.
Smart Images

Figure 2025058886000001_ABST
Abstract
Description
[Technical field]
[0001] The present invention relates to a system for assisting in the calculation of payment amounts for payment recipients, and in particular to a payment calculation system suitable for calculating payment amounts when paying transportation expenses to employees belonging to multiple workplaces according to the commuting routes they use. [Background technology]
[0002] Conventionally, as a technology for calculating commuting allowances and linking them to wages when changes occur due to new commuting expenses, route changes, terminations, etc., the technology described in Patent Document 1, for example, is known.
[0003] The technology described in Patent Document 1 is a technology that works in conjunction with a payroll system to calculate the amount of commuting expenses to be included in salary when an application for commuting expenses is made, a route change, or termination is made, and it creates definitions regarding the company's commuting allowance payment standards and calculation methods.When application data for commuting expenses is input, the application data is converted into commuting allowance data based on the commuting allowance definition, and when the amount of commuting expenses to be included in salary is settled, an update process is performed to recalculate the commuting allowance data. [Prior art documents] [Patent documents]
[0004] [Patent Document 1] JP 2016-192201 A Summary of the Invention [Problem to be solved by the invention]
[0005] However, the technology described in Patent Document 1 is not configured on the assumption that one employee belongs to multiple workplaces, so there is a problem in that it is not possible to know which workplace an employee who receives daily travel expenses actually attended on each working day, making it difficult to calculate the amount of travel expenses to be paid.
[0006] Therefore, the present invention has been made with a focus on the unresolved problems of such conventional technology, and aims to provide a payment calculation system that is suitable for calculating the payment amount when paying transportation expenses to employees belonging to multiple workplaces according to the commuting route they use. [Means for solving the problem]
[0007] [Invention 1] In order to achieve the above object, the payment calculation system of Invention 1 comprises: route information acquisition means for acquiring route information regarding the routes used by a single payment recipient to travel between the home and each of multiple workplaces to which the single payment recipient belongs; usage history information acquisition means for acquiring usage history information regarding the single payment recipient's actual usage of multiple routes; and payment amount calculation means for calculating a payment amount for transportation expenses when the single payment recipient uses multiple routes, based on the route information acquired by the route information acquisition means, the usage history information acquired by the usage history information acquisition means, and fare information stored in a fare information storage means for storing fare information regarding fares related to the routes.
[0008] In this configuration, the route information acquisition means acquires route information on routes used by one payee for each of multiple workplaces, and the usage history information acquisition means acquires usage history information on the usage history of the multiple routes by one payee. Then, the payment amount calculation means calculates the payment amount of transportation expenses when one payee uses multiple routes based on the acquired route information and usage history information, and the fare information in the fare information storage means.
[0009] Here, the present system may be realized as a single device, terminal, or other equipment, or may be realized as a network system in which multiple devices, terminals, or other equipment are communicatively connected. In the latter case, each component may belong to any one of the multiple devices, etc., as long as they are communicatively connected to each other.
[0010] [Invention 2] Furthermore, the payment calculation system of Invention 2 is the payment calculation system of Invention 1, wherein the route information acquisition means and the usage history information acquisition means acquire the route information and usage history information corresponding to a plurality of routes from a storage means which stores, in association with each other, route information regarding a route used by the one payment recipient among the plurality of routes used by the one payment recipient and usage history information regarding the actual usage of the route by the payment recipient.
[0011] With this configuration, the route information acquisition means and the usage history information acquisition means acquire from the storage means route information regarding the routes used by a single grant recipient and usage history information regarding the grant recipient's actual use of the routes for multiple routes used by the grant recipient.
[0012] [Invention 3] Furthermore, the payment calculation system of Invention 3 is the payment calculation system of Invention 1, further comprising route information registration means which, upon obtaining approval through an approval process, is capable of registering route information regarding the routes used by said one payment recipient in the route information storage means for a plurality of said routes, and usage history information registration means which, upon obtaining approval through an approval process, registers usage history information regarding the actual use of the route by said one payment recipient in the usage history information storage means, in association with route information regarding the route used by said one payment recipient among the route information in the route information storage means, and said route information acquisition means and said usage history information acquisition means acquire the route information and the usage history information corresponding to the plurality of said routes from the route information storage means and the usage history information storage means.
[0013] With this configuration, the route information registration means registers route information regarding a route used by one payee in the route information storage means upon approval through the approval process. At this time, one payee can register route information for multiple routes. Furthermore, the usage history information registration means registers usage history information regarding the actual usage of the route by the payee in the usage history information storage means, in association with route information regarding the route used by the one payee among the route information in the route information storage means, upon approval through the approval process. Then, the route information acquisition means and the usage history information acquisition means acquire, for multiple routes used by one payee, route information regarding the route used by the one payee and usage history information regarding the actual usage of the route by the payee from the route information storage means and the usage history information storage means. Effect of the Invention
[0014] As described above, according to the payment calculation system of the present invention 1, it is possible to calculate the payment amount when paying transportation expenses according to the route used to a payment recipient belonging to multiple workplaces. [Brief description of the drawings]
[0015] [Figure 1] 1 is a block diagram showing a configuration of a network system according to an embodiment of the present invention; [Diagram 2] FIG. 2 is a diagram illustrating a hardware configuration of a commute expense calculation server 100. [Diagram 3] 4A and 4B are diagrams showing the data structures of a company master table 400, a workplace master table 402, an employee information master table 404, an employee-specific route information table 406, and an employee-specific payment information table 408. [Figure 4] 4A and 4B show data structures of an employee daily pro rata pay information table 410, a department information table 412, a system environment information table 414, a batch job definition information table 416, and a task scheduler information table 418. [Diagram 5] 4 is a diagram showing the data structure of a fare information table 420. FIG. [Figure 6] 13 is a flowchart showing a new commute route information application process. [Figure 7] FIG. 5 shows a commute route application screen 510. [Figure 8] FIG. 5 shows a commute route application screen 520. [Figure 9] FIG. 5 shows an employee information list screen 500. [Figure 10] 13 is a flowchart showing a payment information addition / modification process. [Figure 11] FIG. 8 shows a route list screen 800. [Figure 12] FIG. 8 shows a payment information list screen 801. [Figure 13] 13 is a flowchart showing a salary linkage basic data creation task registration process. [Figure 14] FIG. 13 is a diagram illustrating an example in which the amount of commuting expenses paid fluctuates. [Figure 15] 13 is a flowchart showing the execution process of the payroll linkage batch processing program. [Figure 16] FIG. 13 is a diagram showing a flow of execution processing of a batch processing main program by a task scheduler in the batch server 150. [Figure 17] This is a time chart showing the calculation of payment information related to fare revisions and daily payment information. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0016] BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a schematic diagram showing an embodiment of the present invention; FIG.
[0017] In this embodiment, the term "employee" refers to a full-time employee, a part-time employee, or any other employee. 〔composition〕 First, the configuration of this embodiment will be described.
[0018] FIG. 1 is a block diagram showing a configuration of a network system according to the present embodiment. As shown in FIG. 1, the Internet 199 is connected to a commuter expense calculation server 100 that provides a service that assists in the calculation of commuter expense calculation and the calculation of the amount of commuter expense payment (hereinafter referred to as the "commuter expense / salary linkage support service"), a batch server 150 that executes update processing of various basic data for calculating the amount of commuter expense payment, a database server 170 that manages various table information used by the commuter expense calculation server 100 and the batch server 150, and employee terminals 200 installed for each employee of the company that uses the commuter expense / salary linkage support service.
[0019] [Hardware configuration of commuter travel expense calculation server 100] Next, the configuration of the commute expense calculation server 100 will be described.
[0020] FIG. 2 is a diagram showing a hardware configuration of the commute expense calculation server 100. As shown in FIG. As shown in Figure 2, the commuter expense calculation server 100 is composed of a CPU (Central Processing Unit) 30 which controls calculations and the entire system based on a control program, a ROM (Read Only Memory) 32 which has the control program etc. of the CPU 30 stored in advance in a specified area, a RAM (Random Access Memory) 34 for storing data read from the ROM 32 etc. and calculation results required in the calculation process of the CPU 30, and an I / F (InterFace) 38 which mediates the input and output of data to and from external devices, and these are connected to each other and capable of sending and receiving data by a bus 39, which is a signal line for transferring data.
[0021] The I / F 38 is connected to external devices such as an input device 40 consisting of a keyboard, mouse, etc. that can input data as a human interface, a storage device 42 that stores data, tables, etc. as files, a display device 44 that displays a screen based on an image signal, and a signal line for connecting to the Internet 199.
[0022] [Hardware configuration of the batch server 150 and the database server 170] Next, the configurations of the batch server 150 and the database server 170 will be described.
[0023] The batch server 150 and the database server 170 have the same hardware configuration as the commute expense calculation server 100 .
[0024] [Hardware configuration of employee terminal 200] The employee terminal 200 is composed of a terminal assumed to be a stationary type like the commuter travel expense calculation server 100, or a mobile terminal such as a smartphone or tablet. In the former case, the hardware configuration is the same as that of the commuter travel expense calculation server 100. On the other hand, in the latter case, the hardware configuration is composed of a CPU, a ROM that stores programs such as application software and data for executing the programs, a RAM for storing data read from the ROM and the calculation results required in the CPU's calculation process, and an I / F that mediates the input and output of data to various attached devices. These are connected to each other and capable of sending and receiving data by signal lines for transferring data.
[0025] To the I / F, various accessory devices are connected, such as a touch panel display input device that allows data input and can display a screen based on an image signal, a storage device, a wireless communication device, a video camera, and the like.
[0026] [About the various tables] Next, the data structures of the various tables stored in the storage device of the database server 170 will be described.
[0027] 3(a) to (e) are diagrams showing the data structures of a company master table 400, a workplace master table 402, an employee information master table 404, an employee-specific route information table 406, and an employee-specific payment information table 408.
[0028] As shown in Figures 3(a) to (e), the storage device of the database server 170 stores a company master table 400 for registering company information, a workplace master table 402 for registering information on the workplace of each company, an employee information master table 404 for registering employee information, an employee-specific route information table 406 for registering information on the commuting route for each employee, and an employee-specific payment information table 408 for registering commuting expense payment information for each employee.
[0029] As shown in Fig. 3(a), one record is registered for each combination of company ID and application start date in the company master table 400. Each record contains main information including company ID, company name, application control category, employee group category information, application start date, application end date, last update date, last updater, and other information.
[0030] Here, the company ID is information for identifying a company, and is composed of, for example, a unique number for each company (for example, numbers only or a combination of letters and numbers), etc. Also, the application control category is information that sets whether applications from employees can be accepted, and the employee group category information is information that indicates categories such as job type, office, and affiliation between paid employee groups and other employee groups.
[0031] 3(b), one record is registered for each combination of company ID, workplace ID, and application start date in the workplace master table 402. Each record contains main information including company ID, workplace ID, workplace name, workplace address, calendar ID, start time, end time, fuel unit price type ID, map information, application start date, application end date, last update date, last updater, and other information.
[0032] Here, the workplace ID is information for identifying the workplace, and is composed of, for example, a unique number for each workplace (for example, numbers only, a combination of letters and numbers). The calendar ID is information for identifying a calendar in which the business days and holidays of the workplace set for each company are written, and is composed of, for example, a unique number for each type of calendar (for example, numbers only, a combination of letters and numbers). The fuel unit price type ID is information for identifying a fuel unit price type set for each company, and is composed of, for example, a unique number for each unit price type (for example, numbers only, a combination of letters and numbers). The fuel unit price types include unit price types for each fuel, such as gasoline (regular), gasoline (high octane), and diesel (diesel), and unit price types for each type of eco-friendly automobile, such as EV (electric vehicle), PHV (plug-in hybrid electric vehicle), and FCV (fuel cell vehicle). The map information includes location information of the workplace and information on the nearest station.
[0033] 3(c), one record is registered for each combination of company ID, employee ID, and application start date in employee information master table 404. Each record contains main information including company ID, employee ID, employee name, employee name (kana), employee home postal code, employee home address, telephone number, email address, workplace ID, workplace name, department ID, department name, employee category, payment rule ID, password, authority level, map information, application start date, application end date, last update date, last updater, and other information.
[0034] Here, the department ID is information for identifying the department to which the employee belongs, and is composed of, for example, a unique number for each department (for example, numbers only, or a combination of letters and numbers). The employee classification is information for classifying employees as full-time employees, part-time employees, etc., and the authority level is information indicating one of personnel authority, superior authority, and employee authority. Personnel authority is the authority to use all functions related to commuting expense operations in this system, superior authority is the authority to only apply for commuting routes and approve the contents of the application, and employee authority is the authority to only apply for commuting routes. In addition, the map information includes the location information of the employee's home and information on the nearest station.
[0035] One employee may belong to multiple workplaces. For example, an employee may commute to workplace A in the beginning of the month and to workplace B in the latter half of the month. For this reason, one or multiple workplace IDs and workplace names can be registered for each employee in the employee information master table 404.
[0036] 3(d), one record is registered for each combination of company ID, employee ID, and route ID in the employee-specific route information table 406. Each record contains main information including company ID, employee ID, vehicle ID, route direction type, nearest station to employee's home, workplace ID, workplace name, nearest station to workplace, route ID, commuting route, route usage period, 1-month amount, 3-month amount, 6-month amount, 12-month amount, one-way amount, one-way distance, one-way time, number of transfers, route reference date, application start date, application end date, last update date, last updater, and other information.
[0037] Here, the route direction type is information indicating the direction of the commuting means, and is information on outward, return, or round trip. The route ID is information for identifying the commuting route, and is composed of, for example, a unique number for each commuting route (for example, only numbers, or a combination of letters and numbers). The commuting route is the route from home to the workplace, and for example, if the commuting means is a train, it is "home → walk → nearest station (home) → intermediate station → nearest station (workplace) → walk → workplace", and if the commuting means is a car, it is "home → car → workplace". The 1-month amount, 3-month amount, 6-month amount, and 12-month amount are the amounts of commuting transportation expenses for the 1st, 3rd, 6th, and 12th months for the set commuting means and route direction type, and the route reference date is the reference date on which the commuting route becomes valid.
[0038] When the destination or arrival point of a commuting route is a workplace, the workplace ID and workplace name of the workplace that is the destination or arrival point are registered in association with the commuting route in the employee-specific route information table 406. Also, since one employee may belong to multiple workplaces as described above, one or multiple pieces of route information can be registered for one employee in the employee-specific route information table 406. When registering route information for multiple workplaces, the employee-specific route information table 406 registers the workplace IDs and workplace names for multiple workplaces for one employee.
[0039] 3(e), one record is registered for each combination of company ID, employee ID, route ID, and payment ID in the employee-specific payment information table 408. Each record contains main information including company ID, employee ID, route ID, payment ID, start date, end date, payment date, payment method, payment period, payment months, payment / deduction amount, self-payment amount, type, period, remarks, cancellation date, payment details, number of regular months, number of regular sheets, payment amount, total payment amount, total self-payment amount, and other information.
[0040] Here, the payment ID is information for identifying the payment information, and is composed of, for example, a unique number for each payment information (for example, numbers only, or a combination of letters and numbers). The payment method is information indicating the payment method for commuting expenses, such as incorporation into salary, transfer to a bank account, or payment in kind (cash), and the number of months for which payment is made and the number of regular months are either 1 month, 3 months, 6 months, or 12 months. The payment details are information indicating whether or not the payment is continuous, whether or not the payment cycle is fixed, and whether or not the fare revision process is applicable.
[0041] 4(a) to (e) are diagrams showing the data structures of an employee daily pro rata pay information table 410, a department information table 412, a system environment information table 414, a batch job definition information table 416, and a task scheduler information table 418.
[0042] 4(a)-(e), the storage device of the database server 170 stores an employee-by-employee daily pro rata payment information table 410 for registering daily pro rata commuter travel expense payment information for each employee, and a department information table 412 for registering information on approvers and proxy applicants for each department. In addition, a system environment information table 414 for registering system environment information such as the IP address of the batch server 150, a batch job definition information table 416 for registering batch job definition information including information on the physical file name of the batch processing program, and a task scheduler information table 418 for registering information for executing tasks registered in the task scheduler are stored.
[0043] 4(a), one record is registered for each combination of company ID, employee ID, route ID, and daily rate ID in employee-specific daily rate payment information table 410. Each record contains main information including company ID, employee ID, route ID, daily rate ID, start date, end date, payment date, payment method, period subject to daily rate payment, number of days subject to payment, type of direction of use (one-way / round trip), payment details, payment amount, total payment amount, and other information.
[0044] Here, the per diem ID is information for identifying the per diem information, and is composed of, for example, a unique number for each per diem information (for example, numbers only or a combination of letters and numbers). The per diem payment period is information indicating the period for which commuting expenses are calculated on a per diem basis, the number of payment days is information on the number of days during the payment period for which commuting expenses are paid on a per diem basis, and the direction type (one-way / round trip) is information indicating the type of route direction used during the payment period. The payment details are information indicating whether or not the fare is subject to fare revision processing.
[0045] 4(b), one record is registered for each company and each department in the department information table 412. Each record contains main information including the company ID, department ID, approver ID, proxy applicant ID, application start date, application end date, last update date, last updater, and other information.
[0046] Here, the approver ID is the employee ID of an employee with supervisor authority who is authorized to approve applications for commuting routes for employees who belong to the department corresponding to the department ID, and the proxy applicant ID is the employee ID of an employee with authority to submit commuting route applications on behalf of other employees who belong to the same department.
[0047] As shown in FIG. 4(c), the system environment information table 414 registers main information including the batch server IP address, batch server user ID, password, service URL, packet name, actual cost packet name, and other information.
[0048] Here, the batch server user ID is information for identifying a user who accesses the batch server 150, and is composed of, for example, a unique number for each user (for example, numbers only, or a combination of letters and numbers). Also, the packet name is a packet name used in creating the payroll linkage basic data, and the actual cost packet name is a packet name used in processing actual costs.
[0049] As shown in FIG. 4D, the batch job definition information table 416 registers main information including a tenant number, a batch process ID, a batch name, a batch path, a batch physical file name, and other information.
[0050] Here, the tenant number is the number of the tenant executing batch processing such as the creation processing of payroll linked basic data. The batch processing ID is information for identifying the type of batch processing, and is composed of, for example, a unique number for each type of batch processing (for example, numbers only, or a combination of letters and numbers). The batch path is the physical path (on the batch server 150 side) where the batch processing program is saved, and the batch processing physical file name is the physical file name of the batch processing program.
[0051] 4(e), one record is registered for each combination of a tenant number, a batch processing ID, and a task ID in the task scheduler information table 418. Each record registers main information including the tenant number, the batch processing ID, the batch processing path, parameter information, the task ID, the status, the execution flag, and other information.
[0052] Here, the batch processing path is information indicating the physical file name (full path) of the batch processing main program that controls the batch processing, and the parameter information is parameter information read by the batch processing. For example, in the case of a batch processing that creates basic payroll linkage data (hereinafter referred to as "payroll linkage batch processing"), the information is for identifying payment information in which there has been a change in the amount of payment for commuting expenses, and includes the company ID, employee ID, payment ID (and the prorated ID in the case of prorated payment information), etc.
[0053] FIG. 5 is a diagram showing the data structure of the fare information table 420. As shown in FIG. As shown in FIG. 5, the storage device of the database server 170 stores a fare information table 420 for registering fare information related to fares for transportation such as trains and buses.
[0054] As shown in Fig. 5, the fare information table 420 has one record registered for each fare ID. Each record has registered main information including the fare ID, section information (e.g., the station numbers of the departure station and arrival station), fare type (e.g., 1-month fare, 3-month fare, 6-month fare, 12-month fare, one-way fare), fare, fare revision date, last update date, last updater, and other information. When a fare revision occurs, records with different revision dates are registered for the same section. In this case, the fare related to the record with the older revision date can be identified as the fare before revision, and the fare related to the record with the newer revision date can be identified as the fare after revision.
[0055] The commuting expenses of an employee can be calculated by accumulating the fare for the commuting route based on the route information in the employee route information table 406 and the fare information in the fare information table 420. In addition, when the commuting expenses are paid on a per diem basis, the calculation can be performed by accumulating the fare for the commuting route based on the route information in the employee route information table 406, the per diem payment information in the employee per diem payment information table 410, and the fare information in the fare information table 420. The commuting expenses can be calculated using known technology (for example, JP 2003-90733 A).
[0056] Although not shown, the storage device of database server 170 stores, in addition to tables 400 to 418, tables in which various definition data for calculating commuting expenses and tables in which various basic data for linking commuting expenses with salary are registered. Specific examples of basic data tables include a salary basic data table, a taxation basic data table, a social insurance basic data table, and an employment insurance basic data table.
[0057] Here, the basic salary data is data on the amount of commuting allowance paid, the basic tax data is data on the taxable or non-taxable amount for the commuting allowance paid, the basic social insurance data is data on the social insurance insurance amount for the commuting allowance paid, and the basic employment insurance data is data on the employment insurance insurance amount for the commuting allowance paid.
[0058] [Operation] Next, the operation of this embodiment will be described. [New commute route information application process] First, the operation of commute travel expense calculation server 100 when an employee newly applies for commute route information will be described. Note that, in reality, access to tables 400-418 is performed by commute travel expense calculation server 100 communicating with database server 170, but for the sake of simplicity, the following description will be given assuming that commute travel expense calculation server 100 accesses tables 400-418.
[0059] FIG. 6 is a flowchart showing the process for applying for new commute route information. CPU 30 is made up of an MPU (Micro-Processing Unit) or the like, and starts up a predetermined program stored in a predetermined area of ROM 32, and executes the new commute route information application process shown in the flowchart of FIG. 6 in accordance with the program.
[0060] When the new commute route information application process is executed by the CPU 30, as shown in FIG. 6, it first proceeds to step S100 to determine whether or not a new application request has been received from the employee terminal 200, and if it is determined that a new application request has been received (YES), it proceeds to step S102.
[0061] Here, new applications for commute route information are made, for example, when a new employee registers commute route information for the first time, when an employee moves and their commute route changes, or when an employee's place of employment is added or changed.
[0062] In step S102, an application information input process is executed. In the application information input process, commuting route information such as a commuting means (vehicle ID), a reason for application, a nearest station to the employee's home, a nearest station to the workplace, and a route direction type can be input via an input screen.
[0063] FIG. 7 is a diagram showing commute route application screen 510. In the application information input process, first, a commute route application screen 510 is displayed as shown in Fig. 7. On the commute route application screen 510, the applicant (employee) inputs the application start date, commuting means, transportation company, reason for application, employee home address, company name, place of work, and route direction type, etc.
[0064] As for the employee home address, the employee home address corresponding to the applicant's employee ID is obtained from the employee information master table 404 and displayed.
[0065] For the place of employment, the place of employment corresponding to the applicant's employee ID is obtained from the employee information master table 404 and displayed in the drop-down list 52. If multiple places of employment are registered for one employee, multiple places of employment are displayed in the drop-down list 52. The applicant selects one of these places of employment.
[0066] The route direction type can be selected from one of three options: "Outbound," "Return," and "Round trip." In other words, you can set separate commuting routes for the outbound, return, and round trip if you are only using the outbound route, if you are only using the return route, if the commuting routes are different for the outbound and return routes, or if you are using both the outbound and return routes.
[0067] FIG. 8 is a diagram showing commute route application screen 520. The applicant enters other commute route information and clicks the “Next” button 53, which displays the commute route application screen 520 as shown in Figure 8. On the commute route application screen 520, the applicant enters the nearest station to the employee's home, any intermediate stations, the nearest station to the workplace, etc.
[0068] For the nearest station to the employee's home, the nearest station to the employee's home that corresponds to the applicant's employee ID is obtained from the employee information master table 404 and displayed in the text box 54. If multiple nearest stations to the employee's home are registered, multiple nearest stations are displayed in the text box 54. The nearest station to the employee's home can also be manually entered by clicking the "Search" button 55.
[0069] For the nearest station to the workplace, the nearest station to the workplace selected on the commute route application screen 510 that corresponds to the applicant's employee ID is obtained from the employee information master table 404 and displayed in text box 56. If multiple nearest stations to the workplace are registered, multiple nearest stations are displayed in text box 56. The nearest station to the workplace can also be manually entered by clicking the "Search" button 57.
[0070] The applicant enters other commuting route information and clicks the "Next" button 58, which displays candidate commuting routes between the nearest station to the employee's home and the nearest station to the workplace. If there are multiple nearest stations to the employee's home or workplace, candidate commuting routes between the nearest station to the employee's home and the nearest station to the workplace are displayed for all combinations of those nearest stations. The applicant can select one of the candidate commuting routes displayed and apply for the selected commuting route as their commuting route.
[0071] Next, the process proceeds to step S104 to determine whether or not a registration application has been received from the employee terminal 200. If it is determined that a registration application has been received (YES), the process proceeds to step S106.
[0072] In step S106, information on the applicant's department (department ID) is obtained from employee information master table 404, and approval destination information (employee ID of employee with approval authority) corresponding to the obtained department ID is obtained from department information table 412.
[0073] Here, the department ID is identification information dedicated to the workflow, and it is possible to set employees across multiple different real organizations to have the same department ID. For example, the same department ID "B1" can be set for employees A to D who belong to the general affairs department, which is a real organization, and employees F to I who belong to the sales department, which is also a real organization. Note that the real organizations are registered using the employee group ID in the employee information master table 404.
[0074] Also, for example, suppose that employees A and F are employees with supervisor authority and are given approval authority in the workflow. Also, suppose that employee E is a general employee and is given proxy application authority. Here, approval authority is the authority to approve the application contents of employees who belong to the same department (e.g. B1) in the workflow, and proxy application authority is the authority for employees other than the human resources department to make applications on behalf of other employees. In other words, employees A and F who have approval authority can approve applications made by employees B to E and G to I in the same department B1. Also, employee E who has proxy application authority can process applications on behalf of employees A to D and F to I in the same department B1.
[0075] This allows approval processing and proxy application processing to be performed across different real organizations, even if the real organizations are different, as long as they are managed with the same department ID defined in the department information table 412. In other words, an amoeba-like approval route can be constructed.
[0076] Next, the process proceeds to step S108, where an approval route is constructed based on the obtained approval destination information, and then an approval request for the application information is sent to each approver at the route destination based on the constructed approval route.
[0077] For example, when a general employee (other than A and F) belonging to department B1 applies for a commuting route, approval is given to both employees A and F, and after approval, it is inspected by employees with personnel authority (hereafter referred to as "personnel employees"), for example, the three personnel employees J through L in charge of department B1. Note that personnel employees have the authority to inspect any department.
[0078] In other words, the approval route will first be "employees A and F," and after employee A approves first, it will be "employee A → HR employees J~L." On the other hand, after employee F approves first, it will be "employee F → HR employees J~L." In other words, approval only needs to be done by either employee A or F, and approval by both is not required. In addition, inspection after approval will be carried out by the three HR employees J~L in charge of department B1, and inspection only needs to be carried out by any one of HR employees J~L.
[0079] In this way, approval and inspection are carried out, and the application is permitted, and the application information is registered in employee-specific route information table 406, employee-specific payment information table 408, and employee-specific daily payment information table 410. In other words, when a new commuting route is registered, a change occurs in the payment information or daily payment information stored in employee-specific payment information table 408 or employee-specific daily payment information table 410, causing a change in the amount of commuting expenses paid.
[0080] When the process of step S108 ends, the series of processes ends and the process returns to the original process. On the other hand, if it is determined in step S104 that a registration application has not been received (NO), the process proceeds to step S110 to determine whether or not a cancellation request has been received from the employee terminal 200, and if it is determined that a cancellation request has been received (YES), the process ends and returns to the original process.
[0081] On the other hand, if it is determined in step S110 that a cancellation request has not been received (NO), the process proceeds to step S104.
[0082] On the other hand, if it is determined in step S100 that a new application request has not been received (NO), the process waits in step S100 until a new application request is received.
[0083] [Payment information addition / modification processing] Next, the operation when a personnel staff member adds or modifies the payment information registered in the employee-specific payment information table 408 and the employee-specific daily prorated payment information table 410 will be described.
[0084] FIG. 9 is a diagram showing the employee information list screen 500. When a human resources employee logs in to the commuter expense / salary linking service provider page with an account having human resources authority, the top page of the service is displayed on the display device of the employee terminal 200 of the human resources employee. Although not shown in the figure, this top page displays main menu buttons such as "Application," "Employee Information," and "Business Master." Although not shown in the figure, these main menu buttons are always displayed at the top of the screen and can be selected from pages other than the top page. Then, when the human resources employee selects the "Employee Information" menu button via the employee terminal 200 (by pressing the mouse or touching with a finger, etc.), the employee information list screen 500 shown in FIG. 9 is displayed on the display device. Here, the human resources employee has the authority to perform tasks related to the calculation of the commuter expense payment amount.
[0085] The payment information addition / modification process is a process executed on the route list screen 800 that is displayed after selecting an employee to be added or modified on the employee information list screen 500 and selecting the route list button 51. The route list screen 800 displays one or more approved commuting routes used by the selected employee. If the selected employee belongs to multiple workplaces, the route list screen 800 displays the commuting route from home to the workplace or from the workplace to home for each of the multiple workplaces.
[0086] Fig. 10 is a flow chart showing the payment information addition / modification process, Fig. 11 is a diagram showing a route list screen 800, Fig. 12 is a diagram showing a payment information list screen 801, and Fig. 13 is a diagram showing a payment information list screen 801.
[0087] When the payment information addition / modification process is executed by CPU 30, as shown in FIG. 10, first, the process proceeds to step S200.
[0088] In step S200, it is determined based on information from the employee terminal 200 whether the Modify Route button 80 has been selected for a commuting route selected from the list of commuting routes for the selected employee displayed on the route list screen 800. If it is determined that the Modify Route button 80 has been selected (YES), the screen information of the payment information list screen 801 is sent to the employee terminal 200. In other words, when the Modify Route button 80 is selected on the route list screen 800 shown in FIG. 11, the payment information list screen 801 shown in FIG. 12 is displayed on the display device of the employee terminal 200.
[0089] Next, the process proceeds to step S202, where it is determined based on information from the employee terminal 200 whether or not the Add button 82 has been selected on the payment information list screen 801. If it is determined that the Add button 82 has been selected (YES), screen information of the payment information setting screen is sent to the employee terminal 200. That is, when the Modify button 83 is selected with pro rata payment information selected on the payment information list screen 801 shown in FIG. 12, a pro rata payment information setting screen (not shown) is displayed on the display screen of the employee terminal 200. Note that, although not shown, when the Modify button 83 is selected with regular payment information selected, a screen that allows additional setting of regular payment information different from the pro rata payment information setting screen is displayed, and when the Add button 82 is selected with nothing selected, a screen that allows additional setting of both regular and pro rata payment information is displayed.
[0090] Next, the process proceeds to step S204, where a payment information addition process is executed. As the payment information addition process, a process for adding payment information based on information input by a human resources employee on the pro rata payment information setting screen will be described.
[0091] The personnel staff inputs the necessary information on the pro rata payment information setting screen via the staff terminal 200. Specifically, the pro rata payment period, the number of days for payment, and the type of direction of use (one way / round trip) are input. The pro rata payment information is information that is set, for example, when the joining date is an odd day and the employee starts working partway through the month, and commuting expenses are paid on a pro rata basis only for the days the employee works in that month. Or, for example, when the employee needs to work from home due to the spread of an infectious disease, and the employee works only two days a week, the commuting expenses are paid on a pro rata basis only for the days the employee works. Therefore, the period subject to the pro rata payment is set as the period subject to the pro rata payment.
[0092] Here, the type of direction of travel is selected as "round trip" if the same commute route was used on the outbound and return journeys, and selected as "one way" if different commute routes were used on the outbound and return journeys or if only one way was used. This allows round trip or one way to be set commonly for each date in the payment period. Also, if there are days when the same commute route was used only one way and days when it was used both ways, the type of direction of travel can be set individually for each date after selecting either one way or round trip.
[0093] Furthermore, after inputting the pro rata payment information, when an OK button (not shown) displayed on the pro rata payment information setting screen is selected, it is determined that input of the pro rata payment information is complete, and the screen returns to the payment information list screen 801 shown in Fig. 12. Then, the newly input pro rata payment information is added to the list on the payment information list screen 801, and when the Confirm button at the bottom right is selected, the new pro rata payment information is added to the employee pro rata payment information table 410. In other words, the addition of new pro rata payment information causes a change in the payment amount of commuting expenses.
[0094] When the process of step S204 ends, the series of processes ends and the process returns to the original process. On the other hand, if it is determined in step S202 that the Add button 82 has not been selected (NO), the process proceeds to step S206, where it is determined, based on information from the employee terminal 200, whether or not the Modify button 83 has been selected for the selected payment information on the payment information list screen 801. If it is determined that the Modify button 83 has been selected (YES), screen information for the payment information setting screen is transmitted to the employee terminal 200. That is, if the Modify button 83 is selected with pro rata payment information that has already been registered selected on the payment information list screen 801 shown in Fig. 12, the pro rata payment information setting screen is displayed on the display screen of the employee terminal 200 with information already entered.
[0095] Next, the process proceeds to step S208, where payment information correction processing is executed. The payment information correction processing is processing for correcting information already entered on the pro rata payment information setting screen, and is similar to the payment information addition processing except for whether new information is entered or already entered information is changed (corrected), so a description thereof will be omitted. Furthermore, correction of the pro rata payment information causes a change in the pro rata payment amount for commuting expenses in the pro rata payment information stored in employee-specific pro rata payment information table 410. When the processing of step S208 is completed, the series of processing is terminated and the process returns to the original processing.
[0096] On the other hand, if it is determined in step S206 that the Modify button 83 has not been selected (NO), the process proceeds to step S210, where it is determined whether or not any other button has been selected other than the Add button 82 and the Modify button 83. If it is determined that any other button has been selected (YES), screen information of the screen corresponding to the other button is transmitted to the employee terminal 200, and the process proceeds to step S212.
[0097] In step S212, a process corresponding to the selected other button is executed. The other buttons include a cancel button, a delete button, a confirm button, and a cancel button, as shown in Fig. 12. When the cancel button is selected, a process for canceling the commuter pass is executed, when the delete button is selected, a process for deleting the selected payment information is executed, and when the cancel button is selected, a process for canceling the commuter route correction and returning to the route list screen 800 is executed. When the process in step S212 is completed, the series of processes is terminated and the original process is resumed.
[0098] On the other hand, if it is determined in step S210 that no other button has been selected (NO), the process proceeds to step S202.
[0099] On the other hand, if it is determined in step S200 that the route modification button 80 has not been selected (NO), the process waits in step S200 until the route modification button 80 is selected.
[0100] [Payment information addition / modification processing] Regular employees can also use the same functions as the payment information addition / modification process described above. Regular employees can add to their own payment information. However, the difference is that the content of the payment information added by regular employees is finalized after obtaining approval from the approval authority.
[0101] [Payroll link basic data creation task registration process] Next, the operation of the commuter travel expense calculation server 100 in the case where a salary linked basic data creation task is registered in the batch server 150 when a change occurs in the amount of commuter travel expense payment will be described.
[0102] FIG. 13 is a flowchart showing the salary-linked basic data creation task registration process. When the payroll linked basic data creation task registration process is executed by the CPU 30, as shown in FIG. 13, first, the process proceeds to step S300.
[0103] In step S300, it is determined whether or not a change has occurred in the payment information in the employee-specific payment information table 408 or the employee-specific daily prorated payment information table 410. If it is determined that a change has occurred in the payment information (YES), the process proceeds to step S302.
[0104] FIG. 14 is a diagram for explaining an example in which the amount of commuting expenses paid fluctuates. As shown in Fig. 14, when an employee applies for a new commute route and the application is approved (permitted) by the superior and the human resources department, payment information according to the newly applied commute route is generated and registered in employee-specific payment information table 408. Similarly, when a human resources employee applies for a new commute route on behalf of an employee, payment information according to the applied commute route is generated and registered in employee-specific payment information table 408. In such cases, it is determined whether there has been a change in the payment information that would change the payment amount.
[0105] In addition, when monthly processing by personnel staff involves, for example, calculations to pay commuting expenses on a pro rata basis, fluctuations occur in the registered information in employee pro rata payment information table 410 that change the payment amount, and these fluctuations are determined to be fluctuations in the payment amount.
[0106] In addition, even if a difference occurs between the amount of payment already paid due to a fare revision, a change occurs in the payment information in the employee-specific payment information table 408 or the employee-specific daily pro rata payment information table 410 due to the payment of the difference, and this change is determined as a change in the payment amount. In addition, after the registration of the daily pro rata payment amount and the adjustment process of the difference due to the fare revision are completed, the salary data is output to the salary linkage system, and then the process of creating the next salary linkage basic data in advance is performed. At this time, if a change occurs in the salary linkage basic data created in advance due to daily pro rata payment or fare revision, a change occurs in the payment information in the employee-specific payment information table 408 or the employee-specific daily pro rata payment information table 410, and therefore it is determined that a change in the payment amount has occurred. A change in the payment amount is determined, for example, by whether or not a revision date has been set in the fare information table 420 after the completion of the salary payment calculation process for the previous commuting expenses payment month.
[0107] In step S302, parameter information related to the payment information in which the payment amount has changed is checked. The parameter information to be checked includes the tenant number of the tenant executing the payroll linkage batch process, the company ID, the ID of the payroll linkage batch process program (hereinafter referred to as the "payroll linkage batch process ID"), and the payment ID of the payment information in which it was determined in step S300 that a change has occurred that has changed the payment amount.
[0108] The payment ID of the payment information that has been subject to a fare revision among the payment information set as the target for fare revision processing (hereinafter referred to as "payment information related to the fare revision") is, for example, as follows: Based on the employee-specific route information table 406 and the fare information table 420, the relevant route information is identified from the section information that has been subject to the fare revision, and the payment ID of the payment information for which commuting expenses have been calculated using the identified route information is obtained from the employee-specific payment information table 408. Parameter information including the obtained payment ID is registered in the task scheduler information table 418 in step S322.
[0109] The payment ID of the pro rata payment information that has been subject to a fare revision among the pro rata payment information set as the target for fare revision processing (hereinafter referred to as "pro rata payment information related to the fare revision") is, for example, as follows: Based on the employee-specific route information table 406 and the fare information table 420, the relevant route information is identified from the section information that has been subject to the fare revision, and the payment ID and pro rata ID of the pro rata payment information for which commuting expenses have been calculated using the identified route information are obtained from the employee-specific pro rata payment information table 410. Parameter information including the obtained payment ID is registered in the task scheduler information table 418 in step S322.
[0110] Next, the process proceeds to step S304, where the physical file name (full path) of the batch processing main program is obtained from the batch job definition information table 416 stored in the storage device 42. Here, the batch processing main program is a program that provides overall control over various batch processes such as payroll linked batch processing, and the batch processing that is executed is controlled by the contents of parameters that are set when the batch processing main program is executed.
[0111] Next, the process proceeds to step S306, where the IP address, login user ID, and password of the batch server 150 are obtained from the system environment information table 414 stored in the storage device 42, and the process proceeds to step S308.
[0112] In step S308, based on the information acquired in step S306, the process logs in to the batch server 150 and establishes a session, after which the process proceeds to step S310.
[0113] In step S310, a task execution condition is created by the task scheduler. The task execution condition is such that the task is executed after a predetermined time (hereinafter referred to as the "start delay time") that takes into account the communication lag with the batch server 150. If the system times of the commuter travel expense calculation server 100 and the batch server 150 are the same, the start delay time is set to, for example, two minutes after the system time of the commuter travel expense calculation server 100. If the system times differ by a predetermined time, the predetermined time by which the system times differ is also taken into account. In other words, the task is scheduled to be executed after the start delay time from the registration of the task schedule, taking into account the communication lag.
[0114] In addition, the commute expense calculation server 100 and the batch server 150 have a task scheduler installed in their operating systems (OS).
[0115] A task scheduler is one of the execution control systems for computer programs, which starts and ends programs based on schedules and conditions specified by the user, and records and reports the execution status and results. This makes it possible to automatically start and end specific commands and executable files on the OS based on a schedule.
[0116] Next, the process proceeds to step S312 to create a task action. The task action is composed of an execution program and execution parameters (arguments given to the execution program). Specifically, the execution program is a batch processing main program, and the execution parameters are the tenant number, the payroll linkage batch processing ID, and the task ID. Here, the task ID is information for identifying the task to be registered in the task scheduler.
[0117] Next, proceed to step S314 to create a deletion setting for the action after the task is completed. Here, the process of creating basic payroll linkage data when there is a change in the payment amount is a process that is performed immediately when a change occurs, and is not a process that is repeated periodically, so a setting is created to delete the action after the task is completed. Specifically, the time until the task is deleted if it is not scheduled to be executed again is set.
[0118] Next, the process proceeds to step S316 to create an instance of the task scheduler. That is, an instance of the batch processing main program (payroll-linked batch processing) to be executed by the task scheduler is created. That is, the batch processing main program, execution parameters, etc. are expanded on the main memory of the batch server 150 so that they can be processed and executed.
[0119] Here, the payroll linkage batch process needs to be executed after it is determined that the commuter transportation allowance payment amount has changed, and before data related to the commuter transportation allowance payment amount and other payment amounts is output to another payroll calculation system. Therefore, it is desirable to execute the payroll linkage batch process promptly after it is determined that a change has occurred in the payment amount.
[0120] Furthermore, in the task scheduler, processing is executed on an instance basis, and a plurality of instances can be executed in parallel.
[0121] Next, the process proceeds to step S318, where the various information created in steps S310 to S316 is registered in the task scheduler. That is, information such as the tenant number, company ID, payroll linkage batch process ID, task schedule (year, month, day, hour, minute), and execution user is registered.
[0122] Next, the process proceeds to step S320, where the session with the batch server 150 is discarded, and the process proceeds to step S322.
[0123] In step S322, task scheduler information, which is information necessary for executing the task registered in the task scheduler, is registered in the task scheduler information table 418. Specifically, the tenant number, batch processing ID, batch processing path, parameter information, task ID, status, execution flag, and other information are registered in the task scheduler information table 418. When the process of step S322 ends, the series of processes ends and the process returns to the original process.
[0124] The processes in steps S308 to S320 are automatically performed using, for example, a command line interface installed in the OS (for example, "Windows PowerShell (registered trademark)" when the OS is Windows).
[0125] On the other hand, if it is determined in step S300 that no change has occurred in the payment information (NO), the process waits in step S300 until a change occurs in the payment information.
[0126] [Payroll link batch processing program execution process] The payroll linkage batch processing program execution process is a process executed by the task scheduler in the batch server 150.
[0127] 15 is a flowchart showing the payroll linkage batch processing program execution process, and FIG. 16 is a diagram showing the flow of the batch processing main program execution process by the task scheduler in the batch server 150.
[0128] The CPU of the batch server 150 starts a predetermined program stored in a predetermined area of the ROM, and executes the payroll linkage batch processing program execution process shown in the flowchart of Figure 15 in accordance with the program.
[0129] When the payroll linkage batch processing program execution process is executed in the CPU, it first proceeds to step S400 as shown in FIG.
[0130] In step S400, it is determined whether or not it is time to execute the registered task. If it is determined that the execution time has arrived (YES), the process proceeds to step S402.
[0131] In this case, as shown in FIG. 16, the task schedule is registered in the task scheduler so that the batch processing main program is executed after the start delay time from registration, so the execution time is after the start delay time from registration.
[0132] In step S402, the execution parameters registered in the task scheduler are checked. Here, the execution parameters are the tenant number, the payroll linkage batch process ID, and the task ID.
[0133] Next, the process proceeds to step S404, where parameter information required for executing the task corresponding to the execution parameters checked in step S402 is obtained from the task scheduler information table 418. Specifically, as shown in Fig. 16, parameter information corresponding to the tenant number, batch processing ID, and task ID of the task to be executed is obtained as the parameter information.
[0134] Next, the process proceeds to step S406, where the batch processing main program is executed based on the various information registered in the task scheduler and the parameter information acquired in step S404, and the payroll linkage batch processing program is executed. The batch processing main program reads out the payroll linkage batch processing program (module) corresponding to the payroll linkage batch processing ID, for example, from a batch processing business module library (not shown) stored in the storage device of the batch server 150. Then, the read out payroll linkage batch processing program is executed.
[0135] When the payroll linkage batch processing program is executed, as shown in FIG. 16, the calculated values of the payroll linkage basic data (salary basic data, taxation basic data, social insurance basic data, and employment insurance basic data) are recalculated based on the changes in the payment information corresponding to the parameter information acquired in step S404, and the calculated values of the various basic data registered in the various basic data tables are updated to the recalculated data.
[0136] Here, the salary payment calculation process for calculating the amount of commuting expenses includes a first calculation process for calculating the amount of commuting expenses and the amount of payment that varies depending on the commuting expenses out of the amount of payment paid to the employee. The salary payment calculation process also includes a second calculation process for calculating other payment amounts (e.g. overtime pay, etc.). Furthermore, there is a third calculation process for calculating the payment amount based on the results of the first and second calculation processes. Note that the second and third calculation processes are processes performed, for example, in another salary calculation system. In the salary linkage batch process, the first calculation process is executed.
[0137] The payroll link batch process does not calculate the amount of commuting expenses to be paid in the current month all at once, but instead distributes the calculations over time for each payment information unit. For example, when a new or changed commuting route is applied, the payment amount for that application is calculated at that time, and when a fare revision is made, the payment amount for the fare revision is calculated at that time.
[0138] Furthermore, in the salary linkage batch processing, the amount of commuter transportation expenses is calculated for each predetermined period (for each month in which commuter transportation expenses are paid (for example, every month, every three months, etc.)). Therefore, the salary linkage batch processing program is executed within the period from the completion of the salary payment calculation process for the previous commuter transportation expenses payment month to the execution timing of the salary payment calculation process for the next commuter transportation expenses payment month. Here, "execution timing of the salary payment calculation process" refers to the timing when the second calculation process and the third calculation process are executed, when the second calculation process and the third calculation process are, for example, monthly batch processes. Furthermore, in the salary payment calculation process for the commuter transportation expenses payment month, the uncalculated calculation processes of the first calculation process, second calculation process, and third calculation process are executed.
[0139] FIG. 17 is a time chart showing a case where payment information related to a fare revision and daily pro rata payment information are calculated.
[0140] In the example of FIG. 17, if a fare revision occurs after the completion of the previous salary payment calculation process, and this fare revision causes a change in the amount of commuting expenses paid to employees A and C, a salary linkage batch process related to the payment information of employee A and the payment information of employee C is executed. If a fare revision occurs again after that, and this fare revision causes a change in the amount of commuting expenses paid to employees B and D, a salary linkage batch process related to the payment information of employee B and the payment information of employee D is executed. After that, when it is time to execute the next salary payment calculation process, the second calculation process and the third calculation process are executed. In this way, when a fare revision occurs, the payment information of the relevant employee is recalculated, rather than the payment information of all employees being recalculated each time.
[0141] Next, the process proceeds to step S408, where the task scheduler information after the task completion is deleted from the task scheduler information table 418, the series of processes is terminated, and the process returns to the original process.
[0142] On the other hand, if it is determined in step S400 that the execution time for the task has not yet arrived (NO), the process waits in step S400 until the execution time arrives.
[0143] [Effects of the embodiment] Next, the effects of this embodiment will be described. In this embodiment, route information regarding the commuting route used by an employee to travel between his / her home and each of multiple workplaces to which the employee belongs, and daily payment information regarding the employee's actual use of multiple commuting routes are obtained, and the payment amount for an employee using multiple commuting routes is calculated based on the obtained route information and daily payment information, as well as the fare information in fare information table 420.
[0144] This makes it possible to calculate the amount to be paid when employees who work at multiple workplaces are paid a daily rate of transportation expenses based on the commuting route they use.
[0145] Furthermore, in this embodiment, based on the route information in the employee-specific route information table 406 and the fare information in the fare information table 420, the payment information that is subject to fare revision is identified, and a payroll linkage batch process is executed to calculate the payment amount related to the identified payment information.
[0146] This allows the salary link batch processing to be executed in a time-series distributed manner when there is a fare revision, reducing the load on the salary payment calculation processing. In other words, when there is a fare revision, the payment amount related to the fare revision can be recalculated, reducing the load on the salary payment calculation processing compared to calculating all employees at once.
[0147] Furthermore, in this embodiment, when it is determined that a change has been made to the payment information that will result in a change in the amount of commuting expenses paid, a payroll linkage batch process is executed to calculate or recalculate the amount of commuting expenses paid.
[0148] This allows the salary link batch processing to be executed in a distributed manner in time series when the amount of commuting expenses changes, reducing the load on the salary payment calculation processing. In other words, when the amount of commuting expenses changes, the amount of commuting expenses for the employee related to the change or the payment amount that changes according to the commuting expenses can be recalculated, reducing the load on the salary payment calculation processing compared to calculating the amount for all employees at once.
[0149] Furthermore, in this embodiment, taking communication lags into account, the task is scheduled to be executed after a start delay time from the registration of the task schedule, and the payroll linkage batch processing program is executed a predetermined time after registration.
[0150] This reduces the possibility that the batch server 150 will be unable to execute payroll linkage batch processing if a communication lag occurs.
[0151] Furthermore, in this embodiment, it is determined that a change has occurred in the amount of commuting expenses paid when an employee or a proxy applicant (including a human resources employee) applies for commuting route information or applies for a proxy, the application is approved by the superior employee and the human resources employee, and the payment information of the target employee is registered for the first time in the employee-specific payment information table 408. In addition, it is determined that a change has occurred in the amount of commuting expenses paid when the application for commuting route information is approved and the payment information registered in the employee-specific payment information table 408 is changed.
[0152] Furthermore, when new pro rata payment information is registered in the employee pro rata payment information table 410, it is determined that a change has occurred in the amount of commuting expenses paid. Furthermore, when the existing pro rata payment information registered in the employee pro rata payment information table 410 is changed due to the monthly processing of the personnel staff, it is determined that a change has occurred in the amount of commuting expenses paid.
[0153] Furthermore, if a fare revision causes a difference between the payment amount corresponding to the revised fare and the payment amount already paid, new pro rata payment information is registered in the employee-specific pro rata payment information table 410 to pay the difference, or the existing pro rata payment information already registered is changed. In this case, too, it is determined that a change has occurred in the payment amount of commuting expenses.
[0154] In addition, after the salary linkage basic data is linked (output to the salary linkage system) when a change occurs in the amount of commuting expenses paid, the next salary linkage basic data created in advance will also change, so in this case too, it will be determined that a change has occurred in the amount paid.
[0155] This allows distributed processing even when changes occur in the amount of commuting expenses paid for reasons other than commuting route applications, such as daily rate payments and fare revisions, and further reduces the load on salary payment calculation processing. Also, since it is determined that a change has occurred in the amount of commuting expenses paid based on the registration of payment information or daily rate payment information in employee-specific payment information table 408 or employee-specific daily rate payment information table 410, it is possible to more reliably determine whether the amount of payment has changed.
[0156] [Correspondence] In this embodiment, the storage device of the database server 170 corresponds to the fare information storage means of the first aspect, the storage means of the second aspect, the route information storage means of the third aspect, or the usage record information storage means of the third aspect.
[0157] [Modifications] In the above embodiment, the amount of the transportation allowance was calculated based on the daily payment information (period eligible for daily payment, number of days eligible for payment, etc.) in employee daily payment information table 410 as information regarding an employee's actual use of multiple commuting routes. However, the amount of the transportation allowance can also be calculated based on the payment information (period eligible for payment, number of months eligible for payment, etc.) in employee daily payment information table 408.
[0158] In the above embodiment and its modified example, in the application information input process in step S102, one of the multiple workplaces to which the applicant (employee) belongs is selected, but this is not limiting, and a configuration in which one of the multiple workplaces set for the company to which the employee belongs can be selected can also be adopted. In this case, workplaces to which the employee does not belong may be included as candidates.
[0159] In addition, in the above embodiment and its modified examples, the payment amount calculation means of Invention 1 has been described as corresponding to the process of calculating the payment amount of transportation expenses when the addition of payment information made by an employee is approved by the approval party, but is not limited to this and can also correspond to the process of calculating the payment amount of transportation expenses in batch server 150.
[0160] In the above embodiment and its modified example, the fare information in the fare information table 420 is used to identify the payment information that is the subject of the fare revision, but this is not limiting, and for example, section information on the section where the fare revision occurred, route information on the commuting route where the fare revision occurred, and other revision information on the fare revision can be used. In other words, any information that can grasp that a fare revision has occurred is sufficient, and information on the fares before and after the revision or the revision date is not necessarily required.
[0161] In the above embodiment and its modified example, the payment amount related to the fare revision is recalculated when the fare revision occurs, but this is not limited to this, and a configuration can be adopted in which the payment amount of the commuting expenses to be paid in the current month and related to the fare revision is calculated at the timing of the fare revision. In this case, based on the route information in the employee route information table 406 and the fare information in the fare information table 420, the payment subject to the fare revision is identified, and a salary linkage batch process is executed to calculate the payment amount related to the identified payment. The payment subject to the fare revision can be identified, for example, by identifying the commuting route related to the fare revision, or by identifying the employee who uses the commuting route related to the fare revision.
[0162] In the above embodiment and its modified example, it is determined that a change has occurred in the payment amount of commuting expenses when payment information or daily prorated payment information is newly registered or changed in the employee-specific payment information table 408 or employee-specific daily prorated payment information table 410, but this is not the only possible configuration. For example, it may be configured to determine that a change has occurred in the payment amount when a commuting route is applied for and the application is approved.
[0163] Furthermore, in the above embodiment and its modified examples, the system is realized as a network system, but the present invention is not limited to this and can also be realized as a single device or application.
[0164] In addition, in the above embodiment and its modified examples, the payroll linkage batch processing is configured to be executed by the batch server 150 using a task scheduler, but this is not limited to the above. For example, it is possible to adopt a configuration in which the payroll payment calculation processing is executed only by the commute travel expense calculation server 100, or a configuration in which the payroll payment calculation processing is executed in cooperation with other servers other than the batch server 150.
[0165] In addition, in the above embodiment and its modified example, the case where the present invention is applied to a network system consisting of the Internet 199 has been described, but the present invention is not limited to this, and may be applied, for example, to a so-called intranet that performs communication in the same manner as the Internet 199. Of course, the present invention is not limited to a network that performs communication in the same manner as the Internet 199, and may be applied to a network of any communication method.
[0166] In addition, in the above embodiment and its variations, when executing the processes shown in the flowcharts of Figures 6, 10, 13 and 15, the case has been described where a program pre-stored in ROM is executed, but this is not limited to the above, and the program showing these procedures may be read into RAM from a storage medium on which the program is stored and executed.
[0167] In the above embodiment and its modified example, the present invention is applied to the case of calculating commuting expenses of employees, but it is not limited to this and can be applied to other cases without departing from the spirit of the present invention. For example, the present invention can be applied to the case of calculating travel expenses for business trips and other travel expenses, the case of calculating travel expenses paid to persons other than employees, and the case of calculating travel expenses for using routes other than the commuting route. [Explanation of symbols]
[0168] 100...commuting travel expense calculation server, 150...batch server, 170...database server, 200...employee terminal, 30...CPU, 32...ROM, 34...RAM, 38...I / F, 39...bus, 40...input device, 42...storage device, 44...display device, 199...Internet, 400...company master table, 402...workplace master table, 404...employee information master table, 406...employee route information table, 408...employee payment information table, 410...employee daily rate payment information table, 412...department information table, 414...system environment information table, 416...batch job definition information table, 418...task scheduler information table, 420...fare information table
Claims
1. A workplace information storage means for storing workplace information including a workplace ID for each workplace; an employee information storage means for storing, for each employee, employee information including the employee ID of the employee and the workplace IDs of the plurality of workplaces to which the employee belongs; a workplace information acquisition means for acquiring the workplace information corresponding to the employee ID of the applicant employee by referring to the workplace information storage means and the employee information storage means; a workplace presentation means for presenting to the applicant employee a plurality of workplaces to which the applicant employee belongs based on the workplace information acquired by the workplace information acquisition means; an employer selection means for accepting a selection from among the plurality of employers presented by the employer presentation means; a route information registration means for registering in a route information storage means route information relating to a route used by the applicant employee when traveling between the workplace selected by the workplace selection means and the applicant employee's home; a route information acquisition means for acquiring route information relating to routes used by the target employee for each of a plurality of workplaces to which the target employee belongs from the route information storage means; a usage history information acquisition means for acquiring usage history information regarding the usage history of the target employee of the multiple routes; and a payment amount calculation means for calculating a payment amount for commuting expenses when the target employee uses multiple routes, based on the route information acquired by the route information acquisition means, the usage history information acquired by the usage history information acquisition means, and fare information in a fare information storage means that stores fare information on fares related to the routes.
2. A workplace information storage means for storing workplace information including a workplace ID for each workplace; an employee information storage means for storing, for each employee, employee information including the employee ID of the employee and the workplace IDs of the plurality of workplaces to which the employee belongs; a workplace information acquisition means for acquiring the workplace information corresponding to the employee ID of the applicant employee by referring to the workplace information storage means and the employee information storage means; a workplace presentation means for presenting to the applicant employee a plurality of workplaces to which the applicant employee belongs based on the workplace information acquired by the workplace information acquisition means; an employer selection means for accepting a selection from among the plurality of employers presented by the employer presentation means; a direction type selection means for accepting a selection of one of an outbound route, a return route, or a round trip route as a direction type of a route used by the applicant employee when traveling between the workplace selected by the workplace selection means and the applicant employee's home; a route information registration means for registering in a route information storage means route information relating to a route used by the applicant employee when traveling between the workplace selected by the workplace selection means and the applicant employee's home and direction type information relating to a direction type selected by the direction type selection means; a route information acquisition means for acquiring the route information and the direction type information regarding the route used by the target employee for each of a plurality of workplaces to which the target employee belongs from the route information storage means; a usage history information acquisition means for acquiring usage history information regarding the usage history of the target employee of the multiple routes; and a payment amount calculation means for calculating a payment amount for commuting expenses when the target employee uses multiple routes, based on the route information and direction type information acquired by the route information acquisition means, the usage history information acquired by the usage history information acquisition means, and fare information in a fare information storage means which stores fare information related to the fares for the route.
3. In claim 2, The payment calculation system is characterized in that the route information registration means registers in the route information storage means, for one of the applicant employees, route information regarding different routes used by the applicant employee on the way to and from a first workplace among multiple workplaces to which the applicant employee belongs, and route information regarding different routes used by the applicant employee on the way to and from a second workplace among the multiple workplaces that is different from the first workplace.
4. In any one of claims 1 to 3, The workplace information includes nearest station information regarding a nearest station to the workplace, a route presenting means for presenting to the applicant employee, when it is determined based on the workplace information acquired by the workplace information acquisition means that there are multiple nearest stations to the workplace selected by the workplace selection means, routes to be used by the applicant employee when traveling between the nearest station to the applicant employee's home and the nearest station to the workplace for all combinations of the nearest stations; a route selection means for accepting a selection of one of the multiple routes presented by the route presentation means; A payment calculation system, wherein the route information registration means registers route information relating to the route selected by the route selection means into the route information storage means.
Citation Information
Patent Citations
Commutation cost adjustment management support system
JP2007066214A
Commutation traveling expenses change adjustment device, commutation traveling expenses change adjustment method, and commutation traveling expenses change adjustment program
JP2016192201A
In-commutation ticket cancellation refund amount calculation device, refund amount calculation method, and refund amount calculation program
JP2019113951A
Expense settlement support device, expense settlement support method and expense settlement support program
JP2022154889A
Payment calculation system
JP7300132B1