WO2003012716A1 - Merchant activity and reconciliation program - Google Patents

Merchant activity and reconciliation program Download PDF

Info

Publication number
WO2003012716A1
WO2003012716A1 PCT/US2001/023753 US0123753W WO03012716A1 WO 2003012716 A1 WO2003012716 A1 WO 2003012716A1 US 0123753 W US0123753 W US 0123753W WO 03012716 A1 WO03012716 A1 WO 03012716A1
Authority
WO
WIPO (PCT)
Prior art keywords
software object
data
communication
software
merchant
Prior art date
Application number
PCT/US2001/023753
Other languages
French (fr)
Other versions
WO2003012716A8 (en
Inventor
Dee Anne Davison-Kellum
Charles R. Aschenbeck
Original Assignee
Davison Kellum Dee Anne
Aschenbeck Charles R
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 Davison Kellum Dee Anne, Aschenbeck Charles R filed Critical Davison Kellum Dee Anne
Priority to PCT/US2001/023753 priority Critical patent/WO2003012716A1/en
Priority to AU2001283019A priority patent/AU2001283019A1/en
Publication of WO2003012716A1 publication Critical patent/WO2003012716A1/en
Publication of WO2003012716A8 publication Critical patent/WO2003012716A8/en

Links

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
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance
    • 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
    • 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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • 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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G06Q20/023—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP] the neutral party being a clearing house
    • 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/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction

Definitions

  • the present invention is related generally to the field of software and computer systems that provide credit card sales accounting and reconciliation functions for a merchant.
  • the present invention is related more specifically to the field of software and computer systems utilized to reconcile individual credit card and electronic payment transactions to the credits and debits entered into a merchant's bank account by the credit card processor. Yet more specifically, the present invention is related to software and computer systems that reconcile individual credit card and electronic payment transactions to the credits, debits and adjustments entered into a merchant's bank account by the credit card processor and further reconcile such credits, debits, and adjustments from the merchant's bank account to the merchant's general ledger.
  • the paying entity Visa®, MasterCard®, American Express®, etc.
  • Background Art Accounting software that is capable of reconciling accounts is well known. Multiple applications of such existing software to the problems of a reconciliation of a plurality of accounts could be accomplished.
  • U.S. Patent No. 5,963,925 teaches an electronic statement presentation (ESP) system that replaces the preparation and mailing of paper statements and invoices from a biller with electronic delivery.
  • the ESP system provides software for auditing and reconciliation and balancing of accounts.
  • the ESP system provides for the forwarding of both consumer and merchant data through a central service bureau.
  • the ESP system is designed to be an electronic bill payment service and does not address many of the problems of an individual merchant trying to reconcile his credit and electronic payments sales with his merchant account credits, debits, and chargebacks, in light of his general ledger entries, particularly issues of net versus gross transaction payments and time delayed transfers which are commonly encountered by individual merchants.
  • U.S. Patent No. 6,026,379 teaches a method to securely transmit payment information from a customer to a merchant to a payment gateway and return a certificate, including a credit confidence factor to allow a merchant to determine whether to accept or reject payment information.
  • the method provides for online connection of the merchant to the customer to the payment gateway, which may encompass a credit card processing facility.
  • the detailed description of Object Oriented Programming provided on pages 7 though 11 is referred to and hereby adopted by reference.
  • the method provides for communication of (at page 97) a "LEGACY - Administrative Inquiry Record" which provides all of the information to a merchant necessary to accomplish a reconciliation.
  • the method of this invention does not, however, accomplish the reconciliation for the merchant.
  • U.S. Patent No. 5,608,874 teaches an automated data transfer method suitable for transferring accounting data to a central data storage that can provide a bureau service.
  • the bureau service may include provision of reconciliation services for an individual merchant.
  • the invention speaks to the method of data transfer and does not disclose the reconciliation method.
  • Patent 5,544,086 teaches a system for determining value in a stored value transaction system that has a plurality of value transferring devices including a local device, a collection device, a consolidation device and a settlement device.
  • the system is applicable to integrated circuit cards, as a value transferring device.
  • the integrated circuit card transfers value from an account, may be a bank account, at a point of sale to a collection device.
  • the integrated circuit necessarily maintains balance calculations.
  • the system provides for a network settlement device which performs overall settlement of the accounts of the transaction system.
  • the pattern of transfers following a credit card/electronic payment sale by a merchant is: the credit card is input to the point of sale machine (terminal) or "virtual" terminal, the terminal transmits the individual transaction information to the merchant's chosen credit card processor, the credit card processor transmits the individual transaction information (bundled into a bulk transfer) to a credit card clearing house, the clearing house transmits the individual transaction information to the respective credit card entities (MasterCard®, Visa®, etc.), each credit card entity transmits a bulk transaction payment (providing summary information only) to the merchant's chosen merchant bank, the merchant bank transmits the bulk transaction payment to the merchant account at the merchant's commercial bank, and then the commercial bank sends the merchant a bank statement.
  • the point of sale machine terminal
  • the terminal transmits the individual transaction information to the merchant's chosen credit card processor
  • the credit card processor transmits the individual transaction information (bundled into a bulk transfer) to a credit card clearing house
  • the clearing house transmits the individual transaction information to the respective credit card entities (MasterCard
  • the merchant's chosen processor receives individual transactions from a merchant's point of sale device or terminal and then transfers as a bulk transaction (summarizing all of the individual transactions) into the merchant account on a daily basis. Additionally, a merchant typically closes out (“batches”) each point of sale device or terminal on a daily basis and posts the close out information to his general ledger. Such closeout information may be in various formats, in bulk or summary, individual transactions, summarized by category of goods or services, summarized by sales person, etc.
  • Each credit and/or debit and/or value stored card issuer has an individual contract with the merchant wherein the merchant agrees to charges and fees in greater or lesser amounts on a per item, or per cash volume, or per time period basis. Or any combination of the foregoing.
  • the merchant's chosen processor and chosen merchant bank also have fees and charges which also may be calculated in any combination of the foregoing ways.
  • the charges and fees by all the participants in the merchant's credit sales transactions may be levied by subtraction from individual transactions, or debited from bulk transactions, or simply debited periodically.
  • the merchant account is subject to chargebacks, and related additional fees and charges, whenever a purchaser reverses a credit sale made by the merchant (subject to card holder terms, etc.).
  • the approval of any individual transaction by the credit card issuer/electronic payment source may be delayed for from one to three days. Therefore, the individual transaction may be included within a given bulk transaction from the merchant's chosen processor and thus to the merchant bank for a period of one to three days.
  • the merchant needs to reconcile the individual transaction information of the merchant's point of sale device or terminal to the bulk transaction data reflecting deposits into and chargebacks from the merchant account at the merchant's commercial bank, and reconcile the sales data in the merchant's general ledger (into which the merchant records individual transactions and/or batched transactions, dependent upon the merchant's custom) with the bank deposits and chargebacks data (which records bulk transactions).
  • a first problem occurs when the monthly charges for the merchant account and for the individual credit card issuers are debited from the commercial account. These debits may be stand alone items or may be included within a bulk transfer from the merchant account.
  • a third problem occurs when a particular credit card charge or electronic payment is reversed, whether for non-payment or otherwise.
  • the particular credit card charge or electronic payment is included within and will reduce a bulk transfer from the merchant account to the merchant's commercial bank account. Additionally, certain contracted charges will be incurred by the merchant to the merchant bank and to the particular credit card issuer making the payment reversal.
  • a yet further problem is that the merchant will encounter time delays of up to four days between the incident of sale and transfer to the processor of the individual transaction and the time that the individual transaction appears within a bulk transfer from the merchant account.
  • a yet further problem occurs when merchant attempts to reconcile his merchant account transfers to his general ledger entries which typically are made on a daily basis to accumulate and track sales.
  • a yet further and final problem occurs because the merchant's chosen credit card/electronic payment processor may deduct its charges from individual transactions or debit all transactions on a periodic basis, or both; and the merchant's selected merchant bank may deduct its charges from individual transactions or debit all transactions on a periodic basis, or both; and each credit card issuer may likewise deduct its charges or debit for same (pursuant to individual contract).
  • Each of the various billing entities by charging for services and deducting from credits or remitting on individual transactions in net or in gross impact the amount actually deposited into the merchant's commercial bank account.
  • Many merchants today use an "approximate reconciliation" whereby they take the deposit amounts transmitted to them from their merchant account and subtract those amounts from the recorded general ledger sales and "label" the difference credit card service expenses.
  • the instant invention is of a software program and system that reconciles a plurality of accounts, typically such a reconciliation is of a merchant's point of sale/electronic payment transactions to the merchant's bank account deposits and chargebacks, and then to the merchant's legacy general ledger system.
  • the system of the instant invention provides for a single software object running on a single computer, wherein the software object is in communication with a source of the point of sale/electronic payment transactions, a source of the merchant account deposit and charge back transactions, and the merchant's general ledger system.
  • the system of the instant invention further provides a database and communicates reconciled transactions to the merchant for entry in the merchant's legacy general ledger system.
  • the instant invention addresses all of the hereinabove identified problems encountered by a merchant when reconciling his credit card/electronic payment receipts to his merchant account statement and to his general ledger entries.
  • ActiveX object An object that is exposed to other applications or programming tools through Automation interfaces.
  • Authorization Code - Processor (processor network) authorizes transaction with approval code.
  • Automation object An object that is exposed to other applications or programming tools through Automation interfaces.
  • Bank - Depository facility for funds of electronic transactions for user or customer of this application.
  • Bank Account Specific account number for this user or customer; where funds are deposited electronically for transactions.
  • Boolean expression An expression that evaluates to either True or False.
  • bv an abbreviation used to indicate a view created from two or more tables; used as a suffix in a view name. See View.
  • Charge-back - Merchants may experience occasions when a customer refuses to pay for a transaction or may encounter other reasons for a transaction being "returned".
  • Client/server computing A system of computing in which two or more computers share processing across a network.
  • the server computer manages a shared resource, such as a database, and responds to requests from clients for use of this resource.
  • the client computer interacts with a user and makes requests for use of a shared resource.
  • Client/server computing separates the functions of an application into two parts: a front end component and a back end component.
  • the client presents and manipulates data on the workstation; the server stores, retrieves, and protects data.
  • Cursor closes a cursor and de-allocates the memory used by the cursor.
  • Cursor. Closing Date Designated time period for a specific item.
  • Merchants' banking period may have a closing date at the end of the month or any time during the month, depending on the designated cut-off date of reporting.
  • Data Collection A group of related objects. See object. Column - In an SQL database table, the area, sometimes called a field, in each row that stores the data about an attribute of the object modeled by the table. Individual columns are characterized by their maximum length and the type of data that can be placed in them. A column contains an individual data item within a row.
  • COM See component object model.
  • Component Object Model (COM) - The programming model upon which several SQL Server and database application programming interfaces (APIs) such as SQL-DMO, OLE DB, and ADO are based.
  • APIs application programming interfaces
  • a programming structure that includes both data and functionality.
  • a COM object is defined and allocated as a single unit.
  • Cursor A database object used by applications to manipulate data by rows instead of by sets. Using cursors, multiple operations can be performed row by row against a result set with or without returning to the original table. In other words, cursors conceptually return a result set based on tables within the database(s). For example, a cursor can be generated to include a list of all user-defined table names within a database. After the cursor has been opened, movement (fetching) through the result set can include multiple operations against each table by passing each table name as a variable. Cursors are powerful when combined with stored procedures and the EXECUTE statement (to build strings dynamically).
  • Data The coded representation of information for use in a computer. Data has attributes, such as type and length.
  • Database A collection of information, tables, and other objects organized and presented to serve a specific purpose, such as facilitate searching, sorting, and recombining data.
  • Databases are stored in files.
  • DLL Dynamic Link Library
  • Electronic Payment Transaction The term includes all forms of electronic payments
  • EOF or End Of File - a Boolean variable that indicates the end of file. Indicates that the current record position is after the last record in a Recordset or cursor.
  • Fee - A charge of any kind associated with an electronic payment or a fee charged by the processor or bank.
  • Field - A single item of information contained within a row. A field is more commonly called a column in an SQL database.
  • Flag - a Boolean field that usually indicates True or False, Yes or No, On or Off
  • Hierarchy An arrangement of members of a dimension into levels based on parent-child relationships, such as Year, Quarter, Month, Day or Country, Region, State or province, City.
  • H> - Usually indicates the database field is an Identity Column.
  • Identity Column - A column in a table that uses the identity property for a system-generated, monotonically increasing number.
  • Insert the Identity field is automatically assigned the next whole number in the sequence.
  • Inner Join A join in which records from two tables are combined and added to a query's results only if the values of the joined fields meet certain specified criteria.
  • Join As a verb, to combine the contents of two or more tables and produce a result set that incorporates rows and columns from each table. Tables are typically joined using data that they have in common. As a noun, the process or result of joining tables, as in the term "inner join” to indicate a particular method of joining tables. See Inner Join.
  • Keyed A transaction that has been processed at the point of sale by any manual method. Example: If the terminal were down and the merchant were to "key" in the customer's credit card numbers manually. This could also apply to merchants that process electronic transactions over the internet or telephone. These type of transactions usually experience a higher fee or rate.
  • Ledger The accounting system used by the merchant. Ledger is the term used for the software or system used for warehousing the accounting or financial entries.
  • Left Outer Join or Left Join A type of outer join in which all rows from the first-named table (the left table, which appears leftmost in the JOIN clause) are included. Unmatched rows in the right table do not appear.
  • NULL An entry that has no explicitly assigned value. NULL is not equivalent to zero or blank. A value of NULL is not considered to be greater than, less than, or equivalent to any other value, including another value of NULL.
  • One of the components of a database a table, index, trigger, view, key, constraint, default, rule, user-defined data type, or stored procedure. Also called a database object.
  • (3) A file, directory, database, or database record Other - This software invention has been designed to accommodate any number more than two (unlimited number) of data inputs for reconciliation.
  • the merchant may have more than the Bank, Ledger and POS inputs. Some merchants may add an additional source of data in the future in order to perform additional reconciliations.
  • the POS in this example would be the terminal software that may transmit data into a PC or LAN before transmitting the data to the Processor.
  • the processor would then transmit the data back to our software.
  • a additional comparison could be made between the POS and the processor file at that point; adding another layer of internal control and reconciliation to ensure data is not being dropped between the POS and the processor transmission.
  • PK Primary Key
  • a primary key (PK) must be nonnull and must have a unique index.
  • a primary key is commonly used for joins with foreign keys (matching non-primary keys) in other tables.
  • Processor All merchants that process electronic payments have a processor. The transactions are processed through this vendor. A merchant may have many processors. Each electronic payment method could be processed by a different vendor; depending on the merchant's organization. The processor is the party that presents the electronic payments to the banks/networks for payment. Most processors are associated with a bank.
  • Protocol A set of rules or standards designed to enable computers to connect with one another and exchange information.
  • Query - A specific request for data retrieval, modification, or deletion.
  • Rate - A merchant signs an agreement with a processor or electronic payment vendor to pay an agreed upon amount for the ability to process electronic payments with that processor or vendor. It can be a flat rate, a percentage, applied per transaction or any combination of these scenarios.
  • Reconciliation the making of two or more apparently conflicting things consistent or compatible; the bookkeeping term used for comparing the bank statement to the balance sheet or financial system known as the ledger.
  • a bank reconciliation accounts for the differences between the statement and the ledger system balance. Usually the differences entail any items that are in transit or have never cleared the bank account. The fees or discount rates that have been applied could be another factor, as well as any charge-backs that have occurred that have been unaccounted for. Additional reconciliations may include other factors or transaction groups.
  • ADO object used to contain a result set. It also exhibits cursor behavior depending on the recordset properties set by an apphcation. ADO recordsets are mapped to
  • Resultset The set of rows returned from a SELECT statement.
  • the format of the rows in the result set is defined by the column-list of the SELECT statement.
  • Relationship - A link between tables that references the primary key in one table to a foreign key in another table.
  • the relationship line is represented in a database diagram by a solid line if referential integrity between the tables is enforced, or a dashed line if referential integrity is not enforced for INSERT and UPDATE transactions.
  • the endpoints of a relationship line show a primary key symbol to denote a primary key to foreign key relationship or an infinity symbol to denote the foreign key side of a one-to-many relationship.
  • Retrieve SQL Return Code - indicates the status of a result set or query
  • Right Outer Join or Right Join - A type of outer join in which all rows in the second-named table (the right table, the one that appears rightmost in the JOIN clause) are included.
  • Row - A data structure that is a collection of elements (columns), each with its own name and type. A row can be accessed as a collective unit of elements, or the elements can be accessed individually. A row is equivalent to a record. See also column.
  • Server - A software object mnning on a computer connected to a local area network (LAN) that controls access to resources, such as files, printers, and communication devices.
  • Scheduled Task an automated job that is scheduled to run at predefine times without any intervention
  • Self-join - A join that compares rows within the same table.
  • a self-join is called a reflexive relationship.
  • SQL Insert or Insert query - A query that copies specific columns and rows from one table to another or to the same table.
  • SQL Select or Select query A query that returns rows into a result set from one or more tables.
  • a Select query can contain specifications for those columns to return, the rows to select, the order to put the rows in, and how to group (summarize) information.
  • SQL Statement An SQL or Transact-SQL statement, such as SELECT or DELETE, that performs some action on data.
  • SQL Update or Update query - A query that changes the values in columns of one or more rows in a table.
  • Table - An object in a database that stores data as a collection of rows and columns.
  • Tb - an abbreviation for table; used as a suffix in table names Terminal - Term referring to the machine or method for collecting transactions at the point of sale.
  • this term referred to the actual machine used by merchants for reading or swiping cards.
  • current technology includes the PC and software objects that are virtual 'terminals" with a card reader attached to a keyboard or some merchants even have
  • Terminal accessed via a website or server.
  • Transaction A group of database operations combined into a logical unit of work that is either wholly committed or rolled back.
  • a transaction is atomic, consistent, isolated, and durable.
  • Transaction rollback Rollback of a user-specified transaction to the last save point inside a transaction or to the beginning of a transaction.
  • tv an abbreviation for a SQL table view when the view is created from a single table; used as a suffix in table views.
  • User a person that has been setup and assigned a User ID and password to access the apphcation
  • View an alternate way of looking at data from one or more tables in a database.
  • a View is a virtual table, usually created as a subset of columns from one or more tables.
  • Web Server - A software object nning on a computer that provides Web services and pages to intranet and Internet users.
  • Agreement_Rates_Tb the rates setup in an Agreement or Contract. Indicates the discount rate(s) for each Payment Type.
  • Bank_Tb - table used to store data provided by the Bank, data is stored at the Master Partner level.
  • Ledger Tb - table used to store data provided by the customer ledger system data is stored at the Master Partner level.
  • Ledger_Accounts_Tb - Ledger Accounts are setup at the Master Partner level.
  • Ledger Accounts are setup by the User and are assigned to a Master Partner record in the Partners_Tb. 7. Merchants_Tb - table used to associate Agreements/Contracts with a Merchant
  • Partners Tb - used to store Partner records.
  • a Partner could be a Bank, Merchant Location or a Processor. All Partner records that are not Master Partners reference a
  • Master Partner record A single Master Partner record is setup for each copy of the software that is sold.
  • Partner_Hierarchy_Tb used to create Parent/Child relationship on the Partner Tb. This associates Bank, Merchant Location and Processor records to Master Partner records.
  • Processor_Tb - table used to store data provided by the Processor, data is stored at the Master Partner level.
  • Reconciliation_Tb table used to store data about a reconciliation that is current or complete.
  • Reconciliation_Associations_Tb table used to associate data tables defined in Reconciliation Data Tables Tb to different reconciliations defined in Reconcihation_Decode_Tb. - There is a one-to-many relationship between Reconciliation Code and Table_Code.
  • Reconciliation_Cleared_Data_Tb Once a reconcihation is complete the original data rows used in the reconciliation must be marked so we don't include them in future reconcihation of the same type.
  • Record_ID from the original data table are stored here permanently. The same data can be pulled into another reconciliation as long as it is a different reconciliation being performed.
  • Reconciliation_Data_Tb - table used to temporarily store summarized table data while a reconcihation is being executed. Data from the Bank Tb, Ledger_Tb and
  • Processor Tb is summarized and inserted into this table when a reconcihation is first started.
  • ReconciIiation_Data_Matches_Tb - table used to reconcile the data. When a match is found between two different data sets in the Reconcihation_Data_Tb the Data_IDs are stored in this table to show the match. Once all tables and rows have been matched there will be a circular reference made in this table.
  • Reconciliation_Data_Tables_Tb - table used to store the tables that are available to the reconciliations defined in Reconciliation_Decode_Tb. Only one entry per data table exists in this table. 19.
  • Reconciliation_Decode_Tb - table used to store the different reconciliations that can be performed; i.e. Bank to Ledger, POS to Ledger, Bank to POS, 3-way, 4-way, multi-acct, etc.
  • Reconciliation_Locations_Tb - contains all Merchant Locations that are included in the reconcihation identified by the Batch SSumber.
  • ReconciIiation_Matching_Tb - table is used to identify the tables that will be matched within a reconciliation and provides the procedure to perform the match.
  • Reconciliation_Report_Data_Tb table used to store data for historical reporting. Once a reconcihation is complete the data is inserted here and then deleted from Reconciliation_Data_Tb.
  • Reconciliation_Report_Matches_Tb table used to store data for historical reporting. Once a reconciliation is complete the data is inserted here and then deleted from Reconciliation_Data_Matches_Tb .
  • Terminals_Tb - table used to setup terminals and associates the Terminal with a Merchant Location.
  • Terminal_Merchant_Numbers_Tb used to associate MerchantJSlumbers to a Terminal.
  • User_Tb used to store User records. Each User record is assigned to a Master Partner ld.
  • the User_JJD "SYSTEM' is a reserved User_JJD and can not be assigned to any user.
  • a Merchant Location is defined in the Partners Tb.
  • Agreement_JJD Uniquely identifies the agreement
  • Agreement Rate lD Uniquely identifies the rate for an agreement
  • Payment Type Code Type of rate setup ie. Visa ® , Mastercard ® , etc.
  • Bank Account ID Uniquely identifies the Bank Account Bank Partner lD Partner_ID in Partner Tb which identifies a Master Partner Bank_Account_Number
  • the Bank Account Number Inbound_Routing_Number Unique numeric designation for a bank's location Description Brief description of the bank account Monthly_Fee_Amt Optional Monthly Fees Start_Date Effective Start Date for the Bank Account End Date Effective End Date for the Bank Account Date Added Date the row was added to the table DateJVIodified Date the row was last modified Bank_Tb
  • Bank ID Uniquely identifies a Bank record PartnerJ-D Partner ID in Partners Tb which identifies a Master Partner Merchant_Number Merchant Number used for the transaction. Identifies Visa ® ,
  • Bank AccountJSfumber The Bank Account Number in which the transaction acted upon
  • Ledger AccountJDD Uniquely identifies a Ledger record
  • PartnerJ-D PartnerJ-D in Partners Tb which identifies a Master Partner Ledger Account Number The Ledger account number the transaction acted upon
  • Ledger_AccountJSfumber Used to uniquely identify accounts within the Ledger
  • Ledger Account ID Ledger Account ID from Ledger_Accounts_Tb which uniquely identifies a Ledger Account OverridingJSfet_Gross_Flag Overriding flag indicates if the transaction on the Ledger Account is at Net or at Gross - overrides the Default JS[et_Gross_Flag in the Ledger_Accounts_Tb table
  • Payment Type Code Identifies the type: ie. Visa ® , Mastercard , Discover ® , etc.
  • Bank Account ID Bank_AccountJD from Bank_Accounts_Tb which uniquely identifies a Bank Account OverridingJSfet_Gross_Flag Overriding flag indicates whether the transaction on the Bank
  • Partner Type Code Defines the type of partner record (Master, Bank, Processor,
  • Child Partner ID Partner ID in Partners Tb which identifies the Child Record Processor Tb
  • Processor JDD Uniquely identifies the Processor record PartnerJ-D Partner JDD in Partners_Tb which identifies a Master Partner MerchantJMumber The Merchant Number used for the transaction Transaction Date Date the transaction was made Payment Type Code Visa ® , MasterCard ® , Discover ® , etc. Expiration Date Expiration date on the credit card Card Number Credit Card Number Card _ Holders _ Name Name on the credit card Customer RoutingJSTumber Customer's Bank Routing Number; Electronic
  • Reconciliation Code Unique Code from Reconcihation Decode Tb used to identify the type of reconcihation being performed
  • Reconcihation Code Unique code from Reconcihation DecodeJLb used to identify the type of reconciliation being performed
  • Source Table Code l Unique Code from Reconciliation Data Tables Tb used to identify tables used in the reconcihation
  • Source_Table_Code_2 Unique Code from Reconcihation JDataJTablesJTb used to identify tables used in the reconciliation Matching Procedure Procedure used to match data equal to Source_Table_Code_l and Source_Table_Code_2
  • Table_Code Table Code from Reconcihation Data Table Tb used to identify where the data row came from Merchant JSfumber Merchant Number used in the transaction Transaction Date Date the transaction took place Transaction_Type_Code Visa ® , MasterCard ® , Discover ® , etc.
  • Terminal_ID Uniquely identifies a credit card terminal TerminalJSTame Description of the terminal Merchant PartnerJ-D Partner JD in Partners fb which identifies a Merchant
  • Terminal_Type The type of terminal in use PrinterJType The type of printer the terminal is using, if any Purchased Leased Flag Indicates if the terminal is purchased or leased Monthly JFee_Amt Optional monthly fee associated with this terminal Date Added Date the row was added to the table Date Modified Date the row was last modified
  • Keyword Keyword parameter (like a windows .ini file) Value The value of the user preference
  • Software Object 1 a client software which may be a browser 3. Communication between Software Object 1 and Object 5 5. Object 5, an optional internet to intranet transition 7. Communication between Object 5 and Object 9 9. Object 9, an optional firewall which may be either hardware or software
  • Software Object 14 the parent software object for software objects 16, 40, 20, 22, and 24
  • Data Object 16 is the database of the instant invention
  • Software Object 20 is the web server
  • Software Object 22 is the parent object for ah of the Web based Languages, Active server pages, Java, Active X controls, etc. 24.
  • Software Object 24 is the parent software object for the software program of the instant invention
  • Software Object 30 is the parent software object for software objects 20, 22, and 24
  • Data Object 32 data from either POS software or from processor
  • Data Object 42 Data Object 42, general ledger transactions from user's general ledger/legacy system 44. Communication between Data Object 42 and Software Object 30
  • This is a generic data object that can be added to the instant invention for configuration and reconcihation. For example; it may be necessary for a user to have both POS and processor files, therefore one of those two files would be placed in Data Object 45.
  • the instant invention has been designed to provide reconcihation between any two or more set of data. The instant invention permits any number of data sets to be added to the reconcihation by the user 46. Communication from the merchant to Communication Object 50
  • Communication Object 50 communicates the POS/Processor data, Bank data or
  • Data Object 52 an intermediate data file which is hereinafter referred to as data file
  • Communication Object 54 may be scheduled task or human intervention that starts
  • Data Object 58 intermediate storage of data file "3 A" onto local LAN.
  • Communication Object 60 may be scheduled task or human intervention that starts
  • Software Object 80 executes an SQL Insert of Bank Adjustments into BankJTb 82.
  • Software Object 82 execute an SQL Insert of POS data into ProcessorJTb 84.
  • Software Object 84 execute an SQL Insert of Ledger Adjustment into LedgerJTb 85.
  • Software Object 86 closes file "3A"
  • Reconciliation Code to Software Object 97 97 initiates reconcihation upon User selection and input of choices for the type of reconcihation to perform (Reconcihation_Code set), the bank account and the ClosingJDate
  • Software Object 310 initializes an SQL insert into the Reconcihation Tb table.
  • Software Object 320 inserts the input parameters into the Reconcihation Tb and assigns a BatchJSTumber through an SQL Identity field 330.
  • Software Object 330 retrieves the BatchJSTumber identity field from Reconcihation Tb
  • Software Object 335 retrieves the SQL Return Code making sure the insert of the input parameters into Reconcihation_Tb was successful 340.
  • Software Object 340 a Child of Software Object 105, commits transaction 350.
  • Software Object 350 a Child of Software Object 115, performs an SQL select from the UserJVIerchants Tb, selecting the merchants that are assigned to the bank account selected in Software Object 97 360.
  • Software Object 360 generates a User screen to select locations 370. Communication from User to Software Object 380 of selections 380.
  • Software Object 380 accepts User selections of location(s) or merchant partners (a Merchant Partner is a location)
  • Software Object 390 begins the transaction 400.
  • Software Object 400 inserts User selected locations or merchant partners into the transaction 400.
  • Software Object 415 a Child of Software Object 130, performs an SQL select using
  • BatchJSTumber to query the ReconciliationJTb to retrieve the User J-d, bank account number, Reconciliation Code and ClosingJDate, and saves the retrieved data in local variables 420.
  • Software Object 420 performs an SQL select using the Reconcihation_Code and creates a cursor selecting all the selected tables used in this reconciliation from the
  • Software Object 470 performs SQL select on the Reconcihation Data Tables Tb and retrieves the Starting Procedure for the current Table_Code retrieved from the cursor by Software Object 460 475. Communication from Software Object 470 to Software Object 480 480. Software Object 480, executes the StartingJProcedure with data retrieved by Software
  • Software Object 490 a Child of Software Object 130, closes cursor 500.
  • Software Object 500 performs a selection case on input parameter 1 (which equals the Table_Code) 505. Communication from Software Object 500 to Software Object 515 on the case that
  • Bank Table_Code is the input parameter 515.
  • Software Object 515 present if Other data types are selected to be reconciled
  • POS Table_Code is the input parameter 530. Communication from Software Object 500 to Software Object 650 on the case that
  • Ledger Table Code is the input parameter 535.
  • Software Object 535 queries the database for User_Id, Partner Id,
  • Reconcihation Tb table 540 Software Object 540, initializes transaction 545. Communication from Software Object 540 to Software Object 550 550. Software Object 550, resets working tables for reconciliation, passing the Table_Code and BatchJSTumber to Software Object 560 OR Software Object 620 OR Software
  • Software Object 570 retrieves SQL return code and checks status 580.
  • Software Object 580 Commits transaction 590.
  • Software Object 590 queries the database for User ld, Partner ld, the
  • Software Object 630 retrieves the SQL return code and checks status.
  • Software Object 640 commits transaction 650.
  • Software Object 650 queries the database for UserJ-d, PartnerJ-d, the
  • Software Object 660 initializes transaction 665. Communication from Software Object 660 to Software Object 550 675. Communication from Software Object 550 to Software Object 680 680. Software Object 680, executes SQL insert of Ledger data into the
  • Reconcihcation Data _Tb joining on the following tables: Reconcihation Cleared Data Tb, MerchantJSTumbersJTb, Reconcihation Locations Tb,
  • Software Object 690 retrieves the SQL return code and checks status. 700. Software Object 700, commits transaction 800. Software Object 800, queries the database for UserJ-d, Partner ld, the
  • Software Object 850 executes "simple match" on the dynamic stream of data that is built out of Software Object 840 data 855. Communication from Software Object 850 to Software Object 810 860. Software Object 860, a Child of Software Object 140, closes cursor 870. Software Object 870, initializes transaction 875. Software Object 875, executes an SQL insert of matching data rows into
  • Software Object 940 gets row from the cursor set which is Source Table Code l and Source_Table_Code_2 945. Communication from Software Object 940 to Software Object 950. 950. Software Object 950, executes the complex match 955. Communication from Software Object 950 to Software Object 10
  • Software Object 1000 Creates data cursor "13A” by doing an SQL select on the database to retrieve all rows equal to Source_Table_Code_2 from
  • Reconcihation_DataJVIatches_Tb for Source_Table_Code_2 1030 1030.
  • Software Object 1030 sets the date range for comparisons 1040.
  • Software Object 1040 checks cursor "13B" for EOF
  • Loop Counter 0 1080.
  • Software Object 1080 increments the Loop Counter by one 1090.
  • Software Object 1090 checks the Loop Counter to make sure it is less than or equal to the number of data objects in data collection "13C" 1100. Communication from Software Object 1090 to Software Object 1200 if Software
  • Object 1090 output is Yes 1110. Communication from Software Object 1090 to Software Object 1120 if Software Object 1090 output is No
  • Object 1120 output is YES 1140. Communication from Software Object 1120 to Software Object 1040 if Software Object 1120 output is NO
  • Software Object 1150 executes an SQL Insert into Reconcihation Data Matches Tb using the Data lD from the current row in cursor "13B” and the DataJD from data row(s) contained in the data object found at the Match Index in data collection "13C” 1160.
  • Software Object 1160 removes the data object found at Match Index from Data Collection "13C"
  • Software Object 1300 a Child of Software Object 260, executes an SQL select to obtain User D, Bank Account JSTumber, and Reconcihation Code from
  • Reconcihation Data Tb to Reconcihation_Report_Data_Tb 1315 The Software Object 1315, retrieves SQL Return Code 1320. Software Object 1320, performs an SQL Insert to copy data from
  • Table Code is Other 1510. Communication from Software Object 1500 to Software Object 1540 if the
  • Table Code is Bank 1515 Software Object 1515 handles future ("Other") data types
  • Table Code is Ledger. 1540.
  • Software Object 1540 executes an SQL Select Set-Local Variables
  • Software Object 1550 executes an SQL select on the Reconcihation Data Tb table summing up transaction net amount for the current BatchJSTumber and Table_Code 1560.
  • Software Object 1560 initializes transaction
  • Software Object 1570 executes an SQL Update on ReconciliationJTb table 1575.
  • Software Object 1575 retrieves the SQL Return Code
  • Software Object 1580 executes an SQL Insert using the Reconcihation Data Tb table, join to the Reconcihation_Data_Matches_Tb table and Bank Tb table; inserting all Bank JDDs from the Bank Tb matched during the reconciliation into the
  • Software Object 1620 executes an SQL Select on the Reconcihation Data Tb table summing up transaction net amount for the current BatchJSTumber and Table_Code 1630.
  • Software Object 1630 initializes transaction
  • Software Object 1640 performs an SQL Update setting the ReconcihationJTb table processor batch ending amount equal to reconciliation amount in Software Object
  • Software Object 1645 retrieves the SQL Return Code 1650.
  • Software Object 1650 executes an SQL insert using the Reconcihation _Data_Tb table, join to the Reconciliation DataJVIatches Tb table and Processor Tb table; inserting all Processor Ds from the Processor Tb matched during the reconciliation into the Reconcihation Cleared Data Tb 1660.
  • Software Object 1660 retrieves the SQL Return Code 1670.
  • Software Object 1670 commits transaction
  • Software Object 1680 executes an SQL Select for current BatchJSTumber 1690.
  • Software Object 1690 executes an SQL Select on the Reconcihation Data Tb table summing up transaction net amount for the current BatchJNumber and Table_Code 1700.
  • Software Object 1700 initializes transaction 1710.
  • Software Object 1710 executes an SQL Update to the reconcihation table; setting ledger batch ending amount equal to local variable reconcihation amount for current variable for current BatchJSTumber
  • Software Object 1720 executes an SQL Insert using the Reconcihation _Data_Tb table, join to the Reconcihation Data Matches Tb table and Ledger Tb table; inserting all LedgerJDs from the Ledger Tb matched during the reconcihation into the Reconciliation_Cleared_Data_Tb
  • Software Object 1730 retrieves the SQL Return Code 1800.
  • Software Object 1800 performs OR function 1805.
  • Software Object 1805 initializes transaction
  • Software Object 1810 checks the parameter received to determine if the Table_Code parameter is Null 1820. Communication from Software Object 1810 to Software Object 1840 if Null
  • Software Object 1860 executes an SQL Delete on Reconcihation_DataJVIatches_Tb joining to Reconcihation Data Tb deleting the current BatchJSTumber for the current Table_Code
  • Software Object 1864 deletes rows from Reconciliation JVIatches Tb by joining to Reconcihation Data Tb on DataJD equal to Data_ ⁇ )_2 and current BatchJSTumber and Table Code 1866. Software Object 1866, retrieves the SQL Return Code
  • Software Object 1870 Executes an SQL Delete on Reconciliation J)ata_Tb for current BatchJSTumber and Table_Code 1875.
  • Software Object 1875 retrieves the SQL Return Code 1880.
  • Software Object 1880 commits transaction 1890.
  • Software Object 1890 selects output communication path according to communication path utilized by input, as follows: If input on 545 exit on 555
  • Software Object 2120 accepts User input of POS data
  • Software Object 2210 User selection of input screen for Ledger data.
  • Software Object 3010 creates an input screen for User and asks whether this is a new Merchant Partner 3020. Communication from Software Object 3010 to Software Object 3040 if ' ⁇ es"
  • Software Object 3050 creates an input screen for User to select existing Merchant
  • Software Object 3100 creates an input screen for User to select Agreement form; if new Agreement is added it will be auto selected 3105. Communication from User to Software Object 3100 3110.
  • Software Object 3110 creates an input screen for User to set up new terminals 3115. Communication from User to Software Object 3110
  • Software Object 3150 creates an input screen for User to select terminal; if user setup new terminal it will be automatically selected; otherwise select from a list of terminals already in the database for this Merchant Partner 3155. Communication from User to Software Object 3150 3160. Communication from Software Object 3150 to Software Object 5600
  • Agreement D 3720 Software Object 3720, queries AgreementsJTb and Agreement_Rates_Tb to setup local variables with the discount rates and transaction fees for the agreement found in
  • Software Object 3710 3730 utilizes the local variables setup in Software Object 3720 to calculate the gross, net and fee amounts for the Bank data 3740.
  • Software Object 3740 initializes transaction 3750.
  • Software Object 3750 executes an SQL Insert into BankJTb 3760.
  • Software Object 3760 retrieves the SQL Return Code 3770.
  • Software Object 3770 commits the transaction
  • Software Object 3780 a Child of Software Object 80, selects output communication path according to commumcation path utilized by input, as follows:
  • Software Object 3800 accepts input from communication 76 OR 2140 OR 4570 3810.
  • Software Object 3810 looks up MerchantJSTumber in MerchantJSTumbersJTb gets
  • Software Object 3830 uses the local variable created by Software Object 3820 to calculate the gross, net and fee amounts for the POS data 3840.
  • Software Object 3840 initializes transaction 3850.
  • Software Object 3850 executes a SQL Insert into ProcessorJTb 3860.
  • Software Object 3860 retrieves the SQL Return Code 3870.
  • Software Object 3870 commits transaction , 3880.
  • Software Object 3880 a Child of Software Object 82, selects output communication path according to communication path utilized by input, as follows: If entered via Communication 76 exit via Communication 85 If entered via Communication 2140 exit via Communication 2170
  • Software Object 3900 accepts input from commumcation 78 OR 2240 OR 4580 3910.
  • Software Object 3910 performs join on MerchantJ-,edger_Account_Tb by looking up MerchantJSTumber and ledger account number and joining to Merchant JSTumbersJTb to find Merchant_PartnerJDD and then to MerchantsJTb to get the Agreement JD and stores result in a local variable 3920.
  • Software Object 3920 queries AgreementsJTb and Agreement_Rates_Tb to setup local variables with the discount rates and transaction fees for the agreement found in
  • Software Object 3910 3930 uses the local variable created by Software Object 3920 to calculate the gross, net and fee amounts for the Ledger data
  • Software Object 3940 initializes transaction 3950.
  • Software Object 3950 executes a SQL Insert into LedgerJTb 3960.
  • Software Object 3960 retrieves the SQL Return Code 3970.
  • Software Object 3970 commits transaction 3980.
  • Software Object 3980 a Child of Software Object 84, selects output communication path according to communication path utilized by input, as follows: If entered via Communication 78 exit via Communication 85
  • Software Object 4000 a Child of Software Object 170, creates User reconcihation screen 4005. Communication from User to Software Object 4010 4010. Software Object 4010, User selects which of the two accounts to compare on the screen 4020. Software Object 4020, takes the first of the two accounts selected in Software Object
  • Reconcihation_DataJVIatches_Tb 4030 displays on screen the rows Selected in Software Object 4020 4040.
  • Software Object 4040 takes the second of the two accounts selected in Software Object 4010 and performs an SQL Select on Reconcihation Data Tb and
  • Software Object 4050 displays the rows Selected in Software Object 4040 4060.
  • Software Object 4060 displays inquiry asking User if "finished” 4070.
  • Communication from User to Software Object 4060 4080. Commumcation from Software Object 4060 to Software Object 4100 if "Yes” 4090.
  • Software Object 4100 a Child of Software Object 170, displays User option to reconcile another set of accounts in this session 4110.
  • Communication from Software Object 4100 to Software Object 4010 if "Yes" 4120.
  • Software Object 4130 creates screen for User to elect to set options, viewing options and filters 4135. Communication from User to Software Object 4130
  • Object 4210. 4225. Communication from User to Software Object 4220 4230.
  • Software Object 4230 initializes transaction 4240.
  • Software Object 4240 executes SQL inserts on Reconciliation )ata_Matches_Tb; inserting the Data Ds from the rows that were manually matched by the User in
  • Software Object 4210 4250 retrieves the SQL Return Code 4260.
  • Software Object 4260 commits transaction 4270.
  • Software Object 4270 creates display of User options available and communicates
  • Software Object 4510 displays User Adjustment screen and accepts User input 4520.
  • Software Object 4520 sets commumcation path on case User selects "Save” or
  • Software Object 5000 a Child of Software Object 3040, receives Communication from Communication 3020 OR Communication 5002 OR Communication 5115 5002.
  • Software Object 5010 accepts User input of data 5015. Commumcation from User to Software Object 5010,
  • Software Object 5100 a Child of Software Object 3090, displays User Agreement setup screen 5105.
  • Software Object 5105 creates screen to query User whether to set up new Processor Partner 5110. Communication from User to Software Object 5105
  • Software Object 5135 creates screen for User selection from hst of processor partners available or if a new processor partner was entered it will be automatically selected
  • Software Object 5180 creates screen for User to input rate(s) for new agreement
  • Software Object 5190 close input screen 5200.
  • Software Object 5200 creates Terminal setup screen
  • Software Object 5210 accepts User data inputs
  • Software Object 5250 executes an SQL Insert on input data from Software Object 5210 into Terminals Tb
  • Software Object 5300 a Child of Software Object 3200, creates the screen to setup MerchantJSTumber.
  • Software Object 5310 accepts User input of data
  • Software Object 5350 execute an SQL Insert of input data from Software Object 5310 into Merchant JSTumbers Tb
  • Software Object 5370 closes input screen 5400.
  • Software Object 5400 a Child of Software Object 5050, initializes transaction
  • Software Object 5410 executes an SQL Insert of Partner data into PartnersJTb
  • Software Object 5430 executes an SQL Insert into PartnerJJierarchy_Tb
  • Software Object 5440 retrieves the SQL Return Code 5450.
  • Software Object 5450 a Child of Software Object 5050, commits transaction to associate the MerchantJSTumber to the terminal; performed by inserting the Terminal_ID selected and the MerchantJSTumber selected into Terminal JVIerchantJSTumbers_Tb 5520.
  • Software Object 5520 retrieves the SQL Return Code
  • Software Object 5530 executes an SQL Insert into Merchant_Bank_Account_Tb
  • Software Object 5550 executes an SQL Insert into Merchant J edger_Account_Tb
  • Software Object 5600 creates an input screen for User and asks whether this is a new Bank account
  • Software Object 5650 creates an input screen for User to select Bank account
  • Software Object 5710 creates an input screen for User to select Ledger account
  • Software Object 6110 executes an SQL Insert into Bank Accounts Tb of new Bank Account data 6120.
  • Software Object 6120 retrieves the SQL Return Code
  • Software Object 6130 executes an SQL Insert into User_Accounts_Tb table to associate the new bank account with the user
  • Software Object 6150 commits the transaction 6200.
  • Software Object 6200 creates Ledger set up screen
  • Software Object 6210 accepts User input of Ledger Account data
  • Software Object 6260 executes an SQL Insert of Ledger data input into Software Object 6210 into Ledger_Accounts_Tb
  • Software Object 6280 closes input screen 6300.
  • Software Object 6300 a Child of Software Object 5180, creates Rate screen for User setup of processor rates
  • Software Object 6580 executes an SQL Insert of data input into Software Object
  • Software Object 6775 executes an SQL delete(s) to remove Bank Accounts not selected in Software Object 6720 from User_Aceounts_Tb 6780.
  • Software Object 6780 executes SQL Inserts of UserJTD and selected Bank_Account_ ⁇ ) into the User_Accounts_Tb table
  • Software Object 6800 commits the transaction 6810.
  • Software Object 6810 closes input screen
  • Software Object 6860 creates Merchant Partner/User Association screen
  • Software Object 7025 executes an SQL Delete(s) on UserJVIerchantsJTb for Merchant Partners not selected in Software Object 6870.
  • Software Object 7030 executes an SQL Insert(s) into UserJVIerchantsJTb for all Merchant Partners selected in Software Object 6870.
  • Fig. 1 is a block diagram of the instant invention in an internet-enabled configuration.
  • Fig. 2 is a flow chart depicting the communication paths between the Software Objects of the Reconciliation Software of the instant invention and the Bank, the Merchant Account Processor, the Point of Sale and/or Electronic Payment terminal, the Database, and "Other".
  • Fig. 3a is a flow chart depicting initialization of data transfer into data file "3 A”.
  • Fig. 3b is a flow chart depicting data retrieval from the ledger/legacy system.
  • Fig. 4 is a flow chart depicting periodic sweep of data file "3 A" into the database.
  • Fig. 5a is the first part of a flow chart depicting the overall operation of the reconcihation software of the instant invention.
  • Fig. 5b is the second part of a flow chart depicting the overall operation of the reconciliation software of the instant invention.
  • Fig. 6 is a flow chart depicting the operation of the Child Software Objects of Software Object 105 in Fig. 5a performing an SQL Insert into the Reconcihation Tb table.
  • Fig. 7 is a flow chart depicting the operation of the Child Software Objects of
  • Fig. 8 is a flow chart depicting the operation of the Child Software Objects of Software Object 130 in Fig. 5a initializing reconciliation procedure by gathering data and inserting it into the Reconcihation Data Tb table.
  • Fig. 9 is a flow chart depicting the operation of the Child Software Objects of Software Object 480 in Fig. 8 performing a query of the database to obtain the starting procedure and executing such fetched starting procedure.
  • Fig. 10 is a flow chart depicting the operation of the Child Software Objects of Software Object 140 in Fig. 5a while performing the first pass or "simple match" of the reconciliation process of the instant invention.
  • Fig. 11 is a flow chart depicting the operation of the Child Software Objects of Software Object 850 in Fig. 10 performing the "simple match" of the reconciliation process of the instant invention.
  • Fig. 12 is a flow chart depicting the operation of the Child Software Objects of Software Object 150 in Fig. 5a starting the "complex match" of the instant invention by taking all of the rows in the Reconcihation )ata_Tb table that did not match in the previous steps and, by combining rows, tries to locate matches.
  • Fig. 13a is the first page of a flow chart depicting the operation of the Child Software Objects of Software Object 950 in Fig. 12 performing a complex row matching of data within accounts being reconciled.
  • Fig. 13b is the second page of a flow chart depicting the operation of the Child Software Objects of Software Object 950 in Fig. 12 performing a complex row matching of data within accounts being reconciled.
  • Fig. 14a is the first page of a flow chart depicting the operation of the Child Software Objects of Software Object 260 in Fig. 5b cleaning up temporary files, performing backup of all reconciliation data tables so that reports can be produced and labeling ah of the matched transactions as cleared.
  • Fig. 14b is the second page of a flow chart depicting the operation of the Child Software Objects of Software Object 260 in Fig. 5b cleaning up temporary files, perfo ⁇ ning backup of all reconciliation data tables so that reports can be produced and labeling all of the matched transactions as cleared.
  • Fig. 15 is a flow chart depicting the operation of the Child Software Objects of Software Object 1390 in Fig. 14b performing a query of the database to obtain the ending procedure and executing such fetched ending procedure.
  • Fig. 16 is a flow chart depicting the operation of the Child Software Objects of
  • Fig. 17 is a flow chart depicting the creation of a User screen for input of Bank data.
  • Fig. 18 is a flow chart depicting the creation of a User screen for input of POS data.
  • Fig. 19 is a flow chart depicting the creation of a User screen for input of Ledger data.
  • Fig. 20a is the first page of a three page flow chart depicting the creation and operation of a wizard for User setup of a new Account (Merchant, POS, Bank, User, or Other), Agreement, User, or Terminal.
  • Fig. 20b is the second page of a three page flow chart depicting the creation and operation of a wizard for User setup of a new Account (Merchant, POS, Bank, User, or Other), Agreement, User, or Terminal.
  • a new Account Merchant, POS, Bank, User, or Other
  • Agreement User, or Terminal.
  • Fig. 20c is the third page of a three page flow chart depicting the creation and operation of a wizard for User setup of a new Account (Merchant, POS, Bank, User, or Other), Agreement, User, or Terminal.
  • Fig. 21 is a flow chart depicting the operation of the Child Software Objects of
  • Fig. 22 is a flow chart depicting the operation of the Child Software Objects of Software Object 82 in Fig. 4 inserting POS data into the Processor Tb table.
  • Fig. 23 is a flow chart depicting the operation of the Child Software Objects of Software Object 84 in Fig. 4 inserting Ledger data into the LedgerJTb table.
  • Fig. 24a is the first page of a two page flow chart depicting the operation of the Child Software Objects of Software Object 170 in Fig. 5b permitting User input to the reconcihation process of the instant invention.
  • Fig. 24b is the second page of a two page flow chart depicting the operation of the Child Software Objects of Software Object 170 in Fig. 5b permitting User input to the reconciliation process of the instant invention.
  • Fig. 25 is a flow chart depicting the operation of the Child Software Objects of Software Object 4200 in Fig. 24b creating a screen for User to enter Bank/POS/Ledger/Other adjustments
  • Fig. 26 is a flow chart depicting the operation of the Child Software Objects of
  • Fig. 27 is a flow chart depicting the operation of the Child Software Objects of Software Object 3090 in Fig. 20a creating a screen for User to setup a new agreements with Processors.
  • Fig. 28 is a flow chart depicting the operation of the Child Software Objects of
  • FIG. 29 is a flow chart depicting the operation of the Child Software Objects of Software Object 3200 in Fig. 20b creating a screen for User to setup a new MerchantJSTumber.
  • Fig. 30 is a flow chart depicting the operation of the Child Software Objects of Software Object 5050 in Fig. 26 Inserting Partner data into the database.
  • Fig. 31 is a flow chart depicting the operation of the Child Software Objects of Software Object 3220 in Fig. 20c performing all of the associations to the MerchantJSTumber the User entered in the merchant setup wizard.
  • Fig. 32 is a flow chart depicting the operation of the Child Software Objects of Software Object 5630 in Fig. 20b creating a screen for the User to setup a new Bank account.
  • Fig. 33 is a flow chart depicting the operation of the Child Software Objects of Software Object 6060 in Fig. 32 executing SQL Inserts of new Bank account data into the database and associating the current User with the new Bank account.
  • Fig. 34 is a flow chart depicting the operation of the Child Software Objects of Software Object 5690 in Fig. 20b creating a screen for the User to setup a new Ledger account.
  • Fig. 35 is a flow chart depicting the operation of the Child Software Objects of Software Object 5180 in Fig. 27 creating a screen for the User to setup rates for a Processor agreement.
  • Fig. 36 is a flow chart depicting the creation and operation of a screen for User setup of a new User.
  • Fig. 37 is a flow chart depicting the creation and operation of a screen for User setup of associations between User and Bank accounts.
  • Fig. 38 is a flow chart depicting the creation and operation of a screen for User setup of associations between User and Merchant Partners.
  • Fig. 39 is a printout of the source code that Inserts unmatched rows in the Reconcihation Data Matches Tb table using the Reconcihation Data Tb table. Only matches on rows where the BatchJSTumber, MerchantJSTumber, Transaction JDate, Fee, Net, and Gross Amounts are equal.
  • This query takes three parameters: BatchJSTumber, Source_Table_Code_l, and Source_Table_Code_2.
  • the Reconcihation Data Tb is joined to itself with each instance on pulling the SourceJTable Code l and Source_Table_Code_2. Data Ds equal to Source_Table_Code_l are inserted in DataJD_l and DataJDDs for Source_Table_Code_2 are inserted into Data_ID_2 of the Reconciliation Data Matches Tb.
  • Fig. 40 is a printout of the source code that Inserts unmatched rows in the Reconcihation Data Matches Tb table using the Reconciliation JDataJTb table. Only matches on rows where the BatchJSTumber, MerchantJSTumber, TransactionJDate, Fee, Net, and Gross Amounts are equal.
  • This query takes three parameters: BatchJSTumber, Source Table Code l, and Source_Table_Code_2.
  • the Reconcihation Data Tb is joined to itself with each instance on pulling the Source_Table_Code_l and Source_Table_Code_2.
  • Data lDs equal to Source Table Code l are inserted in Data_TD_2 and Data IDs for Source_Table_Code_2 are inserted into Data J0D_1 of the Reconciliation JDataJVIatch.es JTb.
  • Fig. 41 is a printout of the source code that Inserts Bank data into the
  • Reconcihation Data Tb table where the bank data has not already been cleared for the same type of reconcihation being performed. On the insert the data is being grouped by
  • Fig. 42 is a printout of the source code that Inserts POS data into the Reconcihation JDataJTb table where the POS data has not already been cleared for the same type of reconcihation being performed. On the insert the data is being grouped by BatchJSTumber, POS Table_Code, MerchantJSTumber, Transaction )ate, and Transaction Type Code and summed on the following fields: Transaction Gross, Net and Fee amounts.
  • Fig. 43 is a printout of the source code that Inserts Ledger data into the Reconcihation Data Tb table where the Ledger data has not already been cleared for the same type of reconcihation being performed.
  • the data is being grouped by BatchJSTumber, Ledger Table_Code, MerchantJSTumber, TransactionJDate, and Transaction_Type_Code and summed on the following fields: Transaction Gross, Net and Fee amounts.
  • Fig. 44 is a printout of the source code that Selects Table Source Code l data from the Reconcihation )ata_Tb table where there is no corresponding match for Table_Source_Code_2 data.
  • Three parameters are needed to run the query: BatchJSTumber, Table_Source_Code_l, and Table jSouree_Code_2.
  • the Select uses a view that shows the rows for Table_Source_Code_2 that already have matches.
  • Fig. 45 is a printout of the source code that View used in the Select in Figure 44. Selects matches on the right side (Data_ID_2) of the Reconcihation Data Matches Tb.
  • Fig. 46 is a printout of the source code that Inserts matched Bank data rows from the
  • the Bank lD is found by matching rows from the Reconcihation Data Tb with rows in the Bank Tb where the MerchantJSTumber and TransactionJDate is equal.
  • Fig. 47 is a printout of the source code that Inserts matched POS data rows from the Reconcihation JDataJTb table and the Reconcihation JDataJVIatchesJTb table into the Reconcihation_ClearedJ)ata Tb table. Inserts the current Reconcihation Code,
  • the Processor ID is found by matching rows from the Reconcihation Data Tb table with rows in the Processor Tb table where the MerchantJSTumber and TransactionJDate are equal.
  • Fig. 48 is a printout of the source code that Inserts matched Ledger data rows from the Reconcihation Data Tb table and the Reconcihation JDataJVIatchesJTb table into the Reconcihation Cleared Data Tb table. Inserts the current Reconcihation Code, Ledger Table_Code and the LedgerJ-D of rows that matched in the reconcihation into the Reconcihation Cleared Data Tb. The Ledger D is found by matching rows from the Reconciliation )ata_Tb table with rows in the Ledger Tb table where the MerchantJSTumber and TransactionJDate are equal.
  • Fig. 49 is a printout of the screen depicting the field names for and the relationships between the Partners Tb, UsersJTb, and the UserJVIerchantsJTb table, the User_AccountsJTb table, and the Partner JffierarchyJTb table.
  • Fig. 50 is a printout of the screen depicting the field names for and the relationships between the AgreementsJTb table and the AgreementJR.ates_Tb table.
  • Fig. 51 is a printout of the screen depicting the field names for and the relationships between the Partners Tb table, the Bank_Accounts_Tb table and the Ledger_Accounts_Tb table.
  • Fig. 52 is a printout of the screen depicting the field names for and the relationships between the BankJTb table, the LedgerJTb table, and the ProcessorJTb table.
  • Fig. 53 is a printout of the screen depicting field names for and the relationships between the ReconciliationJTb table, the Reconcihation JData_Tables_Tb table, the Reconciliation LocationsJTb table, Reconciliation JVIatching Tb table, the Reconciliation DecodeJTb table, and the Reconciliation_Associations_Tb table.
  • Fig. 54 is a printout of the screen depicting field names for and the relationships between the MerchantsJTb table, the Terminals Tb table, the MerchantJSTumbers_Tb table, the Terminal MerchantJSTumbers Tb, the Merchant_Ledger_Account_Tb table, and the Ledger_Accounts_Tb table.
  • Fig. 55 is a printout of the screen depicting field names for and the relationships between the Reconcihation Data Tb table, the Reconciliation _Report_DataJTb table, the Reconciliation Cleared DataJTb table, the Reconciliation JDataJVIatchesJTb table, and the Reconciliation J ⁇ eport MatchesJTb table.
  • Fig. 56 is a printout of a sample standard Month End Exceptions report comparing the
  • Fig. 57 is a printout of a sample standard Month End Exceptions report comparing the POS transactions to the Bank transactions.
  • Fig. 58a is a printout of the first of three pages of a sample standard Reconcihation Report of Outstanding Deposits by Transaction Type Code.
  • Fig. 58b is a printout of the second of three pages of a sample standard Reconcihation Report of Outstanding Deposits by Transaction Type Code.
  • Fig. 58c is a printout of the third of three pages of a sample standard Reconcihation Report of Outstanding Deposits by Transaction Type Code.
  • Fig. 59 is a printout of a sample standard Daily Transactions Report.
  • Fig. 60a is a printout of the first page of a two page sample standard Transaction Report.
  • Fig. 60b is a printout of the second page of a two page sample standard Transaction Report.
  • Fig. 61 is a printout of a sample User screen. Best Mode for Carrying Out the Invention
  • the instant invention is of a software program and system that reconciles a merchant's point of sale/electronic payment transactions to the merchant's bank account deposits and chargebacks, and then to the merchant's legacy general ledger system or "Other" source.
  • the software program of the preferred embodiment of the instant invention will be described in terms of software objects constructed in accordance with the methodology of object oriented programming. It being understood that the particular computer language utilized to implement the software program is not determinative of whether the invention is being practiced.
  • the discussion of object oriented programming (OOP), class libraries, and frameworks contained in U.S. Patent 6,026,379 (page 7, line 26, through page 11, line 46) is on point, correct, and is hereby adopted and incorporated by reference herein.
  • a preferred embodiment of the instant invention was written in Microsoft's Visual Basic®.
  • the instant invention is expected to be available for utilization in an internet/intranet environment.
  • the chent 1 which is a software program and may be a browser, is seen to be in communication 3 with the internet/intranet interface 5, which in turn is in communication 7 with a firewall 9.
  • the firewall 9 is optional, but if used as in the preferred embodiment is in communication 11 with the software portion 14 of the instant invention, which is assumed to be resident on a suitable computing platform.
  • a database 16 which is in commumcation 40 with the software objects 30 of the instant invention.
  • the software objects 30, comprise software object 24, a web server 20, and a web interactive language object 22 which intermediates between the web server 20 and the software objects 24.
  • the software object 30 (referred to as "software object of the reconcihation software” in Fig. 2) of the instant invention is seen to be in communication 40 with the database 16, in communication 44 with the merchant's general ledger program 42, in communication 34 with and receiving data from a source of the merchant's point of sale credit card/electronic payment transaction data 32 (referred to in Fig. 2 as “electronic transactions"), in communication 38 with and receiving data from the merchant's bank account 36, and in communication 41 with "Other” 45.
  • the "Other" 45 category of inputs is to depict future types of account data that may be reconciled with the software of the instant invention.
  • the instant invention is capable of simultaneous reconciliation of any two or more accounts.
  • Fig. 2 serves to emphasize and depict the instant invention acting between three or more sources of data (the electronic transactions 32, the bank account 36, the general ledger 42, and Other 45) and the database 16.
  • Fig. 3a depicts the initiation of data transfer into the software objects of the instant invention.
  • Data transfer may be initiated by communication 46 from the Merchant or by communication 48 from the data provider.
  • the data provider may be a Bank, a Terminal, a Ledger program mnning on another computing platform, or any other source which, in the preferred embodiment, communicates via TCP/IP, using FTP or other protocol.
  • Software object 50 receives data via communication 46 or communication 48 and transfers such data as a flat file to the local LAN upon which the program, the software objects of the instant invention, is installed.
  • Data file 3 A is the name given to a temporary data storage file used for temporary storage on the local LAN of various data throughout this description of the preferred embodiment.
  • Data file 3A is given a unique file name each time it is processed, written to an input directory. There may be multiple data file 3 A files open in the system at any given time. Each data file 3A is stamped with a date/time stamp providing a unique sequence number for each record in order to prevent the over-writing of other 3 A data files.
  • Fig. 3B depicts the retrieval of data from the Merchant's legacy ledger. Such retrieval may be accomplished either via human intervention or via a scheduled task.
  • Software object 54 initializes the retrieval of data and communicates the completion of such initialization to software object 56.
  • Software object 56 exports the electronic payment transaction and other data entries from the Merchant's legacy Ledger system.
  • Software object 56 communicates its completion of the importation of the data to software object 58 which stores the data in data file 3A.
  • Fig. 4 depicts the transfer of data from data file 3A into the database 16.
  • Software object 60 initializes the transfer as a scheduled task.
  • Software object 60 communicates completion of mitiahzation to software object 62 which opens an input data file 3 A and receives from the input data file 3 A either an open indication or an EOF indication.
  • Software object 62 communicates the open indication or the EOF indication to software object 64.
  • Software object 64 determines whether an EOF indication is present. If an EOF indication is present, software object 64 commumcates 66 this fact to software object 86.
  • Software object 86 upon receipt of the communication 66 from software object 64, acts to close the input file, data file 3A.
  • Software object 86 communicates the fact that data file 3A has been closed to software object 88 which acts to archive the data file 3 A as a record of data received by the instant invention. If Software object 64 determines that the file opened by software object 62 was not an EOF, then software object 64 communicates 68 this fact to software object 70 which acts to read the next sequential data record from the data file 3A. Software object 70 communicates the data record to software object 72. Software object 72 selects an output communication path dependent upon the type, or form, of the data record received by software object 72 from software object 70.
  • the software object 72 chooses output communication path 74, if the data record type was POS data, the software object 72 chooses output communication path 76, if the data record type was Ledger data, the software object 72 chooses output communication path 78, and if the data record type was "Other" data, the software object 72 chooses output communication path 79.
  • Software object 80 receives communication 74 of the Bank data from software object 72 and acts to store such data in the database 16.
  • Software object 80 then communicates 85 the completion of storage of the data to software object 64.
  • Software object 82 receives communication 76 of the POS data from software object 72 and acts to store such data in the database 16.
  • Software object 82 then communicates 85 the completion of storage of the data to software object 64.
  • Software object 84 receives communication 78 of the Ledger data from software object 72 and acts to store such data in the database 16.
  • Software object 84 then communicates 85 the completion of storage of the data to software object 64.
  • Software object 87 receives communication 79 of the Other data from software object 72 and acts to store such data in the database 16.
  • Software object 87 then communicates 85 the completion of storage of the data to software object 64.
  • Software Object 64 upon receipt of communication 85, then acts to again check for EOF. If EOF is not detected by Software Object 64, then software object 64, again, communicates 68 this fact to software object 70 which acts to read the next sequential data record from the data file 3 A and the above-stated cycle repeats until EOF is reached.
  • Fig. 5 a and Fig. 5b depict the operation of the software object that performs the reconcihations, the objects of the instant invention.
  • Fig. 5a depicts the initiation of the reconcihation operation by receipt of communication 90 from the User to software object 97.
  • Software object 97 creates a User input screen so that the User may, via communication 95, input the reconciliation parameters.
  • Such input parameters include the User's selection of the Bank account and other accounts to be reconciled, and the User's entry of the ClosingJDate for the reconcihation.
  • a table within database 16, User ccountsJTb stores all of the accounts for which each specific user is authorized. The User to Account association is depicted in Fig. 37.
  • the User can then select only accounts for which the User is authorized according to the authorizations assigned to that User in the User AccountsJTb. Setup of users is depicted in Fig. 36.
  • the User can perform reconciliations by comparing any data files to which the User has access.
  • the User can create any number of comparisons or reconcihations between any number of data sets. Due to limited screen space available, only two-way comparisons are depicted in the Drawings which are part of this apphcation. However, a circular reconcihation is still being performed between all data sets that have been designated by the User. Each reconcihation between accounts sets flags in the accounts indicating that a match occurred.
  • Software object 115 communicates 120 the completion of User's section of Merchant Partner locations to software object 130.
  • Software Object 130 upon receipt of communication 120, uses the data obtained from the User by software object 97, the BatchJSTumber from software object 105, and the data obtained from the User by software object 115 to collect and prepare the data for processing. Once software object 130 has completed collecting and preparing the data for processing, it communicates 135 the fact of the data's availability to software object 140.
  • the "preparing" of the data for processing will include, for example, the combination of data from each location selected by User in software object 115 into a single table in database 16 named Reconcihation DataJTb, to correspond to the hypothetical situation where the credit transactions from all of such locations is deposited by the Merchant into a single Bank Account.
  • Software object 140 upon receipt of commumcation 135 from software object 130, acts to perform a simple match between the data collected and prepared for processing by software object 130.
  • a "simple" match is a search for identical records between the data sets collected and prepared for processing by software object 130.
  • software object 140 Once software object 140 has completed its "simple" match, it communicates 145 the fact of its completion to software object 150 which then commences a second or “complex” matching of those records remaining unmatched between the data sets collected and prepared for processing by software object 130.
  • a "complex" match is a search for identities between combinations of records remaining unmatched between each of the data sets collected and prepared for processing by software object 130.
  • software object 150 Upon completion of the "complex” match, software object 150 communicates 165 the fact of such completion to software object 170.
  • Software object 170 creates a screen for the User to manually enter any necessary adjustments and to manually make such matches as the User may identify. Upon User's completion of his manual matching and adjustments, the software object 170 communicates 175 the fact of completion to software object 195.
  • Software object 195 queries the User as to whether the User is finished attempting to make manual matches and the User communicates 190 his response to software object 195. If the User has communicated 190 to software object 195 that the User is not finished attempting to make manual matches, software object 195 communicates 210 to software object 220 that exception reports need to be generated. Upon receipt of communication 210 from software object 195, software object 220 creates a screen that queries the User as to which exception reports are desired. Once the User has made his selections, software object 220 acts to create the selected exception reports and communicates 240 a standard set of exceptions reports to a printer, viewer, or file, (see Figs. 56 and 57) and communicates 250 a custom set of exception reports (see Figs. 58, 59 and 60) selected by the User to a printer, viewer, or file.
  • Fig. 56 is a printout of a sample standard Month End Exceptions report comparing the Bank transactions to the transactions posted to the Ledger.
  • Fig. 57 is a printout of a sample standard Month End Exceptions report comparing the POS transactions to the Bank transactions.
  • Figs. 56 and 57 are samples of standard exception reports that will hst all transactions that have not been previously "matched”. The outstanding deposits (those that have not cleared the bank) will be transferred to the standard reconcilation reports. The User will be able to direct the report contents from either exception report (Fig. 56 or Fig. 57) onto an interactive screen. This will enable the User to manually make any adjustments, corrections or changes to the transactions that are necessary in order to achieve a balance.
  • the criteria for the displayed elements of the standard reconcihation report can be filtered or changed by the User based on the Bank Account, MerchantJD (location) or the transaction type for the standard reconcihation report to be generated.
  • the standard reconcihation report screen, Fig. 58 contents can be modified by the User selections in the "puh-down" menus, and can be filtered specificaUy for each location, each bank account, by transaction type; and by any other database 16 table content. Note that in Fig. 58, the display is of transactions that have been processed at a POS, booked into the ledger, but have not yet cleared the bank, therefore the transactions are considered "outstanding" in accounting terms. Fig.
  • Fig. 60 is a sample of a display screen of full detail report, summed and sorted by card type.
  • the software object 195 communicates 200 this fact to software object 260 which then acts to clean up the data sets being reconciled and archive the database tables and mark all of the transactions (records) that have been matched as cleared.
  • Software object 260 communicates 265 the completion of its tasks to software object 270.
  • Software object 270 upon receipt of communication 265 from software object 260 and with selections communicated 280 from User acts to generate both standard and custom reconcihation reports.
  • Software object 270 communicates 290 its generated standard reconciliation reports to a printer, viewer, or file, and communicates 300 its custom reconcihation reports as selected by User to a printer, viewer, or file (see Fig 56, Fig 57).
  • Fig. 6 depicts in detail the operation of software object 105 (see Fig. 5a).
  • the function of the software objects depicted in Fig. 6 is to initialize the reconciliation by performing an SQL Insert into the ReconciliationJTb table.
  • software object receives it's input communication 100 from software object 97.
  • communication 100 is depicted going to software object 310, a Child of software object 105.
  • Software object 310 acts to initialize the SQL Insert into the ReconciliationJIb table that is accomplished by software object 105.
  • Software object 310 communicates completion of initialization to software object 320 which then Inserts the input parameters communicated 100 from software object 97 (see Fig. 5a.) into the Reconcihation Tb table in the database 16.
  • the data within the ReconciliationJTb is organized by Batch Numbers.
  • a BatchJSTumber is automatically assigned by the database 16 when data is inserted into the Reconcihation_Tb table.
  • Software object 320 communicates the completion of the database 16 insertion to software object 330 which then acts to retrieve the BatchJSTumber from the database 16 and communicate that BatchJSTumber to software object 335.
  • the BatchJSTumber is used throughout the software program of the instant invention.
  • the BatchJSTumber keeps track of what reconciliation the user is working with., via the BatchJSTumber the user can reference the Reconcihation Tb table which will tell the user all of the controls, i.e.: the bank account, bank account number, the user, starting balances and ending balances, whether reconcihation of a particular account has been completed and the date of such completion.
  • the BatchJSTumber Once the BatchJSTumber has been retrieved by software object 330, the BatchJSTumber is passed to each software object in the instant invention that is related to the reconciliation of accounts. Each software object may therefore use the input reconcihation parameters stored as data in the ReconciliationJTb at the assigned BatchJSTumber.
  • Fig. 7 depicts in detail the operation of software object 115 (see Fig. 5a).
  • the function of software object 115 is to create the screen for User selection of the Merchant Partner locations to include in the reconciliation.
  • Software object 350 is the Child of software object 115 (see Fig. 5a) and receives communication 110 from software object 105. The function of the software objects depicted in Fig.
  • software object 350 Upon receipt of communication 110 from software object 105, software object 350 acts to execute an SQL Select from the UserJVIerchantsJTb and Merchant JBank_AccountsJ)v, selecting the Merchants that are assigned to the Bank Account that was selected by the User in software object 97.
  • software object 350 Once software object 350 has completed execution of the SQL Select from the UserJVIerchantsJTb and Merchant JBank_AecountsJ)v, it communicates that fact to software object 360 which then acts to create a screen for the User to select the locations and Merchant Partners whose data is to be included in the reconcihation. After the screen is created by software object 360, software object 360 communicates that fact to software object 380.
  • Software object 380 then acts to accept the User's communication 370 of his selections and to store the User's selections. After the software object 380 has stored the User's selections, it commumcates that fact to software object 390 which then acts to initialize the transaction. Once software object 390 has completed its initialization of the database 16 for the transaction, it communicates such fact to software object 400 which executes an SQL Insert(s) of the Merchant_Partners previously selected by the User into the Reconciliation_Locations_Tb.
  • the ReconcihationJ ocationsJTb table is used throughout the reconciliation process to indicate which Merchant Partners are being included in the reconciliation.
  • Software object 400 communicates the completion of its Insert(s) to software object 405 which then acts to retrieve the SQL Return Code; making sure the Insert(s) were successful. Following its retrieval of the SQL Return Code, software object 405 communicates the completion of it action to software object 410 which then acts to commit the transaction. Once the transaction has been committed by software object 410, software object 410 communicates 120 this fact to software object 130 (see Fig. 5a).
  • Fig. 8 depicts in detail the operation of software object 130.
  • Software object 415 is the Child of software object 130 (see Fig. 5a) and receives communication 120 from software object 115. The function of the software objects depicted in Fig. 8 is to initiate the reconcihation process by gathering data and placing it in the Reconciliation JData Tb table.
  • software object 415 acts to execute an SQL Select using the Batch JSTumber to query the Reconcihation Tb to retrieve the UserJD, Reconcihation_Code and Closing Date. This information is then saved in local variables to be used throughout the software object 130.
  • software object 415 Once software object 415 has completed execution of the SQL Select, it communicates that fact to software object 420 which then executes an SQL Select on the Reconcihation Associations Tb using the current Reconcihation Code.
  • the SQL Select creates a cursor selecting all the Table Codes used in this reconcihation from the Reconcihation Associations Tb.
  • the Reconcihation Associations Tb table determines what data tables are referenced in this reconciliation. Completion of the creation of the cursor is communicated from software object 420 to software object 430 which, following receipt of such communication, acts to perform a check verifying that the cursor is not empty, that there is data in it. If software object 430 determines that the cursor is EOF, or empty, it communicates 440 that fact to software object 490 which then acts to close the cursor. If software object 430 determines that the cursor contains data, it communicates 450 that fact to software object 460.
  • Software object 460 upon receipt of communication 450 from software object 430, acts to retrieve the next row, or record, from the cursor. Each record in the cursor will consist of a Table_Code that will be referenced in software object 470. After software object 460 retrieves the Table_Code, it communicates that fact to software object 470 which then acts to execute an SQL Select on the Reconcihation Data Tables Tb and retrieve the Starting Procedure for the current Table Code as assigned in Software object 460. Each data table has an independent starting procedure (stored in the variable StartingJProcedure) that describes and defines the method of data collection to be used, based on the BatchJSTumber.
  • Software object 470 communicates 475 the completion of its execution of the SQL Select to software object 480 which then utilizes the starting procedure to gather data for the particular table and to total and Insert the gathered data in the Reconciliation JData Tb.
  • Software object 480 communicates 485 the completion of its execution of the SQL Insert to software object 430 which repeats its determination of whether the cursor has reached EOF.
  • Software object 490 communicates 135 the completion of its closure of the cursor to software object 140 (see Fig. 5a).
  • Fig. 9 depicts in detail the operation of software object 480 (see Fig. 8).
  • Software object 500 is the Child of software object 480 and receives communication 475 from software object 470.
  • the function of the software objects depicted in Fig. 9 is to execute the Starting J ⁇ rocedure for the reconciliation process where the local variable Input Parameter (in Fig. 9) is a Table Code.
  • the routines depicted in detail in Fig. 9 are for the three major reconcihations, Bank, Ledger and POS.
  • the software of the instant invention has been designed to permit an unlimited number of "Other" data sources which can be optionally included in the reconcihation process.
  • software object 500 Upon receipt of communication 475 from software object 470, software object 500 acts to select its output communication hne on case equal the input parameter. If software object 500 determines that the input parameter is "Other" Table_Code then software object 500 will communicate 505 such code to software object 515. If software object 500 determines that the input parameter is "Bank” Table Code then software object 500 will communicate 510 its input data to software object 535. If software object 500 determines that the input parameter is "POS" Table Code then software object 500 will communicate 520 its input data to software object 590. If software object 500 deteimines that the input parameter is "Ledger” Table Code then software object 500 will communicate 530 it input data to software object 650. Software object 500's input data consists of the Table_Code and BatchJSTumber.
  • PartnerJDs There may be a Partner !) for each corporate customer, a PartnerJ-D for each customer, and a PartnerJD for each merchant location.
  • Bank Partner ID is the variable name utilized for each Bank Account
  • Processor Partner lD is the variable name utihzed for each Processor.
  • Software object 515 is displayed on Fig. 9 only to reflect that for each Other data type and source another similar set of software objects must be utihzed as is utilized for Bank, POS, or Ledger data.
  • software object 500 begins to determine whether such data should be communicated 510 to software object 535 and, if so, communicates 510 the data.
  • Software object 535 upon receipt of the communicated 510 data from software object 500, acts to execute an SQL Select to query the ReconciliationJTb and Bank_Accounts_Tb tables in the database 16 for the User_Id, PartnerJ-D, the Reconcihation_Code, Bank_Account JSTumber and the ClosingJDate.
  • Software object 535 then executes a second query on the Reconcihation Decode Tb table to retrieve the Reconcihation Code that represents a reconcihation of ah accounts and assigns it to a local variable called Reconcihation_AU. There will be only one row in the Reconciliation DecodeJTb table with the column All_Accounts_Flag equal to 1 or "True”.
  • software object 535 Upon receipt of the results of such queries, software object 535 communicates the fact of such receipt to software object 540 which then begins the transaction.
  • Software object 540 communicates 545 the completion of its beginning the transaction to software object 550.
  • software object 550 Upon receipt of communication 545 from software object 540, software object 550 acts to reset the working tables for the reconcihation.
  • Software object 550 accepts an optional (OR function input to Child software object 1800 as shown in Fig. 16) parameter which is equivalent to a Table_Code prior to resetting the working tables. Once software object 550 has completed the reset of the working tables, it communicates 555 this fact to software object 560 which then acts to insert the uncleared Bank transactions from the Bank Tb table that fit the current reconcihation definition provided by the local variables set in software object 535 into the Reconcihation JData Tb table. Uncleared Bank transactions are those that have not been cleared in another reconciliation of the same type as the current reconcihation or cleared in a reconcihation that included ah accounts. A reconcihation of the same type is a reconcihation between the same accounts.
  • Software object 560 performs an SQL Insert of the values for BatchJSTumber, Table_Code, MerchantJSTumber, TransactionJDate, Transaction Type Code,
  • the SQL Insert into the Reconcihation JDataJTb table which is executed by software object 560 groups the data ("grouping data” is selecting data rows that have the values required or specified in the columns over which the "grouping" takes place) in the Transaction_Gross_Amt, Transaction JFee_Amt, and Transaction JSTet Arnt columns by the values in the MerchantJSTumber, TransactionJDate, and Bank_Code columns of the BankJTb table.
  • Software object 560 in order to accomplish its SQL Insert of the values for BatchJSTumber, Table_Code, MerchantJSTumber, TransactionJDate, Transaction_Type_Code, Transaction Gross Amt, Transaction_Fee_Amt, and Transaction JSTet_Amt into the Reconcihation JData Tb table, first selects from the Bank_Tb the values of MerchantJSTumber and TransactionJDate, and aliases the names Bank_Code, SUM of Transaction_Gross_Amt, SUM of Transaction_Fee_Amt, and SUM of Transaction JSTet_Amt from the Bank Tb as Transaction Type Code, Transaction_Gross_Amt, Transaction_Fee_Amt, and TransactionJSTet_An ⁇ t, respectively, to be inserted into the Reconcihation Data Tb table.
  • the local variable BatchJSTumber was assigned a value in software object 320.
  • the local variable Table_Code was assigned a value in software object 535. Only summed values of the Transaction_Gross_Amt, TransactionJFee_Amt, and Transaction JSTet_Amt from the Bank Tb table are inserted by software object 560 into the Reconcihation Data Tb table.
  • Software object 560 then continues its execution by performing a first left join of the Bank Tb table to the Reconcihation Cleared Data Tb table on Reconcihation Code in the Reconciliation ClearedJData Tb equal to the local variable Reconcihation Code (Reconcihation Code of the current reconciliation) AND Table Code in the Reconcihation Cleared Data Tb equal to the local variable Table Code (Table Code of the current reconcihation) AND Row_ ⁇ D in the Reconcihation Cleared Data Tb equal to Bank JDD in the Bank_Tb (Bank D is an identity column in the Bank Tb table).
  • the Reconcihation Cleared Data Tb table contains Bank records, if any, that have already been cleared in a prior reconcihation.
  • Software object 560 then continues its execution by performing a second left join of the BankJTb table to the AhJCleared (an alias for Reconcihation Cleared Data Tb) table on Reconcihation Code in the AhJCleared ahased table equal to the local variable Reconciliation_All AND Table_Code in the AhJCleared ahased table equal to the local variable Table_Code AND RowJDD in the All_Cleared aliased table equal to the identity column BankJD in the BankJTb table.
  • the local variable Reconciliation_AU was assigned a value in software object 535.
  • Software object 560 then continues its execution by performing a join of the Merchant JSTumbersJTb table to the BankJTb table on the MerchantJSTumber in the Bank Tb equal to the MerchantJSTumber in the Merchant JSTumbersJTb.
  • the MerchantJSTumber column in the MerchantJSTumbers_Tb includes only Merchant Numbers for Merchant Locations included in the current reconcihation.
  • Software object 560 finally, completes its selection of candidate uncleared Bank transactions by performing a join of the Bank Tb table on the Reconciliation Locations Tb on the MerchantJPartner_ID in the MerchantJNumbersJTb equal to the Merchant_Partner_ ⁇ ) in the Reconcihation J-Ocations Tb AND BatchJSTumber in the Reconcilation Locations Tb equal to the local variable BatchJSTumber.
  • the Reconcihation J ocationsJTb table includes only Merchant Locations included in the current reconcihation.
  • software object 560 completes its execution by performing the SQL Insert of uncleared bank transaction data into the ReconciliationJDataJTb table only where the RowJD of the prospective data row insertion is Null in both the Reconciliation JData Tb table and the AhJCleared aliased table AND the PartnerJD of the bank record in the Bank Tb equals the local variable PartnerJD assigned in software object 535 AND the TransactionJDate of the bank record in the BankJTb is less than or equal to the local variable Closing Date assigned in software object 535 AND the Bank_Account JSTumber of the bank record in the Bank Tb equals the local variable Bank AccountJSTumber selected for this reconcihation as queried in software object 535 from the Reconcihation Tb table.
  • the SQL code to accomphsh the transaction(s) performed by software object 560 is depicted in Fig. 41.
  • software object 560 Upon completion of the execution of the transaction(s), software object 560 communicates the fact of such completion to software object 570.
  • Software object 570 upon receipt of communication of the fact of completion from software object 560, acts to retrieve the SQL Return Code. Once software object 570 has retrieved the SQL Return Code, it communicates that fact to software object 580 which then acts to commit the transaction. After committing the transaction, software object 580 then communicates 485 the completion of its action to software object 430 (see Fig. 8).
  • software object 500 then acts to determine whether such data should be communicated 520 to software object 590 and, if so, communicates 520 the data.
  • Software object 590 upon receipt of the communicated 520 data from software object 500, acts to execute an SQL Select to query the ReconciliationJTb and Bank_AccountsJTb tables in the database 16 for the UserJD, Partner_ID, the Reconcihation Code, Bank_Account_Number and the ClosingJDate.
  • Software object 590 then executes a second query on the Reconciliation DecodeJTb table to retrieve the Reconcihation Code that represents a reconcihation of all accounts and assigns it to a local variable called Reconciliation_AU. There will be only one row in the Reconcihation JDecodeJTb table with the column AhJAccountsJFlag equal to 1 or "True”.
  • software object 590 communicates the fact of the completion of its execution to software object 600 which then begins the transaction.
  • Software object 600 communicates 605 the completion of its beginning the transaction to software object 550.
  • software object 550 Upon receipt of communication 605 from software object 600, software object 550 acts to reset the working tables for the reconciliation.
  • software object 550 Once software object 550 has completed the reset of the working tables, it communicates 615 this fact to software object 620 which then acts to insert the uncleared POS transactions from the Processor Tb table that fit the current reconciliation definition provided by the local variables set in software object 535 into the Reconcihation JData Tb table.
  • Uncleared POS transactions are those that have not been cleared in another reconcihation of the same type as the current reconcihation or cleared in a reconcihation that included all accounts.
  • a reconcihation of the same type is a reconciliation between the same accounts.
  • Software object 620 performs an SQL Insert of the values for BatchJSTumber, Table_Code, MerchantJSTumber, TransactionJDate, Transaction_Type_Code,
  • the SQL Insert into the Reconcihation Data Tb table which is executed by software object 620 groups the data ("grouping data” is selecting data rows that have the values required or specified in the columns over which the "grouping" takes place) in the Transaction_Gross_Amt, Transaction 'ee Amt, and Transaction JSTet_Amt columns by the values in the MerchantJSTumber, TransactionJDate, and Payment Type Code columns of the ProcessorJTb table.
  • Transaction_Type_Code, Transaction_Gross_Amt, Transaction JFee Amt, and Transaction JSTet_Amt into the Reconcihation Data Tb table, first selects from the ProcessorJTb the values of Merchant JSTumber and TransactionJDate, and ahases the names Payment Type Code, SUM of Transaction Gross Amt, SUM of Transaction JFee_Amt- and SUM of Transaction JSTet_Amt from the ProcessorJTb as Transaction_Type_Code, Transaction Gross Amt, Transaction_Fee_Amt, and Transaction JSTet_Amt, respectively, to be inserted into the Reconcihation JDataJTb table.
  • the local variable BatchJSTumber was assigned a value in software object 330.
  • the local variable Table_Code was assigned a value in software object 590. Only summed values of the Transaction Gross Amt, Transaction_Fee_Amt, and Transaction JSTet_Amt from the
  • ProcessorJTb table are inserted by software object 620 into the Reconciliation Data Tb table.
  • Software object 620 then continues its execution by performing a first left join of the ProcessorJTb table to the ReconcUiation_Cleared_Data_Tb table on Reconciliation_Code in the Reconcihation_Cleared JDataJTb equal to the local variable Reconcihation_Code (Reconcihation_Code of the current reconcihation) AND Table Code in the Reconcihation Cleared Data Tb equal to the local variable Table Code (Table Code of the current reconcihation) AND RowJ-D in the Reconciliation_Cleared DataJTb equal to Processor !) in the Processor Tb (Processor D is an identity column in the Processor Tb table).
  • the Reconcihation Cleared Data Tb table contains POS records, if any, that have already been cleared in a prior reconcihation.
  • Software object 620 then continues its execution by performing a second left join of the Processor Tb table to the AhJCleared (an alias for Reconcihation Cleared Data Tb) table on Reconcihation Code in the AhJCleared aliased table equal to the local variable Reconcihation Ah AND Table Code in the AhJCleared ahased table equal to the local variable Table_Code AND RowJDD in the AhJCleared ahased table equal to the identity column Processor !) in the Processor Tb table.
  • the local variable Reconcihation Ah was assigned a value in software object 590.
  • Software object 620 then continues its execution by performing a join of the MerchantJNumbersJTb table to the Processor Tb table on the MerchantJSTumber in the ProcessorJTb equal to the MerchantJSTumber in the Merchant JNTumbersJTb.
  • the MerchantJSTumber column in the MerchantJSTumbersJTb includes only Merchant Numbers for Merchant Locations included in the current reconciliation.
  • Software object 620 then continues its execution by performing a join of the Reconciliation Locations Tb table to the Processor Tb table on the Merchant PartnerJ-D in the MerchantJSTumbers_Tb equal to the Merchant Partner JQD in the Reconcihation Locations Tb AND BatchJSTumber in the Reconcilation Locations Tb equal to the local variable BatchJSTumber.
  • the Reconcihation J ocations Tb table includes only Merchant Locations included in the current reconcihation.
  • Software object 620 finally, completes its selection of candidate uncleared POS transactions by performing a join of the Processor Tb table to the Merchant JSTumberJBank ⁇ count table view on the MerchantJSTumber in the ProcessorJTb equal to the MerchantJSTumber in the MerchantJSTumber_Bank_Account table view.
  • software object 620 completes its execution by performing the SQL Insert of uncleared POS transaction data into the Reconcihation JDataJTb table only where the RowJDD of the prospective data row insertion is Null in both the Reconcihation JData Tb table and the AhJCleared ahased table AND the Partner_ID of the POS record in the Processor Tb equals the local variable PartnerJD assigned in software object 590 AND the TransactionJDate of the POS record in the ProcessorJTb is less than or equal to the local variable ClosingJDate assigned in software object 590 AND the Bank_AccountJSTumber in the Merchant Number Bank Account table view equals the local variable Bank_Account JSTumber selected for this reconciliation as queried in software object 590 from the Reconcihation Tb table.
  • the SQL code to accomphsh the transactions) performed by software object 620 is depicted in Fig. 42.
  • software object 620 Upon completion of the execution of the transactions), software object 620 communicates the fact of such completion to software object 630.
  • Software object 630 upon receipt of communication of the fact of completion from software object 620, acts to retrieve the SQL Return Code. Once software object 630 has retrieved the SQL Return Code, it communicates that fact to software object 640 which then acts to commit the transaction. After committing the transaction, software object 640 then communicates 485 the completion of its action to software object 430 (see Fig. 8).
  • Ledger Table_Code is received by software object 500 as Input Parameter
  • software object 500 then acts . to determine whether such data should be communicated 530 to software object 650 and, if so, communicates 530 the data.
  • Software object 650 upon receipt of the communicated 530 data from software object 500, acts to execute an SQL Select to query the ReconciliationJTb and Bank_Accounts_Tb tables in the database 16 for the User D, PartnerJD, the Reconcihation Code, Bank_Account JSTumber and the ClosingJDate.
  • Software object 650 then executes a second query on the Reconcihation JDecodeJTb table to retrieve the Reconciliation_Code that represents a reconcihation of all accounts and assigns it to a local variable called Reconciliation Ul. There will be only one row in the Reconcihation JDecodeJTb table with the column AhJAccountsJ ? lag equal to 1 or "True”.
  • software object 650 communicates the fact of the completion of its execution to software object 660 which then begins the transaction.
  • Software object 660 communicates 665 the completion of its beginning the transaction to software object 550.
  • software object 550 Upon receipt of communication 665 from software object 650, software object 550 acts to reset the working tables for the reconciliation.
  • software object 550 Once software object 550 has completed the reset of the working tables, it communicates 675 this fact to software object 680 which then acts to insert the uncleared Ledger transactions from the LedgerJTb table that fit the current reconciliation definition provided by the local variables set in software object 535 into the ReconciliationJDatajrb table.
  • Uncleared Ledger transactions are those that have not been cleared in another reconciliation of the same type as the current reconcihation or cleared in a reconcihation that included all accounts.
  • a reconcihation of the same type is a reconciliation between the same accounts.
  • Software object 680 performs an SQL Insert of the values for BatchJSTumber, Table_Code, MerchantJSTumber, TransactionJDate, Transaction_Type_Code,
  • the SQL Insert into the Reconcihation Data Tb table which is executed by software object 680 groups the data ("grouping data” is selecting data rows that have the values required or specified in the columns over which the "grouping" takes place) in the Transaction_Gross_Amt, Transaction Fee Amt, and Transaction Net Amt columns by the values in the MerchantJSTumber, and Ledger JDate columns of the LedgerJTb table.
  • Transaction_Type_Code, Transaction_Gross_Amt, Transaction_Fee_Amt, and Transaction Net Amt into the Reconcihation JData Tb table first selects from the LedgerJTb the values of MerchantJSTumber and Ledger JDate, and ahases the names SUM of Ledger Gross Amt, SUM of LedgerJFee Amt, and SUM of LedgerJSTet_Amt from the LedgerJTb as Transaction_Gross_Amt, Transaction JFee_Amt, and Transaction JSTet_Amt, respectively, to be inserted into the Reconcihation Data Tb table.
  • the local variable BatchJSTumber was assigned a value in software object 330.
  • the local variable Table_Code was assigned a value in software object 650. Only summed values of the Transaction_Gross_Amt, Transaction_Fee_Amt, and Transaction JSTet_Amt from the
  • LedgerJTb table are inserted by software object 680 into the Reconcihation JData Tb table.
  • Software object 680 then continues its execution by performing a first left join of the
  • Recon liation ClearedJData Tb equal to the local variable Reconciliation_Code (Recontiliation Code of the current reconcihation) AND Table_Code in the
  • Ledger TD in the LedgerJTb (Ledger_ TD is an identity column in the LedgerJTb table).
  • Reconciliation Cleared Data _Tb table contains Ledger records, if any, that have already been cleared in a prior reconciliation.
  • Software object 680 then continues its execution by performing a second left join of the LedgerJTb table to the AhJCleared (an alias for Reconcihation Cleared Data Tb) table on Reconciliation_Code in the AU_Cleared ahased table equal to the local variable
  • Reconcihation Ah AND Table_Code in the AU_Cleared aliased table equal to the local variable Table_Code AND Row TD in the AU Cleared ahased table equal to the identity column Ledger TD in the LedgerJTb table.
  • the local variable Reconcihation Ah was assigned a value in software object 650.
  • Software object 680 then continues its execution by performing a join of the
  • MerchantJSTumber column in the MerchantJSTumbersJTb includes only Merchant Numbers for Merchant Locations included in the current reconcihation.
  • Software object 680 then continues its execution by performing a join of the
  • the Reconciliation_Locations_Tb table includes only Merchant Locations included in the current recontiliation.
  • Software object 680 finaUy, completes its selection of candidate uncleared Ledger transactions by performing a join of the LedgerJTb table to the MerchantJSTumberJBank Account table view on the MerchantJSTumber in the LedgerJTb equal to the MerchantJSTumber in the MerchantJSTumber_Bank_Account table view.
  • software object 680 completes its execution by performing the SQL Insert of uncleared Ledger transaction data into the Reconcihation Data Tb table only where the Row TD of the prospective data row insertion is NuU in both the Reconcihation JData Tb table and the AU Cleared ahased table AND the PartnerJD of the Ledger record in the
  • LedgerJTb equals the local variable PartnerJD assigned in software object 650 AND the
  • Ledger JDate of the Ledger record in the LedgerJTb is less than or equal to the local variable
  • the SQL code to accomphsh the transactions) performed by software object 680 is depicted in Fig. 43.
  • software object 680 Upon completion of the execution of the transactions), software object 680 communicates the fact of such completion to software object 690.
  • Software object 690 upon receipt of communication of the fact of completion from software object 680, acts to retrieve the SQL Return Code. Once software object 690 has retrieved the SQL Return Code, it communicates that fact to software object 700 which then acts to commit the transaction. After committing the transaction, software object 700 then communicates 485 the completion of its action to software object 430 (see Fig. 8).
  • Fig. 10 depicts in detaU the operation of software object 140.
  • Software object 800 is the Child of software object 140 (see Fig. 5a) and receives communication 135 from software object 130.
  • the function of the software objects depicted in Fig. 10 is to execute the first pass or "simple match" of the reconcihation process which is the object of the instant invention.
  • software object 800 Upon receipt of communication 135 from software object 130, software object 800 executes an SQL Select on the Reconcihation Tb table, retrieving the UserJD, Bank_Account_Number, Reconcihation Code and the ClosingJDate and setting up the local variables for the current BatchJSTumber.
  • SQL Select Once software object 800 has completed execution of the SQL Select, it communicates that fact to software object 805.
  • Software object 805 upon receipt of such communication from software object 800, acts to create and open a cursor by, first, executing an SQL Select on the Reconcihation_Matching_Tb table, to retrieve the following fields: Reconcihation Code Source Table Code l Source_Table_Code_2 Matching JProcedure Process Drder
  • Software object 805 then completes the act of creating and opening a cursor by selecting all rows from the ReconcilationJVIatching Tb where the Reconciliation_Code in the Reconcihation Matching Tb table is equal to the local variable Reconcihation Code assigned by software object 800, and sorts the cursor by Process Order.
  • Software object 805 communicates the completion of its formation of the cursor to software object 810.
  • software object 810 acts to determine whether an EOF condition exists, thereby checking to see if there is any data in the cursor. If software object 810 determines that the end of file has been reached, it communicates 820 such fact to software object 860.
  • Software object 860 acts to close the cursor and communicates 145 the fact of such closing to software object 150 (see Fig. 5a). If software object 810 determines that the cursor contains data, it communicates 830 that fact to software object 840. Software object 840, upon receipt of commumcation 830 from software object 810, acts to retrieve the next row, or record, from the cursor. Software object 840 communicates 845 the retrieved record to software object 850. Software object 850, upon receipt of communication 845 from software object 840, executes a "simple match".
  • a "simple match” consists of matching rows in the Reconcihation Data Tb table where the Table_Code in the Reconcihation DataJTb table is identified by one of two input parameters, Source_Table_Code_l and Source_Table_Code_2, and by searching, according to criteria set by the Matching Procedure, for identical entries in the Reconcihation Data Tb table.
  • the criteria set by the Matching Procedure is that the following columns must equal each other: Batch Number, Transaction_Type_Code, TransactionJDate, MerchantJSTumber, Transaction_Gross_Amt, Transaction_FeeJ ⁇ tnt, and Transaction JSTet_Amt
  • software object 850 communicates 855 the fact of completion to software object 810 which repeats its previously described determination of whether EOF has been reached in the cursor.
  • Software object 850 performs a "simple match" between the rows of data contained within the accounts being reconciled utilizing the software objects depicted in Fig. 11.
  • Software object 870 is a Child of software object 850 (see Fig. 10) and receives the communication 845 that a record has been retrieved from the cursor which is sent by software object 840. Upon receipt of the communication 845 from software object 840, software object 870 acts to begin the transaction.
  • the SQL Insert performed by software object 875 inserts data rows into the Recontilation JDataJVIatchesJTb table for the current BatchJSTumber, the Data TD column from the aliased table Sourcel, and the DataJDD column from the ahased table Source2, into the foUowing columns BatchJSTumber, Data TD l, and Data_TD_2, respectively.
  • Software object 875 then continues its execution by joining the table ReconcUiation JDataJTb, aliased as Sourcel, to another instance of the table Reconcihation JDataJTb, ahased as Source2, where the ahased table Sourcel has columns BatchJSTumber, MerchantJSTumber, Transaction Date, Transaction_Gross_Amt, TransactionJFee Amt and TransactionJSTet_Amt that are equal to the same columns in the aliased table Source2.
  • Software object 875 then continues its execution by performing a left join to the
  • Data JD column in the ahased table Source2 is equal to the Data_TD_2 column in the table
  • Software object 875 completes its execution by performing the SQL Insert of matched data rows into the Reconciliation DataJVIatchesJTb table where the Table Code and BatchJSTumber columns in the ahased table Sourcel are equal to the input parameter Source_Table_Code_l and local variable BatchJSTumber, respectively. Also, the Table_Code and BatchJSTumber columns in the ahased table Source2 must equal the input Parameter Source_Table_Code_2 and the local variable BatchJSTumber, respectively. Assuring duplicate rows are not inserted, only rows where the columns Data TD l and Data TD 2, from the left joined table Reconcihation JDataJVIatchesJTb, are NULL are selected for insertion.
  • software object 875 communicates the fact of completion to software object 880 which then acts to retrieve the SQL Return Code.
  • software object 880 communicates the fact of completion to software object 885 which then executes an SQL Insert.
  • the source code of the SQL Insert executed by software object 885 is depicted in Fig. 40.
  • the SQL Insert performed by software object 885 is similar to the SQL Insert performed by software object 875 in that only the input parameters SourceJTable Code l and Source_Table_Code_2 are reversed.
  • ReconcUiation DataJVIatchesJTb consists of 3 columns of data; Data TD l, Data_TD_2 and BatchJSTumber.
  • Data TD l and Data TD 2 are just the Data_TDs that match up from a simple match of the records in the Reconciliation JDataJTb. For example, if you have a Bank reconcihation record and a Processor reconcihation record that match up on the first SQL Insert which is performed by software object 875, the Bank_TD went in the Data TD l field and the ProcessorJD for the reconciliation went in the Data_ID_2 field. Then in the second match which is performed by software object 885 the order of processing would be reversed.
  • software object 885 Once software object 885 has completed its SQL Insert, it communicates the fact of completion to software object 890.
  • Software object 890 retrieves the SQL Return Code and communicates the fact of receipt of the SQL Return Code to software object 895.
  • Software object 895 commits the transaction upon receipt of the communication from software object 890. Once software object 895 has committed the transaction, it communicates 855 this fact to software object 810 (see Fig. 10).
  • Fig. 12 depicts in detaU the operation of software object 150.
  • Software object 900 is the ChUd of software object 150 (see Fig. 5a) and receives communication 145 from software object 140.
  • the function of the software objects depicted in Fig. 12 is to execute the start of the "complex match" procedure of the instant invention.
  • the software object depicted in Fig. 12 takes aU of the rows in the Reconcihation Data Tb that did not match in the previous steps performed by software object 885 (Fig. 11) and combines rows and tries to match them.
  • the program of the instant invention would create all possible combinations of those three rows from the ProcessorJTb and attempt to match each of those combinations to the one row remaining from the Bank Tb. Then, if a unique match (there has to be a unique match, if more than one of the combinations match then no match is considered to have occurred) were discovered during the process of comparing each possible combination of rows fromthe Processor Tb to the rows from the BankJTb, the matching rows would be inserted by the program into the Reconcihation Data Matches Tb.
  • software object 900 Upon receipt of communication 145 from software object 140, software object 900 acts to create a cursor by querying the Reconcihation_Matching_Tb table, selecting Source Table Code l and Source_Table_Code_2 using the current Reconcihation Code of the reconcihation being performed. After software object 900 has created the cursor, it communicates this fact to software object 910 which then acts to determine whether the cursor has reached EOF, ie. whether the cursor has any records remaining in it to be read.
  • software 910 object determines that the cursor has reached EOF, it commumcates 920 this fact to software object 935.
  • software object 935 receives communication 920 from software object 910, software object 935 acts to close the cursor and communicates 165 the fact that the cursor is closed to software object 170 (see Fig. 5b).
  • the software object 910 determines that the cursor has not reached EOF, it communicates 930 this fact to software object 940 which acts to get the next row from the cursor set, which next row consists of the SourceJTable Code l and the Source_Table_Code_2.
  • software object 940 After software object 940 has retrieved the next record in the cursor, it communicates 945 this record to software object 950 which then acts to execute the "complex match" procedure which attempts to match all combinations of rows in the table identified by Source Table Code l against each row of the table identified by Source_Table_Codej2. For example, if Source_Table_Code_l is Bank data and Source_Table_Code_2 is Processor data, software object 950 wUl attempt to match every combination of the unmatched rows of Processor data against each unmatched row of the Bank data.
  • software object 950 wiU repeat its action (accomphsh a second execution) but with reversed input parameters so that software object 950 attempts to match ah combination of rows in the table identified by Source_Table_Code_2 against each row of the table identified by Source_Table_Code_l.
  • software object 950 completes its "complex match” procedure, it communicates 955 this fact to software object 910 which then acts as previously described.
  • Fig. 13a and Fig. 13b form a single flow chart depicting in detail the operation of software object 950.
  • Software object 1000 is the CWld of software object 950 (see Fig. 12) and receives communication 945 from software object 940.
  • the function of the software objects depicted in Figs. 13a and 13b is to perform a complex row matching of data within accounts being reconciled.
  • software object 1000 Upon receipt of communication 945 from software object 940, software object 1000 acts to create a data cursor "13 A" by doing an SQL Select on Database 16 to select all fields in all rows equal to Source_Table_Code_2 from the Reconcihation Data Tb table where there is no match in the ReconcUiation DataJVIatchesJTb table for SourceJTable Code l.
  • Software object 1000 accepts two Table Codes, Source_Table_Code_l and Source_Table_Code_2, and a BatchJSTumber as input parameters.
  • the two Table_Codes are of those tables that Software Object 950 is doing the complex match on and the BatchJSTumber is the current one. Recall that Batch JSTumbers are assigned automatically for processing purposes.
  • ' Software object 1000 then continues its SQL execution by left joining to the table view RightJVIatchesJjv where the DataJD from the ReconciliationJTb table is equal to the Data_TD_l from the RightJVIatchesJiv table view and the Table_Code form the Right JVIatches_bv table view is equal to the input parameter Table_Source_Code_2.
  • Software object 1000 finally, completes its selection by only selecting the rows where the BatchJSTumber and the Table_Code in the Reconcihation JDataJTb table is equal to the input parameter Source Table Code l and the local variable BatchJSTumber, respectively, and the Table_Cpde in the Right JVIatches_bv table view must be NULL.
  • Fig. 44 depicts in detaU the SQL Query that is being performed by software object 1000.
  • Software object 1000 communicates the completed cursor 13A to software object 1010.
  • Software object 1010 then takes cursor 13A and creates a new data coUection "13C" by taking all unique combinations of rows from cursor 13 A.
  • a new data object is created and inserted into data collection 13C.
  • the original data rows from cursor 13 A used to create each unique combination are stored in the newly created data object 13C. This is done so that other software objects can later reference the rows used to create each data object in data collection 13C.
  • Data objects in data collection 13C contain the transaction type and the sum of the net, gross, and fee amounts of each row used to create that data object.
  • cursor 13 A contains rows A, B, and C.
  • the row combinations now in the data collection 13C as new data objects are A, B, C, AB, AC, BC, and ABC.
  • Software object 1010 communicates the completion of its operation to software object 1020.
  • Software object 1020 then acts to create data cursor "13B" by doing an SQL Select on the database 16 to select all fields and all rows from the ReconcUiation Data Tb where the Table Code column in the Reconcihation Data Tb table is equal to the input paramater Source_Table_Code_l, and there is no match in the Reconciliation DataJVIatches Tb table for Source Table Code __2.
  • Software object 1020 accepts two Source Table Codes and one BatchJSTumber as parameters.
  • Source_Table_Codes are those that software object 950 is doing the complex match on and the BatchJSTumber is the current one.
  • Software object 1020 performs the same SQL select as was performed by software object 1000 with the exception that software object 1020 reverses the two input paramaters, Source_Table_Code_l and Source_Table_Code_2.
  • Software object 1020 communicates the completion of its operation to software object 1030.
  • Software object 1030 queries the UserJPreferenceJTb table to select the acceptable date range for comparing Dates to each other. There is no need, and it would consume excessive processing power to attempt to match dates that are too far apart, i.e. more than 2 weeks apart.
  • "real time" processing of transactions whether they be credit card or cash, is assumed. For other applications, the timing between matching transactions may be greater, as for example where credit card charge shps (hand swiped) are accumulated for a month or more and then submitted for processing.
  • Software object 1030 acts to remove from consideration in the complex matching process data objects in Cursor 13 A and 13B that are outside the acceptable date range.
  • Software object 1030 acts to communicate the completion of its operation to software object 1040.
  • Software object 1040 then acts to check cursor 13B for End Of FUe. If End Of File has been reached, software object 1040 communicates 955 this fact to software object 910 (see Fig. 12). If End Of FUe has not been reached, software object 1040 communicates 1050 this fact to software object 1060.
  • Software object 1060 then acts to move to read the next row in cursor 13B. Each row of data in cursor 13B contains the BatchJNumber, MerchantJSTumber, TransactionJDate, Transaction_Type_Code, gross, net and fee amounts and software object 950 attempts to match that row of data against the data objects in data collection 13C.
  • software object 1060 retrieves the data from the next row in the cursor 13B, it communicates that fact to software object 1070.
  • the Match Counter is a counter used to accumulate the number of times that software object 950 finds a unique match.
  • the Match Index is used to point to the data object's index in the data coUection 13C when a match is found.
  • the Loop Counter is used to loop through the data coUection 13C.
  • Software object 1090 checks the Loop Counter to make sure it is less than or equal to the number of data objects in data collection 13C. If the Loop Counter is less than or equal to the number of data objects in data coUection 13C then software object 1090 commumcates 1100 this fact to software object 1200 (see Fig. 13b). If the Loop Counter is not less than or equal to the number of data objects in data coUection 13C then software object 1090 communicates 1110 this fact to software object 1120. Software object 1120 then acts to check for the condition match counter equal to one. This is done because if more than one match is encountered, the match is not unique and must be rejected.
  • the instant invention only commits to a match if there is one unique match between the current data row in cursor 13B and a data row in data collection 13C. If the Match Counter equals one, then software object 1120 will communicate 1130 that fact to software object 1150. If the match counter is not one, software object 1120 will communicate 1140 that fact to software object 1040. Upon receipt of communication 1130 from software object 1120, software object 1150 acts to execute two sets of SQL Inserts into the ReconcUiationJDataJ IatchesJTb table using the Data TD from the current row in cursor 13B and the Data D(s) from the data row(s) contained in the data object found at the Match Index in data collection 13C.
  • the second SQL Insert being performed by software object 1150 wUl insert into the Reconcihation Data Matches Tb table the current BatchJSTumber, the DataJD from cursor 13B and the DataJD(s) from the data row(s) in the data object found at the Match Index in data coUection 13C into columns BatchJSTumber, Data TD_2 and Data TD l, respectively.
  • Software object 1150 commumcates the completion of its two SQL Inserts to software object 1160.
  • Software object 1160 then acts to remove the data object found at Match Index from the data collection 13C so that no attempt is made to perform a match on the data object in subsequent loops.
  • Software object 1160 communicates the completion of its action to software object 1040.
  • Software object 1040 then, again, acts to determine whether End Of FUe has been reached in cursor 13B, and, if not, another cycle (including incrementing the Loop Counter) is begun.
  • software object 1090 checks the Loop Counter to make sure it is less than or equal to the number of data objects in data collection 13C and determined that the Loop Counter is less than or equal to the number of data objects in data collection 13 C then software object 1090 communicates 1100 this fact to software object 1200 (see Fig. 13b).
  • Software object 1200 then acts to create data object 13D from data coUection 13C by selecting the data object where the Loop Counter value is equal to the index number in the data coUection 13C. Once software object 1200 has created data object 13D, it communicates this fact to software object 1220.
  • Software object 1220 uses the date range set in software object 1030 (Fig.
  • Software object 1240 upon receipt of communication from software object 1220, acts to compare the BatchJSTumber, MerchantJSTumber, Net, Gross, and Fee amounts contained in the data object 13D to the corresponding fields of the current row in cursor 13B. If ah of the values in the compared fields in data object 13D and cursor 13B are equal then software object 1240 communicates Line 1250 this fact to software object 1260. If any one of the values in the fields compared is not equal then software object 1240 w l communicate 1180 this fact to software object 1080 (Fig. 13a). Upon receipt of communication 1250 from software object 1240, software object 1260 acts to increment the Match Counter by one. The increment is one because if more than one match were found, no rows of data are considered a match.
  • software object 260 Upon receipt of communication 200 from software object 195, software object 260 acts to clean up the working tables used throughout the reconciliation and archive aU reconcihation data tables and label aU of the transactions (records) that have been matched as cleared, aU in preparation for the next reconcihation to be performed.
  • the detailed operation of software object 260 begins with the receipt of communication 200 by software object 1300, a Child of software object 260.
  • Software object 1300 executes an SQL Select of the User TD, Bank Account, and Reconcihation Code from the ReconciliationsJTb table using the current BatchJSTumber. Once software object 1300 has completed its execution, it commumcates this fact to software object 1305.
  • Software object 1305 then acts to begin the transaction.
  • software object 1305 When software object 1305 has completed its execution, it communicates this fact to software object 1310.
  • Software object 1310 then acts to execute an SQL Insert to copy data (transaction totals) from the ReconciliationJDataJTb table into the Reconciliation JReport JDataJTb table for future use in creating reports.
  • the SQL Insert functions to create exact copies of the data from the ReconciliationJDataJTb table into the Reconciliation ⁇ Report JDataJTb table.
  • software object 1315 After software object 1310 has completed its execution, it communicates this fact to software object 1315.
  • Software object 1315 then acts to retrieve the SQL Return Code. Once software object 1315 has retrieved the SQL Return Code, it communicates the completion of its execution to software object 1320.
  • Software object 1320 then acts to execute an SQL Insert which copies data from the Reconciliation JDataJVIatchesJTb table into the Reconcihation_ReportJVIatches_Tb table for future use in creating reports.
  • the SQL Insert functions to create exact copies of the rows from the Reconcihation JDataJVIatchesJTb table into the
  • ReconcUiation_Report_Matches_Tb table After software object 1320 has completed its execution, it communicates this fact to software object 1325. Software object 1325 then acts to retrieve the SQL Return Code. Once software object 1325 has retrieved the SQL Return Code, it commumcates the completion of its execution to software object 1330. Software object 1330 then acts to commit the transaction. In this fashion, the transaction is not committed until we are assured that aU data has been backed up and that no errors have occurred. After software object 1330 commits the transaction, it communicates this fact to software object 1335.
  • software object 1335 Upon receipt of communication from software object 1330, software object 1335 acts to buUd a cursor by executing an SQL Select on the ReconcUiation_Associations_Tb table where the Reconciliation_Code in the ReconcUiation_Associations_Tb table is equal to the local variable Reconcihation_Code , returning the Table_Codes of aU of the data tables that were included in the reconcihation; these Table_Codes are used to loop through each table used in the current reconcihation.
  • Software object 1340 then acts to check for End Of File (EOF). If software object 1340 detects End Of FUe (EOF), it communicates 1350 this fact to software object 1400. If software object 1340 does not detect End Of FUe (EOF), it communicates 1360 this fact to software object 1370.
  • EEF End Of File
  • software object 1370 Upon receipt of communication 1360 from software object 1340, software object 1370 (Fig. 14b) acts to retrieve the next Table Code from the cursor created by software object 1335 (Fig!4a). After software object 1370 has retrieved the next Table_Code from the cursor, it communicates this fact to software object 1380. Software object 1380 then acts to execute an SQL Select on the ReconcUiation JData_Tables_Tb table returning the Ending Procedure name for the Table Code in the current row of the cursor. After software object 1380 has retrieved the ending procedure name from the Reconcihation Data Tables Tb table, it communicates 1385 this data to software object 1390.
  • Software object 1390 upon receipt of communication 1385 from software object 1380, acts to execute the EndingJProcedure retrieved by software object 1380 (see details at Fig. 15). Once software object 1390 has completed its execution, it communicates 1395 that fact to software object 1340 (Fig. 14a). Upon receipt of communication 1350 from software object 1340 (Fig. 14a), software object 1400 acts to close the cursor created by software object 1335 (Fig. 14a). Once software object 1400 has closed the cursor created by software object 1335, it communicates this fact to software object 1405. Software object 1405 then acts to begin the transaction. When software object 1405 has completed its execution, it communicates 1410 this fact to software object 550 (detaUs of the operation of software object 550 are depicted in Fig. 16).
  • Software object 550 after receipt of communication 1410 from 1405, then acts to delete rows from the ReconcUiation JData Tb table and the Reconcihation JDataJVIatchesJTb table for
  • Fig. 15 depicts in detaU the operation of software object 1390.
  • Software object 1500 is the Child of software object 1390 (see Fig. 14b) and receives communication 1385 from software object 1380.
  • the function of the software objects depicted in Fig. 15 is to execute the EndingJProcedure for the reconciliation process where the local variable Input Parameter 1 (in Fig. 15) is a Table_Code.
  • the routines depicted in detail in Fig. 15 are for the three major reconcihations, Bank, Ledger and POS.
  • the software of the instant invention has been designed to permit an unlimited number of "Other" data sources which can be optionally included in the reconcihation process.
  • software object 1390 Upon receipt of communication 1385 from software object 1380, software object 1390 acts to select its output communication hne on case equal the input parameter.
  • Tf software object 1500 determines that the input parameter is "Other” Table Code then software object 1500 wiU communicate 1505 its input data to software object 1515. If software object 1500 determines that the input parameter is "Bank” Table Code then software object 1500 wiU communicate 1510 its input data to software object 1540.
  • Tf software object 1500 determines that the input parameter is 'TOS" Table_Code then software object 1500 wUl communicate 1520 its input data to software object 1610. If software object 1500 determines that the input parameter is "Ledger” Table Code then software object 1500 wUl communicate 1530 its input data to software object 1680.
  • Software object 1500's input data consists of the current BatchJSTumber and Table Code.
  • Software object 1515 is displayed on Fig. 15 only to reflect that for each Other data type and source, another simUar set of software objects must be utihzed as is utilized for Bank, POS, or Ledger data.
  • software object 1500 then acts to determine that such data should be communicated 1510 to software object 1540 and so commumcates 1510 the data.
  • Software object 1540 upon receipt of the communicated 1510 data from software object 1500, acts to execute an SQL Select Set of the local variables UserJD, Bank_AccountJSTumber, Reconciliation_Code from the Reconcihation_Tb table by using the current BatchJSTumber. Upon completion of its execution, software object 1540 communicates that fact to software object 1550. Software object 1550 upon receipt of communication from software object 1540 acts to perform an SQL Select on the Reconcihation Data _Tb table summing the transaction net amount for the current BatchJSTumber and Table Code. Software object 1550 stores the sum in the local variable ReconcUiation Amount. Upon completion of its execution software object 1550 communicates that fact to software object 1560. Software object 1560 then acts to begin the transaction.
  • software object 1560 Once software object 1560 has completed its execution, it communicates that fact to software object 1570.
  • Software object 1570 then acts to perform an SQL Update on the Reconcihation Tb table where the BatchJSTumber in the ReconciliationJTb table is equal to the current BatchJSTumber, setting the BankJBatch Ending Amt equal to the ReconcUiation Amount calculated in software object 1550.
  • software object 1570 Upon completion of its execution, software object 1570 then communicates that fact to software object 1575.
  • Software object 1575 then acts to retrieve the SQL Return Code. Once software object 1575 has retrieved the SQL Return Code, it communicates that fact to software object 1580.
  • Software object 1580 then acts to execute an SQL Insert into the Reconciliation_Cleared JDataJTb table.
  • the source code for the SQL Insert executed by software object 1580 is depicted in Fig. 46.
  • the SQL Insert by software object 1580 is done so that the same data rows don't get puUed (selected) in the future.
  • the Reconciliation ClearedJData Tb table consists of the following columns: Reconciliation - ⁇ ode, Table_Code, and RowJDD.
  • the RowJ is the equivalent of the primary key from a source table indicated by the Table Code.
  • the same data rows can again be included in a reconcihation defined by a different ReconcUiation_Code. Once a transaction has been cleared it can be included in new reconciliation of a different type as long as the transaction has not been included in a reconcihation of all accounts.
  • software object 1500 then acts to determine that such data should be communicated 1520 to software object 1610 and so communicates 1520 the data.
  • Software object 1610 upon receipt of the communicated 1520 data from software object 1500, acts to execute an SQL Select Set of the local variables UserJD, Bank_Account JSTumber, and Reconcihation Code from the Reconciliation Tb table by using the BatchJNumber. Upon completion of its execution, software object 1610 communicates that fact to software object 1620.
  • Software object 1620 upon receipt of commumcation from software object 1610 acts to perform an SQL Select on the ReconcUiation JDataJTb table summing up the transaction net amount for the current BatchJSTumber and Table_Code. Software object 1620 stores the sum in the local variable ReconcUiation_Amount. Upon completion of its execution software object 1620 commumcates that fact to software object 1630. Software object 1630 then acts to begin the transaction. Once software object 1630 has completed its execution, it communicates that fact to software object 1640.
  • Software object 1640 then acts to perform an SQL Update on the Reconcihation Tb table where the BatchJSTumber in the ReconciliationJTb table is equal to the local variable BatchJSTumber, setting the POS_Batch_Ending_Amt equal to the Reconciliation Amount calculated in software object 1620.
  • software object 1640 Upon completion of its execution, software object 1640 then communicates that fact to software object 1645.
  • Software object 1645 then acts to retrieve the SQL Return Code. Once software object 1645 has retrieved the SQL Return Code, it communicates that fact to software object 1650.
  • Software object 1650 then acts to execute an SQL Insert.
  • the source code for the SQL Insert executed by software object 1650 is depicted in Fig. 47.
  • the SQL Insert by software object 1650 is done so that the same rows don't get selected in the future.
  • the ReconcUiationJTb table consists of the foUowing columns:Reconciliation_Code, Table_Code, and Row D.
  • the same data rows can again be included in a new reconciliation defined by a different Reconciliation_Code, provided however that once a data row is cleared in a reconcUiation of aU accounts it cannot thereafter be used as an uncleared data row in any reconcUiation.
  • software object 1500 then acts to determine that such data should be communicated 1530 to software object 1680 and so communicates 1530 the data.
  • Software object 1680 upon receipt of the communicated 1530 data from software object 1500, acts to execute an SQL Select Set of the local variables UserJQD, Bank_AccountJSfumber, Reconcihation Code from the Reconcihation_Tb table by using the BatchJNumber. Upon completion of its execution, software object 1680 communicates that fact to software object 1690.
  • Software object 1690 upon receipt of communication from software object 1680 acts to perform an SQL Select on the Reconciliation Data Tb table summing up the transaction net amount for the current BatchJSTumber and Table_Code. Software object 1690 stores the sum in the local variable Reconcihation_Amount. Upon completion of its execution software object 1690 communicates that fact to software object 1700. Software object 1700 then acts to begin the transaction. Once software object 1700 has completed its execution, it communicates that fact to software object 1710.
  • Software object 1710 then acts to perform an SQL Update on the Reconcihation Tb table where the BatchJNumber in the ReconcUiation Tb table is equal to the local variable BatchJSTumber, setting the Ledger Batch Ending Amt equal to the ReconcUiation Amount calculated in software object 1690.
  • software object 1710 Upon completion of its execution, software object 1710 then communicates that fact to software object 1715.
  • Software object 1715 then acts to retrieve the SQL Return Code. Once software object 1715 has retrieved the SQL Return Code, it communicates that fact to software object 1720.
  • Software object 1720 then acts to execute an SQL Insert.
  • the source code for the SQL Insert executed by software object 1720 is depicted in Fig. 48.
  • the SQL Insert by software object 1720 is done so that the same rows don't get selected in the future.
  • the Reconcihation Tb table consists of the foUowing columns:ReconcUiation_Code, Table Code, and RowJDD.
  • the same data rows can again be included in a new reconcUiation defined by a different Reconcihation_Code, provided however that once a data row is cleared in a reconcUiation of aU accounts it cannot thereafter be used as an uncleared data row in any reconcUiation.
  • Fig. 16 depicts in detaU the operation of software object 550.
  • Software object 1800 is the ChUd of software object 550 (see Fig. 9) and receives communication 545 from software object 540 OR communication 605 from software object 600 OR communication 665 from software object 660 OR communication 1410 from software object 1405 (Fig. 14b).
  • the function of software object 550 is to reset the ReconcUiation Data Tb table and the ReconcUiation JDataJVIatchesJTb table by deleting data that is in both tables.
  • Software object 550 accepts as an input parameter the current BatchJSTumber and an optional input parameter of Table_Code.
  • software object 550 does not receive the optional Table Code input, it wiU act to delete aU rows from both tables equal to the current BatchJSTumber; alternatively, if software object 550 does receive a Table Code it wUl act to delete only the data equal to that Table_Code for the current BatchJSTumber.
  • software object 1800 wiU communicate such received data to software object 1805.
  • Software Object 1805 wiU then act to begin the transaction. Once software object 1805 has completed its execution, it wUl communicate that fact to software object 1810.
  • Software object 1810 will then act to check the parameter passed initially into software object 1800, if the Table_Code parameter passed into software object 1800 was not null software object 1810 will communicate 1830 that fact to software object 1860. If the Table Code parameter passed into software object 1800 was null software object 1810 wUl communicate 1820 that fact to software object 1840.
  • software object 1860 Upon receipt of communication 1830 from software object 1810, software object 1860 acts to execute an SQL Delete from the ReconcUiation JDataJVIatchesJTb table joining to the ReconcUiation JDataJTb table on the DataJD column in the ReconcUiaton JData _Tb equal to the Data TD l column in the Reconciliation ⁇ DataJVIatchesJTb where the BatchJSTumber in the Reconcihation Data Tb is equal to the local variable BatchJSTumber and the Table_Code column in the ReconciliationJDataJTb is equal to the local variable Table_Code.
  • Software object 1864 upon receipt of communication from software object 1862, then acts to to execute an SQL Delete from the Reconciliation_Data JVIatchesJTb table joining to the ReconciliationJDataJTb table on the Data JDD column in the ReconcUiaton Data Tb equal to the Data D_2 column in the Reconcihation JData JVIatchesJTb where the BatchJSTumber in the ReconciliationJDataJTb is equal to the local variable BatchJSTumber and the Table_Code column in the ReconcUiation JData Tb is equal to the local variable Table_Code.
  • Software object 1870 then acts to execute an SQL Delete on the Reconciliation JDataJTb table where the BatchJSTumber column in the Reconcihation Data Tb is equal to the local variable BatchJSTumber and the Table Code column in the ReconcilationJData Tb is equal to the lcoal variable Table_Code. Upon completion of its execution, software object 1870 then communicates that fact to software object 1875. Software object 1875, upon receipt of communication from software object 1870, acts to retrieve the SQL Return Code. Software object 1875 then communicates the fact that it has retrieved the SQL Return Code to software object 1880.
  • Software object 1840 upon receipt of communication 1820 from software object 1810, acts to execute an SQL Delete on aU rows in the Reconcihation _Data JVIatchesJTb table where the BatchJSTumber column is equal to the local variable BatchJSTumber.
  • Software object 1845 upon receipt of communication from software object 1840, acts to retrieve the SQL Return Code.
  • Software object 1845 then communicates the fact that it has retrieved the SQL Return Code to software object 1850.
  • Software object 1850 upon receipt of communication from software object 1845, acts to execute and SQL Delete on all rows in the ReconcUiation JData Tb table where the BatchJSTumber column in the ReconciliationJDataJTb is equal to the local variable BatchJSTumber.
  • Software object 1855 upon receipt of communication from software object 1850, acts to retrieve the SQL Return Code.
  • Software object 1855 then communicates the fact that it has retrieved the SQL Return Code to software object 1880.
  • Software object 1880 upon receipt of communication from software object 1855 OR software object 1875 acts to commit the transaction. Once software object 1880 has completed its execution, it communicates that fact to software object 1890.
  • Software object 1890 upon receipt of commumcation from software object 1880, acts to select a communication path out on case communication path into software object 1800, as follows: communication path in communication path out 545 555
  • Fig. 17 depicts the operation of the Bank data User input screen; where the user can select to input Bank data via an on-screen menu item or button.
  • Communication 2000 is the User Input selecting the Bank data input screen and commencing execution of software object 2010.
  • software object 2010 When activated by a User Input, software object 2010 creates a User input screen for the input of Bank data.
  • the User input screen created by software object 2010 also provides for a User selection of either a "save” command or a "cancel” command.
  • the User Input, including both Bank data and a "save” or "cancel” command, is communicated 2015 to software object 2020.
  • Software object 2020 acts to accept the User Input.
  • software object 2020 Upon software object 2020 receiving User Input which is either a :"save” or “cancel” command, it communicates this fact together with the User Input to software object 2030.
  • software object 2030 Upon software object 2030 receiving communication from software object 2020, software object 2030 communicates 2040 the Bank data to software object 80 if the User Input included the command "save”. If, alternatively, the User Input included the command "cancel", then software object 2030 communicates 2050 the Bank data to software object 2080.
  • Software object 80 acts to inserts the Bank data into the BankJTb table of the database 16. Details of the operation of software object 80 are depicted in Fig. 21.
  • software object Upon completion of the insertion of the Bank data into the BankJTb table, software object communicates 2070 the fact of completion to software object 2080.
  • software object 2080 acts to close the User input screen.
  • Fig. 18 depicts the operation of the POS data User input screen; where the user can select to input POS data via an on-screen menu item or button.
  • Communication 2100 is the User Input selecting the POS data input screen and commencing execution of software object 2110.
  • software object 2110 When activated by a User Input, software object 2110 creates a User input screen for the input of POS data.
  • the User input screen created by software object 2110 also provides for a User selection of either a "save” command or a "cancel” command.
  • the User Input including both POS data and a "save” or “cancel” command, is communicated 2115 to software object 2120.
  • Software object 2120 acts to accept the User Input. Upon software object 2120 receiving User Input which is either a :"save” or “cancel” command, it communicates this fact together with the User Input to software object 2130. Upon software object 2130 receiving commumcation from software object 2120, software object 2130 communicates 2140 the POS data to software object 82 if the User Input included the command "save". If, alternatively, the User Input included the command "cancel", then software object 2130 commumcates 2150 the POS data to software object 2180. Software object 82 acts to insert the POS data into the ProcessorJTb table of the database 16. DetaUs of the operation of software object 82 are depicted in Fig.
  • software object 82 Upon completion of the insertion of the POS data into the ProcessorJTb table, software object 82 communicates 2170 the fact of completion to software object 2180. Upon receipt of either communication 2150 from software object 2130 OR communication 2170 from software object 82, software object 2080 acts to close the User input screen.
  • Fig. 19 depicts the operation of the Ledger data User input screen; where the user can select to input Ledger data via an on-screen menu item or button.
  • Communication 2200 is the User Input selecting the Ledger data input screen and commencing execution of software object 2210.
  • software object 2210 When activated by a User Input, software object 2210 creates a User input screen for the input of Ledger data.
  • the User input screen created by software object 2210 also provides for a User selection of either a "save” command or a "cancel” command.
  • the User Input including both Ledger data and a "save” or “cancel” command, is communicated 2215 to software object 2220.
  • Software object 2220 acts to accept the User Input. Upon software object 2220 receiving User Input which is either a :"save” or “cancel” command, it communicates this fact together with the User Input to software object 2230. Upon software object 2230 receiving communication from software object 2220, software object 2230 communicates 2240 the Ledger data to software object 84 if the User Input included the command "save”. If, alternatively, the User Input included the command "cancel", then software object 2230 communicates 2250 the Ledger data to software object 2280. Software object 84 acts to insert the Ledger data into the LedgerJTb table of the database 16. DetaUs of the operation of software object 84 are depicted in Fig. 23.
  • software object 84 Upon completion of the insertion of the Ledger data into the LedgerJTb table, software object 84 communicates 2270 the fact of completion to software object 2280. Upon receipt of either communication 2250 from software object 2230 OR communication 2270 from software object 84, software object 2280 acts to close the User input screen.
  • Figs. 20a, 20b, and 20c are three pages of a single flow chart depicting in detail the operation of a merchant set-up wizard for the input of data by User for new Merchant Numbers.
  • the User can, through use of this set-up wizard set up numerous items; the User can set up new Partners, new Agreements, new Terminals, new Bank Accounts, new Ledger Accounts, new Merchant Accounts, and new Users.
  • AdditionaUy through this set-up wizard, the User can input additional Merchant Numbers for the same terminal, more Terminals for the same Partner, and add additional Merchant Partners.
  • Partner IDs There are several different "Partner IDs”. There may be a master Partner_ID for each corporate customer, merchant location, customer bank, and electronic payment processor.
  • MachineJPartnerJD is the variable name utihzed for each merchant location
  • Bank Partner lD is the variable name utihzed for each Bank partner
  • Processor Partner TD is the variable name utilized for each Processor partner.
  • operation of the set-up wizard is commenced by communication 3000 as User Input selecting operation of the set-up wizard.
  • Communication 3000 is received by software object 3010 which acts to display an input screen inquiring of the User whether the new input data is for a new Merchant Partner.
  • Software object 3010 may, alternatively, begin execution upon receipt of communication 3300 from software object 3290 which communicates 3300 that additional new Merchant Partners need to be set-up.
  • the User responds to the input screen inquiry created by software object 3010 by communication 3005 to software object 3010, selecting either "Yes” or "No". If the User communicated 3005 a "Yes" to software object 3010, then software object 3010 communicates 3020 the completion of its execution to software object 3040.
  • the software object 3010 communicates 3030 the completion of its execution to software object 3050.
  • Software object 3040 upon receipt of communication 3020, acts to create the input screens necessary for the User to input the data for a new Merchant Partner. The detaUs of the operation of software object 3040 are depicted in Fig. 26.
  • Software object 3040 communicates 3045 the fact of the completion of its execution to software object 3050.
  • Software object 3050 upon receipt of commumcation 3030, acts to accept User input via communication 3055.
  • the User input to software object 3050 is the User's selection of an existing Merchant_PartnerJD to setup or if the User had just completed setup of a new Merchant Partner, then the newly estabhshed (by software object 3040) Merchant PartnerJD is communicated 3045 to software object 3050.
  • Software Object 3050 upon receipt of the Merchant JPartnerJDD, via either communication 3045 OR communication 3055, communicates the Merchant_PartnerJD to software object 3050.
  • a Merchant Partner is a merchant location. That is, a single merchant may have multiple locations, each location generating point of sale data, and each location would then be assigned a separate Merchant Partner TD.
  • Software object 3050 communicates its received Merchant Partner JD to software object 3060.
  • Software object 3060 then acts to inquire of the User whether a new processor agreement is being set up for this merchant location.
  • the User communicates 3065 either a "Yes” or a "No” to software object 3060 in response to the inquiry.
  • Software object 3060 then communicates 3070 the completion of its execution to software object 3090 if the User communication 3065 was "Yes” or communicates 3080 the completion of its execution to software object 3100 if the User commumcation 3065 was "No".
  • Software object 3090 upon receipt of communication 3070, acts to create the input screens necessary for the User to input the data for a new processor agreement.
  • the detaUs of the operation of software object 3090 are depicted in Fig. 27.
  • Software object 3090 communicates 3095 the fact of the completion of its execution to software object 3100.
  • Software object 3100 upon receipt of communication 3095, acts to accept User input via communication 3105.
  • the User input to software object 3100 is the User's selection of an existing AgreementJD to use or if the User had just completed setup of a new Merchant Agreement, then the newly estabhshed (by software object 3090) AgreementJD is communicated 3095 to software object 3100.
  • Software Object 3100 upon receipt of the AgreementJD, via either communication 3095 OR communication 3105, communicates the AgreementJD to software object 3110.
  • a Merchant Agreement is a contract with a processor. That is, a single merchant may, and usuaUy wiU, have multiple contracts with multiple processors of ATM, credit, debit, and cash cards. Each Merchant Agreement would be assigned a separate Agreement D .
  • Software object 3100 communicates the completion of its execution to software object 3110 which then acts to display an input screen inquiring of the User whether the new input data is for a new Terminal.
  • the User responds to the input screen inquiry by communication 3115 to software object 3110, selecting either "Yes” or “No". If the User communicated 3115 a "Yes” to software object 3110, the software object 3110 communicates 3120 that fact to software object 3140. If the User communicated 3115 a "No" to software object 3110, the software object 3110 communicates 3130 that fact to software object 3150.
  • Software object 3110 may, alternatively, begin execution upon receipt of communication 3270 from software object 3260 which commumcates 3270 that additional new Terminals need to be set-up.
  • Software object 3140 upon receipt of communication 3120, acts to create the input screens necessary for the User to input the data for a new Terminal. The details of the operation of software object 3140 are depicted in Fig. 28.
  • Software object 3140 communicates 3145 the fact of the completion of its execution to software object 3150.
  • Software object 3150 upon receipt of commumcation 3130, acts to accept User input via communication 3155.
  • the User input to software object 3150 is the User's selection of an existing Terminal _TD to use or if the User had just completed setup of a new Teiminal, then the newly estabhshed (by software object 3140) Terminal TD is communicated 3145 to software object 3150.
  • Software Object 3150 upon receipt of the Terminal TD, via either communication 3145 OR communication 3155, communicates 3160 the completion of its execution to software object 5600.
  • a single merchant may have multiple terminals, and thus TerminalJDs, at each of multiple locations. Each terminal, at each location, would then be assigned a separate Terminal JD.
  • Software object 5600 upon receipt of communication 3160 from software object 3150, then acts to display an input screen inquiring of the User whether the new input data is for a new Bank Account. The User responds to the input screen inquiry by communication 5605 to software object 5600, selecting either ' ⁇ es" or "No".
  • the software object 5600 communicates 5610 that fact to software object 5630. If the User communicated 5605 a "No" to software object 5600, then software object 5600 communicates 5620 that fact to software object 5650.
  • Software object 5630 upon receipt of communication 5610, acts to create the input screens necessary for the User to input the data for a new Bank Account. The details of the operation of software object 5630 are depicted in Fig. 32.
  • Software object 5630 communicates 5640 the fact of the completion of its execution to software object 5650.
  • Software object 5650 upon receipt of communication 5620, acts to accept User input via communication 5655.
  • the User input to software object 5650 is the User's selection of an existing Bank_Account_ ED to use or if the User had just completed setup of a new Bank Account, then the newly established (by software object 5630) Bank Account ED is communicated 5640 to software object 5650.
  • Software Object 5650 upon receipt of the Bank Account ED, via either communication 5640 OR communication 5655, communicates the completion of its execution to software object 5665. In the instant invention, a single merchant location may utilize and thus need to be associated with multiple bank accounts.
  • Software object 5660 upon receipt of communication from software object 5650, then acts to display an input screen inquiring of the User whether the new input data is for a new Ledger Account.
  • the User responds to the input screen inquiry by communication 5665 to software object 5660, selecting either 'Yes" or "No". If the User communicated 5665 a "Yes" to software object 5660, then software object 5660 communicates 5670 that fact to software object 5690. If the User communicated 5665 a "No" to software object 5660, then software object 5660 communicates 5680 that fact to software object 5710. Software object 5690, upon receipt of communication 5670, acts to create the input screens necessary for the User to input the data for a new Ledger Account. The detaUs of the operation of software object 5690 are depicted in Fig. 34. Software object 5690 communicates 5700 the fact of the completion of its execution to software object 5710.
  • Software object 5710 upon receipt of communication 5680, acts to accept User input via communication 5715.
  • the User input to software object 5710 is the User's selection of an existing Ledger_Account_ ED to use or if the User had just completed setup of a new Ledger Account, then the newly established (by software object 5690) Ledger ccount ED is communicated 5700 to software object 5710.
  • Software Object 5710 upon receipt of the Ledger ⁇ ccount lD, via either communication 5700 OR communication 5715, communicates the completion of its execution to software object 3170.
  • a single merchant location may utihze and thus need to be associated with but a single ledger account. However, one User may choose to associate one Ledger AccountJD with multiple Merchant Partner Ds.
  • Software object 5710 communicates the completion of its execution to software object 3170 which then acts to display an input screen inquiring of the User whether the new input data is for a new Merchant Number.
  • the User responds to the input screen inquiry by commumcation 3175 to software object 3170, selecting either 'Yes" or "No". Lf the User communicated 3175 a 'Yes" to software object 3170, then software object 3170 communicates 3180 that fact to software object 3200. If the User communicated 3175 a "No" to software object 3170, then software object 3170 communicates 3190 that fact to software object 3210.
  • Software object 3170 may, alternatively, begin execution upon receipt of communication 3240 from software object 3230 which communicates 3240 that additional new Merchant Numbers need to be set up for the same Terminal.
  • Software object 3200 upon receipt of communication 3180, acts to create the input screens necessary for the User to input the data for a new Merchant Number. The details of the operation of software object 3200 are depicted in Fig. 29.
  • Software object 3200 communicates 3205 the fact of the completion of its execution to software object 3210.
  • Software object 3210 upon receipt of communication 3190, acts to accept User input via communication 3195.
  • the User input to software object 3210 is the User's selection of an existing MerchantJSTumber to use or if the User had just completed setup of a new MerchantJSTumber, then the newly established (by software object 3200) MerchantJSTumber is communicated 3205 to software object 3210.
  • Software Object 3210 upon receipt of the MerchantJSTumber, via either commumcation 3205 OR communication 3195, commumcates 3215 the completion of its execution to software object 3220.
  • a single terminal may have multiple Merchant Numbers, and thus MerchantJNumbers, assigned to it.
  • a single MerchantJSTumber may also be assigned to a terminal group consisting of multiple terminals.
  • Software object 3220 upon receipt of communication 3215 from software object 3210, then acts to execute SQL Inserts of aU of the selected table associations created by software objects 3010, 3100, 3150, 5650, 5710, and 3210.
  • the detaU of the operation of software object 3220 is depicted in Fig. 31.
  • Software object 3220 communicates 3225 the completion of its execution to software object 3230.
  • Software object 3230 upon receipt of communication 3225 from software object 3220, acts to create a user input screen inquiring whether more Merchant Numbers need to be input for the currently selected (in software object 3150) terminal. The User then commumcates 3235 his selection of "Yes" or "No".
  • software object 3230 communicates 3240 that fact to software object 3170. If the User communication 3235 is of the selection "No”, then software object 3230 commumcates 3250 that fact to software object 3260.
  • Software object 3260 upon receipt of communication 3250 from software object 3230, acts to create a user input screen inquiring whether more Terminals need to be input for the currently selected (in software object 3050) Merchant Partner. The User then commumcates 3265 his selection of 'Yes” or "No”. If the User communication 3265 is of the selection "Yes", then software object 3260 communicates 3270 that fact to software object 3110.
  • software object 3260 communicates 3280 that fact to software object 3290.
  • Software object 3290 upon receipt of communication 3280 from software object 3260, acts to create a user input screen inquiring whether more Merchant Partners need to be input. The User then communicates 3295 his selection of "Yes” or "No”. If the User communication 3295 is of the selection 'Yes", then software object 3290 communicates 3300 that fact to software object 3010. If the User commumcation 3295 is of the selection "No”, then software object 3290 communicates 3310 that fact to software object 3320. Software object 3320, upon receipt of communication 3310 from software object 3290, acts to close the user input screen, and terminates execution of the setup wizard. Fig.
  • Software object 3700 is the ChUd of software object 80 and receives communication 74 from software object 72 (see Fig. 4) OR communication 2040 from software object 2030 (see Fig. 17) OR communication 4560 from software object 4550 (see Fig. 25). Upon receipt of communication 74 OR communication 2040 OR communication 4560, software object 3700 communicates that fact to software object 3710.
  • Software object 3710 upon receipt of communication from software object 3700, acts to setup local variables, Payment_Type_Code, Agreement_ED and OverridingJSTet_GrossJFlag, by executing an SQL Select on the Merchant JSTumbersJTb table and joining to the MerchantsJTb table on the Merchant JPartnerJD column in the MerchantsJTb table equal to the MerchantJPartnerJD column in the MerchantJSTumbersJTb, selecting the Payment_Type_Code, Agreement_ED and OverridingJSTet_GrossJFlag columns, where the MerchantJSTumber column in the MerchantJSTumbesJTb is equal to the MerchantJSTumber provided in the Bank data.
  • Software object 3720 upon receipt of commumcation from software object 3710, acts to setup local variables, Discount Rate, Transaction Fee, and Default JSTet_Gross_Flag, by executing an SQL Select on the Agreement_Rates_Tb table, selecting the Discount J ate, Transaction Fee, and the DefaultJSTet_Gross_Flag columns where the Agreement_ED in the AgreementJR.ates_Tb table is equal to the local varaible Agreement TD found in software object 3710 and the Payment_Type_Code in the AgreementJRates Tb is equal to the local variable Payment_Type_Code found in software object 3710.
  • Software object 3720 also determines whether the bank deposit is deposited at gross or net for reconcihation purposes. f the Overriding_Net_GrossJFlag is not NULL then that value wUl be used to determine the calculations in softare object 3730; otherwise, the Default JSTet_GrossJFlag wiU be used.
  • Software object 3730 upon receipt of communication from software object 3720, acts to compute the Gross, Net, and Fee amounts for the Bank data to be inserted. If the Bank data was entered at Net value, as determined by software object 3720, then using the Discount Rate and Transaction_Fee from software object 3720, the Fee and Gross amounts are calculated.
  • Software object 3770 upon receipt of communication from software object 3760 acts to commit the transaction. Once software object 3770 has completed its execution, it communicates that fact to software object 3780.
  • Software object 3780 upon receipt of communication from software object 3770, acts to select a communication path out on case communication path into software object 3700, as foUows: communication path in communication path out 74 85
  • FIG. 22 depicts in detaU the operation of software object 82, which acts to insert the
  • Software object 3800 is the Child of software object 82 (see Fig. 4) and receives communication 76 from software object 82 OR communication 2140 from software object 2130 (see Fig. 18) OR communication 4570 from software object 4550 (see Fig. 25). Upon receipt of communication 76 OR communication 2140 OR communication 4570, software object 3800 communicates that fact to software object 3810.
  • Software object 3810 upon receipt of communication from software object 3800, acts to setup local variables, Payment_Type_Code, AgreementJD and OverridingJSTet_Gross_Flag, by executing an SQL Select on the MerchantJSTumbers_Tb table and joining to the MerchantsJTb table on the Merchant PartnerJTD column in the MerchantsJTb table equal to the Merchant_PartnerJD column in the MerchantJSTumbersJTb, selecting the Payment_Type_Code, Agreement ED and OverridingJSTet_Gross_Flag columns, where the MerchantJSTumber column in the MerchantJSTumbesJTb is equal to the MerchantJSTumber provided in the POS data.
  • Software object 3810 Once software object 3810 has completed its execution, it communicates its completion to software object 3820.
  • Software object 3820 upon receipt of communication from software object 3810, acts to setup local variables, Discount JRate, Transaction JFee, and DefaultJSTet_GrossJFlag, by executing an SQL Select on the AgreementJRatesJTb table, selecting the Discount Rate, Transaction Fee, and the DefaultJSTet_GrossJFlag columns where the AgreementJD in the Agreement_RatesJTb table is equal to the local varaible Agreement ED found in software object 3810 and the Payment JType Code in the Agreement_Rates_Tb is equal to the local variable Payment_Ty ⁇ e_Code found in software object 3810.
  • Software object 3820 also determines whether the POS data is deposited at gross or net for reconcihation purposes. If the Overriding JSTet_Gross_Flag is not NULL then that value wiU be used to determine the calculations in softare object 3830; otherwise, the Default JSTet_GrossJFlag wiU be used. Once software object 3820 has completed its execution, it communicates that fact to software object 3830. Software object 3830, upon receipt of communication from software object 3820, acts to compute the Gross, Net, and Fee amounts (from the discount rates and transaction fees queried in software object 3820) for the POS data to be inserted.
  • software object 3850 Once software object 3850 has completed its execution, it communicates that fact to software object 3860.
  • Software object 3860 upon receipt of communication from software object 3850, acts to retrieve the SQL Return Code.
  • Software object 3860 then communicates the fact that it has retrieved the SQL Return Code to software object 3870.
  • Software object 3870 upon receipt of communication from software object 3860 acts to commit the transaction.
  • Software object 3880 upon receipt of commumcation from software object 3870, acts to select a communication path out on case communication path into software object 3800, as foUows: communication path in communication path out
  • Fig. 23 depicts in detail the operation of software object 84 which acts to insert the Ledger data into the LedgerJTb table of the database 16.
  • Software object 3900 is the Child of software object 84 and receives communication 78 from software object 84 (see Fig. 4) OR communication 2240 from software object 2230 (see Fig. 19) OR communication 4580 from software object 4550 (see Fig. 25). Upon receipt of communication 78 OR communication 2240 OR communication 4580, software object 3900 communicates that fact to software object 3910.
  • Software object 3910 upon receipt of communication from software object 3900, acts to setup local variables, Payment_Type_Code, Agreement_ED and OverridingJSTet_Gross_Flag, by executing an SQL Select on the MerchantJSTumbers_Tb table and joining to the MerchantsJTb table on the MerchantJPartnerJD column in the MerchantsJTb table equal to the Merchant Partner ED column in the MerchantJSTumbersJTb then joining to the Merchant_Ledger_Accounts_Tb on the MerchantJSTumber in the Merchant_LedgerJ ⁇ ccounts_Tb equal to the Merchant_number provided with the Ledger data, selecting the columns Payment_Type_Code, AgreementJD and OverridingJSTet_Gross_Flag from the Ledger_Accounts_Tb, where the MerchantJSTumber column in the MerchantJSTumbesJTb is equal to the MerchantJSTumber provided in the Ledger data.
  • Software object 3920 upon receipt of communication from software object 3910, acts to setup local variables, Discount Rate, Transaction JFee, and DefaultJSTet_Gross_Flag, by executing an SQL Select on the AgreementJRatesJTb table, selecting the Discount Rate, TransactionJFee, and the DefaultJSTet_GrossJFlag columns where the AgreementJD in the Agreement_Rates_Tb table is equal to the local varaible AgreementJD found in software object 3910 and the Payment_Type_Code in the Agreement JRates_Tb is equal to the local variable Payment_Type_Code found in software object 3910.
  • Software object 3920 also determines whether the ledger data is entered at gross or net for reconcihation purposes. If the Overriding_Net_Gross_Flag is not NULL then that value wiU be used to determine the calculations in softare object 3930; otherwise, the DefaultJSTet_GrossJ i lag wUl be used. Once software object 3920 has completed its execution, it communicates that fact to software object 3930. Software object 3930, upon receipt of communication from software object 3920, acts to compute the Gross, Net, and Fee amounts (from the discount rates and transaction fees queried in software object 3920) for the Ledger data to be inserted.
  • Software object 3950 upon receipt of communication from software object 3940, acts to execute an SQL Insert of the Ledger data and the computed data from software object 3930 into the LedgerJTb table. Once software object 3950 has completed its execution, it communicates that fact to software object 3960. Software object 3960, upon receipt of communication from software object 3950, acts to retrieve the SQL Return Code. Software object 3960 then communicates the fact that it has retrieved the SQL Return Code to software object 3970.
  • Software object 3970 upon receipt of communication from software object 3960 acts to commit the transaction. Once software object 3970 has completed its execution, it
  • Software object 3980 upon receipt of communication from software object 3970, acts to select a communication path out on case communication path into software object 3900, as foUows: communication path in communication path out 78 85
  • FIGs. 24a and 24b are a single flow chart depicting in detaU the operation of software object 170 (see Fig. 5b).
  • Software object 170 provides the User with an opportunity to make manual entries in the entry matching of the reconciliation process.
  • Software object 4000 is a Child of software object 170.
  • Software object 4000 begins execution upon receipt of a communication 165 from software object 150 (see Fig. 5a) once software object 150 has completed its execution of the complex match process.
  • Software object 4000 creates a user reconcihation screen. Once software object 4000 has completed its execution, it communicates that fact to software object 4010.
  • Software object 4010 foUowing its receipt of communication from software object 4000, accepts communication 4005 from the User or communication 4110 from software object 4100.
  • the User input via communication 4005 to software object 4010 selects which accounts to display and compare on the screen created by software object 4000. Typically, due to limited screen size, a User will elect to view only two accounts simultaneously on the screen.
  • the instant invention does however, permit the User to select via communication 4005 an unlimited number of account/data sources for display and reconciliation.
  • Software object 4010 provides initial, default values for the User account selection, but subsequent runs will store User's selection for use as the default in subsequent processing.
  • Software object 4010 selects rows from the selected account tables for viewing based on user preferences. AU rows from the ReconcUiation JData Tb table can
  • Communication 4110 from software object 4100 to software object 4010 wiU cause software object 4010 to again accept User input via communication 4005, so that User might select another set of accounts to display and compare on the screen. User's selection of accounts to display and compare on the screen is communicated by software object 4010 to software object 4020.
  • Software object 4020 takes the first of the User selected set of accounts and performs an SQL Select on the ReconcUiation JDataJTb and the Reconcihation Data Matches Tb tables, selecting rows from the Reconcihation Data Tb where the Table Code in the ReconihationJDataJTb is equal to the first account selected and the BatchJSTumber in the Reconcihation JDataJTb is equal to the current BatchJSTumber.
  • Software object 4020 communicates the completion of its execution to software object 4030.
  • Software object 4030 upon receipt of communication from software object 4020, then displays on the computer screen the rows of account data resultant from the query performed by Object 4020.
  • Software object 4030 communicates the completion of its execution to software object 4040.
  • Software object 4040 upon receipt of communication from software object 4030, takes the next sequential one of the set of accounts selected by the User in Object 4010 and performs an SQL Select on the Reconciliation JData Tb and the Reconcihation JDataJVIatchesJTb tables, selecting rows from the ReconcUiation JDataJTb where the Table_Code in the Reconiliation JDataJTb is equal to the second account selected and the BatchJSTumber in the ReconciliationJDataJTb is equal to the current BatchJSTumber.
  • Software object 4040 communicates the completion of its execution to software object 4050.
  • Software object 4050 upon receipt of communication from software object 4040, then displays on the computer screen the rows of account data resultant from the query performed by Object 4040.
  • Software object 4050 communicates the completion of its execution to software object 4060.
  • Software object 4060 inquires of the User whether the User is finished viewing the displayed accounts. The User communicates 4070 either a 'Yes" or "No" to software object 4060 in response to the inquiry. If the User communicates 4070 ⁇ es", then software object 4060 will communicate 4080 that fact to software object 4100. If the User communicates 4070 "No”, then software object 4060 will communicate 4090 that fact to software object 4130. Upon receipt of communication 4080, software object 4100 gives the User the option to reconcUe another set of accounts in this reconciliation session.
  • software object 4130 will communicate 4140 that fact to software object 4270. Lf the User communicates 4135 "No", then software object 4130 wiU communicate 4150 that fact to software object 4160 (see Fig. 24b).
  • software object 4270 creates a computer screen display of the various options avaUable for User's selection. The User makes his selection via communication 4280 into software object 4270.
  • Software object 4280 communicates User's selections back to software object 4020, which again commences execution with User's preferences apphed.
  • software object 4160 inquires of the User whether User desires to enter or finalize the adjustments as they currently exist.
  • software object 4160 communicates 4190 that fact to software object 4210.
  • Software object 4210 displays on the computer screen the User selected rows of unmatched account data and permits the User to communicate 4215 row selections from the rows of the two displayed accounts which are declared by User to be a match. Such declared matches by User may routinely be necessary because of disparity in dates between the POS and Bank items or other various minor variations which are not overcome by the automatic simple and complex matching procedures of the instant invention.
  • software object 4210 communicates the manually matched rows of data to software object 4220.
  • software object 4220 Upon receipt of commumcation from software object 4210, software object 4220 provides the User the option to update the database 16 with rows of data manuaUy matched in software object 4210. User communicates 4225 his selection to either "No", don't update the database 16 with his changes, or Yes" update database 16 with his changes and highlights on the computer display screen created by software object 4220 those rows of manuaUy matched data that User elects to use to update database 16. If User communicated 4225 "No” to software object 4220, then software object 4220 communicates 4223 the completion of its execution to software object 4060 (Fig. 24a). If the User communicated 4225 "Yes" to software object 4220, then software object 4220 communicates 4228 the completion of its execution to software object 4230.
  • software object 4230 Upon receipt of communication from software object 4220, software object 4230 acts to begin the transaction. Software object 4230 communicates the completion of its execution to software object 4240. Upon receipt of communication from software object 4230, software object 4240 performs an SQL Insert on the Reconcihation JDataJVIatchesJTb table; inserting the Data_EDs from the rows of data that were manuaUy matched by the User in software object 4210. Software object 4240 commumcates the completion of its execution to software object 4250. Upon receipt of commumcation from software object 4240, software object 4250 acts to retrieve the SQL Return Code. Software object 4250 communicates the completion of its execution to software object 4260.
  • software object 4260 Upon receipt of communication from software object 4250, software object 4260 acts to commit the transaction.
  • Software object 4260 communicates 4290 the completion of its execution to software object 4020.
  • Software object 4020 upon receipt of communication 4290 from software object 4260 OR software object 4200, commences execution making its selection of rows of data to display from the remaining unmatched rows of data in the accounts selected by the User.
  • software object 4160 communicates 4180 that fact to software object 4200.
  • the details of the operation of software object 4200 are depicted in Fig. 25.
  • Software object 4200 provides an adjustment screen display on the computer.
  • Software object 4200 communicates 4290 the completion of its execution to sof ware object 4020.
  • Fig. 25 depicts in detail the operation of software object 4200 (see Fig. 24b).
  • Software object 4200 creates an adjustment screen for the User to enter Bank/POS/Ledger/Other adjustments to rows of data in the accounts being reconciled.
  • Software object 4500 is a Child of software object 4200 and receives communication 4180 from software object 4160 (see Fig. 24b). Upon receipt of communication 4180 from software object 4160, software object 4500 creates and displays a User adjust screen.
  • Software object 4500 communicates the completion of its execution to software object 4510.
  • software object 4510 acts to accept User input data, which is an adjustment to the rows of data in the accounts being reconcUed.
  • the User's input is via communication 4505 to software object 4510 and is completed by the User's selection of either a "Cancel” or a “Save” command.
  • software object 4510 communicates the completion of its execution to software object 4520.
  • Software object 4520 upon receipt of communication from software object 4510, acts to determine whether the User elected to "Cancel” or "Save” the data adjustments that he made.
  • software object 4520 determines that the User elected "Cancel"
  • software object 4520 communicates 4540 that fact to software object 4680.
  • Software object 4680 upon receipt of communication 4540 from software object 4520 OR communication from software object 4690 OR communication from software object 4610 OR communication from software object 4640 OR communication from software object 4670 acts to close the adjustment screen.
  • Software object 4680 communicates 4290 the completion of its execution to software object 4020 (see Fig. 24a).
  • software object 4520 determines that the User elected "Save"
  • software object 4520 communicates 4530 that fact to software object 4550.
  • Software object 4550 upon receipt of communication 4530 from software object 4520, acts to determine the data type being saved: The data type wUl be determined by software object 4550 to be one of the following types: Other, Bank, POS, or Ledger. Based on its determination of the data type to be saved, software object 4550 communicates the data via communication 4555 to software object 4690 if the data is Other (future types) data, via communication 4560 to software object 80 if the data is Bank data (see Fig. 21), via communication 4570 to software object 82 if the data is POS data (see Fig.
  • Software object 4690 upon receipt of communication 4555 from software object 4550, acts to insert the Other data (a future data type) into the database 16 and communicate the completion of its execution to software object 4680.
  • Software object 80 upon receipt of communication 4560 from software object 4550, acts to insert the Bank adjustment data into the BankJTb table of the database 16 and communicate 4600 the completion of its execution to software object 4610.
  • Software object 4610 upon receipt of communication 4600 from software object 80 (see Fig.21 for detaUs of operation), executes an SQL Update of the Bank adjustment data in the ReconciliationJDataJTb for the merchant number, date and time and transaction type of the adjustment that was made.
  • the SQL Update will either add to or subtract from the value of the transaction depending on whether the adjustment made is positive or negative.
  • Software object 4610 communicates the completion of its execution to software object 4680.
  • Software object 82 upon receipt of communication 4570 from software object 4550, acts to insert the POS adjustment data into the ProcessorJTb table of the database 16 and communicate 4630 the completion of its execution to software object 4640.
  • Software object 4640 upon receipt of communication 4630 from software object 82 (see Fig.22 for details of operation), executes an SQL Update of the POS adjustment data in the ReconcUiation JData Tb for the merchant number, date and time and transaction type of the adjustment that was made.
  • the SQL Update will either add to or subtract from the value of the transaction depending on whether the adjustment made is positive or negative.
  • Software object 4640 communicates the completion of its execution to software object 4680.
  • Software object 84 upon receipt of communication 4580 from software object 4550, acts to insert the Ledger adjustment data into the LedgerJTb table of the database 16 and communicate 4660 the completion of its execution to software object 4670.
  • Software object 4670 upon receipt of communication 4660 from software object 84 (see Fig.23 for details of operation), executes an SQL Update of the Ledger adjustment data in the Reconcihation Data Tb for the merchant number, date and time and transaction type of the adjustment that was made.
  • the SQL Update wiU either add to or subtract from the value of the transaction depending on whether the adjustment made is positive or negative.
  • Software object 4670 communicates the completion of its execution to software object 4680.
  • Fig. 26 depicts in detaU the operation of software object 3040.
  • Software object 3040 creates the Partner set up screen (see Fig. 20a), giving the User the possible choices of Master Partner, Bank Partner, Processor Partner, or Merchant Partner. Additionally, software object 3040 can accommodate future "Other" Partner types.
  • Software object 5000 is a ChUd of software object 3040 and receives input via communication 3020 from software object 3010 (see Fig. 20a) OR communication 5115 from software object 5105 (see Fig. 27) OR communication 5002 from User. Upon receipt of communication 3020 OR communication 5002 OR communication 5115, software object 5000 communicates the received data together with the completion of its execution to software object 5005.
  • Software object 5005 upon receipt of communication from software object 5000, creates and displays the Partner Setup screen.
  • Software object 5005 communicates the completion of its execution to software object 5010.
  • Software object 5010 accepts the User Input via communication 5015 of data about the Partner being set-up, which is input into fields by the User. The User selects and communicates 5015 "Save” or "Cancel” to software object 5010 when he is finished inputting data to software object 5010. After completion of the User's input via communication 5015, software object 5010 communicates the completion of its execution to software object 5020.
  • Software object 5020 upon receipt of communication from software object 5010, acts to determine whether the User elected to "Cancel" or “Save” the partner data entered.
  • software object 5020 dete ⁇ nines that the User elected "Cancel"
  • software object 5020 communicates 5030 that fact to software object 5060.
  • Software object 5060 upon receipt of communication 5030 from software object 5020, acts to close the input screen.
  • Software object 5060 commumcates the completion of its execution to software object 5070.
  • Software object 5070 upon receipt of communication from software object 5060, acts to deteimine the source of the input communication to software object 5000. If the input commumcation to software object 5000 was via communication 3020, then software object 5070 communicates 3045 the completion of its execution to software object 3050 (see Fig. 20a).
  • software object 5070 communicates 5125 the completion of its execution to software object 5135 (see Fig. 27). If the software object 5020 determines that the User elected “Save”, then software object 5020 communicates 5040 that fact to software object 5050. Software object 5050, upon receipt of communication 5040 from software object 5020, acts to execute an SQL Insert of Partner Data (see Fig. 30 for detaUs of operation). Software object 5050 communicates 5055 the completion of its execution to software object 5060.
  • Fig. 27 depicts in detail the operation of software object 3090.
  • Software object 3090 creates the Agreement set up screen (see Fig. 20a), giving the User the ability to input new Processor agreements as needed.
  • Software object 5100 is a ChUd of software object 3090 and begins execution upon receipt of communication 3070 from software object 3060.
  • Software object 5100 creates and displays the Processor Agreement Set-Up screen.
  • Software object 5100 communicates the completion of its execution to software object 5105.
  • Software object 5105 upon receipt of communication from software object 5100, inquires of the User whether he desires to set-up a new Processor Partner. If the User communicates 5110 that Yes", he wants to set up a new Processor Partner, then software object 5105 will communicate 5115 that fact to software object 3040. If the User communicates 5110 that "No", he does not want to set up a new Processor Partner, then software object 5105 will communicate 5130 that fact to software object 5135.
  • Software object 3040 communicates 5125 the completion of its execution to software object 5135.
  • Software object 5135 upon receipt of communication 5125 from software object 3040, wUl communicate the new Processor data created in software object 3040 to software object 5145.
  • Software object 5135 upon receipt of communication 5130 from software object 5105, accepts input from the User via communication 5140 so that the User may select an existing Processor for which Agreement data is being entered. This selection by User is accomphshed in the preferred embodiment by highlighting on the computer screen the particular Processor desired from a list of all possible Processors previously entered into the database 16.
  • software object 5135 communicates this selection to software object 5145.
  • Software object 5145 upon receipt of communication from software object 5135, accepts User input data regarding the terms of the Agreement (such data including name of the processor, length of the Agreement, discount rates by card type, charge back fees, and monthly fees) via communication 5150.
  • the final input by User to software object 5145 is the selection of a "Save” or "Cancel” button.
  • software object 5145 Upon completion of User's input to software object 5145, software object 5145 communicates the completion of its execution together with the data input by the User to software object 5155.
  • Software object 5155 upon receipt of communication from software object 5145, acts to determine whether the User selected the "Save” or the "Cancel” button in his input communication 5150 to software object 5145. If software object 5155 determines that the User's input communication 5150 to software object 5145 included a "Save” command, then software object 5155 communicates 5160 this fact to software object 5170. If software object 5155 determines that the User's input communication 5150 to software object 5145 included a "Cancel” command, then software object 5155 communicates 5165 this fact to software object 5190.
  • Software object 5170 upon receipt of commumcation 5160 from software object 5155, acts to execute an SQL Insert of input data from software object 5145 into the AgreementsJTb table.
  • Software object 5170 communicates 5175 the completion of its execution to software object 5180.
  • Software object 5180 upon receipt of communication 5175 from software object 5170, acts to create and display a screen for the User to input rate data regarding the Agreement being set up.
  • the detaUed operation of software object 5180 is depicted in Fig. 35.
  • Software object 5180 communicates 5185 the completion of its execution to software object 5190.
  • Software object 5190 upon receipt of communication 5185 from software object 5180 OR communication 5165 from software object 5155, acts to close the input screen.
  • Software object 5190 communicates 3095 the completion of its execution to software object 3100 (see Fig. 20a).
  • Fig. 28 depicts in detaU the operation of software object 3140.
  • Software object 3140 creates the Terminal setup screen (see Fig. 20a), giving the User the ability to setup new Terminals as needed.
  • Software object 5200 is a Child of software object 3140 and begins execution upon receipt of communication 3120 from software object 3110 (see Fig. 20a).
  • Software object 5200 creates and displays the Terminal Set-Up screen.
  • Software object 5200 communicates the completion of its execution to software object 5210.
  • Software object 5210 upon receipt of communication from software object 5200, acts to accept User Input via communication 5205 whereby the User can input data regarding the Terminal and then elect to either "Cancel" or “Save” the data to the database 16.
  • the data input by the User may include the Terminal name, the Merchant_PartnerJD, the Terminal type, the printer type, a lease flag, Monthly Fee amounts, and other pertinent data.
  • the final input by User to software object 5210 is the selection of a "Save” or "Cancel” button.
  • software object 5210 Upon completion of User's input to software object 5210, software object 5210 communicates the completion of its execution together with the data input by the User to software object 5220.
  • Software object 5220 upon receipt of communication from software object 5210, acts to determine whether the User selected the "Save” or the "Cancel” button in his input communication 5205 to software object 5210.
  • software object 5220 determines that the User's input communication 5205 to software object 5210 included a "Save" command, then software object 5220 communicates 5240 this fact to software object 5250.
  • Tf software object 5220 determines that the User's input communication 5205 to software object 5210 included a "Cancel" command, then software object 5220 communicates 5230 this fact to software object 5260.
  • Software object 5250 upon receipt of communication 5240 from software object 5220, acts to execute an SQL Insert of input data from software object 5210 into the Terminals Tb table.
  • Software object 5250 communicates the completion of its execution to software object 5260.
  • Software object 5260 upon receipt of communication from software object 5250 OR communication 5230 from software object 5220, acts to close the input screen.
  • Software object 5260 communicates 3145 the completion of its execution to software object 3150 (see Fig. 20a).
  • Fig. 29 depicts in detail the operation of software object 3200.
  • Software object 3200 creates the Merchant Number set up screen (see Fig. 20b), giving the User the ability to setup new Merchant Numbers as needed.
  • Software object 5300 is a Child of software object 3200 and begins execution upon receipt of commumcation 3180 from software object 3170 (Fig. 20b).
  • Software object 5300 creates and displays the Merchant Number setup screen.
  • Software object 5300 communicates the completion of its execution to software object 5310.
  • Software object 5310 upon receipt of commumcation from software object 5300, acts to accept User Input via commumcation 5315 whereby the User can input data regarding the Merchant Number and then elect to either "Cancel" or "Save" the data to the database 16.
  • the data input by the User may include the MerchantJSTumber, Merchant JPartner_ED, Payment_Type_Code, Overriding_Agreement_TD, Monthly_Fee_Amounts, and other pertinent data.
  • the final input by User to software object 5310 is the selection of a "Save” or "Cancel” button.
  • software object 5310 Upon completion of User's input to software object 5310, software object 5310 communicates the completion of its execution together with the data input by the User to software object 5320.
  • Software object 5320 upon receipt of communication from software object 5310, acts to determine whether the User selected the "Save" or the "Cancel” button in his input communication 5315 to software object 5310.
  • software object 5320 determines that the User's input communication 5315 to software object 5310 included a "Save" command, then software object 5320 communicates 5340 this fact to software object 5350.
  • Tf software object 5320 determines that the User's input communication 5315 to software object 5310 included a "Cancel” command, then software object 5320 communicates 5330 this fact to software object 5370.
  • Software object 5350 upon receipt of communication 5340 from software object 5320, acts to execute an SQL Insert of input data from software object 5310 into the MerchantJSTumbers_Tb table.
  • Software object 5350 communicates 5360 the completion of its execution to software object 5370.
  • Software object 5370 upon receipt of communication 5360 from software object 5350 OR communication 5330 from software object 5320, acts to close the input screen.
  • Software object 5370 communicates 3205 the completion of its execution to software object 3210 (see Fig. 20b).
  • Fig. 30 depicts in detaU the operation of software object 5050 (see Fig. 26).
  • Software object 5050 performs the SQL Insert of Partner data into the database 16. Two SQL inserts are executed by software object 5050. The first SQL Insert inserts Partner data into the PartnersJTb table. The second SQL Insert associates the Partner with the Master Partner record. Each Partner, except for Master Partners, is associated back to a Master Partner record/row in the PartnersJTb table.
  • Software object 5400 is a Child of software object 5050 and begins execution upon receipt of communication 5040 from software object 5020. Software object 5400, upon receipt of communication 5040 from software object 5020, acts to begin the transaction.
  • Software object 5400 communicates the completion of its execution to software object 5410.
  • Software object 5410 upon receipt of communication from software object 5400, acts to execute an SQL Insert of Partner data into the PartnersJTb table.
  • Software object 5410 communicates the completion of its execution to software object 5420.
  • Software object 5420 upon receipt of communication from software object 5410, acts to retrieve the SQL Return Code.
  • Software object 5420 communicates the completion of its execution to software object 5430.
  • Software object 5430 upon receipt of communication from software object 5420, acts to execute an SQL Insert of Partner data into the Partner JEJierarchy _Tb table. This SQL Insert by software object 5430 associates the new Partner record (data row) with a Master Partner record hi the PartnersJTb.
  • the Master Partner_ED associated with the new Partner is that of the current User's Partner ED as setup in the UsersJTb.
  • the program of the instant invention is first started the User is logged in and the Partner ED from the UsersJTb is stored in a session variable.
  • Software object 5430 communicates the completion of its execution to software object 5440.
  • Software object 5440 upon receipt of communication from software object 5430, acts to retrieve the SQL Return Code.
  • Software object 5440 communicates the completion of its execution to software object 5450.
  • Software object 5450 upon receipt of communication from software object 5440, acts to commit the transaction.
  • Software object 5450 communicates 5055 the completion of its execution to software object 5060 (see Fig. 26).
  • Fig. 31 depicts in detaU the operation of software object 3220 (see Fig. 20c).
  • Software object 3220 creates aU of the associations necessitated by the User entry of a Merchant Number in the Merchant Setup wizard (Figs. 20a, 20b, and 20c).
  • Software object 5500 is a ChUd of software object 3220 and begins execution upon receipt of communication 3215 from software object 3210 (see Fig. 20b).
  • Software object 5500 upon receipt of communication 3215 from software object 3210, acts to begin the transaction.
  • Software object 5500 communicates the completion of its execution to software object 5510.
  • Software object 5510 upon receipt of communication from software object 5500, acts to execute an SQL Insert into the Terminal JVIerchantJSTumbersJTb table to associate the Merchant Number to the Terminal; the SQL Insert is performed by inserting the Terminal ED selected and the MerchantJSTumber selected into the Terminal JVIerchant JSTumbersJTb table.
  • Software object 5510 communicates the completion of its execution to software object 5520.
  • Software object 5520 upon receipt of communication from software object 5510, acts to retrieve the SQL Return Code.
  • Software object 5520 commumcates the completion of its execution to software object 5530.
  • Software object 5530 upon receipt of communication from software object 5520, acts to execute an SQL Update on the Merchant JSTumbers_Tb table to associate the Merchant Number to the Bank Account that was previously selected.
  • the SQL Update is performed by updating the MerchantJSTumber record with the Bank_Account_TD for the Bank Account selected.
  • Software object 5530 communicates the completion of its execution to software object 5540.
  • Software object 5540 upon receipt of communication from software object 5530, acts to retrieve the SQL Return Code.
  • Software object 5540 communicates the completion of its execution to software object 5550.
  • Software object 5550 upon receipt of communication from software object 5540, acts to execute an SQL Insert into the Merchant_Ledger_Account_Tb table to associate the Merchant Number to the Ledger account selected.
  • the SQL Insert executed by software object 5550 inserts the MerchantJSTumber and the Ledger AccountJD into the Merchant JLedger_AccountJTb table.
  • Software object 5550 communicates the completion of its execution to software object 5560.
  • Software object 5560 upon receipt of communication from software object 5550, acts to retrieve the SQL Return Code.
  • Software object 5560 communicates the completion of its execution to software object 5570.
  • Software object 5570 acts to commit the transaction.
  • Software object 5570 communicates 3225 the completion of its execution to software object 3230 (see Fig. 20c).
  • Fig. 32 depicts in detail the operation of software object 5630.
  • Software object 5630 creates the Bank Account setup screen (see Fig. 20b), giving the User the ability to setup new Bank Accounts as needed.
  • Software object 6000 is a Child of software object 5630 and begins execution upon receipt of communication 5610 from software object 5600 (Fig. 20b).
  • Software object 6000 creates and displays the Bank Account Setup screen.
  • Software object 6000 communicates the completion of its execution to software object 6010.
  • Software object 6010 upon receipt of communication from software object 6000, acts to accept User Input via communication 6020 whereby the User can input data regarding the Bank Account and then elect to either "Cancel" or “Save” the data to the database 16.
  • the final input by User to software object 6010 is the selection of a "Save” or "Cancel” button.
  • software object 6010 Upon completion of User's input to software object 6010, software object 6010 communicates the completion of its execution together with the data input by the User to software object 6030.
  • Software object 6030 upon receipt of communication from software object 6010, acts to determine whether the User selected the "Save” or the "Cancel” button in his input communication 6020 to software object 6010. If software object 6030 determines that the User's input communication 6020 to software object 6010 included a "Save” command, then software object 6030 communicates 6040 this fact to software object 6060.
  • software object 6030 determines that the User's input communication 6020 to software object 6010 included a "Cancel" command, then software object 6030 communicates 6050 this fact to software object 6080.
  • Software object 6060 upon receipt of communication 6040 from software object 6030, acts to execute an SQL Insert of input data from software object 6010 into the Bank_Accounts_Tb table. DetaUed operation of software object 6060 is depicted in Fig. 33.
  • Software object 6060 communicates 6070 the completion of its execution to software object 6080.
  • Software object 6080 upon receipt of communication 6070 from software object 6060 OR communication 6050 from software object 6030, acts to close the input screen.
  • Software object 6080 communicates 5640 the completion of its execution to software object 5650 (see Fig. 20b).
  • Fig. 33 depicts in detail the operation of software object 6060 (see Fig. 32).
  • Software object 6060 performs SQL Inserts of new Bank Account data into the database 16 and associates the current User with the new Bank Account.
  • Software object 6100 is a Child of software object 6060 and begins execution upon receipt of communication 6040 from software object 6030 (Fig. 32).
  • Software object 6100 upon receipt of communication 6040 from software object 6030, acts to begin the transaction.
  • Software object 6100 commumcates the completion of its execution to software object 6110.
  • Software object 6110 upon receipt of communication from software object 6100, acts to execute an SQL Insert into the Bank Accounts Tb table of new Bank Account data.
  • Software object 6110 communicates the completion of its execution to software object 6120.
  • Software object 6120 upon receipt of communication from software object 6110, acts to retrieve the SQL Return Code.
  • Software object 6120 communicates the completion of its execution to software object 6130.
  • Software object 6130 upon receipt of communication from software object 6120, acts to execute an SQL Insert into the User_Accounts_Tb table to associate the new Bank Account with the current User. The SQL Insert is performed by inserting the User JD for the current User and the Bank_Account_ED for the Bank Account selected into the User_Accounts_Tb table.
  • Software object 6130 communicates the completion of its execution to software object 6140.
  • Software object 6140 upon receipt of communication from software object 6130, acts to retrieve the SQL Return Code.
  • Software object 6130 communicates the completion of its execution to software object 6150.
  • Software object 6150 upon receipt of communication from software object 6140, acts to commit the transaction.
  • Software object 6150 communicates 6070 the completion of its execution to software object 6080 (see Fig. 32).
  • Fig. 34 depicts in detaU the operation of software object 5690.
  • Software object 5690 creates the Ledger Account set up screen (see Fig. 20b), giving the User the ability to setup new Ledger Accounts as needed.
  • Software object 6200 is a Child of software object 5690 and begins execution upon receipt of commumcation 5670 from software object 5660 (Fig. 20b).
  • Software object 6200 creates and displays the Ledger Account Setup screen.
  • Software object 6200 communicates the completion of its execution to software object 6210.
  • Software object 6210 upon receipt of communication from software object 6200, acts to accept User Input via communication 6220 whereby the User can input data regarding the Ledger Account and then elect to either "Cancel" or "Save" the data to the database 16.
  • the final input by User to software object 6210 is the selection of a "Save” or "Cancel” button.
  • software object 6210 Upon completion of User's input to software object 6210, software object 6210 communicates the completion of its execution together with the data input by the User to software object 6230.
  • Software object 6230 upon receipt of commumcation from software object 6210, acts to determine whether the User selected the "Save” or the "Cancel” button in his input communication 6220 to software object 6210. If software object 6230 dete ⁇ nines that the User's input communication 6220 to software object 6210 included a "Save” command, then software object 6230 communicates 6240 this fact to software object 6260.
  • software object 6230 determines that the User's input communication 6220 to software object 6210 included a "Cancel" command, then software object 6230 commumcates 6250 this fact to software object 6280.
  • Software object 6260 upon receipt of commumcation 6240 from software object 6230, acts to execute an SQL Insert of input data from software object 6210 into the Ledger_Accounts_Tb table.
  • Software object 6260 communicates 6270 the completion of its execution to software object 6280.
  • Software object 6280 upon receipt of communication 6270 from software object 6260 OR communication 6250 from software object 6230, acts to close the input screen.
  • Software object 6280 communicates 5700 the completion of its execution to software object 5710 (see Fig. 20b).
  • Fig. 35 depicts in detaU the operation of software object 5180.
  • Software object 5180 creates the Processor Rates setup screen (see Fig. 27), giving the User the abUity to setup new Processor Rates as needed, as for example when a new Processor Agreement is entered into the instant invention, then new rates must also be added to complete input of data for the Agreement.
  • Software object 6300 is a Child of software object 5180 and begins execution upon receipt of communication 5175 from software object 5170.
  • Software object 6300 creates and displays the Processor Rate Setup screen.
  • Software object 6300 communicates the completion of its execution to software object 6310.
  • Software object 6310 upon receipt of communication from software object 6300, acts to accept User Input via commumcation 6320 whereby the User can input data regarding the Processor Rates and then elect to either "Cancel” or “Save” the data to the database 16.
  • the information input by the User to software object 6310 could include the payment type, the different rates for type of transactions (keyed vs. swipe), the monthly fees, and the statement fees.
  • the final input by User to software object 6310 is the selection of a "Save” or "Cancel” button.
  • software object 6310 Upon completion of User's input to software object 6310, software object 6310 communicates the completion of its execution together with the data input by the User to software object 6330.
  • Software object 6330 upon receipt of commumcation from software object 6310, acts to determine whether the User selected the "Save” or the "Cancel” button in his input communication 6320 to software object 6310. If software object 6330 determines that the User's input communication 6320 to software object 6310 included a "Save” command, then software object 6330 communicates 6350 this fact to software object 6360. If software object 6330 determines that the User's input communication 6320 to software object 6310 included a "Cancel” command, then software object 6330 communicates 6340 this fact to software object 6410. Software object 6360, upon receipt of communication 6350 from software object 6330, acts to execute an SQL Insert of input data from software object 6310 into the Agreement JRatesJTb table.
  • Software object 6360 communicates the completion of its execution to software object 6370.
  • Software object 6370 upon receipt of communication from software object 6360, accepts to accept User Input via communication 6371 in response to the query whether to enter another rate.
  • User Input via communication 6371 to software object 6370 can be either a Yes" or a "No". If the User communicates 6371 a Yes" to software object 6370, software object 6370 wUl communicate 6380 such fact to software object 6400. If the User communicates 6371 a "No" to software object 6370, software object 6370 wUl communicate 6390 such fact to software object 6410.
  • Software object 6400 upon receipt of communication 6380 from software object 6370, acts to clear the input screen.
  • Software object 6400 communicates the completion of its execution to software object 6300.
  • Software object 6410 upon receipt of communication 6390 from software object 6370 OR communication 6340 from software object 6330 acts to close the input screen.
  • Software object 6410 communicates 5185 the" completion of its execution to software object 5190 (Fig. 27).
  • Fig. 36 depicts those software objects used by the instant invention to set up new Users.
  • Software object 6510 creates and displays the New User setup screen.
  • Software object 6510 has its operation initiated by input communication 6500 from an existing User.
  • Software object 6510 communicates the completion of its execution to software object 6520.
  • Software object 6520 upon receipt of communication from software object 6510, acts to accept User Input via communication 6530 whereby the User can input data regarding the new User and then elect to either "Cancel" or “Save” the data to the database 16.
  • the final input by User to software object 6520 is the selection of a "Save” or "Cancel” button.
  • software object 6520 Upon completion of User's input to software object 6520, software object 6520 communicates the completion of its execution together with the data input by the User to software object 6540.
  • Software object 6540 upon receipt of communication from software object 6520, acts to determine whether the User selected the "Save” or the "Cancel” button in his input communication 6530 to software object 6520. If software object 6540 determines that the User's input communication 6530 to software object 6520 included a "Save” command, then software object 6540 communicates 6550 this fact to software object 6570. If software object 6540 determines that the User's input communication 6530 to software object 6520 included a "Cancel” command, then software object 6540 communicates 6560 this fact to software object 6610. Software object 6570, upon receipt of communication 6550 from software object 6540, acts to begin the transaction. Software object 6570 communicates the completion of its execution to software object 6580.
  • Software object 6580 upon receipt of communication from software object 6570, acts to execute an SQL Insert of input data from software object 6520 into the UsersJTb table.
  • Software object 6580 communicates the completion of its execution to software object 6590.
  • Software object 6590 upon receipt of communication from software object 6580, acts to retrieve the SQL Return Code.
  • Software object 6590 communicates the completion of its execution to software object 6600.
  • Software object 6600 upon receipt of commumcation from software object 6590, acts to commit the transaction.
  • Software object 6600 communicates the completion of its execution to software object 6610.
  • Software object 6610 upon receipt of communication from software object 6600 OR communication 6560 from software object 6540, acts to close the input screen.
  • Fig. 37 depicts those software objects used by the instant invention to setup associations of Users to Bank Accounts.
  • the association of a User to a Bank Account authorizes that associated User to access and reconcile that associated Bank Account.
  • Software object 6710 creates and displays the User/Bank Account Association screen.
  • Software object 6710 has its operation initiated by input communication 6700 from the current User.
  • Software object 6710 commumcates the completion of its execution to software object 6720.
  • Software object 6720 upon receipt of communication from software object 6710, acts to accept User Input via communication 6730 whereby the User can input data regarding the new User/Bank Account Associations and then elect to either "Cancel" or "Save" the data to the database 16.
  • the final input by User to software object 6720 is the selection of a "Save” or "Cancel” button.
  • software object 6720 Upon completion of User's input to software object 6720, software object 6720 communicates the completion of its execution together with the data input by the User to software object 6740.
  • Software object 6740 upon receipt of communication from software object 6720, acts to determine whether the User selected the "Save” or the "Cancel” button in his input communication 6730 to software object 6720. If software object 6740 determines that the User's input commumcation 6730 to software object 6720 included a "Save” command, then software object 6740 communicates 6750 this fact to software object 6770.
  • software object 6740 determines that the User's input communication 6730 to software object 6720 included a "Cancel" command, then software object 6740 communicates 6760 this fact to software object 6810.
  • Software object 6770 upon receipt of communication 6750 from software object 6740, acts to begin the transaction.
  • Software object 6770 communicates the completion of its execution to software object 6775.
  • Software object 6775 upon receipt of communication from software object 6770, acts to execute SQL Delete(s) to remove Bank Accounts not selected in software object 6720 from the User_Accounts_Tb table.
  • Software object 6775 communicates the completion of its execution to software object 6780
  • Software object 6780 upon receipt of communication from software object 6775, acts to execute an SQL Insert of input data from software object 6720 into the User_Accounts_Tb table.
  • Software object 6780 communicates the completion of its execution to software object 6790.
  • Software object 6790 upon receipt of communication from software object 6780, acts to retrieve the SQL Return Code.
  • Software object 6790 communicates the completion of its execution to software object 6800.
  • Software object 6800 upon receipt of communication from software object 6790, acts to commit the transaction.
  • Software object 6800 communicates the completion of its execution to software object 6810.
  • Software object 6810 upon receipt of communication from software object 6800 OR communication 6760 from software object 6740, acts to close the input screen.
  • Fig: 38 depicts those software objects used by the instant invention to set up an Association of Users to Merchant Partners.
  • the association of a User to a Merchant Partner authorizes that associated User to access and reconcile that Merchant Partner Account.
  • Software object 6860 creates and displays the User/Merchant Partner Association screen.
  • Software object 6860 has its operation initiated by input communication 6850 from the current User.
  • Software object 6860 communicates the completion of its execution to software object 6870.
  • Software object 6870 upon receipt of communication from software object 6860, acts to accept User Input via communication 6880 whereby the User can input data regarding the new User/Merchant Partner Associations and then elect to either "Cancel" or "Save" the data to the database 16.
  • the final input by User to software object 6870 is the selection of a "Save” or "Cancel” button.
  • software object 6870 Upon completion of User's input to software object 6870, software object 6870 communicates the completion of its execution together with the data input by the User to software object 6890.
  • Software object 6890 upon receipt of communication from software object 6870, acts to determine whether the User selected the "Save” or the "Cancel” button in his input communication 6880 to software object 6870. If software object 6890 determines that the User's input communication 6880 to software object 6870 included a "Save” command, then software object 6890 communicates 7000 this fact to software object 7020.
  • software object 6890 determines that the User's input communication 6880 to software object 6870 included a "Cancel" command, then software object 6890 communicates 7010 this fact to software object 7060.
  • Software object 7020 upon receipt of communication 7000 from software object 6890, acts to begin the transaction.
  • Software object 7020 communicates the completion of its execution to software object 7025.
  • Software object 7025 upon receipt of communication from software object 7020, acts to execute SQL Delete(s) to remove Merchant Partner Accounts not selected in software object 6870 from the UserJVIerchantsJTb table.
  • Software object 7025 communicates the completion of its execution to software object 7030.
  • Software object 7030 upon receipt of communication from software object 7025, acts to execute an SQL Insert of input data from software object 6870 into the User Merchants Tb table.
  • Software object 7030 commumcates the completion of its execution to software object 7040.
  • Software object 7040 upon receipt of commumcation from software object 7030, acts to retrieve the SQL Return Code.
  • Software object 7040 communicates the completion of its execution to software object 7050.
  • Software object 7050 upon receipt of communication from software object 7040, acts to commit the transaction.
  • Software object 7050 commumcates the completion of its execution to software object 7060.
  • Software object 7060 upon receipt of communication from software object 7050 OR communication 7010 from software object 6890, acts to close the input screen.
  • a second embodiment of the instant invention provides that software object 24 encapsulates the database 16.
  • a third embodiment of the instant invention provides that no database 16 exists and that its functions are provided by data sets.
  • a fourth embodiment of the instant invention provides that there are no data sets wherein the database 16 provides additional tables to hold the data described in the preferred embodiment as being in data sets.
  • a fifth embodiment of the instant invention provides that software object 24 encapsulates the database 16 and further provides that there are no data sets wherein the database 16 provides additional tables to hold the data described in the preferred embodiment as being in data sets.
  • the instant invention addresses a pervasive problem throughout the commercial world.
  • businesses all over the world are doing a reconciliation of their credit card and other electronic payment processor account statements, their monthly bank statements, and their general ledger accounting system by hand.
  • the difficulty in obtaining an accurate reconcUiation of the hereinabove described accounts is such that many, if not most, businesses simply enter "correction” or "reconcUiation” factors into their ledgers rather than attempting or obtaining an accurate reconciliation. Largely the difficulty is cause by the quantity and diversity of Processor Agreement forms and terms and by the varying delays the Processor inserts between the POS sale and the posting of the credit to the businesses' Merchant Account.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Technology Law (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

A system for simultaneously reconciling a merchant's point of sale/electronic payment transactions data to the merchant's bank account deposits and chargebacks data received from the merchant's merchant account/processor's transactions to the data in the merchant's legacy general accounting ledger system. The system provides a software object running on a computer, which software object is in communication with a source of the point of sale/electronic payment transactions data, with a source of the merchant's bank account deposit and charge back transactions data from the merchant's chosen merchant account, and with the data in the merchant's general ledger system. The system is further capable of simultaneous reconciliation of an arbitrary number of acounts, limited only by the hardware of the user's computing system.

Description

MERCHANT ACTIVITY AND RECONCILIATION PROGRAM Background of the Invention a. Technical Field
The present invention is related generally to the field of software and computer systems that provide credit card sales accounting and reconciliation functions for a merchant.
The present invention is related more specifically to the field of software and computer systems utilized to reconcile individual credit card and electronic payment transactions to the credits and debits entered into a merchant's bank account by the credit card processor. Yet more specifically, the present invention is related to software and computer systems that reconcile individual credit card and electronic payment transactions to the credits, debits and adjustments entered into a merchant's bank account by the credit card processor and further reconcile such credits, debits, and adjustments from the merchant's bank account to the merchant's general ledger. A substantial problem exists in that the merchant's point of sale data is in terms of individual transactions which are transmitted to a credit card/electronic payment processor which in turn transmits the data to the paying entity (Visa®, MasterCard®, American Express®, etc.) in bulk (that is, the individual transactions are accumulated, usually for a days' worth of individual transactions) and the paying entity then transmits payment in bulk to the merchant's merchant account.
A further problem exists in that the credit card/electronic payment processor, the paying entity (credit card or other electronic payment company), and the merchant bank all have individual contracts with the merchant which require payment by the merchant for their services; and such payments may be subtracted at various rates from the deposits made into the merchant's merchant account
A yet further problem exists in that the credit card/electronic payment processor, the paying entity (credit card or other electronic payment company), and the merchant bank all have individual contracts with the merchant which permit the back charging of the merchant's merchant account, and the charging of fees for making such back charge, in the event that the merchant's customer refuses payment. A yet further and final problem exists in that the deposits and chargebacks into the merchant's merchant account are delayed from the making of the individual point of sale transaction, usually by from one to four days, b. Background Art Accounting software that is capable of reconciling accounts is well known. Multiple applications of such existing software to the problems of a reconciliation of a plurality of accounts could be accomplished. However, rather than sequential application of accounting software packages, which would approximate the actual labor intensive process accomplished routinely today by merchants to obtain functional approximations of a reconciliation of the three accounts (same being the individual transactions of the point of sale system, the bulk transactions of the merchant account, and the individual and/or bulk transactions of the general ledger system), the prior art tends toward large scale electronic systems.
U.S. Patent No. 5,963,925 teaches an electronic statement presentation (ESP) system that replaces the preparation and mailing of paper statements and invoices from a biller with electronic delivery. The ESP system provides software for auditing and reconciliation and balancing of accounts. The ESP system provides for the forwarding of both consumer and merchant data through a central service bureau. The ESP system is designed to be an electronic bill payment service and does not address many of the problems of an individual merchant trying to reconcile his credit and electronic payments sales with his merchant account credits, debits, and chargebacks, in light of his general ledger entries, particularly issues of net versus gross transaction payments and time delayed transfers which are commonly encountered by individual merchants.
U.S. Patent No. 6,026,379 teaches a method to securely transmit payment information from a customer to a merchant to a payment gateway and return a certificate, including a credit confidence factor to allow a merchant to determine whether to accept or reject payment information. The method provides for online connection of the merchant to the customer to the payment gateway, which may encompass a credit card processing facility. The detailed description of Object Oriented Programming provided on pages 7 though 11 is referred to and hereby adopted by reference. The method provides for communication of (at page 97) a "LEGACY - Administrative Inquiry Record" which provides all of the information to a merchant necessary to accomplish a reconciliation. The method of this invention does not, however, accomplish the reconciliation for the merchant. U.S. Patent No. 5,608,874 teaches an automated data transfer method suitable for transferring accounting data to a central data storage that can provide a bureau service. The bureau service may include provision of reconciliation services for an individual merchant.
However, the invention speaks to the method of data transfer and does not disclose the reconciliation method.
Patent 5,544,086 teaches a system for determining value in a stored value transaction system that has a plurality of value transferring devices including a local device, a collection device, a consolidation device and a settlement device. The system is applicable to integrated circuit cards, as a value transferring device. The integrated circuit card transfers value from an account, may be a bank account, at a point of sale to a collection device. The integrated circuit necessarily maintains balance calculations. The system provides for a network settlement device which performs overall settlement of the accounts of the transaction system. The consolidation device's functions of totaling and consolidating information received at the end of each processing day, such information may include the total amount for each issuer of cards, a total amount for each merchant or service provider may also be included in this information See pages 13 and 14. However, no portion of the system teaches the reconciliation that must be accomplished by the individual merchant
Typically, the pattern of transfers following a credit card/electronic payment sale by a merchant is: the credit card is input to the point of sale machine (terminal) or "virtual" terminal, the terminal transmits the individual transaction information to the merchant's chosen credit card processor, the credit card processor transmits the individual transaction information (bundled into a bulk transfer) to a credit card clearing house, the clearing house transmits the individual transaction information to the respective credit card entities (MasterCard®, Visa®, etc.), each credit card entity transmits a bulk transaction payment (providing summary information only) to the merchant's chosen merchant bank, the merchant bank transmits the bulk transaction payment to the merchant account at the merchant's commercial bank, and then the commercial bank sends the merchant a bank statement.
Routinely, the merchant's chosen processor receives individual transactions from a merchant's point of sale device or terminal and then transfers as a bulk transaction (summarizing all of the individual transactions) into the merchant account on a daily basis. Additionally, a merchant typically closes out ("batches") each point of sale device or terminal on a daily basis and posts the close out information to his general ledger. Such closeout information may be in various formats, in bulk or summary, individual transactions, summarized by category of goods or services, summarized by sales person, etc.
Several charges or fees are incurred by a merchant for using a credit card/electronic payment system as above described. Each credit and/or debit and/or value stored card issuer has an individual contract with the merchant wherein the merchant agrees to charges and fees in greater or lesser amounts on a per item, or per cash volume, or per time period basis. Or any combination of the foregoing. Additionally, the merchant's chosen processor and chosen merchant bank also have fees and charges which also may be calculated in any combination of the foregoing ways. Further, the charges and fees by all the participants in the merchant's credit sales transactions may be levied by subtraction from individual transactions, or debited from bulk transactions, or simply debited periodically. Finally, the merchant account is subject to chargebacks, and related additional fees and charges, whenever a purchaser reverses a credit sale made by the merchant (subject to card holder terms, etc.).
Also, the approval of any individual transaction by the credit card issuer/electronic payment source may be delayed for from one to three days. Therefore, the individual transaction may be included within a given bulk transaction from the merchant's chosen processor and thus to the merchant bank for a period of one to three days.
The merchant needs to reconcile the individual transaction information of the merchant's point of sale device or terminal to the bulk transaction data reflecting deposits into and chargebacks from the merchant account at the merchant's commercial bank, and reconcile the sales data in the merchant's general ledger (into which the merchant records individual transactions and/or batched transactions, dependent upon the merchant's custom) with the bank deposits and chargebacks data (which records bulk transactions).
A first problem occurs when the monthly charges for the merchant account and for the individual credit card issuers are debited from the commercial account. These debits may be stand alone items or may be included within a bulk transfer from the merchant account.
A second problem occurs when the merchant compares an individual transaction to the amount included within a bulk transfer including that individual transaction. The contract with various entities may either include the right to pay/transfer a net amount or may provide for a gross transfer and debit periodically for the accumulated charges.
A third problem occurs when a particular credit card charge or electronic payment is reversed, whether for non-payment or otherwise. The particular credit card charge or electronic payment is included within and will reduce a bulk transfer from the merchant account to the merchant's commercial bank account. Additionally, certain contracted charges will be incurred by the merchant to the merchant bank and to the particular credit card issuer making the payment reversal. A yet further problem is that the merchant will encounter time delays of up to four days between the incident of sale and transfer to the processor of the individual transaction and the time that the individual transaction appears within a bulk transfer from the merchant account.
A yet further problem occurs when merchant attempts to reconcile his merchant account transfers to his general ledger entries which typically are made on a daily basis to accumulate and track sales.
A yet further and final problem occurs because the merchant's chosen credit card/electronic payment processor may deduct its charges from individual transactions or debit all transactions on a periodic basis, or both; and the merchant's selected merchant bank may deduct its charges from individual transactions or debit all transactions on a periodic basis, or both; and each credit card issuer may likewise deduct its charges or debit for same (pursuant to individual contract). Each of the various billing entities by charging for services and deducting from credits or remitting on individual transactions in net or in gross impact the amount actually deposited into the merchant's commercial bank account. Many merchants today use an "approximate reconciliation" whereby they take the deposit amounts transmitted to them from their merchant account and subtract those amounts from the recorded general ledger sales and "label" the difference credit card service expenses. This is a labor saving technique, but it results in the loss of the identity of individual transactions and in the loss of many thousands of dollars of sales revenue due to the inability to trace and identify individual transactions, whereby fraud, chargebacks, and other unaccounted for losses proliferate. The reconciliation process for a merchant is a difficult, time-consuming, expensive process that does not appear to be adequately addressed in the prior art. Disclosure of the Invention
The instant invention is of a software program and system that reconciles a plurality of accounts, typically such a reconciliation is of a merchant's point of sale/electronic payment transactions to the merchant's bank account deposits and chargebacks, and then to the merchant's legacy general ledger system. The system of the instant invention provides for a single software object running on a single computer, wherein the software object is in communication with a source of the point of sale/electronic payment transactions, a source of the merchant account deposit and charge back transactions, and the merchant's general ledger system. The system of the instant invention further provides a database and communicates reconciled transactions to the merchant for entry in the merchant's legacy general ledger system. The instant invention addresses all of the hereinabove identified problems encountered by a merchant when reconciling his credit card/electronic payment receipts to his merchant account statement and to his general ledger entries.
Accordingly, it is an object of this invention to provide a software program and system which reconciles the individual transaction information of the merchant's point of sale device or terminal to the bulk transaction data reflecting deposits into and chargebacks from the merchant account at the merchant's commercial bank, and reconciles the sales data in the merchant's general ledger with the bank deposits and chargebacks data.
It is a further object of this invention to provide a software program and system which identifies and includes within the reconciliation process any and all (including without limitation monthly, transactional, and volume) charges for the merchant account and for the individual credit card issuers that are debited from the commercial account, either as stand alone items or as included within a bulk transfer from the merchant account.
It is a yet further object of this invention to provide a software program and system which includes and applies the individual contract terms with the various card issuers, processors, and merchant banks, to each individual credit card/electronic transfer transaction in order to identify that transaction within a bulk transfer from the merchant bank to the merchant's merchant account at his commercial bank.
It is a yet further object of this invention to provide a software program and system which identifies each credit card/electronic payment reversal or charge back, together with the contractually agreed upon charges and fees due to the merchant bank and the credit card issuer, and includes such information in the reconciliation process. It is a yet further object of this invention to provide a software program and system which identifies individual credit card and/or electronic payment transactions, even though delayed up to four days in time from the incident of sale, within bulk transfers from the merchant account and includes them in the reconciliation process. It is a yet further object of this invention to provide a software program and system which identifies the individual components of within a bulk transfer from the merchant account, either debit or credit, and reconciles those components back to the merchant's general ledger entries.
It is a yet further and final object of this invention to provide a software program and system which identifies the contractually incurred adjustments to each individual credit card and/or electronic payment transaction and/or bulk transfer from the merchant bank and includes them in the reconciliation of the merchant account and of the general ledger.
Definition of Terms and Phrases
The following terms and phrases are utilized throughout the instant apphcation and are herein deemed to have the definitions indicated:
ActiveX object - An object that is exposed to other applications or programming tools through Automation interfaces.
Adjustment - Increase or decrease in amount of a transaction for any reason or cause.
Agreement - Merchant contract with a bank or processor indicating fees and obligations between the two parties.
Authorization Code - Processor (processor network) authorizes transaction with approval code.
Automation object - An object that is exposed to other applications or programming tools through Automation interfaces.
Bank - Depository facility for funds of electronic transactions for user or customer of this application. Bank Account - Specific account number for this user or customer; where funds are deposited electronically for transactions.
Batch - Merchant "closes" electronic transactions in groups called batches.
Begin Transaction - Begins a database transaction. See Transaction.
Boolean expression - An expression that evaluates to either True or False. bv - an abbreviation used to indicate a view created from two or more tables; used as a suffix in a view name. See View.
Charge-back - Merchants may experience occasions when a customer refuses to pay for a transaction or may encounter other reasons for a transaction being "returned".
Client/server computing - A system of computing in which two or more computers share processing across a network. The server computer manages a shared resource, such as a database, and responds to requests from clients for use of this resource. The client computer interacts with a user and makes requests for use of a shared resource. Client/server computing separates the functions of an application into two parts: a front end component and a back end component. The client presents and manipulates data on the workstation; the server stores, retrieves, and protects data.
Close Cursor - closes a cursor and de-allocates the memory used by the cursor. See Cursor. Closing Date - Designated time period for a specific item. Example: Merchants' banking period may have a closing date at the end of the month or any time during the month, depending on the designated cut-off date of reporting. Data Collection - A group of related objects. See object. Column - In an SQL database table, the area, sometimes called a field, in each row that stores the data about an attribute of the object modeled by the table. Individual columns are characterized by their maximum length and the type of data that can be placed in them. A column contains an individual data item within a row. COM - See component object model. Commit Transaction - To save a change to a database, cube, or dimension. An SQL COMMIT statement guarantees that all or none of the transaction's modifications are made a permanent part of the database. A COMMIT statement also frees resources, such as locks, used by the transaction. See also roll back. Communication Line - All numbered items on the flowcharts have been assigned a designation of either an Object or a Communication Line. Communication Line designates movement of either the user or data from one Object to another.
Component Object Model (COM) - The programming model upon which several SQL Server and database application programming interfaces (APIs) such as SQL-DMO, OLE DB, and ADO are based. A programming structure that includes both data and functionality. A COM object is defined and allocated as a single unit.
Cursor - A database object used by applications to manipulate data by rows instead of by sets. Using cursors, multiple operations can be performed row by row against a result set with or without returning to the original table. In other words, cursors conceptually return a result set based on tables within the database(s). For example, a cursor can be generated to include a list of all user-defined table names within a database. After the cursor has been opened, movement (fetching) through the result set can include multiple operations against each table by passing each table name as a variable. Cursors are powerful when combined with stored procedures and the EXECUTE statement (to build strings dynamically). Data - The coded representation of information for use in a computer. Data has attributes, such as type and length. Database - A collection of information, tables, and other objects organized and presented to serve a specific purpose, such as facilitate searching, sorting, and recombining data.
Databases are stored in files.
Dynamic Link Library (DLL) - An executable routine containing a specific set of functions stored in a .dll file and loaded on demand when needed by the program that calls it.
Electronic Payment Transaction - The term includes all forms of electronic payments
(payments other than cash). Includes but not limited to the following:
Visa®, Mastercard®, Diners Club®, American Express®, Discover®, EBT(Electronic Benefit
Transfer), ACH (Automated Clearing House), ATM (Automated Teller Machine), Debit, In- House Charge, Stored Value Cards and Electronic Checks.
EOF or End Of File - a Boolean variable that indicates the end of file. Indicates that the current record position is after the last record in a Recordset or cursor.
Fee - A charge of any kind associated with an electronic payment or a fee charged by the processor or bank. Field - A single item of information contained within a row. A field is more commonly called a column in an SQL database.
Flag - a Boolean field that usually indicates True or False, Yes or No, On or Off
FTP - File Transfer Protocol. See protocol.
Gross - The original amount of the transaction at the point of sale before any fees or discount rates have been applied.
Hierarchy - An arrangement of members of a dimension into levels based on parent-child relationships, such as Year, Quarter, Month, Day or Country, Region, State or Province, City.
Members in a hierarchy are arranged from more general to more specific.
H> - Usually indicates the database field is an Identity Column. Identity Column - A column in a table that uses the identity property for a system-generated, monotonically increasing number.
Identity Field - an auto sequencing field in a database table. Upon execution of an SQL
Insert the Identity field is automatically assigned the next whole number in the sequence.
Initialize - to reset the database registers in preparation for receipt of SQL commands. Inner Join - A join in which records from two tables are combined and added to a query's results only if the values of the joined fields meet certain specified criteria. Join - As a verb, to combine the contents of two or more tables and produce a result set that incorporates rows and columns from each table. Tables are typically joined using data that they have in common. As a noun, the process or result of joining tables, as in the term "inner join" to indicate a particular method of joining tables. See Inner Join. Keyed - A transaction that has been processed at the point of sale by any manual method. Example: If the terminal were down and the merchant were to "key" in the customer's credit card numbers manually. This could also apply to merchants that process electronic transactions over the internet or telephone. These type of transactions usually experience a higher fee or rate. LAN - Local Area Network
Ledger - The accounting system used by the merchant. Ledger is the term used for the software or system used for warehousing the accounting or financial entries. Left Outer Join or Left Join - A type of outer join in which all rows from the first-named table (the left table, which appears leftmost in the JOIN clause) are included. Unmatched rows in the right table do not appear.
Local Variables - variables local to the current function or procedure. Merchant - Company, person or business that is accepting credit cards or electronic payments from customers. The merchant is the customer or user for this software. Merchant Number - Every merchant is assigned unique customer or identification number by each of the electronic payment methods. Example: Every American Express® merchant is assigned a unique identification number for each location.
Net - This is the gross (sale) amount of the electronic payment less the fees or discount rates that were applied. Depending on the agreement, some electronic payment methods are deposited into the merchant's bank account at net, while others may be deposited at gross. NULL - An entry that has no explicitly assigned value. NULL is not equivalent to zero or blank. A value of NULL is not considered to be greater than, less than, or equivalent to any other value, including another value of NULL.
Object - (1) An instance of a class, combining both data and procedures. For example, a control on a running form is an object. (2) One of the components of a database: a table, index, trigger, view, key, constraint, default, rule, user-defined data type, or stored procedure. Also called a database object. (3) A file, directory, database, or database record Other - This software invention has been designed to accommodate any number more than two (unlimited number) of data inputs for reconciliation. The merchant may have more than the Bank, Ledger and POS inputs. Some merchants may add an additional source of data in the future in order to perform additional reconciliations. Example: A merchant may want to add a comparison between the POS and the Processor files. The POS in this example would be the terminal software that may transmit data into a PC or LAN before transmitting the data to the Processor. The processor would then transmit the data back to our software. A additional comparison could be made between the POS and the processor file at that point; adding another layer of internal control and reconciliation to ensure data is not being dropped between the POS and the processor transmission.
Primary Key (PK) - The column or combination of columns that uniquely identifies one row from any other row in a table. A primary key (PK) must be nonnull and must have a unique index. A primary key is commonly used for joins with foreign keys (matching non-primary keys) in other tables. POS -Point of Sale
Processor - All merchants that process electronic payments have a processor. The transactions are processed through this vendor. A merchant may have many processors. Each electronic payment method could be processed by a different vendor; depending on the merchant's organization. The processor is the party that presents the electronic payments to the banks/networks for payment. Most processors are associated with a bank.
Protocol - A set of rules or standards designed to enable computers to connect with one another and exchange information.
Query - A specific request for data retrieval, modification, or deletion.
Rate - A merchant signs an agreement with a processor or electronic payment vendor to pay an agreed upon amount for the ability to process electronic payments with that processor or vendor. It can be a flat rate, a percentage, applied per transaction or any combination of these scenarios. Example: American Express® may charge a merchant 3.25%, while the Mastercard® or Visa® processor for that same merchant may charge 2.25%; plus $0.25 per transaction. While another merchant may have lower rates; but also offer electronic checks, being charged another rate from that processor or vendor.
Reconciliation - the making of two or more apparently conflicting things consistent or compatible; the bookkeeping term used for comparing the bank statement to the balance sheet or financial system known as the ledger. A bank reconciliation accounts for the differences between the statement and the ledger system balance. Usually the differences entail any items that are in transit or have never cleared the bank account. The fees or discount rates that have been applied could be another factor, as well as any charge-backs that have occurred that have been unaccounted for. Additional reconciliations may include other factors or transaction groups.
Record - A group of related fields (columns) of information treated as a unit. A record is more commonly called a row in an SQL database.
Recordset - The ADO object used to contain a result set. It also exhibits cursor behavior depending on the recordset properties set by an apphcation. ADO recordsets are mapped to
OLE DB rowsets.
Resultset - The set of rows returned from a SELECT statement. The format of the rows in the result set is defined by the column-list of the SELECT statement.
Relationship - A link between tables that references the primary key in one table to a foreign key in another table. The relationship line is represented in a database diagram by a solid line if referential integrity between the tables is enforced, or a dashed line if referential integrity is not enforced for INSERT and UPDATE transactions. The endpoints of a relationship line show a primary key symbol to denote a primary key to foreign key relationship or an infinity symbol to denote the foreign key side of a one-to-many relationship. Retrieve SQL Return Code - indicates the status of a result set or query
Right Outer Join or Right Join - A type of outer join in which all rows in the second-named table (the right table, the one that appears rightmost in the JOIN clause) are included.
Unmatched rows in the left table are not included.
Roll back - The ability to remove partially completed transactions after a database or other system failure. See also commit.
Row - A data structure that is a collection of elements (columns), each with its own name and type. A row can be accessed as a collective unit of elements, or the elements can be accessed individually. A row is equivalent to a record. See also column.
SELECT - The Transact-SQL statement used to request a selection, projection, join, query, and so on, from a SQL Server database.
Server - A software object mnning on a computer connected to a local area network (LAN) that controls access to resources, such as files, printers, and communication devices. Scheduled Task - an automated job that is scheduled to run at predefine times without any intervention
Self-join - A join that compares rows within the same table. In database diagrams, a self-join is called a reflexive relationship. SQL Insert or Insert query - A query that copies specific columns and rows from one table to another or to the same table.
SQL Select or Select query - A query that returns rows into a result set from one or more tables. A Select query can contain specifications for those columns to return, the rows to select, the order to put the rows in, and how to group (summarize) information. SQL Statement - An SQL or Transact-SQL statement, such as SELECT or DELETE, that performs some action on data.
SQL Update or Update query - A query that changes the values in columns of one or more rows in a table.
Swiped - Term for the method of sale or electronic transaction. If the transaction were processed via a card reader or credit card terminal; this would indicate that the card was present and would be considered "swiped". The card reader or terminal retrieves the pertinent information via the magnetic bar code on the back of the card.
Table - An object in a database that stores data as a collection of rows and columns.
Tb - an abbreviation for table; used as a suffix in table names Terminal - Term referring to the machine or method for collecting transactions at the point of sale. Originally this term referred to the actual machine used by merchants for reading or swiping cards. However, current technology includes the PC and software objects that are virtual 'terminals" with a card reader attached to a keyboard or some merchants even have
"terminals" accessed via a website or server. Transaction - A group of database operations combined into a logical unit of work that is either wholly committed or rolled back. A transaction is atomic, consistent, isolated, and durable.
Transaction rollback - Rollback of a user-specified transaction to the last save point inside a transaction or to the beginning of a transaction. tv - an abbreviation for a SQL table view when the view is created from a single table; used as a suffix in table views. User - a person that has been setup and assigned a User ID and password to access the apphcation
View - an alternate way of looking at data from one or more tables in a database. A View is a virtual table, usually created as a subset of columns from one or more tables.
Web Server - A software object nning on a computer that provides Web services and pages to intranet and Internet users.
All terms and phrases not defined in the foregoing list are deemed to have their usual and ordinary meaning to persons skilled in the art of programming in the visual basic language.
Database Table Definitions
1. Agreements Tb - Agreement or Contract setup between a Merchant and a Processor.
2. Agreement_Rates_Tb - the rates setup in an Agreement or Contract. Indicates the discount rate(s) for each Payment Type. 3. Bank_Tb - table used to store data provided by the Bank, data is stored at the Master Partner level.
4. Bank_Accounts_Tb - Bank Accounts setup at the Bank Partner level.
5. Ledger Tb - table used to store data provided by the customer ledger system, data is stored at the Master Partner level. 6. Ledger_Accounts_Tb - Ledger Accounts are setup at the Master Partner level.
Ledger Accounts are setup by the User and are assigned to a Master Partner record in the Partners_Tb. 7. Merchants_Tb - table used to associate Agreements/Contracts with a Merchant
Location. 8. Merchant_Ledger_Account_Tb - table used to associate Ledger Accounts to a
Merchant_Number, uses effective dates.
9. Merchant_Numbers_Tb - table used to store Merchant Numbers assigned to a Merchant Location by the Processor.
10. Partners Tb - used to store Partner records. A Partner could be a Bank, Merchant Location or a Processor. All Partner records that are not Master Partners reference a
Master Partner record. A single Master Partner record is setup for each copy of the software that is sold.
11. Partner_Hierarchy_Tb - used to create Parent/Child relationship on the Partner Tb. This associates Bank, Merchant Location and Processor records to Master Partner records.
12. Processor_Tb - table used to store data provided by the Processor, data is stored at the Master Partner level.
13. Reconciliation_Tb - table used to store data about a reconciliation that is current or complete. 14. Reconciliation_Associations_Tb - table used to associate data tables defined in Reconciliation Data Tables Tb to different reconciliations defined in Reconcihation_Decode_Tb. - There is a one-to-many relationship between Reconciliation Code and Table_Code.
15. Reconciliation_Cleared_Data_Tb Once a reconcihation is complete the original data rows used in the reconciliation must be marked so we don't include them in future reconcihation of the same type. The Reconciliation_Code, Table_Code, and
Record_ID from the original data table are stored here permanently. The same data can be pulled into another reconciliation as long as it is a different reconciliation being performed.
16. Reconciliation_Data_Tb - table used to temporarily store summarized table data while a reconcihation is being executed. Data from the Bank Tb, Ledger_Tb and
Processor Tb is summarized and inserted into this table when a reconcihation is first started.
17. ReconciIiation_Data_Matches_Tb - table used to reconcile the data. When a match is found between two different data sets in the Reconcihation_Data_Tb the Data_IDs are stored in this table to show the match. Once all tables and rows have been matched there will be a circular reference made in this table.
18. Reconciliation_Data_Tables_Tb - table used to store the tables that are available to the reconciliations defined in Reconciliation_Decode_Tb. Only one entry per data table exists in this table. 19. Reconciliation_Decode_Tb - table used to store the different reconciliations that can be performed; i.e. Bank to Ledger, POS to Ledger, Bank to POS, 3-way, 4-way, multi-acct, etc. 20. Reconciliation_Locations_Tb - contains all Merchant Locations that are included in the reconcihation identified by the Batch SSumber. 21. ReconciIiation_Matching_Tb - table is used to identify the tables that will be matched within a reconciliation and provides the procedure to perform the match. When a reconciliation is being executed only two data sets at a time are being compared. All possible combinations between any two data sets for the reconciliation are included in the Reconcilation_Matching_Tb. - If the reconcihation consisted of two data sets then only one row would exist in this table; if the reconcihation consisted of three data sets then three rows would exist in this table. When all matching procedures are executed for a Reconcihation_Code a circular reference will be created between each of the data sets included in the reconcihation.
22. Reconciliation_Report_Data_Tb - table used to store data for historical reporting. Once a reconcihation is complete the data is inserted here and then deleted from Reconciliation_Data_Tb.
23. Reconciliation_Report_Matches_Tb - table used to store data for historical reporting. Once a reconciliation is complete the data is inserted here and then deleted from Reconciliation_Data_Matches_Tb .
24. Terminals_Tb - table used to setup terminals and associates the Terminal with a Merchant Location.
25. Terminal_Merchant_Numbers_Tb - used to associate MerchantJSlumbers to a Terminal.
26. User_Tb - used to store User records. Each User record is assigned to a Master Partner ld. The User_JJD "SYSTEM' is a reserved User_JJD and can not be assigned to any user.
27. User Aecounts Tb - Bank Accounts a User is setup or authorized to use.
28. User_Merchants_Tb - Merchant Locations assigned to a User. A Merchant Location is defined in the Partners Tb.
29. User_Preference_Tb - used to store User preferences and system settings for the instant invention, if system settings are being saved the User JO will be equal to
"SYSTEM'.
Definitions of Table Fields (Variables)
Table Name Field Description Agreements Tb
Agreement_JJD Uniquely identifies the agreement
Processor PartnerJDD Partner lD in Partners Tb which identifies a Processor Partner
Agreement_Name Name or Description of the agreement with the Processor
Descripton Optional Description of the agreement with the Processor
Comments Optional Comments about the agreement with the Processor
Monthly_Fee_Amt Monthly Fee associated with this agreement
Chargeback_Fee_Amt Charge Back fees associated with this agreement
Start Date Effective Start Date of the Agreement
End_Date Effective End Date of the Agreement
Date_Added Date the row was added to the table
DateJVIodified Date the row was last modified
Agreement Rates Tb
Agreement Rate lD Uniquely identifies the rate for an agreement
Agreement_ID Associates the rate with an agreement in the Agreements Tb
Payment Type Code Type of rate setup (ie. Visa®, Mastercard®, etc.)
Start_Date Effective Start Date of the rate
End_Date Effective End Date of the rate
Keyed_Discount_Rate The keyed discount rate assigned to the rate Keyed_Transaction_Fee_Amt The keyed per transaction amount assigned to the rate Swiped_Discount_Rate The swiped discount rate assigned to the rate
Swiped_Transaction_Fee_Amt The swiped per transaction amount assigned to the rate Monthly_Fee_Amt Optional monthly fee assigned to this rate
Min_Monthly_Fee_Amt Optional niinimum monthly Fee assigned to this rate
Default_Net_Gross_Flag Indicates the default deposit method for transactions
(Net or Gross)
Date Added Date the row was added to the table
DateJVIodified Date the row was last modified
Bank_Accounts_Tb
Bank Account ID Uniquely identifies the Bank Account Bank Partner lD Partner_ID in Partner Tb which identifies a Master Partner Bank_Account_Number The Bank Account Number Inbound_Routing_Number Unique numeric designation for a bank's location Description Brief description of the bank account Monthly_Fee_Amt Optional Monthly Fees Start_Date Effective Start Date for the Bank Account End Date Effective End Date for the Bank Account Date Added Date the row was added to the table DateJVIodified Date the row was last modified Bank_Tb Bank ID Uniquely identifies a Bank record PartnerJ-D Partner ID in Partners Tb which identifies a Master Partner Merchant_Number Merchant Number used for the transaction. Identifies Visa®,
Mastercard®, Discover®, etc. Transaction Date The date the transaction took place
Bank Code Identifies if Deposit, Chargeback, etc.
Bank AccountJSfumber The Bank Account Number in which the transaction acted upon
Transaction_Gross_Amt The gross transaction amount
Transaction_Fee_Amt Fee's associated with the transaction Transaction_Net_Amt Net transaction amount (Gross - Fee) = Net
Date Added Date the row was added to the table.
Ledger_Accounts_Tb
Ledger AccountJDD Uniquely identifies a Ledger record
PartnerJ-D PartnerJ-D in Partners Tb which identifies a Master Partner Ledger Account Number The Ledger account number the transaction acted upon
Description The description of the transaction
DefaultJSTet GrossJFlag Indicates the default method for account entries entered into the general ledger (Net or Gross)
Date_Added The date the Ledger record was added Date_Modified The date the Ledger record was modified Ledger Tb Ledger lD The unique id given to each ledger PartnerJ-D The Master Partner record to which the Ledger is associated
Ledger_AccountJSfumber Used to uniquely identify accounts within the Ledger
Ledger Date The date the Ledger entry was made
MerchantJSfumber The Merchant Number used for the transaction
Ledger_Gross_Amt The gross transaction amount
LedgerJ7ee_Amt The Fees associated with the transaction
Ledger Net A t The net transaction amount (Gross - Fee = Net)
Date_Added Date the row was added to the table
Merchants_Tb
PartnerJ-D Partner ID in the Partners Tb which identifies a Master Partner
Merchant_Partner_ID PartnerJD in Partners Tb which identifies a Merchant Location Partner
Agreement !!) The agreement number assigned to the Merchant Location
Montly_Fee_Amt Optional Monthly fees associated with this Merchant Location
Date Added Date the row was added to the table
DateJVIodified Date the row was last modified
Merchant Ledger Account _Tb
Merchant Number Merchant Number from Merchant JN~umbers_Tb
Start JDate Effective start date for transactions to act upon the assigned Ledger Account
EndJDate Effective end date for transactions to stop acting upon the assigned Ledger Account
Ledger Account ID Ledger Account ID from Ledger_Accounts_Tb which uniquely identifies a Ledger Account OverridingJSfet_Gross_Flag Overriding flag indicates if the transaction on the Ledger Account is at Net or at Gross - overrides the Default JS[et_Gross_Flag in the Ledger_Accounts_Tb table
Date_Added Date the row was added to the table DateJVIodified Date the row was last modified Merchant_Numbers_Tb
Merchant Number Unique Merchant Number assigned to the Merchant Location by the Processor Merchant Partner ID PartnerJD in Partners_Tb which identifies a Merchant
Location Partner
Payment Type Code Identifies the type: ie. Visa®, Mastercard , Discover®, etc. Bank Account ID Bank_AccountJD from Bank_Accounts_Tb which uniquely identifies a Bank Account OverridingJSfet_Gross_Flag Overriding flag indicates whether the transaction on the Bank
Account is at Net or at Gross - overrides the
Default JSIet_Gross_Flag in the Agreement_Rates_Tb Overriding_Agreement_ ID An agreement assigned to the MerchantJNTumber that overrides the Agreement D in the Merchants Tb table
Monthly JFee_Amt Optional Monthly fee associated with the Merchant J^umber
Date Added Date the row was added to the table
DateJVIodified Date the row was last modified
Partners_Tb
Partners !!) Uniquely identifies the row in the Partners Tb
Partner Type Code Defines the type of partner record (Master, Bank, Processor,
Merchant Location, etc.)
PartnerJSTame Name or Description of the Partner
AddressJLinel Mailing Address Line 1
AddressJ ine2 Mailing Address Line 2
AddressJ-ine3 Mailing Address Line 3
City Mailing City
Region Mailing Region, State or Province
Postal Code Mailing Postal Code
Country Mailing Country
StoreJMumber Store Number for Merchant Locations
Date Added Date the row was added to the table
DateJVIodified Date the row was last modified
Partner Hierarchy Tb
Parent Partner lD Partner_ID in Partners Tb which identifies the Parent Record
Child Partner ID Partner ID in Partners Tb which identifies the Child Record Processor Tb
Processor JDD Uniquely identifies the Processor record PartnerJ-D Partner JDD in Partners_Tb which identifies a Master Partner MerchantJMumber The Merchant Number used for the transaction Transaction Date Date the transaction was made Payment Type Code Visa®, MasterCard®, Discover®, etc. Expiration Date Expiration date on the credit card Card Number Credit Card Number Card _ Holders _ Name Name on the credit card Customer RoutingJSTumber Customer's Bank Routing Number; Electronic
Checks/Transfers Customer 3ank_AccountJNFumber Customer's Bank Account Number; Electronic
Checks/Transfers Customer CheckJSTumber Customer's Check or Reference Number; Electronic Checks/Transfers ,
Transaction Gross Amt The gross transaction amount Transaction_Fee_Amt The Fees associated with the transaction TransactionJSTet_Amt The net transaction amount (Gross - Fee -= Net) Authorization Code Authorization code used for this transaction Transaction J-nputJVIethod Swiped or Keyed or Electronic Check flag
Date Added Date the row was added to the table ReconciliationJTb
BatehJNumber Uniquely identifies the reconcihation Batch JDate The date the reconciliation was started UserJD The ID of the User running the reconciliation Reconciliation Code The code from Reconciliation JDecode Tb of the reconciliation being performed
Bank Account TD The id of the Bank Account the reconcihation is being performed on ClosingJDate The closing date the reconciliation is using as an ending point Bank_Batch_Starting_Amt The amount of summarized Bank transactions at the start of the reconcihation Bank_Batch_Ending_Amt The amount of summarized Bank transactions at the end of the reconciliation Ledger J3atch_Starting_Amt The amount of summarized Ledger transactions at the start of the reconciliation Ledger_Batch_Ending_Arnt The amount of summarized Ledger transactions at the end of the reconciliation Processor_Batch_Starting_Amt The amount of summarized Process transactions at the start of the reconciliation ProcessorJBatch_Ending_Amt The amount of summarized Processor transactions at the end of the reconciliation Closed Out Flag Indicates if the reconcihation is complete
Closed Out Date The date the reconcihation was completed
Date Added The date the row was added to the table
Reconciliation Associations Tb Reconcihation Code Unique code from Recondiiation Decode Tb used to identify the type of reconcihation being performed
Table Code Unique code from Reconcihation _Data_Tables_Tb used to identify tables used in the reconciliation
Process Order Indicates the order in which the tables should be processed Reconciliation Cleared Data Tb
Reconciliation Code Unique Code from Reconcihation Decode Tb used to identify the type of reconcihation being performed
Table Code Unique code from Reconcihation Data Tables Tb used to identify tables used in the reconcihation Row ID Record ID from the Original data table indicated by the
Table Code
Date Added The date the row was added to the table Reconciliation Data Tb
DataJD Uniquely identifies a summarized data row in the table
Batch JNTumber Batch JSFumber from Reconcihation_Tb which identifies the reconcihation
Table Code Table Code from Reconcihation Data Tables Tb used to identify where the data row came from
MerchantJNfumber Merchant Number used in the transaction Transaction Date Date the transaction took place Transaction Type Code Visa®, MasterCard®, Discover®, etc. Transaction_Gross_Amt Transaction gross amount Transaction JFee_Amt Fees associated with the transaction Transaction JSfet_Amt Net transaction amount (Gross - Fee = Net) Date Added Date the row was added to the table Reconciliation Data Matches Tb Data lD l Data _ID from Reconciliation )ata_Tb
Data J-D 2 Data ID from Reconciliation Data Tb
BatchJNumber BatchJMumber from ReconciliationJTb which identifies the reconciliation Reconciliation Data Tables Tb Table Code Unique table code used to identify tables used in the reconciliation
TableJSfame SQL table name of the table Description Description of the SQL table Starting_Procedure Procedure used to initialize the reconcihation for this table Ending JProcedure Procedure used to finalize the reconcihation for this table Reconciliation Decode Tb
Reconcihation Code Unique Code used to identify the type of reconciliation being performed
Description Description of the type of reconciliation AhJAccounts Flag Indicates the reconciliation includes all accounts, only a single row in this table can be marked as "True"
ReconeiliationJLocationsJTb
BatchJSfumber Controlling number for reconcihation, similar to a primary key, same as BatchJNumber in Reconciliations Tb
Merchant JPartner ID Points to a Merchant Record in Partners Tb
Reconciliation Matching Tb
Reconcihation Code Unique code from Reconcihation DecodeJLb used to identify the type of reconciliation being performed
Source Table Code l Unique Code from Reconciliation Data Tables Tb used to identify tables used in the reconcihation Source_Table_Code_2 Unique Code from Reconcihation JDataJTablesJTb used to identify tables used in the reconciliation Matching Procedure Procedure used to match data equal to Source_Table_Code_l and Source_Table_Code_2
Process Order Indicates the order in which the tables should be processed Reconciliation Report Data_Tb DataJD Uniquely identifies a summarized data row in the table
BatchJSTumber BatchJNumber from Reconciliation Ib which identifies the reconcihation
Table_Code Table Code from Reconcihation Data Table Tb used to identify where the data row came from Merchant JSfumber Merchant Number used in the transaction Transaction Date Date the transaction took place Transaction_Type_Code Visa®, MasterCard®, Discover®, etc. Transaction_Gross_Amt Transaction gross amount Transaction_Fee_Amt Fees associated with the transaction Transaction_Net_Amt Net transaction amount (Gross - Fee = Net) Date Added Date the row was added to the table
ReconciIiation_Report_ Matches Tb DataJDD l DataJD from Reconcihation Data Tb Data_ID_2 Data JDD from Reconcihation Data Tb BatchJSTumber Batch Nurnber from ReconciliationJIb which identifies the reconciliation
Terminals_Tb
Terminal_ID Uniquely identifies a credit card terminal TerminalJSTame Description of the terminal Merchant PartnerJ-D Partner JD in Partners fb which identifies a Merchant
Location Partner
Terminal_Type The type of terminal in use PrinterJType The type of printer the terminal is using, if any Purchased Leased Flag Indicates if the terminal is purchased or leased Monthly JFee_Amt Optional monthly fee associated with this terminal Date Added Date the row was added to the table Date Modified Date the row was last modified
Terminal Merchant Numbers Tb
TerminalJD Id from TerminalsJTb which uniquely identifies a credit card terminal
MerchantJNTumber Merchant Number from Merchant JNumbersJTb Date_Added Date the row was added to the table Date Modified Date the row was last modified Users Tb User ID Unique User ID, the User ID "SYSTEM' is a reserved User ID that is used for application settings and preferences, the
User JDD "SYSTEM' can not be assigned to a User.
PartnerJDD Associates the User to a Master Partner in the PartnersJTb
UserJMame Name or Description of the User
Department Department of the User
Email Address User's Email Address
PhoneJMumber User's Phone Number
RoleJD User's Security Role
Password User's Password
Date Added Date the row was added to the table
DateJVIodified Date the row was last modified
User_Accounts_Tb
User ID User ID setup in the UsersJTb
Bank_Account_ ID Bank Accounts assigned to the User from the
Bank_Accounts_Tb
Date_Added Date the row was added to the table User_Merchants_Tb
User_ID User ID setup in the UsersJTb
Merchant Partner ID Partner ID in Partners Tb which identifies a Merchant Location Partner
Date_Added Date the row was added to the table User Preference Tb
User_ID User ID setup in the UsersJTb, for system preferences/settings the UserJD is equal to "SYSTEM'
Section Section Parameter (like a windows .ini file) Keyword Keyword parameter (like a windows .ini file) Value The value of the user preference
Date_Added Date the row was added to the table Date Modified Date the row was last modified
Description of Numeric References No. Description
I . Software Object 1, a client software which may be a browser 3. Communication between Software Object 1 and Object 5 5. Object 5, an optional internet to intranet transition 7. Communication between Object 5 and Object 9 9. Object 9, an optional firewall which may be either hardware or software
II. Communication between Object 9 and Software Object 14
14. Software Object 14, the parent software object for software objects 16, 40, 20, 22, and 24
16. Data Object 16 is the database of the instant invention
20. Software Object 20 is the web server
22. Software Object 22 is the parent object for ah of the Web based Languages, Active server pages, Java, Active X controls, etc. 24. Software Object 24 is the parent software object for the software program of the instant invention
30. Software Object 30 is the parent software object for software objects 20, 22, and 24
32. Data Object 32, data from either POS software or from processor
34. Communication between Data Object 32 and Software Object 30 36. Data Object 36, bank account data that is being retrieved or transmitted
38. Communication between Data Object 36 and Software Object 30
40. Communication between Data Object 16 and Software Object 30
41. Communication between Data Object 45 and Software Object 30
42. Data Object 42, general ledger transactions from user's general ledger/legacy system 44. Communication between Data Object 42 and Software Object 30
45. Data Object 45-Referred to as data group "Other" throughout this document. This is a generic data object that can be added to the instant invention for configuration and reconcihation. For example; it may be necessary for a user to have both POS and processor files, therefore one of those two files would be placed in Data Object 45. The instant invention has been designed to provide reconcihation between any two or more set of data. The instant invention permits any number of data sets to be added to the reconcihation by the user 46. Communication from the merchant to Communication Object 50
48. Communication from the data provider to Communication Object 50
50. Communication Object 50, communicates the POS/Processor data, Bank data or
Other data gets into Data Object 52 52. Data Object 52, an intermediate data file which is hereinafter referred to as data file
"3A" 54. Communication Object 54, may be scheduled task or human intervention that starts
Software Object 56's operation
56. Software Object 56
58. Data Object 58, intermediate storage of data file "3 A" onto local LAN.
60, Communication Object 60, may be scheduled task or human intervention that starts
Software Object 60's operation
62. Software Object 62, opens input file "3 A" for processing
64 Software Object 64, checks to see if the end of file has occurred
66 Communication Line from Software Object 64 to Software Object 70 OR Software
Object 86, on the event end of file
68 Communication from Software Object 64 to Object 70; if not end of file
70 Software Object 70, reads next data record in file "3A"
72 Software Object 72, performs a selection case on reconciliation type
74 Communication from Software Object 72 to Software Object 80 on case data record is
Bank data 76. Communication from Software Object 72 to Software Object 82 on case data record is
POS/Processor data
78. Communication from Software Object 72 to Software Object 84 on case data record is Ledger/Legacy data
79. Communication from Software Object 72 to Software Object 87 on case data record is Other data
80. Software Object 80, execute an SQL Insert of Bank Adjustments into BankJTb 82. Software Object 82, execute an SQL Insert of POS data into ProcessorJTb 84. Software Object 84, execute an SQL Insert of Ledger Adjustment into LedgerJTb 85. Communication from Software Object 80 OR Software Object 82 OR Software Object 84 OR Software Object 87 to Software Object 64 86. Software Object 86, closes file "3A"
88. Software Object 88, archives the input file
90. Communication from User of selection of type of reconcihation (thus setting the
Reconcihation_Code) to perform and of bank account and other data sets to be reconciled to Software Object 97
95. Communication from User of Closing JDate and bank account number and
Reconciliation Code to Software Object 97 97. Software Object 97, initiates reconcihation upon User selection and input of choices for the type of reconcihation to perform (Reconcihation_Code set), the bank account and the ClosingJDate
100. Communication from Software Object 97 to Software Object 105 105. Software Object 105, initializes reconcihation by inserting data into the
Reconciliation Tb table and retrieving BatchJSfumber 110. Communication from Software Object 105 to Software Object 115 115. Software Object 115, creates a User screen for selection of merchant partner locations to be used in the reconcihation 120. Communication from Software Object 115 to Software Object 130 130 Software Object 130, gathers data for processing 135. Communication from Software Object 130 to Software Object 140 140. Software Object 140, performs first pass of reconcihation, a "simple match" of data 145. Communication from Software Object 140 to Software Object 150 150. Software Object 150, performs second pass of reconcihation, complex match 165. Communication from Software Object 150 to Software Object 170 170. Software Object 170, creates User input screen for manual matching and viewing of the data
175. Communication from Software Object 170 to Software Object 195 if "No"
190. Communication from User to Software Object 195, indicating "finished" with current reconciliation 195. Software Object 195, outputs communication to Software Object 220 OR Software Object 260 on case User selection
200. Communication from Software Object 195 to Software Object 260 on case User selection of "finished" 210 Communication from Software Object 195 to Software Object 220 on case User selection of NOT "finished" 220. Software Object 220, generates exception reports 230. Communication from User to Software Object 220 240. Communication from Software Object 220 to output of standard exception reports 250. Communication from Software Object 220 to output of User selected custom exception reports 260. Software Object 260, cleans up and archives database tables and marks all of the transaction that have been matched as cleared 265. Communication from Software Object 260 to Software Object 270 270. Software Object 270, generates reconciliation reports 280. Communication from User to Software Object 270
290. Communication from Software Object 260 to output of standard reconciliation reports 300. Communication from Software Object 260 to output of User selected custom reconcihation reports
310. Software Object 310, initializes an SQL insert into the Reconcihation Tb table. 320. Software Object 320, inserts the input parameters into the Reconcihation Tb and assigns a BatchJSTumber through an SQL Identity field 330. Software Object 330, retrieves the BatchJSTumber identity field from Reconcihation Tb
335. Software Object 335, retrieves the SQL Return Code making sure the insert of the input parameters into Reconcihation_Tb was successful 340. Software Object 340, a Child of Software Object 105, commits transaction 350. Software Object 350, a Child of Software Object 115, performs an SQL select from the UserJVIerchants Tb, selecting the merchants that are assigned to the bank account selected in Software Object 97 360. Software Object 360, generates a User screen to select locations 370. Communication from User to Software Object 380 of selections 380. Software Object 380, accepts User selections of location(s) or merchant partners (a Merchant Partner is a location)
390. Software Object 390, begins the transaction 400. Software Object 400, inserts User selected locations or merchant partners into the
Reconcihation Locations Tb 405. Software Object 405, retrieves the SQL Retμrn Codes making sure inserts into
Reconcihation JLocations Tb were successful 410. Software Object 410, a Child of Software Object 115, commits transaction
415. Software Object 415, a Child of Software Object 130, performs an SQL select using
BatchJSTumber to query the ReconciliationJTb to retrieve the User J-d, bank account number, Reconciliation Code and ClosingJDate, and saves the retrieved data in local variables 420. Software Object 420, performs an SQL select using the Reconcihation_Code and creates a cursor selecting all the selected tables used in this reconciliation from the
Reconcihation Associations Tb. This table deteπnines what tables are referenced in this reconcihation. 430. Software Object 430, performs a check verifying that the cursor is not empty, that there is data in it
440. Communication from Software Object 430 to Software Object 490 in the case that the cursor is empty 450. Communication from Software Object 430 to Software Object 460 in the case that the cursor is not empty 460. Software Object 460, retrieves the next row from the cursor
470. Software Object 470, performs SQL select on the Reconcihation Data Tables Tb and retrieves the Starting Procedure for the current Table_Code retrieved from the cursor by Software Object 460 475. Communication from Software Object 470 to Software Object 480 480. Software Object 480, executes the StartingJProcedure with data retrieved by Software
Object 470 485. Communication from Software Object 515 OR 580 OR 640 OR 700 to Software
Object 430 490. Software Object 490, a Child of Software Object 130, closes cursor 500. Software Object 500, performs a selection case on input parameter 1 (which equals the Table_Code) 505. Communication from Software Object 500 to Software Object 515 on the case that
Other Table_Code is the input parameter 510. Communication from Software Object 500 to Software Object 535 on the case that
Bank Table_Code is the input parameter 515. Software Object 515, present if Other data types are selected to be reconciled
520. Communication from Software Object 500 to Software Object 590 on the case that
POS Table_Code is the input parameter 530. Communication from Software Object 500 to Software Object 650 on the case that
Ledger Table Code is the input parameter 535. Software Object 535, queries the database for User_Id, Partner Id,
Reconcihation Code, Bank Account and the Closing Date from the
Reconcihation Tb table 540. Software Object 540, initializes transaction 545. Communication from Software Object 540 to Software Object 550 550. Software Object 550, resets working tables for reconciliation, passing the Table_Code and BatchJSTumber to Software Object 560 OR Software Object 620 OR Software
Object 680 on case Input Parameter to Software Object 550 555. Communication from Software Object 550 to Software Object 560 560, Software Object 560, executes an SQL insertion of bank data joining on the tables Reconcihation Cleared Data Tb,
MerchantjSTumbers_Tb, ReconcihationJ ocationsJTb, and Bank Ib table
And then inserts the data into Reconcihation Data Tb 570. Software Object 570, retrieves SQL return code and checks status 580. Software Object 580, Commits transaction 590. Software Object 590, queries the database for User ld, Partner ld, the
Reconcihation Code, bank account and the Closing Date from the Reconcihation Tb table using the current BatchJSTumber 600. Software Object 600, initializes transaction
605. Communication from Software Object 600 to Software Object 550 615. Communication from Software Object 550 to Software Object 620 620. Software Object 620, executes an SQL insert of POS data into the
Reconcihation Data Tb joining on the following tables:
Reconcihation_Cleared_Data_Tb,
MerchantJSTumbersJTb, Reconcihation_Locations_Tb,
MerchantJSTumber_Bank_Account_bv, and Processor Tb.
630. Software Object 630, retrieves the SQL return code and checks status. 640. Software Object 640, commits transaction 650. Software Object 650, queries the database for UserJ-d, PartnerJ-d, the
Reconcihation Code, bank account and the Closing Date from the Reconcihation Tb table 660. Software Object 660, initializes transaction 665. Communication from Software Object 660 to Software Object 550 675. Communication from Software Object 550 to Software Object 680 680. Software Object 680, executes SQL insert of Ledger data into the
Reconcihcation Data _Tb joining on the following tables: Reconcihation Cleared Data Tb, MerchantJSTumbersJTb, Reconcihation Locations Tb,
MerchantJSTumber_Bank_Account_Tb, and Ledger Tb
690. Software Object 690, retrieves the SQL return code and checks status. 700. Software Object 700, commits transaction 800. Software Object 800, queries the database for UserJ-d, Partner ld, the
Reconcihation Code, bank account and the Closing Date from the Reconcihation Tb table using the current BatchJSTumber 805. Software Object 805, performs an SQL select on the Reconcihation Matching Tb 810. Software Object 810, performs an end of file check on the cursor 820. Communication from Software Object 810 to Software Object 860 if EOF
830. Communication from Software Object 810 to Software Object 840 if NOT EOF 840. Software Object 840, gets next data row from cursor 845. Communication from Software Object 840 to Software Object 850.
850. Software Object 850, executes "simple match" on the dynamic stream of data that is built out of Software Object 840 data 855. Communication from Software Object 850 to Software Object 810 860. Software Object 860, a Child of Software Object 140, closes cursor 870. Software Object 870, initializes transaction 875. Software Object 875, executes an SQL insert of matching data rows into
Reconcihation JDataJVIatchesJTb 880. Software Object 880, retrieves the SQL Return Code 885. Software Object 885, performs an SQL Insert into Reconciliation_Data_Matches_Tb 890. Software Object 890, retrieves the SQL Return Code 895. Software Object 895, commits transaction 900. Software Object 900, a Child of Software Object 150, creates a cursor by querying the
Reconcihation JVIatching Tb table, selecting the Source_Table_Code_l and Source_Table_Code_2 using the current Reconcihation Code of the reconciliation being performed 910. Software Object 910, checks for end of file. 920. Communication from Software Object 910 to Object 935 if EOF 930. Communication from Software Object 910 to Object 940 if NOT EOF 935. Software Object 935, a Child of Software Object 150, closes cursor
940. Software Object 940, gets row from the cursor set which is Source Table Code l and Source_Table_Code_2 945. Communication from Software Object 940 to Software Object 950. 950. Software Object 950, executes the complex match 955. Communication from Software Object 950 to Software Object 10
1000. Software Object 1000, Creates data cursor "13A" by doing an SQL select on the database to retrieve all rows equal to Source_Table_Code_2 from
Reconcihation Data Tb where there is no match in
Reconcihation Data Matches Tb for SourceJTable Code l 1010. Software Object 1010, creates data set "13C" by taking all unique combinations of rows from cursor "13A" 1020. Software Object 1020, creates data cursor "13B" by doing an SQL select on the database to retrieve ah rows equal to Source_Table_Code_l from
Reconcihation Data Tb where there is no match in
Reconcihation_DataJVIatches_Tb for Source_Table_Code_2 1030. Software Object 1030, sets the date range for comparisons 1040. Software Object 1040, checks cursor "13B" for EOF
1050. Communication from Software Object 1040 to Software Object 1060 if NOT EOF 1060. Software Object 1060, gets the next row of data in cursor "13B" containing the
BatchJSTumber, MerchantJSTumber, Transaction Date, Transaction_Type_Code, gross, net and fee amounts and attempts to match that data against data objects in data collection "13C" 1070. Software Object 1070, sets up local variables; sets the Match Counter = 0, sets Match
Index = 0, sets Loop Counter = 0 1080. Software Object 1080, increments the Loop Counter by one 1090. Software Object 1090, checks the Loop Counter to make sure it is less than or equal to the number of data objects in data collection "13C" 1100. Communication from Software Object 1090 to Software Object 1200 if Software
Object 1090 output is Yes 1110. Communication from Software Object 1090 to Software Object 1120 if Software Object 1090 output is No
1120. Software Object 1120, check for Match Counter equal to one
1130. Communication from Software Object 1120 to Software Object 1150 if Software
Object 1120 output is YES 1140. Communication from Software Object 1120 to Software Object 1040 if Software Object 1120 output is NO
1150. Software Object 1150, executes an SQL Insert into Reconcihation Data Matches Tb using the Data lD from the current row in cursor "13B" and the DataJD from data row(s) contained in the data object found at the Match Index in data collection "13C" 1160. Software Object 1160, removes the data object found at Match Index from Data Collection "13C"
1170. Communication from Software Object 1220 to Software Object 1080 if Date Range check failed 1180. Communication from Software Object 1240 to Software Object 1080 if comparison fails 1190. Communication from Software Object 1270 to Software Object 1080 1200. Software Object 1200, gets data object "13D" from Data Collection "13C". 1220. Software Object 1220, uses Date Range set in Object 1030 to check all rows used to create data object "13D" 1230. Communication from Software Object 1220 to Software Object 1240 if Date Range check passed 1240. Software Object 1240, compares the Merchant JSTumber, Transaction_Type_Code, net, gross, and fee amounts of data object "13D" to the corresponding fields of the current row in cursor "13B" 1250. Communication from Software Object 1240 to Software Object 1260 if comparison passes 1260. Software Object 1260, ,increments the Match Counter by one 1270. Software Object 1270, sets the Match Index equal to the Loop Counter
1300. Software Object 1300, a Child of Software Object 260, executes an SQL select to obtain User D, Bank Account JSTumber, and Reconcihation Code from
Reconcihation Tb 1305. Software Object 1305, initializes transaction 1310. Software Object 1310, performs an SQL Insert to copy data from
Reconcihation Data Tb to Reconcihation_Report_Data_Tb 1315. Software Object 1315, retrieves SQL Return Code 1320. Software Object 1320, performs an SQL Insert to copy data from
Reconcihation Data Matches Tb to Reconcihation Report Matches Tb. 1325. Software Object 1325, retrieves SQL Return Code 1330. Software Object 1330, commits transaction 1335. Software Object 1335, builds a cursor on execution of an SQL Select from
Reconcihation Associations Tb 1340. Software Object 1340, checks for EOF 1350. Commumcation from Software Object 1340 to Software Object 1400 if EOF
1360. Communication from Software Object 1340 to Software Object 1370 if NOT EOF 1370. Software Object 1370, gets next Table Code from the cursor 1380. Software Object 1380, executes an SQL select from Reconciliation Data Tables Tb retailing the Ending_Procedure name for the Table_Code in the current row of the cursor 1385. Communication from Software Object 1380 to Software Object 1390 1390. Software Object 1390, executes the EndingJProcedure queried in Software Object
1380 1395. Communication Software Object 1390 to Software Object 1340 1400. Software Object 1400, closes cursor 1405. Software Object 1405, initializes transaction 1410. Communication from Software Object 1405 to Software Object 550 1425. Communication from Software Object 550 to Software Object 1430 1430. Software Object 1430, updates the Reconcihation_Tb table updating closed flag and the date completed reconcihation 1440. Software Object 1440, a Child of Software Object 260, commits transaction 1500. Software Object 1500, selects output path based on the input parameter, a Table Code 1505 Communication from Software Object 1500 to Software Object 1515 if the
Table Code is Other 1510. Communication from Software Object 1500 to Software Object 1540 if the
Table Code is Bank 1515 Software Object 1515 handles future ("Other") data types
1520. Communication Software Object 1500 to Software Object 1610 if the Table_Code is
POS 1530. Communication from Software Object 1500 to Software Object 1680 if the
Table Code is Ledger. 1540. Software Object 1540, executes an SQL Select Set-Local Variables
1550. Software Object 1550, executes an SQL select on the Reconcihation Data Tb table summing up transaction net amount for the current BatchJSTumber and Table_Code 1560. Software Object 1560, initializes transaction
1570. Software Object 1570, executes an SQL Update on ReconciliationJTb table 1575. Software Object 1575, retrieves the SQL Return Code
1580. Software Object 1580, executes an SQL Insert using the Reconcihation Data Tb table, join to the Reconcihation_Data_Matches_Tb table and Bank Tb table; inserting all Bank JDDs from the Bank Tb matched during the reconciliation into the
Reconcihation Cleared Data Tb 1590. Software Object 1590, retrieves the SQL Return Code 1600. Software Object 1600, commits transaction 1610. Software Object 1610, executes an SQL Select on Reconcihation Tb
1620. Software Object 1620, executes an SQL Select on the Reconcihation Data Tb table summing up transaction net amount for the current BatchJSTumber and Table_Code 1630. Software Object 1630, initializes transaction
1640. Software Object 1640, performs an SQL Update setting the ReconcihationJTb table processor batch ending amount equal to reconciliation amount in Software Object
1620 1645. Software Object 1645, retrieves the SQL Return Code 1650. Software Object 1650, executes an SQL insert using the Reconcihation _Data_Tb table, join to the Reconciliation DataJVIatches Tb table and Processor Tb table; inserting all Processor Ds from the Processor Tb matched during the reconciliation into the Reconcihation Cleared Data Tb 1660. Software Object 1660, retrieves the SQL Return Code 1670. Software Object 1670, commits transaction
1680. Software Object 1680, executes an SQL Select for current BatchJSTumber 1690. Software Object 1690, executes an SQL Select on the Reconcihation Data Tb table summing up transaction net amount for the current BatchJNumber and Table_Code 1700. Software Object 1700, initializes transaction 1710. Software Object 1710, executes an SQL Update to the reconcihation table; setting ledger batch ending amount equal to local variable reconcihation amount for current variable for current BatchJSTumber
1715. Software Object 1715, retrieves the SQL Return Code
1720. Software Object 1720, executes an SQL Insert using the Reconcihation _Data_Tb table, join to the Reconcihation Data Matches Tb table and Ledger Tb table; inserting all LedgerJDs from the Ledger Tb matched during the reconcihation into the Reconciliation_Cleared_Data_Tb
1730. Software Object 1730, retrieves the SQL Return Code 1800. Software Object 1800, performs OR function 1805. Software Object 1805, initializes transaction
1810. Software Object 1810, checks the parameter received to determine if the Table_Code parameter is Null 1820. Communication from Software Object 1810 to Software Object 1840 if Null
1830. Communication from Software Object 1810 to Software Object 1860 if NOT Null 1840. Software Object 1840, executes an SQL Delete on Reconcihation Data Matches Tb for current BatchJSTumber 1845, Software Object 1845, retrieves the SQL Return Code 1850. Software Object 1850, executes an SQL Delete on Reconcihation JData Tb for current BatchJSTumber 1855. Software Object 1855, retrieves the SQL Return Code
1860. Software Object 1860, executes an SQL Delete on Reconcihation_DataJVIatches_Tb joining to Reconcihation Data Tb deleting the current BatchJSTumber for the current Table_Code
1862. Software Object 1862, retrieves the SQL Return Code
1864. Software Object 1864, deletes rows from Reconciliation JVIatches Tb by joining to Reconcihation Data Tb on DataJD equal to Data_ϋ)_2 and current BatchJSTumber and Table Code 1866. Software Object 1866, retrieves the SQL Return Code
1870. Software Object 1870, Executes an SQL Delete on Reconciliation J)ata_Tb for current BatchJSTumber and Table_Code 1875. Software Object 1875, retrieves the SQL Return Code 1880. Software Object 1880, commits transaction 1890. Software Object 1890, selects output communication path according to communication path utilized by input, as follows: If input on 545 exit on 555
If input on 605 exit on 615
If input on 665 exit on 675 If input on 1410 exit on 1425
2000. Communication from User into Software Object 2010
2010. Software Object 2010, User selection of input screen for Bank data. 2015. Communication from User into Software Object 2020
2020. Software Object 2020, accepts User input of Bank data
2030. Software Object 2030, determine which button the user hit. "Save" or "Cancel"
2050. Communication from Software Object 2030 to Software Object 2080 if "Cancel" 2040. Communication from Software Object 2030 to Software Object 80 if "Save"
2070. Communication from Software Object 80 to Software Object 2080
2080. Software Object 2080, closes input screen
2100. Communication from User into Software Object 2110
2110. Software Object 2110, User selection of input screen for POS data. 2115. Communication from User into Software Object 2120
2120. Software Object 2120, accepts User input of POS data
2130. Software Object 2130, determine which button the user hit. "Save" or "Cancel"
2150. Communication from Software Object 2130 to Software Object 2180 if "Cancel"
2140. Communication from Software Object 2130 to Software Object 82 if "Save" 2170. Communication from Software Object 82 to Software Object 2180
2180. Software Object 2180, closes input screen
2200. Communication from User into Software Object 2210
2210. Software Object 2210, User selection of input screen for Ledger data.
2215. Communication from User into Software Object 2220 2220. Software Object 2220, accepts User input of Ledger data
2230. Software Object 2230, deteπnine which button the user hit. "Save" or "Cancel"
2240. Communication from Software Object 2230 to Software Object 84 if "Save"
2250. Communication from Software Object 2230 to Software Object 2280 if "Cancel"
2270. Communication from Software Object 84 to Software Object 2280 2280. Software Object 2280, closes input screen
3000. Communication from User of New Merchant Setup selection
3005. Communication from User to Software Object 3010
3010. Software Object 3010, creates an input screen for User and asks whether this is a new Merchant Partner 3020. Communication from Software Object 3010 to Software Object 3040 if 'Υes"
3030. Communication from Software Object 3010 to Software Object 3050 if "No"
3040. Software Object 3040, creates new Partner in Database 3045. Communication from Software Object 3040 to Software Object 3050
3050. Software Object 3050, creates an input screen for User to select existing Merchant
Partner; if new Partner is added it will be auto selected 3055. Communication from User to Software Object 3050 3060. Software Object 3060, creates an input screen for User and asks whether this is a new agreement 3065. Communication from User to Software Object 3060
3070. Communication from Software Object 3060 to Software Object 3090 if 'Υes" 3080. Communication from Software Object 3060 to Software Object 3100 if "No" 3090. Software Object 3090, creates new agreement
3095. Communication from Software Object 3090 to Software Object 3100
3100. Software Object 3100, creates an input screen for User to select Agreement form; if new Agreement is added it will be auto selected 3105. Communication from User to Software Object 3100 3110. Software Object 3110, creates an input screen for User to set up new terminals 3115. Communication from User to Software Object 3110
3120. Communication from Software Object 3110 to Software Object 3140 if "Yes" 3130. Communication from Software Object 3110 to Software Object 3150 if "No" 3140. Software Object 3140, creates new terminal 3145. Communication from Software Object 3140 to Software Object 3150
3150. Software Object 3150, creates an input screen for User to select terminal; if user setup new terminal it will be automatically selected; otherwise select from a list of terminals already in the database for this Merchant Partner 3155. Communication from User to Software Object 3150 3160. Communication from Software Object 3150 to Software Object 5600
3170. Software Object 3170, creates an input screen for User and asks whether this is a new
MerchantJSTumber 3175. Communication from User to Software Object 3170
3180. Commumcation from Software Object 3170 to Software Object 3200 if "Yes" 3190. Communication from Software Object 3170 to Software Object 3210 if "No" 3195. Communication from User to Software Object 3210 3200. Software Object 3200, creates new MerchantJSTumber 3205. Communication from Software Object 3200 to Software Object 3210 3210. Software Object 3210, creates an input screen for User to select MerchantJSTumber 3215. Communication from Software Object 3210 to Software Object 3220 3220. Software Object 3220, associates MerchantJSTumber, with the terminal, with the Merchant Partner number, with the Bank account and with the Ledger and performs a series of SQL inserts 3225. Commumcation from Software Object 3220 to Software Object 3230 3230. Software Object 3230, creates an input screen for User and asks whether more merchant numbers need to be added to this terminal 3235. Communication from User to Software Object 3230
3240. Communication from Software Object 3230 to Software Object 3170 if "Yes" 3250. Communication from Software Object 3230 to Software Object 3260 if "No" 3260. Software Object 3260, creates an input screen for User and asks whether more terminals for same Merchant Partner 3265. Communication from User to Software Object 3260
3270. Communication from Software Object 3260 to Software Object 3110 if "Yes" 3280. Communication from Software Object 3260 to Software Object 3290 if "No" 3290. Software Object 3290, creates an input screen for User and asks whether setting up more Merchant Partners 3295. Communication from User to Software Object 3290
3300. Commumcation from Software Object 3290 to Software Object 3010 if 'Υes" 3310. Commumcation from Software Object 3290 to Software Object 3320 if "No" 3700. Software Object 3700, accepts input from communication 74 OR 2040 OR 4560 3710. Software Object 3710, uses MerchantJSTumber provided in the Bank data to do a SQL Select on Merchant JSTumbersJTb joining to Merchants Tb; retrieving the
Agreement D 3720. Software Object 3720, queries AgreementsJTb and Agreement_Rates_Tb to setup local variables with the discount rates and transaction fees for the agreement found in
Software Object 3710 3730. Software Object 3730, utilizes the local variables setup in Software Object 3720 to calculate the gross, net and fee amounts for the Bank data 3740. Software Object 3740, initializes transaction 3750. Software Object 3750, executes an SQL Insert into BankJTb 3760. Software Object 3760, retrieves the SQL Return Code 3770. Software Object 3770, commits the transaction
3780. Software Object 3780, a Child of Software Object 80, selects output communication path according to commumcation path utilized by input, as follows:
If entered on Communication 74 exit Communication 85
If entered on Communication 2040 exit Communication 2070
If entered on Communication 4560 exit Communication 4600
3800. Software Object 3800, accepts input from communication 76 OR 2140 OR 4570 3810. Software Object 3810, looks up MerchantJSTumber in MerchantJSTumbersJTb gets
Merchants Partner ID; looks up Agreement !!) in Merchants Tb for the current agreement being used by this merchant - then assigns to local variable 3820. Software Object 3820, queries AgreementsJTb and Agreement_Rates_Tb to setup local variables with the discount rates and transaction fees for the agreement found in Software Object 3810
3830. Software Object 3830, uses the local variable created by Software Object 3820 to calculate the gross, net and fee amounts for the POS data 3840. Software Object 3840, initializes transaction 3850. Software Object 3850, executes a SQL Insert into ProcessorJTb 3860. Software Object 3860, retrieves the SQL Return Code 3870. Software Object 3870, commits transaction , 3880. Software Object 3880, a Child of Software Object 82, selects output communication path according to communication path utilized by input, as follows: If entered via Communication 76 exit via Communication 85 If entered via Communication 2140 exit via Communication 2170
If entered via Communication 4570 exit via Commumcation 4630
3900. Software Object 3900, accepts input from commumcation 78 OR 2240 OR 4580 3910. Software Object 3910, performs join on MerchantJ-,edger_Account_Tb by looking up MerchantJSTumber and ledger account number and joining to Merchant JSTumbersJTb to find Merchant_PartnerJDD and then to MerchantsJTb to get the Agreement JD and stores result in a local variable 3920. Software Object 3920, queries AgreementsJTb and Agreement_Rates_Tb to setup local variables with the discount rates and transaction fees for the agreement found in
Software Object 3910 3930. Software Object 3930, uses the local variable created by Software Object 3920 to calculate the gross, net and fee amounts for the Ledger data
3940. Software Object 3940, initializes transaction 3950. Software Object 3950, executes a SQL Insert into LedgerJTb 3960. Software Object 3960, retrieves the SQL Return Code 3970. Software Object 3970, commits transaction 3980. Software Object 3980, a Child of Software Object 84, selects output communication path according to communication path utilized by input, as follows: If entered via Communication 78 exit via Communication 85
If entered via Communication 2240 exit via Communication 2270
If entered via Communication 4580 exit via Communication 4660 4000. Software Object 4000, a Child of Software Object 170, creates User reconcihation screen 4005. Communication from User to Software Object 4010 4010. Software Object 4010, User selects which of the two accounts to compare on the screen 4020. Software Object 4020, takes the first of the two accounts selected in Software Object
4010 and performs an SQL Select on Reconcihation Data Tb and
Reconcihation_DataJVIatches_Tb 4030. Software Object 4030, displays on screen the rows Selected in Software Object 4020 4040. Software Object 4040, takes the second of the two accounts selected in Software Object 4010 and performs an SQL Select on Reconcihation Data Tb and
Reconciliation )ataJVIatches_Tb 4050. Software Object 4050, displays the rows Selected in Software Object 4040 4060. Software Object 4060, displays inquiry asking User if "finished" 4070. Communication from User to Software Object 4060 4080. Commumcation from Software Object 4060 to Software Object 4100 if "Yes" 4090. Communication from Software Object 4060 to Software Object 4130 if "No" 4100. Software Object 4100, a Child of Software Object 170, displays User option to reconcile another set of accounts in this session 4110. Communication from Software Object 4100 to Software Object 4010 if "Yes" 4120. Communication from User to Software Object 4100 4130. Software Object 4130, creates screen for User to elect to set options, viewing options and filters 4135. Communication from User to Software Object 4130
4140. Commumcation from Software Object 4130 to Software Object 4270 if "Yes" 4150. Communication from Software Object 4130 to Software Object 4160 if "No" 4160. Software Object 4160, creates screen to display User's option to enter adjustments 4170. Communication from User to Software Object 4160
4180. Communication from Software Object 4160 to Software Object 4200 if "Yes" 4190. Communication from Software Object 4160 to Software Object 4210 if "No" 4200. Software Object 4200, creates User Adjustment screen 4210. Software Object 4210, creates screen providing User the option of manually matching/reconciling between data rows in two displayed accounts 4215. Communication from User to Software Object 4210 4220. Software Object 4220, creates screen for User to update the rows matched in Software
Object 4210. 4225. Communication from User to Software Object 4220 4230. Software Object 4230, initializes transaction 4240. Software Object 4240, executes SQL inserts on Reconciliation )ata_Matches_Tb; inserting the Data Ds from the rows that were manually matched by the User in
Software Object 4210 4250. Software Object 4250, retrieves the SQL Return Code 4260. Software Object 4260, commits transaction 4270. Software Object 4270, creates display of User options available and communicates
User selected options to Software Object 4020 4280. Communication from User to Software Object 4270 4290. Communication from Software 4260 OR Software Object 4200 to Software Object
4020 4500. Software Object 4500, a Child of Software Object 4200, creates User Adjustment screen 4505. Communication from User to Software Object 4510
4510. Software Object 4510, displays User Adjustment screen and accepts User input 4520. Software Object 4520 sets commumcation path on case User selects "Save" or
"Cancel" 4530. Communication from Software Object 4520 to Software Object 4550 if "Save" 4540. Communication from Software Object 4520 to Software Object 4290 if "Cancel" 4550. Software Object 4550, sets communication path on case = data type: Other output to Communication 4555
Bank output to Communication 4560
POS output to Communication 4570
Ledger output to Communication 4580
4555. Communication from Software Object 4550 to Software Object 4690 on "Other" 4560. Communication from Software Object 4550 to Software Object 80 on 'Ηank" 4570. Communication from Software Object 4550 to Software Object 82 on "POS" 4580. Communication from Software Object 4550 to Software Object 84 on "Ledger" 4600. Communication from Software Object 80 to Software Object 4610 4610. Software Object 4610, execute an SQL Update of Reconcihation Data Tb for the MerchantJSTumber, date and time and Transaction Type Code of the User adjustment 4630. Communication from Software Object 82 to Software Object 4640 4640. Software Object 4640, execute an SQL Update of Reconciliation J)ata_Tb for the
MerchantJSTumber, date and time and Transaction Type Code of the User adjustment
4660. Communication from Software Object 84 to Software Object 4670
4670. Software Object 4670, execute an SQL update of Reconcihation Data Tb for the
MerchantJSTumber, date and time and Transaction_Type_Code of the User adjustment 4680. Software Object 4680, a Child of Software Object 4200, closes screen
4690. Software Object 4690, insert and update "Other" data then communicate to Software
Object 4680 5000. Software Object 5000, a Child of Software Object 3040, receives Communication from Communication 3020 OR Communication 5002 OR Communication 5115 5002. User Input (User Request) 5005. Software Object 5005, create Partner setup screen 5010. Software Object 5010, accepts User input of data 5015. Commumcation from User to Software Object 5010,
5020. Software Object 5020, selects Communication path on case="Save" or "Cancel" 5030. Communication from Software Object 5020 to Software Object 5060 on "Cancel" 5040. Commumcation from Software Object 5020 to Software Object 5050 on "Save" 5050. Software Object 5050, execute an SQL Insert of Partner data
5055. Communication from Software Object 5050 to Software Object 5060 5060. Software Object 5060, closes input screen
5070. Software Object 5070, selects output Communication path on case = input, as: If entered via Communication 3020 exit via Communication 3045 If entered via Communication 5115 exit via Communication 5125
5100. Software Object 5100, a Child of Software Object 3090, displays User Agreement setup screen 5105. Software Object 5105, creates screen to query User whether to set up new Processor Partner 5110. Communication from User to Software Object 5105
5115. Communication from Software Object 5105 to Software Object 3040 if "Yes"
5125. Communication from Software Object 3040 to Software Object 5135
5130. Communication from Software Object 5105 to Software Object 5135 if "No"
5135. Software Object 5135, creates screen for User selection from hst of processor partners available or if a new processor partner was entered it will be automatically selected
5140. Communication from User to Software Object 5135 5145. Software Object 5145, creates screen for User input of Agreement data 5150. Communication from User to Software Object 5145 5155. Software Object 5155, selects Communication path on case = "Save" or "Cancel" 5160. Communication from Software Object 5155 to Software Object 5170 if "Save" 5165. Communication from Software Object 5155 to Software Object 5190 if "Cancel" 5170. Software Object 5170, executes an SQL Insert on input data into Agreements JTb 5175. Communication from Software Object 5170 to Software Object 5180
5180. Software Object 5180, creates screen for User to input rate(s) for new agreement
5185. Communication from Software Object 5180 to Software Object 5190
5190. Software Object 5190, close input screen 5200. Software Object 5200, creates Terminal setup screen
5205. Communication from User to Software Object 5210
5210. Software Object 5210, accepts User data inputs
5220. Software Object 5220, selects Communication path on case = "Save" or "Cancel"
5230. Communication from Software Object 5220 to Software Object 5260 if "Cancel" 5240. Communication from Software Object 5220 to Software Object 5250 if "Save"
5250. Software Object 5250, executes an SQL Insert on input data from Software Object 5210 into Terminals Tb
5260. Software Object 5260, closes input screen
5300. Software Object 5300, a Child of Software Object 3200, creates the screen to setup MerchantJSTumber.
5310. Software Object 5310, accepts User input of data
5315. Communication from User to Software Object 5310
5320. Software Object 5320, selects Commumcation path on case = "Save" or "Cancel"
5330. Communication from Software Object 5320 to Software Object 5370 if "Cancel" 5340. Communication from Software Object 5320 to Software Object 5350 if "Save"
5350. Software Object 5350, execute an SQL Insert of input data from Software Object 5310 into Merchant JSTumbers Tb
5360. Communication from Software Object 5350 to Software Object 5370
5370. Software Object 5370, closes input screen 5400. Software Object 5400, a Child of Software Object 5050, initializes transaction
5410. Software Object 5410, executes an SQL Insert of Partner data into PartnersJTb
5420. Software Object 5420, retrieves the SQL Return Code
5430. Software Object 5430, executes an SQL Insert into PartnerJJierarchy_Tb
5440. Software Object 5440, retrieves the SQL Return Code 5450. Software Object 5450, a Child of Software Object 5050, commits transaction to associate the MerchantJSTumber to the terminal; performed by inserting the Terminal_ID selected and the MerchantJSTumber selected into Terminal JVIerchantJSTumbers_Tb 5520. Software Object 5520, retrieves the SQL Return Code
5530. Software Object 5530, executes an SQL Insert into Merchant_Bank_Account_Tb
5540. Software Object 5540, retrieves the SQL Return Code
5550. Software Object 5550, executes an SQL Insert into Merchant J edger_Account_Tb
5560. Software Object 5560, retrieves the SQL Return Code 5570. Software Object 5570, commits the transaction
5600. Software Object 5600, creates an input screen for User and asks whether this is a new Bank account
5605. Communication from User to Software Object 5600
5610. Communication from Software Object 5600 to Software Object 5630 if "Yes" 5620. Communication from Software Object 5600 to Software Object 5650 if "No"
5630. Software Object 5630, creates new bank account
5640. Communication from Software Object 5630 to Software Object 5650
5650. Software Object 5650, creates an input screen for User to select Bank account
5655. Communication from User to Software Object 5650 5660. Software Object 5660, creates an input screen for User and asks whether this is a new Ledger account
5665. Communication from User to Software Object 5660
5670. Commumcation from Software Object 5660 to Software Object 5690 if "Yes"
5680. Communication from Software Object 5660 to Software Object 5710 if "No" 5690. Software Object 5690, creates new ledger account
5700. Communication from Software Object 5690 to Software Object 5710
5710. Software Object 5710, creates an input screen for User to select Ledger account
5715. Communication from User to Software Object 5710
6000. Software Object 6000, a Child of Software Object 5630, creates Bank account setup screen
6010. Software Object 6010, accepts User input data
6020. Communication from User to Software Object 6010 6030. Software Object 6030, selects Commumcation path on case = "Save" or "Cancel"
6040. Communication from Software Object 6030 to Software Object 6060 if "Save"
6050. Commumcation from Software Object 6030 to Software Object 6080 if "Cancel"
6060 Software Object 6060, executes an SQL Insert of Bank Account data input by User 6070. Communication from Software Object 6060 to Software Object 6080
6080. Software Object 6080, a Child of Software Object 5630, closes input screen
6100. Software Object 6100, initializes transaction
6110. Software Object 6110, executes an SQL Insert into Bank Accounts Tb of new Bank Account data 6120. Software Object 6120, retrieves the SQL Return Code
6130. Software Object 6130, executes an SQL Insert into User_Accounts_Tb table to associate the new bank account with the user
6140. Software Object 6140, retrieves the SQL Return Code
6150. Software Object 6150, commits the transaction 6200. Software Object 6200, creates Ledger set up screen
6210. Software Object 6210, accepts User input of Ledger Account data
6220. Communication from User to Software Object 6210
6230. Software Object 6230, selects Commumcation path on case = "Save" or "Cancel"
6240. Commumcation from Software Object 6230 to Software Object 6260 if "Save" 6250. Commumcation from Software Object 6230 to Software Object 6280 if "Cancel"
6260. Software Object 6260, executes an SQL Insert of Ledger data input into Software Object 6210 into Ledger_Accounts_Tb
6270. Communication from Software Object 6260 to Software Object 6280
6280. Software Object 6280, closes input screen 6300. Software Object 6300, a Child of Software Object 5180, creates Rate screen for User setup of processor rates
6310. Software Object 6310, accepts User input of rate data
6320. Communication from User to Software Object 6310
6330. Software Object 6330, selects Communication path on case = "Save" or "Cancel" 6340. Communication from Software Object 6330 to Software Object 6410 if "Cancel"
6350. Commumcation from Software Object 6330 to Software Object 6360 if "Save" 6360. Software Object 6360, executes an SQL Insert into Agreement Jlates fb associating the new rate with the processor agreement inserted in Software Object 5170.
6370. Software Object 6370, creates screen to query User whether to enter additional rates and selects Communication path on case = "Yes" or "No"
6371. User Input to software object 6370
6380. Communication from Software Object 6370 to Software Object 6400 if "Yes"
6390. Communication from Software Object 6370 to Software Object 6410 if "No"
6400 Software Object 6400, clears input screen for new rate
6410. Software Object 6410, a Child of Software Object 5180, closes input screen
6500. Communication from User to Software Object 6510
6510. Software Object 6510, creates New User setup screen
6520. Software Object 6520, accepts User input of new user data
6530. Communication from User to Software Object 6520
6540. Software Object 6540, selects Communication path on case = "Save" or "Cancel"
6550. Communication from Software Object 6540 to Software Object 6570 if "Save"
6560. Communication from Software Object 6540 to Software Object 6610 if "Cancel"
6570. Software Object 6570, initialize transaction
6580. Software Object 6580, executes an SQL Insert of data input into Software Object
6520 into UsersJTb
6590. Software Object 6590, retrieves the SQL Return Code
6600. Software Object 6600, commits the transaction
6610. Software Object 6610, closes input screen
6700. Communication from User to Software Object 6710
6710. Software Object 6710, creates User Bank Account selection screen
6720. Software Object 6720, accepts User selection of bank account(s)
6730. Communication from User to Software Object 6720
6740. Software Object 6740, selects Communication path on case = "Save" or "Cancel"
6750. Communication from Software Object 6740 to Software Object 6770 if "Save"
6760. Communication from Software Object 6740 to Software Object 6810 if "Cancel"
6770. Software Object 6770, initialize transaction
6775. Software Object 6775, executes an SQL delete(s) to remove Bank Accounts not selected in Software Object 6720 from User_Aceounts_Tb 6780. Software Object 6780, executes SQL Inserts of UserJTD and selected Bank_Account_π) into the User_Accounts_Tb table
6790. Software Object 6790, retrieves the SQL Return Code
6800. Software Object 6800, commits the transaction 6810. Software Object 6810, closes input screen
6850. Communication from User to Software Object 6860
6860. Software Object 6860, creates Merchant Partner/User Association screen
6870. Software Object 6870, User selects Merchant Partner(s) to be associated
6880. Communication from User to Software Object 6870 6890. Software Object 6890, selects Communication path on case = "Save" or "Cancel"
7000. Communication from Software Object 6890 to Software Object 7020 if "Save"
7010. Communication from Software Object 6890 to Software Object 7060 if "Cancel"
7020. Software Object 7020, initialize transaction
7025. Software Object 7025. executes an SQL Delete(s) on UserJVIerchantsJTb for Merchant Partners not selected in Software Object 6870.
7030. Software Object 7030, executes an SQL Insert(s) into UserJVIerchantsJTb for all Merchant Partners selected in Software Object 6870.
7040. Software Object 7040, retrieves the SQL Return Code
7050. Software Object 7050, commits the transaction 7060. Software Object 7060, closes input screen
7100. Set of seven Ledger entries in a sample standard Month End Exceptions report comparing the Bank transactions to the transactions posted to the Ledger that are transferred to the standard reconcihation reports
7101. Set of seven Ledger entries in a sample standard Month End Exceptions report comparing the POS/Processor transactions to the transactions posted to the Ledger that are transferred to the standard reconciliation reports
Brief Description of Drawings
While the novel features of the instant invention are set forth with particularity in the appended claims, a full and complete understanding of the invention can be had by referring . to the detailed description of the preferred embodiment(s) which are set forth subsequently, and which are as illustrated in the accompanying drawings, in which:
Fig. 1 is a block diagram of the instant invention in an internet-enabled configuration.
Fig. 2 is a flow chart depicting the communication paths between the Software Objects of the Reconciliation Software of the instant invention and the Bank, the Merchant Account Processor, the Point of Sale and/or Electronic Payment terminal, the Database, and "Other".
Fig. 3a is a flow chart depicting initialization of data transfer into data file "3 A".
Fig. 3b is a flow chart depicting data retrieval from the ledger/legacy system.
Fig. 4 is a flow chart depicting periodic sweep of data file "3 A" into the database.
Fig. 5a is the first part of a flow chart depicting the overall operation of the reconcihation software of the instant invention.
Fig. 5b is the second part of a flow chart depicting the overall operation of the reconciliation software of the instant invention.
Fig. 6 is a flow chart depicting the operation of the Child Software Objects of Software Object 105 in Fig. 5a performing an SQL Insert into the Reconcihation Tb table. Fig. 7 is a flow chart depicting the operation of the Child Software Objects of
Software Object 115 in Fig. 5a creating the screen for User selection of the Merchant Partner locations to include in the reconcihation.
Fig. 8 is a flow chart depicting the operation of the Child Software Objects of Software Object 130 in Fig. 5a initializing reconciliation procedure by gathering data and inserting it into the Reconcihation Data Tb table.
Fig. 9 is a flow chart depicting the operation of the Child Software Objects of Software Object 480 in Fig. 8 performing a query of the database to obtain the starting procedure and executing such fetched starting procedure.
Fig. 10 is a flow chart depicting the operation of the Child Software Objects of Software Object 140 in Fig. 5a while performing the first pass or "simple match" of the reconciliation process of the instant invention. Fig. 11 is a flow chart depicting the operation of the Child Software Objects of Software Object 850 in Fig. 10 performing the "simple match" of the reconciliation process of the instant invention.
Fig. 12 is a flow chart depicting the operation of the Child Software Objects of Software Object 150 in Fig. 5a starting the "complex match" of the instant invention by taking all of the rows in the Reconcihation )ata_Tb table that did not match in the previous steps and, by combining rows, tries to locate matches.
Fig. 13a is the first page of a flow chart depicting the operation of the Child Software Objects of Software Object 950 in Fig. 12 performing a complex row matching of data within accounts being reconciled.
Fig. 13b is the second page of a flow chart depicting the operation of the Child Software Objects of Software Object 950 in Fig. 12 performing a complex row matching of data within accounts being reconciled.
Fig. 14a is the first page of a flow chart depicting the operation of the Child Software Objects of Software Object 260 in Fig. 5b cleaning up temporary files, performing backup of all reconciliation data tables so that reports can be produced and labeling ah of the matched transactions as cleared.
Fig. 14b is the second page of a flow chart depicting the operation of the Child Software Objects of Software Object 260 in Fig. 5b cleaning up temporary files, perfoπning backup of all reconciliation data tables so that reports can be produced and labeling all of the matched transactions as cleared.
Fig. 15 is a flow chart depicting the operation of the Child Software Objects of Software Object 1390 in Fig. 14b performing a query of the database to obtain the ending procedure and executing such fetched ending procedure. Fig. 16 is a flow chart depicting the operation of the Child Software Objects of
Software Object 550 in Fig. 9 resetting the Reconcihation JData_Tb and Reconcihation Data Matches Tb tables.
Fig. 17 is a flow chart depicting the creation of a User screen for input of Bank data.
Fig. 18 is a flow chart depicting the creation of a User screen for input of POS data. Fig. 19 is a flow chart depicting the creation of a User screen for input of Ledger data. Fig. 20a is the first page of a three page flow chart depicting the creation and operation of a wizard for User setup of a new Account (Merchant, POS, Bank, User, or Other), Agreement, User, or Terminal.
Fig. 20b is the second page of a three page flow chart depicting the creation and operation of a wizard for User setup of a new Account (Merchant, POS, Bank, User, or Other), Agreement, User, or Terminal.
Fig. 20c is the third page of a three page flow chart depicting the creation and operation of a wizard for User setup of a new Account (Merchant, POS, Bank, User, or Other), Agreement, User, or Terminal. Fig. 21 is a flow chart depicting the operation of the Child Software Objects of
Software Object 80 in Fig. 4 inserting Bank data into the Bank Tb table.
Fig. 22 is a flow chart depicting the operation of the Child Software Objects of Software Object 82 in Fig. 4 inserting POS data into the Processor Tb table.
Fig. 23 is a flow chart depicting the operation of the Child Software Objects of Software Object 84 in Fig. 4 inserting Ledger data into the LedgerJTb table.
Fig. 24a is the first page of a two page flow chart depicting the operation of the Child Software Objects of Software Object 170 in Fig. 5b permitting User input to the reconcihation process of the instant invention.
Fig. 24b is the second page of a two page flow chart depicting the operation of the Child Software Objects of Software Object 170 in Fig. 5b permitting User input to the reconciliation process of the instant invention.
Fig. 25 is a flow chart depicting the operation of the Child Software Objects of Software Object 4200 in Fig. 24b creating a screen for User to enter Bank/POS/Ledger/Other adjustments Fig. 26 is a flow chart depicting the operation of the Child Software Objects of
Software Object 3040 in Fig. 20a creating a screen for User to setup a Partner.
Fig. 27 is a flow chart depicting the operation of the Child Software Objects of Software Object 3090 in Fig. 20a creating a screen for User to setup a new agreements with Processors. Fig. 28 is a flow chart depicting the operation of the Child Software Objects of
Software Object 3140 in Fig. 20a creating a screen for User to setup a new terminals. Fig. 29 is a flow chart depicting the operation of the Child Software Objects of Software Object 3200 in Fig. 20b creating a screen for User to setup a new MerchantJSTumber.
Fig. 30 is a flow chart depicting the operation of the Child Software Objects of Software Object 5050 in Fig. 26 Inserting Partner data into the database.
Fig. 31 is a flow chart depicting the operation of the Child Software Objects of Software Object 3220 in Fig. 20c performing all of the associations to the MerchantJSTumber the User entered in the merchant setup wizard.
Fig. 32 is a flow chart depicting the operation of the Child Software Objects of Software Object 5630 in Fig. 20b creating a screen for the User to setup a new Bank account.
Fig. 33 is a flow chart depicting the operation of the Child Software Objects of Software Object 6060 in Fig. 32 executing SQL Inserts of new Bank account data into the database and associating the current User with the new Bank account.
Fig. 34 is a flow chart depicting the operation of the Child Software Objects of Software Object 5690 in Fig. 20b creating a screen for the User to setup a new Ledger account.
Fig. 35 is a flow chart depicting the operation of the Child Software Objects of Software Object 5180 in Fig. 27 creating a screen for the User to setup rates for a Processor agreement. Fig. 36 is a flow chart depicting the creation and operation of a screen for User setup of a new User.
Fig. 37 is a flow chart depicting the creation and operation of a screen for User setup of associations between User and Bank accounts.
Fig. 38 is a flow chart depicting the creation and operation of a screen for User setup of associations between User and Merchant Partners.
Fig. 39 is a printout of the source code that Inserts unmatched rows in the Reconcihation Data Matches Tb table using the Reconcihation Data Tb table. Only matches on rows where the BatchJSTumber, MerchantJSTumber, Transaction JDate, Fee, Net, and Gross Amounts are equal. This query takes three parameters: BatchJSTumber, Source_Table_Code_l, and Source_Table_Code_2. The Reconcihation Data Tb is joined to itself with each instance on pulling the SourceJTable Code l and Source_Table_Code_2. Data Ds equal to Source_Table_Code_l are inserted in DataJD_l and DataJDDs for Source_Table_Code_2 are inserted into Data_ID_2 of the Reconciliation Data Matches Tb.
Fig. 40 is a printout of the source code that Inserts unmatched rows in the Reconcihation Data Matches Tb table using the Reconciliation JDataJTb table. Only matches on rows where the BatchJSTumber, MerchantJSTumber, TransactionJDate, Fee, Net, and Gross Amounts are equal. This query takes three parameters: BatchJSTumber, Source Table Code l, and Source_Table_Code_2. The Reconcihation Data Tb is joined to itself with each instance on pulling the Source_Table_Code_l and Source_Table_Code_2. Data lDs equal to Source Table Code l are inserted in Data_TD_2 and Data IDs for Source_Table_Code_2 are inserted into Data J0D_1 of the Reconciliation JDataJVIatch.es JTb.
Fig. 41 is a printout of the source code that Inserts Bank data into the
Reconcihation Data Tb table where the bank data has not already been cleared for the same type of reconcihation being performed. On the insert the data is being grouped by
BatchJSTumber, Bank Table_Code, MerchantJSTumber, TransactionJDate, and Transaction_Type_Code and summed on the following fields: Transaction Gross, Net and Fee amounts.
Fig. 42 is a printout of the source code that Inserts POS data into the Reconcihation JDataJTb table where the POS data has not already been cleared for the same type of reconcihation being performed. On the insert the data is being grouped by BatchJSTumber, POS Table_Code, MerchantJSTumber, Transaction )ate, and Transaction Type Code and summed on the following fields: Transaction Gross, Net and Fee amounts.
Fig. 43 is a printout of the source code that Inserts Ledger data into the Reconcihation Data Tb table where the Ledger data has not already been cleared for the same type of reconcihation being performed. On the insert the data is being grouped by BatchJSTumber, Ledger Table_Code, MerchantJSTumber, TransactionJDate, and Transaction_Type_Code and summed on the following fields: Transaction Gross, Net and Fee amounts.
Fig. 44 is a printout of the source code that Selects Table Source Code l data from the Reconcihation )ata_Tb table where there is no corresponding match for Table_Source_Code_2 data. Three parameters are needed to run the query: BatchJSTumber, Table_Source_Code_l, and Table jSouree_Code_2. The Select uses a view that shows the rows for Table_Source_Code_2 that already have matches.
Fig. 45 is a printout of the source code that View used in the Select in Figure 44. Selects matches on the right side (Data_ID_2) of the Reconcihation Data Matches Tb. Fig. 46 is a printout of the source code that Inserts matched Bank data rows from the
Reconciliation Data Tb table and the Reconcihation JDataJVIatches rb table into the Reconcihation ClearedJ ata Tb table. Inserts the current Reconcihation Code, Bank Table Code and the Bank TD of rows that matched in the reconcihation. The Bank lD is found by matching rows from the Reconcihation Data Tb with rows in the Bank Tb where the MerchantJSTumber and TransactionJDate is equal.
Fig. 47 is a printout of the source code that Inserts matched POS data rows from the Reconcihation JDataJTb table and the Reconcihation JDataJVIatchesJTb table into the Reconcihation_ClearedJ)ata Tb table. Inserts the current Reconcihation Code,
POS Table Code and the Processor !!) of rows that matched in the reconciliation. The Processor ID is found by matching rows from the Reconcihation Data Tb table with rows in the Processor Tb table where the MerchantJSTumber and TransactionJDate are equal.
Fig. 48 is a printout of the source code that Inserts matched Ledger data rows from the Reconcihation Data Tb table and the Reconcihation JDataJVIatchesJTb table into the Reconcihation Cleared Data Tb table. Inserts the current Reconcihation Code, Ledger Table_Code and the LedgerJ-D of rows that matched in the reconcihation into the Reconcihation Cleared Data Tb. The Ledger D is found by matching rows from the Reconciliation )ata_Tb table with rows in the Ledger Tb table where the MerchantJSTumber and TransactionJDate are equal.
Fig. 49 is a printout of the screen depicting the field names for and the relationships between the Partners Tb, UsersJTb, and the UserJVIerchantsJTb table, the User_AccountsJTb table, and the Partner JffierarchyJTb table.
Fig. 50 is a printout of the screen depicting the field names for and the relationships between the AgreementsJTb table and the AgreementJR.ates_Tb table.
Fig. 51 is a printout of the screen depicting the field names for and the relationships between the Partners Tb table, the Bank_Accounts_Tb table and the Ledger_Accounts_Tb table. Fig. 52 is a printout of the screen depicting the field names for and the relationships between the BankJTb table, the LedgerJTb table, and the ProcessorJTb table.
Fig. 53 is a printout of the screen depicting field names for and the relationships between the ReconciliationJTb table, the Reconcihation JData_Tables_Tb table, the Reconciliation LocationsJTb table, Reconciliation JVIatching Tb table, the Reconciliation DecodeJTb table, and the Reconciliation_Associations_Tb table.
Fig. 54 is a printout of the screen depicting field names for and the relationships between the MerchantsJTb table, the Terminals Tb table, the MerchantJSTumbers_Tb table, the Terminal MerchantJSTumbers Tb, the Merchant_Ledger_Account_Tb table, and the Ledger_Accounts_Tb table.
Fig. 55 is a printout of the screen depicting field names for and the relationships between the Reconcihation Data Tb table, the Reconciliation _Report_DataJTb table, the Reconciliation Cleared DataJTb table, the Reconciliation JDataJVIatchesJTb table, and the Reconciliation J^eport MatchesJTb table. Fig. 56 is a printout of a sample standard Month End Exceptions report comparing the
Bank transactions to the transactions posted to the Ledger.
Fig. 57 is a printout of a sample standard Month End Exceptions report comparing the POS transactions to the Bank transactions.
Fig. 58a is a printout of the first of three pages of a sample standard Reconcihation Report of Outstanding Deposits by Transaction Type Code.
Fig. 58b is a printout of the second of three pages of a sample standard Reconcihation Report of Outstanding Deposits by Transaction Type Code.
Fig. 58c is a printout of the third of three pages of a sample standard Reconcihation Report of Outstanding Deposits by Transaction Type Code. Fig. 59 is a printout of a sample standard Daily Transactions Report.
Fig. 60a is a printout of the first page of a two page sample standard Transaction Report.
Fig. 60b is a printout of the second page of a two page sample standard Transaction Report. Fig. 61 is a printout of a sample User screen. Best Mode for Carrying Out the Invention
The instant invention is of a software program and system that reconciles a merchant's point of sale/electronic payment transactions to the merchant's bank account deposits and chargebacks, and then to the merchant's legacy general ledger system or "Other" source. The software program of the preferred embodiment of the instant invention will be described in terms of software objects constructed in accordance with the methodology of object oriented programming. It being understood that the particular computer language utilized to implement the software program is not determinative of whether the invention is being practiced. The discussion of object oriented programming (OOP), class libraries, and frameworks contained in U.S. Patent 6,026,379 (page 7, line 26, through page 11, line 46) is on point, correct, and is hereby adopted and incorporated by reference herein. A preferred embodiment of the instant invention was written in Microsoft's Visual Basic®.
As seen in Fig. 1, the instant invention is expected to be available for utilization in an internet/intranet environment. In Fig. 1, the chent 1, which is a software program and may be a browser, is seen to be in communication 3 with the internet/intranet interface 5, which in turn is in communication 7 with a firewall 9. The firewall 9 is optional, but if used as in the preferred embodiment is in communication 11 with the software portion 14 of the instant invention, which is assumed to be resident on a suitable computing platform. Included within the software portion 14 of the instant invention is a database 16 which is in commumcation 40 with the software objects 30 of the instant invention. The software objects 30, in turn, comprise software object 24, a web server 20, and a web interactive language object 22 which intermediates between the web server 20 and the software objects 24.
In Fig. 2 the software object 30 (referred to as "software object of the reconcihation software" in Fig. 2) of the instant invention is seen to be in communication 40 with the database 16, in communication 44 with the merchant's general ledger program 42, in communication 34 with and receiving data from a source of the merchant's point of sale credit card/electronic payment transaction data 32 (referred to in Fig. 2 as "electronic transactions"), in communication 38 with and receiving data from the merchant's bank account 36, and in communication 41 with "Other" 45. The "Other" 45 category of inputs is to depict future types of account data that may be reconciled with the software of the instant invention. The instant invention is capable of simultaneous reconciliation of any two or more accounts. Fig. 2 serves to emphasize and depict the instant invention acting between three or more sources of data (the electronic transactions 32, the bank account 36, the general ledger 42, and Other 45) and the database 16.
Ah software objects mentioned in Figs. 3a through 38 are both descendants of and contained within software object 24.
Fig. 3a depicts the initiation of data transfer into the software objects of the instant invention. Data transfer may be initiated by communication 46 from the Merchant or by communication 48 from the data provider. The data provider may be a Bank, a Terminal, a Ledger program mnning on another computing platform, or any other source which, in the preferred embodiment, communicates via TCP/IP, using FTP or other protocol. Software object 50 receives data via communication 46 or communication 48 and transfers such data as a flat file to the local LAN upon which the program, the software objects of the instant invention, is installed. Software object 50 transfers the data to software object 52 where the flat file of data is stored on the local LAN as data file "3 A." Data file 3 A is the name given to a temporary data storage file used for temporary storage on the local LAN of various data throughout this description of the preferred embodiment. Data file 3A is given a unique file name each time it is processed, written to an input directory. There may be multiple data file 3 A files open in the system at any given time. Each data file 3A is stamped with a date/time stamp providing a unique sequence number for each record in order to prevent the over-writing of other 3 A data files.
Fig. 3B depicts the retrieval of data from the Merchant's legacy ledger. Such retrieval may be accomplished either via human intervention or via a scheduled task. Software object 54 initializes the retrieval of data and communicates the completion of such initialization to software object 56. Software object 56 exports the electronic payment transaction and other data entries from the Merchant's legacy Ledger system. Software object 56 communicates its completion of the importation of the data to software object 58 which stores the data in data file 3A.
Fig. 4 depicts the transfer of data from data file 3A into the database 16. Software object 60 initializes the transfer as a scheduled task. Software object 60 communicates completion of mitiahzation to software object 62 which opens an input data file 3 A and receives from the input data file 3 A either an open indication or an EOF indication. Software object 62 communicates the open indication or the EOF indication to software object 64. Software object 64 determines whether an EOF indication is present. If an EOF indication is present, software object 64 commumcates 66 this fact to software object 86. Software object 86, upon receipt of the communication 66 from software object 64, acts to close the input file, data file 3A. Software object 86 communicates the fact that data file 3A has been closed to software object 88 which acts to archive the data file 3 A as a record of data received by the instant invention. If Software object 64 determines that the file opened by software object 62 was not an EOF, then software object 64 communicates 68 this fact to software object 70 which acts to read the next sequential data record from the data file 3A. Software object 70 communicates the data record to software object 72. Software object 72 selects an output communication path dependent upon the type, or form, of the data record received by software object 72 from software object 70. If the data record type was Bank data, the software object 72 chooses output communication path 74, if the data record type was POS data, the software object 72 chooses output communication path 76, if the data record type was Ledger data, the software object 72 chooses output communication path 78, and if the data record type was "Other" data, the software object 72 chooses output communication path 79. Software object 80 receives communication 74 of the Bank data from software object 72 and acts to store such data in the database 16. Software object 80 then communicates 85 the completion of storage of the data to software object 64. Software object 82 receives communication 76 of the POS data from software object 72 and acts to store such data in the database 16. Software object 82 then communicates 85 the completion of storage of the data to software object 64. Software object 84 receives communication 78 of the Ledger data from software object 72 and acts to store such data in the database 16. Software object 84 then communicates 85 the completion of storage of the data to software object 64. Software object 87 receives communication 79 of the Other data from software object 72 and acts to store such data in the database 16. Software object 87 then communicates 85 the completion of storage of the data to software object 64. Software Object 64, upon receipt of communication 85, then acts to again check for EOF. If EOF is not detected by Software Object 64, then software object 64, again, communicates 68 this fact to software object 70 which acts to read the next sequential data record from the data file 3 A and the above-stated cycle repeats until EOF is reached.
Fig. 5 a and Fig. 5b, together, depict the operation of the software object that performs the reconcihations, the objects of the instant invention. Fig. 5a depicts the initiation of the reconcihation operation by receipt of communication 90 from the User to software object 97. Software object 97 creates a User input screen so that the User may, via communication 95, input the reconciliation parameters. Such input parameters include the User's selection of the Bank account and other accounts to be reconciled, and the User's entry of the ClosingJDate for the reconcihation. A table within database 16, User ccountsJTb, stores all of the accounts for which each specific user is authorized. The User to Account association is depicted in Fig. 37. The User can then select only accounts for which the User is authorized according to the authorizations assigned to that User in the User AccountsJTb. Setup of users is depicted in Fig. 36. The User can perform reconciliations by comparing any data files to which the User has access. The User can create any number of comparisons or reconcihations between any number of data sets. Due to limited screen space available, only two-way comparisons are depicted in the Drawings which are part of this apphcation. However, a circular reconcihation is still being performed between all data sets that have been designated by the User. Each reconcihation between accounts sets flags in the accounts indicating that a match occurred. The results, meaning the flagged rows of data only, from any of the two-way comparisons described in detail in this specification will, as a part of the same reconcihation, be compared against any of the other data sets that have been designated by the User. Once the User has input the reconciliation parameters to software object 97, those parameters are communicated 100 to software object 105 which acts to initialize the reconcihation by inserting data into ReconciliationJTb and retrieve the BatchJSTumber created by the SQL Insert. Software object 105 communicates 110 the completion of its retrieval of the BatchJSTumber to software object 115. Software object 115, upon receipt of communication 110 from software object 105, acts to create a User screen to permit the User, via communication 370, to select Merchant Partner locations to be used in the reconciliation. Only Merchant Partners using the Bank Account selected in software object 97 are displayed in the User screen created by software object 115. Software object 115 communicates 120 the completion of User's section of Merchant Partner locations to software object 130. Software Object 130, upon receipt of communication 120, uses the data obtained from the User by software object 97, the BatchJSTumber from software object 105, and the data obtained from the User by software object 115 to collect and prepare the data for processing. Once software object 130 has completed collecting and preparing the data for processing, it communicates 135 the fact of the data's availability to software object 140. The "preparing" of the data for processing will include, for example, the combination of data from each location selected by User in software object 115 into a single table in database 16 named Reconcihation DataJTb, to correspond to the hypothetical situation where the credit transactions from all of such locations is deposited by the Merchant into a single Bank Account. Software object 140, upon receipt of commumcation 135 from software object 130, acts to perform a simple match between the data collected and prepared for processing by software object 130. A "simple" match is a search for identical records between the data sets collected and prepared for processing by software object 130. Once software object 140 has completed its "simple" match, it communicates 145 the fact of its completion to software object 150 which then commences a second or "complex" matching of those records remaining unmatched between the data sets collected and prepared for processing by software object 130. A "complex" match is a search for identities between combinations of records remaining unmatched between each of the data sets collected and prepared for processing by software object 130. Upon completion of the "complex" match, software object 150 communicates 165 the fact of such completion to software object 170. Software object 170 creates a screen for the User to manually enter any necessary adjustments and to manually make such matches as the User may identify. Upon User's completion of his manual matching and adjustments, the software object 170 communicates 175 the fact of completion to software object 195. Software object 195 queries the User as to whether the User is finished attempting to make manual matches and the User communicates 190 his response to software object 195. If the User has communicated 190 to software object 195 that the User is not finished attempting to make manual matches, software object 195 communicates 210 to software object 220 that exception reports need to be generated. Upon receipt of communication 210 from software object 195, software object 220 creates a screen that queries the User as to which exception reports are desired. Once the User has made his selections, software object 220 acts to create the selected exception reports and communicates 240 a standard set of exceptions reports to a printer, viewer, or file, (see Figs. 56 and 57) and communicates 250 a custom set of exception reports (see Figs. 58, 59 and 60) selected by the User to a printer, viewer, or file.
Fig. 56 is a printout of a sample standard Month End Exceptions report comparing the Bank transactions to the transactions posted to the Ledger. Fig. 57 is a printout of a sample standard Month End Exceptions report comparing the POS transactions to the Bank transactions. Figs. 56 and 57 are samples of standard exception reports that will hst all transactions that have not been previously "matched". The outstanding deposits (those that have not cleared the bank) will be transferred to the standard reconcilation reports. The User will be able to direct the report contents from either exception report (Fig. 56 or Fig. 57) onto an interactive screen. This will enable the User to manually make any adjustments, corrections or changes to the transactions that are necessary in order to achieve a balance. The results of the User's adjustments or corrections will create a report for the User to later key or enter any necessary journal entries into the User's ledger system. This step requires human intervention and analysis. However, the instant invention's matching system assures that there are a hmited number of transactions on the exception report and adjustment screen. Examples of exceptions displayed in the exception reports, Figs. 56 and 57, include dates different at POS vs. date cleared at bank-by more than 3 days; amounts different; card type error. Fig. 58 is a printout of the screen created by a standard reconciliation report generated by the instant invention. The criteria for the displayed elements of the standard reconcihation report can be filtered or changed by the User based on the Bank Account, MerchantJD (location) or the transaction type for the standard reconcihation report to be generated. The standard reconcihation report screen, Fig. 58, contents can be modified by the User selections in the "puh-down" menus, and can be filtered specificaUy for each location, each bank account, by transaction type; and by any other database 16 table content. Note that in Fig. 58, the display is of transactions that have been processed at a POS, booked into the ledger, but have not yet cleared the bank, therefore the transactions are considered "outstanding" in accounting terms. Fig. 59 is a printout of the screen created as an example of a full detail report. A User's determination of the need for a print out of any details from the database 16, and the User's appropriate selections from the puh-down menus can create any number of different reports. Fig. 60 is a sample of a display screen of full detail report, summed and sorted by card type.
If the communication 190 from the User to software object 195 is that the User is finished attempting to make adjustments and manually matching records in the data sets being reconciled, the software object 195 communicates 200 this fact to software object 260 which then acts to clean up the data sets being reconciled and archive the database tables and mark all of the transactions (records) that have been matched as cleared. Software object 260 communicates 265 the completion of its tasks to software object 270. Software object 270, upon receipt of communication 265 from software object 260 and with selections communicated 280 from User acts to generate both standard and custom reconcihation reports. Software object 270 communicates 290 its generated standard reconciliation reports to a printer, viewer, or file, and communicates 300 its custom reconcihation reports as selected by User to a printer, viewer, or file (see Fig 56, Fig 57).
Fig. 6 depicts in detail the operation of software object 105 (see Fig. 5a). The function of the software objects depicted in Fig. 6 is to initialize the reconciliation by performing an SQL Insert into the ReconciliationJTb table. As seen in Fig. 5a, software object receives it's input communication 100 from software object 97. In Fig. 6 communication 100 is depicted going to software object 310, a Child of software object 105. Software object 310 acts to initialize the SQL Insert into the ReconciliationJIb table that is accomplished by software object 105. Software object 310 communicates completion of initialization to software object 320 which then Inserts the input parameters communicated 100 from software object 97 (see Fig. 5a.) into the Reconcihation Tb table in the database 16. The data within the ReconciliationJTb is organized by Batch Numbers. A BatchJSTumber is automatically assigned by the database 16 when data is inserted into the Reconcihation_Tb table. Software object 320 communicates the completion of the database 16 insertion to software object 330 which then acts to retrieve the BatchJSTumber from the database 16 and communicate that BatchJSTumber to software object 335. The BatchJSTumber is used throughout the software program of the instant invention. The BatchJSTumber keeps track of what reconciliation the user is working with., via the BatchJSTumber the user can reference the Reconcihation Tb table which will tell the user all of the controls, i.e.: the bank account, bank account number, the user, starting balances and ending balances, whether reconcihation of a particular account has been completed and the date of such completion. Once the BatchJSTumber has been retrieved by software object 330, the BatchJSTumber is passed to each software object in the instant invention that is related to the reconciliation of accounts. Each software object may therefore use the input reconcihation parameters stored as data in the ReconciliationJTb at the assigned BatchJSTumber. Once software object 335 receives communication from software object 330, software object 335 acts to retrieve the SQL Return Code. The retrieval of the SQL Return Code is a check to make sure that the Insert into the database 16 was successfully executed. Once the SQL Return Code has been retrieved from the database 16 by software object 335 that fact is communicated from software object 335 to software object 340 which then acts to commit the transaction. Fig. 7 depicts in detail the operation of software object 115 (see Fig. 5a). The function of software object 115 is to create the screen for User selection of the Merchant Partner locations to include in the reconciliation. Software object 350 is the Child of software object 115 (see Fig. 5a) and receives communication 110 from software object 105. The function of the software objects depicted in Fig. 7 is to create a screen for the User to select the Merchant Partner locations to include in the reconcihation. Upon receipt of communication 110 from software object 105, software object 350 acts to execute an SQL Select from the UserJVIerchantsJTb and Merchant JBank_AccountsJ)v, selecting the Merchants that are assigned to the Bank Account that was selected by the User in software object 97. Once software object 350 has completed execution of the SQL Select from the UserJVIerchantsJTb and Merchant JBank_AecountsJ)v, it communicates that fact to software object 360 which then acts to create a screen for the User to select the locations and Merchant Partners whose data is to be included in the reconcihation. After the screen is created by software object 360, software object 360 communicates that fact to software object 380. Software object 380 then acts to accept the User's communication 370 of his selections and to store the User's selections. After the software object 380 has stored the User's selections, it commumcates that fact to software object 390 which then acts to initialize the transaction. Once software object 390 has completed its initialization of the database 16 for the transaction, it communicates such fact to software object 400 which executes an SQL Insert(s) of the Merchant_Partners previously selected by the User into the Reconciliation_Locations_Tb. The ReconcihationJ ocationsJTb table is used throughout the reconciliation process to indicate which Merchant Partners are being included in the reconciliation. Software object 400 communicates the completion of its Insert(s) to software object 405 which then acts to retrieve the SQL Return Code; making sure the Insert(s) were successful. Following its retrieval of the SQL Return Code, software object 405 communicates the completion of it action to software object 410 which then acts to commit the transaction. Once the transaction has been committed by software object 410, software object 410 communicates 120 this fact to software object 130 (see Fig. 5a). Fig. 8 depicts in detail the operation of software object 130. Software object 415 is the Child of software object 130 (see Fig. 5a) and receives communication 120 from software object 115. The function of the software objects depicted in Fig. 8 is to initiate the reconcihation process by gathering data and placing it in the Reconciliation JData Tb table. All of the gathered data is summed by date and Merchant Number and placed in the Reconcihation JData Tb. Upon receipt of communication 120 from software object 115, software object 415 acts to execute an SQL Select using the Batch JSTumber to query the Reconcihation Tb to retrieve the UserJD, Reconcihation_Code and Closing Date. This information is then saved in local variables to be used throughout the software object 130. Once software object 415 has completed execution of the SQL Select, it communicates that fact to software object 420 which then executes an SQL Select on the Reconcihation Associations Tb using the current Reconcihation Code. The SQL Select creates a cursor selecting all the Table Codes used in this reconcihation from the Reconcihation Associations Tb. The Reconcihation Associations Tb table determines what data tables are referenced in this reconciliation. Completion of the creation of the cursor is communicated from software object 420 to software object 430 which, following receipt of such communication, acts to perform a check verifying that the cursor is not empty, that there is data in it. If software object 430 determines that the cursor is EOF, or empty, it communicates 440 that fact to software object 490 which then acts to close the cursor. If software object 430 determines that the cursor contains data, it communicates 450 that fact to software object 460. Software object 460, upon receipt of communication 450 from software object 430, acts to retrieve the next row, or record, from the cursor. Each record in the cursor will consist of a Table_Code that will be referenced in software object 470. After software object 460 retrieves the Table_Code, it communicates that fact to software object 470 which then acts to execute an SQL Select on the Reconcihation Data Tables Tb and retrieve the Starting Procedure for the current Table Code as assigned in Software object 460. Each data table has an independent starting procedure (stored in the variable StartingJProcedure) that describes and defines the method of data collection to be used, based on the BatchJSTumber. Software object 470 communicates 475 the completion of its execution of the SQL Select to software object 480 which then utilizes the starting procedure to gather data for the particular table and to total and Insert the gathered data in the Reconciliation JData Tb. Software object 480 communicates 485 the completion of its execution of the SQL Insert to software object 430 which repeats its determination of whether the cursor has reached EOF. Software object 490 communicates 135 the completion of its closure of the cursor to software object 140 (see Fig. 5a).
Fig. 9 depicts in detail the operation of software object 480 (see Fig. 8). Software object 500 is the Child of software object 480 and receives communication 475 from software object 470. The function of the software objects depicted in Fig. 9 is to execute the Starting J^rocedure for the reconciliation process where the local variable Input Parameter (in Fig. 9) is a Table Code. The routines depicted in detail in Fig. 9 are for the three major reconcihations, Bank, Ledger and POS. The software of the instant invention has been designed to permit an unlimited number of "Other" data sources which can be optionally included in the reconcihation process. Upon receipt of communication 475 from software object 470, software object 500 acts to select its output communication hne on case equal the input parameter. If software object 500 determines that the input parameter is "Other" Table_Code then software object 500 will communicate 505 such code to software object 515. If software object 500 determines that the input parameter is "Bank" Table Code then software object 500 will communicate 510 its input data to software object 535. If software object 500 determines that the input parameter is "POS" Table Code then software object 500 will communicate 520 its input data to software object 590. If software object 500 deteimines that the input parameter is "Ledger" Table Code then software object 500 will communicate 530 it input data to software object 650. Software object 500's input data consists of the Table_Code and BatchJSTumber.
Note that there are several different "PartnerJDs". There may be a Partner !!) for each corporate customer, a PartnerJ-D for each customer, and a PartnerJD for each merchant location. "Bank Partner ID" is the variable name utilized for each Bank Account, and "Processor Partner lD" is the variable name utihzed for each Processor. Software object 515 is displayed on Fig. 9 only to reflect that for each Other data type and source another similar set of software objects must be utihzed as is utilized for Bank, POS, or Ledger data.
Beginning the description of the operation of the software objects depicted in Fig. 9 with the assumption that Bank Table_Code is received by software object 500 as Input Parameter, software object 500 then acts to determine whether such data should be communicated 510 to software object 535 and, if so, communicates 510 the data. Software object 535, upon receipt of the communicated 510 data from software object 500, acts to execute an SQL Select to query the ReconciliationJTb and Bank_Accounts_Tb tables in the database 16 for the User_Id, PartnerJ-D, the Reconcihation_Code, Bank_Account JSTumber and the ClosingJDate. Software object 535 then executes a second query on the Reconcihation Decode Tb table to retrieve the Reconcihation Code that represents a reconcihation of ah accounts and assigns it to a local variable called Reconcihation_AU. There will be only one row in the Reconciliation DecodeJTb table with the column All_Accounts_Flag equal to 1 or "True". Upon receipt of the results of such queries, software object 535 communicates the fact of such receipt to software object 540 which then begins the transaction. Software object 540 communicates 545 the completion of its beginning the transaction to software object 550. Upon receipt of communication 545 from software object 540, software object 550 acts to reset the working tables for the reconcihation. Software object 550 accepts an optional (OR function input to Child software object 1800 as shown in Fig. 16) parameter which is equivalent to a Table_Code prior to resetting the working tables. Once software object 550 has completed the reset of the working tables, it communicates 555 this fact to software object 560 which then acts to insert the uncleared Bank transactions from the Bank Tb table that fit the current reconcihation definition provided by the local variables set in software object 535 into the Reconcihation JData Tb table. Uncleared Bank transactions are those that have not been cleared in another reconciliation of the same type as the current reconcihation or cleared in a reconcihation that included ah accounts. A reconcihation of the same type is a reconcihation between the same accounts.
Software object 560 performs an SQL Insert of the values for BatchJSTumber, Table_Code, MerchantJSTumber, TransactionJDate, Transaction Type Code,
Transaction Gross Amt, Transaction _Fee_Amt, and Transaction JSTet_Amt into the Reconciliation DataJTb table. The SQL Insert into the Reconcihation JDataJTb table which is executed by software object 560 groups the data ("grouping data" is selecting data rows that have the values required or specified in the columns over which the "grouping" takes place) in the Transaction_Gross_Amt, Transaction JFee_Amt, and Transaction JSTet Arnt columns by the values in the MerchantJSTumber, TransactionJDate, and Bank_Code columns of the BankJTb table.
Software object 560, in order to accomplish its SQL Insert of the values for BatchJSTumber, Table_Code, MerchantJSTumber, TransactionJDate, Transaction_Type_Code, Transaction Gross Amt, Transaction_Fee_Amt, and Transaction JSTet_Amt into the Reconcihation JData Tb table, first selects from the Bank_Tb the values of MerchantJSTumber and TransactionJDate, and aliases the names Bank_Code, SUM of Transaction_Gross_Amt, SUM of Transaction_Fee_Amt, and SUM of Transaction JSTet_Amt from the Bank Tb as Transaction Type Code, Transaction_Gross_Amt, Transaction_Fee_Amt, and TransactionJSTet_Anιt, respectively, to be inserted into the Reconcihation Data Tb table.
The local variable BatchJSTumber was assigned a value in software object 320. The local variable Table_Code was assigned a value in software object 535. Only summed values of the Transaction_Gross_Amt, TransactionJFee_Amt, and Transaction JSTet_Amt from the Bank Tb table are inserted by software object 560 into the Reconcihation Data Tb table.
Software object 560 then continues its execution by performing a first left join of the Bank Tb table to the Reconcihation Cleared Data Tb table on Reconcihation Code in the Reconciliation ClearedJData Tb equal to the local variable Reconcihation Code (Reconcihation Code of the current reconciliation) AND Table Code in the Reconcihation Cleared Data Tb equal to the local variable Table Code (Table Code of the current reconcihation) AND Row_ϋD in the Reconcihation Cleared Data Tb equal to Bank JDD in the Bank_Tb (Bank D is an identity column in the Bank Tb table). The Reconcihation Cleared Data Tb table contains Bank records, if any, that have already been cleared in a prior reconcihation.
Software object 560 then continues its execution by performing a second left join of the BankJTb table to the AhJCleared (an alias for Reconcihation Cleared Data Tb) table on Reconcihation Code in the AhJCleared ahased table equal to the local variable Reconciliation_All AND Table_Code in the AhJCleared ahased table equal to the local variable Table_Code AND RowJDD in the All_Cleared aliased table equal to the identity column BankJD in the BankJTb table. The local variable Reconciliation_AU was assigned a value in software object 535.
Software object 560 then continues its execution by performing a join of the Merchant JSTumbersJTb table to the BankJTb table on the MerchantJSTumber in the Bank Tb equal to the MerchantJSTumber in the Merchant JSTumbersJTb. The MerchantJSTumber column in the MerchantJSTumbers_Tb includes only Merchant Numbers for Merchant Locations included in the current reconcihation. Software object 560, finally, completes its selection of candidate uncleared Bank transactions by performing a join of the Bank Tb table on the Reconciliation Locations Tb on the MerchantJPartner_ID in the MerchantJNumbersJTb equal to the Merchant_Partner_ϋ) in the Reconcihation J-Ocations Tb AND BatchJSTumber in the Reconcilation Locations Tb equal to the local variable BatchJSTumber. The Reconcihation J ocationsJTb table includes only Merchant Locations included in the current reconcihation.
After assuring that only uncleared bank transactions are considered in the reconcihation process, software object 560 completes its execution by performing the SQL Insert of uncleared bank transaction data into the ReconciliationJDataJTb table only where the RowJD of the prospective data row insertion is Null in both the Reconciliation JData Tb table and the AhJCleared aliased table AND the PartnerJD of the bank record in the Bank Tb equals the local variable PartnerJD assigned in software object 535 AND the TransactionJDate of the bank record in the BankJTb is less than or equal to the local variable Closing Date assigned in software object 535 AND the Bank_Account JSTumber of the bank record in the Bank Tb equals the local variable Bank AccountJSTumber selected for this reconcihation as queried in software object 535 from the Reconcihation Tb table. The SQL code to accomphsh the transaction(s) performed by software object 560 is depicted in Fig. 41.
Upon completion of the execution of the transaction(s), software object 560 communicates the fact of such completion to software object 570. Software object 570, upon receipt of communication of the fact of completion from software object 560, acts to retrieve the SQL Return Code. Once software object 570 has retrieved the SQL Return Code, it communicates that fact to software object 580 which then acts to commit the transaction. After committing the transaction, software object 580 then communicates 485 the completion of its action to software object 430 (see Fig. 8).
If it is assumed that POS Table_Code is received by software object 500 as Input Parameter, software object 500 then acts to determine whether such data should be communicated 520 to software object 590 and, if so, communicates 520 the data. Software object 590, upon receipt of the communicated 520 data from software object 500, acts to execute an SQL Select to query the ReconciliationJTb and Bank_AccountsJTb tables in the database 16 for the UserJD, Partner_ID, the Reconcihation Code, Bank_Account_Number and the ClosingJDate. Software object 590 then executes a second query on the Reconciliation DecodeJTb table to retrieve the Reconcihation Code that represents a reconcihation of all accounts and assigns it to a local variable called Reconciliation_AU. There will be only one row in the Reconcihation JDecodeJTb table with the column AhJAccountsJFlag equal to 1 or "True". Upon receipt of the results of such queries, software object 590 communicates the fact of the completion of its execution to software object 600 which then begins the transaction. Software object 600 communicates 605 the completion of its beginning the transaction to software object 550. Upon receipt of communication 605 from software object 600, software object 550 acts to reset the working tables for the reconciliation. Once software object 550 has completed the reset of the working tables, it communicates 615 this fact to software object 620 which then acts to insert the uncleared POS transactions from the Processor Tb table that fit the current reconciliation definition provided by the local variables set in software object 535 into the Reconcihation JData Tb table. Uncleared POS transactions are those that have not been cleared in another reconcihation of the same type as the current reconcihation or cleared in a reconcihation that included all accounts. A reconcihation of the same type is a reconciliation between the same accounts.
Software object 620 performs an SQL Insert of the values for BatchJSTumber, Table_Code, MerchantJSTumber, TransactionJDate, Transaction_Type_Code,
Transaction Gross Amt, Transaction_Fee_Amt, and Transaction_Net_Amt into the Reconcihation Data Tb table. The SQL Insert into the Reconcihation Data Tb table which is executed by software object 620 groups the data ("grouping data" is selecting data rows that have the values required or specified in the columns over which the "grouping" takes place) in the Transaction_Gross_Amt, Transaction 'ee Amt, and Transaction JSTet_Amt columns by the values in the MerchantJSTumber, TransactionJDate, and Payment Type Code columns of the ProcessorJTb table.
Software object 620, in order to accomplish its SQL Insert of the values for BatchJSTumber, Table_Code, MerchantJSTumber, TransactionJDate,
Transaction_Type_Code, Transaction_Gross_Amt, Transaction JFee Amt, and Transaction JSTet_Amt into the Reconcihation Data Tb table, first selects from the ProcessorJTb the values of Merchant JSTumber and TransactionJDate, and ahases the names Payment Type Code, SUM of Transaction Gross Amt, SUM of Transaction JFee_Amt- and SUM of Transaction JSTet_Amt from the ProcessorJTb as Transaction_Type_Code, Transaction Gross Amt, Transaction_Fee_Amt, and Transaction JSTet_Amt, respectively, to be inserted into the Reconcihation JDataJTb table.
The local variable BatchJSTumber was assigned a value in software object 330. The local variable Table_Code was assigned a value in software object 590. Only summed values of the Transaction Gross Amt, Transaction_Fee_Amt, and Transaction JSTet_Amt from the
ProcessorJTb table are inserted by software object 620 into the Reconciliation Data Tb table.
Software object 620 then continues its execution by performing a first left join of the ProcessorJTb table to the ReconcUiation_Cleared_Data_Tb table on Reconciliation_Code in the Reconcihation_Cleared JDataJTb equal to the local variable Reconcihation_Code (Reconcihation_Code of the current reconcihation) AND Table Code in the Reconcihation Cleared Data Tb equal to the local variable Table Code (Table Code of the current reconcihation) AND RowJ-D in the Reconciliation_Cleared DataJTb equal to Processor !!) in the Processor Tb (Processor D is an identity column in the Processor Tb table). The Reconcihation Cleared Data Tb table contains POS records, if any, that have already been cleared in a prior reconcihation.
Software object 620 then continues its execution by performing a second left join of the Processor Tb table to the AhJCleared (an alias for Reconcihation Cleared Data Tb) table on Reconcihation Code in the AhJCleared aliased table equal to the local variable Reconcihation Ah AND Table Code in the AhJCleared ahased table equal to the local variable Table_Code AND RowJDD in the AhJCleared ahased table equal to the identity column Processor !!) in the Processor Tb table. The local variable Reconcihation Ah was assigned a value in software object 590.
Software object 620 then continues its execution by performing a join of the MerchantJNumbersJTb table to the Processor Tb table on the MerchantJSTumber in the ProcessorJTb equal to the MerchantJSTumber in the Merchant JNTumbersJTb. The MerchantJSTumber column in the MerchantJSTumbersJTb includes only Merchant Numbers for Merchant Locations included in the current reconciliation.
Software object 620 then continues its execution by performing a join of the Reconciliation Locations Tb table to the Processor Tb table on the Merchant PartnerJ-D in the MerchantJSTumbers_Tb equal to the Merchant Partner JQD in the Reconcihation Locations Tb AND BatchJSTumber in the Reconcilation Locations Tb equal to the local variable BatchJSTumber. The Reconcihation J ocations Tb table includes only Merchant Locations included in the current reconcihation.
Software object 620, finally, completes its selection of candidate uncleared POS transactions by performing a join of the Processor Tb table to the Merchant JSTumberJBank ϊcount table view on the MerchantJSTumber in the ProcessorJTb equal to the MerchantJSTumber in the MerchantJSTumber_Bank_Account table view.
After assuring that only uncleared bank transactions are considered in the reconcihation process, software object 620 completes its execution by performing the SQL Insert of uncleared POS transaction data into the Reconcihation JDataJTb table only where the RowJDD of the prospective data row insertion is Null in both the Reconcihation JData Tb table and the AhJCleared ahased table AND the Partner_ID of the POS record in the Processor Tb equals the local variable PartnerJD assigned in software object 590 AND the TransactionJDate of the POS record in the ProcessorJTb is less than or equal to the local variable ClosingJDate assigned in software object 590 AND the Bank_AccountJSTumber in the Merchant Number Bank Account table view equals the local variable Bank_Account JSTumber selected for this reconciliation as queried in software object 590 from the Reconcihation Tb table. The SQL code to accomphsh the transactions) performed by software object 620 is depicted in Fig. 42.
Upon completion of the execution of the transactions), software object 620 communicates the fact of such completion to software object 630. Software object 630, upon receipt of communication of the fact of completion from software object 620, acts to retrieve the SQL Return Code. Once software object 630 has retrieved the SQL Return Code, it communicates that fact to software object 640 which then acts to commit the transaction. After committing the transaction, software object 640 then communicates 485 the completion of its action to software object 430 (see Fig. 8).
If it is assumed that Ledger Table_Code is received by software object 500 as Input Parameter, software object 500 then acts . to determine whether such data should be communicated 530 to software object 650 and, if so, communicates 530 the data. Software object 650, upon receipt of the communicated 530 data from software object 500, acts to execute an SQL Select to query the ReconciliationJTb and Bank_Accounts_Tb tables in the database 16 for the User D, PartnerJD, the Reconcihation Code, Bank_Account JSTumber and the ClosingJDate. Software object 650 then executes a second query on the Reconcihation JDecodeJTb table to retrieve the Reconciliation_Code that represents a reconcihation of all accounts and assigns it to a local variable called Reconciliation Ul. There will be only one row in the Reconcihation JDecodeJTb table with the column AhJAccountsJ?lag equal to 1 or "True". Upon receipt of the results of such queries, software object 650 communicates the fact of the completion of its execution to software object 660 which then begins the transaction. Software object 660 communicates 665 the completion of its beginning the transaction to software object 550. Upon receipt of communication 665 from software object 650, software object 550 acts to reset the working tables for the reconciliation. Once software object 550 has completed the reset of the working tables, it communicates 675 this fact to software object 680 which then acts to insert the uncleared Ledger transactions from the LedgerJTb table that fit the current reconciliation definition provided by the local variables set in software object 535 into the ReconciliationJDatajrb table. Uncleared Ledger transactions are those that have not been cleared in another reconciliation of the same type as the current reconcihation or cleared in a reconcihation that included all accounts. A reconcihation of the same type is a reconciliation between the same accounts.
Software object 680 performs an SQL Insert of the values for BatchJSTumber, Table_Code, MerchantJSTumber, TransactionJDate, Transaction_Type_Code,
Transaction_Gross_Amt, Transaction_Fee_Amt, and Transaction JSTet_Amt into the Reconcihation Data Tb table. The SQL Insert into the Reconcihation Data Tb table which is executed by software object 680 groups the data ("grouping data" is selecting data rows that have the values required or specified in the columns over which the "grouping" takes place) in the Transaction_Gross_Amt, Transaction Fee Amt, and Transaction Net Amt columns by the values in the MerchantJSTumber, and Ledger JDate columns of the LedgerJTb table.
Software object 680, in order to accomphsh its SQL Insert of the values for BatchJSTumber, Table Code, MerchantJSTumber, TransactionJDate,
Transaction_Type_Code, Transaction_Gross_Amt, Transaction_Fee_Amt, and Transaction Net Amt into the Reconcihation JData Tb table, first selects from the LedgerJTb the values of MerchantJSTumber and Ledger JDate, and ahases the names SUM of Ledger Gross Amt, SUM of LedgerJFee Amt, and SUM of LedgerJSTet_Amt from the LedgerJTb as Transaction_Gross_Amt, Transaction JFee_Amt, and Transaction JSTet_Amt, respectively, to be inserted into the Reconcihation Data Tb table.
The local variable BatchJSTumber was assigned a value in software object 330. The local variable Table_Code was assigned a value in software object 650. Only summed values of the Transaction_Gross_Amt, Transaction_Fee_Amt, and Transaction JSTet_Amt from the
LedgerJTb table are inserted by software object 680 into the Reconcihation JData Tb table.
Software object 680 then continues its execution by performing a first left join of the
LedgerJTb table to the Reconcihation Cleared Data Tb table on Recontiliation Code in the
Recon liation ClearedJData Tb equal to the local variable Reconciliation_Code (Recontiliation Code of the current reconcihation) AND Table_Code in the
Reconcihation Cleared Data Tb equal to the local variable Table Code (Table Code of the current reconcihation) AND RowJD in the Reconcihation Cleared Data Tb equal to
Ledger TD in the LedgerJTb (Ledger_ TD is an identity column in the LedgerJTb table). The
Reconciliation Cleared Data _Tb table contains Ledger records, if any, that have already been cleared in a prior reconciliation.
Software object 680 then continues its execution by performing a second left join of the LedgerJTb table to the AhJCleared (an alias for Reconcihation Cleared Data Tb) table on Reconciliation_Code in the AU_Cleared ahased table equal to the local variable
Reconcihation Ah AND Table_Code in the AU_Cleared aliased table equal to the local variable Table_Code AND Row TD in the AU Cleared ahased table equal to the identity column Ledger TD in the LedgerJTb table. The local variable Reconcihation Ah was assigned a value in software object 650.
Software object 680 then continues its execution by performing a join of the
MerchantJSTumbersJTb table to the LedgerJTb table on the MerchantJSTumber in the LedgerJTb equal to the MerchantJSTumber in the MerchantJSTumbersJTb. The
MerchantJSTumber column in the MerchantJSTumbersJTb includes only Merchant Numbers for Merchant Locations included in the current reconcihation.
Software object 680 then continues its execution by performing a join of the
Reconciliation J ocationsJTb table to the LedgerJTb table on the Merchant_Partner_TD in the MerchantJSTumbersJTb equal to the Merchant JPartner JDD in the
Reconciliation^ JLocationsJTb AND BatchJNumber in the Recontilation Locations Tb equal to the local variable BatchJSTumber. The Reconciliation_Locations_Tb table includes only Merchant Locations included in the current recontiliation.
Software object 680, finaUy, completes its selection of candidate uncleared Ledger transactions by performing a join of the LedgerJTb table to the MerchantJSTumberJBank Account table view on the MerchantJSTumber in the LedgerJTb equal to the MerchantJSTumber in the MerchantJSTumber_Bank_Account table view.
After assuring that only uncleared bank transactions are considered in the reconcihation process, software object 680 completes its execution by performing the SQL Insert of uncleared Ledger transaction data into the Reconcihation Data Tb table only where the Row TD of the prospective data row insertion is NuU in both the Reconcihation JData Tb table and the AU Cleared ahased table AND the PartnerJD of the Ledger record in the
LedgerJTb equals the local variable PartnerJD assigned in software object 650 AND the
, Ledger JDate of the Ledger record in the LedgerJTb is less than or equal to the local variable
ClosingJDate assigned in software object 650 AND the Bank AccountJSTumber in the Merchant JSTumber_Bank_Account table view equals the local variable Bank_AccountJSTumber selected for this reconcihation as queried in software object 650 from the Reconcihation Tb table. The SQL code to accomphsh the transactions) performed by software object 680 is depicted in Fig. 43.
Upon completion of the execution of the transactions), software object 680 communicates the fact of such completion to software object 690. Software object 690, upon receipt of communication of the fact of completion from software object 680, acts to retrieve the SQL Return Code. Once software object 690 has retrieved the SQL Return Code, it communicates that fact to software object 700 which then acts to commit the transaction. After committing the transaction, software object 700 then communicates 485 the completion of its action to software object 430 (see Fig. 8).
Fig. 10 depicts in detaU the operation of software object 140. Software object 800 is the Child of software object 140 (see Fig. 5a) and receives communication 135 from software object 130. The function of the software objects depicted in Fig. 10 is to execute the first pass or "simple match" of the reconcihation process which is the object of the instant invention. Upon receipt of communication 135 from software object 130, software object 800 executes an SQL Select on the Reconcihation Tb table, retrieving the UserJD, Bank_Account_Number, Reconcihation Code and the ClosingJDate and setting up the local variables for the current BatchJSTumber. Once software object 800 has completed execution of the SQL Select, it communicates that fact to software object 805. Software object 805, upon receipt of such communication from software object 800, acts to create and open a cursor by, first, executing an SQL Select on the Reconcihation_Matching_Tb table, to retrieve the following fields: Reconcihation Code Source Table Code l Source_Table_Code_2 Matching JProcedure Process Drder
Software object 805 then completes the act of creating and opening a cursor by selecting all rows from the ReconcilationJVIatching Tb where the Reconciliation_Code in the Reconcihation Matching Tb table is equal to the local variable Reconcihation Code assigned by software object 800, and sorts the cursor by Process Order. Software object 805 communicates the completion of its formation of the cursor to software object 810. Upon receipt of communication from software object 805, software object 810 acts to determine whether an EOF condition exists, thereby checking to see if there is any data in the cursor. If software object 810 determines that the end of file has been reached, it communicates 820 such fact to software object 860. Software object 860 acts to close the cursor and communicates 145 the fact of such closing to software object 150 (see Fig. 5a). If software object 810 determines that the cursor contains data, it communicates 830 that fact to software object 840. Software object 840, upon receipt of commumcation 830 from software object 810, acts to retrieve the next row, or record, from the cursor. Software object 840 communicates 845 the retrieved record to software object 850. Software object 850, upon receipt of communication 845 from software object 840, executes a "simple match". A "simple match" consists of matching rows in the Reconcihation Data Tb table where the Table_Code in the Reconcihation DataJTb table is identified by one of two input parameters, Source_Table_Code_l and Source_Table_Code_2, and by searching, according to criteria set by the Matching Procedure, for identical entries in the Reconcihation Data Tb table. The criteria set by the Matching Procedure is that the following columns must equal each other: Batch Number, Transaction_Type_Code, TransactionJDate, MerchantJSTumber, Transaction_Gross_Amt, Transaction_FeeJ^tnt, and Transaction JSTet_Amt
After the completion of the search for simple matches, software object 850 communicates 855 the fact of completion to software object 810 which repeats its previously described determination of whether EOF has been reached in the cursor. Software object 850 performs a "simple match" between the rows of data contained within the accounts being reconciled utilizing the software objects depicted in Fig. 11. Software object 870 is a Child of software object 850 (see Fig. 10) and receives the communication 845 that a record has been retrieved from the cursor which is sent by software object 840. Upon receipt of the communication 845 from software object 840, software object 870 acts to begin the transaction. Note that (see Definition of Terms and Phrases) ''beginning a transaction" involves data being processed, performing table updates into multiple tables and committing the transactions. This means that aU of the updates to the tables are done at one time. If one table insert fails during any of the processing, the program of the instant invention can roU back aU of the updates that the program has made so that the enthe update is done as one transaction. Once software object 870 has concluded beginning the transaction, it communicates this fact to software object 875. Software object 875, following receipt of the communication from software object 870, acts to execute an SQL Insert. Fig. 39 depicts the source code for the SQL Insert accomphshed by software object 870. The SQL Insert performed by software object 875 inserts data rows into the Recontilation JDataJVIatchesJTb table for the current BatchJSTumber, the Data TD column from the aliased table Sourcel, and the DataJDD column from the ahased table Source2, into the foUowing columns BatchJSTumber, Data TD l, and Data_TD_2, respectively.
Software object 875 then continues its execution by joining the table ReconcUiation JDataJTb, aliased as Sourcel, to another instance of the table Reconcihation JDataJTb, ahased as Source2, where the ahased table Sourcel has columns BatchJSTumber, MerchantJSTumber, Transaction Date, Transaction_Gross_Amt, TransactionJFee Amt and TransactionJSTet_Amt that are equal to the same columns in the aliased table Source2.
Software object 875 then continues its execution by performing a left join to the
Reconchation DataJVIatchesJTb where the DataJD column in the aliased table Sourcel, is equal to the Data TD 1 column in the table Reconciliation JDataJVIatchesJTb and the
Data JD column in the ahased table Source2, is equal to the Data_TD_2 column in the table
Reconcihation DataJVIatchesJTb .
Software object 875 completes its execution by performing the SQL Insert of matched data rows into the Reconciliation DataJVIatchesJTb table where the Table Code and BatchJSTumber columns in the ahased table Sourcel are equal to the input parameter Source_Table_Code_l and local variable BatchJSTumber, respectively. Also, the Table_Code and BatchJSTumber columns in the ahased table Source2 must equal the input Parameter Source_Table_Code_2 and the local variable BatchJSTumber, respectively. Assuring duplicate rows are not inserted, only rows where the columns Data TD l and Data TD 2, from the left joined table Reconcihation JDataJVIatchesJTb, are NULL are selected for insertion. FoUowing completion of the execution of the SQL Insert, software object 875 communicates the fact of completion to software object 880 which then acts to retrieve the SQL Return Code. Once software object 880 has retrieved the SQL Return Code, software object 880 communicates the fact of completion to software object 885 which then executes an SQL Insert. The source code of the SQL Insert executed by software object 885 is depicted in Fig. 40. The SQL Insert performed by software object 885 is similar to the SQL Insert performed by software object 875 in that only the input parameters SourceJTable Code l and Source_Table_Code_2 are reversed. The
ReconcUiation DataJVIatchesJTb consists of 3 columns of data; Data TD l, Data_TD_2 and BatchJSTumber. Data TD l and Data TD 2 are just the Data_TDs that match up from a simple match of the records in the Reconciliation JDataJTb. For example, if you have a Bank reconcihation record and a Processor reconcihation record that match up on the first SQL Insert which is performed by software object 875, the Bank_TD went in the Data TD l field and the ProcessorJD for the reconciliation went in the Data_ID_2 field. Then in the second match which is performed by software object 885 the order of processing would be reversed. This is done so that the match wUl appear without regard to the relative placement of the records, which is determined by the timing sequence of data entry, within the tables. Once software object 885 has completed its SQL Insert, it communicates the fact of completion to software object 890. Software object 890 retrieves the SQL Return Code and communicates the fact of receipt of the SQL Return Code to software object 895. Software object 895 commits the transaction upon receipt of the communication from software object 890. Once software object 895 has committed the transaction, it communicates 855 this fact to software object 810 (see Fig. 10).
Fig. 12 depicts in detaU the operation of software object 150. Software object 900 is the ChUd of software object 150 (see Fig. 5a) and receives communication 145 from software object 140. The function of the software objects depicted in Fig. 12 is to execute the start of the "complex match" procedure of the instant invention. The software object depicted in Fig. 12 takes aU of the rows in the Reconcihation Data Tb that did not match in the previous steps performed by software object 885 (Fig. 11) and combines rows and tries to match them. For example if the program of the instant invention was in a state where the Reconcilation JDataJTb table has one row left unmatched from the BankJTb and three rows left unmatched from the ProcessorJTb, the program of the instant invention would create all possible combinations of those three rows from the ProcessorJTb and attempt to match each of those combinations to the one row remaining from the Bank Tb. Then, if a unique match (there has to be a unique match, if more than one of the combinations match then no match is considered to have occurred) were discovered during the process of comparing each possible combination of rows fromthe Processor Tb to the rows from the BankJTb, the matching rows would be inserted by the program into the Reconcihation Data Matches Tb. This algorithm of attempting to match combined rows of one data set to a single row of another data set is required because either the Bank or the Processor may report multiple, summed transactions as a single transaction in the statement or data that they provide to the Merchant. Upon receipt of communication 145 from software object 140, software object 900 acts to create a cursor by querying the Reconcihation_Matching_Tb table, selecting Source Table Code l and Source_Table_Code_2 using the current Reconcihation Code of the reconcihation being performed. After software object 900 has created the cursor, it communicates this fact to software object 910 which then acts to determine whether the cursor has reached EOF, ie. whether the cursor has any records remaining in it to be read. If software 910 object determines that the cursor has reached EOF, it commumcates 920 this fact to software object 935. When software object 935 receives communication 920 from software object 910, software object 935 acts to close the cursor and communicates 165 the fact that the cursor is closed to software object 170 (see Fig. 5b). If the software object 910 determines that the cursor has not reached EOF, it communicates 930 this fact to software object 940 which acts to get the next row from the cursor set, which next row consists of the SourceJTable Code l and the Source_Table_Code_2. After software object 940 has retrieved the next record in the cursor, it communicates 945 this record to software object 950 which then acts to execute the "complex match" procedure which attempts to match all combinations of rows in the table identified by Source Table Code l against each row of the table identified by Source_Table_Codej2. For example, if Source_Table_Code_l is Bank data and Source_Table_Code_2 is Processor data, software object 950 wUl attempt to match every combination of the unmatched rows of Processor data against each unmatched row of the Bank data. Upon completion of its initial execution of the "complex match", software object 950 wiU repeat its action (accomphsh a second execution) but with reversed input parameters so that software object 950 attempts to match ah combination of rows in the table identified by Source_Table_Code_2 against each row of the table identified by Source_Table_Code_l. When software object 950 completes its "complex match" procedure, it communicates 955 this fact to software object 910 which then acts as previously described.
Fig. 13a and Fig. 13b form a single flow chart depicting in detail the operation of software object 950. Software object 1000 is the CWld of software object 950 (see Fig. 12) and receives communication 945 from software object 940. The function of the software objects depicted in Figs. 13a and 13b is to perform a complex row matching of data within accounts being reconciled. Upon receipt of communication 945 from software object 940, software object 1000 acts to create a data cursor "13 A" by doing an SQL Select on Database 16 to select all fields in all rows equal to Source_Table_Code_2 from the Reconcihation Data Tb table where there is no match in the ReconcUiation DataJVIatchesJTb table for SourceJTable Code l. Software object 1000 accepts two Table Codes, Source_Table_Code_l and Source_Table_Code_2, and a BatchJSTumber as input parameters. The two Table_Codes are of those tables that Software Object 950 is doing the complex match on and the BatchJSTumber is the current one. Recall that Batch JSTumbers are assigned automatically for processing purposes. ' Software object 1000 then continues its SQL execution by left joining to the table view RightJVIatchesJjv where the DataJD from the ReconciliationJTb table is equal to the Data_TD_l from the RightJVIatchesJiv table view and the Table_Code form the Right JVIatches_bv table view is equal to the input parameter Table_Source_Code_2. Software object 1000, finally, completes its selection by only selecting the rows where the BatchJSTumber and the Table_Code in the Reconcihation JDataJTb table is equal to the input parameter Source Table Code l and the local variable BatchJSTumber, respectively, and the Table_Cpde in the Right JVIatches_bv table view must be NULL.
Fig. 44 depicts in detaU the SQL Query that is being performed by software object 1000. Software object 1000 communicates the completed cursor 13A to software object 1010. Software object 1010 then takes cursor 13A and creates a new data coUection "13C" by taking all unique combinations of rows from cursor 13 A. For each unique combination of data rows in cursor 13A, a new data object is created and inserted into data collection 13C. The original data rows from cursor 13 A used to create each unique combination are stored in the newly created data object 13C. This is done so that other software objects can later reference the rows used to create each data object in data collection 13C. Data objects in data collection 13C contain the transaction type and the sum of the net, gross, and fee amounts of each row used to create that data object. For example, cursor 13 A contains rows A, B, and C. The row combinations now in the data collection 13C as new data objects are A, B, C, AB, AC, BC, and ABC. Software object 1010 communicates the completion of its operation to software object 1020. Software object 1020 then acts to create data cursor "13B" by doing an SQL Select on the database 16 to select all fields and all rows from the ReconcUiation Data Tb where the Table Code column in the Reconcihation Data Tb table is equal to the input paramater Source_Table_Code_l, and there is no match in the Reconciliation DataJVIatches Tb table for Source Table Code __2. Software object 1020 accepts two Source Table Codes and one BatchJSTumber as parameters. The two Source_Table_Codes are those that software object 950 is doing the complex match on and the BatchJSTumber is the current one. Software object 1020 performs the same SQL select as was performed by software object 1000 with the exception that software object 1020 reverses the two input paramaters, Source_Table_Code_l and Source_Table_Code_2.
Software object 1020 communicates the completion of its operation to software object 1030. Software object 1030 then queries the UserJPreferenceJTb table to select the acceptable date range for comparing Dates to each other. There is no need, and it would consume excessive processing power to attempt to match dates that are too far apart, i.e. more than 2 weeks apart. In the example of the preferred embodiment "real time" processing of transactions, whether they be credit card or cash, is assumed. For other applications, the timing between matching transactions may be greater, as for example where credit card charge shps (hand swiped) are accumulated for a month or more and then submitted for processing. Software object 1030 acts to remove from consideration in the complex matching process data objects in Cursor 13 A and 13B that are outside the acceptable date range. Software object 1030 acts to communicate the completion of its operation to software object 1040. Software object 1040 then acts to check cursor 13B for End Of FUe. If End Of File has been reached, software object 1040 communicates 955 this fact to software object 910 (see Fig. 12). If End Of FUe has not been reached, software object 1040 communicates 1050 this fact to software object 1060. Software object 1060 then acts to move to read the next row in cursor 13B. Each row of data in cursor 13B contains the BatchJNumber, MerchantJSTumber, TransactionJDate, Transaction_Type_Code, gross, net and fee amounts and software object 950 attempts to match that row of data against the data objects in data collection 13C. Once software object 1060 retrieves the data from the next row in the cursor 13B, it communicates that fact to software object 1070. Software object 1070 then acts to set up local variables, set the Match Counter = 0, set the Match Index = 0, and set the Loop Counter = 0. The Match Counter is a counter used to accumulate the number of times that software object 950 finds a unique match. The Match Index is used to point to the data object's index in the data coUection 13C when a match is found. The Loop Counter is used to loop through the data coUection 13C. Once software object 1070 has completed its action, it communicates this fact to software object 1080. Software object 1080 increments the Loop Counter by one. Upon completion of its incrementing the Loop Counter by one, software object 1080 communicates the completion of its action to software object 1090.
Software object 1090 checks the Loop Counter to make sure it is less than or equal to the number of data objects in data collection 13C. If the Loop Counter is less than or equal to the number of data objects in data coUection 13C then software object 1090 commumcates 1100 this fact to software object 1200 (see Fig. 13b). If the Loop Counter is not less than or equal to the number of data objects in data coUection 13C then software object 1090 communicates 1110 this fact to software object 1120. Software object 1120 then acts to check for the condition match counter equal to one. This is done because if more than one match is encountered, the match is not unique and must be rejected. The instant invention only commits to a match if there is one unique match between the current data row in cursor 13B and a data row in data collection 13C. If the Match Counter equals one, then software object 1120 will communicate 1130 that fact to software object 1150. If the match counter is not one, software object 1120 will communicate 1140 that fact to software object 1040. Upon receipt of communication 1130 from software object 1120, software object 1150 acts to execute two sets of SQL Inserts into the ReconcUiationJDataJ IatchesJTb table using the Data TD from the current row in cursor 13B and the Data D(s) from the data row(s) contained in the data object found at the Match Index in data collection 13C. Software object 1150's first SQL Insert wUl insert into the Reconcihation Data Matches Tb table the current BatchJSTumber, the DataJD field from cursor 13B and the Data D(s) from the data row(s) in the data object found at the Match Index in data coUection 13C into the columns BatchJNumber, Data D_l and DataJDD_2, respectively. There will be exactly one SQL insert for every row that makes up the data object found at the Match Index position in data collection 13C. The second SQL Insert being performed by software object 1150 wUl insert into the Reconcihation Data Matches Tb table the current BatchJSTumber, the DataJD from cursor 13B and the DataJD(s) from the data row(s) in the data object found at the Match Index in data coUection 13C into columns BatchJSTumber, Data TD_2 and Data TD l, respectively. Software object 1150 commumcates the completion of its two SQL Inserts to software object 1160. Software object 1160 then acts to remove the data object found at Match Index from the data collection 13C so that no attempt is made to perform a match on the data object in subsequent loops. Software object 1160 communicates the completion of its action to software object 1040. Software object 1040 then, again, acts to determine whether End Of FUe has been reached in cursor 13B, and, if not, another cycle (including incrementing the Loop Counter) is begun.
If software object 1090 checked the Loop Counter to make sure it is less than or equal to the number of data objects in data collection 13C and determined that the Loop Counter is less than or equal to the number of data objects in data collection 13 C then software object 1090 communicates 1100 this fact to software object 1200 (see Fig. 13b). Software object 1200 then acts to create data object 13D from data coUection 13C by selecting the data object where the Loop Counter value is equal to the index number in the data coUection 13C. Once software object 1200 has created data object 13D, it communicates this fact to software object 1220. Software object 1220 uses the date range set in software object 1030 (Fig. 13a) to check all data rows used to create data object 13D to make sure the data rows are within the acceptable date range of the transaction date found in the current row of cursor 13B. If software object 1220 determines that the date range is outside the acceptable data range set by software object 1030 (Fig. 13a), then software object 1220 will communicate 1170 this fact to software object 1080 (Fig. 13a). If software object 1220 determines that the date range is inside the acceptable data range set by software object 1030, then software object 1220 wiU communication 1230 this fact to software object 1240. Software object 1240, upon receipt of communication from software object 1220, acts to compare the BatchJSTumber, MerchantJSTumber, Net, Gross, and Fee amounts contained in the data object 13D to the corresponding fields of the current row in cursor 13B. If ah of the values in the compared fields in data object 13D and cursor 13B are equal then software object 1240 communicates Line 1250 this fact to software object 1260. If any one of the values in the fields compared is not equal then software object 1240 w l communicate 1180 this fact to software object 1080 (Fig. 13a). Upon receipt of communication 1250 from software object 1240, software object 1260 acts to increment the Match Counter by one. The increment is one because if more than one match were found, no rows of data are considered a match. A unique match is required by the instant invention. After software object 1260 has incremented the Match Counter, it communicates this fact to software object 1270. Software object 1270 then acts to set the Match Index value equal to the value of the Loop Counter, saving the current index so that the object (value of the Loop Counter) can later be referenced if a unique match if found. Software object 1270 then communicates 1190 the completion of its action to software object 1080. Fig. 14a and Fig. 14b form a single flow chart depicting in detail the operation of software object 260 (see Fig. 5b). Upon receipt of communication 200 from software object 195, software object 260 acts to clean up the working tables used throughout the reconciliation and archive aU reconcihation data tables and label aU of the transactions (records) that have been matched as cleared, aU in preparation for the next reconcihation to be performed. The detailed operation of software object 260 begins with the receipt of communication 200 by software object 1300, a Child of software object 260. Software object 1300 executes an SQL Select of the User TD, Bank Account, and Reconcihation Code from the ReconciliationsJTb table using the current BatchJSTumber. Once software object 1300 has completed its execution, it commumcates this fact to software object 1305. Software object 1305 then acts to begin the transaction. When software object 1305 has completed its execution, it communicates this fact to software object 1310. Software object 1310 then acts to execute an SQL Insert to copy data (transaction totals) from the ReconciliationJDataJTb table into the Reconciliation JReport JDataJTb table for future use in creating reports. The SQL Insert functions to create exact copies of the data from the ReconciliationJDataJTb table into the Reconciliation ^Report JDataJTb table. After software object 1310 has completed its execution, it communicates this fact to software object 1315. Software object 1315 then acts to retrieve the SQL Return Code. Once software object 1315 has retrieved the SQL Return Code, it communicates the completion of its execution to software object 1320. Software object 1320 then acts to execute an SQL Insert which copies data from the Reconciliation JDataJVIatchesJTb table into the Reconcihation_ReportJVIatches_Tb table for future use in creating reports. The SQL Insert functions to create exact copies of the rows from the Reconcihation JDataJVIatchesJTb table into the
ReconcUiation_Report_Matches_Tb table. After software object 1320 has completed its execution, it communicates this fact to software object 1325. Software object 1325 then acts to retrieve the SQL Return Code. Once software object 1325 has retrieved the SQL Return Code, it commumcates the completion of its execution to software object 1330. Software object 1330 then acts to commit the transaction. In this fashion, the transaction is not committed until we are assured that aU data has been backed up and that no errors have occurred. After software object 1330 commits the transaction, it communicates this fact to software object 1335. Upon receipt of communication from software object 1330, software object 1335 acts to buUd a cursor by executing an SQL Select on the ReconcUiation_Associations_Tb table where the Reconciliation_Code in the ReconcUiation_Associations_Tb table is equal to the local variable Reconcihation_Code , returning the Table_Codes of aU of the data tables that were included in the reconcihation; these Table_Codes are used to loop through each table used in the current reconcihation. After software object 1335 has completed its execution, it communicates this fact to software object 1340. Software object 1340 then acts to check for End Of File (EOF). If software object 1340 detects End Of FUe (EOF), it communicates 1350 this fact to software object 1400. If software object 1340 does not detect End Of FUe (EOF), it communicates 1360 this fact to software object 1370.
Upon receipt of communication 1360 from software object 1340, software object 1370 (Fig. 14b) acts to retrieve the next Table Code from the cursor created by software object 1335 (Fig!4a). After software object 1370 has retrieved the next Table_Code from the cursor, it communicates this fact to software object 1380. Software object 1380 then acts to execute an SQL Select on the ReconcUiation JData_Tables_Tb table returning the Ending Procedure name for the Table Code in the current row of the cursor. After software object 1380 has retrieved the ending procedure name from the Reconcihation Data Tables Tb table, it communicates 1385 this data to software object 1390. Software object 1390, upon receipt of communication 1385 from software object 1380, acts to execute the EndingJProcedure retrieved by software object 1380 (see details at Fig. 15). Once software object 1390 has completed its execution, it communicates 1395 that fact to software object 1340 (Fig. 14a). Upon receipt of communication 1350 from software object 1340 (Fig. 14a), software object 1400 acts to close the cursor created by software object 1335 (Fig. 14a). Once software object 1400 has closed the cursor created by software object 1335, it communicates this fact to software object 1405. Software object 1405 then acts to begin the transaction. When software object 1405 has completed its execution, it communicates 1410 this fact to software object 550 (detaUs of the operation of software object 550 are depicted in Fig. 16).
Software object 550, after receipt of communication 1410 from 1405, then acts to delete rows from the ReconcUiation JData Tb table and the Reconcihation JDataJVIatchesJTb table for
■ the current BatchJSTumber (backup has already occurred). Upon completion of its execution, software object 550 communicates 1425 the fact of completion to software object 1430. Software object 1430 then acts to execute an SQL Update on the ReconcUiation Tb table, inserting a closed flag and the date of the completed reconcihation for the current BatchJSTumber. Once software object 1430 has completed its execution, it communicates that fact to software object 1440. Software object 1440 upon receipt of communication from software object 1430 acts to commit the transaction. After software object 1440 has committed the transaction, it communicates 265 this fact to software object 270 (Fig. 5b).
Fig. 15 depicts in detaU the operation of software object 1390. Software object 1500 is the Child of software object 1390 (see Fig. 14b) and receives communication 1385 from software object 1380. The function of the software objects depicted in Fig. 15 is to execute the EndingJProcedure for the reconciliation process where the local variable Input Parameter 1 (in Fig. 15) is a Table_Code. The routines depicted in detail in Fig. 15 are for the three major reconcihations, Bank, Ledger and POS. The software of the instant invention has been designed to permit an unlimited number of "Other" data sources which can be optionally included in the reconcihation process. Upon receipt of communication 1385 from software object 1380, software object 1390 acts to select its output communication hne on case equal the input parameter. Tf software object 1500 determines that the input parameter is "Other" Table Code then software object 1500 wiU communicate 1505 its input data to software object 1515. If software object 1500 determines that the input parameter is "Bank" Table Code then software object 1500 wiU communicate 1510 its input data to software object 1540. Tf software object 1500 determines that the input parameter is 'TOS" Table_Code then software object 1500 wUl communicate 1520 its input data to software object 1610. If software object 1500 determines that the input parameter is "Ledger" Table Code then software object 1500 wUl communicate 1530 its input data to software object 1680. Software object 1500's input data consists of the current BatchJSTumber and Table Code. Software object 1515 is displayed on Fig. 15 only to reflect that for each Other data type and source, another simUar set of software objects must be utihzed as is utilized for Bank, POS, or Ledger data. Beginning the description of the operation of the software objects depicted in Fig. 15 with the assumption that "Bank" Table Code is received by software object 1500 as Input Parameterl, software object 1500 then acts to determine that such data should be communicated 1510 to software object 1540 and so commumcates 1510 the data. Software object 1540, upon receipt of the communicated 1510 data from software object 1500, acts to execute an SQL Select Set of the local variables UserJD, Bank_AccountJSTumber, Reconciliation_Code from the Reconcihation_Tb table by using the current BatchJSTumber. Upon completion of its execution, software object 1540 communicates that fact to software object 1550. Software object 1550 upon receipt of communication from software object 1540 acts to perform an SQL Select on the Reconcihation Data _Tb table summing the transaction net amount for the current BatchJSTumber and Table Code. Software object 1550 stores the sum in the local variable ReconcUiation Amount. Upon completion of its execution software object 1550 communicates that fact to software object 1560. Software object 1560 then acts to begin the transaction. Once software object 1560 has completed its execution, it communicates that fact to software object 1570. Software object 1570 then acts to perform an SQL Update on the Reconcihation Tb table where the BatchJSTumber in the ReconciliationJTb table is equal to the current BatchJSTumber, setting the BankJBatch Ending Amt equal to the ReconcUiation Amount calculated in software object 1550. Upon completion of its execution, software object 1570 then communicates that fact to software object 1575. Software object 1575 then acts to retrieve the SQL Return Code. Once software object 1575 has retrieved the SQL Return Code, it communicates that fact to software object 1580. Software object 1580 then acts to execute an SQL Insert into the Reconciliation_Cleared JDataJTb table. The source code for the SQL Insert executed by software object 1580 is depicted in Fig. 46. The SQL Insert by software object 1580 is done so that the same data rows don't get puUed (selected) in the future. The Reconciliation ClearedJData Tb table consists of the following columns: Reconciliation -^ode, Table_Code, and RowJDD. The RowJ is the equivalent of the primary key from a source table indicated by the Table Code. The same data rows can again be included in a reconcihation defined by a different ReconcUiation_Code. Once a transaction has been cleared it can be included in new reconciliation of a different type as long as the transaction has not been included in a reconcihation of all accounts. Once a transaction has been included in a reconcUiation of aU accounts, it wUl no longer be avaUable in future reconcUiations of any type. Once software object 1580 has completed its execution, it communicates that fact to software object 1590. Software object 1590 then acts to retrieve the SQL Return Code. Software object 1590 then commumcates the fact that it has retrieved the SQL Return Code to software object 1600. Software object 1600 then acts to commit the transaction. After software object 1600 has committed the transaction, it communicates 1395 this fact to software object 1340 (Fig. 14a).
If it is assumed that "POS" Table_Code is received by software object 1500 as Input Parameter 1, software object 1500 then acts to determine that such data should be communicated 1520 to software object 1610 and so communicates 1520 the data. Software object 1610, upon receipt of the communicated 1520 data from software object 1500, acts to execute an SQL Select Set of the local variables UserJD, Bank_Account JSTumber, and Reconcihation Code from the Reconciliation Tb table by using the BatchJNumber. Upon completion of its execution, software object 1610 communicates that fact to software object 1620. Software object 1620 upon receipt of commumcation from software object 1610 acts to perform an SQL Select on the ReconcUiation JDataJTb table summing up the transaction net amount for the current BatchJSTumber and Table_Code. Software object 1620 stores the sum in the local variable ReconcUiation_Amount. Upon completion of its execution software object 1620 commumcates that fact to software object 1630. Software object 1630 then acts to begin the transaction. Once software object 1630 has completed its execution, it communicates that fact to software object 1640. Software object 1640 then acts to perform an SQL Update on the Reconcihation Tb table where the BatchJSTumber in the ReconciliationJTb table is equal to the local variable BatchJSTumber, setting the POS_Batch_Ending_Amt equal to the Reconciliation Amount calculated in software object 1620. Upon completion of its execution, software object 1640 then communicates that fact to software object 1645. Software object 1645 then acts to retrieve the SQL Return Code. Once software object 1645 has retrieved the SQL Return Code, it communicates that fact to software object 1650. Software object 1650 then acts to execute an SQL Insert. The source code for the SQL Insert executed by software object 1650 is depicted in Fig. 47. The SQL Insert by software object 1650 is done so that the same rows don't get selected in the future. The ReconcUiationJTb table consists of the foUowing columns:Reconciliation_Code, Table_Code, and Row D. The same data rows can again be included in a new reconciliation defined by a different Reconciliation_Code, provided however that once a data row is cleared in a reconcUiation of aU accounts it cannot thereafter be used as an uncleared data row in any reconcUiation. Once software object 1650 has completed its execution, it communicates that fact to software object 1660. Software object 1660 then acts to retrieve the SQL Return Code. Software object 1660 then communicates the fact that it has retrieved the SQL Return Code to software object 1670. Software object 1670 then acts to commit the transaction. After software object 1670 has committed the transaction, it communicates 1395 this fact to software object 1340 (Fig. 14a).
If it is assumed that "Ledger" Table_Code is received by software object 1500 as Input Parameterl, software object 1500 then acts to determine that such data should be communicated 1530 to software object 1680 and so communicates 1530 the data. Software object 1680, upon receipt of the communicated 1530 data from software object 1500, acts to execute an SQL Select Set of the local variables UserJQD, Bank_AccountJSfumber, Reconcihation Code from the Reconcihation_Tb table by using the BatchJNumber. Upon completion of its execution, software object 1680 communicates that fact to software object 1690. Software object 1690 upon receipt of communication from software object 1680 acts to perform an SQL Select on the Reconciliation Data Tb table summing up the transaction net amount for the current BatchJSTumber and Table_Code. Software object 1690 stores the sum in the local variable Reconcihation_Amount. Upon completion of its execution software object 1690 communicates that fact to software object 1700. Software object 1700 then acts to begin the transaction. Once software object 1700 has completed its execution, it communicates that fact to software object 1710. Software object 1710 then acts to perform an SQL Update on the Reconcihation Tb table where the BatchJNumber in the ReconcUiation Tb table is equal to the local variable BatchJSTumber, setting the Ledger Batch Ending Amt equal to the ReconcUiation Amount calculated in software object 1690. Upon completion of its execution, software object 1710 then communicates that fact to software object 1715. Software object 1715 then acts to retrieve the SQL Return Code. Once software object 1715 has retrieved the SQL Return Code, it communicates that fact to software object 1720. Software object 1720 then acts to execute an SQL Insert. The source code for the SQL Insert executed by software object 1720 is depicted in Fig. 48. The SQL Insert by software object 1720 is done so that the same rows don't get selected in the future. The Reconcihation Tb table consists of the foUowing columns:ReconcUiation_Code, Table Code, and RowJDD. The same data rows can again be included in a new reconcUiation defined by a different Reconcihation_Code, provided however that once a data row is cleared in a reconcUiation of aU accounts it cannot thereafter be used as an uncleared data row in any reconcUiation. Once software object 1720 has completed its execution, it communicates that fact to software object 1730. Software object 1730 then acts to retrieve the SQL Return Code. Software object 1730 then communicates the fact that it has retrieved the SQL Return Code to software object 1740. Software object 1740 then acts to commit the transaction. After software object 1740 has committed the transaction, it communicates 1395 this fact to software object 1340 (Fig. 14a).
Fig. 16 depicts in detaU the operation of software object 550. Software object 1800 is the ChUd of software object 550 (see Fig. 9) and receives communication 545 from software object 540 OR communication 605 from software object 600 OR communication 665 from software object 660 OR communication 1410 from software object 1405 (Fig. 14b). The function of software object 550 is to reset the ReconcUiation Data Tb table and the ReconcUiation JDataJVIatchesJTb table by deleting data that is in both tables. Software object 550 accepts as an input parameter the current BatchJSTumber and an optional input parameter of Table_Code. If software object 550 does not receive the optional Table Code input, it wiU act to delete aU rows from both tables equal to the current BatchJSTumber; alternatively, if software object 550 does receive a Table Code it wUl act to delete only the data equal to that Table_Code for the current BatchJSTumber. Upon receipt of communication 545 OR communication 605 OR communication 665 OR communication 1410, software object 1800 wiU communicate such received data to software object 1805. Software Object 1805 wiU then act to begin the transaction. Once software object 1805 has completed its execution, it wUl communicate that fact to software object 1810. Software object 1810 will then act to check the parameter passed initially into software object 1800, if the Table_Code parameter passed into software object 1800 was not null software object 1810 will communicate 1830 that fact to software object 1860. If the Table Code parameter passed into software object 1800 was null software object 1810 wUl communicate 1820 that fact to software object 1840. Upon receipt of communication 1830 from software object 1810, software object 1860 acts to execute an SQL Delete from the ReconcUiation JDataJVIatchesJTb table joining to the ReconcUiation JDataJTb table on the DataJD column in the ReconcUiaton JData _Tb equal to the Data TD l column in the Reconciliation^ DataJVIatchesJTb where the BatchJSTumber in the Reconcihation Data Tb is equal to the local variable BatchJSTumber and the Table_Code column in the ReconciliationJDataJTb is equal to the local variable Table_Code. This means that if the 'Ηank" Table_Code was communicated into software object 1800, it would be detected by software object 1810 and software object 1860 would act to delete only bank data from the Reconcihation JVIatchesJTb table equal to the current BatchJSTumber. When software object 1860 completes its execution, it communicates that fact to software object 1862. Software object 1862 then acts to retrieve the SQL Return Code. Software object 1862 then communicates the fact that it has retrieved the SQL Return Code to software object 1864. Software object 1864, upon receipt of communication from software object 1862, then acts to to execute an SQL Delete from the Reconciliation_Data JVIatchesJTb table joining to the ReconciliationJDataJTb table on the Data JDD column in the ReconcUiaton Data Tb equal to the Data D_2 column in the Reconcihation JData JVIatchesJTb where the BatchJSTumber in the ReconciliationJDataJTb is equal to the local variable BatchJSTumber and the Table_Code column in the ReconcUiation JData Tb is equal to the local variable Table_Code. Note that when the join was done in the first delete by software object 1860; it was joining to the Data TD l equal to Data TD field and the Reconcihation JVIatchesJTb table and that deleted half of the data. In order to get the other half of data, software object 1864 joins to Data_TD_2 field in the ReconcUiation JVIatchesJTb table. Upon completion of its execution, software object 1864 communicates that fact to software object 1866. Software object 1866, upon receipt of communication from software object 1864, acts to retrieve the SQL Return Code. Software object 1866 then communicates the fact that it has retrieved the SQL Return Code to software object 1870. Software object 1870 then acts to execute an SQL Delete on the Reconciliation JDataJTb table where the BatchJSTumber column in the Reconcihation Data Tb is equal to the local variable BatchJSTumber and the Table Code column in the ReconcilationJData Tb is equal to the lcoal variable Table_Code. Upon completion of its execution, software object 1870 then communicates that fact to software object 1875. Software object 1875, upon receipt of communication from software object 1870, acts to retrieve the SQL Return Code. Software object 1875 then communicates the fact that it has retrieved the SQL Return Code to software object 1880.
Software object 1840, upon receipt of communication 1820 from software object 1810, acts to execute an SQL Delete on aU rows in the Reconcihation _Data JVIatchesJTb table where the BatchJSTumber column is equal to the local variable BatchJSTumber. Once software object 1840 has completed its execution, it communicates that fact to software object 1845. Software object 1845, upon receipt of communication from software object 1840, acts to retrieve the SQL Return Code. Software object 1845 then communicates the fact that it has retrieved the SQL Return Code to software object 1850. Software object 1850, upon receipt of communication from software object 1845, acts to execute and SQL Delete on all rows in the ReconcUiation JData Tb table where the BatchJSTumber column in the ReconciliationJDataJTb is equal to the local variable BatchJSTumber. Once software object 1850 has completed its execution, it communicates that fact to software object 1855. Software object 1855, upon receipt of communication from software object 1850, acts to retrieve the SQL Return Code. Software object 1855 then communicates the fact that it has retrieved the SQL Return Code to software object 1880.
Software object 1880, upon receipt of communication from software object 1855 OR software object 1875 acts to commit the transaction. Once software object 1880 has completed its execution, it communicates that fact to software object 1890. Software object 1890, upon receipt of commumcation from software object 1880, acts to select a communication path out on case communication path into software object 1800, as follows: communication path in communication path out 545 555
605 615
665 675
1410 1425
Which results in software object 1890 providing an output communication 555 to software object 560 in the case that software object 540 provided a commumcation 545 into software object 550 OR in software object 1890 providing an output commumcation 615 to software object 620 in the case that software object 600 provided a communication 605 into software object 550 OR in software object 1890 providing an output communication 555 to software object 680 in the case that software object 660 provided a communication 665 into software object 550 OR in software object 1890 providing an output communication 1425 to software object 1430 in the case that software object 1405 provided a commumcation 1410 into software object 550.
Fig. 17 depicts the operation of the Bank data User input screen; where the user can select to input Bank data via an on-screen menu item or button. Communication 2000 is the User Input selecting the Bank data input screen and commencing execution of software object 2010. When activated by a User Input, software object 2010 creates a User input screen for the input of Bank data. The User input screen created by software object 2010 also provides for a User selection of either a "save" command or a "cancel" command. Once software object 2010 has created the User input screen, it commumcates this fact to software object 2020. The User Input, including both Bank data and a "save" or "cancel" command, is communicated 2015 to software object 2020. Software object 2020 acts to accept the User Input. Upon software object 2020 receiving User Input which is either a :"save" or "cancel" command, it communicates this fact together with the User Input to software object 2030. Upon software object 2030 receiving communication from software object 2020, software object 2030 communicates 2040 the Bank data to software object 80 if the User Input included the command "save". If, alternatively, the User Input included the command "cancel", then software object 2030 communicates 2050 the Bank data to software object 2080. Software object 80 acts to inserts the Bank data into the BankJTb table of the database 16. Details of the operation of software object 80 are depicted in Fig. 21. Upon completion of the insertion of the Bank data into the BankJTb table, software object communicates 2070 the fact of completion to software object 2080. Upon receipt of either communication 2050 from software object 2030 OR communication 2070 from software object 80, software object 2080 acts to close the User input screen.
Fig. 18 depicts the operation of the POS data User input screen; where the user can select to input POS data via an on-screen menu item or button. Communication 2100 is the User Input selecting the POS data input screen and commencing execution of software object 2110. When activated by a User Input, software object 2110 creates a User input screen for the input of POS data. The User input screen created by software object 2110 also provides for a User selection of either a "save" command or a "cancel" command. Once software object 2110 has created the User input screen, it communicates this fact to software object 2120. The User Input, including both POS data and a "save" or "cancel" command, is communicated 2115 to software object 2120. Software object 2120 acts to accept the User Input. Upon software object 2120 receiving User Input which is either a :"save" or "cancel" command, it communicates this fact together with the User Input to software object 2130. Upon software object 2130 receiving commumcation from software object 2120, software object 2130 communicates 2140 the POS data to software object 82 if the User Input included the command "save". If, alternatively, the User Input included the command "cancel", then software object 2130 commumcates 2150 the POS data to software object 2180. Software object 82 acts to insert the POS data into the ProcessorJTb table of the database 16. DetaUs of the operation of software object 82 are depicted in Fig. 22. Upon completion of the insertion of the POS data into the ProcessorJTb table, software object 82 communicates 2170 the fact of completion to software object 2180. Upon receipt of either communication 2150 from software object 2130 OR communication 2170 from software object 82, software object 2080 acts to close the User input screen.
Fig. 19 depicts the operation of the Ledger data User input screen; where the user can select to input Ledger data via an on-screen menu item or button. Communication 2200 is the User Input selecting the Ledger data input screen and commencing execution of software object 2210. When activated by a User Input, software object 2210 creates a User input screen for the input of Ledger data. The User input screen created by software object 2210 also provides for a User selection of either a "save" command or a "cancel" command. Once software object 2210 has created the User input screen, it communicates this fact to software object 2220. The User Input, including both Ledger data and a "save" or "cancel" command, is communicated 2215 to software object 2220. Software object 2220 acts to accept the User Input. Upon software object 2220 receiving User Input which is either a :"save" or "cancel" command, it communicates this fact together with the User Input to software object 2230. Upon software object 2230 receiving communication from software object 2220, software object 2230 communicates 2240 the Ledger data to software object 84 if the User Input included the command "save". If, alternatively, the User Input included the command "cancel", then software object 2230 communicates 2250 the Ledger data to software object 2280. Software object 84 acts to insert the Ledger data into the LedgerJTb table of the database 16. DetaUs of the operation of software object 84 are depicted in Fig. 23. Upon completion of the insertion of the Ledger data into the LedgerJTb table, software object 84 communicates 2270 the fact of completion to software object 2280. Upon receipt of either communication 2250 from software object 2230 OR communication 2270 from software object 84, software object 2280 acts to close the User input screen.
Figs. 20a, 20b, and 20c are three pages of a single flow chart depicting in detail the operation of a merchant set-up wizard for the input of data by User for new Merchant Numbers. The User can, through use of this set-up wizard set up numerous items; the User can set up new Partners, new Agreements, new Terminals, new Bank Accounts, new Ledger Accounts, new Merchant Accounts, and new Users. AdditionaUy, through this set-up wizard, the User can input additional Merchant Numbers for the same terminal, more Terminals for the same Partner, and add additional Merchant Partners. Note that there are several different "Partner IDs". There may be a master Partner_ID for each corporate customer, merchant location, customer bank, and electronic payment processor. "MerchantJPartnerJD" is the variable name utihzed for each merchant location, "Bank Partner lD" is the variable name utihzed for each Bank partner, and "Processor Partner TD" is the variable name utilized for each Processor partner.
As seen in Fig. 20a, operation of the set-up wizard is commenced by communication 3000 as User Input selecting operation of the set-up wizard. Communication 3000 is received by software object 3010 which acts to display an input screen inquiring of the User whether the new input data is for a new Merchant Partner. Software object 3010 may, alternatively, begin execution upon receipt of communication 3300 from software object 3290 which communicates 3300 that additional new Merchant Partners need to be set-up. The User responds to the input screen inquiry created by software object 3010 by communication 3005 to software object 3010, selecting either "Yes" or "No". If the User communicated 3005 a "Yes" to software object 3010, then software object 3010 communicates 3020 the completion of its execution to software object 3040. If the User communicated 3005 a "No" to software object 3010, the software object 3010 communicates 3030 the completion of its execution to software object 3050. Software object 3040, upon receipt of communication 3020, acts to create the input screens necessary for the User to input the data for a new Merchant Partner. The detaUs of the operation of software object 3040 are depicted in Fig. 26. Software object 3040 communicates 3045 the fact of the completion of its execution to software object 3050. Software object 3050, upon receipt of commumcation 3030, acts to accept User input via communication 3055. The User input to software object 3050 is the User's selection of an existing Merchant_PartnerJD to setup or if the User had just completed setup of a new Merchant Partner, then the newly estabhshed (by software object 3040) Merchant PartnerJD is communicated 3045 to software object 3050. Software Object 3050, upon receipt of the Merchant JPartnerJDD, via either communication 3045 OR communication 3055, communicates the Merchant_PartnerJD to software object 3050. In the instant invention, a Merchant Partner is a merchant location. That is, a single merchant may have multiple locations, each location generating point of sale data, and each location would then be assigned a separate Merchant Partner TD. Software object 3050 communicates its received Merchant Partner JD to software object 3060.
Software object 3060 then acts to inquire of the User whether a new processor agreement is being set up for this merchant location. The User communicates 3065 either a "Yes" or a "No" to software object 3060 in response to the inquiry. Software object 3060 then communicates 3070 the completion of its execution to software object 3090 if the User communication 3065 was "Yes" or communicates 3080 the completion of its execution to software object 3100 if the User commumcation 3065 was "No". Software object 3090, upon receipt of communication 3070, acts to create the input screens necessary for the User to input the data for a new processor agreement. The detaUs of the operation of software object 3090 are depicted in Fig. 27. Software object 3090 communicates 3095 the fact of the completion of its execution to software object 3100. Software object 3100, upon receipt of communication 3095, acts to accept User input via communication 3105. The User input to software object 3100 is the User's selection of an existing AgreementJD to use or if the User had just completed setup of a new Merchant Agreement, then the newly estabhshed (by software object 3090) AgreementJD is communicated 3095 to software object 3100. Software Object 3100, upon receipt of the AgreementJD, via either communication 3095 OR communication 3105, communicates the AgreementJD to software object 3110. In the instant invention, a Merchant Agreement is a contract with a processor. That is, a single merchant may, and usuaUy wiU, have multiple contracts with multiple processors of ATM, credit, debit, and cash cards. Each Merchant Agreement would be assigned a separate Agreement D .
Software object 3100 communicates the completion of its execution to software object 3110 which then acts to display an input screen inquiring of the User whether the new input data is for a new Terminal. The User responds to the input screen inquiry by communication 3115 to software object 3110, selecting either "Yes" or "No". If the User communicated 3115 a "Yes" to software object 3110, the software object 3110 communicates 3120 that fact to software object 3140. If the User communicated 3115 a "No" to software object 3110, the software object 3110 communicates 3130 that fact to software object 3150. Software object 3110 may, alternatively, begin execution upon receipt of communication 3270 from software object 3260 which commumcates 3270 that additional new Terminals need to be set-up. Software object 3140, upon receipt of communication 3120, acts to create the input screens necessary for the User to input the data for a new Terminal. The details of the operation of software object 3140 are depicted in Fig. 28. Software object 3140 communicates 3145 the fact of the completion of its execution to software object 3150. Software object 3150, upon receipt of commumcation 3130, acts to accept User input via communication 3155. The User input to software object 3150 is the User's selection of an existing Terminal _TD to use or if the User had just completed setup of a new Teiminal, then the newly estabhshed (by software object 3140) Terminal TD is communicated 3145 to software object 3150. Software Object 3150, upon receipt of the Terminal TD, via either communication 3145 OR communication 3155, communicates 3160 the completion of its execution to software object 5600. In the instant invention, a single merchant may have multiple terminals, and thus TerminalJDs, at each of multiple locations. Each terminal, at each location, would then be assigned a separate Terminal JD. Software object 5600 (see Fig. 20b), upon receipt of communication 3160 from software object 3150, then acts to display an input screen inquiring of the User whether the new input data is for a new Bank Account. The User responds to the input screen inquiry by communication 5605 to software object 5600, selecting either 'Υes" or "No". If the User communicated 5605 a "Yes" to software object 5600, the software object 5600 communicates 5610 that fact to software object 5630. If the User communicated 5605 a "No" to software object 5600, then software object 5600 communicates 5620 that fact to software object 5650. Software object 5630, upon receipt of communication 5610, acts to create the input screens necessary for the User to input the data for a new Bank Account. The details of the operation of software object 5630 are depicted in Fig. 32. Software object 5630 communicates 5640 the fact of the completion of its execution to software object 5650. Software object 5650, upon receipt of communication 5620, acts to accept User input via communication 5655. The User input to software object 5650 is the User's selection of an existing Bank_Account_ ED to use or if the User had just completed setup of a new Bank Account, then the newly established (by software object 5630) Bank Account ED is communicated 5640 to software object 5650. Software Object 5650, upon receipt of the Bank Account ED, via either communication 5640 OR communication 5655, communicates the completion of its execution to software object 5665. In the instant invention, a single merchant location may utilize and thus need to be associated with multiple bank accounts. Software object 5660, upon receipt of communication from software object 5650, then acts to display an input screen inquiring of the User whether the new input data is for a new Ledger Account. The User responds to the input screen inquiry by communication 5665 to software object 5660, selecting either 'Yes" or "No". If the User communicated 5665 a "Yes" to software object 5660, then software object 5660 communicates 5670 that fact to software object 5690. If the User communicated 5665 a "No" to software object 5660, then software object 5660 communicates 5680 that fact to software object 5710. Software object 5690, upon receipt of communication 5670, acts to create the input screens necessary for the User to input the data for a new Ledger Account. The detaUs of the operation of software object 5690 are depicted in Fig. 34. Software object 5690 communicates 5700 the fact of the completion of its execution to software object 5710. Software object 5710, upon receipt of communication 5680, acts to accept User input via communication 5715. The User input to software object 5710 is the User's selection of an existing Ledger_Account_ ED to use or if the User had just completed setup of a new Ledger Account, then the newly established (by software object 5690) Ledger ccount ED is communicated 5700 to software object 5710. Software Object 5710, upon receipt of the Ledger ^ccount lD, via either communication 5700 OR communication 5715, communicates the completion of its execution to software object 3170. In the instant invention, a single merchant location may utihze and thus need to be associated with but a single ledger account. However, one User may choose to associate one Ledger AccountJD with multiple Merchant Partner Ds.
Software object 5710 communicates the completion of its execution to software object 3170 which then acts to display an input screen inquiring of the User whether the new input data is for a new Merchant Number. The User responds to the input screen inquiry by commumcation 3175 to software object 3170, selecting either 'Yes" or "No". Lf the User communicated 3175 a 'Yes" to software object 3170, then software object 3170 communicates 3180 that fact to software object 3200. If the User communicated 3175 a "No" to software object 3170, then software object 3170 communicates 3190 that fact to software object 3210. Software object 3170 may, alternatively, begin execution upon receipt of communication 3240 from software object 3230 which communicates 3240 that additional new Merchant Numbers need to be set up for the same Terminal. Software object 3200, upon receipt of communication 3180, acts to create the input screens necessary for the User to input the data for a new Merchant Number. The details of the operation of software object 3200 are depicted in Fig. 29. Software object 3200 communicates 3205 the fact of the completion of its execution to software object 3210. Software object 3210, upon receipt of communication 3190, acts to accept User input via communication 3195. The User input to software object 3210 is the User's selection of an existing MerchantJSTumber to use or if the User had just completed setup of a new MerchantJSTumber, then the newly established (by software object 3200) MerchantJSTumber is communicated 3205 to software object 3210. Software Object 3210, upon receipt of the MerchantJSTumber, via either commumcation 3205 OR communication 3195, commumcates 3215 the completion of its execution to software object 3220. In the instant invention, a single terminal may have multiple Merchant Numbers, and thus MerchantJNumbers, assigned to it. A single MerchantJSTumber may also be assigned to a terminal group consisting of multiple terminals.
Software object 3220 (see Fig. 20c), upon receipt of communication 3215 from software object 3210, then acts to execute SQL Inserts of aU of the selected table associations created by software objects 3010, 3100, 3150, 5650, 5710, and 3210. The detaU of the operation of software object 3220 is depicted in Fig. 31. Software object 3220 communicates 3225 the completion of its execution to software object 3230. Software object 3230, upon receipt of communication 3225 from software object 3220, acts to create a user input screen inquiring whether more Merchant Numbers need to be input for the currently selected (in software object 3150) terminal. The User then commumcates 3235 his selection of "Yes" or "No". If the User communication 3235 is of the selection "Yes", then software object 3230 communicates 3240 that fact to software object 3170. If the User communication 3235 is of the selection "No", then software object 3230 commumcates 3250 that fact to software object 3260. Software object 3260, upon receipt of communication 3250 from software object 3230, acts to create a user input screen inquiring whether more Terminals need to be input for the currently selected (in software object 3050) Merchant Partner. The User then commumcates 3265 his selection of 'Yes" or "No". If the User communication 3265 is of the selection "Yes", then software object 3260 communicates 3270 that fact to software object 3110. If the User communication 3265 is of the selection "No", then software object 3260 communicates 3280 that fact to software object 3290. Software object 3290, upon receipt of communication 3280 from software object 3260, acts to create a user input screen inquiring whether more Merchant Partners need to be input. The User then communicates 3295 his selection of "Yes" or "No". If the User communication 3295 is of the selection 'Yes", then software object 3290 communicates 3300 that fact to software object 3010. If the User commumcation 3295 is of the selection "No", then software object 3290 communicates 3310 that fact to software object 3320. Software object 3320, upon receipt of communication 3310 from software object 3290, acts to close the user input screen, and terminates execution of the setup wizard. Fig. 21 depicts in detaU the operation of software object 80, which acts to insert Bank data into the BankJTb table of the database 16. Software object 3700 is the ChUd of software object 80 and receives communication 74 from software object 72 (see Fig. 4) OR communication 2040 from software object 2030 (see Fig. 17) OR communication 4560 from software object 4550 (see Fig. 25). Upon receipt of communication 74 OR communication 2040 OR communication 4560, software object 3700 communicates that fact to software object 3710. Software object 3710, upon receipt of communication from software object 3700, acts to setup local variables, Payment_Type_Code, Agreement_ED and OverridingJSTet_GrossJFlag, by executing an SQL Select on the Merchant JSTumbersJTb table and joining to the MerchantsJTb table on the Merchant JPartnerJD column in the MerchantsJTb table equal to the MerchantJPartnerJD column in the MerchantJSTumbersJTb, selecting the Payment_Type_Code, Agreement_ED and OverridingJSTet_GrossJFlag columns, where the MerchantJSTumber column in the MerchantJSTumbesJTb is equal to the MerchantJSTumber provided in the Bank data. Once software object 3710 has completed its execution, it communicates its completion to software object 3720. Software object 3720, upon receipt of commumcation from software object 3710, acts to setup local variables, Discount Rate, Transaction Fee, and Default JSTet_Gross_Flag, by executing an SQL Select on the Agreement_Rates_Tb table, selecting the Discount J ate, Transaction Fee, and the DefaultJSTet_Gross_Flag columns where the Agreement_ED in the AgreementJR.ates_Tb table is equal to the local varaible Agreement TD found in software object 3710 and the Payment_Type_Code in the AgreementJRates Tb is equal to the local variable Payment_Type_Code found in software object 3710. Software object 3720 also determines whether the bank deposit is deposited at gross or net for reconcihation purposes. f the Overriding_Net_GrossJFlag is not NULL then that value wUl be used to determine the calculations in softare object 3730; otherwise, the Default JSTet_GrossJFlag wiU be used. Once software object 3720 has completed its execution, it communicates that fact to software object 3730. Software object 3730, upon receipt of communication from software object 3720, acts to compute the Gross, Net, and Fee amounts for the Bank data to be inserted. If the Bank data was entered at Net value, as determined by software object 3720, then using the Discount Rate and Transaction_Fee from software object 3720, the Fee and Gross amounts are calculated. If the Bank data was entered at Gross value, as determined by software object 3720, then using the DiscountJRate and Transaction Fee from software object 3720, the Fee and Net amounts are calculated. Once software object 3730 has completed its execution, it communicates that fact to software object 3740. Software object 3740, upon receipt of commumcation from software object 3730, acts to begin the transaction. Once software object 3740 has completed its execution, it communicates that fact to software object 3750. Software object 3750, upon receipt of commumcation from software object 3740, acts to execute an SQL Insert of the Bank data, including calculated values for Gross, Net, and Fee amounts from software object 3730, into the BankJTb table. Once software object 3750 has completed its execution, it communicates that fact to software object 3760. Software object 3760, upon receipt of commumcation from software object 3750, acts to retrieve the SQL Return Code. Software object 3760 then commumcates the fact that it has retrieved the SQL Return Code to software object 3770.
Software object 3770, upon receipt of communication from software object 3760 acts to commit the transaction. Once software object 3770 has completed its execution, it communicates that fact to software object 3780. Software object 3780, upon receipt of communication from software object 3770, acts to select a communication path out on case communication path into software object 3700, as foUows: communication path in communication path out 74 85
2040 2070
4560 4600
Which results in software object 3780 providing an output communication 85 to software object 64 in the case that software object 72 provided a communication 74 into software object 3700 OR in software object 3780 providing an output communication 2070 to software object 2080 in the case that software object 2030 provided a communication 2040 into software object 3700 OR in software object 3780 providing an output communication 4600 to software object 4610 in the case that software object 4550 provided a communication 4560 into software object 3700. Fig. 22 depicts in detaU the operation of software object 82, which acts to insert the
POS data into the Processor Tb table of the database 16. Software object 3800 is the Child of software object 82 (see Fig. 4) and receives communication 76 from software object 82 OR communication 2140 from software object 2130 (see Fig. 18) OR communication 4570 from software object 4550 (see Fig. 25). Upon receipt of communication 76 OR communication 2140 OR communication 4570, software object 3800 communicates that fact to software object 3810. Software object 3810, upon receipt of communication from software object 3800, acts to setup local variables, Payment_Type_Code, AgreementJD and OverridingJSTet_Gross_Flag, by executing an SQL Select on the MerchantJSTumbers_Tb table and joining to the MerchantsJTb table on the Merchant PartnerJTD column in the MerchantsJTb table equal to the Merchant_PartnerJD column in the MerchantJSTumbersJTb, selecting the Payment_Type_Code, Agreement ED and OverridingJSTet_Gross_Flag columns, where the MerchantJSTumber column in the MerchantJSTumbesJTb is equal to the MerchantJSTumber provided in the POS data. Once software object 3810 has completed its execution, it communicates its completion to software object 3820.. Software object 3820, upon receipt of communication from software object 3810, acts to setup local variables, Discount JRate, Transaction JFee, and DefaultJSTet_GrossJFlag, by executing an SQL Select on the AgreementJRatesJTb table, selecting the Discount Rate, Transaction Fee, and the DefaultJSTet_GrossJFlag columns where the AgreementJD in the Agreement_RatesJTb table is equal to the local varaible Agreement ED found in software object 3810 and the Payment JType Code in the Agreement_Rates_Tb is equal to the local variable Payment_Tyρe_Code found in software object 3810. Software object 3820 also determines whether the POS data is deposited at gross or net for reconcihation purposes. If the Overriding JSTet_Gross_Flag is not NULL then that value wiU be used to determine the calculations in softare object 3830; otherwise, the Default JSTet_GrossJFlag wiU be used. Once software object 3820 has completed its execution, it communicates that fact to software object 3830. Software object 3830, upon receipt of communication from software object 3820, acts to compute the Gross, Net, and Fee amounts (from the discount rates and transaction fees queried in software object 3820) for the POS data to be inserted. If the POS data was entered at Net value, as determined by software object 3820, then using the Discount_Rate and Transaction Fee from software object 3820, the Fee and Gross amounts are calculated. If the POS data was entered at Gross value, as determined by software object 3820, then using the Discount JRate and Transaction Fee from software object 3820, the Fee and Net amounts are calculated. Once software object 3830 has completed its execution, it communicates that fact to software object 3840. Software object 3840, upon receipt of communication from software object 3830, acts to begin the transaction. Once software object 3840 has completed its execution, it communicates that fact to software object 3850. Software object 3850, upon receipt of communication from software object 3840, acts to execute an SQL Insert of POS data and calculated fields from software object 3830 into the ProcessorJTb table. Once software object 3850 has completed its execution, it communicates that fact to software object 3860. Software object 3860, upon receipt of communication from software object 3850, acts to retrieve the SQL Return Code. Software object 3860 then communicates the fact that it has retrieved the SQL Return Code to software object 3870. Software object 3870, upon receipt of communication from software object 3860 acts to commit the transaction. Once software object 3870 has completed its execution, it communicates that fact to software object 3880. Software object 3880, upon receipt of commumcation from software object 3870, acts to select a communication path out on case communication path into software object 3800, as foUows: communication path in communication path out
76 85
2140 2170
4570 4630 Which results in software object 3880 providing an output communication 85 to software object 64 in the case that software object 72 provided a communication 76 into software object 3800 OR in software object 3880 providing an output communication 2170 to software object 2180 in the case that software object 2130 provided a communication 2140 into software object 3800 OR in software object 3880 providing an output communication 4630 to software object 4640 in the case that software object 4550 provided a communication 4570 into software object 3800.
Fig. 23 depicts in detail the operation of software object 84 which acts to insert the Ledger data into the LedgerJTb table of the database 16. Software object 3900 is the Child of software object 84 and receives communication 78 from software object 84 (see Fig. 4) OR communication 2240 from software object 2230 (see Fig. 19) OR communication 4580 from software object 4550 (see Fig. 25). Upon receipt of communication 78 OR communication 2240 OR communication 4580, software object 3900 communicates that fact to software object 3910. Software object 3910, upon receipt of communication from software object 3900, acts to setup local variables, Payment_Type_Code, Agreement_ED and OverridingJSTet_Gross_Flag, by executing an SQL Select on the MerchantJSTumbers_Tb table and joining to the MerchantsJTb table on the MerchantJPartnerJD column in the MerchantsJTb table equal to the Merchant Partner ED column in the MerchantJSTumbersJTb then joining to the Merchant_Ledger_Accounts_Tb on the MerchantJSTumber in the Merchant_LedgerJ^ccounts_Tb equal to the Merchant_number provided with the Ledger data, selecting the columns Payment_Type_Code, AgreementJD and OverridingJSTet_Gross_Flag from the Ledger_Accounts_Tb, where the MerchantJSTumber column in the MerchantJSTumbesJTb is equal to the MerchantJSTumber provided in the Ledger data. . Once software object 3910 has completed its execution, it communicates its completion to software object 3920. Software object 3920, upon receipt of communication from software object 3910, acts to setup local variables, Discount Rate, Transaction JFee, and DefaultJSTet_Gross_Flag, by executing an SQL Select on the AgreementJRatesJTb table, selecting the Discount Rate, TransactionJFee, and the DefaultJSTet_GrossJFlag columns where the AgreementJD in the Agreement_Rates_Tb table is equal to the local varaible AgreementJD found in software object 3910 and the Payment_Type_Code in the Agreement JRates_Tb is equal to the local variable Payment_Type_Code found in software object 3910. Software object 3920 also determines whether the ledger data is entered at gross or net for reconcihation purposes. If the Overriding_Net_Gross_Flag is not NULL then that value wiU be used to determine the calculations in softare object 3930; otherwise, the DefaultJSTet_GrossJilag wUl be used. Once software object 3920 has completed its execution, it communicates that fact to software object 3930. Software object 3930, upon receipt of communication from software object 3920, acts to compute the Gross, Net, and Fee amounts (from the discount rates and transaction fees queried in software object 3920) for the Ledger data to be inserted. If the Ledger data was entered at Net value, as determined by software object 3920, then using the Discount Rate and TransactionJFee from software object 3920, the Fee and Gross amounts are calculated. If the data was entered at Gross value, as determined by software object 3920, then using the Discount_Rate and TransactionJFee from software object 3920, the Fee and Net amounts are calculated. Once software object 3930 has completed its execution, it communicates that fact to software object 3940. Software object 3940, upon receipt of communication from software object 3930, acts to begin the transaction. Once software object 3940 has completed its execution, it communicates that fact to software object 3950. Software object 3950, upon receipt of communication from software object 3940, acts to execute an SQL Insert of the Ledger data and the computed data from software object 3930 into the LedgerJTb table. Once software object 3950 has completed its execution, it communicates that fact to software object 3960. Software object 3960, upon receipt of communication from software object 3950, acts to retrieve the SQL Return Code. Software object 3960 then communicates the fact that it has retrieved the SQL Return Code to software object 3970.
Software object 3970, upon receipt of communication from software object 3960 acts to commit the transaction. Once software object 3970 has completed its execution, it
no communicates that fact to software object 3980. Software object 3980, upon receipt of communication from software object 3970, acts to select a communication path out on case communication path into software object 3900, as foUows: communication path in communication path out 78 85
2240 2270
4580 4660
Which results in software object 3980 providing an output communication 85 to software object 64 in the case that software object 72 provided a communication 78 into software object 3900 OR in software object 3980 providing an output communication 2270 to software object 2280 in the case that software object 2230 provided a communication 2240 into software object 3900 OR in software object 3980 providing an output communication 4660 to software object 4670 in the case that software object 4550 provided a communication 4580 into software object 3900. Figs. 24a and 24b are a single flow chart depicting in detaU the operation of software object 170 (see Fig. 5b). Software object 170 provides the User with an opportunity to make manual entries in the entry matching of the reconciliation process. Software object 4000 is a Child of software object 170. Software object 4000 begins execution upon receipt of a communication 165 from software object 150 (see Fig. 5a) once software object 150 has completed its execution of the complex match process. Software object 4000 creates a user reconcihation screen. Once software object 4000 has completed its execution, it communicates that fact to software object 4010. Software object 4010, foUowing its receipt of communication from software object 4000, accepts communication 4005 from the User or communication 4110 from software object 4100. The User input via communication 4005 to software object 4010 selects which accounts to display and compare on the screen created by software object 4000. Typically, due to limited screen size, a User will elect to view only two accounts simultaneously on the screen. The instant invention does however, permit the User to select via communication 4005 an unlimited number of account/data sources for display and reconciliation. Software object 4010 provides initial, default values for the User account selection, but subsequent runs will store User's selection for use as the default in subsequent processing. Software object 4010 selects rows from the selected account tables for viewing based on user preferences. AU rows from the ReconcUiation JData Tb table can
in be selected by the User, or just unmatched rows. Communication 4110 from software object 4100 to software object 4010 wiU cause software object 4010 to again accept User input via communication 4005, so that User might select another set of accounts to display and compare on the screen. User's selection of accounts to display and compare on the screen is communicated by software object 4010 to software object 4020. Software object 4020 takes the first of the User selected set of accounts and performs an SQL Select on the ReconcUiation JDataJTb and the Reconcihation Data Matches Tb tables, selecting rows from the Reconcihation Data Tb where the Table Code in the ReconihationJDataJTb is equal to the first account selected and the BatchJSTumber in the Reconcihation JDataJTb is equal to the current BatchJSTumber. Software object 4020 communicates the completion of its execution to software object 4030. Software object 4030, upon receipt of communication from software object 4020, then displays on the computer screen the rows of account data resultant from the query performed by Object 4020. Software object 4030 communicates the completion of its execution to software object 4040. Software object 4040, upon receipt of communication from software object 4030, takes the next sequential one of the set of accounts selected by the User in Object 4010 and performs an SQL Select on the Reconciliation JData Tb and the Reconcihation JDataJVIatchesJTb tables, selecting rows from the ReconcUiation JDataJTb where the Table_Code in the Reconiliation JDataJTb is equal to the second account selected and the BatchJSTumber in the ReconciliationJDataJTb is equal to the current BatchJSTumber. Software object 4040 communicates the completion of its execution to software object 4050. Software object 4050, upon receipt of communication from software object 4040, then displays on the computer screen the rows of account data resultant from the query performed by Object 4040. At this point there will be rows from both software object 4030 and software object 4050 displayed on the computer screen. Software object 4050 communicates the completion of its execution to software object 4060. Software object 4060 inquires of the User whether the User is finished viewing the displayed accounts. The User communicates 4070 either a 'Yes" or "No" to software object 4060 in response to the inquiry. If the User communicates 4070 Υes", then software object 4060 will communicate 4080 that fact to software object 4100. If the User communicates 4070 "No", then software object 4060 will communicate 4090 that fact to software object 4130. Upon receipt of communication 4080, software object 4100 gives the User the option to reconcUe another set of accounts in this reconciliation session. User communicates 4120 either a Υes" or a "No" to software object 4100 in response to its query as to whether User desires to reconcile another set of accounts in this reconciliation session. If the User communicates 4120 Yes", then software object 4100 wUl communicate 4110 that fact to software object 4010. If the User communicates 4120 "No", then software object 4100 will communicate 175 that fact to software object 195 (see Fig. 5b). Upon receipt of communication 4090 from software object 4060, software object 4130 inquires of the User whether the User desires to set viewing and filtering options. User communicates 4135 either a Yes" or a "No" to software object 4130 in response to its query as to whether User desires to set options. If the User communicates 4130 Yes", then software object 4130 will communicate 4140 that fact to software object 4270. Lf the User communicates 4135 "No", then software object 4130 wiU communicate 4150 that fact to software object 4160 (see Fig. 24b). Upon receipt of communication 4140 from software object 4130, software object 4270 creates a computer screen display of the various options avaUable for User's selection. The User makes his selection via communication 4280 into software object 4270. Software object 4280 communicates User's selections back to software object 4020, which again commences execution with User's preferences apphed. Upon receipt of communication 4150 from software object 4130, software object 4160 inquires of the User whether User desires to enter or finalize the adjustments as they currently exist.
If the User communicates 4170 "No" to software object 4160, software object 4160 communicates 4190 that fact to software object 4210. Software object 4210 displays on the computer screen the User selected rows of unmatched account data and permits the User to communicate 4215 row selections from the rows of the two displayed accounts which are declared by User to be a match. Such declared matches by User may routinely be necessary because of disparity in dates between the POS and Bank items or other various minor variations which are not overcome by the automatic simple and complex matching procedures of the instant invention. When User communicates 4215 his completion of the manual matching to software object 4210, software object 4210 communicates the manually matched rows of data to software object 4220. Upon receipt of commumcation from software object 4210, software object 4220 provides the User the option to update the database 16 with rows of data manuaUy matched in software object 4210. User communicates 4225 his selection to either "No", don't update the database 16 with his changes, or Yes" update database 16 with his changes and highlights on the computer display screen created by software object 4220 those rows of manuaUy matched data that User elects to use to update database 16. If User communicated 4225 "No" to software object 4220, then software object 4220 communicates 4223 the completion of its execution to software object 4060 (Fig. 24a). If the User communicated 4225 "Yes" to software object 4220, then software object 4220 communicates 4228 the completion of its execution to software object 4230. Upon receipt of communication from software object 4220, software object 4230 acts to begin the transaction. Software object 4230 communicates the completion of its execution to software object 4240. Upon receipt of communication from software object 4230, software object 4240 performs an SQL Insert on the Reconcihation JDataJVIatchesJTb table; inserting the Data_EDs from the rows of data that were manuaUy matched by the User in software object 4210. Software object 4240 commumcates the completion of its execution to software object 4250. Upon receipt of commumcation from software object 4240, software object 4250 acts to retrieve the SQL Return Code. Software object 4250 communicates the completion of its execution to software object 4260. Upon receipt of communication from software object 4250, software object 4260 acts to commit the transaction. Software object 4260 communicates 4290 the completion of its execution to software object 4020. Software object 4020, upon receipt of communication 4290 from software object 4260 OR software object 4200, commences execution making its selection of rows of data to display from the remaining unmatched rows of data in the accounts selected by the User.
If the User communicates 4170 Yes" to software object 4160, software object 4160 communicates 4180 that fact to software object 4200. The details of the operation of software object 4200 are depicted in Fig. 25. Software object 4200 provides an adjustment screen display on the computer. Software object 4200 communicates 4290 the completion of its execution to sof ware object 4020.
Fig. 25 depicts in detail the operation of software object 4200 (see Fig. 24b). Software object 4200 creates an adjustment screen for the User to enter Bank/POS/Ledger/Other adjustments to rows of data in the accounts being reconciled. Software object 4500 is a Child of software object 4200 and receives communication 4180 from software object 4160 (see Fig. 24b). Upon receipt of communication 4180 from software object 4160, software object 4500 creates and displays a User adjust screen. Software object 4500 communicates the completion of its execution to software object 4510. Upon receipt of communication from software object 4500, software object 4510 acts to accept User input data, which is an adjustment to the rows of data in the accounts being reconcUed. The User's input is via communication 4505 to software object 4510 and is completed by the User's selection of either a "Cancel" or a "Save" command. After completion of the User's input via communication 4505, software object 4510 communicates the completion of its execution to software object 4520. Software object 4520, upon receipt of communication from software object 4510, acts to determine whether the User elected to "Cancel" or "Save" the data adjustments that he made.
If the software object 4520 determines that the User elected "Cancel", then software object 4520 communicates 4540 that fact to software object 4680. Software object 4680, upon receipt of communication 4540 from software object 4520 OR communication from software object 4690 OR communication from software object 4610 OR communication from software object 4640 OR communication from software object 4670 acts to close the adjustment screen. Software object 4680 communicates 4290 the completion of its execution to software object 4020 (see Fig. 24a).
If the software object 4520 determines that the User elected "Save", then software object 4520 communicates 4530 that fact to software object 4550. Software object 4550, upon receipt of communication 4530 from software object 4520, acts to determine the data type being saved: The data type wUl be determined by software object 4550 to be one of the following types: Other, Bank, POS, or Ledger. Based on its determination of the data type to be saved, software object 4550 communicates the data via communication 4555 to software object 4690 if the data is Other (future types) data, via communication 4560 to software object 80 if the data is Bank data (see Fig. 21), via communication 4570 to software object 82 if the data is POS data (see Fig. 22), and via communication 4580 to software object 84 if the data is Ledger data (see Fig. 23). Software object 4690, upon receipt of communication 4555 from software object 4550, acts to insert the Other data (a future data type) into the database 16 and communicate the completion of its execution to software object 4680. Software object 80, upon receipt of communication 4560 from software object 4550, acts to insert the Bank adjustment data into the BankJTb table of the database 16 and communicate 4600 the completion of its execution to software object 4610. Software object 4610, upon receipt of communication 4600 from software object 80 (see Fig.21 for detaUs of operation), executes an SQL Update of the Bank adjustment data in the ReconciliationJDataJTb for the merchant number, date and time and transaction type of the adjustment that was made. The SQL Update will either add to or subtract from the value of the transaction depending on whether the adjustment made is positive or negative. Software object 4610 communicates the completion of its execution to software object 4680. Software object 82, upon receipt of communication 4570 from software object 4550, acts to insert the POS adjustment data into the ProcessorJTb table of the database 16 and communicate 4630 the completion of its execution to software object 4640. Software object 4640, upon receipt of communication 4630 from software object 82 (see Fig.22 for details of operation), executes an SQL Update of the POS adjustment data in the ReconcUiation JData Tb for the merchant number, date and time and transaction type of the adjustment that was made. The SQL Update will either add to or subtract from the value of the transaction depending on whether the adjustment made is positive or negative. Software object 4640 communicates the completion of its execution to software object 4680. Software object 84, upon receipt of communication 4580 from software object 4550, acts to insert the Ledger adjustment data into the LedgerJTb table of the database 16 and communicate 4660 the completion of its execution to software object 4670. Software object 4670, upon receipt of communication 4660 from software object 84 (see Fig.23 for details of operation), executes an SQL Update of the Ledger adjustment data in the Reconcihation Data Tb for the merchant number, date and time and transaction type of the adjustment that was made. The SQL Update wiU either add to or subtract from the value of the transaction depending on whether the adjustment made is positive or negative. Software object 4670 communicates the completion of its execution to software object 4680.
Fig. 26 depicts in detaU the operation of software object 3040. Software object 3040 creates the Partner set up screen (see Fig. 20a), giving the User the possible choices of Master Partner, Bank Partner, Processor Partner, or Merchant Partner. Additionally, software object 3040 can accommodate future "Other" Partner types. Software object 5000 is a ChUd of software object 3040 and receives input via communication 3020 from software object 3010 (see Fig. 20a) OR communication 5115 from software object 5105 (see Fig. 27) OR communication 5002 from User. Upon receipt of communication 3020 OR communication 5002 OR communication 5115, software object 5000 communicates the received data together with the completion of its execution to software object 5005. Software object 5005, upon receipt of communication from software object 5000, creates and displays the Partner Setup screen. Software object 5005 communicates the completion of its execution to software object 5010. Software object 5010 accepts the User Input via communication 5015 of data about the Partner being set-up, which is input into fields by the User. The User selects and communicates 5015 "Save" or "Cancel" to software object 5010 when he is finished inputting data to software object 5010. After completion of the User's input via communication 5015, software object 5010 communicates the completion of its execution to software object 5020. Software object 5020, upon receipt of communication from software object 5010, acts to determine whether the User elected to "Cancel" or "Save" the partner data entered.
If the software object 5020 deteπnines that the User elected "Cancel", then software object 5020 communicates 5030 that fact to software object 5060. Software object 5060, upon receipt of communication 5030 from software object 5020, acts to close the input screen. Software object 5060 commumcates the completion of its execution to software object 5070. Software object 5070, upon receipt of communication from software object 5060, acts to deteimine the source of the input communication to software object 5000. If the input commumcation to software object 5000 was via communication 3020, then software object 5070 communicates 3045 the completion of its execution to software object 3050 (see Fig. 20a). If the input communication to software object 5000 was via communication 5115, then software object 5070 communicates 5125 the completion of its execution to software object 5135 (see Fig. 27). If the software object 5020 determines that the User elected "Save", then software object 5020 communicates 5040 that fact to software object 5050. Software object 5050, upon receipt of communication 5040 from software object 5020, acts to execute an SQL Insert of Partner Data (see Fig. 30 for detaUs of operation). Software object 5050 communicates 5055 the completion of its execution to software object 5060. Fig. 27 depicts in detail the operation of software object 3090. Software object 3090 creates the Agreement set up screen (see Fig. 20a), giving the User the ability to input new Processor agreements as needed. Software object 5100 is a ChUd of software object 3090 and begins execution upon receipt of communication 3070 from software object 3060. Software object 5100 creates and displays the Processor Agreement Set-Up screen. Software object 5100 communicates the completion of its execution to software object 5105. Software object 5105, upon receipt of communication from software object 5100, inquires of the User whether he desires to set-up a new Processor Partner. If the User communicates 5110 that Yes", he wants to set up a new Processor Partner, then software object 5105 will communicate 5115 that fact to software object 3040. If the User communicates 5110 that "No", he does not want to set up a new Processor Partner, then software object 5105 will communicate 5130 that fact to software object 5135. The operation of software object 3040 was depicted in Fig. 26 and is hereinabove described in detail. Software object 3040 communicates 5125 the completion of its execution to software object 5135. Software object 5135, upon receipt of communication 5125 from software object 3040, wUl communicate the new Processor data created in software object 3040 to software object 5145. Software object 5135, upon receipt of communication 5130 from software object 5105, accepts input from the User via communication 5140 so that the User may select an existing Processor for which Agreement data is being entered. This selection by User is accomphshed in the preferred embodiment by highlighting on the computer screen the particular Processor desired from a list of all possible Processors previously entered into the database 16. When User communicates 5140 his selection of a Processor, software object 5135 communicates this selection to software object 5145. Software object 5145, upon receipt of communication from software object 5135, accepts User input data regarding the terms of the Agreement (such data including name of the processor, length of the Agreement, discount rates by card type, charge back fees, and monthly fees) via communication 5150. The final input by User to software object 5145 is the selection of a "Save" or "Cancel" button. Upon completion of User's input to software object 5145, software object 5145 communicates the completion of its execution together with the data input by the User to software object 5155. Software object 5155, upon receipt of communication from software object 5145, acts to determine whether the User selected the "Save" or the "Cancel" button in his input communication 5150 to software object 5145. If software object 5155 determines that the User's input communication 5150 to software object 5145 included a "Save" command, then software object 5155 communicates 5160 this fact to software object 5170. If software object 5155 determines that the User's input communication 5150 to software object 5145 included a "Cancel" command, then software object 5155 communicates 5165 this fact to software object 5190. Software object 5170, upon receipt of commumcation 5160 from software object 5155, acts to execute an SQL Insert of input data from software object 5145 into the AgreementsJTb table. Software object 5170 communicates 5175 the completion of its execution to software object 5180. Software object 5180, upon receipt of communication 5175 from software object 5170, acts to create and display a screen for the User to input rate data regarding the Agreement being set up. The detaUed operation of software object 5180 is depicted in Fig. 35. Software object 5180 communicates 5185 the completion of its execution to software object 5190. Software object 5190, upon receipt of communication 5185 from software object 5180 OR communication 5165 from software object 5155, acts to close the input screen. Software object 5190 communicates 3095 the completion of its execution to software object 3100 (see Fig. 20a).
Fig. 28 depicts in detaU the operation of software object 3140. Software object 3140 creates the Terminal setup screen (see Fig. 20a), giving the User the ability to setup new Terminals as needed. Software object 5200 is a Child of software object 3140 and begins execution upon receipt of communication 3120 from software object 3110 (see Fig. 20a). Software object 5200 creates and displays the Terminal Set-Up screen. Software object 5200 communicates the completion of its execution to software object 5210. Software object 5210, upon receipt of communication from software object 5200, acts to accept User Input via communication 5205 whereby the User can input data regarding the Terminal and then elect to either "Cancel" or "Save" the data to the database 16. The data input by the User may include the Terminal name, the Merchant_PartnerJD, the Terminal type, the printer type, a lease flag, Monthly Fee amounts, and other pertinent data. The final input by User to software object 5210 is the selection of a "Save" or "Cancel" button. Upon completion of User's input to software object 5210, software object 5210 communicates the completion of its execution together with the data input by the User to software object 5220. Software object 5220, upon receipt of communication from software object 5210, acts to determine whether the User selected the "Save" or the "Cancel" button in his input communication 5205 to software object 5210. If software object 5220 determines that the User's input communication 5205 to software object 5210 included a "Save" command, then software object 5220 communicates 5240 this fact to software object 5250. Tf software object 5220 determines that the User's input communication 5205 to software object 5210 included a "Cancel" command, then software object 5220 communicates 5230 this fact to software object 5260. Software object 5250, upon receipt of communication 5240 from software object 5220, acts to execute an SQL Insert of input data from software object 5210 into the Terminals Tb table. Software object 5250 communicates the completion of its execution to software object 5260. Software object 5260, upon receipt of communication from software object 5250 OR communication 5230 from software object 5220, acts to close the input screen. Software object 5260 communicates 3145 the completion of its execution to software object 3150 (see Fig. 20a).
Fig. 29 depicts in detail the operation of software object 3200. Software object 3200 creates the Merchant Number set up screen (see Fig. 20b), giving the User the ability to setup new Merchant Numbers as needed. Software object 5300 is a Child of software object 3200 and begins execution upon receipt of commumcation 3180 from software object 3170 (Fig. 20b). Software object 5300 creates and displays the Merchant Number setup screen. Software object 5300 communicates the completion of its execution to software object 5310. Software object 5310, upon receipt of commumcation from software object 5300, acts to accept User Input via commumcation 5315 whereby the User can input data regarding the Merchant Number and then elect to either "Cancel" or "Save" the data to the database 16. The data input by the User may include the MerchantJSTumber, Merchant JPartner_ED, Payment_Type_Code, Overriding_Agreement_TD, Monthly_Fee_Amounts, and other pertinent data. The final input by User to software object 5310 is the selection of a "Save" or "Cancel" button. Upon completion of User's input to software object 5310, software object 5310 communicates the completion of its execution together with the data input by the User to software object 5320. Software object 5320, upon receipt of communication from software object 5310, acts to determine whether the User selected the "Save" or the "Cancel" button in his input communication 5315 to software object 5310. If software object 5320 determines that the User's input communication 5315 to software object 5310 included a "Save" command, then software object 5320 communicates 5340 this fact to software object 5350. Tf software object 5320 determines that the User's input communication 5315 to software object 5310 included a "Cancel" command, then software object 5320 communicates 5330 this fact to software object 5370. Software object 5350, upon receipt of communication 5340 from software object 5320, acts to execute an SQL Insert of input data from software object 5310 into the MerchantJSTumbers_Tb table. Software object 5350 communicates 5360 the completion of its execution to software object 5370. Software object 5370, upon receipt of communication 5360 from software object 5350 OR communication 5330 from software object 5320, acts to close the input screen. Software object 5370 communicates 3205 the completion of its execution to software object 3210 (see Fig. 20b). Fig. 30 depicts in detaU the operation of software object 5050 (see Fig. 26). Software object 5050 performs the SQL Insert of Partner data into the database 16. Two SQL inserts are executed by software object 5050. The first SQL Insert inserts Partner data into the PartnersJTb table. The second SQL Insert associates the Partner with the Master Partner record. Each Partner, except for Master Partners, is associated back to a Master Partner record/row in the PartnersJTb table. Software object 5400 is a Child of software object 5050 and begins execution upon receipt of communication 5040 from software object 5020. Software object 5400, upon receipt of communication 5040 from software object 5020, acts to begin the transaction. Software object 5400 communicates the completion of its execution to software object 5410. Software object 5410, upon receipt of communication from software object 5400, acts to execute an SQL Insert of Partner data into the PartnersJTb table. Software object 5410 communicates the completion of its execution to software object 5420. Software object 5420, upon receipt of communication from software object 5410, acts to retrieve the SQL Return Code. Software object 5420 communicates the completion of its execution to software object 5430. Software object 5430, upon receipt of communication from software object 5420, acts to execute an SQL Insert of Partner data into the Partner JEJierarchy _Tb table. This SQL Insert by software object 5430 associates the new Partner record (data row) with a Master Partner record hi the PartnersJTb. The Master Partner_ED associated with the new Partner is that of the current User's Partner ED as setup in the UsersJTb. At the time the program of the instant invention is first started the User is logged in and the Partner ED from the UsersJTb is stored in a session variable. Software object 5430 communicates the completion of its execution to software object 5440. Software object 5440, upon receipt of communication from software object 5430, acts to retrieve the SQL Return Code. Software object 5440 communicates the completion of its execution to software object 5450. Software object 5450, upon receipt of communication from software object 5440, acts to commit the transaction. Software object 5450 communicates 5055 the completion of its execution to software object 5060 (see Fig. 26).
Fig. 31 depicts in detaU the operation of software object 3220 (see Fig. 20c). Software object 3220 creates aU of the associations necessitated by the User entry of a Merchant Number in the Merchant Setup wizard (Figs. 20a, 20b, and 20c). Software object 5500 is a ChUd of software object 3220 and begins execution upon receipt of communication 3215 from software object 3210 (see Fig. 20b). Software object 5500, upon receipt of communication 3215 from software object 3210, acts to begin the transaction. Software object 5500 communicates the completion of its execution to software object 5510. Software object 5510, upon receipt of communication from software object 5500, acts to execute an SQL Insert into the Terminal JVIerchantJSTumbersJTb table to associate the Merchant Number to the Terminal; the SQL Insert is performed by inserting the Terminal ED selected and the MerchantJSTumber selected into the Terminal JVIerchant JSTumbersJTb table. Software object 5510 communicates the completion of its execution to software object 5520. Software object 5520, upon receipt of communication from software object 5510, acts to retrieve the SQL Return Code. Software object 5520 commumcates the completion of its execution to software object 5530. Software object 5530, upon receipt of communication from software object 5520, acts to execute an SQL Update on the Merchant JSTumbers_Tb table to associate the Merchant Number to the Bank Account that was previously selected. The SQL Update is performed by updating the MerchantJSTumber record with the Bank_Account_TD for the Bank Account selected. Software object 5530 communicates the completion of its execution to software object 5540. Software object 5540, upon receipt of communication from software object 5530, acts to retrieve the SQL Return Code. Software object 5540 communicates the completion of its execution to software object 5550. Software object 5550, upon receipt of communication from software object 5540, acts to execute an SQL Insert into the Merchant_Ledger_Account_Tb table to associate the Merchant Number to the Ledger account selected. The SQL Insert executed by software object 5550 inserts the MerchantJSTumber and the Ledger AccountJD into the Merchant JLedger_AccountJTb table. Software object 5550 communicates the completion of its execution to software object 5560. Software object 5560, upon receipt of communication from software object 5550, acts to retrieve the SQL Return Code. Software object 5560 communicates the completion of its execution to software object 5570. Software object 5570 acts to commit the transaction. Software object 5570 communicates 3225 the completion of its execution to software object 3230 (see Fig. 20c).
Fig. 32 depicts in detail the operation of software object 5630. Software object 5630 creates the Bank Account setup screen (see Fig. 20b), giving the User the ability to setup new Bank Accounts as needed. Software object 6000 is a Child of software object 5630 and begins execution upon receipt of communication 5610 from software object 5600 (Fig. 20b). Software object 6000 creates and displays the Bank Account Setup screen. Software object 6000 communicates the completion of its execution to software object 6010. Software object 6010, upon receipt of communication from software object 6000, acts to accept User Input via communication 6020 whereby the User can input data regarding the Bank Account and then elect to either "Cancel" or "Save" the data to the database 16. The final input by User to software object 6010 is the selection of a "Save" or "Cancel" button. Upon completion of User's input to software object 6010, software object 6010 communicates the completion of its execution together with the data input by the User to software object 6030. Software object 6030, upon receipt of communication from software object 6010, acts to determine whether the User selected the "Save" or the "Cancel" button in his input communication 6020 to software object 6010. If software object 6030 determines that the User's input communication 6020 to software object 6010 included a "Save" command, then software object 6030 communicates 6040 this fact to software object 6060. If software object 6030 determines that the User's input communication 6020 to software object 6010 included a "Cancel" command, then software object 6030 communicates 6050 this fact to software object 6080. Software object 6060, upon receipt of communication 6040 from software object 6030, acts to execute an SQL Insert of input data from software object 6010 into the Bank_Accounts_Tb table. DetaUed operation of software object 6060 is depicted in Fig. 33. Software object 6060 communicates 6070 the completion of its execution to software object 6080. Software object 6080, upon receipt of communication 6070 from software object 6060 OR communication 6050 from software object 6030, acts to close the input screen. Software object 6080 communicates 5640 the completion of its execution to software object 5650 (see Fig. 20b).
Fig. 33 depicts in detail the operation of software object 6060 (see Fig. 32). Software object 6060 performs SQL Inserts of new Bank Account data into the database 16 and associates the current User with the new Bank Account. Software object 6100 is a Child of software object 6060 and begins execution upon receipt of communication 6040 from software object 6030 (Fig. 32). Software object 6100, upon receipt of communication 6040 from software object 6030, acts to begin the transaction. Software object 6100 commumcates the completion of its execution to software object 6110. Software object 6110, upon receipt of communication from software object 6100, acts to execute an SQL Insert into the Bank Accounts Tb table of new Bank Account data. Software object 6110 communicates the completion of its execution to software object 6120. Software object 6120, upon receipt of communication from software object 6110, acts to retrieve the SQL Return Code. Software object 6120 communicates the completion of its execution to software object 6130. Software object 6130, upon receipt of communication from software object 6120, acts to execute an SQL Insert into the User_Accounts_Tb table to associate the new Bank Account with the current User. The SQL Insert is performed by inserting the User JD for the current User and the Bank_Account_ED for the Bank Account selected into the User_Accounts_Tb table. Software object 6130 communicates the completion of its execution to software object 6140. Software object 6140, upon receipt of communication from software object 6130, acts to retrieve the SQL Return Code. Software object 6130 communicates the completion of its execution to software object 6150. Software object 6150, upon receipt of communication from software object 6140, acts to commit the transaction. Software object 6150 communicates 6070 the completion of its execution to software object 6080 (see Fig. 32).
Fig. 34 depicts in detaU the operation of software object 5690. Software object 5690 creates the Ledger Account set up screen (see Fig. 20b), giving the User the ability to setup new Ledger Accounts as needed. Software object 6200 is a Child of software object 5690 and begins execution upon receipt of commumcation 5670 from software object 5660 (Fig. 20b). Software object 6200 creates and displays the Ledger Account Setup screen. Software object 6200 communicates the completion of its execution to software object 6210. Software object 6210, upon receipt of communication from software object 6200, acts to accept User Input via communication 6220 whereby the User can input data regarding the Ledger Account and then elect to either "Cancel" or "Save" the data to the database 16. The final input by User to software object 6210 is the selection of a "Save" or "Cancel" button. Upon completion of User's input to software object 6210, software object 6210 communicates the completion of its execution together with the data input by the User to software object 6230. Software object 6230, upon receipt of commumcation from software object 6210, acts to determine whether the User selected the "Save" or the "Cancel" button in his input communication 6220 to software object 6210. If software object 6230 deteπnines that the User's input communication 6220 to software object 6210 included a "Save" command, then software object 6230 communicates 6240 this fact to software object 6260. If software object 6230 determines that the User's input communication 6220 to software object 6210 included a "Cancel" command, then software object 6230 commumcates 6250 this fact to software object 6280. Software object 6260, upon receipt of commumcation 6240 from software object 6230, acts to execute an SQL Insert of input data from software object 6210 into the Ledger_Accounts_Tb table. Software object 6260 communicates 6270 the completion of its execution to software object 6280. Software object 6280, upon receipt of communication 6270 from software object 6260 OR communication 6250 from software object 6230, acts to close the input screen. Software object 6280 communicates 5700 the completion of its execution to software object 5710 (see Fig. 20b).
Fig. 35 depicts in detaU the operation of software object 5180. Software object 5180 creates the Processor Rates setup screen (see Fig. 27), giving the User the abUity to setup new Processor Rates as needed, as for example when a new Processor Agreement is entered into the instant invention, then new rates must also be added to complete input of data for the Agreement. Software object 6300 is a Child of software object 5180 and begins execution upon receipt of communication 5175 from software object 5170. Software object 6300 creates and displays the Processor Rate Setup screen. Software object 6300 communicates the completion of its execution to software object 6310. Software object 6310, upon receipt of communication from software object 6300, acts to accept User Input via commumcation 6320 whereby the User can input data regarding the Processor Rates and then elect to either "Cancel" or "Save" the data to the database 16. The information input by the User to software object 6310 could include the payment type, the different rates for type of transactions (keyed vs. swipe), the monthly fees, and the statement fees. The final input by User to software object 6310 is the selection of a "Save" or "Cancel" button. Upon completion of User's input to software object 6310, software object 6310 communicates the completion of its execution together with the data input by the User to software object 6330. Software object 6330, upon receipt of commumcation from software object 6310, acts to determine whether the User selected the "Save" or the "Cancel" button in his input communication 6320 to software object 6310. If software object 6330 determines that the User's input communication 6320 to software object 6310 included a "Save" command, then software object 6330 communicates 6350 this fact to software object 6360. If software object 6330 determines that the User's input communication 6320 to software object 6310 included a "Cancel" command, then software object 6330 communicates 6340 this fact to software object 6410. Software object 6360, upon receipt of communication 6350 from software object 6330, acts to execute an SQL Insert of input data from software object 6310 into the Agreement JRatesJTb table. Software object 6360 communicates the completion of its execution to software object 6370. Software object 6370, upon receipt of communication from software object 6360, accepts to accept User Input via communication 6371 in response to the query whether to enter another rate. User Input via communication 6371 to software object 6370 can be either a Yes" or a "No". If the User communicates 6371 a Yes" to software object 6370, software object 6370 wUl communicate 6380 such fact to software object 6400. If the User communicates 6371 a "No" to software object 6370, software object 6370 wUl communicate 6390 such fact to software object 6410. Software object 6400, upon receipt of communication 6380 from software object 6370, acts to clear the input screen. Software object 6400 communicates the completion of its execution to software object 6300. Software object 6410, upon receipt of communication 6390 from software object 6370 OR communication 6340 from software object 6330 acts to close the input screen. Software object 6410 communicates 5185 the" completion of its execution to software object 5190 (Fig. 27).
Fig. 36 depicts those software objects used by the instant invention to set up new Users. Software object 6510 creates and displays the New User setup screen. Software object 6510 has its operation initiated by input communication 6500 from an existing User. Software object 6510 communicates the completion of its execution to software object 6520. Software object 6520, upon receipt of communication from software object 6510, acts to accept User Input via communication 6530 whereby the User can input data regarding the new User and then elect to either "Cancel" or "Save" the data to the database 16. The final input by User to software object 6520 is the selection of a "Save" or "Cancel" button. Upon completion of User's input to software object 6520, software object 6520 communicates the completion of its execution together with the data input by the User to software object 6540. Software object 6540, upon receipt of communication from software object 6520, acts to determine whether the User selected the "Save" or the "Cancel" button in his input communication 6530 to software object 6520. If software object 6540 determines that the User's input communication 6530 to software object 6520 included a "Save" command, then software object 6540 communicates 6550 this fact to software object 6570. If software object 6540 determines that the User's input communication 6530 to software object 6520 included a "Cancel" command, then software object 6540 communicates 6560 this fact to software object 6610. Software object 6570, upon receipt of communication 6550 from software object 6540, acts to begin the transaction. Software object 6570 communicates the completion of its execution to software object 6580. Software object 6580, upon receipt of communication from software object 6570, acts to execute an SQL Insert of input data from software object 6520 into the UsersJTb table. Software object 6580 communicates the completion of its execution to software object 6590. Software object 6590, upon receipt of communication from software object 6580, acts to retrieve the SQL Return Code. Software object 6590 communicates the completion of its execution to software object 6600. Software object 6600, upon receipt of commumcation from software object 6590, acts to commit the transaction. Software object 6600 communicates the completion of its execution to software object 6610. Software object 6610, upon receipt of communication from software object 6600 OR communication 6560 from software object 6540, acts to close the input screen.
Fig. 37 depicts those software objects used by the instant invention to setup associations of Users to Bank Accounts. The association of a User to a Bank Account authorizes that associated User to access and reconcile that associated Bank Account. Software object 6710 creates and displays the User/Bank Account Association screen. Software object 6710 has its operation initiated by input communication 6700 from the current User. Software object 6710 commumcates the completion of its execution to software object 6720. Software object 6720, upon receipt of communication from software object 6710, acts to accept User Input via communication 6730 whereby the User can input data regarding the new User/Bank Account Associations and then elect to either "Cancel" or "Save" the data to the database 16. The final input by User to software object 6720 is the selection of a "Save" or "Cancel" button. Upon completion of User's input to software object 6720, software object 6720 communicates the completion of its execution together with the data input by the User to software object 6740. Software object 6740, upon receipt of communication from software object 6720, acts to determine whether the User selected the "Save" or the "Cancel" button in his input communication 6730 to software object 6720. If software object 6740 determines that the User's input commumcation 6730 to software object 6720 included a "Save" command, then software object 6740 communicates 6750 this fact to software object 6770. If software object 6740 determines that the User's input communication 6730 to software object 6720 included a "Cancel" command, then software object 6740 communicates 6760 this fact to software object 6810. Software object 6770, upon receipt of communication 6750 from software object 6740, acts to begin the transaction. Software object 6770 communicates the completion of its execution to software object 6775. Software object 6775, upon receipt of communication from software object 6770, acts to execute SQL Delete(s) to remove Bank Accounts not selected in software object 6720 from the User_Accounts_Tb table. Software object 6775 communicates the completion of its execution to software object 6780 Software object 6780, upon receipt of communication from software object 6775, acts to execute an SQL Insert of input data from software object 6720 into the User_Accounts_Tb table. Software object 6780 communicates the completion of its execution to software object 6790. Software object 6790, upon receipt of communication from software object 6780, acts to retrieve the SQL Return Code. Software object 6790 communicates the completion of its execution to software object 6800. Software object 6800, upon receipt of communication from software object 6790, acts to commit the transaction. Software object 6800 communicates the completion of its execution to software object 6810. Software object 6810, upon receipt of communication from software object 6800 OR communication 6760 from software object 6740, acts to close the input screen.
Fig: 38 depicts those software objects used by the instant invention to set up an Association of Users to Merchant Partners. The association of a User to a Merchant Partner authorizes that associated User to access and reconcile that Merchant Partner Account. Software object 6860 creates and displays the User/Merchant Partner Association screen. Software object 6860 has its operation initiated by input communication 6850 from the current User. Software object 6860 communicates the completion of its execution to software object 6870. Software object 6870, upon receipt of communication from software object 6860, acts to accept User Input via communication 6880 whereby the User can input data regarding the new User/Merchant Partner Associations and then elect to either "Cancel" or "Save" the data to the database 16. The final input by User to software object 6870 is the selection of a "Save" or "Cancel" button. Upon completion of User's input to software object 6870, software object 6870 communicates the completion of its execution together with the data input by the User to software object 6890. Software object 6890, upon receipt of communication from software object 6870, acts to determine whether the User selected the "Save" or the "Cancel" button in his input communication 6880 to software object 6870. If software object 6890 determines that the User's input communication 6880 to software object 6870 included a "Save" command, then software object 6890 communicates 7000 this fact to software object 7020. If software object 6890 determines that the User's input communication 6880 to software object 6870 included a "Cancel" command, then software object 6890 communicates 7010 this fact to software object 7060. Software object 7020, upon receipt of communication 7000 from software object 6890, acts to begin the transaction. Software object 7020 communicates the completion of its execution to software object 7025. Software object 7025, upon receipt of communication from software object 7020, acts to execute SQL Delete(s) to remove Merchant Partner Accounts not selected in software object 6870 from the UserJVIerchantsJTb table. Software object 7025 communicates the completion of its execution to software object 7030. Software object 7030, upon receipt of communication from software object 7025, acts to execute an SQL Insert of input data from software object 6870 into the User Merchants Tb table. Software object 7030 commumcates the completion of its execution to software object 7040. Software object 7040, upon receipt of commumcation from software object 7030, acts to retrieve the SQL Return Code. Software object 7040 communicates the completion of its execution to software object 7050. Software object 7050, upon receipt of communication from software object 7040, acts to commit the transaction. Software object 7050 commumcates the completion of its execution to software object 7060. Software object 7060, upon receipt of communication from software object 7050 OR communication 7010 from software object 6890, acts to close the input screen.
The Definition of Terms and Phrases, the Database Table Definitions, the Definitions of Table Fields (Variables), the Description of Numeric References, and the Brief Description of the Drawings preceding the description of the Best Mode for Carrying Out the Invention are not simply Ulustrative of the instant invention, but in fact comprise a portion of the description of the invention and are hereby incorporated herein for aU purposes as if repeated in their entirety hereat.
A second embodiment of the instant invention provides that software object 24 encapsulates the database 16.
A third embodiment of the instant invention provides that no database 16 exists and that its functions are provided by data sets.
A fourth embodiment of the instant invention provides that there are no data sets wherein the database 16 provides additional tables to hold the data described in the preferred embodiment as being in data sets.
A fifth embodiment of the instant invention provides that software object 24 encapsulates the database 16 and further provides that there are no data sets wherein the database 16 provides additional tables to hold the data described in the preferred embodiment as being in data sets.
Industrial Benefits of the Instant Invention
The instant invention addresses a pervasive problem throughout the commercial world. At the present time businesses all over the world are doing a reconciliation of their credit card and other electronic payment processor account statements, their monthly bank statements, and their general ledger accounting system by hand. The difficulty in obtaining an accurate reconcUiation of the hereinabove described accounts is such that many, if not most, businesses simply enter "correction" or "reconcUiation" factors into their ledgers rather than attempting or obtaining an accurate reconciliation. Largely the difficulty is cause by the quantity and diversity of Processor Agreement forms and terms and by the varying delays the Processor inserts between the POS sale and the posting of the credit to the businesses' Merchant Account. These difficulties, and others not mentioned, to obtaining an accurate reconcihation of accounts are overcome by the instant invention. Substantial benefits to industry wUl be achieved by use of the instant invention in that there wiU be a savings of labor costs presently incurred in trying to obtain an accurate reconcUiation of accounts while simultaneously reducing losses due to errors, chargebacks and fraud.
Substantial additional benefits to industry may be expected by the increased competition between Processors that wiU hkely ensue once merchants are enabled to precisely calculate and account for the Processor's charges and delays.
While the preferred embodiments of the instant invention have been described in substantial detail and fully and completely hereinabove, it will be apparent to one skilled in the art that numerous variations of the instant invention may be made without departing from the spirit and scope of the instant invention, and accordingly the instant invention is to be limited only by the following claims.

Claims

ClaimsI Claim:
1. A system for reconciling data from a plurality of accounts comprising a computer a software object ranning on said computer, wherein said software object provides a database, said software object receives communication from sources of said data, said software object selects as reconcUed all matching data entries present in each of said plurality of accounts, said software object selects as reconcUed a sum of two or more data entries present in a first one of said plurality of said accounts that matches a data entry in each of the other of said plurality of accounts, said software object creates a first table in said database for data communicated to it from said sources of said data- said software object creates a second table in said database for aU reconcUed data entries, said software object creates a third table in said database for aU unreconcUed data entries said software object inserts aU data communicated from said sources of said data into said first table, said software object inserts aU data entries selected as reconcUed into said second table, said software object inserts aU data entries not selected as reconcUed into said third table, and said software object provides output communication and display of the contents of said tables in said database.
A system for reconcUing a merchant's general ledger data to said merchant's bank account data and to said merchant's credit card and electronic payment processor's account data comprising a computer, and a software object running on said computer; wherein said software object is in communication with a source of said bank account data, said software object is in communication with a source of said credit card and electronic payment transaction processor's account data, said software object is in commumcation with a source of said general ledger data, said software object performs a first match of the deposit and charge back transactions contained in said bank account data to the daUy totals of said credit card and electronic payment processor's account data, said software object performs a second match of said deposit and charge back transactions in said bank account data to the daUy totals of said general ledger data, said software object performs a third match of said deposit and charge back transactions contained in said bank account data to the sum of two or more of said data entries in said credit card and electronic payment processor's account data, said software object performs a fourth match of said daUy totals of said general ledger data to the sum of two or more of said deposit and charge back transactions in said bank account data, said software object selects as reconciled said deposit and charge back transactions in said bank account data that is included in said first match and in said second match, said software object selects as reconcUed said deposit and charge back transactions contained in said bank account data that is included in said second match and in said third match, said software object selects as reconcUed said deposit and charge back transactions contained in said bank account data that is included in said first match and in said fourth match, said software object selects as reconcUed said deposit and charge back transactions contained in said bank account data that is included in said third match and in said fourth match, said software object generates an interactive computer screen display listing aU unreconcUed deposit and charge back transactions contained in said bank account data and all unreconciled point of sale and electronic payment transaction data for user selection of additional reconciled data entries.
A system for reconciling a merchant's point of sale and electronic payment transaction data to said merchant's bank account data and to said merchant's credit card and electronic payment processor's account data comprising a computer, and a software object running on said computer; wherein said software object is in communication with a source of said bank account data, said software object is in communication with a source of said credit card and electronic payment transaction processor's account data, said software object is in communication with a source of said point of sale and electronic payment transaction data, said software object performs a first match of the deposit and charge back transactions contained in said bank account data to the daUy totals of the data entries in said credit card and electronic payment processor's account data, said software object performs a second match of said data entries in said credit card and electronic payment processor's account data to the daily totals of the data entries in said point of sale and electronic payment transaction data, said software object performs a third match of said deposit and charge back transactions contained in said bank account data to the sum of two or more of said data entries in said credit card and electronic payment processor's account data, said software object performs a fourth match of said daily totals contained in said credit card and electronic payment processor's account data to the sum of two or more of said data entries contained in said point of sale and electronic payment transaction data, said software object selects as reconcUed said data entries in said credit card and electronic payment processor's account data that is in said first match and in said second match, said software object selects as reconciled said data entries in said credit card and electronic payment processor's account data that is in said first match and in said fourth match, said software object selects as reconciled said data entries in said credit card and electronic payment processor's account data that is in said second match and in said third match, said software object selects as reconcUed said data entries in said credit card and electronic payment processor's account data that is in said third match and in said fourth match, said software object generates an interactive computer screen display listing all unreconcUed data entries in said credit card and electronic payment processor's bank account data and aU unreconcUed point of sale and electronic payment transaction data for user selection of additional reconciled data entries.
4. The system of Claim 1 wherein said software object calculates discounts, charges, and fees applicable to each said data entry in each of said plurality of accounts; and wherein prior to performing said selection operations said software object adds said apphcable discounts, charges, and fees to each said data entry in each of said plurality of accounts.
5. The system of Claim 2 wherein said software object calculates discounts, charges, and fees apphcable to each said data entry in said credit card and electronic payment processor's account; and wherein prior to performing said matching operations said software object adds said apphcable discounts, charges, and fees to each said data entry in said point of said and electronic payment transaction data.
6. The system of Claim 3 wherein said software object calculates discounts, charges, and fees apphcable to each said data entry in said credit card and electronic payment processor's account, said software object calculates discounts, charges, and fees applicable to each said data entry in said point of sale and electronic payment transaction data; and wherein prior to performing said matching operations, said software object adds said apphcable discounts, charges, and fees to each said data entry in said credit card and electronic payment processor's account, and said software object adds said applicable discounts, charges, and fees to each said data entry in said point of said and electronic payment transaction data.
7. The system of Claim 1 additionaUy comprising a second computer, a network server software object running on said first computer, a network chent software object running on said second computer, and a network connection providing communication between said first computer and said second computer; whereby an authorized user may operate said network chent software object and thereby access and operate said system over said network.
8. The system of Claim 2 additionally comprising a second computer, a network server software object running on said first computer, a network chent software object running on said second computer, and a network connection providing communication between said first computer and said second computer; whereby an authorized user may operate said network client software object and thereby access and operate said system over said network.
9. The system of Claim 3 additionaUy comprising a second computer, a network server software object running on said first computer, a network chent software object running on said second computer, and a network connection providing communication between said first computer and said second computer; whereby an authorized user may operate said network client software object and thereby access and operate said system over said network.
PCT/US2001/023753 2001-07-26 2001-07-26 Merchant activity and reconciliation program WO2003012716A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/US2001/023753 WO2003012716A1 (en) 2001-07-26 2001-07-26 Merchant activity and reconciliation program
AU2001283019A AU2001283019A1 (en) 2001-07-26 2001-07-26 Merchant activity and reconciliation program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2001/023753 WO2003012716A1 (en) 2001-07-26 2001-07-26 Merchant activity and reconciliation program

Publications (2)

Publication Number Publication Date
WO2003012716A1 true WO2003012716A1 (en) 2003-02-13
WO2003012716A8 WO2003012716A8 (en) 2007-09-07

Family

ID=21742734

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/023753 WO2003012716A1 (en) 2001-07-26 2001-07-26 Merchant activity and reconciliation program

Country Status (2)

Country Link
AU (1) AU2001283019A1 (en)
WO (1) WO2003012716A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004055698A1 (en) * 2002-12-17 2004-07-01 Stephen James Sullivan Tagging system
US8886570B1 (en) 2013-10-29 2014-11-11 Quisk, Inc. Hacker-resistant balance monitoring

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5832460A (en) * 1995-06-02 1998-11-03 International Business Machines Corporation Method and system for bill presentation and payment reconciliation
US5995973A (en) * 1997-08-29 1999-11-30 International Business Machines Corporation Storing relationship tables identifying object relationships
US6038548A (en) * 1997-11-26 2000-03-14 International Business Machines Corporation System and method for conducting electronic commerce in a computer network using a cashier desk payment framework
US6189785B1 (en) * 1998-04-14 2001-02-20 International Check Services Demand deposit account data processing system

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5832460A (en) * 1995-06-02 1998-11-03 International Business Machines Corporation Method and system for bill presentation and payment reconciliation
US5995973A (en) * 1997-08-29 1999-11-30 International Business Machines Corporation Storing relationship tables identifying object relationships
US6038548A (en) * 1997-11-26 2000-03-14 International Business Machines Corporation System and method for conducting electronic commerce in a computer network using a cashier desk payment framework
US6189785B1 (en) * 1998-04-14 2001-02-20 International Check Services Demand deposit account data processing system

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004055698A1 (en) * 2002-12-17 2004-07-01 Stephen James Sullivan Tagging system
US8886570B1 (en) 2013-10-29 2014-11-11 Quisk, Inc. Hacker-resistant balance monitoring
US10423960B2 (en) 2013-10-29 2019-09-24 Quisk, Inc. Hacker-resistant balance monitoring

Also Published As

Publication number Publication date
WO2003012716A8 (en) 2007-09-07
AU2001283019A8 (en) 2007-10-18
AU2001283019A1 (en) 2003-02-17

Similar Documents

Publication Publication Date Title
AU2001285284B2 (en) System and method for account reconciliation
US11978056B2 (en) Systems and methods for using shared databases for managing supplemental payment sources
US7685190B2 (en) Method and system for an online-like account processing and management
US20090265274A1 (en) Automated Transaction Processing System and Approach with Currency Conversion
AU2001285284A1 (en) System and method for account reconciliation
US20040254866A1 (en) Systems and methods for determining payers in a billing environment
US20020099653A1 (en) E-commerce application service provider micro-billing method and system
US7539634B2 (en) Account reconciliation system and method
US20040230524A1 (en) Charity bundling site
US20230028209A1 (en) User interfaces for using shared databases for managing supplemental payment sources
US20030074288A1 (en) System and method for electronically reconciling financial accounts
WO2001075732A1 (en) Method, system, and computer-usable medium for computer-assisted trading
KR100334249B1 (en) Intelligent data structure, processing apparatus, and medium using network
WO2003012716A1 (en) Merchant activity and reconciliation program
AU2008203400B2 (en) System and method for account reconciliation
JP2000306012A (en) System and method for processing account data
JPH06131374A (en) Buying/selling control system
JPH0785181A (en) Accounting processing system
KR20020019848A (en) Billing system with enhanced database structure

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AU BB BR BZ CA CN CR CU GB ID IL IN IS JP KR MA MX NO NZ PL SG UA

Kind code of ref document: A1

Designated state(s): AE AU BB BR BZ CA CN CR CU GB HU ID IL IN IS JP KR MA MX NO NZ PL RU SG UA US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR

Kind code of ref document: A1

Designated state(s): BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IT LU MC NL PT SE TR US

121 Ep: the epo has been informed by wipo that ep was designated in this application
32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: COMMUNICATION UNDER RULE 69 EPC (EPO FORM 1205A DATED 26.05.2004)

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP