购买管理系统和方法与流程

本公开总体上涉及购买管理系统和方法。

背景

us7319986描述了一种动态支付卡管理系统，在该系统中可以动态修改卡控制设置，以便可以通过可配置的公司购买策略和规则的应用来动态地管理批准参数。

us7319986中描述的系统以购买请求的使用为中心。没有特定的购买请求的情况下，无法进行购买，尽管在某些情况下通过系统可能合成购买请求。购买请求的使用简化了公司内的批准流程。

现有技术的问题

在us7319986中描述的系统中，可以通知客户交易已经发生，但是由于该系统以购买请求的使用为中心，因此在购买时无法将购买的详细信息转移到公司的经济系统中。因此，直到公司从供应商接收到发票后，公司才会收到购买的详细信息。

此外，us7319986中描述的系统是整个卡处理系统，旨在替换现有的支付基础设施。

因此，需要一种改进的购买管理系统。

概要

以购买请求的使用为中心的购买管理系统简化了公司内的批准流程，但是由于购买请求是在公司内部管理的，因此外部各方无法添加信息(诸如有关已完成的购买的详细信息)到购买请求。

根据本发明，可以由系统的任何一方访问的数据库反而被用于存储有关购买的信息。数据库装置优选地包括将由系统的不同方使用的数据格式“翻译”为一个单一的数据格式的功能，因为这使得不同方更容易添加关于购买的信息。

本公开涉及购买管理系统和购买管理方法，其中购买实体可以从供应商/商家购买商品和服务。现有技术的系统不能使来自这种购买的交易信息自动地输入到购买实体的经济系统和其他管理系统中。本发明通过以现有技术的系统不能做到的方式收集来自系统的各方的信息来实现这一点。

所要求保护的购买管理系统可以包括中央数据库装置、到中央数据库装置的顾客界面以及银行特定的数据库模块，该银行特定的数据库模块被布置为与银行内的交易授权模块通信。中央数据库装置可以被布置为通过顾客界面从购买实体接收应用于购买组的购买规则。中央数据库装置可以包括中央处理装备，该中央处理装备被布置为：将所选择的购买组作为链接到中央数据库装置中的第一交易id的元数据添加；将应用于所述购买组的购买规则作为链接到中央数据库装置中的第一交易id的元数据添加；并将链接到第一交易id的元数据转移到银行特定的数据库模块。银行特定的数据库模块可以被布置为从交易授权模块接收购买批准请求，该购买批准请求包括链接到第一交易id的交易信息，该交易信息至少包括购买金额。银行特定的数据库模块可以包括银行处理装备，该银行处理装备被布置成：基于所请求的购买是否满足链接到银行特定的数据库模块中的第一交易id的购买规则，通过批准或拒绝购买批准请求来决定购买批准请求；用对购买批准请求的批准或拒绝响应交易授权模块；将从交易授权模块接收的交易信息作为链接到银行特定的数据库模块中的第一交易id的元数据添加；并将链接到第一交易id的交易信息转移到中央数据库装置。中央数据库装置的中央处理装备可以进一步被布置成将链接到第一交易id的交易信息转移到购买实体，从而可以将关于购买的信息自动地输入到购买实体的至少一个管理系统中。这使来自购买的对交易信息的简化收集以及将该交易信息转换为由购买实体使用的数据格式成为可能，从而可以将交易信息自动地输入到购买实体的经济系统和其他管理系统中。

所要求保护的购买管理方法可以包括：通过顾客界面向中央数据库装置输入适用于购买组的购买规则；将所选择的购买组作为链接到中央数据库装置中的第一交易id的元数据添加；将适用于所述购买组的购买规则作为链接到中央数据库装置中的第一交易id的元数据添加；将链接到第一交易id的元数据从中央数据库装置转移到银行特定的数据库模块；在被布置在银行内的交易授权模块中，接收链接到第一交易id的第一交易授权请求，该第一交易授权请求包括交易授权信息；将购买批准请求从交易授权模块传达到银行特定的数据库模块，该购买批准请求包括交易信息，该交易信息至少包括购买金额；基于所请求的购买是否满足链接于银行特定的的数据库模块中的第一个交易id的购买规则，通过批准或拒绝购买批准请求来决定购买批准请求；用批准或拒绝购买批准请求来响应交易授权模块；从交易授权模块响应链接到第一交易id的第一交易授权请求；将从交易授权模块接收到的交易信息作为链接到银行特定的数据库模块中的第一交易id的元数据添加；将链接到第一交易id的交易信息转移到中央数据库装置；以及将链接到第一交易id的交易信息转移给购买实体，以使关于购买的信息可以自动地输入到购买实体的至少一个管理系统中。这使来自购买的对交易信息的简化收集以及将该交易信息转换为由购买实体使用的数据格式成为可能，从而可以将交易信息自动地输入到购买实体的经济系统和其他管理系统中。

在实施例中，银行特定的数据库模块布置在银行内。“银行内”的定义是指银行内的模块位于银行系统内，在银行的防火墙后面，因此模块之间转移的信息永远不会发送到银行的防火墙之外。这样能够使对于购买批准请求的快速响应时间成为可能，以及还允许将由于监管原因不允许发送到银行防火墙之外的交易信息的类型作为链接到银行特定的数据库模块中的第一交易id的元数据添加。对于允许从银行外部接收和/或发送到银行外部的交易信息有严格的监管要求，但是通过将银行特定的数据库模块布置在银行内，不允许从银行外部接收/或发送到银行的外部的交易信息也可以被输入到银行特定的数据库模块中。

在实施例中，购买组包括至少一个购买个体。这使得可以为一个或多个特定的购买个体或包括一个或多个购买个体的购买实体的子部分定义购买规则并且使购买规则适应于其。

在实施例中，购买组包括整个购买实体。这使购买实体能够为整个实体定义通用购买规则。

在实施例中，购买规则是针对购买实体的子部分的通用购买规则，并且将应用到购买组的购买规则作为链接到中央数据库装置中的第一交易id的元数据的添加涉及确定购买组属于哪个子部分。

在实施例中，交易信息包括商家信息，例如商家的名称或用于识别商家的代码，并且通过批准或拒绝购买批准请求而对购买批准请求的决定是进一步基于商家信息。这使得购买实体能够阻止来自所选择的供应商/商家的购买和/或仅允许从所选择的供应商/商家的购买。

在实施例中，购买规则指定在进行购买之前必须已经添加某些元数据链接到中央数据库装置中的交易id，以及如果不存在该元数据链接到银行特定的数据库模块中的交易id则对购买批准请求的决定包括拒绝购买批准请求。

在实施例中，信息直接地或经由银行内的支付卡管理模块从中央数据库装置转移到支付卡发行实体，使得支付卡发行实体可以将支付卡发行给购买实体。

在实施例中，中央数据库装置和银行特定的数据库模块被同步为彼此的镜像版本。但是，镜像不一定包含数据库中的所有信息-某些元数据字段可能会从镜像中排除。

在实施例中，中央数据库装置被布置成与多个不同方通信，并且包括适配器，其将由这些不同方中的每一个所使用的数据格式转换成一个单一的数据格式，优选地，由购买实体定义的数据格式。

本发明不以任何方式受限制于支付卡的使用，而是还涵盖了使用诸如智能手机或其他设备(例如，使用qr码、ean码或pin码)之类的其他装备进行的交易。

在本申请中，术语“银行”是指被授权批准并进行支付卡付款或类似类型的交易的任何支付服务或金融机构，因此不仅指正式定义并授权为银行的支付服务或金融机构。在某些管辖范围中，支付服务或金融机构必须满足某些监管要求以被例如存款保险制度所覆盖，在那些管辖范围中，术语“银行”可能是为满足这样的监管要求的支付服务或金融机构而保留的。在本申请中，术语“银行”不限于这种方式，而是涵盖被授权批准并进行支付卡支付或类似类型的交易的任何支付服务或金融机构。因此，本申请中的术语“银行”还可以涵盖批准并进行交易的诸如例如万事达信用卡(mastercard)或visa的信用卡网络。本申请中的术语“银行”还涵盖信用卡网络(例如，mastercard或visa)与被授权批准并进行支付卡支付或类似类型的交易的支付服务或金融机构之间的合作。

中央数据库装置的中央处理装备可以是一个中央处理装置，或者是在其间传输信号的多个中央处理装置。某些处理可以例如在一个中央处理装置中发生，然后可以将信号传输到一个或多个其他中央处理装置以进行进一步处理。

银行特定的数据库模块的银行处理装备可以是银行系统内的任何一个处理装置或多个处理装置，因此不一定是特定于银行特定的数据库模块的处理装备。

银行中的模块可以是在其间发送信息的物理上单独的模块，也可以是在同一服务器上实现的虚拟模块，或仅仅是软件模块。

本发明的范围由权利要求书限定，该权利要求书通过引用结合到本部分中。通过考虑以下对一个或多个实施例的详细描述，将向本领域技术人员提供对本发明的实施例的更全面的理解，以及本发明的附加优点的实现。将对将首先简要描述的附图进行参考。

附图的简要说明

图1示意性地示出了根据本文描述的一个或多个实施例的购买管理系统。

图2示意性地示出了根据本文描述的一个或多个实施例的购买管理系统。

图3示意性地示出了根据本文描述的一个或多个实施例的购买管理系统。

图4是根据本文描述的一个或多个实施例的购买管理方法的示例流程图。

