KR20210099098A - PURCHASE MANAGEMENT SYSTEM AND METHOD - Google Patents

Abstract

In accordance with one or more embodiments herein, a purchase management system is provided. The purchase management system 100 is a bank specific database module configured to communicate with a central database arrangement 110 , a customer interface 120 to the central database arrangement 110 and a transaction authorization module 520 within the bank 500 . (130). The central database arrangement 110 is configured to receive purchasing rules applied to a purchasing group 300 from a purchasing entity 200 via the customer interface 120 , and comprises central processing means 115 , the Central processing means (115) are configured to: add in said central database arrangement (110) a selected purchase group (300) with metadata linked to a first transaction ID; adding the purchasing rules applied to the purchasing group (300) with metadata linked to the first transaction ID in the central database arrangement (110); and transmit the metadata linked to the first transaction ID to the bank specific database module 130 . The bank specific database module 130 may be configured to receive a purchase authorization request from the transaction authorization module 520, wherein the purchase authorization request includes transaction information including at least a purchase amount linked to the first transaction ID. include The bank specific database module 130 comprises bank processing means 135 , wherein the bank processing means 135 include: the requested purchase linked to the first transaction ID of the bank specific database module 130 . determine to approve or reject the purchase authorization request based on whether the purchase rules are met; respond to the transaction approval module (520) with the approval or rejection of the purchase approval request; adding the transaction information received from the transaction approval module 520 as metadata linked to the first transaction ID of the bank unique database module 130; and transmit the transaction information linked to the first transaction ID to the central database arrangement 110 . The central processing means 115 of the central database arrangement 110 are further configured to transmit the transaction information linked to the first transaction ID to the purchasing entity 200 so that the transaction information for a purchase is to be automatically entered into at least one management system of the entity 200 .

Description

PURCHASE MANAGEMENT SYSTEM AND METHOD

The present disclosure relates generally to purchase management systems and methods.

U.S. Patent No. US7319986 describes how to dynamically configure card control settings to dynamically manage approval parameters through application of configurable company purchasing policies and rules. A dynamic payment card management system that can be dynamically modified is described.

The system described in US7319986 revolves around the use of purchase requests. A purchase cannot be made without a specific purchase request, but the purchase request may be synthesized by the system according to circumstances. The use of purchase requisitions simplifies the approval process within the company.

Although it is possible to inform the customer that a transaction has occurred in the system described in US7319986, since the system revolves around the use of purchase requisitions, the details of the purchase at the time of purchase can be transferred to the company's economic system. There is no way to transfer to (economy system). Thus, the company does not receive purchase details until it receives an invoice from the supplier.

Also, the system described in US7319986 is a whole card processing system to replace the existing payment infrastructure.

Accordingly, there is a need for an improved purchase management system.

A purchase management system that revolves around the use of purchase requisitions simplifies the approval process, but since purchase requisitions are managed internally within the company, external parties, for example, can You cannot add information such as

According to the present invention, a database accessible by any party to the system is used instead to store information regarding purchases. The database arrangement preferably includes the functionality to "translate" a data format used by different parties to a single data format into one single data format for the system, which It makes it easier for customers to add information about their purchases.

The present disclosure relates to purchase management methods and purchase management systems in which purchasing entities purchase services and goods from suppliers/merchants. Prior art systems cannot allow transaction information from such purchases to be automatically entered into the purchasing entity's economic systems and other administrative systems. The present invention accomplishes this by gathering information from various parties to the system in a way that prior art systems cannot.

The charged purchase management system is a central database arrangement, a customer interface to the central database arrangement and a bank specific database module arranged to communicate with a transaction authorization module within the bank. specific database modules). The central database arrangement may be configured to receive purchasing rules applied to a purchasing group from a purchasing entity via a customer interface. The central database arrangement may comprise central processing means for performing the following: a group of purchases selected with metadata linked to a first transaction ID in the central database arrangement; add; adding the purchasing rules applied to the purchasing group in the central database arrangement as metadata linked to the first transaction ID; Then, the metadata linked to the first transaction ID is transmitted to the bank-specific database module. The bank-specific database module may be configured to receive a purchase approval request from the transaction approval module, wherein the purchase approval request includes transaction information including at least a purchase amount linked to the first transaction ID. do. The bank-specific database module may include bank processing means for performing the following: Authorize the purchase based on whether the requested purchase meets the purchase rules linked to the first transaction ID of the bank-specific database module. to approve or deny the request; respond to the transaction approval module with approval or rejection of the purchase approval request; add the transaction information received from the transaction approval module as metadata linked to the first transaction ID in the bank unique database module; Then, the transaction information linked to the first transaction ID is transmitted to the central database arrangement. The central processing means of the central database arrangement are further configured to transmit, to the purchasing entity, transaction information linked to the first transaction ID, so that the information about the purchase is automatically transmitted to at least one administrative system of the purchasing entity. may be entered. This is a simplified collection of transaction information from purchases and conversion of transaction information into a data format used by the purchasing entity so that transaction information may be automatically entered into the purchasing entity's economic systems and other management systems. makes this possible

The claimed purchase management method includes: inputting purchase rules applied to a purchasing group into a central database arrangement through a customer interface; adding the selected purchase group as metadata linked to the first transaction ID in the central database arrangement; adding, in the central database arrangement, purchasing rules applied to the purchasing group as metadata linked to the first transaction ID; transmitting the meta data linked to the first transaction ID from the central database arrangement to the bank specific database module; receiving, in a transaction approval module configured in the bank, a first transaction approval request linked to a first transaction ID including transaction approval information, wherein the first transaction approval request includes transaction approval information; communicating a purchase approval request from the transaction approval module (the purchase approval request includes transaction information including at least a purchase amount) to a bank-specific database module; determining to approve or reject the purchase authorization request based on whether the requested purchase satisfies the purchase rules linked to the first transaction ID of the bank unique database module; responding to the transaction approval module with approval or rejection of the purchase approval request; responding to a first transaction approval request linked to the first transaction ID from the transaction approval module; adding the transaction information received from the transaction approval module as metadata linked to the first transaction ID in the bank-specific database module; sending transaction information linked to the first transaction ID to a central database arrangement; and sending the transaction information linked with the first transaction ID to the purchasing entity so that it may be automatically entered into at least one management system of the purchasing entity. This is a simplified collection of transaction information from purchases and conversion of transaction information into a data format used by the purchasing entity so that transaction information may be automatically entered into the purchasing entity's economic systems and other management systems. makes this possible

