JP2007025849A - Continuous factoring system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a method or the like suitable for a business category in which a number of relatively small transactions such as the transaction of fresh merchandise are performed almost everyday, and which can reduce a labor hour and cost required for the business work of prepayment processing and hardly causes troubles accompanied by prepayment. <P>SOLUTION: The method for a server to perform prepayment processing to a merchandise seller based on a plurality of sales credits comprises the following steps: A schedule management means periodically instructs the start of prepayment processing to a prepayment processing means according to a predetermined short-period schedule; the prepayment processing means retrieves a sales credit table to specify one or more sales credits generated in one of short periods; the prepayment processing means calculates the total of prepaid amounts related to the specified sales credits; and the prepayment processing means outputs a prepayment instruction containing the total prepaid amount. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a method and the like for a debt payment company to make a pre-payment before an actual payment is made by a buyer based on a trade receivable generated in a commodity transaction. In particular, the present invention relates to a method that is suitable for continuously and safely performing advance payment and settlement in a business condition in which a large number of relatively small transactions are performed every day.

  Recently, in the same way as bill discounts, so-called factoring has been carried out in which individual advance payments are made before actual payments by buyers based on relatively large accounts receivable arising from commodity transactions. I came. The creditor individually specifies the receivables that are desired to be paid in advance and makes a request for advance payment to the credit payment company that performs factoring. At that time, in order to reduce the risk associated with the collection of receivables by the receivables paying company, it is necessary to determine the details of the receivables as well as bills. Upon receipt of the request, the receivable payment company receives the receivable transfer for each receivable and pays the creditor in advance the amount after deducting the factoring fee. Thereby, although the creditor bears the fee, there is an advantage that the timing of the collection of the receivable becomes earlier and the cash flow becomes easier.

  As an example of a system for performing factoring, for the purpose of enabling a new fund procurement method corresponding to the long-term care insurance system, a predetermined item (7- A system that pays up to 80%) as an upper limit, and then pays the unpaid portion according to the amount when payment is made from the debtor on the due date. It is disclosed (see Patent Document 1). In this system, each nursing care receivable is individually handled in the same way as a bill, and is paid in advance according to a copy of the receipt at the time of application for advance payment, and then paid in advance according to the buyer's payment schedule.

  By the way, although individual merchandise transactions are relatively small, in a business condition in which a large number of transactions are performed every day, each receivable is generated in a relatively small amount. For example, in the case of fresh products such as fruits and vegetables such as vegetables and fruits, flowers, seedlings, etc., the value of the product greatly fluctuates in short units such as days or weeks due to ripening or decay. Therefore, producers of fresh products determine the quantity of products to be shipped to the market on a daily basis, taking into account the weather conditions, event schedules, market prices, etc. during the harvest season of the products. In response to daily orders from retailers (mass retailers), collect as many products as possible that can be shipped by producers scattered throughout the country to ensure the quantity and quality of the required products. ing. In other words, a large number of relatively small commodity transactions need to be performed every day. For this reason, if an attempt is made to perform paperwork for payment similar to a bill, a large amount of time and money is required for paperwork.

  In addition, perishable products tend to be damaged due to bruises during transportation, and the quality of the delivered products may differ from the order due to the convenience of the producer, so the amount of receivables at the time of shipment changes after acceptance It's not uncommon. In addition, at the time when ordinary payment paperwork is made, in many cases, the goods are already discarded or consumed and disappear, and it is difficult to verify the amount of accounts receivable afterwards. For these reasons, there is a large difference in certainty between individual accounts receivable and bills in such business categories.

  In other words, if factoring is performed in the same manner as in the bill discount in the business type described above, the administrative work associated with the number of daily transactions is complicated, and the amount of each transaction is often changed, so the amount of receivables increases. There is a problem that it is uncertain and it is difficult to confirm afterward because the product has deteriorated or disappeared in a short period of time, and the creditor company that performs factoring bears a large work cost and recovery risk Become. Furthermore, since products change according to the season, there is no guarantee that there will be continuous transactions with producers of each product, and payment may be delayed if there is a residual payment or overpayment. In addition, the credit status of producers may change during periods when there are no transactions, and this is also a risk for bond payers.

  Here, a system for supporting transactions of commodities to be determined in the future is disclosed, in which the amount of accounts receivable is not fixed between buyers and sellers before transfer of receivables. Specifically, the valuation value of accounts receivable is determined based on the provisional transaction value of the product to be traded, and when the actual transaction value of the product is determined by the subsequent agreement between the buyer and the seller, the transaction value is determined by the buyer or seller. A system is disclosed in which a difference amount between an actual transaction amount and an evaluation amount is calculated based on one of them, and the difference amount is used for purchase or financing of future accounts receivable from the seller (patent document) 2).

