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

Abstract

To provide a mechanism capable of facilitating adaptation to an environment in which a plurality of types of information codes are mixed.SOLUTION: An information processing device includes a control section for setting a format of a receipt history file which is created on the basis of a history of receiving a levy by using a payment statement so as to indicate a receipt history of the levy. The format of the receipt history file corresponds to one of multiple types of information codes which can be applied to the payment statement.SELECTED DRAWING: Figure 1

Description

[Technical Field]

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

[0002] In recent years, collection systems that execute predetermined transactions (for example, collection transactions for payments such as taxes and public fees) based on payment slips have become known. A known example of a device used in such collection systems is a customer-operated cash processing device (hereinafter also referred to as a self-service cash processing machine) that is operated by a customer. For example, Patent Document 1 listed below discloses a cash processing device that reads a barcode attached to a payment slip and collects payments. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Laid-Open No. 2014-203388 Summary of the Invention [Problem to be solved by the invention]

[0004] In recent years, two-dimensional codes have been added to payment slips in place of or in addition to barcodes, and payments are sometimes made by scanning the two-dimensional codes. However, it is difficult to say that these systems are adequately adapted to an environment where barcodes and two-dimensional codes coexist.

[0005] Therefore, the present invention has been made in consideration of the above problems, and an object of the present invention is to provide a mechanism that can easily adapt to an environment in which multiple types of information codes are mixed. [Means for solving the problem]

[0006] In order to solve the above problem, according to one aspect of the present invention, an information processing device is provided which includes a control unit that sets the format of a payment history file that shows the payment history of a payment, which is created based on the history of payment of the payment using a payment slip, and the format of the payment history file corresponds to any one of multiple types of information codes that can be attached to the payment slip.

[0007] The control unit may set the format of the payment history file for each type of payment.

[0008] The information processing device may include a memory unit that stores information stored in the plurality of information codes that are read when the payment is deposited using the payment slip, in association with each other.

[0009] The control unit may refer to the plurality of information codes stored in the memory unit and create the payment history file corresponding to a type of information code different from the information code used to collect the payment.

[0010] The control unit may create the storage history file separately for each of the formats.

[0011] The payment slip may be provided with at least one of a barcode and a two-dimensional code.

[0012] In order to solve the above problem, according to another aspect of the present invention, a system is provided which includes a cash processing device that reads an information code attached to a payment slip and collects the payment, and an information processing device that sets the format of a collection history file that shows the collection history of the payment, which is created based on the history of the payment being collected in the cash processing device using the payment slip, and the format of the collection history file corresponds to any one of multiple types of information codes that can be attached to the payment slip.

[0013] When the cash processing device reads a first information code attached to the payment slip and there is a second information code corresponding to the first information code, the cash processing device may execute a process to additionally read the second information code attached to the payment slip.

[0014] When the cash processing device reads the second information code attached to the payment slip and the format set for the payment amount related to the payment slip corresponds to the first information code, the cash processing device may execute a process to additionally read the first information code attached to the payment slip.

[0015] In addition, in order to solve the above problem, according to another aspect of the present invention, there is provided an information processing method executed by a computer, which includes setting the format of a payment history file that indicates the payment history of a payment, which is created based on the history of payment of the payment using a payment slip, and the format of the payment history file corresponds to any one of multiple types of information codes that can be attached to the payment slip.

[0016] In addition, in order to solve the above problem, according to another aspect of the present invention, a program is provided that causes a computer to function as a control unit that sets the format of a payment history file that shows the payment history of a payment, which is created based on the history of payment of the payment using a payment slip, and the format of the payment history file corresponds to any one of multiple types of information codes that can be attached to the payment slip. [Effects of the Invention]

[0017] As described above, according to the present invention, a mechanism is provided that can easily adapt to an environment in which a plurality of types of information codes coexist. [Brief explanation of the drawings]

[0018] [Figure 1] 1 is a block diagram showing an example of the configuration of a system 1 according to an embodiment of the present invention. [Figure 2] FIG. 10 is a diagram illustrating an example of information stored in a barcode. [Figure 3] FIG. 10 is a diagram illustrating an example of information stored in a two-dimensional code. [Figure 4] FIG. 10 is a diagram showing an example of the configuration of a storage history file. [Figure 5] 10 is a flowchart showing an example of the flow of a storage history file format setting process executed by the system 1 according to the present embodiment. [Figure 6] 10 is a flowchart showing an example of the flow of payment collection processing executed by the system 1 according to this embodiment. [Figure 7] 10 is a flowchart showing an example of the flow of payment collection processing executed by the system 1 according to this embodiment. [Figure 8] 10 is a flowchart showing an example of the flow of a process for creating a storage history file executed by the system 1 according to the present embodiment. [Figure 9] FIG. 2 is a block diagram showing an example of a hardware configuration of the information processing device according to the present embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0019] Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. In this specification and drawings, components having substantially the same functional configurations are designated by the same reference numerals, and redundant explanations will be omitted.

[0020] <1. Overview> 1 is a block diagram showing an example of the configuration of a system 1 according to one embodiment of the present invention. An overview of the system 1 according to this embodiment will be described below with reference to FIG.

[0021] As shown in Fig. 1, the system 1 according to this embodiment includes a cash processing device 10, a control server 20, and a management terminal 30. The control server 20, the cash processing device 10, and the management terminal 30 are communicatively connected to each other. The control server 20 and the local government server 40 are communicatively connected to each other. These communication paths may be established by any network, such as a local network, a business operator network, or the Internet. Although Fig. 1 illustrates one cash processing device 10, the system 1 may include multiple cash processing devices 10.

[0022] The cash processing device 10 is a self-service cash processing machine that customers can operate themselves to pay taxes and other payments. The cash processing device 10 can be installed in stores such as convenience stores. Customers can use a payment slip to pay at the counter of the local government that issued the payment slip, or at the cash processing device 10.

