RU2816505C2 - System and method of managing purchases - Google Patents

Abstract

FIELD: computer engineering.

SUBSTANCE: invention relates to computer engineering. Technical result is achieved by transmitting a purchase approval request from a transaction authorization module to a database module associated with the bank, wherein the purchase approval request contains transaction information; making a decision on the purchase approval request by approving or rejecting the purchase approval request depending on whether the requested purchase satisfies the purchase rules associated with the first transaction identifier in the associated with the bank database module; responding to the transaction authorization module by approving or rejecting the purchase approval request; response from the transaction authorization module to the first transaction authorization request associated with the first transaction identifier; adding transaction information obtained from the transaction authorization module as metadata associated with the first transaction identifier in the database module associated with the bank; transmitting transaction information associated with the first transaction identifier to the central database and transmitting the transaction information associated with the first transaction identifier to a purchasing organization.

EFFECT: faster response to a purchase approval request.

18 cl, 7 dwg

Description

Field of technology to which the invention relates

The present invention relates generally to purchasing management systems and methods.

State of the art

Patent US7319986 describes a dynamic payment card management system in which card management parameters can be dynamically changed by applying customizable policies and company purchase rules, allowing purchase approval parameters to be dynamically controlled.

The system described in patent US7319986 is based on the use of purchase requests. No purchase can be made without a corresponding purchase request, however, in some situations, a purchase request may be generated by the system itself. Using purchase requests simplifies the company's approval process.

Disadvantages of the Prior Art

In the system described in US7319986, the buyer can be notified that a transaction has been completed, but since the system is based on the use of purchase requests, there is no way to transmit purchase data to the company's business management system at the time of purchase. Thus, the company does not receive purchase data until it receives an invoice from the supplier.

In addition, the system described in US7319986 is an entire card processing system designed to replace existing payment infrastructure.

Thus, there is a need for an improved purchasing management system.

Disclosure of the Invention

A purchase management system based on purchase requests simplifies the internal approval process, but because the purchase request is processed internally, external parties cannot add information to it, such as details of the purchase made.

According to the present invention, a database is used to store purchase information and is accessible to any party in the system. This database preferably has functionality to "translate" the data format used by different parties in the system into a single data format, making it easier for those parties to add information relevant to the purchase.

The present description relates to systems for managing purchases and to methods of managing purchases by which buying organizations can purchase goods and services from suppliers or sellers. Prior art systems do not allow such purchases to automatically enter transaction information into the purchasing entity's business management and other management systems. The present invention provides this capability by collecting information from various parties in the system in a manner not available in prior art systems.

The inventive purchase management system may comprise a central database, a customer interface to the central database, and a bank-related database module capable of communicating with a transaction authorization module at the bank. The central database can receive from the buying organization, through the client interface, purchasing rules that apply to a group of buyers. The central database may include a central processing facility to: add the selected group of customers as metadata associated with the first transaction identifier to the central database; add the purchasing rules applicable to this group of buyers as metadata associated with the first transaction ID in the central database; and transmit metadata associated with the first transaction identifier to the bank-associated database module. The bank-associated database module may receive a purchase approval request from the transaction authorization module, wherein the purchase approval request contains transaction information, including at least a purchase amount associated with the first transaction identifier. The bank associated database module may include a banking processing facility capable of: deciding on a purchase approval request by approving or rejecting it depending on whether the requested purchase satisfies the purchase rules associated with the first transaction ID in the bank associated database module data; respond to the transaction authorization module by approving or rejecting the purchase approval request; adding the transaction information received from the transaction authorization module as metadata associated with the first transaction identifier to the bank-related database module; and transmit transaction information associated with the first transaction identifier to the central database. The central processing facility in the central database may transmit transaction information associated with the first transaction identifier to the purchasing entity so that the purchase information can be automatically entered into at least one management system of the purchasing entity. This facilitates the collection of transaction information related to purchases and the conversion of that transaction information into a data format used by the purchasing entity so that the transaction information can be automatically entered into the purchasing entity's business management and other management systems.

An inventive method for managing purchases may include: entering, through a client interface to a central database, purchasing rules applicable to a group of buyers; adding the selected buyer group as metadata associated with the first transaction ID to the central database; adding the purchasing rules applicable to this group of buyers as metadata associated with the first transaction ID in the central database; transmitting metadata associated with the first transaction identifier from the central database to the bank-associated database module; receiving, at the transaction authorization module located in the bank, a first transaction authorization request associated with the first transaction identifier and containing information for authorizing the transaction; transmitting the purchase approval request from the transaction authorization module to the bank associated database module, wherein the purchase approval request contains transaction information including at least a purchase amount; deciding on a purchase approval request by approving or rejecting it depending on whether the requested purchase satisfies the purchase rules associated with the first transaction ID in the bank-related database module; response to the transaction authorization module with approval or rejection of the purchase approval request; a response from the transaction authorization module to the first transaction authorization request associated with the first transaction identifier; adding the transaction information received from the transaction authorization module as metadata associated with the first transaction identifier to the bank-related database module; transmitting transaction information associated with the first transaction identifier to a central database; and transmitting transaction information associated with the first transaction identifier to the purchasing entity so that the purchase information can be automatically entered into the at least one management system of the purchasing entity. This simplifies the collection of transaction information for purchases and the conversion of transaction information into a data format used by the purchasing entity so that the transaction information can be automatically entered into the purchasing entity's business management system and other management systems.

In some embodiments of the invention, a bank-related database module is located within the bank. The definition of "within a bank" means that modules within a bank are located on the bank's systems behind the bank's firewall, so that information transmitted between modules is not sent outside the bank's firewall. This provides fast response times to purchase approval requests and also allows transaction type information that is not legally allowed to be sent outside the bank's firewall to be added as metadata associated with the first transaction ID in the bank's associated database module. There are strict regulatory requirements for transaction information that is permitted to be received from outside and/or sent outside the bank, but by placing a bank-related database module within that bank, transaction information that is not permitted to be received from outside and/or sent outside the bank , can be entered into the database module associated with the bank.

