Information processing system, method of controlling information processing system, and program therefor

Abstract

To make it possible for an invoice receiver to acquire index data without establishment of any invoice issuing system on a side of an invoice issuer.SOLUTION: The present invention is directed to an information processing system which can communicate with a plurality of terminals. The information processing system has: generating means for generating document screen information for use in receiving an attachment of an electronic book and index data of the electronic book; transmission control means for transmitting an email for prompting an input of the attachment of the electronic book and the index data of the electronic book to the document screen information generated by the generating means; and reception means for transmitting the document screen information to addressees of the email transmitted by the transmission control means to receive the attachment of the electronic document and the index data of the electronic document.SELECTED DRAWING: Figure 6

Description

[Technical field]

[0001] The present invention relates to a system for requesting issuance of an invoice. [Background technology]

[0002] Invoice issuers often implement systems that convert transaction information for each customer into electronic data and manage it in one place, and automatically create invoices based on that transaction information. This system allows for the automatic generation of regular invoices.

[0003] However, there was a problem in that if a customer requested an ad-hoc invoice, the invoice could not be created via the system.

[0004] In order to solve the above problem, Patent Document 1 describes an invoice issuing system that, when it receives a request for temporary issuance of an invoice, creates an invoice for the transaction related to the request for temporary issuance based on a customer database and transaction information stored in a transaction database, and updates the transaction information stored in the transaction database to indicate that the invoice has already been issued. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Patent Publication No. 2008-210144 DISCLOSURE OF THEINVENTION [Problem to be solved by the invention]

[0006] In response to the Electronic Bookkeeping Act, invoice recipients are required to be able to set the ledger's "transaction date and other dates," "transaction amount," and "client" as search conditions when storing invoices as electronic records.

[0007] In order to make it possible to search ledgers stored as electromagnetic records (hereafter referred to as electronic ledgers), one method is to accept index data (such as "transaction date and other dates," "transaction amount," and "client") from the invoice issuer as data linked to the electronic ledger, and then link the electronic ledger to the index data. This linking makes it possible to search for the linked electronic ledger from the search results of the index data. If the invoice is from an invoice issuer that has built the invoice issuing system, it becomes easy to receive and link the invoice information (index data) related to the electronic ledger.

[0008] However, the above configuration assumes that the invoice issuer has constructed the invoice issuance system; if the invoice issuer has not constructed the invoice issuance system, the invoice recipient must manually input and link the index data in the electronic ledger.

[0009] The present invention aims to enable a bill recipient to obtain index data without requiring the bill issuer to build a bill issuing system. [Means for solving the problem]

[0010] The present invention for solving the above problem is an information processing system capable of communicating with a plurality of terminals, characterized in having a generation means for generating document screen information that accepts an attachment of an electronic ledger and index data for the electronic ledger, a transmission control means for controlling the transmission of an email prompting the attachment of an electronic ledger to the document screen information generated by the generation means and the input of index data for the electronic ledger, and a reception means for transmitting the document screen information to a destination of the email controlled by the transmission control means, and accepting the attachment of an electronic ledger and index data for the electronic ledger. Effect of the Invention

[0011] The present invention allows a bill recipient to obtain index data without the need for the bill issuer to build a bill issuing system. [Brief description of the drawings]

[0012] [Figure 1] FIG. 1 is a diagram illustrating an example of a schematic configuration of an information processing system. [Diagram 2] FIG. 2 is a block diagram showing an example of a hardware configuration of a person in charge terminal, a manager terminal, and a server. [Diagram 3] FIG. 2 is a block diagram illustrating an example of a hardware configuration of a printing apparatus. [Figure 4] 13 is a flowchart showing an example of an invoice issuance request generation process. [Diagram 5] 13 is a flowchart showing an example of an invoice issuance request process. [Figure 6] FIG. 11 is a sequence diagram illustrating an outline of an invoice issuance request process. [Figure 7] 13 is an example of a screen of an invoice registration information input web page. [Figure 8] 13 is an example of a screen shot of an invoice registration web page. [Figure 9] 13 is an example of a screen shot of an invoice registration web page. [Figure 10] 1A to 1C are schematic diagrams showing an example of CSV data registered in this embodiment and an example of customer data registered in a database. [Figure 11] 13 is a schematic diagram showing an example of an invoice issuance request email text. FIG. [Figure 12] FIG. 13 is a schematic diagram showing an example of an invoice screen displayed on the screen. [Figure 13] FIG. 13 is a schematic diagram showing an example of an invoice search result screen. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings.

[0014] FIG. 1 is a diagram showing an example of a system configuration of an information processing system according to an embodiment of the present invention.

[0015] The information processing system 100 comprises a scanner device 102 on the invoice issuer's side, an invoice issuer terminal 104, an MFP (Multi Function Peripheral) 108, a Web server / batch server 105 placed on an invoice management cloud 114, a database server 106, and an invoice recipient's terminal 110 on the invoice recipient's side, all of which are connected to each other so as to be able to communicate with each other via a network 112.

[0016] In the present invention, the Web server / batch server 105 and the database server 106 are virtual servers located on the invoice management cloud 114. Note that each server does not have to be located on the cloud 114, and each may be located in its own housing, or each function may be integrated into one or more housings.

[0017] The processing of the present invention will now be briefly described with reference to FIG.

[0018] FIG. 6 is a schematic diagram for explaining the general flow of processing according to the present invention.

[0019] Before the process flow of FIG. 6, the invoice recipient first receives a product or service from the invoice issuer.

