USOO9020946B2

(12) United States Patent (10) Patent No.: US 9,020,946 B2

Nagel et al. (45) Date of Patent: Apr. 28, 2015
(54) SYSTEMAND METHOD FOR COMPILATION 2007/0101.437 A1 5/2007 Yamamoto et al.
OF QUICKBOOKS ACCOUNTS DATA 2008/0222189 A1 9/2008 Ovanesyan et al.
2009, OO37356 A1 2/2009 Rothstein et al.
2009/0201294 A1* 8/2009 Hayes ........................... 345,440
(75) Inventors: Charles Brenton Nagel, Dale, TX (US); 2009, 0234885 A1* 9, 2009 Yotsukura ... TO7 104.1
Jay Otterbein, Austin, TX (US) 2009/0313208
2010/O107085
A1* 12/2009 Helfman ........................... 707/2
A1 4/2010 Chadwicket al.
2010/017994.0 A1 7, 2010 Gilder
(73) Assignee: Qvinci Software, LLC, Austin, TX (US)
OTHER PUBLICATIONS
(*) Notice: Subject to any disclaimer, the term of this
patent is extended or adjusted under 35 International Search Report and Written Opinion dated Oct. 6, 2011
U.S.C. 154(b) by 360 days. for International Application No. PCT/US2011/043693, Interna
tional Filing Date: Jul. 12, 2011 consisting of 6-pages.
(21) Appl. No.: 12/834,791 Running Quickbooks 2007 Premier Editions by Kathy Ivens, 10
Pages.
(22) Filed: Jul. 12, 2010 Need Help Understanding Import Options by Derek Atkinds, Jun. 5,
2008, Posted at GnuCash SVN/CVS and Mail Archive Server, 6
(65) Prior Publication Data Pages.
Can I Merge2General Ledger Accounts? by Chief Mechanic, Sep. 5,
US 2012/OO 11123 A1 Jan. 12, 2012 2010, GL & Journal Entries, http://www.qbgarage.com, 3 Pages.
Quickbooks 2007. The Official Guide for QuickBooks Pro Users by
(51) Int. C. Kathy Ivens, 3 Pages.
G06F 7/30 (2006.01) International Search Report and Written Opinion dated Feb. 21, 2012
G06O40/00 (2012.01) for PCT/US2011/060350 filed Nov. 11, 2011, 11 Pages.
G06O 10/10 (2012.01) * cited by examiner
(52) U.S. C.
CPC ............ G06O40/00 (2013.01); G06F 17/3033 Primary Examiner — Syed Hasan
(2013.01); G06O 10/10 (2013.01) (74) Attorney, Agent, or Firm — GaZdzinski & Associates,
(58) Field of Classification Search PC
CPC combination set(s) only.
See application file for complete search history. (57) ABSTRACT
(56) References Cited Embodiments include a method of aggregating data from a
plurality of QuickBooks (QB) files that may be in physically
U.S. PATENT DOCUMENTS separate locations, and having at least one account name in
common. In one embodiment, the method includes, assigning
6,141,664 A 10/2000 Boothby a different parent account identification (ID) number to each
6,411,938 B1 6/2002 Gates differently named parent account. The method includes cre
6,751,663 B1 6/2004 Farrell et al.
6,785,689 B1 8/2004 Daniel ating an entry in a hash table for each parent account ID, the
7401,101 B2 7/2008 Hild contents of the entry being a collection of rows including a
7,490, 108 B2 2/2009 Bruun row for each different sub account of the parent account,
7,580,884 B2 8/2009 Cook wherein data for multiple instances of like named parent
2002fOO52791 A1 5, 2002 Defede
2004/0199369 A1 * 10, 2004 Freidman et al. ............... TO3/19 accounts are aggregated, the key of the entry in the hash table
2005/0086199 A1 4/2005 Champagne et al. being the parent account ID.
2006/0064428 A1 3f2006 Colaco et al. ................. 707/101
2006/0193264 A1 8/2006 Bonar et al. 11 Claims, 9 Drawing Sheets
Eys
AUN ANNAME PARENTRUNT)
3. Hatf
s RES
KEY2
ACUNTI Accountmare PARENTAOUNT
8 his 2
6 Moris 2
kiss
AccuRTI AccountiAME ARENTAutd
ALAS S
s Histol s
KEY.6
AOUND AUNNAE PARENTANd
8 SANANTNo 6
O USTN 6
keys
ANET AOUN NAME PARENTAccount
2 PANG's 1.
13 S3WAY
KEfil4
AUNTs Account ARENTAUNTI
15 HANG's 4.
16 SUBWAf 4.
keys
ACOUNT AUNTNAME PARENANT
19 BUS
21. ANE
23 AR 7
ces
AUN ANTNAE PARENANd
20 TRAN 8
22 PLANE 8
24 AR 8
U.S. Patent Apr. 28, 2015 Sheet 1 of 9 US 9,020,946 B2