In this system as well, each trade receivable is handled separately in principle, as with bills, and the problem of work costs and recovery risks incurred by the payer is not solved. In addition, if there is a difference between the appraisal value and the actual transaction amount, the difference will not be settled until an appropriate transaction or loan is made thereafter. It's hard to understand or trouble. In particular, problems such as the above-described perishable product transactions, in which many transactions are complicated, are likely to cause problems. In addition, since it is impossible to verify whether or not the actual transaction amount communicated is correct, it is difficult to prevent the fraud of the advance payment by the seller or the like.
JP 2002-56199 A JP 2003-91656 A

  The present invention is suitable for business conditions in which relatively small transactions are made almost every day, such as fresh product transactions, and can reduce the labor and cost of prepaid office work and is less likely to cause troubles associated with prepaid processing. It is an object to provide a factoring system or a server therefor. Preferably, it is an object of the present invention to provide a method or the like that reduces a risk to be borne by a creditor company that performs factoring in the business conditions as described above.

  A first aspect of the present invention is a method for a server to perform advance payment processing for a seller of a product based on a plurality of trade receivables of the product, wherein the schedule management means follows a predetermined short cycle schedule. Periodically instructing the advance payment processing means to start the advance payment processing, and the advance payment processing means, in accordance with the advance payment instruction, transfers one or more accounts receivable generated in one of the short cycles to a plurality of sales A step of searching and specifying an accounts receivable table in which credit receivable information is stored; a step in which the advance payment processing means calculates a total amount of advance payment related to the specified trade receivable; and the advance payment processing means And a step of outputting a prepaid instruction including the total prepaid amount.

  Here, the schedule management means further includes a step of instructing the postpayment processing means to start the postpayment processing periodically according to a predetermined long-cycle schedule, and the postpayment processing means follows the postpayment instruction, A step of searching the accounts receivable table to identify one or more accounts receivable generated in one of the long periods, and the post-payment processing means converts the identified accounts receivable to the accounts receivable Preferably, the step of calculating the sum of the postpaid amount by reducing the prepaid amount concerned and the step of the postpay processing means outputting a postpayment instruction including the total postpaid amount.

  Further, the schedule management means instructs the payment verification processing means to start the buyer payment confirmation process periodically according to a debt payment schedule predetermined by the buyer of the product, and the schedule management means A step of instructing the postpayment processing means to start the postpayment processing periodically according to the long-cycle schedule, and the receipt verification processing means in accordance with the confirmation processing start command, the receivable information within a predetermined period Searching for a buyer payment table that stores a plurality of buyer payment information, and the receipt verification processing means includes the account receivable information and the specified buyer payment information. The post-payment processing means In accordance with the step of searching the accounts receivable table for one or more accounts receivable generated in one of the long periods, and the postpayment processing means includes: Identifying one or more receivables whose results are determined to match, and wherein the postpayment processing means calculates a total postpaid amount by subtracting a prepaid amount associated with the specified receivable. Preferably, the postpayment processing means includes a step of outputting a postpayment instruction including the calculated total amount.

  Moreover, it is preferable that the short cycle is a day unit or a week unit, and the long cycle is a month unit. Further, the information receiving means receives a plurality of shipping information of the product from the seller terminal as needed and stores it in a shipping information table; and the information receiving means receives a plurality of the products from the product buyer terminal. Receiving the receipt information and storing it in the receipt information table, and the advance payment processing means reads and collates the shipment information and the receipt information corresponding to the shipment information, and the shipment information and the corresponding receipt information. It is preferable to include the step of storing the shipment information or the corresponding receipt information in the accounts receivable table when the two match. In addition, it is preferable that the product is a fresh product whose product value fluctuates in a short time. Moreover, it is preferable that fresh goods are fruits and vegetables.

  A second aspect of the invention is a server for performing a prepaid process for a seller of a product based on a plurality of accounts receivable of the product, and prepaid the start of the prepaid process periodically according to a predetermined short cycle schedule. A schedule management unit that commands the processing unit; and a prepaid processing unit that executes a prepaid processing in accordance with the prepaid command, wherein the prepaid processing unit stores one or more accounts receivables generated in one of the short cycles. A means for searching and specifying an accounts receivable table in which a plurality of accounts receivable information are stored, a means for calculating the sum of the advance payment amounts related to the specified accounts receivable, and the total advance payment amount And a means for outputting a prepaid instruction.

  A third aspect of the invention is a factoring system characterized in that a merchandise seller terminal, a merchandise buyer terminal, and a merchandise receivable payment company terminal are communicably connected to the server.

  Suitable for business types where relatively small transactions such as perishable products are carried out almost every day, and continuously against a large number of trade receivables without incurring tremendous administrative work and costs at the credit payment company. And reliable factoring.

  Embodiments of the present invention will be described below with reference to the drawings. First, FIG. 1 and FIG. 2 show the specific processing in the case of implementing the method of the present invention along the time axis. FIG. 1 shows the advance payment process, and FIG. 2 shows the post-payment process. The movement of information in the factoring system is indicated by solid arrows, and the movement of goods etc. outside the system is indicated by broken arrows. First, the overall outline will be described using these. All appearing are a seller 1 and a buyer 3 of a product, a server 5 that performs factoring processing, and a receivable payment company 6 that prepays accounts receivable. The seller 1, the buyer 3, and the credit payment company 6 are provided with respective terminals 2, 4, 7 connected to the server 5 through a communication means such as a telephone line, a LAN, or the Internet. These constitute a factoring system (FIG. 4).

  In FIG. 1, the transactions performed after April 1 are taken as an example between the buyer and the seller, and the processes performed for advance payment are arranged in chronological order from top to bottom. In order to facilitate understanding, both buyers and sellers are shown as a single example, but there are actually a plurality of buyers and sellers.

  First, as of April 1, the buyer orders the seller how many items and how many items to buy, and also notifies the order number. This order is preferably placed via the server 5 and the terminals 2 and 4 (A1, A2), but the order number may be specified and the buyer may contact the seller directly by some means. Then, the seller prepares the corresponding product and performs shipping A3 to the buyer on the following April 2, and the fact that the product has been shipped according to the shipping slip is input to the seller terminal 2, and the seller terminal 2 communicates with the communication line. The shipment information A5 is transmitted to the server 5 via The shipping information includes an order number, a seller, a buyer, a delivery store name, a delivery date, a product name, a unit price, a handling unit, a shipping quantity, a shipping date, a shipping amount, and the like. The server 5 that has received the shipping information stores the shipping information in a predetermined table.

  In this example, the goods shipped from the seller 1 arrive at the buyer 3 on the same day, immediately receive the inspection indicated by the black circle, receive the shipping information and stamp the buyer receipt, A delivery slip corresponding to the receipt slip is issued. The stamped receipt slip is returned to the seller 1 as needed (A4). In this example in this example, the buyer 3 inputs that the product has been received according to the delivery slip, and the buyer terminal 4 transmits receipt information A6 to the server 5 via the communication line. The server 5 that has received the receipt information A6 stores the receipt information A6 in a predetermined table.

  Similarly, an order is placed even on April 2, and shipment / receipt is made on April 3, and thereafter, commodity transactions are repeated almost every day. In this way, transactions for 5 days from April 1 to 5 are carried out. Then, on April 8, prepayment processing to the seller 1 is performed collectively for the transactions that have been concluded in these five days. The reason for the interval from April 5th to 8th is that the receipt information is not always sent immediately after receipt, and in many cases, it is sent separately in the May rainy style with time, This is because collation processing is performed after receiving as much receipt information as possible. Note that even if there are one or more transactions between seller 1 and a plurality of buyers other than buyer 3 within the same period, as long as those transactions are prepaid, they are the same as those with buyer 3 In this manner, advance payment processing is performed for the seller 1. As described above, since the advance payment processing is collectively performed for the commodity transactions occurring within the predetermined period, the burden on the server processing and the business processing of the seller is reduced.

  The advance payment process is performed as follows. First, the server 5 reads the shipping information received from the seller terminal 4 at any time during the five days from April 1st to 5th from the predetermined table, and then the receipt information corresponding to the shipping slip number for each shipping information. Are retrieved from a predetermined table in which received information is accumulated. Subsequently, the server 5 collates each shipment information with the corresponding receipt information. The collation is performed with respect to the delivery date, the delivery store name, the slip number, and the total amount, and it is determined whether these match. If both match, it can be determined that the transaction has been made correctly, so that advance payment is possible. In this way, shipping information and receipt information are accumulated as needed, and each shipment information and corresponding receipt information are collated one by one, so that there is little risk of overpayment or fraud of prepaid money. If either of them does not match, it is necessary to confirm the transaction details, and the shipping information and receipt information are printed out from the printer of the server 5 and collated with the actual receipt slip manually. Can do.

  When the server 5 completes the verification process for all of the five-day shipping slips, it calculates the total amount for the matched ones, and then subtracts the predetermined fee of the credit payment company and then multiplies the predetermined advance payment rate. To calculate the actual advance payment amount. The prepaid rate is multiplied in consideration of the fact that defective products are found at the store display stage after delivery to the buyer, and the amount of accounts receivable may further fluctuate. The advance payment rate may be determined in advance based on the past performance of each seller or each product of the seller.

  When the prepaid amount is determined in this way, the server 5 issues a prepaid instruction A8 that allows the terminal 7 of the credit payment company 6 to prepay the amount to the seller 1 who is a prepaid person. Send. The advance payment instruction includes an instruction transmission date, an advance payment designation date (for example, 4/10 after 5 days), an advance payment target person, a payment account, an advance payment amount, and the like. Receivable payment company 6 that received prepaid instruction A8 at terminal 7 performs prepaid processing A9 on the seller's account on April 10, which is the prepaid designated date. The advance payment process A9 is continuously performed every predetermined number of days, for example, every five days, as long as the merchandise transaction of the seller is continuously performed.

  These five days are an example of a short cycle in which advance payment is performed. The short cycle is a cycle in which the advance payment process is repeated for each seller, and is determined in advance within a range of several days to about two weeks shorter than the payment made at the end of each normal month. The seller can obtain a certain amount of money by advance payment and select an appropriate preferable period that does not complicate the paperwork for receiving advance payment, and register it in a predetermined table of the server 5 in advance. Therefore, the short period may be set to a unit of an arbitrary number of days from about several days to about several tens of days, or a weekly advance payment may be performed every week.

  At that time, by collating the shipping information with the receipt information and performing the advance payment only for the verified transaction, even if the seller's unauthorized operation etc. is compared, it will be difficult to fraud the advance payment, A certain level of certainty can be secured without strict handling of individual claims like bill discounts. In addition, since the shipment slip and receipt slip can be used as proof of the shipment information and receipt information, it is possible to confirm the contents of the transaction after the fact and to prevent the occurrence of troubles associated with the advance payment processing as much as possible. . Further, since it is not necessary to determine the evaluation value of the product, the advance payment process is simple and overpayment is unlikely to occur. As a result, the risks associated with the advance payment processing of the credit payment company are greatly reduced.

  In this way, instead of individually performing prepaid paperwork based on the date determined for each trade receivable, such as the discount request date in the case of bill discounts, it is autonomous every predetermined period (short cycle). The process is performed in advance, and a plurality of accounts receivables generated in the meantime are collectively processed in advance. Then, the prepaid process is repeated every short cycle to perform the process continuously or periodically. Thereby, even in a business condition in which a relatively small amount of receivables are generated almost every day, such as perishable goods transactions, it is possible to reduce the business processing burden on the payment side and the seller side associated with the advance payment.

  By the way, the timing of the shipment receipt verification may be performed collectively for five days as described above, or may be performed for unchecked receipt information received every day before the previous day. In this case, it is only necessary to set a verified flag in the verified receipt information and to search for the reception information with the verified flag in the advance payment process. Further, the shipment receipt verification may be performed as needed every time reception information is received.

  Next, FIG. 2 will be described. FIG. 2 is a diagram showing the flow in time series of postpay processing in the same manner as FIG. The post-payment process is an account receivable settlement process that is performed after confirming the buyer's debt payment. In many cases, the buyer pays on the 15th of the month following the end of the month, or the month-end payment. Here, an example of 15-day payment will be described.

  Post-payment processing is based on the fact that the entire amount of accounts receivable is not paid only by advance payment, and that in principle, no prepayment will be made if there is any discrepancy as a result of the verification process by the server. This is because it is preferable to pay for the amount paid. By doing so, although a plurality of transactions are combined and processed, the settlement of each transaction is completed by post-payment, so that the subsequent confirmation work is also simplified. Further, post-payment is repeatedly performed with a long period longer than the short period described above. This long period is preferably on a monthly basis corresponding to the majority of buyers' payment cycles. In other words, it is preferable to perform postpay processing every month on the day determined for each seller. A longer cycle is optional depending on the demand of the seller. Here, an example in which January is a long cycle will be described.

  The postpay process is performed as follows in this example. First, when the buyer terminal 4 reaches the beginning of the month (5/1 in FIG. 2), the receipt information for the previous month is totaled for each seller and the month-end closing process is performed. When the server 5 transmits to the buyer terminal 4 billing information for billing that summarizes a plurality of pieces of receipt information within a certain period for each seller, the received billing information is preferably aggregated. Next, on the payment date (5/15 in FIG. 2), the buyer 3 pays the price of the product purchased in the last month to the account of the credit payment company (A10), and the buyer terminal 4 receives the paid information A11. Send to server 5. The paid information A11 includes a payment date, a payment amount, a buyer, and one or more shipping slip numbers that are the payment targets. When the server 5 receives the paid information A11 from the buyer terminal 4, the server 5 stores it in a predetermined table.

  Thereafter, the server 5 starts post-payment processing for settlement in accordance with the post-payment schedule desired by the seller 1. FIG. 2 is an example in which postpayment processing is performed on May 18 after receiving the paid information A11. The server 5 searches the shipping information for a certain period of the seller 1 that has not been postpaid, confirms that the buyer has been paid, and subtracts the prepaid amount and the fee to make the postpaid amount Is calculated. Subsequently, when there are transactions of a plurality of sellers to be postpaid within the target period, the postpayment amount is totaled to reduce the fee and the total postpayment amount is calculated. Sends a post-payment instruction A12 to the seller 1. The post-payment command includes a command transmission date, a post-payment designation date (for example, 5/20), a post-payment target person, payment account information, a total post-payment amount, and the like. The contents of postpay are stored in a predetermined table.

  When the terminal 7 of the credit payment company 6 receives the postpay order A12, the credit payment company 6 pays the postpaid amount to the designated account of the seller 1 on the designated date in accordance with the postpayment order. This completes the checkout process for one or more transactions.

  In the above flow, there are a plurality of steps where information that is ineligible for payment from the printer 43 of the server 5 is printed out from the printer 43. The majority of transactions are judged by the server 5 to be automatically processed and processed automatically. On the other hand, information on the ineligible information is dealt with in an analog manner by humans on the server side, and the information agreed between the buyer and the seller. Just enter the correct information on the server.

  In this way, based on the collation of the shipment information and the receipt information, a plurality of accounts receivable are put together and repeatedly prepaid one after another in a short cycle. Repeat the postpayment process for the remaining amount of credits over a long period. By doing so, it becomes possible to deal with relatively small transactions such as fresh product transactions, and accurately perform advance payment processing without increasing the labor and cost of paperwork on the advance payment side or seller side. It becomes possible.

  At that time, the shipping information and receipt information, which are the basis for advance payment, are supported by the shipping slip and the received receipt slip, respectively. Correct content can be determined. In addition, for transactions involving a relatively small number of ineligible information, it is possible to deal with separately by taking advantage of automatic processing by the server, so that overpayment and fraud of prepaid money are less likely to occur, and it is difficult for receivable payment companies to Risk can be kept to a relatively small extent.

  FIG. 3 shows, for example, three months (April to June), payment A10 (thick arrow) from buyer 2 to receivable payment company 6, and advance payment A9 (thin arrow) from receivable payment company 6 to seller 1. ) And post-payment A13 (middle arrow) from the credit payment company 6 to the seller 1 is a diagram showing a temporal relationship. Prepayment A9 is made continuously one after another in a short period of about one week before the buyer's payment A10, and immediately after the payment A10 for the buyer's last month is made on the 15th of each month. Postpay A13 is made. As a result, it can be seen that the postpaid A13 is made in a long cycle according to the buyer's payment pattern. In FIG. 3, the postpaid A13 is shown to be performed at a different timing (different day) from the prepaid A9, but it goes without saying that it may be the same day. When overpayment is caused by postpay for returning goods, postpay is preferably performed on the same day as prepayment. This is because the overpayment can be offset immediately by paying in advance on the same day.

  Next, FIG. 4 is different from FIGS. 1 to 3 in that it eliminates the time axis and focuses on everything from ordering a single product transaction to completing payment, so that seller 1, buyer 3, server 5 and It is the figure which showed the outline of the movement of the information between goods and the payment company 6 and goods. The factoring system is configured such that a server 5 is communicably connected to a seller terminal 2, a buyer terminal 4, and a bond payment company terminal 7. As in FIGS. 1 and 2, the movement of information in the factoring system is indicated by solid arrows, and the movement of products and the like outside the system is indicated by broken arrows. Further, in FIG. 4, a single seller and a buyer are shown for simplicity, but there are actually a plurality of sellers and buyers.

  When the buyer terminal 4 transmits the order information A1 for the product to the server 5, the server 5 stores the order information in a predetermined table and transmits it to the seller terminal 2 as the order information A2. The seller 1 who has received the order information A2 prepares the ordered product and sends it to the buyer 3 together with the delivery slip (A3). Further, shipping information A5 indicating that the product has been shipped is transmitted from the seller terminal 2 to the server 5. When the server 5 receives the shipping information A5, the server 5 stores it in a predetermined table. When the merchandise arrives at the store or the like designated by the buyer, a receipt slip with an acceptance seal stamped by the buyer 3 is issued, and the receipt slip is appropriately returned to the seller 1 (A4). Also, receipt information A6 indicating that the merchandise has been received is transmitted from the buyer terminal 4 to the server 5. When the server 5 receives the receipt information A6, the server 5 stores it in a predetermined table.

  The server 5 collates the received shipping information and the received information in accordance with the prepaid schedule desired by the seller 1, calculates a prepaid amount when the two match, and sends the prepaid amount to the seller 1 A pre-payment instruction A8 is sent to pay the pre-paid amount. If they do not match, the advance payment command A8 is not transmitted. Receivable payment company 6 that received prepaid instruction A8 at terminal 7 pays the prepaid amount to the designated account of seller 1 (A9).

  Further, the server 5 transmits billing information A7 that the product price is paid to the buyer terminal 4 in accordance with the payment schedule of the buyer 3 based on the receipt information A6, and the billing information A7 is also stored in a predetermined table. Store. The buyer 3 receives the billing information A7 at the terminal 4, and the buyer 3 pays the commodity price to the claim payment company 6 according to the billing information A7 (A10). In addition, the paid information A11 from the buyer terminal 4 is transmitted to the server 5. When the server 5 receives the paid information A11, it stores it in a predetermined table. The server 5 checks the billing information A7 for the buyer 3 and the paid information A11 according to the payment schedule of the buyer 3, and if they match, the server 5 stores in the predetermined table that the buyer has been paid.

  After confirming that the payment of the buyer 3 has been completed according to the post-payment schedule desired by the seller 1, the server 5 calculates the post-payment amount by subtracting the advance payment amount from the price, and the post-payment amount to the seller 3 A post-payment command A12 is sent to the credit card payment company terminal 7. When the terminal 7 receives the postpayment instruction A12, the credit payment company 6 pays the postpaid amount to the seller 1's account. This completes the processing related to one commodity transaction.

  As described above, when various kinds of information such as shipping information and receipt information are sent to the seller 1, the buyer 3, and the debt payment company 6 through the factoring system, all information is centralized in the server 5. Can manage. In addition, since information such as a receipt slip can be input, it is possible to collate the shipment information with the receipt information, and the billing information with the paid information. For these reasons, troubles such as overpayment of receivables companies and fraud of advance payments are unlikely to occur. In other words, the risk of advance payment of the debt payment company is reduced.

  Next, FIG. 5 is a diagram showing a schematic configuration of the server 5 of the factoring system as viewed from the control side. The server 5 includes a storage unit 20 including a plurality of hard disks storing various data, tables, and computer programs, a CPU and a RAM, and uses computer programs and data read from the storage unit 20. A processing unit 10 that performs data processing, a communication interface 40 that connects the server 5 to a communication line, an input device 41 such as a keyboard and a mouse, a display 42 such as a liquid crystal display or a CRT, and a printer 43 that outputs information on paper. Are connected by a common bus, for example, via a necessary interface (not shown).

  The storage unit 20 of the server 5 includes various tables such as a seller information table 21 and a postpaid recording table 34 as shown in FIG. 5, computer programs for operating the server 5, programs for display display, Other necessary data is stored. Further, in the processing unit 10, an information receiving unit that causes the server 5 to receive an information input receiving function for receiving each information transmitted from the terminal and storing it in a predetermined table by reading a necessary program into the RAM. 11. Each of the processing units 13 to 16 illustrated in FIG. 5 for causing the server 5 to perform the respective functions, such as the schedule management unit 12 that causes the server 5 to perform the schedule management function related to various processes (the same applies to the following processing units). Is provided.

  First, tables in the storage unit 20 will be described. First, the seller information table 21 is a table for identifying a person (seller) in a position to sell a product for the factoring system, and an example of this is shown in FIG. Examples of sellers include farmers who produce fruits and vegetables, local agricultural cooperatives, and wholesalers. In the seller information table 21, in addition to the seller name, seller code, etc., whether the seller is a seller who can receive the advance payment process, and the advance payment conditions desired by the seller, for example, the advance payment, can be received. Includes start date and advance payment interval (how many days do you want to receive advance payment)? The prepaid interval here corresponds to the short cycle described above, and the date when the prepaid start date starts the short cycle first is specified. Further, it includes post-payment conditions desired by the seller, for example, data on the closing date and post-payment date for each month of post-payment processing when the long cycle is set to January, or data on the start date of the long cycle and the number of interval days of the long cycle.

  In this way, even if different prepaid or postpaid conditions are desired for each seller, those conditions can be registered in advance in the seller information table, etc., and flexible prepaid processing based on them can be performed. It can be carried out. Therefore, the seller can flexibly raise funds without being swayed by unilateral convenience on the advance payment side or buyer side.

  The seller account table 22 is a table prepared for each seller, and an example of this is shown in FIG. This table shows the type of transaction, the amount of receivables generated by each transaction, the amount paid to the seller, the sum of the seller's receivables at 24:00 on the transaction date, for each transaction date such as shipment, advance payment, and postpayment. The remaining amount of data is stored. The seller account table 22 stores data every time shipment or payment occurs, and the data on the balance of receivables increases by the amount of receivables when a new receivable is generated by product shipment, and the receivable disappears by payment. In this case, the payment amount, payment fee and consumption tax are reduced. By providing a seller account table like this, multiple relatively small commodity transactions occur every day, and payments are made in advance for transactions between them every certain number of days. Even if the transaction form is complicated, the balance corresponding to the product can be clarified for each seller. Is possible.

  The buyer information table 23 is a table for specifying a person (buyer) in a position to buy a product for the factoring system, and an example of this is shown in FIG. Examples of the buyer include a department store, a convenience store, a retail mass retailer such as a supermarket, a wholesaler for the producer, and the like. In the buyer information table 23, in addition to the data specifying the buyer such as the buyer name, the store name of the buyer delivering the product, the store table code specifying the table storing the store data of each buyer, the payment terms of the buyer, For example, data such as the payment closing date and the monthly payment date are stored.

  The product information table 24 stores data such as product name, code, place of production, packing unit, number of packages, quality, maturity, etc. for each product, stores the data of the packing unit necessary for product transaction as well as specifying the product. It is a table. The products handled are not particularly limited, but preferred products are perishable products whose quality changes on a daily or weekly basis, and in particular, fruits and vegetables such as vegetables and fruits, flowers, seedlings, Fresh fish, or raw meat treated with chilled chicken. This is due to the increased risk of receivables companies in the factoring process for these products. The most preferable handling products are fruits and vegetables with a high rate of quality change.

  The order record table 25 is a table in which the order information A1 received by the server 5 is stored as needed, and is provided for each buyer. An example of the order record table is shown in FIG. This table shows, for each order slip number, the order date, seller name, desired delivery date, desired store name, one or more product names and codes, the number of products, the product unit price, the price per product, the total price The information described in the order slip such as is stored.

  The shipping record table 26 is a table that stores shipping information A5 received by the server 5 as needed, and is provided for each seller. An example of the shipping record table is shown in FIG. This table contains information equivalent to information contained in the seller's shipping slip, shipping slip number, shipping date, order slip number, delivery date, buyer name, delivery store name, product name, quantity, unit price, total shipping amount, etc. Storing. Further, this table also stores the presence / absence of flags necessary for processing in the server 5. Specifically, it stores the presence / absence of a prepaid flag that means that prepaid payment has been completed for the receivables generated by the shipment, as well as the presence / absence of a postpaid flag that means that postpay has ended. . In this way, since the server 5 obtains and stores information equivalent to the information described in the shipping slip almost simultaneously with the shipping, when trouble such as overpayment or omission of billing occurs, By contrast, the contents of the transaction can be confirmed after the fact.

  The receipt record table 27 is a table in which the receipt information A6 received by the server 5 is stored as needed, and is provided for each buyer. An example of the receipt record table is shown in FIG. In addition to information equivalent to the reception information included in the receipt slip stamped by the buyer, this table also stores the presence or absence of a flag necessary for processing in the server 5. Specifically, it stores the presence / absence of a flag that indicates that a payment has been made for the debt generated by the receipt, as well as the presence or absence of a flag that indicates that the buyer has paid the price. . In this way, since the server 5 obtains and stores information equivalent to the receipt slip stamped by the buyer without much delay from the receipt of the actual product, when trouble such as overpayment or omission of billing occurs, The contents of the transaction can be confirmed afterwards by comparing with actual slips.

  The shipment receipt collation result table 28 is a table for storing the collation result between the shipment information A5 by the advance payment processing unit 13 of the server 5 and the corresponding receipt information A6. An example of this table is shown in FIG. This table stores a buyer name, a delivery store code verification result, a delivery date verification result, a total amount verification result, and a determination result of whether or not advance payment is possible for each shipment slip number. Each verification result stores whether or not the results of the verification processing of the shipping information and the receipt information in the server 5 match each other, and whether or not advance payment is possible depends on whether or not all the verification results match. Stores the determination result. Even if a large number of commodity transactions are conducted in this way, the result of collation between shipment and receipt is stored one by one for each of them. Even when it is done, advance payment processing can be performed with the same degree of certainty as discount processing for each bank bill.

  The advance payment rate information table 29 is a table that defines advance payment rates for sellers whose data in the advance payment availability column of the seller information table is “OK”. The prepaid rate means the proportion of the amount of receivables generated by the shipment of goods excluding the prepaid fee and consumption tax, which is actually prepaid to the seller. If the advance payment rate is too low, the advance payment amount to the seller decreases and it becomes difficult to obtain the satisfaction of the seller. If the advance payment rate is too high, the risk of overpayment increases for the debt payment company. The advance payment rate may be determined in advance based on the seller's previous year's transaction results, return results, seller's creditworthiness, and the like. By setting a prepaid rate in advance, reduce the risk of overpayment in advance payments by creditor companies when the amount of receivables decreases due to product returns or disposal due to corruption or quality differences after shipment. Can do. In addition, if there are special circumstances that cause risk factors such as that some of the seller's products are very expensive or the number of products handled is extremely small, it is also possible to set a prepaid rate for each product handled. good.

  The prepaid record table 30 is a table that stores the contents each time the prepaid processing unit 13 of the server 5 transmits a prepaid instruction A8 to the buyer. An example of the advance payment record table 30 is shown in FIG. This table stores data such as the name of the seller to be prepaid, one or more shipping slip numbers that are the cause of prepayment, prepaid fees, consumption tax, prepaid date specifying the scheduled prepaid date, total prepaid amount, etc. is doing.

  The billing record table 31 is a table that stores the contents each time the billing processing unit 14 of the server 5 transmits billing information A7 that is a billing request to the buyer. An example of this table is shown in FIG. This table stores data such as buyer name, billing date, total billing amount, and one or more shipping slip numbers to be processed.

  The buyer payment record table 32 is a table that stores the contents each time the server 5 receives the paid information A11. An example of this table is shown in FIG. This table stores data such as a billing number, a buyer name, a payment date, a total payment amount, and one or two or more shipping slip numbers to be paid.

  The billing receipt verification result table 33 is a table in which the deposit matching processing unit 15 of the server 5 stores the result of matching the billing information A7 and the paid information A11 corresponding thereto for each billing. An example of this table is shown in FIG. This table shows the invoice number, buyer's name, the difference obtained by subtracting the invoice amount from the amount to be paid, and the result of matching to determine whether the invoiced amount and the amount to be paid match based on whether this difference is zero. Is stored.

  The postpayment record table 34 is a table that stores the contents every time the postpayment processing unit 16 of the server 5 transmits a postpayment instruction A12 to the buyer. An example of the postpayment record table 34 is shown in FIG. This table stores data such as the name of the seller to be postpaid, one or more shipping slip numbers that are the cause of postpay, the postpay date specifying the scheduled postpay date, the total amount postpaid, and the like.

  Next, the processing unit 10 of the server 5 will be described with reference to a flowchart as appropriate. First, the information input receiving unit 11 will be described. The information input reception unit 11 mainly implements a function of storing each information received by the server 5 from the terminals 2, 4, and 7 in a predetermined table corresponding to each information. When the server 5 receives the order information A1 from the buyer terminal 2, the information input receiving unit 11 stores the order information A2 in the order of reception in the order record table 25 as needed, and transmits the order information A2 having the same contents to the seller terminal 2. Further, when the server 5 receives the shipping information A5 from the seller terminal 2, the server 5 stores it in the shipping record table 26 for the seller in the order of reception as needed. In addition, when the receipt information A6 is received from the buyer terminal 4, it is stored in the receipt record table 27 for the buyer in the order of reception as needed. Further, when the paid information A11 is received from the buyer terminal 4, it is stored in the buyer payment record table 32 for the buyer in the order of reception as needed. In this way, the information input receiving unit 11 temporarily stores each piece of information received by the server 5 in a predetermined table, so that each process described later can be performed according to a schedule desired by the buyer or seller. .

  The schedule management unit 12 realizes a function for managing the date and time at which each process in the server 5 is started based on the wishes of the seller or the buyer regarding each process of prepaid, billing, deposit verification, and postpay. An outline of the relationship between the schedule management unit 12 and the tables and other processing units is shown in a block diagram in FIG.

  First, the schedule management unit 12 stores the prepaid interval data stored in the seller information table 21 and the seller account table 22 when the prepaid availability column of the seller information table 21 is “Yes” for a seller. The next advance payment date is calculated from the latest advance payment execution date. When the next prepaid date is reached, the prepaid processing unit 13 is instructed to start prepaid processing for the seller. This process is performed for all sellers who can pay in advance. By doing in this way, it becomes possible to perform a prepaid process appropriately according to a schedule desired by the seller and a plurality of transactions together. In other words, it is possible to make a payment in advance for a plurality of transactions by using a different schedule for each seller.

  Further, the schedule management unit 12 instructs the billing processing unit 14 to start billing processing for the buyer before a certain number of days before the payment closing date stored in the buyer information table 23 for a certain buyer. This process is performed for all buyers as needed. In addition, the schedule management unit 12 makes a payment verification for a certain buyer after the payment date stored in the buyer information table 23 has passed, with respect to the payment verification processing unit 15 to check the paid information from the buyer with the billing information. Command to process. This process is performed for all buyers as needed. The predetermined number of days is preferably as short as possible as long as the buyer's paperwork is possible.

  Further, the schedule management unit 12 uses post-payment date data for each seller, which is a desired post-payment date of the seller, stored in the seller information table 21 for a certain seller. The processing unit 16 is instructed to start a postpay process for the seller. This process is performed for all sellers as needed. By doing in this way, it becomes possible to perform postpay processing in accordance with a schedule desired by the seller, and it is possible to appropriately perform postpay processing for a plurality of transactions collectively. It should be noted that the certain number of days here is preferably as short as possible within the scope of the paperwork of the credit payment company.

  FIG. 19 shows a flowchart of schematic processing in the schedule management unit 12. FIG. 19 (1) is a flowchart of processing performed for a buyer, and (2) is a flowchart of processing performed for a seller. The processes of these flowcharts are executed every day. First, the process for the buyer is executed according to the flowchart of (1), and after the corresponding billing process and the matching process are completed, the process for the seller is executed according to the flowchart of (2). Execute. This is because the payment of accounts receivable is settled at the earliest possible timing by executing post-payment processing after confirming the buyer's payment.

  FIG. 19 (1) specifies the first buyer in the buyer information table (g = 1), and whether or not the processing date specified by the internal clock of the server corresponds to the billing processing date or the verification processing date for the buyer. (S2 and S4), and if applicable, each processing unit is instructed to start a billing process or a collation process specifying the buyer (g) (S3 and S5). This process is completed for all buyers (s).

  FIG. 19 (2) specifies the first seller in the seller information table (h = 1), and whether or not the processing day specified by the internal clock of the server corresponds to the prepaid processing date or the postpaid processing date related to the seller. (S12, S14), and if applicable, commands each processing unit to start the prepaid process or the postpaid process specifying the seller (h) (S13, S15). This process is performed for all sellers (t persons) and the process ends.

  As described above, the schedule management unit 12 commands the start of each process such as the advance payment process autonomously from the internal clock of the server and the table data irrespective of the advance payment request date of each trade receivable. Thereby, the processing of each processing unit is collectively performed for a plurality of accounts receivable and the like generated during each predetermined period. Therefore, processing such as advance payment can be performed continuously or periodically for a large number of accounts receivable without increasing the labor and cost of the paperwork of the payment company or the seller.

  The advance payment processing unit 13 realizes a function of performing advance payment processing of a part of the product price to the seller within a relatively short period from the shipment of the product before the buyer pays the price. An outline of the relationship between the advance payment processing unit 13 and tables and other processing units is shown in the block diagram of FIG. A schematic flow of processing performed by the advance payment processing unit 13 is shown in the flowchart of FIG. Processing performed in the advance payment processing unit 13 will be described with reference to FIGS.

  When a pre-payment processing command is sent from the schedule management unit 12 specifying a certain buyer, the pre-payment processing unit 13 starts processing. First, the shipping record table 26 is searched within a range that is a fixed number of days backed by a short period of prepaid from the processing date, and the prepaid flag is not attached, and the corresponding shipping slip number is specified. Here, it is assumed that there are n shipping slip numbers hit in the search. The shipment record specified by the n shipment slip numbers is read into temporary storage (step S20). The first one of n is selected (i = 1), and it is determined whether i has reached n + 1 (whether or not all n have been processed) (step S21).

  If i has not reached n + 1, the flow branches to the right from step S21, and the receipt slip number corresponding to this shipment slip number is specified by searching the receipt record table 27 (step S21). When the corresponding receipt slip number is specified, the flow branches down from step S21, and the receipt record specified by the receipt slip number is read into the temporary storage. Subsequently, the receipt record and the shipment slip number are read. The identified shipment record is collated (step S22). The collation is performed by using the delivery date, the delivery store name, the slip number, and the total amount as the collation keys. In this case, it is because it is considered that the transaction is correctly established. Subsequently, the flow branches downward from step S22, the collation result is stored in the shipment receipt collation result table 28 (step S23), the process moves to the next shipment slip number (i = i + 1), and the step proceeds to step S21. Return.

  On the other hand, if the receipt slip number corresponding to the target shipping slip number is not specified in step S21, there is a possibility that the transaction has not been completed. Data indicating that the corresponding receipt slip number is not specified in the shipping slip number is accumulated in the list A file (step S30), and the processing shifts to the next shipping slip number (i = i + 1).

  If any of the above-mentioned verification keys do not match in step S22, it is necessary to confirm the transaction contents. Therefore, it is determined that the transaction does not match, and the flow branches to the right. The data is stored in the table 28 (step S40), and the data indicating that the shipment record of the target shipment slip number does not match the corresponding receipt record is accumulated in the list B file (step S41), and the next shipment slip number is stored. The process moves to (i = i + 1), and the process returns to step S21.

  In this manner, the steps from S21 to S41 are repeated, and when collation is completed for all n shipping slip numbers, i = n + 1 is obtained in step S21, and the total advance payment amount is calculated by branching downward from here. (S50 step). The calculation of the total advance payment amount is considered to be a record of transactions in which one or two or more shipment records whose shipment receipt verification is “matched” are correctly established. The actual amount of receivables with tax reduced is required. Subsequently, the advance payment rate data of the buyer to be paid in advance is read out from the advance payment rate information table 29, and the amount of advance payment is determined by multiplying the actual claim amount obtained previously by the advance payment rate.

  Subsequently, an instruction to pay the prepaid amount determined above to the buyer is transmitted to the bond payment company terminal 7 via the communication interface 40 (step S51), and the content of this prepaid instruction is prepaid information. Stored in the table 30 and the seller account table 22, a prepaid flag is set in the corresponding column of the shipping record table 26 (step S52). Finally, the previously stored lists A and B are output from the printer 43 (step S53), and the processing in the prepaid processing unit 13 ends.

  Lists A and B are a case where there is no receipt record corresponding to the shipment record and a case where there is a receipt record corresponding to the shipment record, but the collation keys are not completely coincident. Although these are exceptional cases, they may be a risk factor for the creditor company because the transaction is not completed or the details are not finalized. Regarding the transactions listed in Tables A and B, humans will respond analogly according to the list, confirm the amount of receivables by comparing slips and data, negotiating with sellers and buyers, and using the table data It may be corrected and corrected.

  In this way, since one or more receivables generated during a certain period are collectively paid in advance, a large number of relatively small transactions such as perishable products are performed every day. Even in this case, the paperwork is not complicated and can be applied. In addition, since the factoring system server obtains and stores data corresponding to the slips that are actually issued from time to time, the product will disappear before the buyer pays for a short product life. Even with fresh perishables transactions, it is possible to verify what the correct transaction data was after a problem occurred. Even in transactions involving producers and mass merchandisers with various creditworthiness, the risk of overpayment and fraud of prepaid money is reduced, and the credit payment company can safely perform advance payment processing without incurring significant risks. It becomes possible.

  The billing processing unit 14 realizes a function of transmitting a payment request to the buyer terminal 4 based on the receipt record transmitted from the buyer terminal 4 and stored in the receipt record table 27. The outline of the relationship between the billing processing unit 14 and the tables and other processing units is shown in the block diagram of FIG. When the billing processing unit 14 receives an instruction to start the billing process specifying the buyer from the schedule management unit 12, the billing processing unit 14 first uses the buyer information table 23 to identify the period to be billed this time for the buyer, The receipt record table 27 is searched to identify receipt records having no billed flag within the billing target period. This is because these transactions have not yet been charged to the buyer. Subsequently, billing information A7 is formed using the retrieved receipt record and transmitted to the buyer terminal 4 via the communication line. The last transmitted billing information A7 is stored in the billing record table 31, the billed flag is set in the corresponding column of the receipt record table 27, and the process is terminated. This is done from time to time for all buyers.

  The deposit verification processing unit 15 realizes a function of verifying whether or not both the billing record to the buyer and the corresponding buyer payment record are matched. An outline of the relationship between the deposit verification processing unit 15 and the tables and other processing units is shown in the block diagram of FIG. Moreover, the schematic flow of the process performed by the deposit verification processing unit 15 is shown in the flowchart of FIG. The processing performed in the deposit verification processing unit 15 will be described with reference to FIGS.

  When receiving an instruction from the schedule management unit 12 to specify the buyer and perform the charge / payment verification process, the payment verification process unit 15 records the charge record for the buyer whose charge date is within a certain range from the charge record table 31. The retrieved billing records (assumed to be m) are read into the temporary storage (step S60). Next, the first one is selected from the m billing records (j = 1), and then it is determined whether j has reached m + 1 (whether or not all m have been processed). (Step S61).

  If j has not reached m + 1, the flow branches to the right from step S61, and the buyer payment record corresponding to the jth billing record is searched from the buyer payment record table 32 (step S62). If the corresponding buyer payment record is specified, the flow branches down from step S62, and the billing record and the corresponding buyer payment record are collated (step S63). The verification key includes a billing date, a billing number, a buyer code, a total payment amount and a total billing amount. If all of these match, it is determined that the billing record and the buyer payment record “match”. If any of these do not match, it is determined as “mismatch”. If they match, the flow branches downward from step S63, stores the verification result in the billing receipt verification result table 33, and sets a paid flag in the corresponding column of the receipt record table 27. Subsequently, the next billing record is selected (j = j + 1), and the process returns to step S61.

  On the other hand, if the buyer payment record corresponding to the j-th billing record is not specified in step S62, the flow branches to the right and lists the billing record and information indicating that the corresponding buyer payment record is not specified. It accumulates in the table C file (step S73), and moves to the next billing record (j = j + 1).

  If it is determined in step S63 that the data does not match, the flow branches to the right, and the verification result indicating that the data does not match is stored in the charge / payment verification result table 33. The payment record is stored in the list D file together with the inconsistency. Subsequently, the next billing record is selected (j = j + 1), and the process returns to step S61.

  If j has reached m + 1 in step S61, since all of the m billing records have been verified, the flow branches down from step S61, and lists C and D are printed. The paper is output from 43 (step S90), and the collation process is terminated. The deposit verification processing unit 15 performs the above processing on all buyers as needed.

  It should be noted that the lists C and D are exceptional cases as with the lists A and B, and, like the processes of the lists A and B, humans can deal with them in an analog manner while viewing the lists. Thus, it is possible to check slips and input data of buyers and sellers, input corrections of data, and the like.

  The post-payment processing unit 16 performs a settlement process for receivables generated for each transaction, and realizes a function of post-paying the remaining amount of receivables that is insufficient only by advance payment to the buyer. An outline of the relationship between the post-payment processing unit 16 and the tables and other processing units is shown in the block diagram of FIG. A schematic flow of processing executed by the postpaid processing unit 16 is shown in the flowchart of FIG. Processing performed in the postpay processing unit 16 will be described with reference to FIGS.

  First, the post-payment processing unit 16 starts the post-payment processing upon receiving an instruction from the schedule management unit 12 to identify the seller and perform post-payment processing. The post-payment processing unit 16 searches the seller's shipping record table within the post-payment target period of the command and there is no post-paid flag, identifies the corresponding shipping record (assuming it is p), and temporarily stores it. (Step S100). This is because such a shipment record becomes a target of postpayment regardless of whether or not advance payment is made. One of the p pieces is selected (k = 1), and it is determined whether or not k has reached p + 1 (whether or not all the p pieces have been processed) (step S110).

  If k has not reached p + 1, the flow branches to the right from step S110, and a buyer payment record corresponding to this shipment record is specified by searching the buyer payment record table 32 (step S111). If the corresponding buyer payment record is identified, it is determined that the transaction has been established, and the flow branches downward from step S111 and reads the identified buyer payment record to the temporary storage. Subsequently, the billing receipt verification result table 33 is searched for this shipment record, and it is determined whether or not the matching result column of the corresponding shipment record is “match” (step S112). If it is “match”, the buyer has paid correctly, so the flow branches down to the next shipping record processing (k = k + 1), and returns to step S110.

  On the other hand, in step S111, if the corresponding buyer payment record is not specified, there is a possibility that the transaction has not been established. Therefore, the flow branches to the right and the buyer payment record is not specified and the target shipment record Are stored in the list E file (step S120). Subsequently, the process proceeds to the next shipment recording process (k = k + 1), and the process returns to step S110.

  In step S112, if it is “mismatched”, the transaction details need to be confirmed, so that the shipping record and the buyer payment record are accumulated in the list E file. Subsequently, the process similarly proceeds to the next shipment recording process (k = k + 1), and the process returns to step S110.

  In this way, steps S111 to S120 are repeated, and when processing is completed for all of the p shipment records, k = p + 1 is obtained in step S110, and the flow branches downward from step S110. In this way, among the shipment records, the shipment record in which the corresponding buyer payment record exists is specified, and the shipment record in which the matching result column of the billing receipt matching result table 33 is “match” is postpaid set to target. Others are excluded from postpayment.

  Subsequently, the shipping list that is not subject to postpay is output from the printer as a list E (step S130), and the state shifts to a correction input enabled state. This is because the contents of the transactions listed in Table E are confirmed by humans before postpayment, and it is possible to make corrections, so that the number of shipping records subject to postpayment to sellers can be increased as much as possible. This is to complete the payment process. Necessary correction input is made or continuation input is made without correction input (step S131), and the process proceeds to the next step S132.

  In steps S132 to 133, the postpaid amount is calculated. First, in the shipment record to be postpaid, the prepaid amount and the prepaid fee of the prepaid items that were prepaid are searched from the prepaid record table 30, and the total prepaid amount is calculated by adding these searched prepaid amounts. Similarly, the prepaid fees are summed to calculate the total prepaid fee (step S132). Next, calculate the total shipping amount by summing the shipping amounts in the shipping records that are subject to postpay, and subtract the above total prepaid amount and total prepaid fee from the total shipping amount and postpayment fee including consumption tax. The obtained amount is set as the current postpaid amount (step S133). By doing in this way, even when a plurality of advance payments are included in a plurality of shipment records, the postpaid amount can be determined without any problem.

  Next, the postpayment processing unit 16 transmits an instruction to the seller to pay the confirmed postpaid amount to the seller (step S134), and the content of the transmitted postpayment instruction is stored in the postpayment record table. 34, the contents of postpayment are stored in the seller account table 22, a postpaid flag is set in the corresponding column of the shipping record table 26 (step S135), and the postpayment process ends.

  Since post-payment processing is performed as needed in this way, even in the case of a complicated transaction form in which a plurality of advance payments are made for a plurality of transactions, payment is completed without omission for each shipment record. Moreover, since it is possible to deal separately with transactions whose transaction details are not necessarily clear, the possibility of overpayment is low even with postpayment.

  The functions of the storage unit and the processing unit of the server 5 which are the center of the method and factoring system of the present invention have been described above. It can also be regarded as a program. The program may be stored in a computer-readable recording medium. Here, the recording medium refers to a recording medium such as a flexible disk, a magneto-optical disk, a portable medium such as a ROM and a CD-ROM, and a hard disk incorporated in a computer system. Further, the program may be arbitrarily divided and the divided programs may be stored in the storage medium.

  In addition, each terminal 2, 4, 7 used to be connectable to the server 5 is necessary for the screen display by the screen information transmitted from the server 5 and the display screen corresponding to the processing performed by the server 5. For example, it can be configured according to a conventional method using a normal personal computer or workstation, and is not particularly limited. The communication line may be a dedicated line such as a LAN or WAN, or the Internet may be used. Further, the communication may be always connected, or may be connected as needed only when necessary.

  As mentioned above, although embodiment of this invention has been explained in full detail with reference to drawings, this invention is not limited to said specific structure, The deformation | transformation in the range which does not deviate from the thought of this invention is also contained in this invention. . For example, various modifications can be made in the way of holding data in each table, the order of processing in each processing unit, and the like. For example, data related to the short cycle and long cycle that specify the payment schedule to the seller is not stored together with other information in the seller information table, but a table storing only data related to the short cycle, or data related to the long cycle You may prepare and use a table that collects only

  In the above description, the example is described in which the schedule management unit that controls each processing unit according to the internal clock is used. However, each processing unit may have a schedule management unit individually. In the above description, an example in which the short cycle is fixed to one type of interval of 5 days has been described. However, it is only necessary that the advance payment is repeated in a substantially short cycle, and the interval need not be one type. . For example, the day of advance payment in one month is defined as 1 day, 10 days, 15 days, 25 days, and so on. You may make advance payments. In this case, the interval from the 25th to the 1st varies depending on the month, but may be performed in this way. In short, the advance payment schedule desired by the seller may be determined so that a plurality of advance payments can be made during one normal payment of the buyer.

  The same applies to post-payment. The long cycle is set to one month as described above, and post-payment may be made on a fixed date every month or once every two months. Further, an interval of one month and one and a half months may be used alternately. In short, the long period should be determined in principle according to the payment pattern of the main buyer, and the short period should be determined to be the short period desired by the seller.

  Further, in the above, when a plurality of products are included in the collation for advance payment, the total amount is collated, but the amount for each product may be collated.

  Inappropriate shipment records and the like are output from the printer on paper, but data to that effect may be transmitted to the terminals concerned and processed on the server side after waiting for a response from each terminal. . The order information may or may not go through the server 5. However, it is preferable to use the server 5 because all the related information can be centrally managed by the server 5. Further, the billing information is generated based only on the receipt information, but the shipment information may be referred to. The paid information A11 is transmitted from the buyer terminal to the server 5, but may be received from the receivable payment company terminal that has received the payment.

  Moreover, although it demonstrated by the example applied to the transaction of the fresh goods of the fresh goods above, it is sufficient if it is a business form in which a large number of small transactions are performed every day, and it is not necessarily limited to fresh goods. For example, when you want to deliver processed foods such as bento and rice balls to a convenience store little by little every day, or when you need to deliver a small number of necessary mechanical parts to a production line operated by the Kanban method almost every day. It can also be used.