[0023] The payment slip is provided with an information code that stores various information related to the payment, such as the amount to be paid and the payment deadline. Therefore, the cash processing device 10 reads the information code attached to the payment slip and collects the payment based on the information stored in the read information code.

[0024] The control server 20 is an information processing device that controls the operation of the cash processing device 10. In particular, the control server 20 requests the local government server 40 to update the collection history managed by the local government server 40, based on the history of payments collected by the cash processing device 10. In this case, the control server 20 creates a file (hereinafter also referred to as a collection history file) that includes information stored in the information code read by the cash processing device 10, and transmits the file to the local government server 40.

[0025] The management terminal 30 is an information processing device operated by an administrator of the system 1. The management terminal 30 functions as an interface between the control server 20 and the administrator. For example, the management terminal 30 accesses the control server 20 based on an operation by the administrator and causes the control server 20 to execute a predetermined function.

[0026] The local government server 40 is an information processing device operated by the local government that issues the payment slip. The local government server 40 manages a master database (DB) 41 that stores various information related to payments, such as the tax type, amount, payment deadline, and payment history (i.e., whether payment has been made or not). In particular, the local government server 40 updates the master DB 41 based on the payment history file received from the control server 20. Specifically, the local government server 40 deletes records related to payments that have been made from the master DB 41.

[0027] Here, at least one of several types of information codes may be attached to the payment slip. Specifically, a barcode (an example of a first information code), a two-dimensional code (an example of a second information code), or both a barcode and a two-dimensional code may be attached. Conventionally, a barcode version of the payment history file was created for payments deposited using a barcode, and a two-dimensional code version of the payment history file was created for payments deposited using a two-dimensional code.

[0028] However, when payments are deposited using a cash processing device 10 that can use both barcodes and two-dimensional codes, deposit history files in two different formats may be created. Therefore, the local government server 40 is required to have two types of interfaces in order to accept deposit history files in two different formats and update the master DB 41.

[0029] The burden of providing multiple types of interfaces has been an obstacle when introducing new types of information codes. For example, the burden of providing multiple types of interfaces has been an obstacle when adding a package that enables the use of two-dimensional codes to a cash processing device 10 that can already use barcodes. This has prevented the introduction of two-dimensional codes, which offer more benefits to customers than barcodes, and the improvement of customer usability.

[0030] Therefore, the system 1 according to this embodiment flexibly switches the format of the deposit history file depending on the interface preparation status of the local government server 40 that manages the deposit history. This configuration makes it possible to easily adapt to an environment where multiple types of information codes, such as barcodes and two-dimensional codes, coexist. Specifically, by eliminating the need to provide multiple interfaces to the local government server 40, the operational load on the local government server 40 can be reduced. As a result, for example, it becomes easier to add a package that enables the use of two-dimensional codes to a cash processing device 10 that already supports barcodes, thereby improving customer usability.

[0031] <2.Configuration example> Hereinafter, with reference to FIG. 1 again, a detailed description will be given of an example of the configuration of the system 1 according to this embodiment.

[0032] (1) Cash processing device 10 Referring again to FIG. 1, the cash processing device 10 includes an operation and display unit 11, a reading unit 12, an issuing unit 13, a cash processing unit 14, and a control unit 15.

[0033] The operation display unit 11 has the function of a display unit that displays information to the customer, and the function of an operation unit that accepts information input from the customer. The function of the display unit is realized, for example, by a display. The function of the operation unit is realized, for example, by a touch panel. For example, the operation display unit 11 displays a screen that guides the customer through operations related to paying the payment. The customer then inputs various information for paying the payment on this screen. For example, the operation display unit 11 can accept the input of various information related to the transaction, display a screen that guides the customer to hold the information code on the payment slip over the reading unit 12, or display a screen that guides the customer to insert cash equivalent to the payment.

[0034] The reading unit 12 has the function of reading various information contained in the payment slip. The reading unit 12 is configured, for example, with an optical reader, and can read information stored in information codes such as barcodes or two-dimensional codes from these information codes. Information stored in barcodes will also be referred to as barcode information below. Information stored in two-dimensional codes will also be referred to as two-dimensional code information below.

[0035] The issuing unit 13 has a function of issuing a medium storing various information. The issuing unit 13 may be, for example, a receipt printer that prints information on a paper medium. For example, the issuing unit 13 issues a usage statement after the payment has been received.

[0036] The cash processing unit 14 has a function of processing cash. The cash processing unit 14 includes various components related to cash processing, such as an inlet for receiving cash, an outlet for discharging cash, a transport path for transporting cash, a storage cabinet for storing cash, and a mechanism for counting cash. The cash processing unit 14 stores the cash inserted by the customer that is equivalent to the payment amount, and dispenses change, if any.

[0037] The control unit 15 functions as an arithmetic processing device and a control device, and controls the overall operation of the cash processing device 10 in accordance with various programs. The control unit 15 is realized by electronic circuits such as a CPU (Central Processing Unit) or a microprocessor. The control unit 15 may include a ROM (Read Only Memory) that stores the programs to be used and arithmetic parameters, etc., and a RAM (Random Access Memory) that temporarily stores parameters that change as appropriate.

[0038] The output of information and acquisition of input information by the operation display unit 11, the reading of information by the reading unit 12, the printing and issuance by the issuing unit 13, and the cash processing by the cash processing unit 14 are examples of objects controlled by the control unit 15. The transmission and reception of information to and from the control server 20 is also an example of an object controlled by the control unit 15.

[0039] (2) Control Server 20 Referring again to FIG. 1, the control server 20 includes a storage unit 21 and a control unit 22.

[0040] (Storage unit 21) The storage unit 21 has a function of storing various information for the operation of the control server 20. The storage unit 21 stores a tax item code table 211, a collection history file format designation table 212, and a collection history DB 213.

[0041] (Tax Code Table 211) The tax item code table 211 is a table showing the correspondence between tax items and tax item codes. A tax item code is identification information that indicates a tax item. The tax item code table 211 is created when the cash processing device 10 is installed. An example of information stored in the tax item code table 211 is shown in Table 1 below.

[0042] [Table 1]

[0043] As shown in Table 1, the tax item code table 211 may include a number, a tax item name, a tax item code in the barcode information, a two-dimensional code flag, and a tax item code in the two-dimensional code information. The number is a unique number assigned to each tax item when the tax item code table 211 is created. The tax item name is the name of the tax item. The two-dimensional code flag is a flag indicating whether a two-dimensional code is attached to the payment slip for the tax item, with "1" indicating that a two-dimensional code is attached and "0" indicating that a code is not attached. The tax item code in the barcode information is information indicating the tax item that is stored in the digits of the barcode information that correspond to the tax item code. The tax item code in the two-dimensional code information is information indicating the tax item that is stored in the digits of the two-dimensional code information that correspond to the tax item code.

[0044] As shown in Table 1, different tax item codes may be assigned to the same tax item in the barcode information and the two-dimensional code information.

[0045] An example of information stored in a barcode and a two-dimensional code will be described below with reference to FIGS.

[0046] FIG. 2 is a diagram showing an example of information stored in a barcode. As shown in FIG. 2, numbers are stored in the barcode, and it is predetermined which digits each store the meaning of. In the example shown in FIG. 2, the barcode information includes a header, payment deadline, tax item code, company code, amount, flag, and end. According to the example shown in FIG. 2, by referencing the five-digit number from the 10th to 14th digits of the barcode information with the tax item code table 211 shown in Table 1, it is possible to identify which tax item the payment slip relates to.

[0047] Fig. 3 is a diagram showing an example of information stored in a two-dimensional code. As shown in Fig. 3, numbers are stored in the two-dimensional code, just like a barcode, and it is predetermined which digits each store the meaning of. In the example shown in Fig. 3, the two-dimensional code information includes a header, payment due date, payment deadline, period, tax item code, company code, amount, case key, collection year, payment year, flag, and end.

[0048] 2 and 3, it can be seen that a two-dimensional code can store a larger number of digits, i.e., a larger number of items of information, compared to a barcode. For example, the payment deadline in the second to ninth digits and the period in the eighteenth and nineteenth digits are items that are not stored in a barcode but are stored in a two-dimensional code.

[0049] (Storage History File Format Specification Table 212) The storage history file format designation table 212 is a table that designates the format of the storage history file. An example of information stored in the storage history file format designation table 212 is shown in Table 2 below.

[0050] [Table 2]

[0051] As shown in Table 2, the deposit history file format designation table 212 may include a tax item code in the barcode information, a tax item code in the two-dimensional code information, and a format designation flag. The format designation flag is a flag that designates the format of the deposit history file, and for example, "1" may indicate the barcode format and "0" may indicate the two-dimensional code format.

[0052] (Storage history DB213) The receipt history DB 213 is a DB that stores information indicating the receipt history of payments made in the cash processing device 10. An example of information stored in the receipt history DB 213 is shown in Table 3 below.

[0053] [Table 3]

[0054] As shown in Table 3, the collection history DB213 may include a collection number, tax item name, barcode information, two-dimensional code information, amount, fiscal year, period, and collection date and time. The collection number is a number assigned when a payment is collected using a payment slip. The tax item name is the name of the tax item of the collected payment. The barcode information is all digits of the barcode information read from the barcode attached to the payment slip when the payment is collected. As shown in Figure 2, n is a number, and the barcode information consists of 28 digits. The two-dimensional code information is all digits of the two-dimensional code information read from the two-dimensional code attached to the payment slip when the payment is collected. As shown in Figure 3, x is a number, and the two-dimensional code information consists of 56 digits. The amount, fiscal year, and period are the amount, fiscal year, and period of the payment. The collection date and time indicates the date and time when the payment was collected.

[0055] Here, if the barcode information and 2D code information cannot be read from the payment slip, a blank "-" will be displayed. There are also cases where information for specific items, such as the fiscal year and period, will be left blank "-". For example, this occurs when an item is included only in the 2D code information and not in the barcode information, and when the payment is received, only the barcode is read, but not the 2D code.

[0056] As shown in Table 3, the payment history DB213 stores information stored in multiple information codes (i.e., barcode information and two-dimensional code information) that are read when a payment is made using a payment slip, in association with each other. With this configuration, it is possible to create either a barcode version of the payment history file or a two-dimensional code version of the payment history file, as will be described later.

[0057] (control unit 22) The control unit 22 has a function of controlling the overall operation of the control server 20. The control unit 22 functions as a setting unit 221, a storage control unit 222, and a storage history file creation unit 223.

[0058] (Setting unit 221) The setting unit 221 has the function of setting the format of a payment history file that shows the payment history of payments, which is created based on the history of payments made using a payment slip. In particular, the format of the payment history file corresponds to any one of multiple types of information codes that can be attached to a payment slip. In detail, the setting unit 221 sets the payment history file format designation table 212 shown in Table 2 based on operations from the administrator via the management terminal 30. In particular, the setting unit 221 sets the format designation flag in the payment history file format designation table 212 to "0" or "1." This configuration makes it possible to flexibly switch the format of the payment history file.

[0059] The setting unit 221 may set the format of the payment history file for each type of payment. In the case of taxes and public payments, the setting unit 221 may set the format of the payment history file for each tax item of the payment, as shown in Table 2. This configuration makes it possible to flexibly switch the format of the payment history file for each tax item.

[0060] The setting unit 221 may have a function of setting the type of information code to be assigned to the payment slip. As one example, the setting unit 221 may create the tax item code table 211 based on an operation by an administrator via the management terminal 30. As another example, the setting unit 221 may inquire of the local government server 40 about the type of information code to be assigned to the payment slip, and create the tax item code table 211 based on the inquiry result.