In some embodiments of the invention, the buyer group includes at least one individual buyer. This makes it possible to define purchasing rules and tailor them for one or more purchasing individuals or for divisions of a purchasing organization consisting of one or more purchasing individuals.

In some embodiments of the invention, the buyer group includes the entire purchasing organization. This allows the purchasing organization to define common purchasing rules for the entire organization.

In some embodiments of the invention, the purchasing rules are general purchasing rules for divisions of the purchasing organization, and adding the purchasing rules that apply to a group of buyers as metadata associated with the first transaction identifier to the central database includes identifying which division this group of buyers belongs.

In some embodiments, the transaction information includes merchant information, such as a merchant name or merchant identification code, and the decision to approve or reject a purchase approval request is further dependent on the merchant information. This allows the purchasing organization to block purchases from selected suppliers/vendors and/or allow purchases only from selected suppliers/vendors.

In some embodiments, purchase rules specify that certain metadata associated with a transaction ID must be added to a central database prior to making a purchase, wherein deciding on a purchase approval request includes rejecting the purchase approval request if related The bank database module does not have such metadata associated with the transaction ID.

In some embodiments of the invention, information is transferred from a central database to the payment card issuer directly or through a payment card management module within the bank so that the payment card issuer can issue payment cards to the purchasing organization.

In some embodiments of the invention, the central database and the bank-associated database module are synchronized to be mirror versions of each other. However, such mirroring does not necessarily apply to all information in the database, and some metadata fields may be excluded from mirroring.

In some embodiments of the invention, the central database may communicate with a number of different parties and includes adapters that convert the data format used by each of these parties into a single data format, preferably a data format defined by the purchasing organization.

The invention is not limited to the use of payment cards and also covers transactions made using other means such as smartphones or other devices, for example using QR, EAN or PIN codes.

The term "bank" in this application refers to any payment service or financial institution authorized to approve and process payment card payments or other similar types of transactions, and therefore does not only refer to payment services or financial institutions that are formally defined and authorized as banks. In some jurisdictions, a payment service or financial institution must meet certain regulatory requirements, such as to be covered by deposit insurance, and in these jurisdictions the term “bank” may be used to refer to payment services or financial institutions that meet such regulatory requirements. As used herein, the term “bank” is not limited to this meaning and refers to any payment service or financial institution authorized to approve and process payment card payments or other similar types of transactions. Thus, the term "bank" in this application may also refer to credit card networks, such as MasterCard or VISA, that approve and complete transactions. The term “bank” as used in this application may also refer to the collaboration of credit card networks, such as MasterCard or VISA, and payment services or financial institutions that are authorized to approve and process payment card payments or other similar types of transactions.

The central processing facility in the central database may be one central processing device or several central processing devices between which corresponding signals are transmitted. For example, some of the processing may occur in one central processing device, and then the necessary signals can be transmitted to one or more other central processing devices for further processing.

The banking processing means of the bank-related database module may be any one or more devices for processing data in the banking system and thus is not necessarily dedicated to the bank-related database module.

Modules in a bank can be physically separate modules between which information is sent, or they can also be virtual modules implemented on a single server, or simply software modules.

The scope of the invention is determined by the claims, which are incorporated herein by reference. A more complete understanding of the embodiments of the invention by those skilled in the art and the realization of its additional advantages is provided by consideration of the following detailed description of one or more embodiments. First, a link is given to the attached drawings and their brief description.

Brief description of drawings

In fig. 1 schematically illustrates a system for managing purchases in accordance with one or more embodiments described herein.

In fig. 2 is a schematic illustration of a system for managing purchases in accordance with one or more embodiments described herein.

In fig. 3 schematically illustrates a system for managing purchases in accordance with one or more embodiments described herein.

In fig. 4 illustrates an exemplary flowchart of a method for managing purchases in accordance with one or more embodiments described herein.

In fig. 5 is a schematic illustration of a portion of a system for managing purchases in accordance with one or more embodiments described herein.

In fig. Figure 6 shows an example of transaction authorization information.

In fig. 7 schematically illustrates a method for managing purchases in accordance with one or more embodiments described herein.

Embodiments of the present invention and their advantages will be clear from the following detailed description. It should be understood that like numerals are used to refer to like elements illustrated in one or more of the drawings.

Carrying out the invention

There are several different types of payment card processing models. The simplest model, in which the merchant issues a payment card and has a direct relationship with the cardholder, can be defined as a two-corner model. In the two-corner model, the cardholder can only use the payment card at the issuing merchant.

If a merchant is unwilling to issue and process a payment card, a three-corner model may be used, in which a third party acts as an intermediary between the cardholder and the merchant. In the three-corner model, the cardholder can still only use the payment card at the designated merchant.

To provide cardholders with more flexibility, payment cards typically use a four-corner model. In such a model, the cardholder can use a payment card to make payments to any merchant who accepts such card, and the transaction is processed between the merchant's bank and the cardholder's bank through a payment card network such as MasterCard or VISA.

When using a payment card for payment, transaction authorization is accomplished by the merchant's bank sending a transaction authorization request to the cardholder's bank through the payment card network. For example, such a transaction authorization request may include the transaction authorization information shown in FIG. 6. The cardholder's bank then performs a series of checks, such as card details, account balance, limits and behavior, before approving or rejecting the transaction.

According to the present invention, a purchase approval request is added to the transaction authorization process in addition to the general transaction authorization. The purchase is approved by the cardholder's bank at the same time as the general authorization of the transaction. The seller's bank should not be involved or even aware that purchase approval is taking place in addition to general transaction authorization. If the purchase is not approved, the merchant's bank is informed that the transaction is not authorized, whether this is due to checks such as card details, account balance, limits and behavior, or because the requested purchase does not satisfy purchase rules.