In embodiments, a bank specific database module is configured within the bank. The definition of "in the bank" means that the modules within the bank are located within the bank's systems behind the bank's firewall, so that information transferred between modules is never transmitted outside the bank's firewall. This provides fast response times to purchase authorization requests, and also metadata linked to the first transaction ID within the bank's unique database module for types of transaction information that are not permitted to be transmitted outside the bank's firewall for regulatory reasons. may be allowed to be added. Although there are strict regulatory requirements for transaction information that are allowed to be transmitted and/or received outside of the bank, by configuring the bank's own database module inside the bank, it also transmits and/or receives outside the bank. Transaction information that is not permitted to do so may be entered into the bank's own database module.

In embodiments, the purchasing group includes at least one purchasing individual. This enables purchasing rules to be defined and applied for one or more specific buyers or subsections of a purchasing entity comprising one or more buyers.

In embodiments, a purchasing group includes the entire purchasing entity. This allows the purchasing entity to define general purchasing rules for the entity as a whole.

In embodiments, the purchasing rules are general purchasing rules for a subsection of a purchasing entity, and adding purchasing rules applied to a purchasing group with metadata linked to the first transaction ID in a central database arrangement determines which purchasing group is Involves determining whether a subsection belongs to (involve).

In embodiments, the transaction information includes seller information (eg, the seller's name or code to identify the seller), and determining whether to approve or reject the purchase authorization request is further based on the seller information. This allows the purchasing entity to block purchases from selected suppliers/sellers and/or only allow purchases from selected suppliers/sellers.

In embodiments, the purchase rules specify that certain metadata should be added linked to the transaction ID in the central database arrangement before a purchase is made, and this metadata is linked to the transaction ID in the bank specific database module. This includes rejecting the purchase authorization request if it does not exist.

In embodiments, the information is transmitted from a central database arrangement to a payment card issuing entity, either directly or via a payment card management module in the bank, so that the payment card issuing entity issues payment cards to the purchasing entity. You may.

In embodiments, the central database arrangement and the bank specific database module are synchronized to be mirrored versions of each other. However, mirroring does not necessarily include all information in the database, and some metadata fields may be excluded from mirroring.

In embodiments, the central database arrangement is configured to communicate with a number of different parties, and the data format used by each of these different parties is preferably a single data format defined by the purchasing entity. Includes adapters that convert to a single data format.

The present invention is not limited in any way to the use of payment cards, but for transactions made using other means, such as smartphones or other devices using, for example, a QR, EAN or PIN code. also cover.

The term "bank" in this application means any payment service or financial institution that is authorized to accept and execute payment card payments or similar types of transactions. and, as such, are not limited to financial institutions or payment services that are formally defined and authorized as banks. In some jurisdictions, a payment service or financial institution must meet certain regulatory requirements to be covered by, for example, deposit insurance systems, and in those jurisdictions " The term "bank" may be reserved for payment services or financial institutions that meet these regulatory requirements. The term "bank" in this application is not limited in this way and covers any payment service or financial institution that is authorized to effect and accept payments of similar types of transactions or payment cards. Accordingly, the term “bank” in this application may cover credit card networks (eg, MasterCard or VISA) that take effect and authorize transactions. As used herein, the term "bank" refers to credit card networks (such as MasterCard or VISA) and payment services or financial institutions that are authorized to take effect and authorize payments or similar types of transactions on payment cards. It also covers co-operations between them.

The central processing means of the central database arrangement may be one central processing arrangement or a plurality of central processing arrangements in which signals are transmitted to each other. Some processing may occur, for example, within one central processing unit, and signals may be sent to one or more other central processing arrangements for further processing.

The bank processing means of the bank-specific database module may be any processing arrangement or processing arrangements in the banking system, and thus are not necessarily processing means specific to the bank-specific database module.

The modules in the bank may be physically separate modules through which information is transmitted, but may also be virtual modules implemented on the same server or simple software modules.

The scope of the invention is defined by the claims incorporated in this section by reference. A more complete understanding of embodiments of the present invention will be afforded to those skilled in the art, as well as realization of additional advantages thereof, by consideration of the following detailed description of one or more embodiments. Reference will first be made to the appended sheets of drawings which are briefly described.

1 schematically illustrates a purchase management system in accordance with one or more embodiments described herein.
2 schematically illustrates a purchase management system in accordance with one or more embodiments described herein.
3 schematically illustrates a purchase management system in accordance with one or more embodiments described herein.
4 is an exemplary flow diagram of a purchase management method in accordance with one or more embodiments described herein.
5 schematically illustrates a portion of a purchase management system in accordance with one or more embodiments described herein.
6 is an example of transaction approval information.
7 schematically illustrates a purchase management method in accordance with one or more embodiments described herein.
Embodiments of the present disclosure and their advantages are best understood by reference to the following detailed description. It should be understood that like reference numerals are used to identify like elements illustrated in one or more figures.

Various types of payment card processing models exist. The simplest model in which the merchant issues payment cards and has a direct relationship with the cardholder may be defined as the two corner model. In the two-corner model, the cardholder can only use the payment card with the merchant that issued it.

If the merchant does not wish to issue and process payment cards, a three corner model may be used, where a third party acts as an intermediary between the cardholder and the merchant. In the three-corner model, cardholders can only use their payment cards with designated merchants.

To provide more flexibility to cardholders, a four-corner model is commonly used for payment cards instead. In this model, the cardholder can use the payment card to pay any merchant that accepts the card, and the transaction goes through the payment card network (such as MasterCard or VISA) to the merchant bank and the cardholder. processed between banks.

When a payment card is used for payment, transaction authorization is made by the merchant bank, which sends a transaction authorization request to the cardholder bank via the payment card network. Such a transaction approval request may be composed of, for example, transaction approval information shown in FIG. 6 . The cardholder bank then performs a number of checks (eg related to card data, account balance, limits and behavior), and either approves or rejects the transaction.

According to the present invention, in addition to the normal transaction approval, the purchase approval request is added to the transaction approval process. The purchase authorization is effected by the cardholder bank at the same time the normal transaction authorization takes place. The merchant bank does not need to be involved in or provide information about the fact that purchase authorizations occur in addition to normal transaction authorizations. If the purchase is not authorized, the Merchant Bank will, although not necessarily whether this is due to, for example, checks related to card data, account balance, limits and behavior, or whether this is because the requested purchase does not meet the purchase rules, Receive information that the transaction was not approved.

According to the present invention, there is no need for suppliers/sellers to be configured in the purchase management system before a purchase is made, and the suppliers/vendors do not need to be linked to the purchase management system in any way. The present invention allows suppliers/sellers to send information about a purchase to a purchasing entity even if they are not connected in any way to a purchase management system, which is not possible in any prior art systems.

The present disclosure relates to purchase management systems and purchase management methods. Embodiments of the disclosed solution are presented in greater detail with reference to the drawings.

1 schematically illustrates a purchase management system 100 in accordance with one or more embodiments described herein. The purchase management system 100 is a bank specific database module configured to communicate with a central database arrangement 110 , a customer interface 120 to the central database arrangement 110 , and a transaction authorization module 520 within the cardholder bank 500 . 130 may be included. The central database arrangement 110 may be, for example, a cloud service. A bank-specific database module 130 may be configured within the cardholder bank 500 to enable fast response times to purchase authorization requests, and transaction information that is not permitted to be transmitted outside the bank's firewall for regulatory reasons. It may also allow the type to be added within the bank specific database module 130 as metadata linked to the first transaction ID. Although there are strict regulatory requirements for transaction information that is allowed to be transmitted and/or received from outside the bank, transaction information that is not allowed to be transmitted and/or received from outside the bank by configuring the bank's own database module 130 It may also be input to the bank specific database module 130 .

Central database arrangement 110 may be configured to receive purchasing rules from purchasing entity 200 via customer interface 120 . These purchasing rules may be general purchasing rules for the purchasing entity 200 as a whole, but they may also be specific to a specific subsection of the purchasing entity 200 or even be purchaser specific purchasing rules. The customer interface 120 may be, for example, a web interface or a mobile application.

Central processing means 115 of central database arrangement 110 may generate transaction IDs to be used for transactions. These transaction IDs may be generated one at a time or may be generated in a batch, based on predefined rules, or generated at the request of the purchasing entity 200 . Transaction IDs may be generated before any purchase rules are defined. Transaction IDs may require activation before use.

For each transaction ID, information about the intended purchaser may be added as metadata. An intended purchaser is defined as, for example, any purchaser within the purchasing group 300 . Purchasing group 300 may include one or more specific buyers, but may be defined as a subsection of purchasing entity 200 or as a whole of purchasing entity 200 , for example. All buyers of the purchasing group 300 need not be employed by the purchasing entity 200 , and the purchasing group 300 may, for example, hire consultants or sub-consultants to the purchasing entity 200 . include

Based on the metadata about the purchasing group 300 , the central processing means 115 of the central database arrangement 110 may identify purchasing rules that apply to this particular transaction ID, and assign these purchasing rules to the transaction ID. It can also be added as linked metadata. The buying rules are always the same for all buyers in the buying group 300 , but the buying groups 300 dynamically modify as a need arises for different buying rules for different buyers in the buying group. could be In this case, a new buying group 300 is simply formed for buyers who need different buying rules.

Other types of information related to the transaction may also be added as metadata linked to the transaction ID in the central database arrangement 110 . Entities other than the purchasing entity 200 may also access the central database arrangement 110 and may add metadata linked to the transaction ID. The addition of meta data to the central database arrangement 110 by third party entities 150 preferably using a specific third party interface 160 is illustrated in FIG. 2 . The third party interface 160 may be, for example, a web interface or a mobile application.

This third party entity 150 may be, for example, a customer of the purchasing entity 200 , and for the benefit of which the purchasing entity 200 makes a purchase for further invoicing to the customer. . In this case, the metadata may be, for example, an authorization to bear the purchase cost. It is advantageous if the client's invoicing can be simplified or automated when all the information necessary for the client's invoicing is then added as metadata linked to the transaction ID.

Another example of such a third-party entity 150 may 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 IDs, purchasing rules may define that purchases from the supplier/seller defined by this metadata are not allowed.

A further example of such a third party entity 150 is the seller/supplier 400 . If the merchant/supplier 400 is able to access the central database arrangement 110 and add metadata linked to the transaction ID, the vendor/supplier 400 can e.g. e.g. the metadata linked to the transaction ID. You can also add an electronic receipt. The vendor/supplier 400 may use a third party interface 160 or a specific interface to the vendor/supplier 400 . Such an interface may be, for example, a web interface or a mobile application. However, if the seller/supplier 400 does not have access to the central database arrangement 110 , the electronic receipt may be obtained by another party (eg, by a purchasing individual within the purchasing group 300 ). may be added.

Buyers in purchasing groups 300 may also communicate with central database arrangement 110 to retrieve information and/or add metadata. For example, if the purchasing entity 200 desires to use corporate payment cards for private purchases, the buyer can tag the purchase as a private purchase and the cost is automatically deducted, for example, from the next paycheck. There may be an option to make it deductible. Buyers in purchasing groups 300 may use a specific interface for purchasing groups 300 or a third party interface 160 . Such an interface may be, for example, a web interface or a mobile application.

Purchasing rules may require the purchaser to add specific metadata to the transaction ID before or after purchase, for example to simplify management within the purchasing entity 200 . The buyer may be requested to add, for example, an account, cost center, project or object as metadata linked to the transaction ID. Additional requests may then be applied to specific types of purchases based on metadata added by the purchaser. For example, if the purchase involves a representation, such as a restaurant visit with a customer, the buyer may be asked to add the names of the people present as metadata linked to the transaction ID. If the purchase involves business travel, the purchaser may be asked to specify a destination and/or purpose of travel. This may enable automatic accounting of invoices within the purchasing entity 200 . Purchasing rules may require adding this metadata for purchase approval. Where purchasing rules require the addition of this metadata, the purchaser may be warned that the purchase will be rejected if this metadata is not added prior to the purchaser's attempt to purchase. In this case this warning is preferably communicated to the buyer, for example via SMS, email or mobile application.

However, certain items of information cannot be added before the purchase is approved. The purchaser may be requested to add the receipt, for example, as metadata linked to the transaction ID (eg, by photographing the receipt using the mobile application). In these circumstances a purchase has already been made and cannot be rejected as such, but further purchases to the buyer may be blocked until the requested metadata has been added to all previous transactions. Such blocking may be made manually by the purchasing entity 200 . However, a purchase rule may specify that all additional purchases are automatically blocked, for example, after a certain time or a certain number of purchases for which this has not been completed.

Also, for certain suppliers/sellers, purchasing rules may specify how purchases are made. They only allow web-based purchases from certain suppliers, eg for cost reasons, in which case purchase attempts made in a physical shop will be rejected. In this case, the information on the reason for rejection is preferably delivered to the buyer through, for example, SMS, e-mail or a mobile application.

Meta data linked to the transaction ID may be transmitted to the bank specific database module 130 . As long as all metadata and purchasing rules applied to them are transmitted, not all metadata is necessarily transmitted to the bank-specific database module 130 . However, in one embodiment, all information in the central database arrangement 110 is mirrored to the bank-specific database module 130 .

When the bank-specific database module 130 receives the metadata linked with the transaction ID, a purchase authorization request may be sent from the transaction authorization module 520 in the cardholder bank 500 . The purchase authorization request includes transaction information, the transaction information being transmitted from the merchant bank to the cardholder bank 500 via the payment card network when the payment card is used for payment, and received at the transaction authorization module 520 . It may be the same as the transaction approval information. An example of such transaction approval information is shown in FIG. 6 . The transaction information in the purchase authorization request does not necessarily include all transaction authorization information as long as it includes an amount along with information sufficient to link to the desired transaction ID. If the purchase authorization request does not include a transaction ID, the transaction information may accordingly cause the bank unique database module 130 to link the purchase to the transaction ID (eg, transaction information identifying the purchasing group 300 ). It is necessary to include some other items of In the case where one or more specific payment cards are assigned to the purchasing group 300 , this transaction information may be, for example, a payment card number or a token of the payment card number. The bank processing means 135 of the bank specific database module 130 may then simply assign the purchase to the next available transaction ID for this group of purchases 300 .

The bank processing means 135 of the bank specific database module 130 then review whether the requested purchase meets the purchase rules linked to the transaction ID, ie the purchase rules applied to the purchase group 300 . In addition to the examples presented above, purchasing rules may include, for example, a maximum amount for each purchase, an aggregated amount, adherence to budget, or restrictions on where or when a purchase may be made (foreign purchases). or purchases during the weekend may be blocked, for example). Where the purchase authorization request includes seller information (eg, the seller's name or a code to identify the seller), the purchase rules may also relate to specific sellers allowed or blocked for the buying group 300 . . This may allow the purchasing entity 200 to block purchases from selected suppliers/sellers and/or only allow purchases from selected suppliers/sellers. Purchasing entity 200 may, for example, use this functionality to block purchases in liquor stores such as Systembolaget, or certain food chains such as ICA and/or Coop or food stores. You may only allow purchases from certain types of vendors.

Accordingly, the bank processing means 135 of the bank specific database module 130 approve or reject the purchase authorization request based on whether the requested purchase meets the purchase rules linked to the transaction ID in the bank specific database module 130 . do. The bank processing means 135 of the bank specific database module 130 also adds the transaction information received from the transaction approval modules 520 as metadata linked to the transaction ID in the bank specific database module 130, and The transaction information is sent to the central database arrangement 110, where it is added as metadata linked to the transaction ID. This may occur before or after the grant/reject is sent to the transaction approval module 520 .

The transaction information is preferably “translated” or converted by the function of the central database arrangement 110 into another data format, preferably a data format defined by the purchasing entity 200 . This is further explained below with reference to FIG. 5 hereinafter.

Transaction approval module along with general transaction approval performed, for example, by checking card data, account balance, limits and actions based on approvals/rejections received from the bank processing means 135 of the bank specific database module 130 . 520 approves or rejects the transaction. If the bank processing means 135 of the bank specific database module 130 reject the transaction, the transaction authorization module 520 even shows that general transaction authorization checks are acceptable ( even if) will reject the transaction. Likewise, if the general transaction approval checks indicate that the transaction is not accepted, the transaction approval module 520 will reject the transaction even if the bank processing means 135 of the bank specific database module 130 approve the purchase. In such situations, the transaction approval module 520 may not send the purchase approval request to the bank specific database module 130 because the transaction will be rejected anyhow.

When the general transaction approval is performed in the transaction approval module 520 before the purchase approval request is sent to the bank specific database module 130, the bank processing means 135 of the bank specific database module 130 are configured with the bank specific database module ( When the bank processing means 135 of 130 determines whether to approve or reject the purchase authorization request, the transaction approval module 520 may determine whether to approve or reject the transaction. Alternatively, the transaction approval module 520 may send this information to the bank specific database module 130 . Information on whether the transaction has been approved or rejected by the transaction approval module 520 may be added as metadata linked to the transaction ID in the bank unique database module 130 .

Other types of information may also be added as metadata linked to the transaction ID within the bank specific database module 130 . Bank 500 may provide information about suspected fraud, transaction status or other similar types of information to bank specific database module 130 , for example, so that the information may be transmitted to central database arrangement 110 . .

When the central database arrangement 110 receives the transaction information as metadata linked to the transaction ID, the central processing means 115 of the central database arrangement 110 are preferably in the data format defined by the purchasing entity 200 . Transaction information may be transmitted to the purchasing entity 200 . This allows transaction information to be automatically entered into the economic systems and/or other management systems of the purchasing entity 200 . In this way the purchasing entity may follow-up on all transactions long before receiving any invoices from suppliers/sellers. This allows the purchasing entity 200 to always keep track of its budget and adjust its purchasing rules accordingly.

Purchasing rules may apply for a variety of reasons. Although a particular subsection of the purchasing entity 200 is considered one purchasing group 300, purchases made for specific buyers within this subsection to add more restrictions (or block all purchases) for specific buyers. If it is desirable to adjust the rules, a new buying group 300 may be created for this buyer with more restrictive purchasing rules than the rest of the subsections. Accordingly, both the purchasing groups 300 and the purchasing rules may be dynamically updated by the purchasing entity 200 .

The purchasing entity 200 does not necessarily define the actual purchasing groups in the system. Instead, the purchasing entity 200 defines purchasing rules at, for example, several hierarchical levels. Some rules are general to the whole organization, while other rules may be limited to groups of individuals or to a few individuals. In the context of this application, a buying group 300 is a group of one or more buyers to which the same buying rules apply.

Fields in the central database arrangement 110 that allow the purchasing entity 200 to be linked to the transaction ID so that the purchasing entity 200 can define the desired metadata and data format for this metadata are also provided by the purchasing entity. (200) can be set dynamically. This allows metadata about, for example, cost centers, accounts and other invoice information to be linked to transaction IDs in the central database arrangement 110 . This allows the purchasing entity 200 to define the metadata it would like to receive and the format it would like to receive, so that this metadata could be retrieved from the central database arrangement 110 and added to the electronic invoice. . This electronic invoice may be transmitted from the bank 500 , the central database arrangement 110 , or a third party. If the invoice for transactions made using the system 100 is an electronic invoice that includes metadata specified by the purchasing entity 200 , this facilitates automated handling of the invoice by the purchasing entity 200 . This enables significant savings in administrative workload.

The present invention may use payment cards, for example, to make a payment. In this case, information on the purchasers may be transmitted from the central database arrangement 110 to the payment card issuing entity 600 as shown in FIG. 3 . This transfer may occur directly between the central database arrangement 110 and the payment card issuing entity 600 or may be effected via the payment card management module 510 in the bank 500 . The payment card issuing entity 600 may be linked to the bank 500 , but may also be a separate payment card issuing entity 600 .

In order to link to buyers purchasing a payment made with payment cards, information about payment cards is preferably provided either directly from the payment card issuing entity 600 to the central database arrangement 110 or via the payment card management module 510 . is transmitted through The information is preferably not actual credit card numbers, as there may be restrictions on whether it can be stored as metadata linked to the transaction ID in the central database arrangement 110 . The information may instead be tokens for, for example, credit card numbers.

4 is an exemplary flow diagram of a purchase management method in accordance with one or more embodiments described herein. The flow is as follows:

Step 410: The purchasing entity 200 constructs its purchasing rules in a central database arrangement 110 (this may occur at any point prior to step 460, and the metadata may be stored at any point during the flow). may be added by purchasing entity 200).

Step 415 : The central database arrangement 110 orders the card account for the purchasing entity 200 from the cardholder bank 500 .

Step 420 : The cardholder bank 500 orders payment cards from the payment card issuing entity 600 .

Step 425 : Additional information such as personalization (logos, cards, etc.) may be provided to the payment card issuing entity 600 from the central database arrangement 110 . The payment card may also be ordered directly by the payment card issuing entity 600 from the central database arrangement 110 .

Step 430 : A payment card is sent from the payment card issuing entity 600 to the purchasers 300 (distribution may include the purchasing entity 200 ).

Step 435 (optional): Buyers 300 add metadata related to the purchase to central database arrangement 110 via a user interface (this may occur at any point during the flow).

Step 440 : The transaction ID and meta data linked to such as purchase rules are sent from the central database arrangement 110 to the bank specific database module 130 .

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

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

Step 455: Merchant bank 550 requests cardholder bank 500 via a payment card network (eg, such as VISA or MasterCard) to approve the transaction.

Step 460 : The cardholder bank 500 requests a purchase authorization from the bank specific database module 130 .

Step 465 : The bank specific database module 130 sends a purchase authorization to the cardholder bank 500 .

Step 470 : Cardholder bank 500 sends a transaction authorization to merchant bank 550 .

Step 475 : Merchant bank 550 sends a transaction authorization to merchant/supplier 400 .

Step 480: The bank specific database module 130 sends transaction information regarding the authorized purchase to the central database arrangement 110 (this may occur at any point after step 460).

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

Step 490 (optional): A third party adds metadata to the transaction (this may occur at any point in the flow).

5 schematically illustrates a portion of a purchase management system 100 in accordance with one or more embodiments described herein. The central database arrangement 110 preferably uses a dynamic configuration of “meta data carriers” that allows the meta data to be linked to transaction IDs, so that the purchasing entity 200 can store the desired meta data and this You can also define formats for metadata. As described above with respect to FIGS. 1-3 , the central database arrangement 110 may host a number of different parties (eg, purchasing entities 200 , buyers or groups of buyers 300 , sellers). /providers 400 , cardholder banks 500 , payment card issuing entities 600 , and various other third party entities 150 ). In order for the central database arrangement 110 to be able to gather data from and transmit data to and from these parties, the central database arrangement 110 is functionally e.g. For example, in the form of "adapters", "translate" its data format used by each of these different parties into one single data format (preferably the data format defined by the purchasing entity 200 ). or need to be converted. Because different parties typically use different data formats, the central database arrangement 110 provides for each party 200, 300, 400, 500, 600, 150 a specific adapter 205, 305, 405, 505, 605, 155) (if there are multiple different third parties 150, typically multiple different adapters 155 are required). This allows the purchasing entity 200 to define the data format of this metadata as well as the metadata it wishes to receive from different parties.