[0061] The function of the setting unit 221 may be realized as an application accessible via the management terminal 30. This application is also referred to as a setting tool below. Setting the format of the storage history file is one of the functions provided by the setting tool.

[0062] (Storage control unit 222) The receipt control unit 222 has a function of controlling processes related to the receipt of payments by the cash processing device 10. In detail, the receipt control unit 222 controls the process of storing information indicating the receipt history of payments made by the cash processing device 10. For example, the receipt control unit 222 receives information obtained when payments are received in the cash processing device 10 from the cash processing device 10, and adds a record to the receipt history DB213.

[0063] The deposit control unit 222 also controls the reading of the information code when the cash processing device 10 deposits the payment using the payment slip.

[0064] As an example, the collection control unit 222 may control the cash processing device 10 to read the information code by referring to the tax item code table 211. Specifically, when the cash processing device 10 reads a barcode attached to a payment slip and there is a two-dimensional code corresponding to the barcode, the cash processing device 10 may execute a process to additionally read the two-dimensional code attached to the payment slip. This allows the collection control unit 222 to acquire the two-dimensional code information even when both a barcode and a two-dimensional code are attached to the payment slip and the barcode is read first and used to collect the payment. The collection control unit 222 associates the initially read barcode information with the additionally read two-dimensional code information and stores them in the collection history DB 213. This configuration allows both barcode information and two-dimensional code information to be stored in a single record, making it possible to create either a barcode version of the collection history file or a two-dimensional code version of the collection history file.

[0065] As another example, the collection control unit 222 may control the cash processing device 10 to read the information code by referring to the collection history file format designation table 212. More specifically, when the cash processing device 10 reads a two-dimensional code attached to a payment slip and the format set for the payment related to the payment slip corresponds to a barcode, the cash processing device 10 may execute a process to additionally read the barcode attached to the payment slip. This allows the collection control unit 222 to obtain additional barcode information for the payment for which a barcode version of the collection history file is to be created, even if a two-dimensional code is first read and used to collect the payment. With this configuration, it is possible to create a barcode version of the collection history file even if a two-dimensional code is used to collect the payment.

[0066] (Storage History File Creation Unit 223) The collection history file creation unit 223 has a function of creating a collection history file showing the collection history of payments based on the history of payments made using payment slips. Specifically, the collection history file creation unit 223 creates a collection history file that stores information showing the collection history of payments stored in the collection history DB 213 in a format set in the collection history file format designation table 212. In this case, the collection history file creation unit 223 may create a barcode version of the collection history file as a collection history file corresponding to one record based on the barcode information in that record. Alternatively, the collection history file creation unit 223 may create a two-dimensional code version of the collection history file as a collection history file corresponding to one record based on the two-dimensional code information in that record.

[0067] Here, the collection history file creation unit 223 may refer to multiple information codes stored in the collection history DB 213 and create a collection history file corresponding to a type of information code different from the information code used to collect the payment. That is, the collection history file creation unit 223 may create a collection history file corresponding to the record using either barcode information or two-dimensional code information, regardless of whether a barcode or two-dimensional code was used to collect the payment. For example, even if a barcode was used to collect the payment, the collection history file creation unit 223 may create a two-dimensional code version of the collection history file based on the two-dimensional code information. Similarly, even if a two-dimensional code was used to collect the payment, the collection history file creation unit 223 may create a barcode version of the collection history file based on the barcode information. This configuration makes it possible to flexibly switch the format of the collection history file regardless of which information code was used to collect the payment.

[0068] An example of the structure of the storage history file will be described below with reference to FIG.

[0069] Figure 4 is a diagram showing an example of the structure of a collection history file. As shown in Figure 4, a collection history file may contain four types of records: a header record, a data record, a trailer record, and an end record. One collection history file may contain multiple data records. The number of data records contained in one collection history file is the same as the number of payments collected. An example of a barcode version of a collection history file is shown in Table 4 below, and an example of a two-dimensional code version of a collection history file is shown in Table 5 below.

[0070] [Table 4]

[0071] [Table 5]

[0072] In the contents column of these tables, "n" indicates a number, "YYYYMMDD" indicates the date, and "HHMM" indicates the time.

[0073] The two types of storage history files shown in Tables 4 and 5 differ in that, for example, one contains 28-digit barcode information and the other contains 56-digit two-dimensional code information in the data record. This difference is due to the different number of digits of information stored in the barcode and the two-dimensional code, as shown in Figures 2 and 3.

[0074] As shown in Tables 4 and 5, the barcode version of the storage history file and the two-dimensional code version of the storage history file may have the same structure, except for the type, content, and number of digits of the data stored.

[0075] Of course, the barcode version of the storage history file and the two-dimensional code version of the storage history file may have different structures. For example, the two-dimensional code version of the storage history file may include a record specific to two-dimensional codes, such as an M header record, before the header record.

[0076] There are two types of collection history files: one file is created for a single tax item, and one file is created for multiple tax items. When multiple tax items are created as one file, a collection history file is created by linking together a combination of one header record, one or more data records, and one trailer record for each tax item, followed by one end record.

[0077] Here, the collection history file creation unit 223 creates collection history files separately for each format. For example, the collection history file creation unit 223 may create one barcode collection history file for one or more tax items for which a barcode format is specified in the collection history file format designation table 212. Similarly, the collection history file creation unit 223 may create one two-dimensional code collection history file for one or more tax items for which a two-dimensional code format is specified in the collection history file format designation table 212. With this configuration, it is possible to create collection history files without mixing tax items with different formats.

[0078] The functions of the storage history file creation unit 223 described above may be realized as an application accessible via the management terminal 30. This application will also be referred to as a storage history file creation application below. Creating a storage history file is one of the functions provided by the storage history creation application.