According to the present invention, there is no need to configure suppliers/vendors in the purchasing management system before making purchases or to associate them in any way with the purchasing management system. The present invention allows purchase information to be transmitted to the buying organization even if the suppliers/vendors have no connection with the purchasing management system, which is not possible with prior art systems.

The present description relates to purchase management systems and methods for managing purchases. In the following, embodiments of the solution described above are presented in more detail with reference to the drawings.

In fig. 1 is a schematic diagram of a purchase management system 100 in accordance with one or more embodiments described herein. The purchase management system 100 may include a central database 110, a customer interface 120 to the central database 110, and a bank-related database module 130 capable of communicating with a transaction authorization module 520 at the cardholder's bank 500. The central database 110 may, for example, be a cloud service. A bank-related database module 130 may reside within the cardholder's bank 500 to provide a quick response to a purchase approval request, as well as allow transaction type information that is not permitted to be sent outside the bank's firewall for regulatory reasons to be added as metadata. associated with the first transaction identifier to the bank associated database module 130. There are strict regulatory requirements for transaction information that is permitted to be received from outside and/or sent outside the bank, but by placing a bank-related database module within that bank, transaction information that is not permitted to be received from outside and/or sent outside the bank , may be entered into the bank-related database module 130.

The central database 110 is capable of receiving purchasing rules from the purchasing entity 200 via the customer interface 120 . These purchasing rules may be general purchasing rules for the entire purchasing organization 200 or may be purchasing rules associated with a specific division within the purchasing organization 200 or even a specific purchasing individual. In particular, client interface 120 may be a web interface or a mobile application.

The central processing facility 115 in the central database 110 may create transaction identifiers for use in transactions. Transaction IDs can be created individually or in batches, and they can be created based on predefined rules or upon request from the purchasing entity 200. Transaction IDs can be created before any purchasing rules are defined. Transaction IDs may require activation before they can be used.

For each transaction ID, information about the corresponding buyer can be added as metadata. For example, a qualifying buyer may be defined as any individual purchasing from the group of 300 buyers. The buyer group 300 may include one or more buying individuals, but may also be, for example, defined as a subdivision of the buying entity 200 or the entire buying entity 200. All buying individuals in the buying group 300 need not be employees of the buying entity 200 For example, buyer group 300 may include consultants or subcontractors of purchasing entity 200.

Based on the metadata related to the buyer group 300, the central processor 115 of the central database 110 may identify purchase rules applicable to a transaction ID and add these purchase rules as metadata associated with that transaction ID. The purchasing rules are the same for all buying individuals in the buyer group 300, and the buyer groups 300 can be dynamically changed if there is a need for different purchasing rules for different purchasing individuals in the buyer group. In this case, for individuals who require different purchasing rules, a new group of 300 buyers is simply formed.

Other types of transaction-related information may also be added as metadata associated with the transaction ID in the central database 110. Organizations other than purchasing entity 200 may also have access to the central database 110 and be able to add metadata associated with the transaction ID. The addition of metadata to the central data base 110 by third parties 150, preferably using a dedicated third party interface 160, is illustrated in FIG. 2. Specifically, third-party interface 160 may be a web interface or a mobile application.

For example, such third party entity 150 may be a customer of purchasing entity 200 for which purchasing entity 200 makes a purchase and then invoices that customer. In this case, the metadata, for example, could be consent to payment of the purchase price. It is then preferable that all information needed to bill the customer is added as metadata associated with the transaction ID so that billing the customer can be simplified or even automated.

Another example of such a third party organization 150 could be an organization that provides information about blacklisted suppliers or suppliers that do not meet certain regulatory requirements. If such an organization adds this information as metadata to all transaction identifiers, then the purchasing rules may specify that purchases from the supplier/vendor identified by this metadata are not permitted.

Another example of such a third party entity 150 is merchant/supplier 400. If merchant/supplier 400 has access to the central database 110 and can add metadata associated with a transaction ID, then such merchant/supplier 400 may, for example, add an electronic receipt as metadata associated with the transaction ID. Vendor/supplier 400 may use a third-party interface 160 or a custom interface for vendors/suppliers 400. Specifically, such interface may be a web interface or a mobile application. However, the electronic receipt may also be added by another party, such as an individual buyer from the buyer group 300, if the seller/supplier 400 does not have access to the central database 110.

Individual purchasing groups 300 may also be able to communicate with the central database 110 to retrieve information and/or add metadata. For example, if purchasing entity 200 wishes to allow the use of company payment cards for private purchases, the purchasing individual may have the ability to mark the purchase as private, for example, so that its value is automatically deducted from the next paycheck. Individual buyers from groups of 300 buyers can use a third-party interface 160 or a special interface for groups of 300 buyers. In particular, such an interface may be a web interface or a mobile application.

For example, purchasing rules may require the purchasing individual to add certain metadata to the transaction ID before or after the purchase to facilitate management within the purchasing entity 200. In particular, making a purchase may require that an account, cost center, project, or entity be added as metadata. associated with the transaction ID. Some types of purchases may have additional requirements based on metadata added by the individual purchasing. For example, if the purchase relates to entertainment expenses, such as a visit to a restaurant with a client, the purchasing individual may be required to add the names of the people present as metadata associated with the transaction ID. If the purchase involves a business trip, the private buyer may be required to indicate the destination and/or purpose of the trip. This provides automatic accounting of invoices to the purchasing entity 200. Purchasing rules may require that this metadata be added to approve the purchase. If purchasing rules require this metadata to be added, the purchasing individual may be warned that the purchase will be rejected if this metadata is not added before the individual purchasing individual attempts to complete the purchase. In this case, a warning is sent to the purchasing individual, for example via SMS, email or mobile application.