图5示意性地示出了根据本文所述的一个或多个实施例的购买管理系统的一部分。

图6是交易授权信息的示例。

图7示意性地示出了根据本文所述的一个或多个实施例的购买管理方法。

通过参考下面的详细描述，将最好地理解本公开的实施例及其优点。应当理解，相似的附图标记用于标识在一个或多个附图中示出的相似的元件。

详细说明

有许多不同类型的支付卡处理模型。最简单模型(其中商家发行支付卡并且与持卡人有直接关系)可以定义为两个角模型。在两角模型中，持卡人只能在发行商处使用支付卡。

如果商家不希望发行和处理支付卡，则可以使用三角模型，其中第三方充当在持卡人和商家之间的中间人。在三角模型中，持卡人仍只能在指定商家处使用支付卡。

为了给持卡人提供更大的灵活性，通常替代地将四角模型用于支付卡。在这样的模型中，持卡人可以使用支付卡向接受该卡的任何商家付款，并且经由诸如mastercard或visa的支付卡网络在商家的银行和持卡人的银行之间处理交易。

当使用支付卡进行支付时，由商家的银行通过支付卡网络向持卡人的银行发送交易授权请求来实现交易授权。这样的交易授权请求可以例如包括图6所示的交易授权信息。然后，持卡人的银行执行许多检查，例如有关卡数据、账户余额、限额和行为的检查，并批准或拒绝交易。

根据本发明，除了一般交易授权之外，将购买批准请求添加到交易授权过程中。当一般交易授权发生时，购买批准同时受持卡人的银行影响。除了一般交易授权之外，商家的银行不需要参与或不需要甚至被通知购买批准发生的事实。如果购买未获得批准，则商人银行会收到交易未获得授权的信息，但不一定是否这是由于关于例如卡数据、账户余额、限额和行为的检查，或是否这是由于所请求的购买不满足购买规则。

因此，根据本发明，不需要在进行购买之前在购买管理系统中配置供应商/商家，并且供应商/商家不必以任何方式链接到任何购买管理系统。即使供应商/商家没有以任何方式链接到购买管理系统，本发明也能够将关于购买的信息转移到购买实体，并且这对于任何现有技术系统都是不可能的。

本公开涉及购买管理系统和购买管理方法。结合附图更详细地呈现了所公开的解决方案的实施例。

图1示意性地示出了根据本文所述的一个或多个实施例的购买管理系统100。购买管理系统100可以包括中央数据库装置110、到中央数据库装置110的顾客界面120以及银行特定的数据库模块130，银行特定的数据库模块130被布置成与在持卡人的银行500内的交易授权模块520通信。中央数据库装置110可以例如是云服务。银行特定的数据库模块130可以布置在持卡人银行500内，以使对购买批准请求的快速响应时间成为可能，并且还允许出于监管原因不允许发送到银行防火墙之外的交易信息类型作为链接到在银行特定的数据库模块130中的第一交易id的元数据被添加。对于允许从银行外部接收的和/或发送到银行外部的交易信息有严格的监管要求，但是通过在银行内安排银行特定数据库130模块，也可以将不允许从银行外部接收和/或发送到银行外部的交易信息输入到银行特定的数据库模块130中。

中央数据库装置110可以被布置为通过顾客界面120从购买实体200接收购买规则。这些购买规则可以是针对整个购买实体200的通用购买规则，但是它们也可以是特定于购买实体200的某个子部分甚至特定于购买个体的购买规则。顾客界面120可以例如是网络界面或移动应用。

中央数据库装置110的中央处理装备115可以创建要在交易中使用的交易id。这些交易id可以一次一个地创建，也可以成批创建，并且可以基于预定义规则或根据来自购买实体200的请求创建。甚至可以在定义任何购买规则之前创建交易id。交易id可能需要在使用前激活。

对于每个交易id，可以将有关预期购买者的信息作为元数据添加。预期购买者可以例如被定义为购买组300内的任何购买个体。购买组300可以包括一个或多个特定的购买个体，但是也可以被定义为例如购买实体200的子部分或整个购买实体200。购买组300中的所有购买个体不必都被采纳为购买实体200-购买组300可以例如包括购买实体200的顾问或分包商。

基于关于购买组300的元数据，中央数据库装置110的中央处理装备115可以识别哪些购买规则适用于该特定交易id，并且将这些购买规则作为链接到交易id的元数据添加。对于购买组300内的所有购买个体，购买规则总是相同的，但是如果出现了针对购买组内的不同购买个体的不同购买规则的需要，则可以动态地修改购买组300。在这种情况下，可以轻易地针对需要不同购买规则的购买个体而形成新的购买组300。