Hyatt
Motel 6
Dallas
Houston
Restaurants

TABLEB

Motel 6
San Antonio

PF Chang's
Transportation
U.S. Patent Apr. 28, 2015 Sheet 2 of 9 US 9,020,946 B2

TABLEC 2-Jan 3-Jan 4-Jan 5-Jan

Hotel
Hyatt O 400 600
Motel 6
Dallas . O 100 50
San Antonio O 100 50
Houston 200 80 O 80 100
Restaurants
PF Changs 100 280 200 100 2OO
Subway 20 40 40 O O
Transportation
Car 20 40 40 2O 100
Train 10 30 10 10 90
BuS 10 30 10 10 90
Plane 400 800 2000 1000 800

FIG. 1C
U.S. Patent Apr. 28, 2015 Sheet 3 of 9 US 9,020,946 B2

CENTRAL LOCATION

102 / 100
HOSTED OBFILES NETWORK
104 1 06ADMIN.

t 108 t 1000

QB FILEE QB
.. . SYNCH WEBSERVERS
12O ADMINISTRATION T
N 1002
SOLE PARENT PARENT 160
LOCATION BUSINESS BUSINESS
BUSINESS ABC NEW YORK
ALL CLENT
QB FILES CHILD 162
HOSTED
OFFSTE
aaaaaaaaaaaaaaaaaa- SOUTH
BUSINESS
CHICAGO
STORE

CHILD / 164
NORTH BUSINESS
144 STORE ATLANTA

ALL CLENT ALL CLIENT

QB FILES
QB FILESAT AT
CLIENT CENTRAL
LOCATIONS LOCATION

FIG. 2A
U.S. Patent Apr. 28, 2015 Sheet 4 of 9 US 9,020,946 B2

START

2O2 208

SETUP USERS AND ENVITE: THE NEWORK

SETUP YOURACCOUN: SAR BY SETTINGUP ADMINISRAORNVTESUSERS TOONA
YOUR COMPANYACCOUNAND PROFE BUSINESS WITHROESEFENED BY NETWORK
ADMINISTRATOR; NVTATIONS MAYBE SENT
AUTOMATICALLY BY EMA

204 210

CONTRIBUTORSSYNCOB FLES: USERS INSTALL

CREATE PARENT BUSINESS: CREATE BUSINESS SYNCAPPCATION ON HERSYSTEM THA
ACCOUNTS FOR YOUR CLIENTS OR YOUROWN CONTAINS THEIR OBFILES; SYNCAPPS
COMPANY CONNECTED ASA 3PARTY APP TO EACH QB FILE;
NCREMENTAL SYNCSAKE PLACE EACH DAY
2O6 212

CREATE CHILD BUSINESS: F PRIMARY BUSINESS

HAS MULTIPLE LOCATIONS, CREATE THEMAS VIEWERS ACCESS REPORTS: VIEWERS OG IN, CLICK
CHELORENOF HEPARENT REPORING AND WEWBUSINESS REPORTS

CONTINUE

Fig. 2B
U.S. Patent Apr. 28, 2015 Sheet 5 Of 9 US 9,020,946 B2

CoMPANY Account ID Account NAME PARENT Account ID