However, some information cannot be added until the purchase is approved. For example, a retail buyer may need to include a receipt with metadata associated with a transaction ID, such as a photo of the receipt from a mobile app. In these situations, the purchase has already occurred and cannot be declined, but future purchases for that purchasing individual may be blocked until the required metadata has been added to all previous transactions. Such blocking may be performed manually at the purchasing organization 200. However, the purchase rules may state that, for example, if it has not been made after a certain time or after a certain number of purchases, then further purchases are automatically blocked.

Purchasing policies for specific suppliers/sellers may also specify how purchases can be made. For example, for cost reasons, the policy may specify that a certain supplier only allows online purchases, in which case an attempt to purchase in a brick-and-mortar store will be rejected. The purchasing individual is sent information about the reason for such deviation via SMS, email or mobile application.

Metadata associated with the transaction identifier may be transmitted to the bank-associated database module 130. There is no need to transfer all the metadata to the bank-related database module 130 when transferring the purchasing rules and the metadata that applies to them. However, in one embodiment of the invention, the bank-associated database module 130 mirrors all information from the central database 110.

When the bank-related database module 130 has received the metadata associated with the transaction ID, a purchase approval request may be sent from the transaction authorization module 520 to the cardholder's bank 500. The purchase approval request contains transaction information, which may be the same as the transaction authorization information that, when a payment card is used to pay for the purchase, is sent through the payment card network from the merchant's bank to the cardholder's bank 500 and received by the transaction authorization module 520. An example of such transaction authorization information is shown in FIG. 6. The transaction information in the purchase approval request does not need to contain all the information to authorize the transaction, it may contain the amount and enough information to associate it with the desired transaction ID. If the purchase approval request does not contain a transaction identifier, then it must therefore contain other transaction information allowing the bank-related database module 130 to associate the purchase with a transaction identifier, for example, transaction information identifying a group of customers 300. If the customer group 300 is assigned one or more payment cards, this transaction information may be, for example, a payment card number or a token for the payment card number. The bank processing engine 135 of the bank-related database module 130 can then simply associate the purchase with the next transaction ID available for that group of 300 customers.

The bank processing facility 135 of the bank-related database module 130 then checks whether the requested purchase satisfies the purchase rules associated with the transaction ID, that is, the purchase rules applicable to the customer group 300. In addition to the examples above, shopping rules may, for example, relate to maximum amounts per purchase, maximum totals, adherence to a budget, or restrictions on where and when purchases can be made (for example, international or weekend purchases may be blocked). If the purchase approval request contains information about the seller, such as the seller's name or code to identify the seller, then the purchase rules may also apply to specific sellers allowed or blocked for a group of 300 buyers. This allows the purchasing entity 200 to block purchases from selected suppliers/vendors and/or allow purchases only from selected suppliers/vendors. For example, purchasing entity 200 may use this functionality to block purchases from liquor stores such as Systembolaget, or to only allow purchases from certain grocery chains, such as ICA and/or Coop, or from certain types of merchants, such as grocery stores.

Thus, the banking processing engine 135 of the bank-related database module 130 approves or denies the purchase approval request depending on whether the requested purchase satisfies the purchase rules associated with the transaction ID in the bank-related database module 130. The banking processing engine 135 of the bank-related database module 130 also adds the transaction information received from the transaction authorization module 520 as metadata associated with the transaction ID to the bank-related database module 130 and transmits this transaction information to the central database. 110 data, where it is also added as metadata associated with the transaction ID. This may occur before or after the approval/rejection is sent to the transaction authorization module 520 .

The transaction information is preferably "translated" or converted using the functionality of the central database 110 into another data format, preferably a data format defined by the purchasing entity 200. This is further explained with reference to FIG. 5.

Based on the approval/rejection received from the banking processing engine 135 of the bank-related database module 130, along with the general authorization of the transaction performed by checking, for example, card data, account balance, limits and behavior, the transaction authorization module 520 approves or rejects the transaction. . If the banking processing facility 135 of the bank-related database module 130 has rejected a transaction, the transaction authorization module 520 rejects the transaction even if the general transaction authorization checks indicate that it is valid. Likewise, if the general transaction authorization checks indicate that the transaction is invalid, the transaction authorization module 520 rejects the transaction even if the bank processing engine 135 of the bank-related database module 130 approves the purchase. In such situations, the transaction authorization module 520 may not even send the purchase approval request to the bank-related database module 130 since the transaction would be rejected anyway.

If general transaction authorization is performed in the transaction authorization module 520 before sending the purchase approval request to the bank-related database module 130, the banking processing engine 135 of the bank-related database module 130 may determine whether to approve or reject the transaction to the transaction authorization module 520 after as the bank processing facility 135, the bank-related database module 130 will decide to approve or reject the purchase approval request. Alternatively, the transaction authorization module 520 may pass this information to the bank-related database module 130. Information regarding whether a transaction was approved or rejected by the transaction authorization module 520 may be added as metadata associated with the transaction ID in the bank-related database module 130 .

Other types of information may also be added as metadata associated with the transaction ID in the bank-related database module 130. For example, bank 500 may provide bank-related database module 130 with information about suspected fraud, transaction status, or other similar types of information so that the information can be transmitted to central database 110.

Once the transaction information is accepted by the central database 110 as metadata associated with the transaction identifier, the central processing facility 115 in the central database 110 may transmit the transaction information to the purchasing entity 200, preferably in a data format determined by the purchasing entity 200. This allows automatic enter transaction information into the business management systems and/or other management systems of the purchasing entity 200. Thus, the purchasing entity can track all transactions long before receiving invoices from suppliers/vendors. This allows the purchasing organization 200 to continually monitor its budget and adapt its purchasing rules accordingly.

Purchase rules may change for various reasons. If a particular division of the buying entity 200 is treated as one group of 300 buyers, but the purchasing rules need to be adapted for certain buying individuals in that division, such as adding more restrictions (or even blocking all purchases) for a certain buying individual, then for that buying individual individuals, a new group of 300 buyers may be created with more restrictive purchasing rules than for the rest of the division's employees. Thus, the buying organization 200 dynamically updates both the buyer groups 300 and the purchasing rules.