It is a figure explaining merchandise transaction and advance payment processing based on it according to time series It is a figure explaining a postpay process along a time series. It is the schematic diagram which showed the pattern in which buyer payment, advance payment, and postpay are made in the period of about three months. It is a block diagram which takes out one goods transaction and its payment process, and explains the whole. It is the block diagram which showed the schematic structure which looked at the server from the control surface. It is the conceptual diagram which showed the example of the seller information table. It is the conceptual diagram which showed the example of the seller account table. It is the conceptual diagram which showed the example of the buyer information table. It is the conceptual diagram which showed the example of the order recording table. It is the conceptual diagram which showed the example of the shipping record table. It is the conceptual diagram which showed the example of the receipt record table. It is the conceptual diagram which showed the example of the shipment receipt collation result table. It is the conceptual diagram which showed the example of the advance payment recording table. It is the conceptual diagram which showed the example of the claim recording table. It is the conceptual diagram which showed the example of the buyer payment record table. It is the conceptual diagram which showed the example of the claim payment collation result table. It is the conceptual diagram which showed the example of the postpayment recording table. It is the block diagram which showed the relationship with the tables of a schedule management part, another process part, etc. It is the flowchart which showed the outline of the flow of the process in a schedule management part. It is the block diagram which showed the relationship with the tables of the advance payment process part, another process part, etc. FIG. It is the flowchart which showed the general | schematic flow of the process in a prepaid process part. It is the block diagram which showed the relationship between the tables of a claim process part, another process part, etc. It is the block diagram which showed the relationship with the tables of a claim | payment receipt verification process part, another process part, etc. FIG. It is the flowchart which showed the general | schematic flow of the process in a claim payment collation process part. It is the block diagram which showed the relationship with the tables of a postpayment process part, another process part, etc. It is the flowchart which showed the schematic flow of the process in a postpayment process part.