B
A
E.3 E.
HYATT
E.
NULL
1
-
B 6
EGEE
MOTEL6
MoTEL6
1
2
A 7 DALAs Ts
B 8 SAN ANTONIO 6
A 9 Houston is
B 10 Houston T6
A 11 RESTAURANTS NULL
A 12 TPF chANG's 11
A 13 SUBWAY 11
B 14 RESTAURANTS NU
B 15 PF CHANGS 14
B 16 SUBWAY A.
A 17 TRANSPORTATION NULL
B 18 TRANSPORTATION NULL
A 19 BUS 17
B 20 TRAIN 18
A 21 PLANE 17
B 22 |PLANE is
A 23 car 17
B 24 cAR is
F6, 3
U.S. Patent Apr. 28, 2015 Sheet 6 of 9 US 9,020,946 B2

COLLECTION OF PARENT ACCOUNTS, EXISTSOUTSIDE OF THE HASH.TABLE

ACCOUNTD ACCOUNTNAME PARENT ACCOUNT D

RESAURANS
RESTAURANTS

TRANSPORTATION

FG. A.
U.S. Patent Apr. 28, 2015 Sheet 7 Of 9 US 9,020,946 B2

ACCOUNTD

KEY:5
ACCOUNTD ACCOUNTNAME PARENT ACCOUNT ID
7 DAAS
9 HOUSTON

ACCOUNTD ACCOUNT NAME PARENT ACCOUNTD

SAN ANTONIO 6
HOUSTON

ACCOUNTID ACCOUNTNAME PARENT ACCOUNT ID

12 PF CHANGS 11
13 SUBWAY 11.
KEY.14
ACCOUNT NAME PARENT ACCOUNTD
PF CHANGS
SUBWAY
KEY=17
ACCOUNTD ACCOUNTNAME

23 cAR 17
KEYE18
ACCOUNT ID ACCOUNT NAME PARENT ACCOUNTID

EOAPLANE 13as
24 car is
U.S. Patent Apr. 28, 2015 Sheet 8 of 9 US 9,020,946 B2

ASSIGN AN ID TO EACH
OFFERENTLY NAMED PARENT
ACCOUNT

CREATE AN ENTRY IN A HASH

604 TABLE FOREACH PARENT
ACCOUNTID; THE CONTENTS
OF AN ENTRY HAVING A
COLLECTION OF ROWS FOR
EACH DFFERENT SUB
ACCOUNT OF THE PARENT,
WHEREN THE KEY OF THE
ENTRY IN THE HASH.TABLE IS
THE PARENT ACCOUNTD

606
ASSGN AND TO EACHSUB
ACCOUNT OF EACH PARENT
ACCOUNT

CREATE HASH.TABLE ENTRY

FOREACH SUBACCOUNT
THE CONTENTS OF THE
608 ENTRY FOR A SUBACCOUNT
INCLUDINGA COLLECTION OF
ROWS FOREACH OFFERENT
SUB SUBACCOUNT OF THE
SUBACCOUNT, WHEREIN THE
KEY OF THE HASH.TABLES
THE SUBACCOUNTO

FIG. 6
U.S. Patent Apr. 28, 2015 Sheet 9 Of 9 US 9,020,946 B2

702
DENTIFY LIKE-NAMED
PARENT ACCOUNTS

704
DENTIFY LIKE NAMED SUB
ACCOUNTS FOR LIKE NAMED
PARENACCOUNTS

7O6 AGGREGATE DATA FORLKE

NAMEO SUBACCOUNTS OF
LIKE NAMED PARENT
ACCOUNS

708
CREATE REPORT

FIG. 7
 US 9,020,946 B2