Use case

The following use cases are provided to further illustrate the present invention. The purchasing entity Acompany consists of subsections Service, Development, Sales and Administration. Acompany defines its purchasing policies and rules for central database arrangement 110 via customer interface 120 , and orders payment cards for all buyers from bank Cardbank. Some of the purchasing individuals have personal payment cards, while others have joint payment cards.

Acompany defines its subsection Service as a purchasing group Service where the same purchasing rules apply to all personnel. Because service personnel must be able to travel extensively and in short notice to provide immediate service for faulty equipment, all purchasers within the purchasing group Service must use a personal payment card. , and the purchasing rules for the purchasing group Service have very few restrictions. However, Acompany may follow up all purchases to the Service budget and adjust purchasing rules over time due to budgetary constraints.

Acompany defines its subsection Development as a purchasing group Development with even more restrictions. The Development workforce consists of Acompany employees and consultants. Development Personnel shall not be permitted to make purchases not previously approved by the Development manager. Some of the Development personnel have individual payment cards, but there are several collective payment cards for the purchasing group Development.

Acompany defines the subsection Sales as two different purchasing groups: LocalSales and WorldwideSales. Purchasing group LocalSales generally does not travel abroad, so purchasing rules may be limited to domestic purchases. The buying group WorldwideSales, on the other hand, travels extensively, so it may have far fewer restrictions on buying rules. However, purchase rules may state that pre-approval is required, for example, if Acompany chooses a hotel that is not on the list of hotel chains and hotels with which it has negotiated rates. . All sales personnel have personal payment cards.