[0079] (3) Management terminal 30 Referring again to FIG. 1 , the management terminal 30 includes an operation display unit 31. The operation display unit 31 functions as a display unit that displays information to the administrator and as an operation unit that accepts information input from the administrator. The function as a display unit is realized, for example, by a display. The function as an operation unit is realized, for example, by a keyboard and a mouse. As one example, the operation display unit 31 displays a screen of a setting tool, accepts various inputs to the setting tool, and causes the control server 20 to create a storage history file format designation table 212. As another example, the operation display unit 31 displays a screen of a storage history file creation application, accepts various inputs to the storage history file creation application, and causes the control server 20 to create a storage history file and transmit it to the local government server 40.

[0080] (4) Municipal Server 40 1 again, the local government server 40 stores and updates the master DB 41. The master DB 41 stores a collection history including various information such as the tax item for each payment and information indicating whether payment has been made or not. The local government server 40 updates the master DB 41 based on the collection history file received from the control server 20.

[0081] <3. Operation processing> (Format setting process for storage history file) 5 is a flowchart showing an example of the flow of a format setting process for a deposit history file executed by the system 1 according to this embodiment. The process according to this flow is executed based on an operation by an administrator on the management terminal 30 when the cash processing device 10 is installed. Additionally, the process according to this flow may be executed to change the settings at any timing after the system 1 starts operating.

[0082] 5, first, the management terminal 30 starts up a setting tool (step S101). For example, the management terminal 30 accesses the control server 20 based on an operation by an administrator, and starts up the setting tool.

[0083] Next, the management terminal 30 executes the storage history file format setting function in the setting tool (step 102). For example, the management terminal 30 displays an input screen for various information for creating the storage history file format designation table 212.

[0084] Next, the management terminal 30 sets the tax item code in the barcode information, the tax item code in the two-dimensional code information, and the format designation flag for the tax item to be set (step S103). For example, first, the management terminal 30 accepts an operation to select the tax item to be set from among the tax items that the system 1 can accept. Next, the management terminal 30 accepts input of the tax item code in the barcode information for tax items that have a barcode attached to the payment slip, and accepts input of the tax item code in the two-dimensional code information for tax items that have a two-dimensional code attached to the payment slip. The management terminal 30 then accepts input of whether the payment history file should be created in a barcode format or a two-dimensional code format. The setting tool (i.e., the control server 20) registers the information entered into the management terminal 30 as a one-line record in the payment history file format designation table 212.

[0085] Next, the management terminal 30 determines whether the setting is complete (step S104). For example, the management terminal 30 determines that the setting is complete when the process in step S103 has been executed for all tax items that the system 1 can accept, and determines that the setting is incomplete when the process in step S103 has not been executed.

[0086] If it is determined that the setting is not completed (step S104: NO), the process returns to step S103 again.

[0087] If it is determined that the setting is complete (step S104: YES), the process ends.

[0088] (Payment processing) 6 and 7 are flowcharts showing an example of the flow of payment collection processing executed by the system 1 according to this embodiment. The processing according to this flow is executed when a customer pays a payment by himself / herself using the cash processing device 10.

[0089] 6, first, the cash processing device 10 reads the information code attached to the payment slip (step S201). For example, the cash processing device 10 displays, on the operation display unit 11, a screen that guides the customer to hold the barcode or two-dimensional code attached to the payment slip over the reading unit 12, and then reads the information code held by the customer with the reading unit 12.

[0090] Next, the cash processing device 10 determines the type of the read information code (step S202). This is because it is unclear whether a barcode or a two-dimensional code is attached to the payment slip, and even if both a barcode and a two-dimensional code are attached to the payment slip, it is up to the customer to decide which one to have the reading unit 12 read.

[0091] When it is determined that the read information code is a two-dimensional code (step S202: two-dimensional code), the cash processing device 10 extracts a tax item code from the two-dimensional code information (step S203).

[0092] Next, the cash processing device 10 determines whether or not the extracted tax item code is a tax item code that exists in the tax item code table 211 (step S204). For example, the cash processing device 10 determines whether or not the tax item code extracted in step S203 exists in the tax item code column in the two-dimensional code information in the tax item code table 211.

[0093] If it is determined that the tax item code does not exist in the tax item code table 211 (step S204: NO), the cash processing device 10 displays an error message indicating that the payment slip cannot be handled (step S205). Thereafter, the transaction is interrupted and the process ends.

[0094] If it is determined that the tax item code exists in the tax item code table 211 (step S204: YES), the cash processing device 10 determines whether the format of the deposit history file is a two-dimensional code version or a barcode version (step S206). For example, the cash processing device 10 determines the format of the deposit history file by referring to the format designation flag corresponding to the tax item code in the deposit history file format designation table 212.

[0095] If it is determined that the format of the deposit history file is the two-dimensional code version (step S206: two-dimensional code version), the cash processing device 10 executes a deposit process (step S210). For example, the cash processing device 10 deposits cash equivalent to the amount of the payment based on the two-dimensional code information read in step S201. Thereafter, the process ends.

[0096] On the other hand, if it is determined that the format of the deposit history file is the barcode version (step S206: barcode version), the cash processing device 10 displays a guidance screen for reading the barcode (step S207). For example, the cash processing device 10 displays, on the operation display unit 11, a screen for guiding the user to hold over the reading unit 12 a barcode attached to the same payment slip as the payment slip whose two-dimensional code was read in step S201.

[0097] Next, the cash processing device 10 reads the barcode attached to the payment slip (step S208).

[0098] Next, the cash processing device 10 determines whether the barcode read in step S208 matches the two-dimensional code read in step S201 (step S209). For example, the cash processing device 10 determines that the tax item code in the barcode information and the tax item code in the two-dimensional code information match when they indicate the same tax item in the tax item code table 211, and otherwise determines that they do not match.