1.
SYSTEMAND METHOD FOR COMPLATON
OF QUICKBOOKS ACCOUNTS DATA
FIELD
This written description is in the field of QuickBooks (QB)
data processing.
BRIEF DESCRIPTION OF THE DRAWINGS
Aspects of embodiments will become apparent upon read
ing the following detailed description and upon reference to
the accompanying drawings in which like references may
indicate similar elements:
FIG. 1A depicts an expense table for a first company A;
FIG. 1B depicts an expense table for a second company B;
FIG. 1C depicts an expense table that aggregates the
expense data from company A and company B;
FIG. 2A depicts a network and server for aggregating QB
data from computers of companies and Sub companies.
FIG. 2B depicts a flow chart for setting up QB relation
ships:
FIG. 3 depicts a collection of the data from companies A
and B obtained from using Structure Query Language (SQL);
FIG. 4 depicts a table of parent accounts;
FIG.5 depicts a collection of rows in a hash table for each
parent account and each Sub accounts and each Sub Sub
account for the data from companies A and B;
FIG. 6 depicts a flow chart for assigning IDS and creating
hash tables; and
FIG. 7 depicts a flow chart for identifying and aggregating
data of like-named accounts.
DETAILED DESCRIPTION
The following is a detailed description of embodiments
depicted in the accompanying drawings. The amount of detail
offered is not intended to limit the anticipated variations of
embodiments; but, on the contrary, the intention is to cover
modifications, equivalents, and alternatives falling within the
Scope of the appended claims. The detailed descriptions
below are designed to make such embodiments obvious to a
person of ordinary skill in the art.
Embodiments include a method of aggregating data from a
plurality of QuickBooks (QB) files that may be in physically
separate locations, and having at least one account name in
common. In one embodiment, the method includes, assigning
a different parent account identification (ID) number to each
differently named parent account. The method includes cre
ating an entry in a hash table for each parent account ID, the
contents of the entry being a collection of rows including a
row for each different sub account of the parent account,
wherein data for multiple instances of like named parent
accounts are aggregated, the key of the entry in the hash table
being the parent account ID.
Another embodiment is a QuickBooks (QB) data aggrega
tion system having a web server connected to a network of
computers having QB files stored in a database format at each
computer. The server has a memory to store data obtained
from the QB files of the network of computers. The web
server also has a processor configured to identify like-named
parent accounts in the QB files. For each like-named parent
account, the processor is configured to aggregate the data of
like-named Sub accounts of the parent account from each
computer. The processor is further configured to store the
aggregated data in a hash table. Each entry in the hash table
corresponds to data of a different-named Sub account, each
2
hash table entry having a collection of rows, a row for each
Sub account of the parent account, and having columns of data
associated with each Sub account.
Another embodiment is a tangible storage medium having
instructions that when executed by a computer cause the
computer to aggregate data of a plurality of QuickBooks (QB)
files. The instructions cause the computer to obtain QB data
from each of a plurality of computers in a network, the data
being organized into one or more parent accounts. The
10 instructions further cause the computer to aggregate the data
from like-named Sub accounts for each parent account. The
instructions further cause the computer to form a collection in
a hash table for each differently-named parent account, an
entry including aggregate data of like-named Sub accounts
15 associated with the parent account name.
Small businesses and accountants need visibility and
usability of financial and operational data from remote loca
tions. QuickBooksTM (QB) by IntuitTM currently owns
roughly 87% of the small business accounting software
installed at computers of companies distributed geographi
cally. However, the QuickBooks software does not allow for
aggregation and consolidation of disparate files. Only their
EnterpriseTM solution supports this. However, the Enterprise
Solution involves difficult processes and only applies to
25 Enterprise-formatted company files. Most QuickBooks users
do not run Enterprise due to a lack of need for the features it
provides and because of its high cost. If a company has
multiple QuickBooks files with users needing to access data
contained in more than one QB file, one option is to open each
30 QB file, export a large number of reports to MicrosoftTM
ExcelTM and then map the account names of each QB file,
combine the data, create custom analytics to measure results,
create charts and graphs forbetter understanding and transmit
the results to users. This process is extremely manually inten
35 sive and in many cases prohibitive due to the large number of
QB files that may exist. For instance, a franchise might have
50, 200 or even 30,000 QB files in its network of businesses
located across the globe.
Further complicating the process is the fact that versions of
40 QB are not backward compatible. For example, ifa user runs
QB 2008 PremierTM, then opening a file in a later version of
QB will convert the file to the later version and the file can
then not be opened using the earlier version of QB.
FIG. 1A shows a table of expenses for a company A. There
45 is a row for each parent account: Hotel, Restaurants, and
Transportation. For each parent account there is a row for
each Sub account of the parent account. For example, the
parent account, Hotel, has two sub accounts: Hyatt and Motel
6. In this example, the sub account, Motel 6, has two sub sub
50 accounts: Dallas and Houston. Also, the table of FIG. 1A
shows five columns containing the corresponding data asso
ciated with each Sub account and each Sub Sub account.
Although only a few parent accounts, Sub accounts, and Sub
Sub accounts are shown, more or less of these accounts may
55 be given for a company QB file. Further, some company files
may have sub sub sub accounts, or even deeper levels of sub
acCOunts.
FIG. 1B shows a table of expenses for a company B. The
structure of the table is similar as for company A. That is,
60 company B has the same parent accounts and mostly the same
Sub accounts and Sub Sub accounts as has company A.
Embodiments disclosed herein may aggregate the data of
company A and company B as shown in FIG. 1C. The struc
ture of the aggregate table shown in FIG. 1C has the same
65 structure as the structure of the table of FIG. 1A and the table
of FIG. 1B. However, the amount in a particular row and
column of the table of FIG.1C is the sum of the amounts in the
 US 9,020,946 B2