与交易有关的其他类型的信息也可以作为链接到中央数据库装置110中的交易id的元数据被添加。购买实体200以外的其他实体也可以访问中央数据库装置110，并且能够添加链接到交易id的元数据。在图2中示出了由优选地使用特定第三方界面160的第三方实体150将元数据添加到中央数据库装置110。第三方界面160可以例如是网络界面或移动应用。

这样的第三方实体150可以例如是购买实体200的客户，购买实体200为购买实体200的客户的利益而进行购买以进一步向客户开具发票。在这种情况下，元数据可以例如是承担购买费用的批准。然后有利的是，如果将为客户开具发票所需的所有信息作为链接到交易id的元数据添加，从而可以简化或甚至自动化客户的开具发票。

这种第三方实体150的另一个示例可以是提供关于列入黑名单的供应商或不满足某些监管要求的供应商的信息的组织。如果这样的组织将该信息作为元数据添加到所有交易id，则购买规则可以定义将永远不允许从由该元数据定义的供应商/商家购买。

这种第三方实体150的另一示例是商家/供应商400。如果商家/供应商400访问中央数据库装置110并且能够添加链接到交易id的元数据，则商家/供应商400可以例如将电子收据作为链接到交易id的元数据添加。商家/供应商400可以使用第三方界面160，或用于商家/供应商400的特定界面。这样的界面可以例如是网络界面或移动应用。然而，如果商家/供应商400不能访问中央数据库装置110，则也可以由另一方，例如由购买组300内的购买个体来添加电子收据。

购买组300内的购买个体也可以与中央数据库装置110通信，以便检索信息和/或添加元数据。如果例如购买实体200希望使公司支付卡能够用于私人的购买，则对于购买个体可以有选择将购买标记为私人的，并且例如费用自动从下次工资中扣除。购买组300中的购买个体可以使用第三方界面160或针对购买组300的特定的界面。这样的界面可以例如是网络界面或移动应用。

购买规则可以例如要求购买个体在购买之前或之后向交易id添加某些元数据，以便简化购买实体200内的管理。例如，可能要求购买个体将帐户、成本中心、项目或对象作为链接到交易id的元数据添加。然后，基于由购买个体添加的元数据，进一步的要求可以应用于特定的类型的购买。如果购买涉及例如代表，诸如与客户的餐馆拜访，则可能需要购买个体添加作为链接到交易id的元数据的在场人员的姓名。如果购买涉及商务旅行，则可能需要购买个体指定旅行的目的地和/或目的。这使得能够在购买实体200内自动记账发票。购买规则可能要求已经添加此元数据用于批准购买。如果购买规则要求已经添加此元数据，则可能会警告购买个体：如果未添加此元数据，则会拒绝购买，即使在购买个体尝试进行购买之前。在这种情况下，这种警告优选地通过例如sms、电子邮件或移动应用传达给购买个体。

但是，某些信息项在批准购买之前是无法添加的。例如，可能要求购买个体将收据作为链接到交易id的元数据添加，例如通过使用移动应用拍摄收据。在这种情况下，购买已经发生，因此不能被拒绝，但是该购买个体的将来购买可能会被阻止，直到将所需的元数据已被添加到所有先前的交易中为止。该阻止可以由购买实体200手动完成。但是，购买规则可以指定例如，在一定时间或一定数量的尚未完成的购买之后，自动阻止所有其他购买。

对于某些供应商/商家，购买规则还可以指定可以以哪种方式进行购买。例如，出于成本原因，它们可能指定仅允许从某个供应商的基于网络的购买，并且在这种情况下，将拒绝在实体店进行购买的尝试。在这种情况下，关于拒绝原因的信息优选地通过例如sms、电子邮件或移动应用传达给购买个体。

可以将链接到交易id的元数据转移到银行特定的数据库模块130。不必将所有元数据转移到银行特定的数据库模块130,只要将购买规则和适用于它们的所有元数据转移了即可。然而，在一实施例中，中央数据库装置110中的所有信息被镜像到银行特定的数据库模块130中。

当银行特定的数据库模块130已经接收到链接到交易id的元数据时，可以从持卡人的银行500内的交易授权模块520发送购买批准请求。购买批准请求包括交易信息，该交易信息可以与交易授权信息相同，当使用支付卡进行支付时，交易授权信息经由支付卡网络从商家的银行发送到持卡人的银行500并在交易授权模块520中接收。这种交易授权信息的示例如图6所示。购买批准请求中的交易信息不一定必须包含所有交易授权信息，只要它包含金额以及将其链接到所需交易id的足够信息即可。如果购买批准请求不包括交易id，则它因此需要包括交易信息的一些其他项目，其使银行特定的数据库模块130能够将购买链接到交易id，诸如识别购买组300的交易信息。如果购买组300被分配了一个或多个特定的支付卡，则该交易信息可以例如是支付卡号或针对该支付卡号的令牌。银行特定的数据库模块130的银行处理装备135然后可以针对该购买组300仅将购买分配给下一个可用的交易id。