[0020] By receiving the product or service, the bill recipient begins preparation 601 for having the bill issuer issue a bill.

[0021] In 601, the invoice recipient inputs information (such as the invoice document name and invoice issuer identification) into the batch server 105 to generate a web page for having the invoice issued (invoice registration web page), and also inputs the sending date of the email requesting the invoice issuer to issue the invoice.

[0022] In 602, the batch server 105 creates an invoice registration web page immediately before or on the day the email is sent, and in 603, on the day the email is sent, sends an email (invoice issuance request email) with the URI of the invoice registration web page to the invoice issuer.

[0023] When the invoice issuer receives the email, it creates an invoice in any format corresponding to the provided product or service based on the document name, etc. (604). If the created invoice is an electronic file, it is managed as is as a file, and if it is paper, it is converted to a PDF file by the scanner device 102, etc.

[0024] In 605, the invoice issuer opens the URI of the invoice registration web page listed in the received email and uploads the invoice file to the Web server 105 using WebDAV. The invoice issuer also inputs data into the index data input fields of the same invoice registration web page.

[0025] When the invoice file is registered on the Web server 105, the invoice recipient downloads the invoice file in 606, and performs a consistency check between the index data registered on the invoice registration Web page and the invoice file in 607, and then proceeds to subsequent payment processing such as creating a payment request form.

[0026] By following the above general flow, the invoice recipient can obtain the invoice file and index data. After the overview in Figure 6, we will return to the explanation of Figure 1.

[0027] The invoice recipient terminal 110 in Figure 1 is a terminal used by the invoice recipient, and performs processes such as inputting information for creating an invoice registration web page and sending the email sending date to the web server 105, and downloading or viewing invoices sent by the invoice issuer from the web server 105.

[0028] The bill issuer terminal 104 is a terminal used by the bill issuer, and performs processes such as generating bills and uploading bill files by accessing the Web server 105.

[0029] The scanner device 102 and the MFP 108 perform processing such as scanning a paper invoice and importing it into a terminal for an invoice issuer as a PDF file.

[0030] The Web server / batch server 105 creates an invoice registration Web page based on input from the invoice recipient terminal 110, and creates and sends an e-mail on the e-mail sending date set by the invoice recipient terminal 110. It also registers in the database server 106 the invoice file registered from the invoice issuer terminal 104 and the input index data.

[0031] The invoice issuer terminal 104 is capable of searching and displaying invoice files stored in the database server 106 via the Web server 105, and may also be capable of making changes to the invoice files (for example, replacing or deleting pages, changing the order of pages, etc.). The invoice recipient terminal 110 is also capable of searching and displaying invoice files in a similar manner.

[0032] FIG. 2 is a block diagram showing an example of the hardware configuration of the bill issuer terminal 104, Web server 105, database server 106, and bill recipient terminal 110, as well as these information processing devices, in an embodiment of the present invention.

[0033] As shown in FIG. 2, these information processing devices are connected to a CPU (Central Processing Unit) 201, a ROM (Read Only Memory) 202, a RAM (Random Access Memory) 203, an input controller 205, a video controller 206, a memory controller 207, and a communication I / F controller 208 via a system bus 204.

[0034] The CPU 201 comprehensively controls each device and controller connected to a system bus 204 .

[0035] The ROM 202 or external memory 211 holds a BIOS (Basic Input / Output System) and an OS (Operating System), which are control programs executed by the CPU 201, programs that can be read and executed by this information processing device, and various necessary data (including data tables).

[0036] The RAM 203 functions as a main memory, a work area, etc., for the CPU 201. The CPU 201 loads programs and the like required for executing processes from the ROM 202 or the external memory 211 into the RAM 203, and executes the loaded programs to realize various operations.

[0037] The input controller 205 controls input from an input device such as a keyboard 209 or a pointing device such as a mouse (not shown). If the input device is a touch panel, the user can give various instructions by pressing (touching with a finger or the like) icons, cursors, or buttons displayed on the touch panel.

[0038] The touch panel may also be a touch panel capable of detecting positions touched by multiple fingers, such as a multi-touch screen.

[0039] The video controller 206 controls display on an external output device such as a display 210. The display also includes the display of a notebook computer integrated with the main body. Note that the external output device is not limited to a display, and may be, for example, a projector. In addition, for devices capable of receiving the above-mentioned touch operation, an input device is also provided.

[0040] The video controller 206 is capable of controlling a video memory (VRAM) for display control, and can use part of the RAM 203 as the video memory area, or can provide a separate dedicated video memory.

[0041] The memory controller 207 controls access to the external memory 211. As the external memory, an external storage device (hard disk) for storing a boot program, various applications, font data, user files, edit files, and various data, a flexible disk (FD), or a compact flash (registered trademark) memory connected to a PCMCIA card slot via an adapter, etc., can be used.

[0042] The communication I / F controller 208 connects and communicates with external devices via a network, and executes communication control processing on the network. For example, communication using TCP / IP, telephone lines such as ISDN, and 3G lines for mobile phones are possible.

[0043] The CPU 201 enables display on the display 210 by, for example, executing a process of expanding (rasterizing) an outline font in a display information area in the RAM 203. The CPU 201 also enables a user to give instructions using a mouse cursor (not shown) on the display 210.

[0044] Next, the hardware configuration of the printing device 108 shown in FIG. 1 will be described with reference to FIG.

[0045] FIG. 3 is a block diagram showing an example of a hardware configuration of the printing device 108 shown in FIG.