3 4
corresponding row and column of FIG. 1A and FIG. 1B. The
manner in which this aggregation is achieved is described
below.
FIG. 2A depicts a network and server for aggregating QB
data from computers of companies and Sub companies. The
elements of the network may be connected by a local area
network or a wide area network such as the Internet. A virtual
or real central location 102, or a distributed network of loca
tions, may be created to operate, and Supervise the use of the
processing mechanisms described herein. The central loca
tion 102 has access to the QB files of a plurality of companies
120, 140, 160, and the affiliate or child companies of these
companies 142,144, 162, and 164.
Thus, for example, the central location may be at an
accounting firm with a great number of client companies,
each company having at least one QB file. The company 120,
for example, may be a florist shop. The parent business 140
may be a mobile phone store with a south store 142 and a
north store 144, where the north and south stores may be
located at different locations within a city or state. The parent
business 160 may be a law firm with its principal office in
New York, and with offices in Chicago, 162, and in Atlanta,
164.
Note that in the case of related businesses 140, 142, and
144, each business respective QB file is located at the same
location as the business. In contrast, in the case of the related
businesses 160, 162, and 164, each business respective QB
file is located at a central location at business site 160. Note
also, that the QB files of business 120 are located offsite.
Virtually any business, having virtually any complex relation
ships of its Sub businesses, may use separate instances of QB
at the respective locations of the businesses and sub busi
SSS.
In one embodiment, the central location 102 may access
the QB files from these businesses and sub businesses and
store them in a database of QB files 104. A contributor 106
may have access to the system only to the extent necessary to
maintain the system. A network administrator 108 may set
passwords, control access to the system, and perform other
administrative functions. For example, the network adminis
trator 108 may grant viewing access to a client viewer 110.
enabling the viewer 110 to view aggregated QB data. To
enable access to the data, a graphical user interface and a
keyboard and amouse may be provided, as is known in the art.
In one embodiment, QB data is obtained from the plurality
of companies, 120, 140, 142, 144, 160, 162, and 164, by at
least one server 1000 via a QB synchronization application
1002. The server 1000 may be located at any location con
nected to the network. In particular, the server 1000 may be
located at the central location 102 or at a separate location.
The QB synch application 1002 may be downloaded over the
network to the business locations where the QB files are
located. Thus, for example, the QB synch application 1002
may be downloaded to locations 104,140 142,144, and 160,
as well as to the central location 102. The synchronization
application 1002 may reside at the local QB file locations 104,
140 142, 144, and 160, and may operate to upload transac
tional data from the QB files at the locations 104,140 142,
144, and 160. The upload of transactional data may be sched
uled by an administrator to occur as often as desired, for
example, daily, or the upload can occur upon entry of a
command by the administrator.
FIG.2B depicts a flow chart for setting up QB relationships
for uploading QB files to a central location and aggregating
data from a plurality of QB files of client companies and sub
companies. First, an administrator of accounts will set up an
account and company profile, at 202. Then, the administrator
may create a parent business or client account, at 204. Once a
parent client is created, the administrator may create Sub
businesses or sub clients of the parent client, at 206.
The administrator may then authorize certain contributors
to have access to the system, at 208. An authorized contributor
may install a QB synchronization application at a local com
puter, at 210. The QB synchronization application interfaces
with the local QB files of transaction data, and transmits the
data from such files to the central location. Once synchroni
10 Zation takes place, authorized viewers may compile and
review business reports that reflect data aggregated from QB
files of different locations and companies, at 212.
FIG.3 shows a table of data acquired from the files of data
for company A shown in FIG. 1A and for company B as
15 shown in FIG. 1B, using Structured Query Language (SQL).
Acquiring data using SQL is time consuming and complex
SQL commands are required to acquire the desired data in a
desired form.
FIG. 4 depicts a table of parent accounts extracted from the
data associated with company A and company B. A list of
parent accounts from the different QB files is acquired using,
for example, an SQL command or command in C, C++, or C#
or other known programming language. Each parent account
is associated with an account identification (ID). As will be
25 discussed above, an account ID serves as a key to a hash table.
FIG. 5 depicts a collection of hash tables and their collec
tion of Sub accounts, each key in the hash table is an account
ID for the data from companies A and B. Each hash table entry
corresponds to a different parent account or Sub account. For
30 example, referring to FIG. 4, a first parent account named
hotel is from company A and has an account ID of 1. A second
parent account named hotel is from company B and has an
account ID of 2. Thus, like-named parent accounts are ini
tially assigned different account IDs. In FIG. 5, the collection
35 for account ID 1 (key=1) has a row for each of the two sub
accounts of the parent account, Hotel, of company A. Each
Sub account of this table is assigned a unique account ID. The
collection for account ID 2 (key=2) has a row for each of the
two Sub accounts of the parent account, Hotel, of company B.
40 Each Sub account of this collection is assigned a unique
account ID.
Further, an entry in the hash table is created for each sub
account’s Sub accounts. The key of a Sub account's collection
of sub accounts is the account ID of the Sub account, as shown
45 in the table of key=1 and the table of key=2. For example, the
table of key=5 is the table of the sub account named Motel 6
from the table of key=1. The entry of key=5 has a row for each
sub sub account (Dallas and Houston) of the sub account
named Motel 6 of account ID=5. The entry of key=6 is the
50 collection of the sub accounts of the parent named Motel 6
from the entry of key=2. And so forth. Note that there is no
entry with key=3, for example, because the subaccount
named Hyatt of the table of key=1 has no sub sub accounts.
Not shown in FIG.5 are the columns of data extracted from
55 the columns of the Tables of data from company A (FIG. 1A)
and company B (FIG. 1B). An actual hash table will have an
entry for each Such column.
One embodiment, therefore, is a QB data aggregation sys
tem, having a web server connected to a network of comput
60 ers having QB files. The QB files are stored in a database
format at each computer. The web server has memory to store
data obtained from the QB files. The web server also has a
processor configured to process and aggregate the data of the
various QB files. The processor is configured to identify
65 like-named parent accounts of data from each computer. For
each like-named parent account, the data of Sub accounts of
the parent accounts is aggregated. The aggregated data is
 US 9,020,946 B2