Acompany defines the subsection Administration as the purchasing group Administration. Administration personnel should be able to make minor purchases, such as office supplies and lunches, so purchasing rules may be limited, for example, on amounts and suppliers. Purchasing group Administration has a joint payment card.

When a service employee attempts a purchase with a payment card, the merchant bank sends a transaction authorization request to Cardbank, for example, via the payment card network including the transaction authorization information shown in FIG. 6 . Cardbank's transaction authorization module 520 receives the transaction authorization request and performs a number of checks regarding, for example, card data, account balance, limits and behavior. When Cardbank's transaction approval module 520 decides to approve the transaction based on these checks, it sends a purchase authorization request to the bank's proprietary database 130 within Cardbank where the transaction IDs are stored with metadata linked to them. do.

Because the service employees all have the same purchasing rules, the bank specific database 130 may assign the purchase to the next available transaction ID in the database tagged for the purchasing group Service. . It may be determined in this case that the purchase is related to the purchase group Service, for example using a payment card number. However, a particular transaction ID may have already been picked up by a service employee who may have already added metadata linked to this transaction ID. The purchase rules for the Service Person are stored as metadata linked to the transaction ID, so that the bank specific database 130 approves or rejects the requested purchase based on whether it meets the Service purchase rules. Most purchases are allowed because there are very few restrictions on the service purchase rules. The bank specific database 130 stores the transaction information as metadata linked to the transaction ID, and transmits the metadata to the central database arrangement 110 . The central database arrangement 110 transmits transaction information to Acompany so that information about purchases can be automatically entered into Acompany's economic and other management systems.