银行特定的数据库模块130的银行处理装备135然后检查所请求的购买是否满足链接到交易id的购买规则，即，适用于购买组300的购买规则。除了上面给出的示例外，购买规则还可以例如涉及关于每次购买的最大金额、最大合计金额、遵守预算或对在何处或何时可以进行购买的限制(例如，国际购买或周末购买可以被阻止)。如果购买批准请求包括商家信息，例如商家的名称或用于识别商家的代码，则购买规则还可以涉及针对购买组300被允许或阻止的特定商家。这使得购买实体200能够阻止从选定的供应商/商家的购买和/或仅允许从选定的供应商/商家的购买。购买实体200可以例如使用该功能来阻止从诸如systembolaget之类的酒类商店进行购买，或者仅允许从诸如ica和/或coop之类的特定食品连锁店或诸如食品店之类的特定类型的商家购买。

银行特定的数据库模块130的银行处理装备135因此基于所请求的购买是否满足链接到银行特定的数据库模块130中的交易id的购买规则来批准或拒绝购买批准请求。银行特定的数据库模块130的银行处理装备135还将从交易授权模块520接收的交易信息作为在银行特定的数据库模块130中链接到交易id的元数据添加，以及将该交易信息转移到中央数据库装置110，其中也将其作为链接到交易id的元数据添加。这可以在批准/拒绝被发送到交易授权模块520之前或之后发生。

交易信息优选地由中央数据库装置110中的功能“翻译”或转换成另一种数据格式，优选地由购买实体200定义的数据格式。参照图5下面进一步解释此方面。

基于从银行特定的数据库模块130的银行处理装备135接收到的批准/拒绝，与通过检查例如卡数据、账户余额、限额和行为来执行的一般交易授权一起，交易授权模块520批准或拒绝交易。如果银行特定的数据库模块130的银行处理装备135已经拒绝了交易，则交易授权模块520将拒绝交易，即使一般交易授权检查表明它将是被允许的。同样，如果一般交易授权检查表明不允许交易，则即使银行特定的数据库模块130的银行处理装备135批准购买，交易授权模块520也将拒绝交易。在这种情况下，交易授权模块520甚至可能不向银行特定的数据库模块130发送购买批准请求，因为无论如何都会拒绝交易。

如果在将购买批准请求发送到银行特定的数据库模块130之前在交易授权模块520中执行了一般交易授权，则当银行特定的数据库模块130的银行处理装备135已经确定是否批准或拒绝购买批准请求时，银行特定的数据库模块130的银行处理装备135将能够确定交易授权模块520将是否批准或拒绝交易。替代地，交易授权模块520可以将该信息转移到银行特定的数据库模块130。关于交易是否已经被交易授权模块520批准或拒绝的信息可以作为为链接到银行特定的数据库模块130中的交易id的元数据被添加。

其他类型的信息也可以作为链接到银行特定的数据库模块130中的交易id的元数据被添加。银行500可以例如向银行特定的数据库模块130提供关于涉嫌欺诈行为、交易状态或其他类似类型的信息的信息，使得该信息可以被转移到中央数据库装备110。

当中央数据库装备110已经接收到作为链接到交易id的元数据的交易信息时，中央数据库装置110的中央处理装备115可以优选地以由购买实体定义的数据格式将交易信息转移给购买实体200。这使得交易信息能够被自动输入到购买实体200的经济系统和/或其他管理系统中。这样，购买实体可以在从供应商/商家接收到任何发票之前很长时间对所有交易跟进。这使得购买实体200能够始终保持跟踪其预算，并相应地调整购买规则。

购买规则可能由于各种原因而被调整。如果将购买实体200的某个子部分视为一个购买组300，但希望在该子部分中调整针对某些购买个体的购买规则以便例如为某个购买个体增加更多限制(甚至阻止所有购买)，可以为该购买个体创建一个新的购买组300，其具有比该子部分的其余部分更受限制的购买规则。因此，购买组300和购买规则都可以由购买实体200动态地更新。

购买实体200不一定在系统中定义实际的购买组。相反，购买实体200可以例如在多个层次级别上定义购买规则。一些规则可能对整个组织通用，而其他规则可能特定于某些个体或个体组。在本申请的上下文中，购买组300是具有一个或多个购买个体的组，相同的购买规则对其适用。

在中央数据库装置110中允许元数据链接到交易id的字段也可以由购买实体200动态地设置，以便购买实体200可以定义期望的元数据和针对该元数据的数据格式。这允许例如关于成本中心、账户和其他发票信息的元数据链接到中央数据库装置110中的交易id。这使得购买实体200可以在电子发票中定义购买实体200想要接收的元数据以及购买实体200希望接收元数据的格式，从而使该元数据能够从中央数据库装置110中被检索并添加到电子发票中。这样的电子发票可以从银行500、从中央数据库装置110或从第三方发送。如果针对使用系统100进行的交易的发票是包括由购买实体200指定的元数据的电子发票，则这使得由购买实体200能够自动处理发票，这可以极大地节省管理工作量。