5 6
stored in a hash table from which a report may be created to
display the data according to parent account and Sub account.
Each entry of the hash table corresponds to data of a different
named parent account. An entry has a collection of rows for
each Sub account of a parent account, and has columns of
aggregated data associated with each Sub account. Each col
umn may correspond to data associated with a time frame, for
example, monthly data. The data may be an aggregate profit
and loss table, for example, showing the aggregate profit and
loss data for a plurality of companies. As another example, the
aggregate data may be presented in a chart of accounts.
FIG. 6 depicts a flow chart for assigning IDS and creating
hash tables. At 602, the system assigns an ID to each differ
ently-named parent account. An entry in the hash table is
created for each parent account ID, at 604. The contents of an
entry has a collection of rows for each different sub account of
the parent. The key of the entry is the parent account ID. IDs
are also assigned to each Sub account of a parent account, at
606. An entry in the hash table is created for each sub account
ID, at 608. Each entry in a hash table for a sub account is a
collection of rows which representa different sub sub account
of the sub account to which the collection is associated.
FIG. 7 depicts a flow chart for identifying and aggregating
data of like-named accounts. At 702, like named parent
accounts are identified. At 704, for each like-named parent
account, like-named Sub accounts of the like-named parent
accounts are identified. At 706, data for each like-named sub
account of each like-named parent account are aggregated. At
708 a report, such as the table of FIG. 1C, is created upon
request by an authorized contributor or the system adminis
trator.
An example of pseudo code for implementing the methods
described herein is as follows:
For every account returned:
If account is top-level parent, place in a separate collection
Otherwise, place in the collection stored in the hash table at key of
parent account ID
For every parent in result:
For every other parent in result:
If name matches, combine parent accounts
For every parent account that was combined:
Get collection of children from hash table
For every child of this parent:
For every other child of this parent:
If name matches, combine child accounts
The first loop, in C#, is a quick process because the loop
does not perform a comparison of account IDs. Rather, the
loop merely retrieves each account and checks if an account
ID exists or not, which does not require subtraction. The
Subsequent loops in C# compares accounts against a Subset of
accounts that only match parents. Only children that belong to
parents that were combined will be compared. This is because
if the parent accounts did not match, then children accounts
will not match. This drastically reduces the number of com
parisons that are required to aggregate the data. In contrast,
using SQL requires a collection for every parent account,
rather than merely every differently-named parent account.
That is, even with the bulk operations that SQL can perform
for locating matching children, it cannot perform bulk opera
tions needed to recursively aggregate matching children; for
this, CPU intensive custom looping would need to be per
formed. A reason that using C# is faster is that fewer com
parisons need be made.
Another illustrative embodiment includes a machine-read
able medium embodying machine-readable instructions that,
when executed by a processor, cause the processor to obtain
data from each of a plurality of computers in a network, the
data being organized into one or more parent accounts. The
processor is further caused by the instructions to aggregate
the data from like-named parent accounts. The processor may
5
further be caused to form a hash table with entries being a
collection of sub accounts for each differently-named parent
account, the collection including aggregate data associated
with the parent account name In some embodiments, the
processor is further caused to obtain data from each of the
10
plurality of computers in the network, the data being orga
nized into one or more Sub accounts. The processor may
further aggregate data of one or more like-named Sub
accounts of like-named parent accounts. The processor may
15 also form an entry in the hash table for each differently
named Sub account, the entry including aggregate data asso
ciated with the Sub account name. An item in the collection is
a row that has data associated with a Sub Sub account name.
The process may continue further in like manner for sub sub
accounts, and so forth.
Various changes, Substitutions and alterations can be made
to the embodiments described herein without departing from
the scope of the appended claims. An embodiment may
achieve multiple objectives, but not every embodiment falling
25 within the scope of the attached claims will achieve every
objective. Moreover, the scope of the present application is
not intended to be limited to the particular embodiments of
the process, machine, manufacture, composition of matter,
means, methods and steps described in the specification. One
30 of ordinary skill in the art will readily appreciate from this
disclosure that processes, machines, manufacture, composi
tions of matter, means, methods, or steps, presently existing
or later to be developed are equivalent to, and fall within the
Scope of what is claimed. Accordingly, the appended claims
35 are intended to include within their scope Such processes,
machines, manufacture, compositions of matter, means,
methods, or steps.
What is claimed is:
40 1. A method of aggregating data in a computerized appa
ratus, the method comprising:
obtaining a plurality of accounting records from a plurality
of physical locations;
storing the plurality of accounting records in a database
45 associated with the computerized apparatus;
extracting the plurality of accounting records from the
database, each of the accounting records comprising an
account identifier, an account name, and a parent
account identifier, the parent account identifier compris
50 ing either: a top level account identifier, or a non-top
level account identifier;
for each of the plurality of accounting records, assigning
that accounting record in the computerized apparatus as
a top-level parent accounting record in a hierarchical
55 structure when that accounting record comprises the top
level account identifier, otherwise placing that account
ing record into a data structure associated with the com
puterized apparatus;
combining those top-level parent accounting records that
60 share a common name using the computerized appara
tus;
for each of the plurality of accounting records placed into
the data structure, when the parent account identifier
associated with each accounting record matches the
65 account identifier of the top-level parent accounting
record, combining that accounting record into the hier
archical structure with its associated top-level parent
 US 9,020,946 B2