[0099] If it is determined that the two-dimensional code information matches (step S209: YES), the cash processing device 10 executes a storing process (step S210). For example, the cash processing device 10 stores cash equivalent to the payment amount based on the two-dimensional code information read in step S201. Then, the process ends.

[0100] If it is determined that the two do not match (step S209: NO), the cash processing device 10 displays an error message indicating that the payment slip cannot be handled (step S205), after which the transaction is interrupted and the process ends.

[0101] When it is determined that the information code read in step S202 is a barcode (step S202: barcode), as shown in FIG. 7, the cash processing device 10 extracts a tax item code from the barcode information (step S211).

[0102] Next, the cash processing device 10 determines whether or not the extracted tax item code is a tax item code that exists in the tax item code table 211 (step S212). For example, the cash processing device 10 determines whether or not the tax item code extracted in step S211 exists in the tax item code column in the barcode information in the tax item code table 211.

[0103] If it is determined that the tax item code does not exist in the tax item code table 211 (step S212: NO), the cash processing device 10 displays an error message indicating that the payment slip cannot be handled (step S205). Thereafter, the transaction is interrupted and the process ends.

[0104] When it is determined that the tax item code exists in the tax item code table 211 (step S212: YES), the cash processing device 10 identifies the tax item from the tax item code table 211 (step S213).

[0105] Next, the cash processing device 10 determines whether or not a two-dimensional code exists (step S214). For example, the cash processing device 10 determines whether or not a two-dimensional code is attached to the payment slip by referring to the two-dimensional code flag in the tax item code table 211 for the tax item identified in step S213.

[0106] If it is determined that a two-dimensional code does not exist (step S214: NO), the cash processing device 10 executes a storing process (step S210). For example, the cash processing device 10 stores cash equivalent to the amount of the payment based on the barcode information read in step S201. Thereafter, the process ends.

[0107] If it is determined that a two-dimensional code exists (step S214: YES), the cash processing device 10 displays a guidance screen for reading the two-dimensional code (step S215). For example, the cash processing device 10 displays, on the operation display unit 11, a screen for guiding the user to hold over the reading unit 12 a two-dimensional code attached to the same payment slip as the payment slip whose barcode was read in step S201.

[0108] Next, the cash processing device 10 reads the two-dimensional code attached to the payment slip (step S216).

[0109] Next, the cash processing device 10 determines whether the two-dimensional code read in step S216 matches the barcode read in step S201 (step S217). For example, the cash processing device 10 determines that they match if the tax item code in the barcode information and the tax item code in the two-dimensional code information indicate the same tax item in the tax item code table 211, and determines that they do not match if not.

[0110] If it is determined that the data match (step S217: YES), the cash processing device 10 executes a storing process (step S210). For example, the cash processing device 10 stores cash equivalent to the amount of the payment based on the barcode information read in step S201. Thereafter, the process ends.

[0111] If it is determined that the two do not match (step S217: NO), the cash processing device 10 displays an error message indicating that the payment slip cannot be handled (step S205), after which the transaction is interrupted and the process ends.

[0112] In addition, if a barcode is read in step S201 and a two-dimensional code is additionally read in step S216, in step S210, the cash processing device 10 may store cash equivalent to the amount of the payment based on the two-dimensional code information read in step S216.

[0113] (Storage history file creation process) 8 is a flowchart showing an example of the flow of a process for creating a deposit history file executed by the system 1 according to this embodiment. The process according to this flow is executed based on an operation by an administrator on the management terminal 30 after the available time for the cash processing device 10 has ended, for example, after business hours for the day.

[0114] 8, first, the management terminal 30 starts up a storage history file creation application (step S301). For example, the management terminal 30 accesses the control server 20 based on an operation by an administrator, and starts up the storage history file creation application.

[0115] Next, the management terminal 30 sets n=0001 within the application (step S302). This n corresponds to the number in the tax item code table 211.

[0116] Next, the management terminal 30 refers to the two-dimensional code flag in the tax item code table 211 and determines whether or not a two-dimensional code exists in the tax item with the number n (step S303).

[0117] If it is determined that the tax item with the number n does not have a two-dimensional code (step S303: NO), the management terminal 30 refers to the tax item code table 211 and extracts the tax item name of the tax item with the number n (step S304).

[0118] Next, the management terminal 30 displays the tax item name extracted in step S304 as the tax item for which a barcode version of the deposit history file is to be created (step S305). After that, the management terminal 30 sets the value of n+1 to n (step S306).

[0119] On the other hand, if it is determined that a two-dimensional code exists for the tax item number n (step S303: YES), the management terminal 30 refers to the tax item code table 211 and extracts the tax item name for the tax item number n (step S307).

[0120] Next, the management terminal 30 refers to the tax item code table 211 and extracts the tax item code from the two-dimensional code information of the tax item number n (step S308).

[0121] Next, the management terminal 30 determines the format of the deposit history file by referring to the format designation flag in the deposit history file format designation table 212 that corresponds to the tax item code in the two-dimensional code information extracted in step S308 (step S309).

[0122] If it is determined that the format of the deposit history file is barcode (step S309: barcode), the management terminal 30 displays the tax item name extracted in step S307 as the tax item for which the barcode deposit history file is to be created (step S305).Then, the management terminal 30 sets the value of n+1 to n (step S306).

[0123] On the other hand, if it is determined that the format of the deposit history file is a two-dimensional code version (step S309: two-dimensional code version), the management terminal 30 displays the tax item name extracted in step S307 as the tax item for which the two-dimensional code version of the deposit history file is to be created (step S310).Then, the management terminal 30 sets the value of n+1 to n (step S306).

[0124] Thereafter, the management terminal 30 determines whether or not the nth tax item exists in the tax item code table 211 (step S311).

[0125] If it is determined that the nth tax item exists (step S311: YES), the process returns to step S303 again.