For purchases made by Development personnel, a similar flow is followed. However, since development personnel are not allowed to make any purchases that have not been approved in advance by the development manager, prior approval is required. Development personnel wishing to make a purchase use the interface designed for purchasing groups 300 (eg, a web interface or mobile application) to obtain a transaction ID, and metadata requested in connection with this purchase. is input to the central database arrangement 110 through the interface. An action is then established that pre-approves this purchase by the Development Manager. This may simply be a task defined within the system, but a reminder may also be automatically sent to the manager, for example via SMS or e-mail. If the development manager approves the purchase, the purchasing rules will allow it.

A similar flow is followed when a sales employee makes a purchase. As for service personnel, there are very few restrictions on the purchasing group WorldwideSales. However, it may be desirable to change the purchasing rules for an individual or group of individuals within WorldwideSales, for example, if the cause turns out to be too extravagant. For example, a new buying group with more restrictions on the cost of the representation is defined so that the old buying group WorldwideSales is, for example, two groups WorldwideSalesStandard and WorldwideSalesRestricted.

A similar flow is followed for purchases made by Administration personnel. However, Administration personnel have much stricter purchasing rules, for example, with restrictions on allowed suppliers/sellers. The transaction information sent from Cardbank's transaction approval module 520 also includes merchant information, eg, the name of the merchant or a code for identifying the merchant, so that the bank's unique database 130 stores the merchant information in the purchase rules. It can also be compared with acceptable vendors according to Administration personnel may be limited to specific suppliers/vendors (eg, such as ICA and/or Coop) or specific merchant types (eg, grocery stores). The VISA merchant category classification is, for example, “Misc. Use MCC code 5498 for “Food Stores - Convenience Stores and Specialty Markets”, and this code is included in the Merchant Identification Code of Transaction Authorization Information. When Administration personnel purchase food from a grocery store, a number of different VAT levels may apply to different types of goods. Different VAT levels for different items of purchase may then be automatically stored as metadata linked to the transaction ID to simplify management within the purchasing entity 200 .