[0046] In FIG. 3, 316 denotes a controller unit which is connected to a scanner unit 314 functioning as an image input device and a printer unit 312 functioning as an image output device, and is also connected to a LAN (e.g., LAN 112 shown in FIG. 1) or a public line (WAN) (e.g., PSTN or ISDN, etc.) to input and output image data and device information.

[0047] In the controller unit 316, a CPU 301 is a processor that controls the entire system. A RAM 302 is a system work memory for the operation of the CPU 301, and also serves as a program memory for recording programs and an image memory for temporarily recording image data.

[0048] Reference numeral 303 denotes a ROM in which a boot program and various control programs for the system are stored, and 304 denotes a hard disk drive (HDD) in which various programs for controlling the system, image data, and the like are stored.

[0049] An operation unit interface (operation unit I / F) 307 is an interface with an operation unit (keyboard) 308. The operation unit I / F 307 also plays a role in transmitting key information input from the operation unit 308 (for example, pressing a start button) to the CPU 301.

[0050] Reference numeral 305 denotes a network interface (Network I / F) which is connected to the network (LAN) 112. It is also configured to be capable of wireless communication, and connects to other devices via communication using infrared, Bluetooth (registered trademark), or Wi-Fi (registered trademark) to input and output data. Reference numeral 306 denotes a modem which connects to a public line and inputs and outputs data such as sending and receiving faxes.

[0051] Reference numeral 318 denotes an external interface (external I / F), which is an I / F unit that accepts external inputs such as USB, IEEE1394, a printer port, and RS-232C, and in this embodiment, a card reader 319 for reading an IC card (storage medium) of a mobile terminal required for authentication is connected to the external I / F 318. The CPU 301 controls the reading of information from the IC card of the mobile terminal by the card reader 319 via this external I / F 318, and can obtain the information read from the IC card of the mobile terminal. The above devices are arranged on a system bus 309.

[0052] An image bus interface (IMAGE BUS I / F) 320 is a bus bridge that connects the system bus 309 and an image bus 315 that transfers image data at high speed and converts the data structure.

[0053] The image bus 315 is configured as a PCI bus or IEEE 1394. The following devices are connected to the image bus 315.

[0054] Reference numeral 310 denotes a raster image processor (RIP), which develops vector data such as PDL code into a bitmap image. Reference numeral 311 denotes a printer interface (printer I / F), which connects a printer section 312 to a controller unit 316 and performs synchronous / asynchronous conversion of image data. Reference numeral 313 denotes a scanner interface (scanner I / F), which connects a scanner section 314 to the controller unit 316 and performs synchronous / asynchronous conversion of image data.

[0055] An image processing unit 317 performs correction, processing, and editing on input image data, and performs printer correction, resolution conversion, etc. on print output image data. In addition, the image processing unit 317 also performs image data rotation, and compression and decompression processing such as JPEG for multi-value image data and JBIG, MMR, MH for binary image data.

[0056] The scanner unit 314 illuminates an image on a paper document, scans it with a CCD line sensor, and converts it into an electrical signal as raster image data. The document paper is set on the document feeder tray, and when the device user issues a command to start reading from the operation unit 308, the CPU 301 gives a command to the scanner unit 314, and the feeder feeds the document paper one sheet at a time and performs the operation of reading the document image.

[0057] Printer unit 312 is a part that converts raster image data into an image on paper, and any method can be used, such as an electrophotographic method using a photosensitive drum or photosensitive belt, or an inkjet method in which ink is ejected from a minute nozzle array to directly print an image on paper. The printing operation is started by an instruction from CPU 301. Printer unit 312 has multiple paper feed stages so that different paper sizes or different paper orientations can be selected, and corresponding paper cassettes are provided.

[0058] The operation unit 308 has an LCD display unit with a touch panel sheet attached onto the LCD, and displays a system operation screen, and when a displayed key is pressed, transmits position information of the key to the CPU 301 via the operation unit I / F 307. The operation unit 308 also has various operation keys, such as a start key, a stop key, an ID key, and a reset key.

[0059] Furthermore, the display performance of the display unit varies depending on the printing device, and the present invention is composed of a printing device that can be operated via a touch panel, and a printing device that simply has an LCD screen and displays character strings (such as the printing status and the name of the document being printed).

[0060] The start key on the operation unit 308 is used when starting the operation of reading an original image, etc. A two-color LED, green and red, is located in the center of the start key, and the color indicates whether the start key is ready to use. The stop key on the operation unit 308 serves to stop an operation that is in progress. The ID key on the operation unit 308 is used when entering the user ID of the user. The reset key is used when initializing the settings from the operation unit.

[0061] Under the control of CPU 301, card reader 319 reads information stored in an IC card (which may be provided in a mobile terminal as an IC chip) and notifies CPU 301 of the read information via external I / F 318.

[0062] The card reader 319 is compatible with the NFC communication standard and is configured to be able to read and write data from and to IC chips on IC cards and mobile terminals. When an NFC-compatible mobile terminal is held over an NFC-compatible card reader, authentication is performed and pairing is performed between the mobile terminal and the printing device.

[0063] It is then possible to establish communication (P2P) between the held-up mobile device and the printer, and to exchange data. It is also possible to hand over communication to Bluetooth (registered trademark) or Wi-Fi (registered trademark), which are high-speed communication standards, and have the mobile device and printer communicate with each other.

[0064] For example, by holding a mobile terminal over a card reader, it becomes possible to transmit images stored in the mobile terminal to a printing device. Note that details of the NFC communication standard are omitted here because they are conventional technology.