Claims (9)

  A server is a method for performing prepaid processing for a seller of a product based on a plurality of trade receivables of the product, wherein the schedule management means periodically starts prepaid processing according to a predetermined short cycle schedule A plurality of accounts receivable information stored in one or more accounts receivable generated in one of the short cycles in accordance with the advance payment instruction. A step of searching and specifying an account receivable table, a step of calculating the advance payment amount relating to the specified account receivable by the advance payment processing means, and an advance payment processing means calculating the advance payment amount of the total Outputting a prepaid instruction that includes the method.   Further, the schedule management means includes a step of instructing the postpayment processing means to start the postpayment processing periodically according to a predetermined long-cycle schedule, and the postpayment processing means follows the postpayment instruction in accordance with the postpayment instruction. A step of searching the accounts receivable table to identify one or more accounts receivable generated in one, and the post-payment processing means from the identified accounts receivable to the advance payment amount related to the accounts receivable The method according to claim 1, further comprising: calculating a sum of postpaid amounts by subtracting and a step of outputting a postpayment instruction in which the postpayment processing means includes the total postpayment amount. Further, the schedule management means instructs the payment verification processing means to start the buyer payment confirmation process periodically according to a debt payment schedule predetermined by the buyer of the product, and the schedule management means is predetermined. Instructing the post-payment processing means to start post-payment processing periodically according to a long-cycle schedule;