Method Examples

7 schematically illustrates a purchase management method 700 in accordance with one or more embodiments described herein. Method 700 may include:

Step 710 : Input the purchasing rules applied to the purchasing group 300 into the central database arrangement 110 through the customer interface 120 .

Step 720 : Add the selected purchase group 300 as metadata linked to the first transaction ID in the central database arrangement 110 .

Step 725 : Add the purchasing rules applied to the purchasing group 300 in the central database arrangement 110 as metadata linked to the first transaction ID.

Step 730 : Transmit the metadata linked to the first transaction ID from the central database arrangement 110 to the bank specific database module 130 .

Step 740: In the transaction approval module 520 configured in the bank 500, receive a first transaction approval request linked to a first transaction ID, wherein the first transaction approval request includes transaction approval information.

Step 750: A purchase approval request is transmitted from the transaction approval module 520 to the bank specific database module 130, and the purchase approval request includes transaction information including at least a purchase amount.

Step 760 : Determine to approve or reject the purchase authorization request based on whether the purchase meets the purchase rules linked to the first transaction ID of the bank unique database module 130 .

Step 765: Respond to transaction approval module 520 with approval or rejection of the purchase approval request.

Step 770: from the transaction approval module 520, respond to the first transaction approval request linked to the first transaction ID.