The purchasing entity 200 does not necessarily define the actual groups of buyers in the system. Instead, purchasing entity 200 may, for example, define purchasing rules at multiple hierarchical levels. Some rules may be general for the entire organization, while other rules may be specific to individual buying individuals or to groups of purchasing individuals. In the context of this application, a buyer group 300 is a group of one or more individual buying individuals who are subject to the same purchasing rules.

Fields in the central database 110 that allow metadata to be associated with transaction identifiers can also be dynamically set by the purchasing entity 200 so that the purchasing entity 200 can define the desired metadata and the data format for that metadata. This allows, for example, metadata relating to cost centers, invoices and other billing information to be linked to transaction identifiers in the central database 110 . In this way, the purchasing entity 200 can determine the metadata it wishes to receive and the format in which it wishes to receive it in the electronic invoice so that the metadata can be retrieved from the central data base 110 and added to the electronic invoice. Such an electronic invoice may be sent by a bank 500, a central database 110, or a third party. If the invoice for transactions completed using the system 100 is an electronic invoice containing metadata specified by the purchasing entity 200, this allows the invoice to be automatically processed by the purchasing entity 200, thereby significantly reducing the management burden.

To make payments in the present invention, for example, payment cards can be used. In this case, individual purchasing information may be transmitted from the central database 110 to the payment card issuer 600, as shown in FIG. 3. This transfer may occur directly between the central database 110 and the payment card issuer 600, or it may occur through the payment card management module 510 within the bank 500. The payment card issuer 600 may be associated with the bank 500 or may be a separate issuer 600 payment cards.

To associate payments made using payment cards with purchasing individuals making purchases, payment card information is preferably transmitted from the payment card issuer 600 to the central database 110 directly or through the payment card management module 510 within the bank 500. Such information is preferably are not actual credit card numbers, since there may be restrictions as to whether they are allowed to be stored in the central data database 110 as metadata associated with transaction identifiers. Instead, such information could be, for example, tokens for credit card numbers.

In fig. 4 is an example flowchart of a method for managing purchases in accordance with one or more embodiments of the invention described herein. In this case, the following sequence of actions is performed.

Step 410: The purchasing entity 200 generates its purchasing rules in the central database 110 (this may occur at any time prior to step 460, and metadata may be added by the purchasing entity 200 at any time during this sequence of actions).

Step 415: The central database 110 orders card accounts for the purchasing entity 200 from the cardholder's bank 500.

Step 420: The cardholder's bank 500 orders payment cards from the payment card issuer 600.

Step 425: Additional information, such as card personalization, logos, etc., may be provided to the payment card issuer 600 from the central database 110. Payment cards may also be ordered from the payment card issuer 600 directly from the central database 110 .

Step 430: Payment cards are sent by the payment card issuer 600 to the purchasing individuals 300 (the purchasing entity 200 may participate in their distribution).

Step 435 (optional): The purchasing individual 300 adds metadata related to the purchase via a user interface to the central database 110 (this can occur at any time during the sequence of actions).

Step 440: Transaction identifiers and associated metadata, such as purchasing rules, are transferred from the central database 110 to the bank-related database module 130.

Step 445: The purchasing individual makes a purchase from the seller/supplier 400.

Step 450: Merchant bank 550 receives purchase information from merchant/supplier 400.

Step 455: The merchant bank 550 requests the cardholder bank 500 to authorize the transaction, for example, through a payment card network such as VISA or MasterCard.

Step 460: The cardholder's bank 500 requests approval of the purchase from the bank-related database module 130.

Step 465: The bank-related database module 130 sends the purchase approval to the cardholder's bank 500.

Step 470: The cardholder's bank 500 sends the transaction authorization to the merchant's bank 550.

Step 475: The merchant bank 550 sends the transaction authorization to the merchant/supplier 400.

Step 480: The bank-related database module 130 transmits transaction information regarding the approved purchase to the central database 110 (this may occur at any time after step 460).

Step 485: The central database 110 transmits the transaction information to the purchasing entity 200.

Step 490 (optional): Third parties add metadata to the transaction (this can happen at any time during the sequence of actions).

In fig. 5 is a schematic illustration of a portion of a purchase management system 100 in accordance with one or more embodiments of the invention described herein. The central database 110 preferably uses a dynamic configuration of “metadata media” to allow metadata to be associated with transaction identifiers so that the purchasing entity 200 can define the desired metadata and the format of that metadata. As described above with reference to FIG. 1-3, the central database 110 may interact and exchange data with many different parties, such as purchasing entities 200, purchasing individuals or groups of buyers 300, suppliers/merchants 400, cardholder banks 500, payment card issuers 600, and various others. third parties 150. In order for the central database 110 to collect data from these parties and transmit data to and from these parties, the central database 110 must have appropriate functionality, for example in the form of "adapters" to "translate" or convert the data format used each of these parties into a single data format, preferably a data format specified by the purchasing entity 200. The central database 110 should contain a special adapter 205, 305, 405, 505, 605, 155 for each party 200, 300, 400, 500 , 600 , 150 , since different parties typically use different data formats (if there are several different third parties 150 , then several different adapters 155 are typically required). This allows the purchasing entity 200 to define the metadata it wishes to receive from various parties, as well as the format of the data in that metadata.

Usage example

To further describe the invention, the following use case is proposed. Acquiring Company A consists of Service, Development, Sales and Management divisions. Company A defines its purchasing policies and rules through the customer interface 120 to the central database 110 and orders payment cards for all its purchasing individuals from its Cardbank. Some purchasing individuals have personal payment cards, others have group payment cards.