[0126] If it is determined that there is no nth tax item (step S311: NO), at this point, tax items for which a barcode version of a payment history file is created and tax items for which a two-dimensional code version of a payment history file is created are categorized and listed on the screen of the management terminal 30. The management terminal 30 accepts an operation to select a tax item for which a payment history file is to be created from the multiple tax items listed on the screen (step S312).

[0127] Next, the payment history file creation application (ie, the control server 20) refers to the payment history DB 213 and creates a payment history file for the tax item selected in step S312 (step S313).

[0128] This completes the process.

[0129] In step S312, the administrator can select multiple tax items. However, it is not possible to simultaneously select a tax item for which a barcode version of the payment history file is to be created and a tax item for which a two-dimensional code version of the payment history file is to be created. In other words, multiple tax items for which a barcode version of the payment history file is specified may be selected simultaneously. Alternatively, multiple tax items for which a two-dimensional code version of the payment history file is specified may be selected simultaneously.

[0130] The processing of steps S312 to S314 may be executed multiple times until the deposit history file creation application is terminated. For example, the administrator may select all tax items for which a barcode version of the deposit history file is to be created and then create the deposit history file, and then select all tax items for which a two-dimensional code version of the deposit history file is to be created and create the deposit history file.

[0131] <4. Effects> As described above, the control server 20 according to this embodiment can flexibly switch the format of the deposit history file depending on the interface preparation status of the local government server 40 that manages the deposit history. This configuration makes it possible to easily adapt to an environment where multiple types of information codes, such as barcodes and two-dimensional codes, coexist.

[0132] Specifically, the control server 20 can create a barcode version of the collection history file even when the payment is deposited using the two-dimensional code of a payment slip that has both a barcode and a two-dimensional code. Therefore, in a case where two types of payment slips are mixed, namely, payment slips with only a barcode and payment slips with both a barcode and a two-dimensional code, a barcode version of the collection history file can be created regardless of which information code the payment was deposited using. This makes it possible to reduce the interface of the collection history file in the local government server 40 to a single type, the barcode version. Furthermore, the cash processing device 10 can deposit payments using two-dimensional codes, which store more information.

[0133] Similarly, the control server 20 can create a two-dimensional code version of the payment history file even when payments are paid using a barcode. Therefore, in a case where two types of payment slips are mixed, namely, payment slips with only a two-dimensional code and payment slips with both a barcode and a two-dimensional code, a two-dimensional code version of the payment history file can be created regardless of which information code is used. Therefore, it is possible to limit the interface of the payment history file on the local government server 40 to a single type, the two-dimensional code version.

[0134] Furthermore, one local government server 40 does not necessarily manage the collection history for all tax items, and there are cases where a different local government server 40 manages the collection history for each tax item. In such cases, for tax items managed by a local government server 40 that has already created an interface for a barcode version of the collection history file, the system can be set to create a barcode version of the collection history file. Similarly, for tax items managed by a local government server 40 that has already created an interface for a two-dimensional code version of the collection history file, the system can be set to create a two-dimensional code version of the collection history file.

[0135] As explained above, eliminating the need to provide multiple interfaces on the local government server 40 reduces the operational load on the local government server 40. This allows local governments to gradually introduce new types of information codes, such as two-dimensional codes. This allows customers to pay their payments using two-dimensional codes that contain more information. This improves customer usability, allowing customers to check more information about their payments on the screen of the cash processing device 10 and receive more detailed statements.

[0136] <5. Hardware configuration example> Next, the hardware configuration of an information processing device according to this embodiment will be described with reference to Fig. 9. Fig. 9 is a block diagram showing an example of the hardware configuration of an information processing device according to this embodiment. Note that the information processing device 900 shown in Fig. 9 can realize, for example, the control server 20, management terminal 30, and local government server 40 shown in Fig. 1. Information processing by the control server 20, management terminal 30, and local government server 40 according to this embodiment is realized by cooperation between software and hardware described below.

[0137] As shown in FIG. 9, the information processing device 900 includes a CPU (Central Processing Unit) 901, a ROM (Read Only Memory) 902, a RAM (Random Access Memory) 903, a host bus 904, a bridge 905, an external bus 906, an interface 907, an input device 908, an output device 909, a storage device 910, and a communication device 911.

[0138] The CPU 901 functions as an arithmetic processing unit and control unit, and controls the overall operation of the information processing device 900 in accordance with various programs. The CPU 901 may also be a microprocessor. The ROM 902 stores programs used by the CPU 901, calculation parameters, etc. The RAM 903 temporarily stores programs used in the execution of the CPU 901, and parameters that change as appropriate during the execution. These are interconnected by a host bus 904 that is composed of a CPU bus, etc. The CPU 901 may form, for example, the control unit 22 shown in FIG. 1. The CPU 901 may also control the overall operation of the management terminal 30 and the overall operation of the local government server 40.

[0139] The host bus 904 is connected to an external bus 906, such as a PCI (Peripheral Component Interconnect / Interface) bus, via a bridge 905. It is not necessary to configure the host bus 904, bridge 905, and external bus 906 separately, and these functions may be implemented on a single bus.

[0140] The input device 908 is composed of input means for the user to input information, such as a mouse, keyboard, touch panel, buttons, microphone, switches, and levers, and an input control circuit that generates an input signal based on the user's input and outputs it to the CPU 901. A user who operates the information processing device 900 can input various data and instruct the information processing device 900 to perform processing operations by operating this input device 908. The input device 908 can form, for example, the operation and display unit 31 shown in FIG. 1.

[0141] The output device 909 includes, for example, a display device such as a CRT (Cathode Ray Tube) display device, a liquid crystal display (LCD) device, an OLED (Organic Light Emitting Diode) device, a lamp, etc., and an audio output device such as a speaker, etc. The output device 909 can form, for example, the operation display unit 31 shown in FIG.