本发明可以例如使用支付卡来进行支付。在这种情况下，关于购买个体的信息可以从中央数据库装置110转移到支付卡发行实体600，如图3所示。该转移可以直接在中央数据库装置110和支付卡发行实体600之间发生，或者可以经由银行500内的支付卡管理模块510来进行。支付卡发行实体600可以链接到银行500，但是它也可以是单独的支付卡发行实体600。

为了将用支付卡进行的支付连接到进行购买的购买个体，优选地直接或经由在银行500内的支付卡管理模块510将关于支付卡的信息从支付卡发行实体600转移到中央数据库装置110。信息优选地不是实际的信用卡号，因为关于是否允许将其存储为链接到中央数据库装置110中的交易id的元数据可能存在限制。该信息可以替代地例如是用于信用卡号的令牌。

图4是根据本文描述的一个或多个实施例的购买管理方法的示例流程图。流程如下：

步骤410：购买实体200在中央数据库装置110中配置其购买规则(这可以在步骤460之前的任何点发生，并且元数据可以由购买实体200在流程期间的任何点处被添加)。

步骤415：中央数据库装置110从持卡人的银行500要求用于购买实体200的卡账户。

步骤420：持卡人的银行500从支付卡发行实体600要求支付卡。

步骤425：可以从中央数据库装置110向支付卡发行实体600提供诸如卡、徽标等的个性化之类的附加信息。支付卡发行实体600还可以直接从中央数据库装置110要求支付卡。

步骤430：支付卡从支付卡发行实体600发送到购买个体300(分发可能涉及购买实体200)。

步骤435(可选)：购买个体300经由用户界面将与购买有关的元数据添加到中央数据库装置110(这可以在流程期间的任何点发生)。

步骤440：将交易id和链接到它们的元数据(诸如购买规则)从中央数据库装置110转移到银行特定的数据库模块130。

步骤445：购买个体从商家/供应商400进行购买。

步骤450：商家的银行550从商家/供应商400接收关于购买的信息。

步骤455：商家的银行550经由诸如visa或mastercard之类的支付卡网络请求持卡人的银行500授权交易。

步骤460：持卡人的银行500向银行特定的数据库模块130请求购买批准。

步骤465：银行特定的数据库模块130将购买批准发送到持卡人的银行500。

步骤470：持卡人的银行500将交易授权发送给商家的银行550。

步骤475：商家的银行550将交易许可发送给商家/供应商400。

步骤480：银行特定的数据库模块130将关于被批准的购买的交易信息转移到中央数据库装置110(这可以在步骤460之后的任何点发生)。

步骤485：中央数据库装置110将交易信息转移给购买实体200。

步骤490(可选)：第三方将元数据添加到交易中(这可以在流程中的任何点发生)。

图5示意性地示出了根据本文所述的一个或多个实施例的购买管理系统100的一部分。中央数据库装置110优选地使用“元数据载体”的动态配置，其允许将元数据链接到交易id，使得购买实体200可以定义期望的元数据和针对该元数据的格式。如以上关于图1-3所解释的，中央数据库装置110可以与许多不同方(诸如，购买实体200、购买个体或购买组300、商家/供应商400、持卡人银行500、支付卡发行实体600和各种其他第三方实体150)交互和通信。为了使中央数据库装置110能够从这些方收集数据并且向这些方和从这些方传输数据，中央数据库装置110需要包括例如“适配器”形式的功能，以将由这些不同方中的每一个所使用的数据格式“翻译”或转换为一种单一的数据格式，优选地，由购买实体200定义的数据格式。中央数据库装置110需要包括用于每一方200、300、400、500、600、150的特定的适配器205、305、405、505、605、155，因为不同方通常使用不同的数据格式(如果有多个不同的第三方150，通常需要几个不同的适配器155)。这使得购买实体200能够定义其想要从不同方接收的元数据以及该元数据的数据格式。

使用案例

为了进一步描述本发明，提供了以下使用案例。采购实体acompany包括子部分服务部(service)、开发部(development)、销售部(sales)和管理部(administration)。acompany通过顾客界面120将其购买策略和规则定义到中央数据库装置110，并从它的银行cardbank要求针对所有它的购买个体的支付卡。一些购买个体拥有个人支付卡，而其他一些则拥有联合支付卡。

acompany将其子部分服务部定义为购买组服务部，其中相同的购买规则适用于所有人员。由于为了向故障器材提供即时服务服务部人员必须能够到处移动，并且在短时间内，在购买组服务部内的所有购买个体都拥有个人支付卡，并且针对购买组服务部的购买规则具有很少限制。但是，acompany会根据服务部预算不断跟进所有购买，并且由于预算限制，可能会随着时间调整购买规则。