[0065] In the above-mentioned printing device 108, a platform for controlling the printing device 108 exists, and an authentication application for communicating with an authentication server (which may be the server 106) runs on this platform. The authentication application is stored in the HDD 304. Areas are reserved on the HDD 304 for login contexts that store user information at login and various setting information, which are managed by the platform.

[0066] Additionally, applications that extend the main functions of the printing device 108 are installed and run on the platform. These applications are executed using the API of the platform.

[0067] Through this platform, each function of the printing device 108 can be controlled.

[0068] The printing device 108 also stores a Web browser, and can cooperate with a Web system. In this case, a screen received from a Web application server is displayed using the Web browser. A command given on the Web browser is requested to the Web application server, and by receiving the command from the Web application server, the printing device 108 can execute an operation (scanning or printing).

[0069] With the above-described configuration, the printing device 108 can transmit image data read from the scanner unit 314 onto the LAN 112 , and can print out print data received from the LAN 112 using the printer unit 312 .

[0070] In addition, image data read from a scanner unit 314 can be sent by FAX over a public line via a modem 306 , and image data received by FAX over a public line can be output by a printer unit 312 .

[0071] Next, the process of generating an invoice issuance request will be described with reference to the flowchart shown in Fig. 4. Note that, although the present embodiment will be described as an invoice issuance request, the request may be a receipt, estimate, or delivery note as long as it is an issuance request for an electronic book having index data.

[0072] Each step in FIG. 4 is a processing step executed by the CPU 201 of the bill recipient terminal 110 and the CPU 201 of the Web server / batch server 105, respectively.

[0073] Prior to the flow chart of Figure 4, a browser or application is launched on the invoice recipient terminal 110 to start communication with the Web server / batch server 105. Figure 4 shows an example of communication with the Web server 105. Although not shown, it is assumed that an authentication operation for logging in to the Web server 105 is performed on the invoice recipient terminal 110 prior to the processing of S401.

[0074] In S401 of FIG. 4(a), the bill recipient terminal 110 transmits from the Web server 105 a display command for a bill registration information input Web page for inputting bill information.

[0075] In S402, Web server 105, having received the display command, transmits the invoice registration information input Web page to invoice recipient terminal 110. An example of the invoice registration information input Web page that is transmitted will be described with reference to FIG.

[0076] FIG. 7 is an example of an invoice registration information input web page in the present invention.

[0077] Web page 700 in FIG. 7 is an example of an invoice registration information input web page generated by a web server, in which an invoice recipient registers information about the invoice to be received in an input field for receiver input field 720.

[0078] In the document name input field 701, the invoice recipient registers the document name of the invoice and inputs information to identify what type of invoice it is. In the supplier input field 702, the ID of the supplier to which the invoice is to be requested is input or selected from among multiple supplier IDs. In addition, the recipient specifies the destination to which the invoice issuance request email is to be sent from the person in charge input field (not shown). The file upload area 703 is an area for uploading the invoice file issued by the invoice issuer. The file upload area 703 will be described later with reference to Figures 8 and 9.

[0079] The input field for receiving company information 710 accepts input of input items that are set by the company receiving the invoice and do not need to be disclosed to the invoice issuer. For example, it has a storage expiration date 707 for inputting the period for which the invoice will be stored, an email notification date input field 705 for inputting the date on which an email will be sent (notified) to the invoice issuer, and a notification category selection field 706 for selecting whether to notify periodically, notify only once, or not notify at all as the email notification category. The email notification date input field 705 and the notification category selection field 706 will be explained in the next steps S403 and S404.

[0080] The index data input field 730 is an input field where the invoice issuer enters data when attaching an invoice file. This will be described later with reference to Figure 9. Returning to the explanation of the flowchart in Figure 4(a),

[0081] In S401 of Figure 4(a), the invoice recipient terminal 110 receives information for the invoice registration information input web page from the web server 105, and displays it on the display 210 of the invoice recipient terminal 110. Next, in S403, the invoice recipient terminal 110 accepts input from the user into the email sending date setting item on the displayed invoice registration information input web page. The email sending date setting item is the email notification date input field 705 and notification category selection field 706 in the recipient company information input field 710 in Figure 7. This will be explained with reference to the flowchart in Figure 4(b).

[0082] FIG. 4(b) is a flow chart illustrating the flow of processing in which invoice recipient terminal 110 accepts input for setting the date on which an invoice issuance request email is to be sent.

[0083] At S411 in Figure 4, the invoice recipient terminal 110 accepts input from the user in the email notification category selection field 706. If the email notification category is "periodic notification", the process proceeds to S412, and if the email notification category is "one time only", the process proceeds to S414. If the email notification category is "no notification", email notification is not set and the process of Figure 4(b) ends.

[0084] When the process proceeds to S412, the invoice recipient terminal 110 receives input from the user in the email notification date input field 705, such as a predetermined date (for example, the 25th of the month) and a regular interval (every month).

[0085] Next, in S413, the bill recipient terminal 110 acquires the date for sending the email as a setting for sending at regular intervals (the 25th of each month in the above example).

[0086] On the other hand, when the process proceeds to S414, the invoice recipient terminal 110 accepts input of a specific date by the user in the email notification date input field 705 (for example, April 20, 2023).

[0087] Next, in S415, the invoice recipient terminal 110 sets the date for sending the email to a specific date (April 20, 2023 in the above example) and sends the email only once. In order to make the email to be sent identifiable, a flag for attaching identification information to the email to be sent only once may be attached. An example of attaching identification information to an email to be sent only once will be described later in FIG. 11.