7 8
accounting record using the computerized apparatus,
otherwise leaving that accounting record in the data
Structure:
for each of the plurality of accounting records whose par
ent account identifier does not match the account iden
tifier of the top-level parent accounting record, combin
ing that accounting record into the hierarchical structure
when the parent account identifier for that accounting
record matches the account identifier of an accounting
record that has already been placed into the hierarchical
structure using the computerized apparatus, otherwise
leaving that accounting record in the data structure;
repeating the act of combining the accounting record into
the hierarchical structure using the computerized appa
ratus until no accounting records exist in the data struc
ture; and
generating a report using the computerized apparatus
based at least on the hierarchical structure created.
2. The method of claim 1, wherein the combining of that
accounting record into the hierarchical structure is accom
plished via a recursive aggregation.
3. The method of claim 1, wherein a determination of
whether the parent account identifier associated with each
account record matches the account identifier of the top-level
parent accounting record occurs via a general purpose pro
gramming language rather than a query language.
4. The method of claim 3, wherein the extracting the plu
rality of accounting records from the database occurs via the
query language.
5. The method of claim 1, further comprising prior to
generating the report, verifying authorization of a user to
generate the report.
6. The method of claim 1, wherein the obtaining of the
plurality of accounting records from the plurality of physical
locations comprises synchronizing the plurality of account
ing records between a central location and the plurality of
physical locations.
7. Computerized apparatus comprising a non-transient
storage medium having a plurality of computer readable
instructions disposed thereon, the instructions configured to,
when executed:
obtain a plurality of accounting records from a plurality of
physical locations;
store the plurality of accounting records in a database asso
ciated with the computerized apparatus;
extract the plurality of accounting records from the data
base, each of the accounting records comprising an
account identifier, an account name, and a parent
account identifier, the parent account identifier compris
ing either: a top level account identifier, or a non-top
level account identifier;
for each of the plurality of accounting records, assign that
accounting record in the computerized apparatus as a
top-level parent accounting record in a hierarchical
structure when that accounting record comprises the top
level account identifier, otherwise place that accounting
record into a data structure associated with the comput
erized apparatus;
combine those top-level parent accounting records that
share a common name using the computerized appara
tus;
for each of the plurality of accounting records placed into
10
the data structure, when the parent account identifier
associated with each accounting record matches the
account identifier of the top-level parent accounting
record, combine that accounting record into the hierar
15 chical structure with its associated top-level parent
accounting record using the computerized apparatus,
otherwise leaving that accounting record in the data
Structure:
for each of the plurality of accounting records whose par
ent account identifier does not match the account iden
tifier of the top-level parent accounting record, combine
that accounting record into the hierarchical structure
when the parent account identifier for that accounting
record matches the account identifier of an accounting
25 record that has already been placed into the hierarchical
structure using the computerized apparatus, otherwise
leave that accounting record in the data structure;
repeat the combination of the accounting record into the
hierarchical structure until no accounting records exist
30
in the data structure; and
generate a report using the computerized apparatus based
at least on the hierarchical structure created.
8. The computerized apparatus of claim 7, wherein plural
35 ity of accounting records are stored in a plurality of Quick
Books files.
9. The computerized apparatus of claim 7, wherein the
instructions that make a determination of whether the parent
account identifier associated with each account record
40 matches the account identifier of the top-level parent account
ing record occurs via a general purpose programming lan
guage rather than a query language.
10. The computerized apparatus of claim 7, wherein the
instructions are further configured to, when executed:
45 synchronize the plurality of accounting records between a
central location and the plurality of physical locations.
11. The computerized apparatus of claim 7, wherein place
ment of accounting records into the data structure comprises
creation of a hash table entry for each accounting record that
50 comprises a non-top level account identifier, each hash table
entry accessible via a key, the key comprising the parent
account identifier of the accounting record.
k k k k k