acompany将其子部分开发部定义为购买组开发部，具有更多限制。开发部人员包括acompany员工和顾问。开发部人员不允许进行未经开发部经理事先批准的任何购买。一些开发部人员拥有个人支付卡，但也有一些针对购买组开发部的一些联合支付卡。

acompany将其子部分销售部定义为两个不同的购买组，本地销售部(localsales)和全球销售部(worldwidesales)。购买组本地销售部通常不会出国旅行，因此可以将购买规则限制为在国内的购买。另一方面，购买组全球销售部到处旅行，因此可能具有对购买规则的限制要少得多。但是，购买规则可能例如指出，如果选择了不在acompany为其议价的酒店和连锁酒店的列表中的酒店，则必须预先批准。所有销售部人员都拥有个人支付卡。

acompany将其子部分管理部定义为购买组管理部。管理部人员必须能够进行少量购买，诸如办公材料和午餐，因此购买规则可能在例如金额和供应商方面受到限制。购买组管理拥有联合支付卡。

当服务部员工尝试使用支付卡进行购买时，商家的银行会经由支付卡网络向cardbank发送交易授权请求，例如，包括图6中所示的交易授权信息。cardbank的交易授权模块520接收交易授权请求并执行一些检查，例如关于卡数据、账户余额、限额和行为的检查。如果cardbank的交易授权模块520基于这些检查决定批准交易，则它将购买批准请求发送到cardbank内的银行特定的数据库130，其中将交易id与链接到它们的元数据的一起存储。

因为服务部员工都具有相同的购买规则，所以银行特定的数据库130可以将购买分配给数据库中已为购买组服务部标记的下一个可用的交易id。在这种情况下，例如可以使用支付卡号来确定与购买组服务部有关的购买。但是，服务部员工可能反而已经选择了特定的交易id，服务部员工可能已经添加了链接到该交易id的元数据。针对服务部人员的购买规则作为链接到交易id的元数据被存储，因此，银行特定的数据库130基于请求的购买是否满足服务部购买规则，通过批准或拒绝来决定购买批准请求。因为在服务部购买规则中具有很少限制，所以允许大多数购买。银行特定的数据库130将交易信息作为链接到交易id的元数据存储，并将该元数据转移到中央数据库装置110。中央数据库装置110然后将交易信息转移给acompany，从而关于购买的信息可以被自动输入到acompany的经济和其他管理系统中。

当开发部人员进行购买时，遵循类似的流程。但是，因为不允许开发部人员进行未经开发部经理事先批准的任何购买，所以必须预先批准购买。希望进行购买的开发部人员使用用于购买组300的指定界面(例如网络界面或移动应用)来获取交易id，并通过界面将与该购买有关的所需元数据输入到中央数据库装置110。然后为开发部经理设置动作以预先批准此购买。这可能只是系统中定义的动作，但是也可将提醒经由例如sms或电子邮件自动地发送给经理。一旦开发部经理批准了购买，则购买规则将允许它。

当销售部人员进行购买时，也会遵循类似的流程。对于服务部人员，购买组全球销售部具有很少的限制。但是，可能需要更改针对在全球销售部中一个个体或一组个体的购买规则，例如，如果事实证明代表已变得过于奢侈。然后可以定义新的购买组，例如在针对代表的费用上有更多限制，因此以前的购买组全球销售部变成了例如两个组，标准的全球销售部(worldwidesalesstandard)和受限的全球销售部(worldwidesalesrestricted)。

当管理部人员进行购买时，也遵循类似的流程。但是，管理部人员拥有更严格的购买规则，例如对允许的供应商/商家有限制。从cardbank的交易授权模块520发送的交易信息还包括商家信息，例如商家的名称或用于识别商家的代码，因此银行特定的数据库130可以根据购买规则将商家信息与允许的商家比较。管理部人员可能受限于某些供应商/商家，例如ica和/或coop，或者受限于某些商家类型，例如食品店。visa商家类别分类例如将mcc代码5499用于“混杂食品店–便利店和特色市场(misc.foodstores–conveniencestoresandspecialtymarkets)”，并且该代码被包含在交易授权信息中的商家识别代码(merchantidentificationcode)中。当管理部人员在食品店购买食品时，许多不同的增值税级别(vatlevels)可能适用于不同种类的商品。然后可以将针对购买中不同项目的不同增值税级别作为链接到交易id的元数据自动存储，以简化购买实体200中的管理。

方法实施例

图7示意性地示出了根据本文描述的一个或多个实施例的购买管理方法700。方法700可以包括：

步骤710：通过顾客界面120向中央数据库装置110输入适用于购买组300的购买规则。