[0088] In addition, in the case of setting not to notify by email in S411, the invoice issuer does not know the URI of the specified invoice registration web page, but by pressing the search button 740 in FIG. 7 from the parent layer web page of the specified invoice registration information input web page in FIG. 7, the invoice search result as shown in FIG. 13 can be displayed. For example, for an invoice search result such as "BBBB Project Invoice" 1304 in FIG. 13 where the document name is not a link button (underlined in blue), pressing the information button "i" 1305, for example, can transition to the invoice registration web page screen as shown in FIG. 8. After transitioning to the screen as shown in FIG. 8, input of the invoice file and index data is accepted as in S505 described later. An example of not notifying by email is, for example, a process of not notifying by email to an invoice issuer who routinely issues invoices and finds it troublesome to receive emails. Note that FIG. 13 can be confirmed on both the invoice recipient terminal 110 and the invoice issuer terminal 104. Screen example 1300 is an example displayed on the invoice recipient terminal 110 (with "Takeda Shingen" of Kannon Sales in the person in charge column 1309), but when this screen is opened on the invoice issuer terminal 104, the person in charge who issues the invoice will naturally be displayed in the person in charge column 1309. Returning to the explanation of the flowchart in Figure 4(a),

[0089] In step S403 of FIG. 4A, when the setting of the mail sending date is accepted from the user, in step S404, the Web server 105 receives and stores the setting information of the mail sending date.

[0090] Next, in S405, the bill recipient terminal 110 accepts input of information on the bill that the user wishes to receive from the user. An example of accepting input of bill information from the user will be described with reference to FIG.

[0091] For example, if the invoice recipient enters "AAAA Project Invoice" in the document name input field 701 in Fig. 7 and selects "00000000005" (the ID of "Canon Co., Ltd.") in the client (=invoice issuer) ID input field 702 using a suggestion function or the like, "AAAA Project Invoice" will be displayed in the document name input field 801 on the display 210 of the invoice issuer terminal 104 as shown in Fig. 8, and the invoice issuer name "Canon Co., Ltd." obtained from the database server 106 will be displayed to the right of the client ID input field 802 (see customer data 1020 in Fig. 10). As described above, the invoice recipient terminal 110 accepts the input of information for sending the invoice issuer and the document name of the invoice (both are invoice registration information) in S405.

[0092] In S406, Web server 105 receives the invoice registration information sent from invoice recipient terminal 110 and records it in Web server 105. This concludes the explanation of the flow of processing prior to sending the invoice issuance request email.

[0093] The flow of processing for sending an invoice issuance request email will be described with reference to the flowchart shown in FIG.

[0094] 5 are processing steps executed by the CPU 201 of the Web server / batch server 105, the bill issuer terminal 104, and the bill recipient terminal 110, respectively.

[0095] 5(a) is a flowchart explaining the process flow of sending an invoice issuance request email from the Web server / batch server 105 to the invoice issuer terminal 104, and accepting input of an invoice file and index data related to the invoice file from the invoice issuer terminal 104. Although not shown, it is assumed that the invoice issuer terminal 104 performs an authentication operation for logging in to the Web server 105 before the process of S505.

[0096] The flowchart in FIG. 5(a) shows the process that starts on the mail sending date recorded in S404 in FIG.

[0097] In S501 of Fig. 5(a), Web server 105 generates an invoice registration Web page from the invoice registration information recorded in S406. An example of the screen display of the generated invoice registration Web page is shown in Fig. 8.

[0098] FIG. 8 is an example of a screen displayed on the display 210 of the invoice issuer terminal 104, and is an example of an invoice registration Web page generated in S501 of the flow chart of FIG.

[0099] 8, the invoice registration web page displays "AAAA Project Invoice" in document name input field 801 and "Canon Co., Ltd." to the right of the client ID input field 802, and is a web page for requesting registration of the invoice to "Uesugi Kenshin" (809), a person in charge at "Canon Co., Ltd." Note that a notice 804 is displayed encouraging input of required fields, issue date 811 and invoice amount field 812.