Company A defines its Service division as a Service customer group in which all personnel are subject to the same purchasing rules. Because service personnel must respond quickly and frequently travel to the field to immediately repair faulty equipment, all individual purchasers in the Service buyer group have personal payment cards, and there are very few restrictions in the purchasing rules for the Service buyer group. However, Company A continuously monitors all purchases against the Service division's budget and may adapt purchasing policies over time due to budget constraints.

Company A defines its Development division as a significantly more restricted Development buyer group. The Development staff consists of Company A employees and consultants. Development personnel are not permitted to make purchases that have not been pre-approved by the Development Manager. Some of the Development staff have personal payment cards, but there are also several group payment cards for the Development customer group.

Company A defines its Sales division as two different groups of customers: Local Sales and Global Sales. The Local Sales buyer group does not typically travel internationally, so its purchasing rules may be limited to domestic purchases. The Global Sales buyer group, on the other hand, travels a lot and therefore may have significantly fewer restrictions on purchasing rules. However, the purchasing rules may, for example, require pre-approval if a hotel is selected that is not on the list of hotels and hotel chains with which Company A has negotiated prices. All personnel in the Sales department have personal payment cards.

Company A defines its Management division as the Management customer group. Management staff must be able to make minor purchases such as office supplies and lunches, so purchasing rules may include, for example, quantity and supplier restrictions. The “Management” buyer group has a group payment card.

When a member of the Service team attempts to make a purchase using a payment card, the merchant's bank sends a transaction authorization request, for example, containing the transaction authorization information shown in FIG. 6, to Cardbank through the payment card network. Cardbank transaction authorization module 520 receives the transaction authorization request and performs a number of checks, for example regarding card details, account balance, limits and behavior. If Cardbank's transaction authorization module 520 decides to approve the transaction based on these checks, it sends a purchase approval request to the bank-related database 130 at Cardbank, where transaction IDs are stored with associated metadata.

Since all service employees have the same purchase rules, the bank-related database 130 can associate the purchase with the next available transaction ID in the database for the "Service" customer group. In this case, you can determine that the purchase belongs to the “Service” customer group, for example, by the payment card number. However, instead, the Maintenance employee may have already selected a specific transaction ID, and the employee may have already added metadata associated with that transaction ID. The service purchase rules are stored as metadata associated with the transaction ID, so the bank associated database 130 makes a decision on the purchase approval request, approving or denying it depending on whether the requested purchase satisfies the Service purchase rules. Since there are very few restrictions in the Service division's purchasing rules, most purchases are allowed. The bank-associated database 130 stores transaction information as metadata associated with a transaction ID and transmits this metadata to the central database 110 . The central database 110 then transmits the transaction information to Company A so that the purchase information can be automatically entered into Company A's business management system and other management systems.

When purchases are made by the staff of the Development department, a similar sequence of actions is performed. However, because Development personnel are not permitted to make purchases that have not been pre-approved by the Development Manager, they require prior approval of the purchase. Development personnel wishing to make a purchase use the appropriate buyer group 300 interface (e.g., web interface or mobile application) to obtain a transaction ID and enter the required metadata related to that purchase into the central database 110 through that interface. An action is then assigned to the Development Manager to pre-approve this purchase. This could simply be an action defined in the system, but a reminder could also be automatically sent to the manager, for example via SMS or email. After the purchase is approved by the head of the Development department, the purchase rules allow it to be completed.

When purchases are made by the personnel of the Sales department, a similar sequence of actions is also performed. Like the Service staff, the Global Sales buyer group has very few restrictions. However, you may need to change the purchasing rules for an individual or a group of individuals in the Global Sales buyer group, for example, if the hospitality expenses are unusual. A new buyer group can then be defined with additional restrictions, for example on entertainment expenses, so that the previous buyer group “Global Sales” becomes, for example, two groups “Global Sales Regular” and “Global Sales Restricted”.

When purchases are made by the personnel of the Management department, a similar sequence of actions is also performed. At the same time, the personnel of the Management division have significantly more stringent purchasing rules, for example, with restrictions on acceptable suppliers/sellers. The transaction information sent by the Cardbank transaction authorization module 520 also contains merchant information, such as a merchant name or merchant identification code, and therefore the bank-related database 130 can compare the merchant information with eligible merchants according to purchasing rules. Management staff may be limited to purchasing from certain suppliers/vendors, such as ICA and/or Coop, or certain types of merchants, such as grocery stores. Specifically, the VISA merchant classification for the Miscellaneous Grocery Stores - Convenience Stores and Specialty Markets category uses MCC code 5499 and includes this code in the merchant identification code in the transaction authorization information. When Management personnel purchase products at a grocery store, different VAT amounts may apply to different types of goods. Different VAT values for different items during a purchase can then be automatically stored as metadata associated with the transaction ID for ease of management within the purchasing organization 200.

Method embodiments

In fig. 7 is a schematic diagram of a method 700 for managing purchases in accordance with one or more embodiments of the invention described herein. Method 700 may include the following steps.

Step 710: input via customer interface 120 to central database 110 of purchasing rules data applicable to a group of 300 customers.

Step 720: Adding the selected buyer group 300 as metadata associated with the first transaction ID to the central database 110.

Step 725: Adding the purchasing rules applicable to the buyer group 300 as metadata associated with the first transaction ID to the central database 110.

Step 730: Transmits metadata associated with the first transaction identifier from the central database 110 to the bank-related database module 130.

Step 740: Receives, at transaction authorization module 520 located at bank 500, a first transaction authorization request associated with the first transaction identifier and containing transaction authorization information.

Step 750: transmitting the purchase approval request from the transaction authorization module 520 to the bank-related database module 130, wherein the purchase approval request contains transaction information including at least the purchase amount.

Step 760: Decide on the purchase approval request by approving or rejecting it depending on whether the requested purchase satisfies the purchase rules associated with the first transaction ID in the bank-related database module 130.

Step 765: Respond to transaction authorization module 520 by approving or denying the purchase approval request.