步骤720：将被选择的购买组300作为链接到在中央数据库装置110中的第一交易id的元数据添加。

步骤725：在中央数据库装置110中将适用于购买组300的购买规则作为链接到第一交易id的元数据添加。

步骤730：将链接到第一交易id的元数据从中央数据库装置110转移到银行特定的数据库模块130。

步骤740：在布置在银行500内的交易授权模块520中，接收链接到第一交易id的第一交易授权请求，该第一交易授权请求包括交易授权信息。

步骤750：将购买批准请求从交易授权模块520传达到银行特定的数据库模块130，该购买批准请求包括交易信息，该交易信息至少包括购买金额。

步骤760：基于所请求的购买是否满足银行特定的数据库模块130中链接到第一交易id的购买规则，通过批准或拒绝来决定购买批准请求。

步骤765：以购买批准请求的批准或拒绝来响应交易授权模块520。

步骤770：从交易授权模块520响应链接到第一交易id的第一交易授权请求。

步骤780：将从交易授权模块520接收的交易信息作为银行特定的数据库模块130中的链接到第一交易id的元数据添加。

步骤785：将链接到第一交易id的交易信息转移到中央数据库装置110。

步骤790：将与第一交易id链接的交易信息转移到购买实体200，以使关于购买的信息可以被自动地输入到购买实体200的至少一个管理系统中。

在实施例中，银行特定的数据库模块130被布置在银行500内。这样可以快速响应购买批准请求，并且还允许将由于监管原因不允许发送到银行防火墙之外的交易信息类型作为链接到银行特定的数据库模块130中的第一个交易id的元数据添加。对于允许从银行外部接收和/或发送到银行外部的交易信息有严格的监管要求，但是通过在银行内安排银行特定数据库130模块，也可以将不允许从银行外部接收的和/或发送到银行外部的交易信息输入到银行特定的数据库模块130中。

在实施例中，购买组300包括至少一个购买个体。这使得可以为一个或多个特定的购买个体或包括一个或多个购买个体的购买实体的子部分定义购买规则并且使购买规则适应于其。

在实施例中，购买组300包括整个购买实体200。这使购买实体可以为整个实体定义通用购买规则。

在实施例中，购买规则是用于购买实体200的子部分的通用购买规则，并且将应用于购买组300的购买规则作为链接到中央数据库装置110中的第一交易id的元数据的添加725涉及确定购买组300属于哪个子部分。

在实施例中，交易信息包括商家信息，例如商家的名称或用于识别商家的代码，并且通过批准或拒绝它来决定760购买批准请求是进一步基于商家信息。

在实施例中，购买规则指定在进行购买之前必须已经添加某些元数据链接到中央数据库装置110中的交易id，并且如果不存在该元数据链接到银行特定的数据库模块130中的交易id，则关于购买批准请求的决定760包括拒绝购买批准请求。

在实施例中，链接到第一交易id的元数据从中央数据库装置110到银行特定的数据库模块130的转移730以及链接到第一交易id的交易信息到中央数据库装置110的转移785包括将中央数据库装置110和银行特定的数据库模块130同步为彼此的镜像版本。

在实施例中，中央数据库装置110布置成与多个不同方200、300、400、500、600、150通信，并且包括适配器205、305、405、505、605、155，其将由这些不同方中的每一个使用的数据格式转换为一个单一的数据格式，优选地，由购买实体200定义的数据格式。

方法700可以进一步包括：

步骤705：直接或经由银行500内的支付卡管理模块510将信息从中央数据库装置110转移到支付卡发行实体600，使得支付卡发行实体600可以将支付卡发行给购买实体200。

前述公开内容并非旨在将本发明限制为所公开的使用的精确形式或特定领域。可以预期，根据本公开，无论是在本文中明确描述还是暗含的，针对本发明的各种替代实施例和/或修改都是可能的。在本公开中，已经描述了使用支付卡的本发明的实施例。然而，本发明不限于使用支付卡的实施例，而是还涵盖其他支付方法，例如使用智能手机或其他设备(例如使用qr、ean或pin码)的支付。因此，本发明的范围仅由权利要求书限定。

此外，并非必须按照所列顺序实行权利要求的所有步骤。例如，在创建交易id之前不必将购买规则输入到中央数据库装置110中。此外，如果购买实体200修订购买规则并将新的购买规则输入到中央数据库装置110中，则可以更新链接到中央数据库装置110中的交易id的与购买规则有关的元数据，并将其转移到银行特定的数据库模块130，直到针对交易id已批准或拒绝购买批准请求为止。在另一个示例中，可以在对购买批准请求的批准/拒绝之前或之后，将交易信息作为链接到交易id的元数据添加。这些步骤的所有技术上有意义的顺序都由权利要求覆盖。