Step 780: Add the transaction information received from the transaction approval module 520 in the bank specific database module 130 as metadata linked to the first transaction ID.

Step 785 : Send the transaction information linked to the first transaction ID to the central database arrangement 110 .

Step 790: the purchasing entity 200 with the transaction information linked to the first transaction ID, such that the transaction information for the purchase is automatically entered into at least one administrative system of the purchasing entity 200 send to

In embodiments, the bank specific database module 130 is configured within the bank 500 . This provides a fast response time to purchase authorization requests, and also types of transaction information that are not permitted to be transmitted outside the bank firewall for regulatory reasons into metadata linked to the first transaction ID within the bank unique database module 130 . may be allowed to be added. Although there are strict regulatory requirements for transaction information that are allowed to be transmitted and/or received outside the bank, by configuring the bank's own database module 130 inside the bank, and also transmitting and/or outside the bank. Transaction information that is not permitted to be received from the outside may be input into the bank-specific database module 130 .

In embodiments, the purchasing group includes at least one purchasing individual. This enables purchasing rules to be defined and applied for one or more specific buyers or subsections of a purchasing entity comprising one or more buyers.

In embodiments, a purchasing group includes the entire purchasing entity. This allows the purchasing entity to define general purchasing rules for the entity as a whole.

In embodiments, the purchasing rules are general purchasing rules for a subsection of the purchasing entity 200 , and the purchasing rules applied to the purchasing group 300 in the central database arrangement 110 are meta linked to the first transaction ID. Adding with data 725 includes determining which subsection the purchasing group 300 belongs to.

In embodiments, the transaction information includes merchant information, and determining 760 to approve or reject the purchase authorization request is further based on the merchant information.

In embodiments, the purchase rules specify that certain meta data should be added linked to the transaction ID in the central database arrangement 110 before a purchase is made, and the step 760 of determining the purchase authorization request includes: and rejecting the purchase authorization request if the data does not exist linked to the transaction ID in the bank unique database module 130 .

In embodiments, transmitting 730 the metadata linked to the first transaction ID from the central database arrangement 110 to the bank specific database module 130, and transferring the transaction information linked to the first transaction ID to the central database Transmitting 785 to arrangement 110 includes synchronizing central database arrangement 110 and bank specific database module 130 to be mirrored versions of each other.

In embodiments, the central database arrangement 110 is configured to communicate with a number of different parties 200 , 300 , 400 , 500 , 600 , 150 , and purchase entities in a data format used by each of the different parties. adapters 205 , 305 , 405 , 505 , 605 , 155 for converting into one single data format including the data format defined by 200 .

Method 700 may further include:

Step 705 : directly or via the payment card management module 510 in the bank 500 , such that a payment card issuing entity 600 issues payment cards to the purchasing entity 200 ; It transmits information from the central database arrangement 110 to the payment card issuing entity 600 .

The foregoing disclosure is not intended to limit the invention to the precise forms disclosed or to the specific fields of use. It is contemplated that various alternative embodiments and/or modifications to the invention, whether expressly described or implied herein, are possible in light of the present disclosure. In this disclosure, an embodiment of the invention using payment cards has been described. However, the present invention is not limited to embodiments using a payment card, but also includes other payment methods such as payment using a smartphone or other device using, for example, a QR, EAN or PIN code. Accordingly, the scope of the invention is defined solely by the claims.

Additionally, not all steps of the claims need be performed in the order listed. For example, purchase rules do not need to be input to the central database arrangement 110 prior to generation of the transaction ID. Additionally, when the purchasing entity 200 modifies the purchase rules and inputs new purchase rules into the central database arrangement 110 , the metadata related to the purchase rule linked to the transaction ID in the central database arrangement 110 may be updated. , and may be sent to the bank specific database module 130 until the purchase authorization request is approved or rejected for the transaction ID. In another example, the transaction information may be added as metadata linked to the transaction ID before or after approval/rejection of the purchase authorization request. All technically meaningful orders of steps are covered by the claims.

Claims (20)

As a purchase management system (100), the purchase management system (100),
to communicate with a central database arrangement 110 , a customer interface 120 to the central database arrangement 110 and a transaction authorization module 520 in the bank 500 . a configured bank specific database module 130; and
The central database arrangement 110 is configured to receive purchasing rules applied to a purchasing group 300 from a purchasing entity 200 via the customer interface 120; and central processing means (115), said central processing means (115) comprising:
adding a purchase group 300 selected as metadata linked to a first transaction ID in the central database arrangement 110;
adding the purchasing rules applied to the purchasing group (300) with metadata linked to the first transaction ID in the central database arrangement (110); And
arranged to transmit metadata linked to the first transaction ID to the bank specific database module (130);
The bank specific database module 130 may be configured to receive a purchase approval request from the transaction approval module 520 , wherein the purchase approval request is linked to the first transaction ID. amount), and includes bank processing means 135 , wherein the bank processing means 135 include:
determine to approve or reject the purchase authorization request based on whether the requested purchase meets the purchase rules linked to the first transaction ID of the bank unique database module (130);
respond to the transaction approval module 520 with the approval or rejection of the purchase approval request;
adding the transaction information received from the transaction approval module (520) as metadata linked to the first transaction ID of the bank unique database module (130); And
and send the transaction information linked to the first transaction ID to the central database arrangement (110);
The central processing means 115 of the central database arrangement 110 are further configured to transmit the transaction information linked to the first transaction ID to the purchasing entity 200 so that the transaction information for a purchase is to be automatically entered into at least one administrative system of the entity 200,
Purchasing Management System (100).
The method of claim 1,
The bank specific database module 130 is configured in the bank 500,
Purchasing Management System (100).
3. The method according to claim 1 or 2,
wherein the purchasing rules are purchasing rules applied to a purchasing group 300 comprising at least one purchasing individual;
Purchasing Management System (100).
The method of claim 1,
The purchasing rules are purchasing rules applied to the purchasing group 300 including the entire purchasing entity 200,
Purchasing Management System (100).
The method of claim 1,
the purchasing rules are general purchasing rules for a subsection of the purchasing entity 200, and
The central processing means 115 of the central database arrangement 110,
Add the purchasing rules applied to the purchasing group 300 as metadata linked to the first transaction ID of the central database arrangement 110 based on determining the subsection to which the purchasing group 300 belongs composed,
Purchasing Management System (100).
The method of claim 1,
The transaction information includes merchant information, and
the bank processing means (135) of the bank specific database module (130) are configured to determine to approve or reject the purchase authorization request further based on the seller information;
Purchasing Management System (100).
The method of claim 1,
The purchase rules are:
specify that, before a purchase is made, certain metadata should be added by linking to the transaction ID of the central database arrangement 110; and
The bank processing means 135 of the bank specific database module 130 are,
configured to reject the purchase authorization request if the metadata does not exist linked to the transaction ID in the bank specific database module (130).
Purchasing Management System (100).
The method of claim 1,
The central processing means 115 of the central database arrangement 110,
further configured to transmit information via a payment card management module 510 in the bank 500 or directly to a payment card issuing entity 600 that issues payment cards to the purchasing entity 200 ,
Purchasing Management System (100).
The method of claim 1,
The system is
The central database arrangement 110 and the bank specific database module 130 are configured to be synchronized to be mirrored versions of each other,
Purchasing Management System (100).
The method of claim 1,
the central database arrangement 110 is configured to communicate with a number of different parties 200 , 300 , 400 , 500 , 600 , 150 , and
adapters 205, 305, 405, 505, which convert the data format used by each of the different parties into one single data format comprising the data format defined by the purchasing entity 200; 605, 155);
Purchasing Management System (100).
A purchase management method (700) comprising:
inputting ( 710 ) purchasing rules applied to the purchasing group ( 300 ) to the central database arrangement ( 110 ) via the customer interface ( 120 );
adding ( 720 ) the selected purchase group ( 300 ) as metadata linked to a first transaction ID in the central database arrangement ( 110 );
adding (725) the purchasing rules applied to the purchasing group (300) in the central database arrangement (110) as metadata linked to the first transaction ID;
transmitting (730) the metadata linked to the first transaction ID from the central database arrangement (110) to a bank-specific database module (130);
receiving (740), at a transaction approval module (520) configured in a bank (500), a first transaction approval request linked to the first transaction ID, wherein the first transaction approval request includes transaction approval information;
transmitting (750) a purchase approval request from the transaction approval module (520) to the bank specific database module (130), wherein the purchase approval request includes transaction information including at least a purchase amount;
determining (760) to approve or reject the purchase authorization request based on whether the requested purchase meets the purchase rules linked to the first transaction ID of the bank unique database module (130);
responding (765) to the transaction approval module with the approval or rejection of the purchase approval request;
responding (770) from the transaction approval module (520) to the first transaction approval request linked to the first transaction ID;
adding (780) the transaction information received from the transaction approval module (520) as metadata linked to the first transaction ID in the bank specific database module (130);
sending (785) the transaction information linked to the first transaction ID to the central database arrangement (110); and
The transaction information linked to the first transaction ID is transferred to the purchasing entity 200 such that the transaction information for a purchase is automatically entered into at least one administrative system of the purchasing entity 200 . sending 790 to ;
containing,
Purchasing Management Method (700).
12. The method of claim 11,
The bank specific database module 130 is configured in the bank 500,
Purchasing Management Method (700).
13. The method according to claim 11 or 12,
The purchasing group 300 includes at least one buyer (purchasing individual),
Purchasing Management Method (700).
12. The method of claim 11,
The purchasing group 300 includes the entire purchasing entity 200 ,
Purchasing Management Method (700).
12. The method of claim 11,
the purchasing rules are general purchasing rules for a subsection of the purchasing entity 200, and
Adding (725) the purchasing rules applied to the purchasing group (300) in the central database arrangement (110) as metadata linked to the first transaction ID (725),
determining which subsection the purchasing group (300) belongs to (involve),
Purchasing Management Method (700).
12. The method of claim 11,
The transaction information includes seller information, and
Step 760 of determining whether to approve or reject the purchase approval request,
additionally based on seller information;
Purchasing Management Method (700).
12. The method of claim 11,
the purchase rules specify that certain metadata should be added in the central database arrangement 110 linked to the transaction ID before a purchase is made, and
Step 760 of determining the purchase approval request,
Rejecting the purchase authorization request if the metadata does not exist in the bank unique database module (130) linked to the transaction ID,
Purchasing Management Method (700).
12. The method of claim 11,
The central database, either directly or via a payment card management module 510 in the bank 500 , such that a payment card issuing entity 600 issues payment cards to the purchasing entity 200 . sending (705) information from the arrangement (110) to the payment card issuing entity (600);
further comprising,
Purchasing Management Method (700).
12. The method of claim 11,
transmitting (730) the metadata linked to the first transaction ID from the central database arrangement 110 to the bank specific database module 130, and transferring the transaction information linked to the first transaction ID to the central database The step 785 of sending to the database arrangement 110 is,
The central database arrangement 110 and the bank-specific database module 130 are synchronized to be mirrored versions of each other (synchronized);
containing,
Purchasing Management Method (700).
12. The method of claim 11,
the central database arrangement 110 is configured to communicate with a number of different parties 200 , 300 , 400 , 500 , 600 , 150 , and
Adapters 205 , 305 , 405 , 505 , 605 , 155 that convert the data format used by each of the different parties into one single data format comprising the data format defined by the purchasing entity 200 . ) containing,
Purchasing Management Method (700).

Images