Step 770: Response from transaction authorization module 520 to the first transaction authorization request associated with the first transaction identifier.

Step 780: Adding the transaction information received from the transaction authorization module 520 as metadata associated with the first transaction identifier to the bank-related database module 130.

Step 785: Transmitting transaction information associated with the first transaction identifier to the central database 110.

Step 790: transmitting transaction information associated with the first transaction identifier to the purchasing entity 200 so that the purchase information can be automatically entered into the at least one management system of the purchasing entity 200.

In some embodiments, the bank-related database module 130 resides within the bank 500. This provides a fast response time to a purchase approval request and also allows the addition of transaction type information that is not legally allowed to be sent outside the bank's firewall. as metadata associated with the first transaction identifier to the bank-related database module 130. There are strict regulatory requirements for transaction information that is permitted to be received from outside and/or sent outside the bank, but by placing a bank-related database module within that bank, transaction information that is not permitted to be received from outside and/or sent outside the bank , can be entered into the bank-related database module 130.

In some embodiments of the invention, the buyer group 300 includes at least one individual buyer. This makes it possible to define purchasing rules and tailor them for one or more purchasing individuals or for divisions of a purchasing organization consisting of one or more purchasing individuals.

In some embodiments of the invention, buyer group 300 includes the entire buying organization 200. This allows the buying organization to define general purchasing rules for the entire organization.

In some embodiments of the invention, the purchasing rules are general purchasing rules for a division of the buying organization 200, and adding the purchasing rules 725 that apply to a group of 300 buyers as metadata associated with the first transaction identifier to the central database 110 includes determining whether , to which division the group of 300 buyers belongs.

In some embodiments of the invention, the transaction information includes information about the merchant, such as the merchant's name or code to identify the merchant, and the decision 760 on the purchase approval request by either approving or rejecting it further depends on the merchant information.

In some embodiments, purchase rules indicate that certain metadata associated with a transaction ID must be added to the central database 110 prior to making a purchase, and decision 760 on a purchase approval request includes rejecting the purchase approval request if related with the bank database module 130 there is no such metadata associated with the transaction ID.

In some embodiments of the invention, transmitting 730 metadata associated with the first transaction identifier from the central database 110 to the bank-related database module 130 and transmitting 785 transaction information associated with the first transaction identifier to the central database 110 include synchronizing the central database 110 and the bank-related database module 130 so that they are mirror versions of each other.

In some embodiments of the invention, the central database 110 is configured to communicate with a number of different parties 200, 300, 400, 500, 600, 150 and includes adapters 205, 305, 405, 505, 605, 155 that convert the data format used by each of these parties into a common data format, preferably a data format defined by the purchasing entity 200.

Method 700 may further include the following steps.

Step 705: transmits information from the central database 110 to the payment card issuer 600 directly or through the payment card management module 510 within the bank 500 so that the payment card issuer 600 can issue payment cards to the purchasing entity 200.

The foregoing description of the invention is not intended to limit the present invention to the forms described or to specific fields of use. It is intended that in light of the present description, various alternative embodiments and/or modifications of the present invention, whether expressly described or implied, are possible. An embodiment of the invention using payment cards is described here. However, the invention is not limited to embodiments using payment cards and also covers other payment methods, for example payment using smartphones or other devices, in particular using QR, EAN or PIN codes. Accordingly, the scope of the invention is determined solely by the claims.

Additionally, not all steps in a claim need to be performed in the order stated. For example, purchasing rules do not need to be entered into the central database 110 before creating a transaction ID. In addition, if the purchasing entity 200 changes the purchasing rules and enters new purchasing rules into the central database 110, then metadata related to the purchasing rules and associated with the transaction ID in the central database 110 may be updated and transmitted to the bank-related database module 130 data before approving or denying a purchase approval request for that transaction ID. In another example, transaction information may be added as metadata associated with the transaction ID before or after the purchase approval request is approved/rejected. The claims cover all technically feasible options for the sequence of actions.

Claims (41)