[0142] The storage device 910 is a device for storing data. The storage device 910 may include a storage medium, a recording device for recording data on the storage medium, a reading device for reading data from the storage medium, and a deletion device for deleting data recorded on the storage medium. The storage device 910 is configured, for example, with an HDD (Hard Disk Drive). This storage device 910 drives a hard disk and stores programs executed by the CPU 901 and various data. The storage device 910 may form, for example, the storage unit 21 shown in FIG. 1. The storage device 910 may also store the master DB 41 in the local government server 40.

[0143] The communication device 911 is, for example, a communication interface configured with a communication device for connecting to a network, etc. The communication device 911 may be compatible with either wireless communication or wired communication.

[0144] The above describes an example of a hardware configuration capable of realizing the functions of the information processing device 900 according to this embodiment. Each of the above components may be realized using general-purpose components, or may be realized by hardware specialized for the function of each component. Therefore, the hardware configuration used can be changed as appropriate depending on the technical level at the time of implementing this embodiment.

[0145] <6. Supplementary Information> Although the preferred embodiments of the present invention have been described in detail above with reference to the accompanying drawings, the present invention is not limited to these examples. It is clear that a person skilled in the art to which the present invention pertains can conceive of various modifications and alterations within the scope of the technical ideas set forth in the claims, and it is understood that these also naturally fall within the technical scope of the present invention.

[0146] In the above embodiment, an example was described in which the management terminal 30 was a dedicated terminal, but the present invention is not limited to such an example. The functions of the management terminal 30 may be realized as a program that can be stored in an external medium. Then, by installing the program in a personal computer (PC) other than the management terminal 30 using the external medium, the other PC may operate as the management terminal 30.

[0147] In the above embodiment, an example in which the payment slip is issued on paper has been described, but the present invention is not limited to such an example. The payment slip may be issued on a medium other than paper, such as a web page or an image.

[0148] Although the above description concerns the collection of taxes and public fees based on payment slips issued by local governments, the present invention can also be applied to the collection of other payments, such as payments based on payment slips issued by financial institutions.

[0149] In the above embodiment, a barcode and a two-dimensional code are given as examples of information codes, but the present invention is not limited to such examples. Information codes of types other than barcodes and two-dimensional codes may be attached to payment slips. Even in this case, the present invention can be applied in the same way as in the above embodiment.

[0150] The series of processes performed by each device described herein may be implemented using software, hardware, or a combination of software and hardware. The software programs may be stored in advance, for example, on a recording medium (more specifically, a non-transitory computer-readable storage medium) internal or external to each device. Each program is loaded into a random access memory (RAM) and executed by a processing circuit such as a central processing unit (CPU). The recording medium may be, for example, a magnetic disk, an optical disk, a magneto-optical disk, or a flash memory. The computer program may be distributed, for example, via a network without using a recording medium. The computer may be an application-specific integrated circuit (ASIC), a general-purpose processor that executes functions by loading a software program, or a computer on a server used in cloud computing. The series of processes performed by each device described herein may be centrally processed by a single computer or distributed across multiple computers. Furthermore, in each of the above embodiments, two or more communication means present in one device may be physically implemented on a single medium.

[0151] Furthermore, the processes described herein using flowcharts or sequence diagrams do not necessarily have to be performed in the order shown. Some process steps may be performed in parallel. Furthermore, additional process steps may be employed, and some process steps may be omitted. [Explanation of symbols]

[0152] 1 System 10 Cash handling equipment 11 Operation display section 12 Reading unit 13 Publishing Department 14 Cash Processing Section 15 Control Unit 20 Control Server 21 Memory section 211 Tax Code Table 212 Storage History File Format Designation Table 213 Collection History DB 22 Control Unit 221 Setting Section 222 Storage control unit 223 Storage History File Creation Department 30 Management terminal 31 Operation display section 40 Municipal Server 41 Master DB

Claims

1. a control unit that sets the format of a payment history file that indicates the payment history of the payment, the file being created based on the history of payment made using the payment slip; Equipped with The format of the payment history file corresponds to any one of a plurality of types of information codes that can be attached to the payment slip. Information processing device.

2. The control unit sets the format of the payment history file for each type of payment. The information processing device according to claim 1 .

3. The information processing device includes a storage unit that stores information stored in the plurality of information codes read when the payment is deposited using the payment slip in association with each other. The information processing device according to claim 1 .

4. The control unit refers to the plurality of information codes stored in the storage unit and creates the payment history file corresponding to the information code of a type different from the information code used for payment of the payment. The information processing device according to claim 3 .

5. The control unit creates the storage history file separately for each format. The information processing device according to claim 1 .

6. At least one of a barcode or a two-dimensional code is attached to the payment slip. The information processing device according to claim 1 .

7. a cash processing device that reads the information code attached to the payment slip and stores the payment; an information processing device that sets the format of a payment history file that indicates the payment history, the file being created based on the history of payment of the payment to the cash processing device using the payment slip; Equipped with The format of the payment history file corresponds to any one of the multiple types of information codes that can be attached to the payment slip. system.

8. When the cash processing device reads the first information code attached to the payment slip and there is a second information code corresponding to the first information code, the cash processing device executes a process of additionally reading the second information code attached to the payment slip. The system of claim 7.

9. When the cash processing device reads the second information code attached to the payment slip, and the format set for the payment related to the payment slip corresponds to the first information code, execute a process of additionally reading the first information code attached to the payment slip; The system of claim 7.

10. 1. A computer-implemented information processing method, comprising: Setting the format of a payment history file showing the payment history of the payment, which is created based on the history of payment made using the payment slip; Including, The format of the payment history file corresponds to any one of a plurality of types of information codes that can be attached to the payment slip. Information processing methods.

11. Computer, a control unit that sets the format of a payment history file that indicates the payment history of the payment, the file being created based on the history of payment made using the payment slip; It functions as The format of the payment history file corresponds to any one of a plurality of types of information codes that can be attached to the payment slip. program.

Images