DE112019006109T5 - Einkaufsmanagementsystem und -verfahren - Google Patents

Einkaufsmanagementsystem und -verfahren Download PDF

Info

Publication number
DE112019006109T5
DE112019006109T5 DE112019006109.7T DE112019006109T DE112019006109T5 DE 112019006109 T5 DE112019006109 T5 DE 112019006109T5 DE 112019006109 T DE112019006109 T DE 112019006109T DE 112019006109 T5 DE112019006109 T5 DE 112019006109T5
Authority
DE
Germany
Prior art keywords
transaction
purchasing
bank
purchase
linked
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE112019006109.7T
Other languages
English (en)
Inventor
Patric ERIKSSON
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
EASI B2B AB
Original Assignee
EASI B2B AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by EASI B2B AB filed Critical EASI B2B AB
Publication of DE112019006109T5 publication Critical patent/DE112019006109T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/085—Payment architectures involving remote charge determination or related payment systems
    • G06Q20/0855—Payment architectures involving remote charge determination or related payment systems involving a third party
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/108—Remote banking, e.g. home banking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/403—Solvency checks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/403—Solvency checks
    • G06Q20/4037—Remote solvency checks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405—Establishing or using transaction specific rules
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/409—Device specific authentication in transaction processing
    • G06Q20/4093—Monitoring of device authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0633—Lists, e.g. purchase orders, compilation or processing
    • G06Q30/0635—Processing of requisition or of purchase orders
    • G06Q30/0637—Approvals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Marketing (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Technology Law (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Cash Registers Or Receiving Machines (AREA)

Abstract

Gemäß einer oder mehreren hierin beschriebenen Ausführungsformen wird ein Einkaufsmanagementsystem 100 bereitgestellt. Das System 100 umfasst eine zentrale Datenbankanordnung 110, eine Kundenschnittstelle 120 zur zentralen Datenbankanordnung 110 und ein bankspezifisches Datenbankmodul 130, das dazu eingerichtet ist, mit einem Transaktionsautorisierungsmodul 520 in einer Bank 500 zu kommunizieren. Die zentrale Datenbankanordnung 100 ist dazu eingerichtet, über die Kundenschnittstelle 120 von einem einkaufenden Unternehmen 200 Einkaufsregeln zu empfangen, die für eine Einkaufsgruppe 300 gelten, und umfasst zentrale Verarbeitungseinrichtungen 115, die dazu eingerichtet sind, eine ausgewählte Einkaufsgruppe 300 als mit einer ersten Transaktions-ID verknüpfte Metadaten der zentralen Datenbankanordnung 110 hinzuzufügen, die für die Einkaufsgruppe 300 geltenden Einkaufsregeln als mit der ersten Transaktions-ID verknüpfte Metadaten der zentralen Datenbankanordnung 110 hinzuzufügen und mit der ersten Transaktions-ID verknüpfte Metadaten an das bankspezifische Datenbankmodul 130 zu übertragen. Das bankspezifische Datenbankmodul 130 ist dazu eingerichtet, vom Transaktionsautorisierungsmodul 520 eine Einkaufsgenehmigungsanfrage zu empfangen, die Transaktionsinformationen umfasst, welche zumindest den Einkaufsbetrag enthalten und mit der ersten Transaktions-ID verknüpft sind. Das bankspezifische Datenbankmodul 130 umfasst Bankverarbeitungseinrichtungen 135, die dazu eingerichtet sind, basierend darauf, ob der angefragte Einkauf die mit der ersten Transaktions-ID verknüpften Einkaufsregeln im bankspezifischen Datenbankmodul 130 erfüllt, über die Einkaufsgenehmigungsanfrage durch Genehmigen oder Ablehnen derselben zu entscheiden, dem Transaktionsautorisierungsmodul 520 mit der Genehmigung oder Ablehnung der Einkaufgenehmigungsanfrage zu antworten, die vom Transaktionsautorisierungsmodul 520 empfangenen Transaktionsinformationen als mit der ersten Transaktions-ID verknüpfte Metadaten dem bankspezifischen Datenbankmodul 130 hinzuzufügen und die mit der ersten Transaktions-ID verknüpften Transaktionsinformationen an die zentrale Datenbankanordnung 110 zu übertragen. Die zentralen Verarbeitungseinrichtungen 115 der zentralen Datenbankanordnung 110 sind ferner dazu eingerichtet, die mit der ersten Transaktions-ID verknüpften Transaktionsinformationen an das einkaufende Unternehmen 200 zu übertragen, so dass die Informationen bezüglich des Einkaufs automatisch in wenigstens ein Verwaltungssystem des einkaufenden Unternehmens 200 eingegeben werden können.

Description

  • TECHNISCHES GEBIET
  • Die Erfindung betrifft allgemein Einkaufsmanagementsysteme.
  • HINTERGRUND
  • US 7 319 986 beschreibt ein dynamisches Zahlungskartenmanagementsystem, bei dem sich Kartenkontrolleinstellungen dynamisch modifizieren lassen, so dass Genehmigungsparameter durch die Anwendung konfigurierbarer Firmeneinkaufspolitiken und -regeln dynamisch verwaltet werden können.
  • Das in US 7 319 986 beschriebene System dreht sich um die Verwendung von Kaufanfragen. Ohne eine spezifische Kaufanfrage kann kein Einkauf getätigt werden, obgleich die Kaufanfrage in manchen Situationen durch das System synthetisiert werden kann. Die Verwendung von Kaufanfragen vereinfacht den Genehmigungsprozess innerhalb der Firma.
  • PROBLEME BEIM STAND DER TECHNIK
  • Bei dem in US 7 319 986 beschriebenen System kann der Kunde benachrichtigt werden, dass eine Transaktion stattgefunden hat, da sich das System jedoch um die Verwendung von Kaufanfragen dreht, gibt es keine Möglichkeit, zum Einkaufszeitpunkt die Einzelheiten des Einkaufs in das Wirtschaftssystem der Firma zu übertragen. Somit erhält die Firma die Einzelheiten des Einkaufs erst bei Empfang der Rechnung vom Lieferanten.
  • Außerdem ist das in US 7 319 986 beschriebene System ein Gesamtkartenverarbeitungssystem, das die bestehende Zahlungsinfrastruktur ersetzen soll.
  • Daher besteht Bedarf an einem verbesserten Einkaufsmanagementsystem.
  • Zusammenfassung
  • Ein Einkaufsmanagementsystem, das sich um die Verwendung von Kaufanfragen dreht, vereinfacht den Genehmigungsprozess innerhalb der Firma, da die Kaufanfrage jedoch intern in der Firma verwaltet wird, können externe Parteien dieser keine Informationen, wie z.B. Einzelheiten eines abgeschlossenen Einkaufs, hinzufügen.
  • Erfindungsgemäß wird stattdessen eine für alle Parteien des Systems zugängliche Datenbank dazu verwendet, die Informationen bezüglich des Einkaufs zu speichern. Die Datenbankanordnung umfasst bevorzugt eine Funktionalität zum „Übersetzen“ des durch die verschiedenen Parteien des Systems verwendeten Datenformats in ein einzelnes Datenformat, da es dadurch den verschiedenen Parteien erleichtert wird, Informationen bezüglich des Einkaufs hinzuzufügen.
  • Die vorliegende Offenbarung betrifft Einkaufsmanagementsysteme, bei denen einkaufende Unternehmen Waren und Dienste von Lieferanten/Händlern erwerben können. Bekannte Systeme ermöglichen keine automatische Eingabe der Transaktionsinformationen solcher Einkäufe in Wirtschaftssysteme und andere Verwaltungssysteme des einkaufenden Unternehmens. Die Erfindung erreicht dies durch Erfassen von Informationen von verschiedenen Parteien des Systems auf eine Art, zu der bekannte Systeme nicht fähig sind.
  • Das beanspruchte Einkaufsmanagementsystem kann eine zentrale Datenbankanordnung, eine Kundenschnittstelle zur zentralen Datenbankanordnung und ein bankspezifisches Datenbankmodul umfassen, das dazu eingerichtet ist, mit einem Transaktionsautorisierungsmodul in einer Bank zu kommunizieren. Die zentrale Datenbankanordnung kann dazu eingerichtet sein, über die Kundenschnittstelle von einem einkaufenden Unternehmen Einkaufsregeln zu empfangen, die für eine Einkaufsgruppe gelten. Die zentrale Datenbankanordnung kann zentrale Verarbeitungseinrichtungen umfassen, die dazu eingerichtet sind, eine ausgewählte Einkaufsgruppe als mit einer ersten Transaktions-ID (Transaktionskennung) verknüpfte Metadaten der zentralen Datenbankanordnung hinzuzufügen, die für die Einkaufsgruppe geltenden Einkaufsregeln als mit der ersten Transaktions-ID verknüpfte Metadaten der zentralen Datenbankanordnung hinzuzufügen und mit der ersten Transaktions-ID verknüpfte Metadaten an das bankspezifische Datenbankmodul zu übertragen. Das bankspezifische Datenbankmodul kann dazu eingerichtet sein, vom Transaktionsautorisierungsmodul eine Einkaufsgenehmigungsanfrage zu empfangen, die Transaktionsinformationen umfasst, welche zumindest den Einkaufsbetrag enthalten und mit der ersten Transaktions-ID verknüpft sind. Das bankspezifische Datenbankmodul kann Bankverarbeitungseinrichtungen umfassen, die dazu eingerichtet sind, basierend darauf, ob der angefragte Einkauf die mit der ersten Transaktions-ID verknüpften Einkaufsregeln im bankspezifischen Datenbankmodul erfüllt, über die Einkaufsgenehmigungsanfrage durch Genehmigen oder Ablehnen derselben zu entscheiden, dem Transaktionsautorisierungsmodul mit der Genehmigung oder Ablehnung der Einkaufgenehmigungsanfrage zu antworten, die vom Transaktionsautorisierungsmodul empfangenen Transaktionsinformationen als mit der ersten Transaktions-ID verknüpfte Metadaten dem bankspezifischen Datenbankmodul hinzuzufügen und die mit der ersten Transaktions-ID verknüpften Transaktionsinformationen an die zentrale Datenbankanordnung zu übertragen. Die zentralen Verarbeitungseinrichtungen der zentralen Datenbankanordnung können ferner dazu eingerichtet sein, die mit der ersten Transaktions-ID verknüpften Transaktionsinformationen an das einkaufende Unternehmen zu übertragen, so dass die Informationen bezüglich des Einkaufs automatisch in wenigstens ein Verwaltungssystem des einkaufenden Unternehmens eingegeben werden können. Dies ermöglicht ein vereinfachtes Erfassen von Transaktionsinformationen von Einkäufen und eine Umsetzung dieser Transaktionsinformationen in ein durch das einkaufende Unternehmen verwendetes Datenformat, so dass die Transaktionsinformationen automatisch in Wirtschaftssysteme und andere Verwaltungssysteme des einkaufenden Unternehmens eingegeben werden können.
  • Ein Einkaufsmanagementverfahren kann umfassen: Eingeben von für eine Einkaufsgruppe geltenden Einkaufsregeln in eine zentrale Datenbankanordnung über eine Kundenschnittstelle, Hinzufügen einer ausgewählten Einkaufsgruppe als mit einer ersten Transaktions-ID (Transaktionskennung) verknüpfte Metadaten zur zentralen Datenbankanordnung, Hinzufügen der für die Einkaufsgruppe geltenden Einkaufsregeln als mit der ersten Transaktions-ID verknüpfte Metadaten zur zentralen Datenbankanordnung, Übertragen von mit der ersten Transaktions-ID verknüpften Metadaten von der zentralen Datenbankanordnung an ein bankspezifisches Datenbankmodul, Empfangen einer mit der ersten Transaktions-ID verknüpften ersten Transaktionsautorisierungsanfrage in einem in einer Bank angeordneten Transaktionsautorisierungsmodul, wobei die erste Transaktionsautorisierungsanfrage Transaktionsautorisierungsinformationen umfasst, Kommunizieren einer Einkaufsgenehmigungsanfrage vom Transaktionsautorisierungsmodul an das bankspezifische Datenbankmodul, wobei die Einkaufsgenehmigungsanfrage Transaktionsinformationen umfasst, die zumindest den Einkaufsbetrag enthalten, Entscheiden über die Einkaufsgenehmigungsanfrage durch Genehmigen oder Ablehnen derselben basierend darauf, ob der angefragte Einkauf die mit der ersten Transaktions-ID verknüpften Einkaufsregeln im bankspezifischen Datenbankmodul erfüllt, Antworten an das Transaktionsautorisierungsmodul mit der Genehmigung oder Ablehnung der Einkaufgenehmigungsanfrage, Antworten auf die mit der ersten Transaktions-ID verknüpfte erste Transaktionsautorisierungsanfrage durch das Transaktionsautorisierungsmodul, Hinzufügen der vom Transaktionsautorisierungsmodul empfangenen Transaktionsinformationen als mit der ersten Transaktions-ID verknüpfte Metadaten zum bankspezifischen Datenbankmodul, Übertragen der mit der ersten Transaktions-ID verknüpften Transaktionsinformationen an die zentrale Datenbankanordnung und Übertragen der mit der ersten Transaktions-ID verknüpften Transaktionsinformationen an das einkaufende Unternehmen, so dass die Informationen bezüglich des Einkaufs automatisch in wenigstens ein Verwaltungssystem des einkaufenden Unternehmens eingegeben werden können. Dies ermöglicht ein vereinfachtes Erfassen von Transaktionsinformationen von Einkäufen und eine Umsetzung dieser Transaktionsinformationen in ein durch das einkaufende Unternehmen verwendetes Datenformat, so dass die Transaktionsinformationen automatisch in Wirtschaftssysteme und andere Verwaltungssysteme des einkaufenden Unternehmens eingegeben werden können.
  • Bei manchen Ausführungsformen ist das bankspezifische Datenbankmodul in der Bank angeordnet. Die Definition „in der Bank“ bedeutet, dass sich die Module in der Bank in den Systemen der Bank hinter der Firewall der Bank befinden, so dass die Informationen, die zwischen den Modulen übertragen werden, niemals außerhalb der Firewall der Bank gesendet werden. Dies ermöglicht schnelle Antwortzeiten bei Einkaufsgenehmigungsanfragen und lässt es auch zu, die Art von Transaktionsinformationen, die aus regulatorischen Gründen nicht außerhalb der Firewall der Bank gesendet werden darf, als mit der ersten Transaktions-ID verknüpfte Metadaten dem bankspezifischen Datenbankmodul hinzuzufügen. Es gibt strenge regulatorische Anforderungen für Transaktionsinformationen, die von außerhalb der Bank empfangen und/oder nach draußen gesendet werden dürfen, durch Anordnen des bankspezifischen Datenbankmoduls in der Bank können jedoch auch Transaktionsinformationen, die nicht von außerhalb der Bank empfangen und/oder nach draußen gesendet werden dürfen, in das bankspezifische Datenbankmodul eingegeben werden.
  • Bei manchen Ausführungsformen umfasst die Einkaufsgruppe wenigstens eine einkaufende Person. Dies ermöglicht es, für eine oder mehrere bestimmte einkaufende Personen oder Unterabteilungen des einkaufenden Unternehmens, die eine oder mehrere einkaufende Personen umfassen, Einkaufsregeln zu definieren und an diese anzupassen.
  • Bei manchen Ausführungsformen umfasst die Einkaufsgruppe das gesamte einkaufende Unternehmen. Dies ermöglicht es dem einkaufenden Unternehmen, für das gesamte Unternehmen allgemeine Einkaufsregeln zu definieren.
  • Bei manchen Ausführungsformen sind die Einkaufsregeln allgemeine Einkaufsregeln für eine Unterabteilung des einkaufenden Unternehmens und das Hinzufügen der für die Einkaufsgruppe geltenden Einkaufsregeln als mit der ersten Transaktions-ID verknüpfte Metadaten zur zentralen Datenbankanordnung umfasst eine Bestimmung, zu welcher Unterabteilung die Einkaufsgruppe gehört.
  • Bei manchen Ausführungsformen umfassen die Transaktionsinformationen Händlerinformationen, z.B. den Namen des Händlers oder einen Code zur Identifizierung des Händlers, und das Entscheiden über die Einkaufsgenehmigungsanfrage durch Genehmigen oder Ablehnen derselben basiert ferner auf den Händlerinformationen. Dies ermöglicht es dem einkaufenden Unternehmen, Einkäufe bei ausgewählten Lieferanten/Händlern zu blockieren und/oder nur Einkäufe bei ausgewählten Lieferanten/Händlern zuzulassen.
  • Bei manchen Ausführungsformen geben die Einkaufsregeln vor, dass bestimmte Metadaten verknüpft mit der Transaktions-ID der zentralen Datenbankanordnung hinzugefügt werden müssen, bevor ein Einkauf getätigt wird, und das Entscheiden über die Einkaufsgenehmigungsanfrage umfasst das Ablehnen der Einkaufgenehmigungsanfrage, wenn diese Metadaten nicht verknüpft mit der Transaktions-ID im bankspezifischen Datenbankmodul vorhanden sind.
  • Bei manchen Ausführungsformen werden Informationen von der zentralen Datenbankanordnung entweder direkt oder über ein Zahlungskartenverwaltungsmodul in der Bank an ein Zahlungskarten ausgebendes Unternehmen übertragen, so dass das Zahlungskarten ausgebende Unternehmen Zahlungskarten an das einkaufende Unternehmen ausgeben kann.
  • Bei manchen Ausführungsformen werden die zentrale Datenbankanordnung und das bankspezifische Datenbankmodul synchronisiert, so dass sie gespiegelte Versionen voneinander darstellen. Die Spiegelung umfasst jedoch nicht unbedingt sämtliche Informationen in der Datenbank - einige Metadatenfelder können von der Spiegelung ausgenommen werden.
  • Bei manchen Ausführungsformen ist die zentrale Datenbankanordnung dazu eingerichtet, mit mehreren verschiedenen Parteien zu kommunizieren, und umfasst Adapter, die das durch jede dieser verschiedenen Parteien verwendete Datenformat in ein einzelnes Datenformat, bevorzugt ein durch das einkaufende Unternehmen definiertes Datenformat, umsetzen.
  • Die Erfindung ist in keiner Weise auf die Verwendung von Zahlungskarten beschränkt, sondern deckt auch Transaktionen ab, die unter Verwendung anderer Einrichtungen, wie etwa von Smartphones oder anderen Geräten, die z.B. QR-, EAN- oder PIN-Codes verwenden, durchgeführt werden.
  • In dieser Anmeldung bezieht sich der Begriff „Bank“ auf einen Zahlungsdienst oder ein Finanzinstitut, der/das dazu befugt ist, Zahlungskartenzahlungen oder ähnliche Arten von Transaktionen zu genehmigen und auszuführen, und somit nicht nur auf Zahlungsdienste oder Finanzinstitute, die formell als Banken definiert und zugelassen sind. In manchen Ländern muss ein Zahlungsdienst oder Finanzinstitut gewisse regulatorische Anforderungen erfüllen, beispielsweise um durch Einlagensicherungssysteme abgedeckt zu sein, wobei der Begriff „Bank“ in diesen Ländern für Zahlungsdienste und Finanzinstitute reserviert sein kann, die solche regulatorischen Anforderungen erfüllen. In dieser Anmeldung ist der Begriff „Bank“ nicht solchermaßen beschränkt, sondern deckt alle Zahldienste oder Finanzinstitute ab, die dazu befugt sind, Zahlungskartenzahlungen oder ähnliche Arten von Transaktionen zu genehmigen und auszuführen. In dieser Anmeldung kann der Begriff „Bank“ somit auch Kreditkartennetzwerke abdecken, wie z.B. MasterCard oder VISA, die Transaktionen genehmigen und ausführen. In dieser Anmeldung deckt der Begriff „Bank“ auch Kooperationen zwischen Kreditkartennetzwerken, wie z.B. MasterCard oder VISA, und Zahlungsdiensten oder Finanzinstituten ab, die dazu befugt sind, Zahlungskartenzahlungen oder ähnliche Arten von Transaktionen zu genehmigen und auszuführen.
  • Die zentralen Verarbeitungseinrichtungen der zentralen Datenbankanordnung können eine einzelne zentrale Verarbeitungsanordnung oder mehrere zentrale Verarbeitungsanordnungen umfassen, zwischen denen Signale übertragen werden. Ein Teil der Verarbeitung kann beispielsweise in einer zentralen Verarbeitungsanordnung stattfinden und Signale können dann zur weiteren Verarbeitung an eine oder mehrere andere zentrale Verarbeitungsanordnungen übertragen werden.
  • Die Bankverarbeitungseinrichtungen des bankspezifischen Datenbankmoduls können eine beliebige oder mehrere Verarbeitungsanordnungen innerhalb des Banksystems umfassen und sind daher nicht unbedingt Verarbeitungseinrichtungen, die für das bankspezifische Datenbankmodul spezifisch sind.
  • Die Module in der Bank können physisch separate Module sein, zwischen denen Informationen gesendet werden, sie können jedoch auch im gleichen Server implementierte virtuelle Module oder einfach Softwaremodule sein.
  • Der Umfang der Erfindung ist durch die Schutzansprüche definiert, die in diesem Abschnitt durch Bezugnahme gewürdigt sind. Ein genaueres Verständnis der Ausführungsformen der Erfindung sowie eine Einsicht in zusätzliche Vorteile derselben ergeben sich für Fachleute aus einem Studium der folgenden genauen Beschreibung einer oder mehrerer Ausführungsformen. Es wird auf die beiliegenden Zeichnungsblätter Bezug genommen, die zunächst kurz beschrieben sind.
  • Figurenliste
    • 1 zeigt schematisch ein Einkaufsmanagementsystem gemäß einer oder mehreren hierin beschriebener Ausführungsformen.
    • 2 zeigt schematisch ein Einkaufsmanagementsystem gemäß einer oder mehreren hierin beschriebener Ausführungsformen.
    • 3 zeigt schematisch ein Einkaufsmanagementsystem gemäß einer oder mehreren hierin beschriebener Ausführungsformen.
    • 4 zeigt ein beispielhaftes Flussdiagramm eines Einkaufsmanagementverfahrens.
    • 5 zeigt schematisch einen Teil eines Einkaufsmanagementsystems gemäß einer oder mehreren hierin beschriebener Ausführungsformen.
    • 6 zeigt ein Beispiel für Transaktionsautorisierungsinformationen.
    • 7 zeigt schematisch ein Einkaufsmanagementverfahren.
  • Ausführungsformen der vorliegenden Offenbarung und deren Vorteile lassen sich am besten unter Bezugnahme auf die folgende genaue Beschreibung nachvollziehen. Es versteht sich, dass gleiche Bezugszeichen dazu verwendet werden, in einer oder mehreren der Figuren gleiche Elemente zu identifizieren.
  • GENAUE BESCHREIBUNG
  • Es gibt mehrere verschiedene Arten von Zahlungskartenverarbeitungsmodellen. Das einfachste Modell, bei dem ein Händler eine Zahlungskarte ausgibt und eine direkte Beziehung zum Karteninhaber hat, lässt sich als Zwei-Ecken-Modell definieren. Bei einem Zwei-Ecken-Modell kann der Karteninhaber die Zahlungskarte nur beim ausgebenden Händler verwenden.
  • Wenn der Händler die Zahlungskarte nicht ausgeben und abwickeln möchte, kann ein Drei-Ecken-Modell verwendet werden, bei dem eine dritte Partei zwischen dem Karteninhaber und dem Händler als Vermittler agiert. Bei einem Drei-Ecken-Modell kann der Karteninhaber die Zahlungskarte weiterhin nur bei dem vorgegebenen Händler verwenden.
  • Um Karteninhabern mehr Flexibilität zu bieten, wird stattdessen normalerweise ein Vier-Ecken-Modell für Zahlungskarten verwendet. Bei einem solchen Modell kann ein Karteninhaber eine Zahlungskarte für Zahlungen an einen beliebigen Händler verwenden, der die Karte akzeptiert, und die Transaktion wird zwischen der Händlerbank und der Karteninhaberbank über ein Zahlungskartennetzwerk, wie z.B. MasterCard oder VISA, abgewickelt.
  • Wenn die Zahlungskarte zur Zahlung verwendet wird, wird eine Transaktionsautorisierung erreicht, indem die Händlerbank über das Zahlungskartennetzwerk eine Transaktionsautorisierungsanfrage an die Karteninhaberbank sendet. Eine solche Transaktionsautorisierungsanfrage kann beispielsweise die in 6 gezeigten Transaktionsautorisierungsinformationen umfassen. Die Karteninhaberbank führt dann eine Reihe von Prüfungen durch, z.B. bezüglich der Kartendaten, des Kontostands, der Beschränkungen und des Verhaltens, und genehmigt die Transaktion oder lehnt sie ab.
  • Gemäß der vorliegenden Erfindung wird zusätzlich zur allgemeinen Transaktionsautorisierung dem Transaktionsautorisierungsprozess eine Einkaufsgenehmigungsanfrage hinzugefügt. Die Einkaufsgenehmigung wird gleichzeitig mit der allgemeinen Transaktionsautorisierung durch die Karteninhaberbank ausgeführt. Die Händlerbank muss nicht miteinbezogen oder auch nur darüber informiert werden, dass zusätzlich zur allgemeinen Transaktionsautorisierung eine Einkaufsgenehmigung stattfindet. Wenn der Einkauf nicht genehmigt wird, empfängt die Händlerbank die Information, dass die Transaktion nicht autorisiert wird, aber nicht unbedingt, ob dies auf die Prüfungen, z.B. hinsichtlich der Kartendaten, des Kontostands, der Beschränkungen und des Verhaltens, oder darauf zurückzuführen ist, dass der angefragte Einkauf die Einkaufsregeln nicht erfüllt.
  • Gemäß der vorliegenden Erfindung ist es somit nicht notwendig, Lieferanten/Händler im Einkaufsmanagementsystem einzurichten, bevor Einkäufe getätigt werden, und Lieferanten/Händler müssen in keiner Weise mit irgendeinem Einkaufsmanagementsystem vernetzt sein. Die vorliegende Erfindung ermöglicht es, Informationen bezüglich des Einkaufs selbst dann an das einkaufende Unternehmen zu übertragen, wenn die Lieferanten/Händler in keiner Weise mit dem Einkaufsmanagementsystem vernetzt sind, was bei keinem bekannten System möglich ist.
  • Die vorliegende Offenbarung betrifft Einkaufsmanagementsysteme. Ausführungsformen der offenbarten Lösung sind in Verbindung mit den Figuren genauer dargestellt.
  • 1 zeigt schematisch ein Einkaufsmanagementsystem 100 gemäß einer oder mehreren hierin beschriebenen Ausführungsformen. Das Einkaufsmanagementsystem 100 kann eine zentrale Datenbankanordnung 110, eine Kundenschnittstelle 120 zur zentralen Datenbankanordnung 110 und ein bankspezifisches Datenbankmodul 130 umfassen, das dazu eingerichtet ist, mit einem Transaktionsautorisierungsmodul 520 in einer Karteninhaberbank 500 zu kommunizieren. Die zentrale Datenbankanordnung 110 kann beispielsweise ein Cloud-Dienst sein. Das bankspezifische Datenbankmodul 130 kann in der Karteninhaberbank 500 angeordnet sein, um schnelle Antwortzeiten bei Einkaufsgenehmigungsanfragen zu ermöglichen und es auch zuzulassen, die Art von Transaktionsinformationen, die aus regulatorischen Gründen nicht außerhalb der Firewall der Bank gesendet werden darf, als mit der ersten Transaktions-ID verknüpfte Metadaten dem bankspezifischen Datenbankmodul hinzuzufügen. Es gibt strenge regulatorische Anforderungen für Transaktionsinformationen, die von außerhalb der Bank empfangen und/oder nach draußen gesendet werden dürfen, durch Anordnen des bankspezifischen Datenbankmoduls 130 in der Bank können jedoch auch Transaktionsinformationen, die nicht von außerhalb der Bank empfangen und/oder nach draußen gesendet werden dürfen, in das bankspezifische Datenbankmodul 130 eingegeben werden.
  • Die zentrale Datenbankanordnung 100 kann dazu eingerichtet sein, über die Kundenschnittstelle 120 von einem einkaufenden Unternehmen 200 Einkaufsregeln zu empfangen. Diese Einkaufsregeln können allgemeine Einkaufsregeln für das gesamte einkaufende Unternehmen 200, aber auch Einkaufsregeln sein, die für eine bestimmte Unterabteilung des einkaufenden Unternehmens 200 oder auch für eine einkaufende Person spezifisch sind. Die Kundenschnittstelle 120 kann z.B. eine Webschnittstelle oder eine mobile Anwendung sein.
  • Zentrale Verarbeitungseinrichtungen 115 der zentralen Datenbankanordnung 110 können Transaktions-IDs erzeugen, die bei Transaktionen zu verwenden sind. Diese Transaktions-IDs können einzeln oder stapelweise und basierend auf vordefinierten Regeln oder auf Anfrage des einkaufenden Unternehmens 200 erzeugt werden. Transaktions-IDs können sogar erzeugt werden, bevor Einkaufsregeln definiert werden. Transaktions-IDs können vor der Verwendung eine Aktivierung benötigen.
  • Zu jeder Transaktions-ID können Informationen bezüglich des betreffenden Käufers als Metadaten hinzugefügt werden. Der betreffende Käufer kann beispielsweise als beliebige einkaufende Person in einer Einkaufsgruppe 300 definiert werden. Die Einkaufsgruppe 300 kann eine oder mehrere bestimmte einkaufende Personen umfassen, kann jedoch auch beispielsweise als Unterabteilung des einkaufenden Unternehmens 200 oder als das gesamte einkaufende Unternehmen 200 definiert werden. Die einkaufenden Personen in einer Einkaufsgruppe 300 müssen nicht alle in dem einkaufenden Unternehmen 200 angestellt sein - eine Einkaufsgruppe 300 kann beispielsweise auch Berater oder Subunternehmer des einkaufenden Unternehmens 200 umfassen.
  • Basierend auf den Metadaten bezüglich der Einkaufgruppe 300 können die zentralen Verarbeitungseinrichtungen 115 der zentralen Datenbankanordnung 110 ermitteln, welche Einkaufsregeln für diese spezielle Transaktions-ID gelten und diese Einkaufsregeln als mit der Transaktions-ID verknüpfte Metadaten hinzufügen. Die Einkaufsregeln sind für alle einkaufenden Personen in einer Einkaufsgruppe 300 immer gleich, die Einkaufsgruppen 300 können jedoch dynamisch modifiziert werden, wenn für verschiedene einkaufende Personen in einer Einkaufsgruppe verschiedene Einkaufsregeln notwendig werden. In einem solchen Fall wird einfach für die einkaufenden Personen, die andere Einkaufsregeln benötigen, eine neue Einkaufsgruppe 300 gebildet.
  • Andere Arten von Informationen, die die Transaktion betreffen, können ebenfalls als mit der Transaktions-ID verknüpfte Metadaten der zentralen Datenbankanordnung 110 hinzugefügt werden. Andere Unternehmen als das einkaufende Unternehmen 200 können ebenfalls Zugriff auf die zentrale Datenbankanordnung 110 haben und dazu in der Lage sein, mit der Transaktions-ID verknüpfte Metadaten hinzuzufügen. Das Hinzufügen von Metadaten zur zentralen Datenbankanordnung 110 durch Drittunternehmen 150, die bevorzugt eine spezielle Drittparteischnittstelle 160 verwenden, ist in 2 dargestellt. Die Drittparteischnittstelle 160 kann beispielsweise eine Webschnittstelle oder eine mobile Anwendung sein.
  • Ein solches Drittunternehmen 150 kann beispielsweise ein Kunde des einkaufenden Unternehmens 200 sein, zu dessen Gunsten das einkaufende Unternehmen 200 einen Einkauf tätigt, um ihn an den Kunden weiter zu berechnen. In einem solchen Fall können die Metadaten beispielsweise eine Bestätigung umfassen, dass die Kosten des Einkaufs übernommen werden. Dann ist es vorteilhaft, wenn alle Informationen, die benötigt werden, um dem Kunden eine Rechnung zu stellen, als mit der Transaktions-ID verknüpfte Metadaten hinzugefügt sind, so dass die Rechnungsstellung an den Kunden vereinfacht oder sogar automatisiert werden kann.
  • Ein anderes Beispiel für ein solches Drittunternehmen 150 kann eine Organisation sein, die Informationen über auf einer schwarzen Liste stehende Lieferanten oder Lieferanten bereitstellt, die bestimmte regulatorische Anforderungen nicht erfüllen. Wenn eine solche Organisation diese Informationen als Metadaten allen Transaktions-IDs hinzufügt, können die Einkaufsregeln definieren, dass Einkäufe bei einem durch diese Metadaten definierten Lieferanten/Händler zu keiner Zeit erlaubt sind.
  • Als weiteres Beispiel für ein solches Drittunternehmen 150 ist der Händler/Lieferant 400. Wenn der Händler/Lieferant 400 Zugriff auf die zentrale Datenbankanordnung 110 hat und dazu in der Lage ist, mit der Transaktions-ID verknüpfte Metadaten hinzuzufügen, kann der Händler/Lieferant 400 beispielsweise eine elektronische Quittung als mit der Transaktions-ID verknüpfte Metadaten hinzufügen. Der Händler/Lieferant 400 kann die Drittparteischnittstelle 160 oder eine spezielle Schnittstelle für Händler/Lieferanten 400 verwenden. Eine solche Schnittstelle kann beispielsweise eine Webschnittstelle oder eine mobile Anwendung sein. Eine elektronische Quittung kann jedoch auch durch eine andere Partei hinzugefügt werden, wie z.B. durch eine einkaufende Person in einer Einkaufsgruppe 300, wenn der Händler/Lieferant 400 keinen Zugriff auf die zentrale Datenbankanordnung 110 hat.
  • Einkaufende Personen in Einkaufsgruppen 300 können ebenfalls dazu in der Lage sein, mit der zentralen Datenbankanordnung 110 zu kommunizieren, um Informationen abzurufen und/oder Metadaten hinzuzufügen. Wenn es das einkaufende Unternehmen 200 beispielsweise ermöglichen möchte, Firmenzahlungskarten für private Einkäufe zu verwenden, kann es für die einkaufende Person eine Möglichkeit geben, einen Einkauf als privat zu kennzeichnen und die Kosten automatisch vom nächsten Gehalt abziehen zu lassen. Einkaufende Personen in Einkaufsgruppen 300 können die Drittparteischnittstelle 160 oder eine spezielle Schnittstelle für Einkaufsgruppen 300 verwenden. Eine solche Schnittstelle kann beispielsweise eine Webschnittstelle oder eine mobile Anwendung sein.
  • Die Einkaufsregeln können beispielsweise verlangen, dass die einkaufende Person entweder vor oder nach dem Einkauf der Transaktions-ID bestimmte Metadaten hinzufügt, um die Verwaltung innerhalb des einkaufenden Unternehmens 200 zu vereinfachen. Die einkaufende Person kann beispielsweise angehalten sein, das Konto, die Kostenstelle, das Projekt oder den Gegenstand als mit der Transaktions-ID verknüpfte Metadaten hinzuzufügen. Weitere Anforderungen können dann basierend auf den durch die einkaufende Person hinzugefügten Metadaten für spezielle Arten von Einkäufen gelten. Wenn der Einkauf beispielsweise eine Bewirtung betrifft, etwa einen Restaurantbesuch mit einem Kunden, kann die einkaufende Person angehalten sein, die Namen der anwesenden Personen als mit der Transaktions-ID verknüpfte Metadaten hinzuzufügen. Wenn der Einkauf beispielsweise Geschäftsreisen betrifft, kann die einkaufende Person angehalten sein, das Ziel und/oder den Zweck der Reise anzugeben. Dies ermöglicht eine automatische Verrechnung innerhalb des einkaufenden Unternehmens 200. Die Einkaufsregeln können verlangen, dass diese Metadaten bei einem zu genehmigenden Einkauf hinzugefügt werden. Wenn die Einkaufsregeln verlangen, dass diese Metadaten hinzugefügt werden, kann, sogar noch bevor die einkaufende Person versucht, den Einkauf zu tätigen, die einkaufende Person gewarnt werden, dass der Einkauf abgelehnt wird, wenn diese Metadaten nicht hinzugefügt werden. In diesem Fall wird eine solche Warnung bevorzugt beispielsweise über eine SMS, eine E-Mail oder eine mobile Anwendung an die einkaufende Person kommuniziert.
  • Bestimmte Informationen können jedoch unmöglich hinzugefügt werden, bevor der Einkauf genehmigt wurde. Die einkaufende Person kann beispielsweise angehalten sein, die Quittung als mit der Transaktions-ID verknüpfte Metadaten hinzuzufügen, beispielsweise durch Fotografieren der Quittung unter Verwendung einer mobilen Anwendung. In solchen Situationen hat der Einkauf bereits stattgefunden und kann daher nicht abgelehnt werden, es können jedoch zukünftige Einkäufe für diese einkaufende Person blockiert werden, bis die erforderlichen Metadaten allen früheren Transaktionen hinzugefügt wurden. Diese Blockierung kann manuell durch das einkaufende Unternehmen 200 durchgeführt werden. Die Einkaufsregeln können jedoch beispielsweise vorgeben, dass nach einer bestimmten Zeitspanne oder bei einer bestimmten Anzahl von Einkäufen, bei denen dies nicht durchgeführt wurde, sämtliche weiteren Einkäufe automatisch blockiert werden.
  • Die Einkaufsregeln können bei bestimmten Lieferanten/Händlern auch vorgeben, wie Einkäufe durchgeführt werden können. Sie können beispielsweise aus Kostengründen vorgeben, dass nur webbasierte Einkäufe bei einem bestimmten Lieferanten erlaubt sind, wobei in diesem Fall ein Versuch, in einem physischen Geschäft einen Einkauf zu tätigen, abgelehnt wird. Informationen über den Grund der Ablehnung werden in diesem Fall bevorzugt z.B. über eine SMS, eine E-Mail oder eine mobile Anwendung an die einkaufende Person kommuniziert.
  • Die mit der Transaktions-ID verknüpften Metadaten können an das bankspezifische Datenbankmodul 130 übertragen werden. Es ist nicht erforderlich, sämtliche der Metadaten an das bankspezifische Datenbankmodul 130 zu übertragen, sofern die Einkaufsregeln und alle für sie geltenden Metadaten übertragen werden. Bei einer Ausführungsform jedoch werden sämtliche der Informationen in der zentralen Datenbankanordnung 110 in das bankspezifische Datenbankmodul 130 gespiegelt.
  • Wenn das bankspezifische Datenbankmodul 130 die mit der Transaktions-ID verknüpften Metadaten empfangen hat, kann vom Transaktionsautorisierungsmodul 520 in der Karteninhaberbank 500 eine Einkaufsgenehmigungsanfrage gesendet werden. Die Einkaufsgenehmigungsanfrage umfasst Transaktionsinformationen, die den Transaktionsautorisierungsinformationen entsprechen können, die, wenn die Zahlungskarte zur Zahlung verwendet wird, über das Zahlungskartennetzwerk von der Händlerbank an die Karteninhaberbank 500 gesendet und im Transaktionsautorisierungsmodul 520 empfangen werden. Ein Beispiel für solche Transaktionsautorisierungsinformationen ist in 6 gezeigt. Die Transaktionsinformationen in der Einkaufgenehmigungsanfrage müssen nicht unbedingt sämtliche der Transaktionsautorisierungsinformationen umfassen, sofern sie den Betrag zusammen mit genügend Informationen umfassen, um sie mit der gewünschten Transaktions-ID zu verknüpfen. Wenn die Einkaufsgenehmigungsanfrage die Transaktions-ID nicht umfasst, muss sie daher eine andere Transaktionsinformation umfassen, die es dem bankspezifischen Datenbankmodul 130 ermöglicht, den Einkauf mit einer Transaktions-ID zu verknüpfen, wie z.B. Transaktionsinformationen, die die Einkaufsgruppe 300 identifizieren. Wenn der Einkaufgruppe 300 eine oder mehrere spezifische Zahlungskarten zugeteilt sind, können diese Transaktionsinformationen beispielsweise die Zahlungskartennummer oder ein Token für die Zahlungskartennummer umfassen. Die Bankverarbeitungseinrichtung 135 des bankspezifischen Datenbankmoduls 130 kann dann den Einkauf einfach der nächsten verfügbaren Transaktions-ID für diese Einkaufsgruppe 300 zuordnen.
  • Die Bankverarbeitungseinrichtung 135 des bankspezifischen Datenbankmoduls 130 überprüft dann, ob der angefragte Einkauf die mit der Transaktions-ID verknüpften Einkaufsregeln, d.h. die für die Einkaufsgruppe 300 gelten Einkaufsregeln, erfüllt. Zusätzlich zu den vorstehend angegebenen Beispielen können die Einkaufsregeln beispielsweise einen Maximalbetrag für jeden Einkauf, einen maximalen Gesamtbetrag, die Einhaltung des Budgets oder Beschränkungen betreffen, wo oder wann Einkäufe getätigt werden können (z.B. können internationale Einkäufe oder Einkäufe an Wochenenden blockiert werden). Wenn die Einkaufsgenehmigungsanfrage Händlerinformationen umfasst, wie z.B. den Namen des Händlers oder einen Code zur Identifizierung des Händlers, können die Einkaufsregeln auch bestimmte Händler betreffen, die für die Einkaufsgruppe 300 erlaubt oder blockiert sind. Dies ermöglicht es dem einkaufenden Unternehmen 200, Einkäufe bei ausgewählten Lieferanten/Händlern zu blockieren und nur Einkäufe bei ausgewählten Lieferanten/Händlern zuzulassen. Das einkaufende Unternehmen 200 kann diese Funktionalität beispielsweise dazu verwenden, Einkäufe bei Spirituosenläden, wie etwa Systembolaget, zu blockieren oder nur Einkäufe bei spezifischen Lebensmittelketten, wie etwa ICA und/oder Coop, oder bestimmten Arten von Händlern, wie etwa Lebensmittelgeschäften, zuzulassen.
  • Die Bankverarbeitungseinrichtung 135 des bankspezifischen Datenbankmoduls 130 genehmigt oder lehnt die Einkaufsgenehmigungsanfrage somit basierend darauf ab, ob der angefragte Einkauf die mit der Transaktions-ID verknüpften Einkaufsregeln im bankspezifischen Datenbankmodul 130 erfüllt. Die Bankverarbeitungseinrichtung 135 des bankspezifischen Datenbankmoduls 130 fügt außerdem die vom Transaktionsautorisierungsmodul 520 empfangenen Transaktionsinformationen als mit der Transaktions-ID verknüpfte Metadaten dem bankspezifischen Datenbankmodul 130 hinzu und überträgt diese Transaktionsinformationen an die zentralen Datenbankanordnung 110, wo sie ebenfalls als mit der Transaktions-ID verknüpfte Metadaten hinzugefügt werden. Dies kann entweder vor oder nach dem Senden der Genehmigung/Ablehnung an das Transaktionsautorisierungsmodul 520 stattfinden.
  • Die Transaktionsinformationen werden bevorzugt durch eine Funktionalität in der zentralen Datenbankanordnung 110 in ein anderes Datenformat, bevorzugt ein durch das einkaufende Unternehmen 200 definiertes Datenformat, „übersetzt“ oder umgesetzt. Dies ist nachstehend unter Bezugnahme auf 5 näher erläutert.
  • Basierend auf der von der Bankverarbeitungseinrichtung 135 des bankspezifischen Datenbankmoduls 130 empfangenen Genehmigung/Ablehnung zusammen mit der allgemeinen Transaktionsautorisierung, die durch Überprüfen z.B. der Kartendaten, des Kontostands, der Beschränkungen und des Verhaltens durchgeführt wird, genehmigt das Transaktionsautorisierungsmodul 520 die Transaktion oder lehnt sie ab. Wenn die Bankverarbeitungseinrichtung 135 des bankspezifischen Datenbankmoduls 130 die Transaktion ablehnt, wird das Transaktionsautorisierungsmodul 520 die Transaktion selbst dann ablehnen, wenn die allgemeinen Transaktionsautorisierungsprüfungen zeigen, dass sie zulässig wäre. Ebenso wird, wenn die allgemeinen Transaktionsautorisierungsprüfungen zeigen, dass die Transaktion nicht zulässig wäre, das Transaktionsautorisierungsmodul 520 die Transaktion selbst dann ablehnen, wenn die Bankverarbeitungseinrichtung 135 des bankspezifischen Datenbankmoduls 130 den Einkauf genehmigt. In solchen Situationen kann das Transaktionsautorisierungsmodul 520 nicht einmal eine Einkaufsgenehmigungsanfrage an das bankspezifische Datenbankmodul 130 senden, da die Transaktion in jedem Fall abgelehnt wird.
  • Wenn die allgemeine Transaktionsautorisierung im Transaktionsautorisierungsmodul 520 durchgeführt wird, bevor eine Einkaufsgenehmigungsanfrage an das bankspezifische Datenbankmodul 130 gesendet wird, ist die Bankverarbeitungseinrichtung 135 des bankspezifischen Datenbankmoduls 130 dazu in der Lage, zu bestimmen, ob das Transaktionsautorisierungsmodul 520 die Transaktion genehmigen oder ablehnen wird, wenn die Bankverarbeitungseinrichtung 135 des bankspezifischen Datenbankmoduls 130 darüber entschieden hat, ob die Einkaufsgenehmigungsanfrage genehmigt oder abgelehnt werden soll. Alternativ kann das Transaktionsautorisierungsmodul 520 diese Informationen an das bankspezifische Datenbankmodul 130 übertragen. Informationen darüber, ob die Transaktion durch das Transaktionsautorisierungsmodul 520 genehmigt oder abgelehnt wurde, können als mit der Transaktions-ID verknüpfte Metadaten dem bankspezifischen Datenbankmodul 130 hinzugefügt werden.
  • Andere Arten von Informationen können ebenfalls als mit der Transaktions-ID verknüpfte Metadaten dem bankspezifischen Datenbankmodul 130 hinzugefügt werden. Die Bank 500 kann beispielsweise Informationen über einen mutmaßlichen Betrug, den Transaktionsstatus oder andere ähnliche Arten von Informationen dem bankspezifischen Datenbankmodul 130 zuführen, so dass diese Informationen an die zentrale Datenbankanordnung 110 übertragen werden können.
  • Wenn die zentrale Datenbankanordnung 110 die Transaktionsinformationen als mit der Transaktions-ID verknüpfte Metadaten empfangen hat, kann die zentrale Verarbeitungseinrichtung 115 der zentralen Datenbankanordnung 110 die Transaktionsinformationen an das einkaufende Unternehmen 200 übertragen, bevorzugt in einem durch das einkaufende Unternehmen 200 definierten Dateiformat. Dies ermöglicht es, die Transaktionsinformationen automatisch in Wirtschaftssysteme und/oder andere Verwaltungssysteme des einkaufenden Unternehmens 200 einzugeben. Auf diese Weise kann das einkaufende Unternehmen sämtlichen Transaktionen nachgehen, lange bevor von den Lieferanten/Händlern Rechnungen erhalten werden. Dies ermöglicht es dem einkaufenden Unternehmen 200, zu jeder Zeit den Überblick über sein Budget zu behalten und die Einkaufsregeln entsprechend anzupassen.
  • Einkaufsregeln können aus verschiedenen Gründen angepasst werden. Wenn eine bestimmte Unterabteilung des einkaufenden Unternehmens 200 als eine Einkaufsgruppe 300 betrachtet wird, es jedoch erwünscht ist, die Einkaufsregeln für bestimmte einkaufende Personen in dieser Unterabteilung anzupassen, beispielsweise um für eine bestimmte einkaufende Person mehr Beschränkungen hinzuzufügen (oder sogar alle Einkäufe zu blockieren), kann für diese einkaufende Person eine neue Einkaufgruppe 300 mit stärker eingeschränkten Einkaufsregeln als für den Rest der Unterabteilung erzeugt werden. Sowohl die Einkaufsgruppen 300 als auch die Einkaufsregeln können somit durch das einkaufende Unternehmen 200 dynamisch aktualisiert werden.
  • Das einkaufende Unternehmen 200 muss nicht unbedingt tatsächliche Einkaufsgruppen im System definieren. Stattdessen kann das einkaufende Unternehmen 200 beispielsweise auf mehreren hierarchischen Ebenen Einkaufsregeln definieren. Einige der Regeln können allgemein für die gesamte Organisation gelten, während andere Regeln für manche Personen oder Gruppen von Personen spezifisch sein können. Im Rahmen dieser Anmeldung ist eine Einkaufsgruppe 300 eine Gruppe aus einer oder mehreren einkaufenden Personen, für die dieselben Einkaufsregeln gelten.
  • Die Felder in der zentralen Datenbankanordnung 110, die es zulassen, Metadaten mit den Transaktions-IDs zu verknüpfen, können auch dynamisch durch das einkaufende Unternehmen 200 eingestellt werden, so dass das einkaufende Unternehmen 200 die gewünschten Metadaten und das Dateiformat für diese Metadaten definieren kann. Dies erlaubt es beispielsweise, Metadaten bezüglich Kostenstellen, Konten und anderen Rechnungslegungsinformationen in der zentralen Datenbankanordnung 110 mit den Transaktions-IDs zu verknüpfen. Dies ermöglicht es dem einkaufenden Unternehmen 200, die Metadaten, die es erhalten möchte, und das Format, in dem es eine elektronische Rechnung erhalten möchte, zu definieren, um es dadurch zu ermöglichen, diese Metadaten aus der zentralen Datenbankanordnung 100 abzurufen und einer elektronischen Rechnung hinzuzufügen. Eine solche elektronische Rechnung kann von der Bank 500, der zentralen Datenbankanordnung 110 oder einer dritten Partei gesendet werden. Wenn die unter Verwendung des Systems 100 für die Transaktionen erstellte Rechnung eine elektronische Rechnung ist, die durch das einkaufende Unternehmen 200 vorgegebene Metadaten umfasst, ermöglicht dies eine automatische Abwicklung der Rechnung durch das einkaufende Unternehmen 200, wodurch beim Verwaltungsaufwand enorme Einsparungen ermöglicht werden.
  • Die vorliegende Erfindung kann beispielsweise Zahlungskarten verwenden, um die Zahlungen auszuführen. Informationen über die einkaufenden Personen können in diesem Fall, wie in 3 gezeigt, von der zentralen Datenbankanordnung 110 an ein Zahlungskarten ausgebendes Unternehmen 600 übertragen werden. Diese Übertragung kann direkt zwischen der zentralen Datenbankanordnung 110 und dem Zahlungskarten ausgebenden Unternehmen 600 stattfinden oder über ein Zahlungskartenverwaltungsmodul 510 in der Bank 500 ausgeführt werden. Das Zahlungskarten ausgebende Unternehmen 600 kann mit der Bank 500 vernetzt sein, kann aber auch ein separates Zahlungskarten ausgebendes Unternehmen 600 sein.
  • Um mit den Zahlungskarten durchgeführte Zahlungen mit den die Einkäufe tätigenden einkaufenden Personen zu verbinden, werden Informationen über die Zahlungskarten bevorzugt von dem Zahlungskarten ausgebenden Unternehmen 600 entweder direkt oder über das Zahlungskartenverwaltungsmodul 510 in der Bank 500 an die zentrale Datenbankanordnung 110 übertragen. Die Informationen sind bevorzugt nicht die tatsächlichen Kreditkartennummern, da es dahingehend Beschränkungen geben kann, ob es zulässig ist, diese als mit der Transaktions-ID verknüpfte Metadaten in der zentralen Datenbankanordnung 110 zu speichern. Die Informationen können stattdessen beispielsweise Token für die Kreditkartennummern sein.
  • 4 zeigt ein beispielhaftes Flussdiagramm eines Einkaufsmanagementverfahrens. Der Ablauf ist wie folgt:
    • Schritt 410: Das einkaufende Unternehmen 200 konfiguriert seine Einkaufsregeln in der zentralen Datenbankanordnung 110 (dies könnte an jedem beliebigen Punkt vor Schritt 460 stattfinden und Metadaten können an jedem Punkt während des Ablaufs durch das einkaufende Unternehmen 200 hinzugefügt werden).
    • Schritt 415: Die zentrale Datenbankanordnung 110 bestellt Kartenkonten für das einkaufende Unternehmen 200 bei der Karteninhaberbank 500.
    • Schritt 420: Die Karteninhaberbank 500 bestellt Zahlungskarten bei dem Zahlungskarten ausgebenden Unternehmen 600.
    • Schritt 425: Zusätzliche Informationen, wie etwa eine Personalisierung von Karten, Logos oder dergleichen, können dem Zahlungskarten ausgebenden Unternehmen 600 durch die zentrale Datenbankanordnung 110 zugeführt werden. Zahlungskarten können durch die zentrale Datenbankanordnung 110 auch direkt bei dem Zahlungskarten ausgebenden Unternehmen 600 bestellt werden.
    • Schritt 430: Zahlungskarten werden vom Zahlungskarten ausgebenden Unternehmen 600 an die einkaufenden Personen 300 gesendet (die Verteilung kann das einkaufende Unternehmen 200 miteinbeziehen).
    • Schritt 435 (optional): Eine einkaufende Person 300 fügt auf einen Einkauf bezogene Metadaten über eine Benutzerschnittstelle der zentralen Datenbankanordnung 110 hinzu (dies könnte an jedem beliebigen Punkt während des Ablaufs stattfinden).
    • Schritt 440: Transaktions-IDs und mit diesen verknüpfte Metadaten, wie etwa Einkaufsregeln, werden von der zentralen Datenbankanordnung 110 an das bankspezifische Datenbankmodul 130 übertragen.
    • Schritt 445: Eine einkaufende Person tätigt einen Einkauf bei einem Händler/Lieferanten 400. Schritt 450: Die Händlerbank 550 empfängt Informationen über den Einkauf vom Händler/Lieferanten 400.
    • Schritt 455: Die Händlerbank 550 fordert die Karteninhaberbank 500 auf, die Transaktion z.B. über ein Zahlungskartennetzwerk, wie etwa VISA oder MasterCard, zu autorisieren.
    • Schritt 460: Die Karteninhaberbank 500 fordert vom bankspezifischen Datenbankmodul 130 eine Einkaufsgenehmigung an.
    • Schritt 465: Das bankspezifische Datenbankmodul 130 sendet eine Einkaufsgenehmigung an die Karteninhaberbank 500.
    • Schritt 470: Die Karteninhaberbank 500 sendet eine Transaktionsautorisierung an die Händlerbank 550.
    • Schritt 475: Die Händlerbank 550 sendet eine Transaktionserlaubnis an den Händler/Lieferanten 400.
    • Schritt 480: Das bankspezifische Datenbankmodul 130 überträgt Transaktionsinformationen bezüglich des genehmigten Einkaufs an die zentrale Datenbankanordnung 110 (dies könnte an jedem beliebigen Punkt nach Schritt 460 stattfinden).
    • Schritt 485: Die zentrale Datenbankanordnung 110 überträgt die Transaktionsinformationen an das einkaufende Unternehmen 200.
    • Schritt 490 (optional): Drittparteien fügen der Transaktion Metadaten hinzu (dies könnte an jedem beliebigen Punkt während des Ablaufs stattfinden).
  • 5 zeigt schematisch einen Teil eines Einkaufsmanagementsystems 100 gemäß einer oder mehreren hierin beschriebenen Ausführungsformen. Die zentrale Datenbankanordnung 110 verwendet bevorzugt eine dynamische Konfiguration der „Metadatenträger“, die es erlauben, Metadaten mit den Transaktions-IDs zu verknüpfen, so dass ein einkaufendes Unternehmen 200 die gewünschten Metadaten und das Format für diese Metadaten definieren kann. Wie vorstehend in Bezug auf die 1 bis 3 erläutert, kann die zentrale Datenbankanordnung 110 mit zahlreichen anderen Parteien, wie z.B. einkaufenden Unternehmen 200, einkaufenden Personen oder Einkaufgruppen 300, Händlern/Lieferanten 400, Karteninhaberbanken 500, Zahlungskarten ausgebenden Unternehmen 600 und verschiedenen anderen Drittparteiunternehmen 150, interagieren und kommunizieren. Damit die zentrale Datenbankanordnung 110 von diesen Parteien Daten erheben und Daten an diese und von diesen Parteien übertragen kann, muss die zentrale Datenbankanordnung 110 eine Funktionalität, z.B. in Form von „Adaptern“ umfassen, um das durch jede dieser verschiedenen Parteien verwendete Datenformat in ein einzelnes Datenformat, bevorzugt ein durch das einkaufende Unternehmen 200 definiertes Datenformat, zu „übersetzen“ oder umzusetzen. Die zentrale Datenbankanordnung 110 muss für jede Partei 200, 300, 400, 500, 600, 150 einen spezifischen Adapter 205, 305, 405, 505, 605, 155 umfassen, da verschiedene Parteien für gewöhnlich verschiedene Datenformate verwenden (wenn mehrere verschiedene Drittparteien 150 vorhanden sind, werden im Allgemeinen mehrere verschiedene Adapter 155 benötigt). Dies ermöglicht es dem einkaufenden Unternehmen 200, sowohl die Metadaten, die es von den verschiedenen Parteien erhalten möchte, als auch das Datenformat dieser Metadaten zu definieren.
  • Anwendungsfall
  • Zur weiteren Beschreibung der Erfindung wird der folgende Anwendungsfall angegeben. Das einkaufende Unternehmen, Acompany, umfasst die Unterabteilungen Kundendienst, Entwicklung, Vertrieb und Verwaltung. Acompany definiert seine Einkaufsstrategien und - regeln über eine Kundenschnittstelle 120 zu einer zentralen Datenbankanordnung 110 und bestellt Zahlungskarten für alle seine einkaufenden Personen bei seiner Bank, Cardbank. Manche der einkaufenden Personen haben persönliche Zahlungskarten, während andere gemeinschaftliche Zahlungskarten haben.
  • Acompany definiert seine Unterabteilung Kundendienst als Einkaufgruppe Kundendienst, in der für alle Mitarbeiter dieselben Einkaufsregeln gelten. Da die Kundendienstmitarbeiter zur Bereitstellung eines unverzüglichen Kundendiensts bei defekten Geräten dazu in der Lage sein müssen, viel und kurzfristig zu reisen, haben alle einkaufenden Personen in der Einkaufgruppe Kundendienst persönliche Zahlungskarten und die Einkaufsregeln für die Einkaufsgruppe Kundendienst weisen sehr wenige Beschränkungen auf. Acompany gleicht jedoch ständig alle Einkäufe mit dem Kundendienstbudget ab und kann die Einkaufsregeln im Laufe der Zeit aufgrund von Budgeteinschränkungen anpassen.
  • Acompany definiert seine Unterabteilung Entwicklung als Einkaufsgruppe Entwicklung, die deutlich mehr Beschränkungen hat. Die Entwicklungsmitarbeiter umfassen sowohl Angestellte als auch Berater von Acompany. Den Entwicklungsmitarbeitern ist es nicht erlaubt, Einkäufe zu tätigen, die nicht vorab durch den Entwicklungsleiter genehmigt wurden. Manche der Entwicklungsmitarbeiter haben persönliche Zahlungskarten, es gibt aber auch mehrere gemeinschaftliche Karten für die Einkaufsgruppe Entwicklung.
  • Acompany definiert seine Unterabteilung Vertrieb als zwei verschiedene Einkaufsgruppen, lokaler Vertrieb und globaler Vertrieb. Die Einkaufsgruppe lokaler Vertrieb reist normalerweise nicht ins Ausland und die Einkaufsregeln können somit auf Einkäufe im Land beschränkt sein. Die Einkaufsgruppe globaler Vertrieb hingegen reist viel und kann daher in den Einkaufsregeln deutlich weniger Beschränkungen haben. Die Einkaufsregeln können jedoch beispielsweise besagen, dass eine Vorabgenehmigung erforderlich ist, wenn ein Hotel ausgewählt wird, das sich nicht auf der Liste von Hotels und Hotelketten befindet, mit denen Acompany Tarife ausgehandelt hat. Alle Vertriebsmitarbeiter haben persönliche Zahlungskarten.
  • Acompany definiert seine Unterabteilung Verwaltung als Einkaufsgruppe Verwaltung. Verwaltungsmitarbeiter müssen dazu in der Lage sein, kleinere Einkäufe, wie z.B. Büromaterial und Mittagessen, tätigen zu können und die Einkaufsregeln können daher beispielsweise im Hinblick auf Beträge und Lieferanten beschränkt sein. Die Einkaufsgruppe Verwaltung hat eine gemeinschaftliche Zahlungskarte.
  • Wenn ein Kundendienstmitarbeiter versucht, mit der Zahlungskarte einen Einkauf zu tätigen, sendet die Händlerbank über das Zahlungskartennetzwerk eine Transaktionsautorisierungsanfrage, die z.B. die in 6 gezeigten Transaktionsautorisierungsinformationen umfasst, an Cardbank. Das Transaktionsautorisierungsmodul 520 von Cardbank empfängt die Transaktionsautorisierungsanfrage und führt eine Reihe von Prüfungen durch, z.B. bezüglich der Kartendaten, des Kontostands, der Beschränkungen und des Verhaltens. Wenn das Transaktionsautorisierungsmodul 520 von Cardbank basierend auf diesen Prüfungen entscheidet, die Transaktion zu genehmigen, sendet es eine Einkaufsgenehmigungsanfrage an eine bankspezifische Datenbank 130 in der Cardbank, wo Transaktions-IDs mit Metadaten verknüpft gespeichert sind.
  • Da alle Kundendienstmitarbeiter dieselben Einkaufsregeln haben, kann die bankspezifische Datenbank 130 den Einkauf der nächsten in der Datenbank verfügbaren Transaktions-ID zuordnen, die für die Einkaufsgruppe Kundendienst gekennzeichnet ist. Dass der Einkauf die Einkaufgruppe Kundendienst betrifft, kann in diesem Fall beispielsweise unter Verwendung der Zahlungskartennummer bestimmt werden. Eine spezifische Transaktions-ID kann stattdessen jedoch bereits durch den Kundendienstmitarbeiter ausgewählt worden sein, der bereits mit dieser Transaktions-ID verknüpfte Metadaten hinzugefügt haben kann. Die Einkaufsregeln für Kundendienstmitarbeiter sind als mit der Transaktions-ID verknüpfte Metadaten gespeichert, so dass die bankspezifische Datenbank 130 über die Einkaufsgenehmigungsanfrage entscheidet, indem sie diese basierend darauf, ob der angefragte Einkauf die Kundendiensteinkaufsregeln erfüllt, genehmigt oder ablehnt. Da es bei den Kundendiensteinkaufsregeln nur sehr wenige Beschränkungen gibt, sind die meisten Einkäufe zulässig. Die bankspezifische Datenbank 130 speichert die Transaktionsinformationen als mit der Transaktions-ID verknüpfte Metadaten und überträgt diese Metadaten an die zentrale Datenbankanordnung 110. Die zentrale Datenbankanordnung 110 überträgt dann die Transaktionsinformationen an Acompany, so dass die Informationen über den Einkauf automatisch bei Acompany in Wirtschafts- und andere Verwaltungssysteme eingegeben werden können.
  • Wenn Entwicklungsmitarbeiter Einkäufe tätigen, wird ein ähnlicher Ablauf befolgt. Da es Entwicklungsmitarbeitern jedoch nicht erlaubt ist, Einkäufe zu tätigen, die nicht vorab durch den Entwicklungsleiter genehmigt wurden, ist eine Vorabgenehmigung des Einkaufs erforderlich. Ein Entwicklungsmitarbeiter, der einen Einkauf tätigen möchte, verwendet die ausgewiesene Schnittstelle für Einkaufsgruppen 300 (z.B. eine Webschnittstelle oder eine mobile Anwendung) dazu, eine Transaktions-ID zu erhalten und gibt die erforderlichen diesen Einkauf betreffenden Metadaten über die Schnittstelle in die zentrale Datenbankanordnung 110 ein. Dann wird für den Entwicklungsleiter eine Aktion zur Vorabgenehmigung dieses Einkaufs eingestellt. Dies kann einfach eine im System definierte Aktion sein, es kann aber auch z.B. per SMS oder E-Mail automatisch eine Erinnerung an den Leiter gesendet werden. Sobald der Entwicklungsleiter den Einkauf genehmigt hat, lassen ihn die Einkaufsregeln zu.
  • Wenn Vertriebsmitarbeiter Einkäufe tätigen, wird ein ähnlicher Ablauf befolgt. Wie bei den Kundendienstmitarbeitern hat die Einkaufsgruppe globaler Vertrieb nur wenige Beschränkungen. Es kann jedoch erwünscht sein, die Einkaufsregeln für eine Person oder eine Gruppe von Personen im globalen Vertrieb zu ändern, beispielsweise wenn sich herausstellt, dass eine Bewirtung ein wenig zu extravagant geraten ist. Dann kann eine neue Einkaufsgruppe mit stärkeren Beschränkung beispielsweise bezüglich der Kosten einer Bewirtung definiert werden, so dass die vorherige Einkaufsgruppe globaler Vertrieb beispielsweise in die zwei Gruppen standardmäßiger globaler Vertrieb und eingeschränkter globaler Vertrieb aufgeteilt wird.
  • Wenn Verwaltungsmitarbeiter Einkäufe tätigen, wird ebenfalls ein ähnlicher Ablauf befolgt. Verwaltungsmitarbeiter haben jedoch deutlich strengere Beschränkungen, beispielsweise Beschränkungen im Hinblick auf zulässige Lieferanten/Händler. Die vom Transaktionsautorisierungsmodul 520 von Cardbank gesendeten Transaktionsinformationen umfassen auch Händlerinformationen, z.B. den Namen des Händlers oder einen Code zur Identifizierung des Händlers, so dass die bankspezifische Datenbank 130 gemäß den Einkaufsregeln die Händlerinformationen mit den zulässigen Händlern abgleichen kann. Verwaltungsmitarbeiter können auf bestimmte Lieferanten/Händler, wie z.B. ICA und/oder Coop, oder bestimmte Händlerarten, wie z.B. Lebensmittelgeschäfte, beschränkt sein. Die VISA-Händlerkategorienklassifizierung (MCC/Merchant Category Classification) verwendet z.B. den MCC-Code 5499 für „Verschiedene Lebensmittelgeschäfte - Gemischtwarenläden und Fachgeschäfte“, wobei dieser Code im Händleridentifizierungscode in den Transaktionsautorisierungsinformationen enthalten ist. Wenn Verwaltungsmitarbeiter Lebensmittel in einem Lebensmittelgeschäft einkaufen, können für verschiedene Warenarten viele verschiedene Mehrwertsteuersätze gelten. Die verschiedenen Mehrwertsteuersätze für die verschiedenen Posten des Einkaufs können dann automatisch als mit der Transaktions-ID verknüpfte Metadaten gespeichert werden, um die Verwaltung im einkaufenden Unternehmen 200 zu vereinfachen.
  • 7 zeigt schematisch ein Einkaufsmanagementverfahren 700. Das Verfahren 700 kann umfassen:
    • Schritt 710: Eingeben von für eine Einkaufsgruppe 300 geltenden Einkaufsregeln in eine zentrale Datenbankanordnung 110 über eine Kundenschnittstelle 120.
    • Schritt 720: Hinzufügen einer ausgewählten Einkaufsgruppe 300 als mit einer ersten Transaktions-ID verknüpfte Metadaten zur zentralen Datenbankanordnung 110.
    • Schritt 725: Hinzufügen der für die Einkaufsgruppe 300 geltenden Einkaufsregeln als mit der ersten Transaktions-ID verknüpfte Metadaten zur zentralen Datenbankanordnung 110.
    • Schritt 730: Übertragen der mit der ersten Transaktions-ID verknüpften Metadaten von der zentralen Datenbankanordnung 110 an ein bankspezifisches Datenbankmodul 130.
    • Schritt 740: Empfangen einer mit der ersten Transaktions-ID verknüpften ersten Transaktionsautorisierungsanfrage in einem in einer Bank 500 angeordneten Transaktionsautorisierungsmodul 520, wobei die erste Transaktionsautorisierungsanfrage Transaktionsautorisierungsinformationen umfasst.
    • Schritt 750: Kommunizieren einer Einkaufsgenehmigungsanfrage vom Transaktionsautorisierungsmodul 520 an das bankspezifische Datenbankmodul 130, wobei die Einkaufsgenehmigungsanfrage Transaktionsinformationen umfasst, die zumindest den Einkaufsbetrag enthalten.
    • Schritt 760: Entscheiden über die Einkaufsgenehmigungsanfrage durch Genehmigen oder Ablehnen derselben basierend darauf, ob der angefragte Einkauf die mit der ersten Transaktion-ID verknüpften Einkaufsregeln im bankspezifischen Datenbankmodul 130 erfüllt.
    • Schritt 765: Antworten an das Transaktionsautorisierungsmodul 520 mit der Genehmigung oder Ablehnung der Einkaufgenehmigungsanfrage.
    • Schritt 770: Antworten auf die mit der ersten Transaktions-ID verknüpfte erste Transaktionsautorisierungsanfrage durch das Transaktionsautorisierungsmodul 520.
    • Schritt 780: Hinzufügen der vom Transaktionsautorisierungsmodul 520 empfangenen Transaktionsinformationen als mit der ersten Transaktions-ID verknüpfte Metadaten zum bankspezifischen Datenbankmodul 130.
    • Schritt 785: Übertragen der mit der ersten Transaktions-ID verknüpften Transaktionsinformationen an die zentrale Datenbankanordnung 110.
    • Schritt 790: Übertragen der mit der ersten Transaktions-ID verknüpften Transaktionsinformationen an das einkaufende Unternehmen 200, so dass die Informationen bezüglich des Einkaufs automatisch in wenigstens ein Verwaltungssystem des einkaufenden Unternehmens 200 eingegeben werden können.
  • Bei manchen Ausführungsformen ist das bankspezifische Datenbankmodul 130 in der Bank 500 angeordnet. Dies ermöglicht schnelle Antwortzeiten bei Einkaufsgenehmigungsanfragen und es lässt auch zu, die Art von Transaktionsinformationen, die aus regulatorischen Gründen nicht außerhalb der Firewall der Bank gesendet werden darf, als mit der ersten Transaktions-ID verknüpfte Metadaten dem bankspezifischen Datenbankmodul 130 hinzuzufügen. Es gibt strenge regulatorische Anforderungen für Transaktionsinformationen, die von außerhalb der Bank empfangen und/oder nach draußen gesendet werden dürfen, durch Anordnen des bankspezifischen Datenbankmodul 130 in der Bank können jedoch auch Transaktionsinformationen, die nicht von außerhalb der Bank empfangen und/oder nach draußen gesendet werden dürfen, in das bankspezifische Datenbankmodul 130 eingegeben werden.
  • Bei manchen Ausführungsformen umfasst die Einkaufsgruppe 300 wenigstens eine einkaufende Person. Dies ermöglicht es, für eine oder mehrere bestimmte einkaufende Personen oder Unterabteilungen des einkaufenden Unternehmens, die eine oder die mehreren einkaufenden Personen umfassen, Einkaufsregeln zu definieren und an diese anzupassen.
  • Bei manchen Ausführungsformen umfasst die Einkaufsgruppe 300 das gesamte einkaufende Unternehmen 200. Dies ermöglicht es dem einkaufenden Unternehmen, für das gesamte Unternehmen allgemeine Einkaufsregeln zu definieren.
  • Bei manchen Ausführungsformen sind die Einkaufsregeln allgemeine Einkaufsregeln für eine Unterabteilung des einkaufenden Unternehmens 200 und das Hinzufügen 725 der für die Einkaufsgruppe 300 geltenden Einkaufsregeln als mit der ersten Transaktions-ID verknüpfte Metadaten zur zentralen Datenbankanordnung 110 umfasst eine Bestimmung, zu welcher Unterabteilung die Einkaufsgruppe 300 gehört.
  • Bei manchen Ausführungsformen umfassen die Transaktionsinformationen Händlerinformationen, wie z.B. den Namen des Händlers oder einen Code zur Identifizierung des Händlers, und das Entscheiden 760 über die Einkaufsgenehmigungsanfrage durch Genehmigen oder Ablehnen derselben basiert ferner auf den Händlerinformationen.
  • Bei manchen Ausführungsformen geben die Einkaufsregeln vor, dass bestimmte Metadaten verknüpft mit der Transaktions-ID der zentralen Datenbankanordnung 110 hinzugefügt werden müssen, bevor ein Einkauf getätigt wird und das Entscheiden 760 über die Einkaufsgenehmigungsanfrage umfasst das Ablehnen der Einkaufgenehmigungsanfrage, wenn diese Metadaten nicht verknüpft mit der Transaktions-ID im bankspezifischen Datenbankmodul 130 vorhanden sind.
  • Bei manchen Ausführungsformen umfassen das Übertragen 730 von mit der ersten Transaktions-ID verknüpften Metadaten von der zentralen Datenbankanordnung 110 an das bankspezifische Datenbankmodul 130 und das Übertragen 785 der mit der ersten Transaktions-ID verknüpften Transaktionsinformationen an die zentrale Datenbankanordnung 110 das Synchronisieren der zentralen Datenbankanordnung 100 und des bankspezifischen Datenbankmoduls 130, so dass sie gespiegelte Versionen voneinander darstellen.
  • Bei manchen Ausführungsformen ist die zentrale Datenbankanordnung 110 dazu eingerichtet, mit mehreren verschiedenen Parteien 200, 300, 400, 500, 600, 150 zu kommunizieren, und umfasst Adapter 205, 305, 405, 505, 605, 155, die das durch jede dieser verschiedenen Parteien verwendete Datenformat in ein einzelnes Datenformat, bevorzugt ein durch das einkaufende Unternehmen 200 definiertes Datenformat, umsetzt.
  • Das Verfahren 700 kann ferner umfassen:
    • Schritt 705: Übertragen von Informationen von der zentralen Datenbankanordnung 110 entweder direkt oder über ein Zahlungskartenverwaltungsmodul 510 in der Bank 500 an ein Zahlungskarten ausgebendes Unternehmen 600, so dass das Zahlungskarten ausgebende Unternehmen 600 an das einkaufende Unternehmen 200 Zahlungskarten ausgeben kann.
  • Die vorstehende Offenbarung soll die vorliegende Erfindung nicht auf die offenbarten exakten Anwendungsformen oder speziellen Anwendungsgebiete beschränken. Es ist zu berücksichtigen, dass verschiedene alternative Ausführungsformen und/oder Modifikationen der vorliegenden Erfindung, ob sie hierin nun explizit beschrieben oder impliziert sind, im Lichte der Offenbarung möglich sind. In dieser Offenbarung ist eine Ausführungsform der Erfindung beschrieben, die Zahlungskarten verwendet. Die Erfindung ist jedoch nicht auf Ausführungsformen beschränkt, die Zahlungskarten verwenden, sondern deckt auch andere Zahlungswege ab, wie z.B. Zahlungen mit Smartphones oder anderen Geräten, die z.B. QR-, EAN- oder PIN-Codes verwenden. Folglich ist der Umfang der Erfindung ausschließlich durch die Ansprüche definiert.
  • Außerdem müssen nicht alle Schritte der Ansprüche in der aufgeführten Reihenfolge durchgeführt werden. Beispielsweise müssen die Einkaufsregeln nicht vor der Erzeugung einer Transaktions-ID in die zentrale Datenbankanordnung 110 eingegeben werden. Ferner können, wenn das einkaufende Unternehmen 200 die Einkaufsregeln ändert und neue Einkaufsregeln in die zentrale Datenbankanordnung 110 eingibt, die auf die Einkaufsregeln bezogenen Metadaten, die in der zentralen Datenbankanordnung 110 mit einer Transaktions-ID verknüpft werden, aktualisiert und an das bankspezifische Datenbankmodul 130 übertragen werden, bis für die Transaktions-ID eine Einkaufsgenehmigungsanfrage genehmigt oder abgelehnt wurde. Bei einem anderen Beispiel können die Transaktionsinformationen entweder vor oder nach der Genehmigung/Ablehnung der Einkaufgenehmigungsanfrage als mit der Transaktions-ID verknüpfte Metadaten hinzugefügt werden. Alle technisch bedeutsamen Reihenfolgen der Schritte sind durch die Ansprüche abgedeckt.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • US 7319986 [0002, 0003, 0004, 0005]

Claims (20)

  1. Einkaufsmanagementsystem (100), das eine zentrale Datenbankanordnung (110), eine Kundenschnittstelle (120) zur zentralen Datenbankanordnung (110) und ein bankspezifisches Datenbankmodul (130) umfasst, das dazu eingerichtet ist, mit einem Transaktionsautorisierungsmodul (520) in einer Bank (500) zu kommunizieren, -wobei die zentrale Datenbankanordnung (110) dazu eingerichtet ist, über die Kundenschnittstelle (120) von einem einkaufenden Unternehmen (200) Einkaufsregeln zu empfangen, die für eine Einkaufsgruppe (300) gelten, und zentrale Verarbeitungseinrichtungen (115) umfasst, die dazu eingerichtet sind, - eine ausgewählte Einkaufsgruppe (300) als mit einer ersten Transaktions-ID (Transaktionskennung) verknüpfte Metadaten der zentralen Datenbankanordnung (110) hinzuzufügen, - die für die Einkaufsgruppe (300) geltenden Einkaufsregeln als mit der ersten Transaktions-ID verknüpfte Metadaten der zentralen Datenbankanordnung (110) hinzuzufügen und - mit der ersten Transaktions-ID verknüpfte Metadaten an das bankspezifische Datenbankmodul (130) zu übertragen, - wobei das bankspezifische Datenbankmodul (130) dazu eingerichtet ist, vom Transaktionsautorisierungsmodul (520) eine Einkaufsgenehmigungsanfrage zu empfangen, die Transaktionsinformationen umfasst, welche zumindest den Einkaufsbetrag enthalten und mit der ersten Transaktions-ID verknüpft sind, und Bankverarbeitungseinrichtungen (135) umfasst, die dazu eingerichtet sind: - basierend darauf, ob der angefragte Einkauf die mit der ersten Transaktions-ID verknüpften Einkaufsregeln im bankspezifischen Datenbankmodul (130) erfüllt, über die Einkaufgenehmigungsanfrage durch Genehmigen oder Ablehnen derselben zu entscheiden, - dem Transaktionsautorisierungsmodul (520) mit der Genehmigung oder Ablehnung der Einkaufgenehmigungsanfrage zu antworten, - die vom Transaktionsautorisierungsmodul (520) empfangenen Transaktionsinformationen als mit der ersten Transaktions-ID verknüpfte Metadaten dem bankspezifischen Datenbankmodul (130) hinzuzufügen und - die mit der ersten Transaktions-ID verknüpften Transaktionsinformationen an die zentrale Datenbankanordnung (110) zu übertragen, und - wobei die zentralen Verarbeitungseinrichtungen (115) der zentralen Datenbankanordnung (110) ferner dazu eingerichtet sind, die mit der ersten Transaktions-ID verknüpften Transaktionsinformationen an das einkaufende Unternehmen (200) zu übertragen, so dass die Informationen bezüglich des Einkaufs automatisch in wenigstens ein Verwaltungssystem des einkaufenden Unternehmens (200) eingegeben werden können.
  2. System (100) nach Anspruch 1, wobei das bankspezifische Datenbankmodul (130) in der Bank (500) angeordnet ist.
  3. System (100) nach Anspruch 1 oder 2, wobei die Einkaufsregeln Einkaufsregeln sind, die für eine Einkaufsgruppe (300) gelten, die wenigstens eine einkaufende Person umfasst.
  4. System (100) nach einem der Ansprüche 1 bis 3, wobei die Einkaufsregeln Einkaufsregeln sind, die für eine Einkaufsgruppe (300) gelten, die das gesamte einkaufende Unternehmen (200) umfasst.
  5. System (100) nach einem der Ansprüche 1 bis 4, wobei die Einkaufsregeln allgemeine Einkaufsregeln für eine Unterabteilung des einkaufenden Unternehmens (200) sind und die zentralen Verarbeitungseinrichtungen (115) der zentralen Datenbankanordnung (110) dazu eingerichtet sind, basierend auf einer Bestimmung, zu welcher Unterabteilung die Einkaufsgruppe (300) gehört, für die Einkaufsgruppe (300) geltende Einkaufsregeln als mit der ersten Transaktions-ID verknüpfte Metadaten der zentralen Datenbankanordnung (110) hinzuzufügen.
  6. System nach einem der Ansprüche 1 bis 5, wobei die Transaktionsinformationen Händlerinformationen umfassen, und wobei die Bankverarbeitungseinrichtungen (135) des bankspezifischen Datenbankmoduls (130) dazu eingerichtet sein, basierend auf den Händlerinformationen über die Einkaufgenehmigungsanfrage durch Genehmigen oder Ablehnen derselben zu entscheiden.
  7. System nach einem der Ansprüche 1 bis 6, wobei die Einkaufsregeln vorgeben, dass bestimmte Metadaten verknüpft mit der Transaktions-ID der zentralen Datenbankanordnung (110) hinzugefügt werden müssen, bevor ein Einkauf getätigt wird, und wobei die Bankverarbeitungseinrichtungen (135) des bankspezifischen Datenbankmoduls (130) dazu eingerichtet sind, die Einkaufsgenehmigungsanfrage abzulehnen, wenn diese Metadaten nicht verknüpft mit der Transaktions-ID im bankspezifischen Datenbankmodul (130) vorhanden sind.
  8. System nach einem der Ansprüche 1 bis 7, wobei die zentralen Verarbeitungseinrichtungen (115) der zentralen Datenbankanordnung (110) ferner dazu eingerichtet sind, entweder direkt oder über ein Zahlungskartenverwaltungsmodul (510) in der Bank (500) Informationen an ein Zahlungskarten ausgebendes Unternehmen (600) zu übertragen, das an das einkaufende Unternehmen (200) Zahlungskarten ausgibt.
  9. System nach einem der Ansprüche 1 bis 8, wobei das System so eingerichtet ist, dass die zentrale Datenbankanordnung (110) und das bankspezifische Datenbankmodul (130) synchronisiert werden, so dass sie gespiegelte Versionen voneinander darstellen.
  10. System nach einem der Ansprüche 1 bis 9, wobei die zentrale Datenbankanordnung (110) dazu eingerichtet ist, mit mehreren verschiedenen Parteien (200, 300, 400, 500, 600, 150) zu kommunizieren, und Adapter (205, 305, 405, 505, 605, 155) umfasst, die das durch jede dieser verschiedenen Parteien verwendete Datenformat in ein einzelnes Datenformat, bevorzugt ein durch das einkaufende Unternehmen (200) definiertes Datenformat, umsetzen.
  11. Einkaufsmanagementverfahren (700), das umfasst: - Eingeben (710) von für eine Einkaufsgruppe (300) geltenden Einkaufsregeln in eine zentrale Datenbankanordnung (110) über eine Kundenschnittstelle (120), - Hinzufügen (720) einer ausgewählten Einkaufsgruppe (300) als mit einer ersten Transaktions-ID (Transaktionskennung) verknüpfte Metadaten zur zentralen Datenbankanordnung (110), - Hinzufügen (725) der für die Einkaufsgruppe (300) geltenden Einkaufsregeln als mit der ersten Transaktions-ID verknüpfte Metadaten zur zentralen Datenbankanordnung (110), - Übertragen (730) von mit der ersten Transaktions-ID verknüpften Metadaten von der zentralen Datenbankanordnung (110) an ein bankspezifisches Datenbankmodul (130), - Empfangen (740) einer mit der ersten Transaktions-ID verknüpften ersten Transaktionsautorisierungsanfrage in einem in einer Bank (500) angeordneten Transaktionsautorisierungsmodul (520), wobei die erste Transaktionsautorisierungsanfrage Transaktionsautorisierungsinformationen umfasst, - Kommunizieren (750) einer Einkaufsgenehmigungsanfrage vom Transaktionsautorisierungsmodul (520) an das bankspezifische Datenbankmodul (130), wobei die Einkaufsgenehmigungsanfrage Transaktionsinformationen umfasst, die zumindest den Einkaufsbetrag enthalten, - Entscheiden (760) über die Einkaufsgenehmigungsanfrage durch Genehmigen oder Ablehnen derselben basierend darauf, ob der angefragte Einkauf die mit der ersten Transaktions-ID verknüpften Einkaufsregeln im bankspezifischen Datenbankmodul (130) erfüllt, - Antworten (765) an das Transaktionsautorisierungsmodul (520) mit der Genehmigung oder Ablehnung der Einkaufgenehmigungsanfrage, - Antworten (770) auf die mit der ersten Transaktions-ID verknüpfte erste Transaktionsautorisierungsanfrage durch das Transaktionsautorisierungsmodul (520), - Hinzufügen (780) der vom Transaktionsautorisierungsmodul (520) empfangenen Transaktionsinformationen als mit der ersten Transaktions-ID verknüpfte Metadaten zum bankspezifischen Datenbankmodul (130), - Übertragen (785) der mit der ersten Transaktions-ID verknüpften Transaktionsinformationen an die zentrale Datenbankanordnung (110) und - Übertragen (790) der mit der ersten Transaktions-ID verknüpften Transaktionsinformationen an das einkaufende Unternehmen (200), so dass die Informationen bezüglich des Einkaufs automatisch in wenigstens ein Verwaltungssystem des einkaufenden Unternehmens (200) eingegeben werden können.
  12. Verfahren (700) nach Anspruch 11, wobei das bankspezifische Datenbankmodul (130) in der Bank (500) angeordnet ist.
  13. Verfahren (700) nach Anspruch 11 oder 12, wobei die Einkaufsgruppe (300) wenigstens eine einkaufende Person umfasst.
  14. Verfahren (700) nach einem der Ansprüche 11 bis 13, wobei die Einkaufsgruppe (300) das gesamte einkaufende Unternehmen (200) umfasst.
  15. Verfahren (700) nach einem der Ansprüche 11 bis 14, wobei die Einkaufsregeln allgemeine Einkaufsregeln für eine Unterabteilung des einkaufenden Unternehmens (200) sind, und das Hinzufügen (725) der für die Einkaufsgruppe (300) geltenden Einkaufsregeln als mit der ersten Transaktions-ID verknüpfte Metadaten zur zentralen Datenbankanordnung (110) eine Bestimmung umfasst, zu welcher Unterabteilung die Einkaufsgruppe (300) gehört.
  16. Verfahren (700) nach einem der Ansprüche 11 bis 15, wobei die Transaktionsinformationen Händlerinformationen umfassen, und wobei das Entscheiden (760) über die Einkaufsgenehmigungsanfrage durch Genehmigen oder Ablehnen derselben ferner auf den Händlerinformationen basiert.
  17. Verfahren (700) nach einem der Ansprüche 11 bis 16, wobei die Einkaufsregeln vorgeben, dass bestimmte Metadaten verknüpft mit der Transaktions-ID der zentralen Datenbankanordnung (110) hinzugefügt werden müssen, bevor ein Einkauf getätigt wird, und wobei das Entscheiden (760) über die Einkaufsgenehmigungsanfrage das Ablehnen der Einkaufgenehmigungsanfrage umfasst, wenn diese Metadaten nicht verknüpft mit der Transaktions-ID im bankspezifischen Datenbankmodul (130) vorhanden sind.
  18. Verfahren (700) nach einem der Ansprüche 11 bis 17, das ferner das Übertragen (705) von Informationen von der zentralen Datenbankanordnung (110) entweder direkt oder über ein Zahlungskartenverwaltungsmodul (510) in der Bank (500) an ein Zahlungskarten ausgebendes Unternehmen (600) umfasst, so dass das Zahlungskarten ausgebende Unternehmen (600) Zahlungskarten an das einkaufende Unternehmen (200) ausgeben kann.
  19. Verfahren (700) nach einem der Ansprüche 11 bis 18, wobei das Übertragen (730) von mit der ersten Transaktions-ID verknüpften Metadaten von der zentralen Datenbankanordnung (110) an das bankspezifische Datenbankmodul (130) und das Übertragen (785) der mit der ersten Transaktions-ID verknüpften Transaktionsinformationen an die zentrale Datenbankanordnung (110) das Synchronisieren der zentralen Datenbankanordnung (110) und des bankspezifischen Datenbankmoduls (130) umfasst, so dass sie gespiegelte Versionen voneinander darstellen.
  20. Verfahren (700) nach einem der Ansprüche 11 bis 19, wobei die zentrale Datenbankanordnung (110) dazu eingerichtet ist, mit mehreren verschiedenen Parteien (200, 300, 400, 500, 600, 150) zu kommunizieren, und Adapter (205, 305, 405, 505, 605, 155) umfasst, die das durch jede dieser verschiedenen Parteien verwendete Datenformat in ein einzelnes Datenformat, bevorzugt ein durch das einkaufende Unternehmen (200) definiertes Datenformat, umsetzen.
DE112019006109.7T 2018-12-07 2019-12-06 Einkaufsmanagementsystem und -verfahren Pending DE112019006109T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
SE1830356A SE1830356A1 (en) 2018-12-07 2018-12-07 Purchase Management System And Method
SE1830356-0 2018-12-07
PCT/SE2019/051246 WO2020117126A1 (en) 2018-12-07 2019-12-06 Purchase management system and method

Publications (1)

Publication Number Publication Date
DE112019006109T5 true DE112019006109T5 (de) 2021-09-16

Family

ID=70974988

Family Applications (2)

Application Number Title Priority Date Filing Date
DE212019000441.5U Active DE212019000441U1 (de) 2018-12-07 2019-12-06 Einkaufsmanagementsystem
DE112019006109.7T Pending DE112019006109T5 (de) 2018-12-07 2019-12-06 Einkaufsmanagementsystem und -verfahren

Family Applications Before (1)

Application Number Title Priority Date Filing Date
DE212019000441.5U Active DE212019000441U1 (de) 2018-12-07 2019-12-06 Einkaufsmanagementsystem

Country Status (11)

Country Link
US (2) US11216864B2 (de)
JP (1) JP7472125B2 (de)
KR (1) KR20210099098A (de)
CN (1) CN112997208B (de)
AU (1) AU2019393678A1 (de)
CA (1) CA3119983A1 (de)
DE (2) DE212019000441U1 (de)
GB (1) GB2593991A (de)
NO (1) NO20210856A1 (de)
SE (1) SE1830356A1 (de)
WO (1) WO2020117126A1 (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SE1830356A1 (en) * 2018-12-07 2020-06-08 Omnicorn Ab Purchase Management System And Method
GB2606987A (en) * 2021-03-16 2022-11-30 Mastercard International Inc A selective transaction authorisation method and system

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7319986B2 (en) 1999-09-28 2008-01-15 Bank Of America Corporation Dynamic payment cards and related management systems and associated methods

Family Cites Families (49)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7653597B1 (en) * 1999-07-12 2010-01-26 David Stevanovski Payment administration system
GB2352861A (en) * 1999-08-04 2001-02-07 Int Computers Ltd Payment transaction system
US7249093B1 (en) * 1999-09-07 2007-07-24 Rysix Holdings, Llc Method of and system for making purchases over a computer network
KR100373507B1 (ko) * 1999-10-04 2003-02-25 이동산 전자 상거래 시스템 및 전자 상거래 방법
CN1203437C (zh) * 2000-07-17 2005-05-25 戴维·N·哈里斯 商务交易的确认系统和方法
US20020099648A1 (en) * 2000-09-19 2002-07-25 Devoe Dana L. Method of reducing fraud in credit card and other E-business
WO2002069290A2 (en) * 2000-10-23 2002-09-06 Works Operating Company Dynamic payment cards and related management systems and associated methods
CN1290892A (zh) * 2000-11-23 2001-04-11 徐玉麟 电子商务系统
WO2002054361A1 (en) * 2000-12-28 2002-07-11 Inishbeg Investments Limited A payment system
US7389275B2 (en) * 2002-03-05 2008-06-17 Visa U.S.A. Inc. System for personal authorization control for card transactions
US20030212595A1 (en) * 2002-05-10 2003-11-13 American Express Travel Related Services Company, Inc. Real-time promotion engine system and method
JP2007503046A (ja) * 2003-08-18 2007-02-15 ユー−マーケティング インテレクチュアル プロパティーズ プライベート リミテッド 支払処理システムと方法
JP4133721B2 (ja) 2003-10-07 2008-08-13 株式会社日立製作所 電子乗車券チケッティング方法およびシステム
CA2576162A1 (en) * 2004-08-04 2006-02-16 Mastercard International Incorporated Method and system for purchase card utilization and data reconciliation with enterprise resource planning/financial sofware
JP2006059272A (ja) 2004-08-23 2006-03-02 Bank Of Tokyo-Mitsubishi Ltd 利用認証装置、信用照会端末、利用認証システム、及び利用認証方法
US20060106700A1 (en) * 2004-11-12 2006-05-18 Boren Michael K Investment analysis and reporting system and method
AU2012202358A1 (en) * 2005-01-26 2012-05-10 Heng Kah Choy Fraud-free payment for internet purchases
GB0514602D0 (en) * 2005-07-15 2005-08-24 Taylor Robert J R A method of enabling a user to purchase a utility and a system therefor
CN101523428A (zh) * 2006-08-01 2009-09-02 Q佩控股有限公司 交易授权系统和方法
US10395264B2 (en) * 2007-04-30 2019-08-27 Visa U.S.A. Inc. Payment account processing which conveys financial transaction data and non financial transaction data
US20080283594A1 (en) * 2007-05-14 2008-11-20 John Baron Unbehagen Systems and methods for implementing debit card account restrictions
US8405944B2 (en) * 2007-10-09 2013-03-26 Schweitzer Engineering Laboratories Inc Distributed bus differential protection using time-stamped data
US20090228368A1 (en) * 2008-03-04 2009-09-10 Partnet, Inc. Systems and methods for enterprise purchasing and payment
US8788945B1 (en) * 2008-06-30 2014-07-22 Amazon Technologies, Inc. Automatic approval
US9449319B1 (en) * 2008-06-30 2016-09-20 Amazon Technologies, Inc. Conducting transactions with dynamic passwords
US8301502B2 (en) * 2008-12-17 2012-10-30 Noam Livnat Methods and systems for account management of group accounts
GB2466676A (en) * 2009-01-06 2010-07-07 Visa Europe Ltd A method of processing payment authorisation requests
GB2466810A (en) * 2009-01-08 2010-07-14 Visa Europe Ltd Processing payment authorisation requests
US8732082B2 (en) 2009-03-03 2014-05-20 Quercus (BVI) Limited System and method for executing an electronic payment
US20110016052A1 (en) * 2009-07-16 2011-01-20 Scragg Ernest M Event Tracking and Velocity Fraud Rules for Financial Transactions
GB2491076A (en) * 2010-03-11 2012-11-21 Walmart Stores Inc System and method for transaction payments using a mobile device
US8509982B2 (en) 2010-10-05 2013-08-13 Google Inc. Zone driving
US8401904B1 (en) * 2011-11-13 2013-03-19 Google Inc. Real-time payment authorization
AP2014008170A0 (en) * 2012-06-28 2014-12-31 Contour Technology Pty Ltd Automated transaction system
US20140279474A1 (en) * 2013-03-12 2014-09-18 Visa International Service Association Multi-purse one card transaction apparatuses, methods and systems
EP3017413A4 (de) * 2013-07-04 2016-07-13 Visa Int Service Ass Autorisierung von transaktionen mittels regeln auf basis mobiler vorrichtungen
US10002348B1 (en) * 2013-07-24 2018-06-19 Amazon Technologies, Inc. Routing and processing of payment transactions
US9613358B1 (en) * 2013-08-19 2017-04-04 Marqeta, Inc. System, method, and computer program for capturing a unique identifier for a merchant used in purchase transaction approval requests
US20160203483A1 (en) * 2013-08-26 2016-07-14 Total System Services, Inc. Personal Account Authorization Controls
US20150178725A1 (en) * 2013-12-23 2015-06-25 Nicholas Poetsch Transaction authorization control and account linking involving multiple and singular accounts or users
CN104951446A (zh) * 2014-03-25 2015-09-30 阿里巴巴集团控股有限公司 大数据处理方法及平台
CN104036355A (zh) * 2014-06-04 2014-09-10 深圳市一棵米电子商务有限公司 交易信息管理系统及其方法
US10108950B2 (en) * 2014-08-12 2018-10-23 Capital One Services, Llc System and method for providing a group account
US11151634B2 (en) 2014-09-30 2021-10-19 Square, Inc. Persistent virtual shopping cart
US20160300418A1 (en) 2015-04-10 2016-10-13 International Business Machines Corporation Monitoring actions to conduct an activity between multiple participants
EP3147853A1 (de) * 2015-09-23 2017-03-29 Mastercard International Incorporated Transaktionskontrolle
CN111316310B (zh) * 2017-09-12 2024-02-09 大卫.施尼特 统一电子交易管理系统
SE1830356A1 (en) * 2018-12-07 2020-06-08 Omnicorn Ab Purchase Management System And Method
US10757462B2 (en) 2018-12-20 2020-08-25 Viamedia, Inc. Integrating digital advertising ecosystems into linear TV

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7319986B2 (en) 1999-09-28 2008-01-15 Bank Of America Corporation Dynamic payment cards and related management systems and associated methods

Also Published As

Publication number Publication date
US20210233156A1 (en) 2021-07-29
JP7472125B2 (ja) 2024-04-22
GB202107300D0 (en) 2021-07-07
DE212019000441U1 (de) 2021-07-12
CA3119983A1 (en) 2020-06-11
US11922488B2 (en) 2024-03-05
US11216864B2 (en) 2022-01-04
KR20210099098A (ko) 2021-08-11
CN112997208B (zh) 2024-05-31
AU2019393678A1 (en) 2021-07-15
NO20210856A1 (en) 2021-07-01
SE1830356A1 (en) 2020-06-08
GB2593991A (en) 2021-10-13
JP2022512074A (ja) 2022-02-02
WO2020117126A1 (en) 2020-06-11
CN112997208A (zh) 2021-06-18
US20220084106A1 (en) 2022-03-17

Similar Documents

Publication Publication Date Title
DE60015587T2 (de) Effizientes und sicheres zahlungsverarbeitungssystem
DE69900169T3 (de) Kreditkartensystem und verfahren
DE102012112967B4 (de) online Transaktionssystem
WO2003042938A2 (de) Bezahlungsprotokoll sowie datenübertragungsverfahren und -anordnung für bezahlvorgänge
DE202012100172U1 (de) Elektronisches Gutscheinsystem
DE10296919T5 (de) System und Verfahren zur sicheren Rückzahlung
DE212010000059U1 (de) Veränderbarer Sicherheitswert
DE20220745U1 (de) Sicheres Online-Zahlungssystem
DE112019006109T5 (de) Einkaufsmanagementsystem und -verfahren
DE112013004894T5 (de) Verfahren, System und zugehöriger ausführbarer Computercode zur Vermittlung von Kredittransaktionen
DE102007005427A1 (de) Verfahren und Vorrichtung zur elektronischen Zahlung
DE112018005524T5 (de) Zahlungsterminalvorrichtung und -verfahren
DE202013102588U1 (de) Online-Einkaufssystem
DE60115082T2 (de) Dynamische zahlungskarten und entsprechende verwaltungssysteme und zugehörige verfahren
DE19938695A1 (de) Verfahren und Vorrichtung zur elektronischen Abwicklung von bargeldlosen Zahlungen mittels Sicherheitsmodulen
DE202019106383U1 (de) Elektronische Zahlungsvorrichtung
WO2020037344A1 (de) System zum verarbeiten von anfragen mobiler geräte
EP1128340A1 (de) Verfahren zum Aufladen eines Kundenkontos für Telekommunikationsdienste und entsprechendes Aufladesystem
DE10234127A1 (de) Produktgerichtetes, elektronisches Handelssystem
EP2345986A1 (de) Verfahren zur Erfassung von Finanztransaktionen
DE102018112795A1 (de) Verfahren zur Erzeugung eines Finanzierungsangebots
EP2523155B1 (de) Verfahren zum datentechnischen Zuordnen eines NFC-fähigen Endgerätes, einer NFC-Chipkarte und einer Transaktion
DE60209501T2 (de) Bezahlvorrichtung
DE10151200A1 (de) System, Verfahren und Computerprogramm-Produkt zur Erzeugung und/oder Verwendung einer mobilen Digitalkarte
DE102021003724A1 (de) Verfahren zur ldentifikation einer Person durch eine Kreditkartennummer und ldentifikationssystem