1. A purchase management system (100) comprising a central data base (110), a client interface (120) to the central data base (110) and a bank-related database module (130) capable of communicating with a transaction authorization module (520) within the bank (500), while: The central database (110) is capable of receiving from the purchasing entity (200), via the customer interface (120), purchasing rules applicable to a group of customers (300) and a data format defined by the purchasing entity (200) fields in the central database (110). allow metadata to be associated with transaction identifiers, and fields in the central data database (110) are dynamically set by the purchasing entity (200) to determine the metadata required by the purchasing entity (200) and the data format for that metadata, and comprises a central processing facility (115) capable of: add the selected group (300) of buyers as said metadata in a data format determined by the purchasing entity (200) associated with the first transaction identifier of said transaction identifiers to the central database (110); add the purchase rules applicable to the group (300) of buyers as said metadata associated with the first transaction identifier to the central database (110); And transmit said metadata associated with the first transaction identifier to the bank-related database module (130); The bank-related database module (130) is capable of receiving from the transaction authorization module (520) a purchase approval request containing transaction information, wherein the purchase approval request is generated by the transaction authorization module (520) based on the transaction information received from the module ( 520) authorizing a transaction through a payment card network, and the transaction information includes at least a purchase amount associated with the first transaction identifier, and includes a banking processing facility (135) capable of: make a decision on the purchase approval request by approving or rejecting the purchase approval request depending on whether the requested purchase satisfies the purchase rules associated with the first transaction identifier in the bank-related database module (130); respond to the transaction authorization module (520) by approving or rejecting the purchase approval request; add the transaction information received from the transaction authorization module (520) as metadata associated with the first transaction identifier to the bank-related database module (130); And transmit transaction information associated with the first transaction identifier to the central database (110); the central processing facility (115) of the central database (110) is also capable of transmitting transaction information associated with the first transaction identifier to the purchasing entity (200), wherein the purchase information is automatically entered into at least one management system of the purchasing entity (200) , And the central database (110) is configured to communicate with various parties (200, 300, 400, 500, 600, 150) and contains adapters (205, 305, 405, 505, 605, 155), each adapter corresponding to one of the different sides (200, 300, 400, 500, 600, 150), adapters (205, 305, 405, 505, 605, 155) convert the data format used by the corresponding of these different sides (200, 300, 400, 500, 600, 150), into a data format defined by the purchasing organization (200). 2. The system according to claim 1, wherein the bank-related database module (130) is located within the bank (500). 3. The system according to claim 1, in which the purchasing rules apply to a group (300) of buyers, including at least one individual purchasing. 4. The system of claim 1, wherein the purchasing rules apply to a group (300) of buyers including the entire purchasing organization (200). 5. The system according to claim 1, in which the purchasing rules are general purchasing rules for a division of the purchasing organization (200), and the central processing facility (115) of the central data base (110) is capable of adding purchasing rules applicable to a group (300) of buyers, as metadata associated with the first transaction identifier to a central data base (110) based on determining which division the customer group (300) belongs to. 6. The system of claim 1, wherein the transaction information includes merchant information, and the banking processing means (135) of the bank-related database module (130) is capable of deciding on the purchase approval request by approving or rejecting the purchase approval request also depending on the seller's information. 7. The system of claim 1, wherein the purchase rules indicate the need to add certain metadata associated with the transaction identifier to the central data base (110) before making a purchase, and the bank processing means (135) of the bank-related database module (130) data is capable of rejecting a request to approve a purchase if the metadata associated with the transaction identifier is not present in the bank-related database module (130). 8. The system according to claim 1, in which the central processing facility (115) of the central data base (110) is also capable of transmitting information directly or through the payment card management module (510) within the bank (500) to the issuing organization (600) of payment cards cards that issue payment cards for the purchasing organization (200). 9. The system according to claim 1, wherein the central database (110) and the bank-associated database module (130) are synchronized so that they are mirror versions of each other. 10. A method (700) for managing purchases, including: input (710), through the customer interface (120) to the central database (110), of the purchasing rules applicable to the group (300) of customers, and the data format defined by the purchasing organization (200), the fields in the central database (110) data allow metadata to be associated with transaction identifiers and fields in a central data database (110) are dynamically set by the purchasing entity (200) to define the metadata required by the purchasing entity (200) and the data format for that metadata; adding (720) a selected group (300) of buyers as said metadata in a data format determined by the purchasing entity (200) associated with the first transaction identifier of said transaction identifiers to the central database (110); adding (725) purchase rules applicable to the group (300) of buyers as said metadata associated with the first transaction identifier to the central database (110); transmitting (730) said metadata associated with the first transaction identifier from the central data database (110) to the bank-related database module (130); receiving (740) at the transaction authorization module (520) located at the bank (500) a first transaction authorization request associated with the first transaction identifier and containing information for authorizing the transaction; transmitting (750) a purchase approval request from a transaction authorization module (520) to a bank-related database module (130), wherein the purchase approval request contains transaction information, wherein the purchase approval request is generated by the transaction authorization module (520) to based on the transaction information received from the transaction authorization module (520) through the payment card network, and the transaction information includes at least a purchase amount; deciding (760) on a purchase approval request by approving or rejecting the purchase approval request depending on whether the requested purchase satisfies the purchase rules associated with the first transaction identifier in the bank-related database module (130); a response (765) to the transaction authorization module (520) by approving or rejecting the purchase approval request; a response (770) from the transaction authorization module (520) to the first transaction authorization request associated with the first transaction identifier; adding (780) transaction information received from the transaction authorization module (520) as metadata associated with the first transaction identifier to the bank-related database module (130); transmitting (785) transaction information associated with the first transaction identifier to a central database (110) and transmitting (790) transaction information associated with the first transaction identifier to the purchasing entity (200), wherein the purchase information is automatically entered into at least one purchasing entity management system (200), and wherein the central database (110) of the data is configured to communicate with various parties (200, 300, 400, 500, 600, 150) and contains adapters (205, 305, 405, 505, 605, 155), each adapter corresponds to one from different sides (200, 300, 400, 500, 600, 150), adapters (205, 305, 405, 505, 605, 155) convert the data format used by the corresponding of these different sides (200, 300, 400, 500, 600, 150), into a data format defined by the purchasing organization (200). 11. The method of claim 10, wherein the bank-related database module (130) is located within the bank (500). 12. The method according to claim 10, wherein the group (300) of buyers includes at least one individual buyer. 13. The method of claim 10, wherein the buyer group (300) includes the entire purchasing entity (200). 14. The method of claim 10, wherein the purchasing rules are general purchasing rules for a division of the purchasing entity (200), and adding (725) purchasing rules applicable to a group of buyers (300) as metadata associated with the first transaction identifier, the central database (110) of data includes determining which division the group (300) of buyers belongs to. 15. The method of claim 10, wherein the transaction information includes merchant information, and deciding (760) on the purchase approval request by approving or rejecting the purchase approval request also depends on the merchant information. 16. The method of claim 10, wherein the purchasing rules indicate that certain metadata associated with the transaction ID must be added to the central data base (110) before the purchase is made, and the decision (760) on the purchase approval request includes rejecting purchase approval request if the bank-related database module (130) does not have this metadata associated with the transaction identifier. 17. The method according to claim 10, also including the transfer (705) of information from the central data base (110) to the payment card issuing organization (600) directly or through the payment card management module (510) within the bank (500), so that the payment card issuing entity (600) can issue payment cards to the purchasing entity (200). 18. The method of claim 10, wherein transmitting (730) metadata associated with the first transaction identifier from the central database (110) to the bank-associated database module (130) and transmitting (785) transaction information associated with the first transaction identifier to the central data base (110) includes synchronizing the central data base (110) and the bank-related database module (130) so that they are mirror versions of each other.