The receipt verification processing means searches for a buyer payment information corresponding to the trade receivable information within a predetermined period in a buyer payment table storing a plurality of buyer payment information in accordance with a start instruction of the confirmation process. A step of identifying, and a step of collating the receipt receivable information and the identified buyer payment information by the deposit verification processing means,
The post-payment processing means searches the receivables table for one or more accounts receivable generated in one of the long periods in accordance with the post-payment process start instruction; and the post-payment processing means is the search A step of identifying one or more of the receivables determined to match the result of the reconciliation, and the postpay processing means calculates a prepaid amount relating to the identified receivable 2. The method according to claim 1, further comprising the step of calculating a total postpaid amount by subtracting, and the postpayment processing means outputting a postpayment instruction including the calculated total amount.   4. The method according to claim 2, wherein the short period is in days or weeks, and the long period is in months.   Further, the information receiving means receives the plurality of shipping information of the products from the seller terminal as needed and stores them in a shipping information table; and the information receiving means receives the plurality of products from the buyer terminal of the products. A step of receiving information and storing it in a receipt information table; and the advance payment processing means reads and collates the shipment information and the receipt information corresponding to the shipment information, and the shipment information and the corresponding receipt information are 5. The method according to claim 1, further comprising a step of storing the shipping information or the corresponding receipt information in the accounts receivable table when they match.   The method according to claim 1, wherein the product is a fresh product whose product value fluctuates in a short time.   The method according to claim 1, wherein the fresh product is a fruit or vegetable.   A server for performing prepaid processing for a seller of a product based on a plurality of trade receivables of the product, and a schedule for instructing the prepaid processing means to start prepaid processing periodically according to a predetermined short-cycle schedule Management means and advance payment processing means for executing advance payment processing in accordance with the advance payment instruction, wherein the advance payment processing means converts one or more accounts receivables generated in one of the short cycles into a plurality of accounts receivables. Means for searching and specifying an accounts receivable table in which information is stored; means for calculating a sum of advance payment amounts relating to the specified accounts receivable; and means for outputting a prepaid instruction including the total advance payment amount A server characterized by comprising: 9. A factoring system, wherein a merchandise seller terminal, a merchandise buyer terminal, and a merchandise claim payment company terminal are communicably connected to the server according to claim 8.

Images