[0100] The invoice registration web page may be generated just before the email is sent or on the day the email is sent, and the invoice registration web page may not be generated before the email is sent. This specification is a measure to allow the invoice registration web page to be accessed from URIs other than those included in the email. The invoice issuer can search for the invoice registration web page by using the search button 808 in Figure 8 from the URI of the parent hierarchy. If the invoice registration web page is generated in advance before the day the email is sent, for example, when the invoice issuer registers an invoice whose issuance is delayed (such as the previous month's invoice), there is a possibility that the invoice file will be mistakenly uploaded to the wrong invoice registration web page. To prevent this mistake, the invoice registration web page of the URI included in the email is not generated before the invoice issuance request email is sent. Return to the explanation of the flowchart in Figure 5.

[0101] In S501 of (a) in Figure 5, an invoice registration web page like that in Figure 8 is generated and placed at a specified URI (identification position) of the invoice registration web page. Then, in S502, the batch server 105 transmits an invoice issuance request email to the invoice issuer terminal 104. An example of the text of the email to be transmitted will be described with reference to Figure 11.

[0102] FIG. 11 is a diagram showing an example of the invoice issuance request email text.

[0103] Displayed in 1100 are a registration URL field 1101 indicating the URI of the invoice registration web page set in S501 and an invoice document name 1102 that specifies what type of invoice it is. When the invoice issuing clerk presses the URI portion of the registration URL field 1101, the invoice registration web page generated in S501 is displayed.

[0104] The report list URL column 1103 is a URI for displaying a list of reports (invoices) that have been issued by the invoice issuer (Canon Inc. in the example of Figure 11), and the login URI 1104 is a URI for performing login authentication to access the above two URIs.

[0105] FIG. 11 is an example of an email when one-time notification is selected in S411 of FIG. 4. In the case of one-time notification, the email may be sent with an importance flag such as "Impotence: high" 1110 so that it is identifiable and not buried in other emails. In the case of a one-time invoice issuance request email, unlike an invoice that is requested to be issued periodically on a specified date, if the invoice issuer misses the email, it is highly likely that they will not notice until they send a reminder email. Therefore, in the case of a one-time invoice, an importance flag may be attached so that it can be distinguished from other emails. In addition to the importance flag, any method may be used as long as it is easy for the invoice issuer to identify the email, such as attaching a black square (■) to the subject of the email or enclosing the subject in black brackets. Return to the explanation of the flowchart in FIG. 5.

[0106] In S503 of (a) in Figure 5, the invoice issuer terminal 104 receives the email sent from the batch server 105, and displays the email text on the display 210 of the invoice issuer terminal 104 at the instruction of the invoice issuer (in the case of Figure 8, "Uesugi Kenshin").

[0107] The invoice issuer displays the received email and creates an invoice for the relevant product or service based on the invoice document name 801 etc. stated in the email. In S504, the invoice issuer terminal 104 stores the created invoice as a file on an information processing device. The invoice to be stored may be a file generated on an information processing device, or it may be paper. In the case of a paper invoice, it is converted into a PDF file format using the scanner device 102 or MFP 108 etc., and stored in the invoice issuer terminal 104. An example of a created invoice will be described with reference to FIG. 12.

[0108] FIG. 12 is an example of a generated invoice, which is an example of an invoice associated with the drawings of FIGS.

[0109] 1200 is an example of an invoice issued by "Canon Co., Ltd." to "Kannon Sales Co., Ltd." The items specified as search items in the Electronic Bookkeeping Act among the items described in the invoice are "transaction date and other dates," "transaction amount," and "client." The transaction date (invoice date 1202) is "2023 / 4 / 20," the transaction amount 1201 is "32,800 yen," and the client 1203 is "Canon Co., Ltd." These index data must be linked to this invoice and stored so that they can be easily searched for at a later date. After the explanation of FIG. 12, we return to the explanation of the flowchart in FIG. 5.

[0110] In S505 of (a) in Figure 5, when the invoice issuer presses the registration URL field 1101 of the invoice issuance request email displayed on the display 210, the invoice issuer terminal 104 sends a command to the Web server 105 to display the invoice registration Web page.

[0111] In S506, upon receiving the invoice registration web page display command, the Web server 105 transmits the invoice registration web page generated in S501 to the invoice issuer terminal 104. The transmitted invoice registration web page is displayed on the display 210 of the invoice issuer terminal 104, and in S505, the invoice issuer terminal 104 accepts input of index data by the invoice issuer. Note that, in addition to input by the invoice issuer, the index data may also be input by collating data for multiple invoices as a comma separated value (csv) file and uploading it together with the invoice file.

[0112] In S506, the Web server 105 accepts the index data entered on the invoice registration Web page. The index data entry acceptance process will be described with reference to Figs.

[0113] 8 and 9 are examples of screen displays displayed on the display 210 of the bill issuer terminal 104. FIG.

[0114] FIG. 8 shows the invoice registration web page generated by S501, which prompts the user to enter required items (issue date and invoice amount) in the index data entry area 830 (804). An example of values ​​entered in the issue date field 811 and the billing amount field 812 is shown as 930 in FIG.

[0115] FIG. 9 is an example of the invoice registration web page screen after index data has been input by the invoice issuer in S505 and S507 and the invoice file has been uploaded.

[0116] The invoice issuer has entered "2023 / 4 / 20" in the issue date field 911 of 930 in Figure 9, and "32,800" yen in the invoice amount field 912. The supplier information is set as shown in 913 when the invoice registration web page is generated. Returning to the explanation of the flowchart in Figure 5.

[0117] When the input of index data to the invoice registration Web page is accepted in S505 in (a) of FIG. 5, in S507, the invoice issuer terminal 104 accepts upload of the invoice file by the invoice registration Web page. The invoice file is uploaded by dragging and dropping the file into the file upload field 803 in FIG. 8, or by specifying the file from the file specification pop-up window output after pressing the browse button. The file upload field 903 in FIG. 9 shows an example of the screen after uploading. A file with the file name "AAAA Project Invoice.pdf" is set in the file upload field 903. Note that multiple files can be uploaded to the file upload field 903, and when uploading multiple invoice files, the index data cannot be linked with this UI, so a csv file of the index data uploaded in parallel with the multiple invoice files is uploaded. The index data may be linked with a csv file linked to the file name to be uploaded (for example, multiple lines of csv data in which one file name and one invoice index data are input in each line). In this case, the index data is not input in S505, and the csv file is uploaded together with the invoice file in S507.

[0118] In S508, the Web server 105 records in the database server 106 the invoice file uploaded in S507 from the invoice issuer terminal 104 to the invoice registration Web page, and links the index data input in S506 or the CSV file uploaded together with the invoice file in S507 to the index data, and records it in the database server 106. This concludes the explanation of the flowchart in Figure 5(a).

[0119] The flowchart in Figure 5(b) shows the process of downloading the invoice file uploaded to the Web server 105 to the invoice recipient terminal 110 and displaying the invoice file and index data to check the consistency between the index data and the invoice file, etc.

[0120] In S511 of FIG. 5, the bill recipient terminal 110 transmits to the Web server 105 a request to acquire a bill file and index data linked to the bill file.

[0121] In S512, the Web server 105 acquires the bill file and index data requested for display from the database server 106, and transmits them to the bill recipient terminal 110.

[0122] In S513, the bill issuer terminal 110 displays the bill file and index data received from the Web server 105 on the display 210. An example of a screen displaying the bill file and index data will be described with reference to FIG.

[0123] FIG. 13 is a display example showing the invoice file search result screen.

[0124] 1300 in FIG. 13 is an example of an invoice list screen as a result of a search performed by an invoice recipient (in the case of 1300, the Kannon Sales Representative column 1309 is Takeda Shingen) using the search button 1308.

[0125] When the invoice recipient clicks on the "AAAA Project Invoice" link button 1301, which is registered as a link button to the document name in 1300, the invoice screen 1200 in Figure 12 is displayed. The invoice recipient checks (consistency checks) the displayed invoice screen 1200 and the index data in the "AAAA Project Invoice" row in 1300, and if they are consistent, the invoice recipient clicks check box 1302. An invoice with an explanation mark "!" in the check box as in 1302 indicates an invoice that has not been checked for consistency, and an invoice with a check mark as in check box 1303 indicates an invoice that has been checked by the invoice recipient. This concludes the explanation of Figure 13.

[0126] After the display process of the invoice file and index data in S513 in Fig. 5 is completed, the invoice recipient creates and submits a payment request form to the accounting department or the like based on the index data of the invoice, and proceeds with the procedure to have the invoice issuer pay the invoice amount. The data to be sent to the accounting department is the index data that has been checked for consistency with the invoice file in S513, making it easy to create a payment request form and reducing the amount of input work into the accounting system. The process from S513 onwards is not relevant to the contents of this invention, so a description will be omitted.

[0127] As described above, the present invention allows the invoice recipient to obtain index data without the invoice issuer having to build an invoice issuing system. The invoice issuer can also prevent the risk of missing a delivery address or losing an invoice, which can occur when sending an invoice to an individual, and can check invoices in a list as in the example screen of Figure 13, preventing the invoice issuer from missing a delivery. In addition, the invoice recipient can see whether or not an invoice has been confirmed (1303 in Figure 13), reducing the effort required to confirm receipt of the invoice.

[0128] When the index data is sent from the invoice issuer as a CSV file in step S507, it is desirable that the format of the CSV file to be sent (such as the definition of the data order) be defined in advance by the invoice recipient. A file in this format may be sent to the invoice issuer as a CSV file in S502 together with an email, or it may be sent to the invoice issuer in advance and entered by the invoice issuer when sending the CSV file in S507.

[0129] In the case where the format of the csv file is sent to the invoice issuer together with an email in S502, an example of the csv file to be sent to the invoice issuer will be described with reference to Fig. 10. Note that in the data examples 1000 and 1010 in Fig. 10, the data is displayed in a table format rather than a comma-separated format in order to make it easier to view.

[0130] Data example 1000 in Figure 10 is an example of a CSV file attached immediately after an invoice issuance request email is sent from the invoice recipient to the invoice issuer. Predetermined data is entered for items that should be specified in advance, such as the recipient ID, issuer ID, and form name. In data example 1000, "Kannon Sales Co., Ltd." with recipient ID "100000000001" and "Canon Co., Ltd." with issuer ID "00000000005" (for both, see 1020) are entered, and the form name in the first line of data example 1000 clearly indicates that it is a request to issue an "AAAA Project Invoice."

[0131] When an invoice issuer receives a CSV file such as data example 1000, the invoice issuer opens the CSV file using a CSV editor (not shown, for example, Excel (registered trademark)) and enters data into the required fields. Data example 1010 is an example of data entered by an invoice issuer. In the file name field of the first line of data example 1010, "AAAA Project Invoice.pdf" is entered, the issue date is "2023 / 4 / 20", and "￥32,800" is entered in the invoice amount field. This data is an example of one line for invoice 1200 in Figure 12.

[0132] As described above, by using a common CSV file format, index data linking can be easily set up.

[0133] As described above, the present invention allows the invoice recipient to obtain index data without the invoice issuer having to build an invoice issuance system. In addition, the invoice issuer can prevent the risk of missing a delivery address or losing an invoice, which can occur when sending an invoice to an individual, and the invoice issuer can prevent missing a delivery because the invoice can be confirmed in a list as in the example screen of Figure 13. In addition, the invoice recipient can tell whether or not confirmation has been made (1303 in Figure 13), which reduces the effort required to confirm receipt of the invoice.

[0134] Although the embodiment of the present invention has been described above, the present invention can be embodied, for example, as a system, an apparatus, a method, a program, a recording medium, etc. Specifically, the present invention may be applied to a system composed of multiple devices, or may be applied to an apparatus composed of a single device.

[0135] The program of the present invention is a program that enables a computer to execute the processing method of the flowchart shown in Fig. 4 or 5, and the storage medium of the present invention stores a program that enables a computer to execute the processing method of Fig. 4 to 5. The program of the present invention may be a program for each processing method of each device in Fig. 4 or 5.

[0136] As described above, it goes without saying that the object of the present invention can be achieved by supplying a recording medium on which a program that realizes the functions of the above-mentioned embodiments is recorded to a system or device, and having the computer (or CPU or MPU) of that system or device read and execute the program stored on the recording medium.

[0137] In this case, the program itself read out from the recording medium will realize the novel functions of the present invention, and the recording medium on which the program is recorded will constitute the present invention.

[0138] Examples of recording media for supplying the program include flexible disks, hard disks, optical disks, magneto-optical disks, CD-ROMs, CD-Rs, DVD-ROMs, magnetic tapes, non-volatile memory cards, ROMs, EEPROMs, silicon disks, etc.

[0139] Furthermore, it goes without saying that the functions of the above-mentioned embodiments are not only realized by the computer executing a program it has read, but also includes cases where an OS (operating system) running on the computer performs some or all of the actual processing based on the instructions of the program, and the functions of the above-mentioned embodiments are realized through that processing.

[0140] Furthermore, it goes without saying that this also includes cases where a program read from a recording medium is written into a memory provided on a function expansion board inserted into a computer or a function expansion unit connected to a computer, and then a CPU or the like provided on the function expansion board or function expansion unit performs some or all of the actual processing based on the instructions of the program code, thereby realizing the functions of the above-mentioned embodiments.

[0141] The present invention may be applied to a system consisting of multiple devices, or to an apparatus consisting of a single device. Needless to say, the present invention can also be applied to a case where the object is achieved by supplying a program to a system or apparatus. In this case, the effect of the present invention can be enjoyed by the system or apparatus by reading a recording medium storing a program for achieving the present invention into the system or apparatus.

[0142] Furthermore, by downloading and reading a program for achieving the present invention from a server, database, etc. on a network using a communication program, the system or device can enjoy the effects of the present invention. Note that the present invention also includes configurations that combine the above-mentioned embodiments and their modified examples. [Explanation of symbols]

[0143] 100 Information Processing Systems 102 Scanner device 104 Bill Issuer Terminal 105 Batch server and Web server 106 Database Server 108 MFP 110 Bill Recipient Terminal 112 Internet line 114 Cloud Environment

Claims

1. A designation acceptance means that accepts the designation of the issuer of the documents relating to a transaction from the recipient of the documents relating to a transaction, A transmission control means that transmits to the issuer information of a screen that accepts the attachment of documents related to the transaction addressed to the recipient and the input of index data for the attached documents related to the transaction, based on the designation by the designated receiving means, A receiving means for receiving the documents relating to the transaction addressed to the recipient, attached by the issuer via the screen displayed based on the information on the screen, and the index data entered via the screen, A storage control means that controls the storage of the attached transaction documents and the entered index data received by the receiving means in an area managed by the recipient. A transaction management system characterized by having the following features.

2. The transaction management system according to Claim 1, characterized in that the transmission control means transmits information on a screen that includes information for displaying a list of documents related to the transaction that have been issued by the issuer in the past, which is stored in an area managed by the recipient.

3. A generation means that generates the screen to be transmitted to the issuer by the transmission control means in response to the designation of the issuer's information being received by the designation receiving means. Furthermore, The transaction management system according to claim 1, characterized in that the transmission control means transmits access information to the screen generated by the generation means.

4. The transaction management system according to claim 3, characterized in that the generation means generates a screen comprising a function unit for attaching documents relating to the transaction and a function unit for receiving input of index data for the attached documents relating to the transaction.

5. The transaction management system according to claim 3, characterized in that the generation means generates the screen individually for each document relating to the transaction.

6. Identification information receiving means for receiving the input of identification information of documents relating to the transaction addressed to the recipient from the recipient. Furthermore, The transaction management system according to claim 1, characterized in that the transmission control means transmits information on the screen, including identification information of documents relating to the transaction.

7. The transaction management system according to claim 1, characterized in that the transmission control means controls the transmission of an email via email prompting the attachment of documents related to the transaction and the input of the index data.

8. The transaction management system according to claim 3, characterized in that the generation means generates the screen immediately before the transmission control means controls the transmission of the screen information or on the day the screen information is transmitted.

9. A transmission designation receiving means that receives a designation from the recipient as to whether or not to periodically transmit the information on the screen, The transaction management system according to claim 1, characterized in that the transmission control means periodically transmits the information on the screen to the issuer that received the designation from the designation receiving means when the transmission designation receiving means receives a designation to periodically transmit the information on the screen, and transmits the information on the screen to the issuer that received the designation from the designation receiving means at a predetermined timing when the designation receiving means does not receive a designation to periodically transmit the information on the screen.

10. The designated receiving means receives the designation of the information of the issuer of the document relating to the transaction via a terminal operated by a user of the organization that is the recipient, The transaction management system according to claim 1, characterized in that the receiving means receives the transaction documents addressed to the recipient, attached via the screen displayed on a terminal operated by a user of the issuing organization, and the index data entered via the screen.

11. The transaction management system according to claim 1 or 3, characterized in that the screen is a web page.

12. A method for controlling a transaction management system, The designated acceptance method includes a designated acceptance step in which the recipient of the transaction documents specifies the information of the issuer of the transaction documents, A transmission control means transmits to the issuer information of a screen that accepts the attachment of documents related to the transaction addressed to the recipient and the input of index data for the attached documents related to the transaction, based on the designation made in the designation acceptance step. The receiving means includes a receiving step that receives the documents relating to the transaction addressed to the recipient, attached by the issuer via a screen displayed with information from the screen, and the index data entered via the screen, A memory control means controls the memory control means to store the attached transaction documents and the input index data received in the reception step in an area managed by the recipient. A control method characterized by including

13. A program for causing at least one computer to function as one of the means of the transaction management system described in any one of claims 1 to 10.

14. A program for causing at least one computer to function as each of the means of the transaction management system described in Claim 11.

Images