Note: Descriptions are shown in the official language in which they were submitted.
CA 02657303 2009-03-06
INTERNET ENABLED VEHICLE DOWNPAYMENT SYSTEM AND
METHOD WITH
BACKEND SYSTEM FOR MANAGING VEHICLE DEALER
INFORMATION
FIELD OF INVENTION
[0001] This invention relates to online vehicle searching and purchasing.
[0002] This invention relates to management of accounting information for
service, parts, and product oriented business.
BACKGROUND OF THE INVENTION
[0003] It is recognised that over 75 percent of new car buyers consult the
Internet
before making their purchase. Presently, new car inventory currently on
franchise new
car dealer lots can be viewed on various Internet Web sites so that every car
shopper
can find out which dealers may have the vehicle he or she wants to buy while
sitting at
their computer. Accordingly, the current use of the Internet for purchase of
vehicles by
consumers is growing in popularity due to the ever-expanding placement of
information
that is accessible on-line through various search tools, such as search
engines and
specialized consumer vehicle portals. Placement of advertising content on-line
has
grown in popularity due to advantages in reaching a wider target audience.
Further, the
Internet is fast becoming the primary information search tool for obtaining
information
about vehicles and vehicle dealerships.
[0004] Unfortunately, problems exist in today's vehicle purchasing
environments,
due to large and often disconnected amounts of dealership vehicle data stored
locally
(e.g. at the dealership) and the inability of users to find desired vehicles
remotely (via a
search query over a global network - e.g. the internet) that are relevant to
the users,
such as near the users' location, in the appropriate price range, etc.
[0005] Further, current automotive information systems do not provide down
payment facilities for automobiles that match vehicle searchers search
criteria. There is
CA 02657303 2009-03-06
-2-
a current need for facilitating down payment ability for car dealers, as well
as for
tracking automotive leads generated through online interaction between the
vehicle
searchers and automotive product of the dealers.
[0006] Further, it is difficult for vehicle retailers to manage their product
inventories to coordinate published details of their products in the form of
advertisements in a product information aggregated environment. Further,
currently it
is difficult for retailers to coordinate generation of advertisements and
other product
descriptions for publication electronically.
[0007] Unfortunately, problems exist in today's vehicle information management
environments, due to large and often disconnected amounts of dealership
vehicle data
stored locally (e.g. at the dealership) and the inability of users to find
desired vehicles
remotely (via a search query over a global network - e.g. the Internet) that
are relevant
to the users, such as near the users' location, in the appropriate price
range, etc. For
example, a major problem in current DMS systems in the USA and Canada is that
they
do not do proper work in progress (WIP) accounting. The current DMS systems
also
have weak integration between the inventory applications and the general
ledger, which
means that the current DMS systems have major manual reconciliations that need
to be
done every month in order to do accurate financial reporting.
[0008] Further, it is recognised that the dealership data is often unbalanced
financially, due to disconnects in financial data relationship management,
both at the
dealership level and at the consolidated dealership level (e.g. one company
owning
more than one dealership for one or more different vehicle manufacturers).
This
unbalanced financial data is currently reconciled through manual
reconciliation
procedures implemented many times throughout a financial year of the
dealership.
However, the use of manual reconciliation practices does not facilitate the
operation of
dealerships to adapt to constantly changing vehicle market conditions and the
leveraging of the Internet as a sales and marketing tool. It is a disadvantage
to the
dealership to have dated or otherwise incorrect financial data relating to the
in-stock and
on-order parts, service and individual vehicles, in view of the dynamic nature
of up-to-
date information needed in today's Internet based sales and marketing
practices.
CA 02657303 2009-03-06
-3-
[0009] Accordingly, it is difficult for vehicle retailers/dealers to manage
their
product inventories to coordinate published details of their products in the
form of
advertisements in a product information aggregated environment
SUMMARY
[0010] It is an object of the present invention to provide an vehicle
purchasing
environment to obviate or mitigate at least some of the above-presented
disadvantages.
[0011] It is an object of the present invention to provide an vehicle
information
management environment to obviate or mitigate at least some of the above-
presented
disadvantages.
[0012] Current automotive information systems do not provide down payment
facilities for automobiles that match vehicle searchers search criteria. There
is a current
need for facilitating down payment ability for car dealers, as well as for
tracking
automotive leads generated through online interaction between the vehicle
searchers
and automotive product of the dealers. Contrary to current online automotive
systems,
there is provided a system and method for providing access to a user of
vehicle
information over a telecommunications network for facilitating a purchase of a
vehicle
from a vehicle dealer. The system and method comprise a database adapted for
storing a plurality of vehicle information obtained from a plurality of
vehicle dealer
databases, the vehicle information including vehicle characteristics of
vehicles available
for purchase by the user. Further, a network interface is used for receiving
at least one
search request parameter from the user from the network and for sending over
the
network in a response message response data selected from the plurality of
vehicle
information matching the at least one search parameter. Further, an
information
module is used for coordinating the processing of a down payment from the user
for a
selected vehicle chosen from one or more vehicles defined in the response
data, such
that the down payment represents a portion of the purchase price of the
selected
vehicle. As well, the information module confirms the selected vehicle is
available for
purchase before accepting a submission of the down payment.
[0013] Current dealership data is often unbalanced financially, due to
disconnects
in financial data relationship management, both at the dealership level and at
the
CA 02657303 2009-03-06
-4-
consolidated dealership level (e.g. one company owning more than one
dealership for
one or more different vehicle manufacturers). However, the use of manual
reconciliation practices does not facilitate the operation of dealerships to
adapt to
constantly changing vehicle market conditions and the leveraging of the
Internet as a
sales and marketing tool. It is a disadvantage to the dealership to have dated
or
otherwise incorrect financial data relating to the in-stock and on-order
parts, service and
individual vehicles, in view of the dynamic nature of up-to-date information
needed in
today's Internet based sales and marketing practices. Contrary to current
vehicle
information management systems, there is provided a system and method for
representing in-progress activities of a vehicle dealership in financial
information of a
general ledger. The system and method comprise a receipt module adapted for
receiving financial data associated with a dealership activity and having an
in-progress
status, and for subsequently receiving update information representing a
cancellation of
the in-progress status of the dealership activity. A storage is used with an
account data
structure adapted for storing the financial data, such that the account data
structure is
associated with a trio of accounts in the general ledger, such that pairs of
the trio of
accounts are related through double entry bookkeeping. A processing module is
adapted for updating the received financial data in the account data structure
as
representing a financial value of the in-progress activity, such that the
updating is done
in response to the receipt of the financial data, such that the financial
value represents a
debit entry for application to the first account of the trio of accounts and
represents a
credit entry for application to the second account of the trio of accounts,
the credit and
debit entries having the financial value. The processing module is further
adapted for
updating the financial value in the account data structure in response to
receipt of the
cancellation of the in-progress status, such that the updating is for revising
the credit
entry of said second account to a debit and for adding a credit entry to the
third account
of the trio of accounts, the revised credit entry and the added credit entry
having the
financial value. Subsequently, the entries stored in the account data
structure are used
for updating the financial information corresponding to at least two of the
trio of
accounts in the general ledger, when requested.
[0014] One aspect provided is a system for providing access to a user of
vehicle
information over a telecommunications network for facilitating a purchase of a
vehicle
from a vehicle dealer, the system comprising: a database adapted for storing a
plurality
CA 02657303 2009-03-06
-5-
of vehicle information obtained from a plurality of vehicle dealer databases,
the vehicle
information including vehicle characteristics of vehicles available for
purchase by the
user; a network interface adapted for receiving at least one search request
parameter
from the user from the network and for sending over the network in a response
message response data selected from the plurality of vehicle information
matching the
at least one search parameter; and an information module adapted for
coordinating the
processing of a down payment from the user for a selected vehicle chosen from
one or
more vehicles defined in the response data, the down payment representing a
portion of
the purchase price of the selected vehicle, such that the information module
is further
adapted to confirm the selected vehicle is available for purchase before
accepting a
submission of the down payment; wherein upon validation of the down payment,
the
user is invited to follow-up with the vehicle dealer for finalizing the
purchase of the
selected vehicle.
[0015] A further aspect provided is a method for providing access to a user of
vehicle information over a telecommunications network for facilitating a
purchase of a
vehicle from a vehicle dealer, the method including instructions stored on a
memory for
execution by a computer processor, the instructions comprising: accessing a
plurality of
vehicle information obtained from a plurality of vehicle dealer databases, the
vehicle
information including vehicle characteristics of vehicles available for
purchase by the
user; receiving at least one search request parameter from the user from the
network
and for sending over the network in a response message response data selected
from
the plurality of vehicle information matching the at least one search
parameter; and
coordinating the processing of a down payment from the user for a selected
vehicle
chosen from one or more vehicles defined in the response data, the down
payment
representing a portion of the purchase price of the selected vehicle, such
that the
information module is further adapted to confirm the selected vehicle is
available for
purchase before accepting a submission of the down payment; wherein upon
validation
of the down payment, the user is invited to follow-up with the vehicle dealer
for finalizing
the purchase of the selected vehicle.
[0016] A still further aspect is where the information module is adapted for
tagging the vehicle information related to the selected vehicle as unavailable
for use as
message response data for subsequent search requests received other users and
CA 02657303 2009-03-06
-6-
further adapted for removing the tagging of said vehicle information in the
event that the
down payment is returned to the user.
[0017] A still aspect provided is a system for representing in-progress
activities
of a vehicle dealership in financial information of a general ledger; the
system
comprising: a receipt module adapted for receiving financial data associated
with a
dealership activity and having an in-progress status, and for subsequently
receiving
update information representing a cancellation of the in-progress status of
the
dealership activity; a storage having an account data structure adapted for
storing the
financial data, the account data structure associated with a trio of accounts
in the
general ledger, pairs of the trio of accounts being related through double
entry
bookkeeping; a processing module adapted for updating the received financial
data in
the account data structure as representing a financial value of the in-
progress activity,
the updating in response to the receipt of the financial data, such that the
financial value
represents a debit entry for application to the first account of the trio of
accounts and
represents a credit entry for application to the second account of the trio of
accounts,
the credit and debit entries having the financial value; the processing module
is further
adapted for updating the financial value in the account data structure in
response to
receipt of the cancellation of the in-progress status, such that the updating
is for revising
the credit entry of said second account to a debit and for adding a credit
entry to the
third account of the trio of accounts, the revised credit entry and the added
credit entry
having the financial value; wherein the entries stored in the account data
structure are
used for updating the financial information corresponding to at least two of
the trio of
accounts in the general ledger when requested.
[0018] A still further aspect provided is a method for representing in-
progress
activities of a vehicle dealership in financial information of a general
ledger; the method
including instructions stored on a memory for execution by a computer
processor, the
instructions comprising: receiving financial data associated with a dealership
activity,
the financial data having an in-progress status; accessing account data
structure
adapted for storing the financial data, the account data structure associated
with a trio
of accounts in the general ledger, pairs of the trio of accounts being related
through
double entry bookkeeping; updating the received financial data in the account
data
structure as representing a financial value of the in-progress activity, the
updating in
CA 02657303 2009-03-06
-7-
response to the receipt of the financial data, such that the financial value
represents a
debit entry for application to the first account of the trio of accounts and
represents a
credit entry for application to the second account of the trio of accounts,
the credit and
debit entries having the financial value; subsequently receiving update
information
representing a cancellation of the in-progress status of the dealership
activity; and
updating the financial value in the account data structure in response to
receipt of the
cancellation of the in-progress status, such that the updating is for revising
the credit
entry of said second account to a debit and for adding a credit entry to the
third account
of the trio of accounts, the revised credit entry and the added credit entry
having the
financial value; wherein the entries stored in the account data structure are
used for
updating the financial information corresponding to at least two of the trio
of accounts in
the general ledger when requested.
[0019] A still further aspect provided is a general ledger module adapted for
receiving a ledger generation request and for updating the financial
information of the
general ledger using the contents of the account data structure.
[0020] A still further aspect provided is a consolidation module adapted for
combining a plurality of account data structures in the storage for use in
generating a
consolidated general ledger representing the financial information for a
plurality of
dealerships, such that each of the plurality of account data structures is
associated with
a respective dealership of the plurality of dealerships.
[0021] A still further aspect is wherein collection and organization of a
plurality of
vehicle information is obtained from a specialized aggregation framework, such
that the
specialized aggregation framework first obtained the plurality of vehicle
information from
a plurality of vehicle dealer databases.
BRIEF DESCRIPTION OF THE DRAWINGS
[0022] Exemplary embodiments of the invention will now be described in
conjunction with the following drawings, by way of example only, in which:
[0023] Figure 1 is a block diagram of components of a vehicle purchase and
management system;
CA 02657303 2009-03-06
-8-
[0024] Figure 2 is an example information generated by the information
management framework of Figure 1;
[0025] Figure 3 is a block diagram of an example computing device for
implementing the components of the system of Figure 1;
[0026] Figure 4 is an example operation of the system of Figure 1;
[0027] Figure 5 is an example embodiment of the framework of Figure 1;
[0028] Figure 6 is an example operation of the framework of Figure 5;
[0029] Figure 7 is a further example operation of the framework of Figure 4;
[0030] Figure 8 is an example consolidation engine configuration of the
framework of Figure 1;
[0031] Figure 9 an example accounting engine configuration of the framework of
Figure 1;
[0032] Figure 10 is a further example of the accounting engine configuration
of
Figure 9; and
[0033] Figure 11 is a flowchart of an example operation of the engines of
Figure
1.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT(S)
[0034] It is recognised in the following description, it may be advantageous
to set
forth definitions of certain words and phrases used throughout this patent
document,
such as : the terms "include" and "comprise," as well as derivatives thereof,
mean
inclusion without limitation; the term "or," can be inclusive, meaning and/or;
the phrases
"associated with" and "associated therewith," as well as derivatives thereof,
may mean
to include, be included within, interconnect with, contain, be contained
within, connect to
or with, couple to or with, be communicable with, cooperate with, interleave,
juxtapose,
be proximate to, be bound to or with, have, have a property of, or the like;
and the term
"controller" "engine" or "module" or "processor "means any device, system or
part
thereof that controls at least one operation, such a device may be implemented
in
hardware, firmware or software, or some combination of at least two of the
same. It
should be noted that the functionality associated with any particular
"controller" "engine"
or "module" or "processor "may be centralized or distributed, whether locally
or
CA 02657303 2009-03-06
-9-
remotely. Definitions for certain words and phrases are provided throughout
this patent
document, those of ordinary skill in the art should understand that in many,
if not most
instances, such definitions apply to prior, as well as future uses of such
defined words
and phrases.
Vehicle Purchase and Information Environment 10
[0035] Referring to Figure 1, shown is a vehicle purchase and information
system
10, with respect to the interaction between the online information 107 (e.g.
vehicle
definitions/profiles constructed from information obtained from dealer vehicle
information) and DMSs of the dealers 114. The Internet enabled vehicle
purchase
system 10 facilitates the searching of vehicle dealer inventories 115 via an
electronic
vehicle database110 (containing vehicles of both on the lot and custom ordered
in view
of consumer selected options) and for processing of a real-time, nominal down
payment
/transaction 92 by a consumer 104 (e.g. through an on-line credit card
transaction) for a
vehicle chosen from the dealer inventories 115.
[0036] A vehicle framework 112 consolidates selected vehicle information from
the dealer inventory information 115 from a plurality of dealers 114 in a
framework
database 110, and then provides this information to the consumers 104 over a
network
11 (e.g. the Internet) to facilitate vehicle search and purchase capabilities.
Once the
down payment 92 is accepted by the framework 112, the consumer 104 would then
either in person, or remotely, communicate with the dealership 114 for
completing all
paperwork necessary to purchase the chosen vehicle. It is also recognised that
the
framework 112 is also adapted to monitor the status of any particular vehicle,
vehicle
component, and/or vehicle service tracked in the database 110 (and/or
database(s)
115) related to the information 107, as confirmed via update information from
the DMSs
of the dealers 114 (e.g. the sale/sold status of a vehicle). Further, the
framework 112 is
also adapted to restrict purchase access (for example restricting contents of
related
information 107 from being included in the search results 106) to any
particular vehicle/
vehicle component/ vehicle service related to the information 107 that is
already tagged
or otherwise reserved for another user (e.g. for those vehicles in the midst
of purchase
by the other user - such as in the case where a down payment 92 has already
been
submitted/accepted on the vehicle).
CA 02657303 2009-03-06
-10-
[0037] Further to the above, it is recognised that both the dealers 114 and
the
consumers 104 can be registered with a network interface 202 (e.g. Web portal)
of the
framework 112, to facilitate full use of the vehicle search and payment
features provided
by the framework 112 (and any interaction between the framework 112 and the
dealers
114 - e.g. DMSs). Once registered, the contact information of the consumers
104 can
be sent to respective dealers 114, as a result of any interaction between the
consumers
104 and the framework 112 (e.g. in view of the request 105 and response 106
messaging).
[0038] The vehicle information 107 provided to the users (as well as
searchable
by the users in the database 110) can be for any complete vehicle and/or
vehicle
component (e.g. part) and/or available vehicle service (e.g.
maintenance/repair of a
vehicle), such that the vehicle can be defined as any motorized vehicle (e.g.
car, truck,
bus, van, motor home, etc.) that is for use as a means of transport (both on
and off-
road) for a person/people and/or conveyed goods. Accordingly, the system 10
can also
accommodate service and parts in addition to search and purchase of the entire
vehicle,
such that the framework 112 would include service/parts definitions 107
similar to the
vehicle definition 107. In any event, it is recognized that searching and
purchasing via
the framework 112 can include vehicles, parts, and/or service, as further
described
below, and that discussions of vehicles can also pertain to parts and/or
service
interaction between the framework 112 and the dealers 114 and the framework
112 and
the consumers 104, as desired. It is recognised that the service and/or parts
can also
be provided to the consumer 14 using down payment(s) 92 suitable to the cost
of the
service and/or parts. For example, the consumer 104 can set-up and make a down
payment 92 related to an upcoming service/repair appointment for his currently
owned
vehicle at one of the dealers 114.
[0039] Communications between the consumers 104, the framework 112, and
the dealers 114 are facilitated via one or more communication networks 11
(such as
intranets and/or extranets - e.g. the Internet). The vehicle information
system 10 can
include multiple consumers 104, one or more frameworks 112 (e.g. each
framework
directed to a specified vehicle type - such as particular manufacturers,
particular
geographic regions, particular vehicle classifications such as new or used,
etc.), multiple
dealers 114, respective multiple hosting devices 101, and one or more coupled
CA 02657303 2009-03-06
-11-
communication networks 11, as desired. Examples of the devices 101 are
provided
below.
[0040] The DMSs can include an information management framework 152 (e.g.
as part of a fully configured DMS and/or as a local/remote service coupled to
the DMS)
for dynamically monitoring of parts, service, vehicle inventory data (also
referred to as
vehicle data 140) and their associated financial data 142 in a database 115
coupled to
the DMSs. It is recognised that the vehicle data 140 of the different data
types (i.e.
parts, service, vehicle inventory) and their corresponding financial data 142
are
interrelated in the DMSs through a general accounts ledger 150 (see Figure 2),
which
also includes accounts payable 154 and accounts receivable 156 sub ledgers 151
as
coordinated by the management framework 152, as further described below. In
overview, the DMS systems (i.e. inclusive of the framework 152) provides for
proper
work in progress (WIP) accounting. The DMS systems also have proper
integration
between the inventory applications (e.g. parts, sales, service, etc.) and the
general
ledger 150, which means that the major manual reconciliations are inhibited
every
month by the dealer 114, in order to do accurate financial reporting.
[0041] Further, in overview, the DMSs (i.e. inclusive of the framework 152
functionality) also provide for consolidated accounting, whereby a multi
franchise and/or
multi-location dealer 114 has the ability to submit OEM financial statements
that
adheres to manufacturer standards while enabling the dealer 114 to have
consolidated
reporting. The configured DMS can include a Consolidated Financial Statement
that
enables the dealer to view all Franchisee/Companies as a single company, and
can
provide Consolidated accounting view of all activities combined and broken out
by
department with extensive break down detail (i.e. views of pertinent data
140,142), see
Figure 2, as further described below.
[0042] In terms of vehicle information 107 searching and purchasing by users
104 over the network 11, a vehicle framework 112 consolidates selected vehicle
information 108 (e.g. subsets of the data 140,142) from the dealer inventory
information
115 from a plurality of dealers 114 in a framework database 110, and then
provides this
information to the consumers 104 over a network 11 (e.g. the Internet) to
facilitate
vehicle search and purchase capabilities. It is also recognised that the
framework 112
CA 02657303 2009-03-06
-12-
is adapted to monitor the status of any particular vehicle, vehicle component,
and/or
vehicle service tracked in the database 110 (and/or database(s) 115) related
to the
information 107, as confirmed via update information from the DMSs of the
dealers 114
(e.g. the sale/sold status of a vehicle). Further, the framework 112 is also
adapted to
restrict purchase access (for example restricting contents of related
information 107
from being included in the search results 106) to any particular vehicle/
vehicle
component/ vehicle service related to the information 107 that is already
tagged or
otherwise reserved for another user (e.g. for those vehicles in the midst of
purchase by
the other user - such as in the case where the transaction 92 (e.g. down
payment) has
already been submitted/accepted on the vehicle).
[0043] Further to the above, it is recognised that both the dealers 114 and
the
consumers 104 can be registered with a network interface 202 (e.g. Web portal)
of the
framework 112, to facilitate full use of the vehicle search and payment
features provided
by the framework 112 (and any interaction between the framework 112 and the
dealers
114 - e.g. DMSs). Once registered, the contact information of the consumers
104 can
be sent to respective dealers 114, as a result of any interaction between the
consumers
104 and the framework 112 (e.g. in view of the request 105 and response 106
messaging). Further, it is recognised that the management framework 152 can
have a
configured network interface 202 for providing communication between the
dealer
interface 117 (of the DMS) and the management framework 152, when hosted
remote
to the dealer 114.
[0044] The vehicle information 107 provided to the users 104 (as well as
searchable by the users 104 in the database 110) can be for any complete
vehicle
and/or vehicle component (e.g. part) and/or available vehicle service (e.g.
maintenance/repair of a vehicle), such that the vehicle can be defined as any
motorized
vehicle (e.g. car, truck, bus, van, motor home, etc.) that is for use as a
means of
transport (both on and off-road) for a person/people and/or conveyed goods.
This up-
to-date vehicle information 107 is aggregated from the available information
108 from
the various dealer databases 115 via their DMSs, as managed by the management
framework 152.
CA 02657303 2009-03-06
-13-
[0045] Accordingly, the system 10 can also accommodate service and parts in
addition to search and purchase of the entire vehicle, such that the framework
112
would include service/parts definitions 107 similar to the vehicle definition
107. In any
event, it is recognized that searching and purchasing via the framework 112
can include
vehicles, parts, and/or service, as further described below, and that
discussions of
vehicles can also pertain to parts and/or service interaction between the
framework 112
and the dealers 114 and the framework 112 and the consumers 104, as desired.
It is
recbgnised that the service and/or parts can also be provided to the consumer
14 using
transactions 92 suitable to the cost of the service and/or parts. For example,
the
consumer 104 can set-up and make a transaction (e.g. down payment) 92 over the
network 11 related to an upcoming service/repair appointment for his currently
owned
vehicle at one of the dealers 114.
[0046] Communications between the consumers 104, the framework 112, the
framework 152 (if hosted remotely for example), and the dealers 114 (e.g. the
DMSs
and/or interface applications 117 connected to the DMSs) are facilitated via
one or more
communication networks 11 (such as intranets and/or extranets - e.g. the
Internet).
The vehicle information system 10 can include multiple consumers 104, one or
more
frameworks 112 ,152 (e.g. each framework directed to a specified vehicle type -
such
as particular manufacturers, particular geographic regions, particular vehicle
classifications such as new or used, etc.), multiple dealers 114 and their
respective
DMSs, respective multiple hosting devices 101, and one or more coupled
communication networks 11, as desired. Examples of the devices 101 are
provided
below.
[0047] It is also recognised that the framework 112 can consist of a plurality
of
frameworks 112, such that a number of specialized frameworks 112 (based on
vehicle
make, model, year, new/used, geographic region, etc.) report to and interact
with one or
more aggregation frameworks 112 configured to collect the information 107 from
the
specialized frameworks 112 for submission to the user in the response 106,
request the
information 107 from the specialized frameworks 112 in view of the request 105
received from the user 104, and to interact with the user 104 and the
specialized
frameworks 112 to coordinate the submission and acceptance of the down payment
92,
as further described below.
CA 02657303 2009-03-06
-14-
Consumers 104
[0048] The consumers 104 can be potential vehicle purchasers (e.g. people,
named organizations, etc.) that desire to purchase the vehicle based on
vehicle details
contained in the vehicle definitions 107 that are available from the framework
112. The
vehicle definitions 107 could contain vehicle data such as but not limited to:
image data;
video data; audio data; and/or text/literary data, such that the vehicle data
provides
information for use by the consumer 104 in making a decision whether to or not
to
purchase the vehicle. The user 104 submits the search request 105 to the
framework
112 over the network 11 in order to find out about the vehicle details and
associated
price, delivery, and/or location information of the vehicle, through matching
of at least
some of the search parameters 99 in the request 105 with contents of the
vehicle
definition 107. For example, the consumer 104 wants to locate all vehicles of
a certain
make and model and year in the state of New York. These parameters 99 would be
part of the search request 105, which is then sent to the framework 112 for
matching
against the contents of the vehicle definitions 107 stored in the database
110.
[0049] It is recognised that the framework(s) 112 can be configured for
communication over the network 11 with the consumers 104 and with the dealers
114
(e.g. via their DMSs). This is compared to the management framework(s) 152,
which
can be configured for communication over the network 11 with the dealers 114
(e.g. via
their DMSs), if hosted remotely.
[0050] Accordingly, in view of the above, the online system 10 of locating a
vehicle having specific details in an inventory 115 (actual on the lot and/or
virtual as not
on the lot but available for purchase through the dealership 114) is
represented by the
product definitions 107 stored in the framework 112 data base 110, as made
available
by the DMSs as information 108 (for data 104,142 managed by the management
frameworks 152). The framework 112 includes a locate client process operable
to
receive vehicle details parameters 99 and generate a search response 106
message
incorporating the vehicle details data in response to user input, and an
inventory
database 110 storing vehicle availability data of dealer inventory 115. The
framework
112 includes a locate server process operable to receive the search request
message
from the locate client process, and search the vehicle availability data in
the database
CA 02657303 2009-03-06
-15-
110 for vehicles matching and substantially matching the vehicle details data.
The
locate server is further operable to generate the search reply message 106
containing
the matching vehicles and return the search reply message to the locate client
process,
including the vehicle information 107. In general, a consumer 104 provided
with real-
time information is contemplated, prior to the placement of an order or
purchase by the
consumer 104. The information107 regards the availability and status of the
vehicle in
relation to the framework 112 inventory 110. The customer 104 is afforded the
opportunity to specify the desired vehicle to search the inventory for
availability, as well
as the ability to tag a vehicle that is currently anywhere in the inventory
110 that fits
his/her criteria for purchase, by placing the down payment 92, e.g.
transaction.
Examgle ogeration of the Down Payment 92
[0051] Referring to Figures 1 and 4, an example process 160 for a nominal down
payment 92 is as follows, after the vehicle and/or vehicle part/service is
selected from
the information 107 provided by the framework 112,namely: at step 158.
Consumer 104
fills in credit card details (or other payment mechanism details - e.g.
PayPaITM) in via
the Web portal 202 and clicks a payment button; at step 162 the Web interface
202 runs
a web service that sends the credit card payment data 92 via the Internet 11
to a third
party payment processor 120 (e.g. the payment engine 218 if hosted remote to
the
framework 212); at step 163, the payment transaction is posted/submitted to
the
dealer's General Ledger (of the DMS) (e.g. in real-time), which can be
provided by the
dealer's DMS and/or the Web interface 113; at step 164, the payment processor
120
validates the consumer's payment 92 and sends the funds to the dealer's bank
account
(an arrangement set up in advance by the dealer 114); at step 165, the
information 107
pertaining to the vehicle to which the down payment 92 is associated with is
updated,
e.g. via an update module 212 (see Figure 5), such that the vehicle
information 107 is
tagged to indicate that the vehicle (and/or vehicle parts/service) is marked
as a
restricted status (e.g. the tagged vehicle (and/or vehicle parts/service) is
now not
available to searches/access by other consumers 104 unless the tagged vehicle
information 107 is cleared of the restricted status at step 167 (e.g. down
payment 92 for
the vehicle and/or vehicle parts/service is returned to the consumer 104 and
the
associated vehicle and/or vehicle parts/service is made available again for
searching by
the consumers 104 for purchase). Otherwise, the vehicle is purchased by the
consumer
CA 02657303 2009-03-06
-16-
104 (i.e. through follow-up interaction between the consumer 104 and the
dealer 114)
and the vehicle listing is removed at step 166 (e.g. updated as no longer
available or
otherwise deleted from the database 110).
[0052] Accordingly, in view of the above, the online system 10 of locating a
vehicle having specific details in an inventory 115 (actual on the lot and/or
virtual as not
on the lot but available for purchase through the dealership) is represented
by the
product definitions 107 stored in the framework 112 data base 110. The
framework 112
includes a locate client process (e.g. information module 216) operable to
receive
vehicle details parameters99 and generate a search response 106 message
incorporating the vehicle details data in response to user input, and an
inventory
database 110 storing vehicle availability data of dealer inventory 115. The
framework
112 includes a locate server process (e.g. information module 216) operable to
receive
the search request message from the locate client process, and search the
vehicle
availability data in the database 110 for vehicles matching and substantially
matching
the vehicle details data. The locate server is further operable to generate
the search
reply message 106 containing the matching vehicles and return the search reply
message to the locate client process, including the vehicle information 107.
In general,
a consumer 1-04 provided with real-time information is contemplated, prior to
the
placement of an order or purchase by the consumer 104. The information107
regards
the availability and status of the vehicle in relation to the framework 112
inventory 110.
the customer 104 is afforded the opportunity to specify the desired vehicle to
search the
inventory for availability, as well as the ability to tag a vehicle that is
currently anywhere
in the inventory 110 that fits his/her criteria for purchase, by placing the
down payment
92, as described.
Framework 112
[0053] Referring again to Figures 1 and 5, the database 110 is hosted by or
otherwise accessed through the information aggregation framework 112, which
aggregates vehicle information 108 from various DMS sources (e.g. product
manufacturers, product retailers such as vehicle dealerships). This aggregated
vehicle
information 108 is then made available as the vehicle definitions 107 to the
consumers
104 via the database 110. The aggregation of the vehicle information 108 in
the
CA 02657303 2009-03-06
-17-
electronic database 110 can be applied to any vehicle retailer, vehicle
dealerships in a
competitive marketplace for similar products through digital aggregation of
vehicle
information 108, including for-sale/availability status in view of any down
payments 92
and/or completed contracts for the vehicles as noted by the dealers 114 in
their DMSs)
as further described below. It is recognised that the vehicle information 108,
when
received by the framework 112, may already contain a formatted vehicle
definition 107
(e.g. vehicle advertisement) as part of the vehicle information 108. Further,
the
framework 112 may make available the formatted vehicle definition 107 to the
consumer
104, as received, or may modify the received formatted vehicle definition 107
before
making it available to the consumer 104. It is also recognised that the
framework 112
can supply the vehicle definition 107 to a third party network interface, not
shown, (e.g.
independent web portal), who then makes the product definitions 107 available
to the
consumers 104 via corresponding ones of the search requests 105 and results
106 over
the network 11.
[0054] Also, for example, the framework 112 also hosts, and/or has access to
(e.g. hosted by a third party on the network 11), a payment engine 218 that is
configured for coordinating the processing (e.g. in conjunction with financing
entities
associated with the dealer 114, e.g. banks, financing companies, etc., not
shown) the
down payment 92. For example, the payment engine 218 could be coupled to the
information module 216, for coordinating the information used in defining or
otherwise
reporting on the processing status of the down payment 92.
[0055] Referring to Figure 5, shown is an example framework 112 having a
network interface 202 for interacting with the consumers 104, any specialized
frameworks 112, as well as any DMSs of the dealers 114, in order to facilitate
the
distribution and collection of data (e.g. vehicle information 108, vehicle
information 107,
payment information 92 including payment/purchase status of selected vehicles,
and
any other information included in the messages 105,106). The framework 112
also has:
an aggregation module 210 for collecting the information 108 from all of the
dealers
114, for making available as information 107 to the consumers 104; an update
module
212 for receiving/requesting updates 109 to the information 108 already stored
in the
memory 110; and an information module 216 for receiving the requests 105,
formulating
the responses 106, including identifying any related payment information 92
and
CA 02657303 2009-03-06
-18-
formatting the responses 106 in view of vehicle status information (e.g.
tagged vehicles)
obtained by the dealer 114 (e.g. from the DMSs).
Database 110
[0056] The aggregation of the vehicle information 107 in the electronic
database
110 can be applied to any vehicle retailer, vehicle dealerships in a
competitive
marketplace for similar products through digital aggregation of vehicle
information 108,
including for-sale/availability status in view of any down payments 92 and/or
completed
contracts for the vehicles as noted by the dealers 114 in their DMSs) as
further
described below. It is recognised that the vehicle information may include a
formatted
vehicle definition 107 (e.g. vehicle advertisement) as part of the vehicle
information 107.
Further, the database 110 makes the product definitions 107 available to the
consumers
104 via corresponding ones of the search requests 105 and results 106, as
prompted by
the information module 216.
[0057] In terms of inventory database 110 updates, the inventory database 110
contains the updated vehicle definitions 107 from all the dealerships 114 and
products
in-process (in-transit, in production, and on the order bank). An inventory
data importer
(e.g. the update module 212) can perform the inventory data import batch
process in a
periodic manner, such as nightly, to update109 the data in inventory database
110.
Inventory data importer may use a modem dial-up connection, file transport
protocol
(FTP) and/or other mechanism to pull inventory records from the dealerships
114. The
inventory database 110 may be batch processed or updated in real-time as
necessary
so that the most recent data is available for searching by the consumer 104.
Weekly full
extract may be performed in addition to nightly updates on new data, as well
as other
contemplated update period frequencies. Further, it is noted that the database
110 can
maintain a record of tagged vehicles, as when a vehicle is temporarily tagged
it is not
returned in subsequent search results.
Network Interface 202
[0058] The framework 112 uses the network interface 202 (e.g. a Web portal) to
provide access by the consumer 104, via the DMSs, directly to the dealer's
inventory
CA 02657303 2009-03-06
-19-
115 of vehicles. There is polled (according to a selected poll frequency)
intercommunication between the DMSs (via the Web interfaces) and the Web
portal 202
for any information updates 109 available on the vehicles in the vehicle
inventories 115
(e.g. changes to existing postings, new postings, and deleted postings,
postings with
down payment in process/progress, etc.), as well as for initial information
108 for
vehicles and/or vehicle service/parts. The intercommunication also includes an
availability check on the consumer chosen vehicle prior to acceptance of the
credit card
(or other electronic payment e.g. Pay Pal) down payment 92, in the event that
the
chosen vehicle has recently been sold (or in the process of being sold) onsite
at the
dealership (or via another on-line transaction). Further, once the down
payment 92 is
accepted, the on-line purchase is entered into the respective DMS as if the
consumer
had physically come into the dealership to see a salesperson that is assigned
to the
chosen vehicle.
[0059] The module 202 can be part of the network connection interface 300 (see
Figure 3) of the device 101 operating the framework 112. The module 202 can
communicate synchronously or asynchronously with the device 101 of the
consumer
104 over the network 11 to receive or otherwise structure the search requests
105. For
example, the module 202 could be a Web service as a software system designed
to
support interoperable machine-to-machine interaction over the network 11,
between the
framework 112 and the consumers 104. The Web service of the framework 112, as
facilitated by the module 202 can be configured as a series of Web APIs that
can be
accessed over the network 11 by the consumer 104 and then executed on the
framework 112 hosting the requested services.
[0060] The Web service definition of the interface of the module 202 can
encompass many different systems, such as clients and servers that communicate
using XML messages that follow the SOAP standard. Also, the module 202 could
provide a machine-readable description of the operations supported by the
framework
112 written in the Web Services Description Language (WSDL).
[0061] For example, the module 202 provides to the consumer 104 an electronic
interface for access to the vehicle definitions 107, as searched in the
database 110
through any subset of the vehicle details via the search parameters 99. For
example,
CA 02657303 2009-03-06
-20-
the electronic interface 202 can be a Web portal offering a structured vehicle
search
engine, i.e. the consumers 104 via their browser access the contents of the
electronic
database 110 over the network 11 via the framework 112 that hosts the vehicle
search
engine (e.g. information module 216 - see Figure 5). For example, the
consumers 104
could search vehicle "for sale" information in the database110 to find the
lowest
advertised new vehicle prices in various markets across the country. The
electronic
interface 202 can present predefined search parameter 99 selections (e.g.
vehicle
classifications as selections via suitable user interface control elements) as
product
and/or vendor centric (e.g. vehicle and dealership centric input). Therefore,
instead of
the consumer 104 typing a vehicle of vendor name in the search engine search
string
(e.g. a vehicle or dealership name), the consumer 104 can chose a name from a
list
element that is updated regularly. It is recognised that the selections 99 can
pertain to
the classifications that were assigned to the vehicle definitions 107 via a
classification
module.
[0062] Examples of user interface control elements of the interface 202 can
include such as but not limited to a dropdown list that is similar to a list
box, which
allows the consumer 104 to choose one or more values 99 from the list. When
the
dropdown list is inactive it displays a single value. When activated, the
dropdown list
displays (drops down) a list of values (e.g. classifications) 99, from which
the consumer
104 may select. When the consumer 104 selects a new value 99, the control
element
reverts to its inactive state, displaying the selected value. The control
elements can
include, for example, a combo box having an editable entry portion of the
list. The
navigation field of a web browser is an example of a combo box. A further
example of
the control elements is a list box or tabs that provide for the selection of
one or more
classifications at a time by the consumer 104. A further type of example
control
element is a Pop-up/down menu, whereby pop-ups are used to select a single
classification from a list while pop-downs are used to issue commands 99 (e.g.
customized search terms) or in cases where multiple classifications 99 can be
selected.
In any event, it is recognised that the control elements can be used by the
consumer
104 to formulate at least some of the search parameters 99 of the search
request 105,
for example._The module 202 can include receipt and transmit sub-modules can
be part
of the network connection interface module 202, in accordance with the
parameters of
the search request 105 as well as the generated search results 106, as
desired.
CA 02657303 2009-03-06
-21-
[0063] It is recognised that the above described module 202 can also be used
for
access by the consumer 104 to parts and/or service information made available
to the
framework 112 via the dealers 114 (e.g. from their inventory 115 and coupled
DMSs).
As well, It is recognised that the module 202 can be used to provide for
access with
dealer staff and enabled DMS features that are for example, part of the dealer
DMS
and/or are hosted remote to the dealer (e.g. via the framework 112).
Aggregation Module 210
[0064] Referring again to Figure 5, the aggregation module 210 collects or
otherwise receives all of the vehicle information 108 for use in creating the
vehicle
information 107 searchable in the database 110 by the consumers 104. It is
recognised
that the aggregation of the information 108 can be done using various defined
search
categories, such as but not limited to: new; used; service quality standards;
vehicle type
(e.g. vehicle make, manufacturer); vehicle retailer (e.g. specific dealerships
114 having
the desired vehicle); and/or vehicle location (e.g. physical location of the
vehicle
dealership); etc.
[0065] Further, it is recognised that the aggregation of the vehicle
information 108
in the database 110 (as sourced from various independent physical/virtual
vehicle
definitions, such as vehicle advertisements, from the dealers 114) can
facilitate higher
efficiency and data integrity through vertical specialization, such that the
vehicle
definitions can be organized as vehicle and/or vendor centric (e.g. vehicle
and
dealership centric input). Therefore, instead of the consumer 104 typing a
vehicle of
vendor name for insertion into the search request 105 (e.g. a vehicle or
dealership
name), the consumer can chose the name from a list that is updated regularly,
as
provided by the information module 216, further described below. This list of
available
vehicles, vendors/retailers 114, and/or location of the vendors/retailers 114
could be
provided online via the network interface module 202 of the framework 112. It
is
recognized that the information content available of the vehicle definitions
107 in the
database 110 is dependent upon the vehicle information 108 obtained from the
dealers
114, as well as the periodic updates 109, further noted below.
Update Module 212
CA 02657303 2009-03-06
-22-
[0066] The update module 212 is adapted for receiving/requesting updates 109
to the information 108 already stored in the memory 110, as well as noting
payment
status (e.g. tagged indication for selected vehicle information 107 related to
the down
payment 92 status of the vehicle). For example, in the event that a vehicle is
sold off
the dealership floor, an update message would be sent (either inside or
outside of a
periodic update cycle) from the dealership 114 to the framework 112 that
indicates that
this specific vehicle is no longer available. Also, a further example is where
in the event
that the dealer 114 wishes to change the vehicle pricing or other vehicle
information in
the vehicle definition 107, the update message could be used to inform the
framework
112 to make a corresponding change to the vehicle definition 107 store in the
database
110, via the information 108 made available to the framework 112 from the DMS
of the
dealer 114. It is recognized that the update information 109 could be obtained
from the
DMSs of the dealers 114, and that any interaction (e.g. definition 107
selected from
results 106 list, down payment 92 submitted, etc.) of the consumers 104 with
the
definitions 107 could also be reported back to the dealer DMSs via the
framework 112.
[0067] As further described below, periodic update information 109
(received/obtained from the dealers DMSs) is associated with corresponding
vehicle
definitions 107, in order to have the vehicle definitions properly reflect the
status (e.g.
revised vehicle availability, revised vehicle price, revised vehicle
financing, etc.) of the
vehicles contained in the vehicle inventories 115 of the dealers 114. Each of
the vehicle
definitions 107 can be assigned a unique identifier by the framework 112 when
they
structured and classified for storage in the database 110, whereby this unique
identifier
is communicated to the dealers 114 for each of the vehicle definitions 107
received in
the vehicle information 108. Accordingly, subsequent update information 109
sent by
the dealers 114 contains the appropriate unique identifier, such that the
framework 112
can match the update information 109 to the appropriate vehicle definition
107. The
unique identifier can contain identifier information (e.g. alpha-numeric)
assigned by the
framework 112, which can include information about the specific dealer and/or
retailer
associated with the vehicle of the vehicle definition 107.
Information Module 216
[0068] Referring to Figure 4, the information module 216 of the framework 112
provides published consumer vehicle definitions 107 to a plurality of
potential
CA 02657303 2009-03-06
-23-
consumers 104, via search results 106, based on one or more search requests
105.
One example of the published vehicle definitions 107 is a vehicle
advertisement 107
that provides vehicle details such as price, location, and/or vehicle
description, as
further described below. The search request 105 of the consumer 104 includes
search
parameters 99 (e.g. keyword terms, phrases, etc.) for use in helping to
identify the
search results 106 from the electronic storage 110 (e.g. database) that are
relevant to
the potential consumer 104 of the vehicle defined in the vehicle definition
107. For
example, the consumers 104 could search vehicle "for sale" information in the
database
110 of the system 10 to find the sorted (e.g. lowest) advertised new vehicle
prices
(associated with the corresponding vehicle advertisement 107) in
various/selected
market(s) across the country. Accordingly, the search parameters 99 could
include
parameters such as but not limited to: vehicle type (e.g. vehicle make,
manufacturer);
vehicle retailer (e.g. specific dealerships having the desired vehicle);
and/or vehicle
location (e.g. physical location of the vehicle dealership). The information
module 216
identifies matches to at least some of these search parameters 99 in the
contents of the
various vehicle definitions 107 stored in the database 110, and provides those
matches
in the vehicle definitions 107 submitted in the response message 106. It is
recognised
that the information 107 in the response 106 could have a variety of different
formatted
layouts for sorting the information 107 according to selected categories (e.g.
as
provided in the parameters 99), for example: new; used; service quality
standards;
available parts; vehicle type (e.g. vehicle make, manufacturer); vehicle
retailer (e.g.
specific dealerships 114 having the desired vehicle); and/or vehicle location
(e.g.
physical location of the vehicle dealership); etc.
[0069] For example, the information module 216 could check (e.g. via s set
flag
associated with the information 107) on the consumer chosen vehicle prior to
acceptance/request of the credit card (or other electronic payment e.g. Pay
Pal) down
payment 92, in the event that the chosen vehicle has recently been sold (or in
the
process of being sold) onsite at the dealership (or via another on-line
transaction).
Further, the information module 216 could restrict viewing access to the
information 107
(e.g. decide not to include or to otherwise exclude the information 107) via
the response
106, even if the information 107 matches at least some of the parameters 99 of
the
associated search request 105
CA 02657303 2009-03-06
-24-
Payment Engine 218
[0070] Referring again to Figure 5, a payment engine 218 is configured for
coordinating the processing (e.g. in conjunction with financing entities
associated with
the dealer 114, e.g. banks, financing companies, etc., not shown) the down
payment 92,
for example in conjunction with the information module 216.
[0071] The intercommunication between the consumer 104 and the engine 218
(e.g. via the framework 212) includes an availability check on the consumer
chosen
vehicle prior to acceptance of the credit card (or other electronic payment
e.g. Pay Pal)
down payment 92, in the event that the chosen vehicle has recently been sold
(or in the
process of being sold) onsite at the dealership (or via another on-line
transaction).
Further, once the down payment 92 is accepted, the on-line purchase is entered
into the
respective DMS and confirmed as accepted by the framework 112, as if the
consumer
104 had physically come into the dealership 114 to see a salesperson that is
assigned
to the chosen vehicle and/or vehicle part/service.
[0072] In terms of payment options, the consumer 104 may tag a located
vehicle,
for example, using a customer credit card, checking account number or
electronic
voucher or gift certificate, i.e. the down payment 92. The consumer 104 is
then notified
by the framework 112 and/or directly by the dealer 114 that the vehicle has
been
located and tagged, and may be further notified that the actual purchase or
delivery of
such vehicle may be conditioned, for example, upon payment or credit
verification. The
consumer 104 may be warned that there is a possibility that the vehicle has
been
tagged or sold to someone who may have purchased the vehicle prior to the
consumer's
effort to locate and tag the vehicle. This may occur due to lag time in
updating the
inventory database 110 via the DMSs. It should be noted that the tag/holding
process is
to reserve a vehicle, by providing credit and/or other financial information.
The down
payment 92can be defined as (e.g. provided a credit card account number from
which)
a predetermined amount or a certain percentage of the vehicle price that is
charged to
hold the selected vehicle for subsequent negotiation and possible purchase.
Further,
the consumer 104 is able to tag a vehicle only after a down payment 92 has
been paid
or the consumer's credit has been approved.
CA 02657303 2009-03-06
-25-
Dealers 114
[0073] Referring again to Figure 1, the framework 112 hosts the Web portal
202,
accessed by the consumer 104 via their browser, and is also connected to the
plurality
of Dealer Management Systems (DMSs) through dealer 114 hosted Web
interfaces113.
Each of the DMSs upload, for example, through their respective Web interface
113, to
the Web portal 202 all information 108 needed about each dealer's inventory
115 to
facilitate the consumer purchase (e.g. vehicle window sticker details,
leasing/payment
options, and vehicle picture(s)). The information for each vehicle (and/or
vehicle
parts/service, etc.) in the DMS system can be selected so as to only make
available a
portion of the total vehicle information to the Web portal 202 (e.g. using set
flags or
other indicators). The framework 112 uses the DMSs to provide access by the
consumer 104, via the Web portal 202, directly to the dealer's inventory 115
of vehicles.
There is polled intercommunication between the DMSs (via the Web interfaces)
and the
Web portal 202 for any information updates 109 available on the vehicles in
the vehicle
inventories 115 (e.g. changes to existing postings, new postings, and deleted
postings,
postings with down payment in process/progress, etc.). The intercommunication
also
includes an availability check on the consumer chosen vehicle prior to
acceptance of
the credit card (or other electronic payment e.g. Pay Pal) down payment 92, in
the event
that the chosen vehicle has recently been sold (or in the process of being
sold) onsite at
the dealership (or via another on-line transaction). Further, once the down
payment 92
is accepted, the on-line purchase is entered into the respective DMS as if the
consumer
had physically come into the dealership to see a salesperson that is assigned
to the
chosen vehicle.
DMSs
[0074] It is recognized that the use of online advertisements (e.g. car ads
107)
and updating of the advertisements is based on information 108,109 obtained
from the
dealerships DMSs (i.e. Dealer Management Systems). It should be noted that an
advertisement 107 searchable by the consumers 104 in the database 110 is in
combination with this online system 10, and as such the interaction between
DMSs and
the online ad content is used to keep the online advertisements 107 current
with respect
to the details of the respective vehicle and/or vehicle part/service available
in the DMSs.
CA 02657303 2009-03-06
-26-
Computing Devices 101
[0075] Referring to Figures 1 and 3, each of the above-described components of
the system 10, i.e. the consumer 104, the framework 112, the framework 152
(including
the engines 350, 400, the dealers 114, the DMSs can be implemented on one or
more
respective computing device(s) 101. The devices 101 in general can include a
network
connection interface 300, such as a network interface card or a modem, coupled
via
connection 318 to a device infrastructure 304. The connection interface 300 is
connectable during operation of the devices 101 to the network 11 (e.g. an
intranet
and/or an extranet such as the Internet), which enables the devices 101 to
communicate with each other as appropriate. The network 11 can support the
communication of the search request 105 and the corresponding search results
106
between the components of the system 10.
[0076] Referring again to Figure 3, the devices 101 can also have a user
interface 302, coupled to the device infrastructure 304 by connection 322, to
interact
with a user (e.g. dealer 114, consumer 104, framework 112,152 administrator,
etc.).
For example, the consumer 104 to view and interact with the electronic
interface
supplied by the interface module 202 uses the user interface 302 of the device
101.
The user interface 302 can include one or more user input devices such as but
not
limited to a QWERTY keyboard, a keypad, a trackwheel, a stylus, a mouse, a
microphone and the user output device such as an LCD screen display and/or a
speaker. If the screen is touch sensitive, then the display can also be used
as the user
input device as controlled by the device infrastructure 304. For example, the
user
interface 302 for the devices 101 used by the consumers 104 can be configured
to
interact with a web browser (e.g. applications 307) to formulate the search
requests 105
as well as process the received search results 106 (e.g. review the various
details of the
products offered for sale). For the devices 101 used by the framework 112, 152
the
user interfaces 302 can be used by a framework 112,152 administrator to
monitor (e.g.
manually or automated through software - e.g. applications 307) the
classification of the
product definitions 107 and associated update information 109, as well as for
the dealer
staff to interact with the enabled features of the dealer DMS for generation
of the
CA 02657303 2009-03-06
-27-
general ledger 150 as well as changes to the clearing account tables 402 (see
Figure
9).
[0077] Referring again to Figure 3, operation of the devices 101 is
facilitated by
the device infrastructure 304. The device infrastructure 304 includes one or
more
computer processors 308 and can include an associated memory 110,115 (e.g. a
random access memory). The computer processor 308 facilitates performance of
the
device 101 configured for the intended task through operation of the network
interface
300, the user interface 302 and other application programs/hardware 307 of the
device
101 by executing task related instructions. These task related instructions
can be
provided by an operating system, and/or software applications 307 located in
the
memory 110,115, and/or by operability that is configured into the
electronic/digital
circuitry of the processor(s) 308 designed to perform the specific task(s).
Further, it is
recognized that the device infrastructure 304 can include a computer readable
storage
medium 312 coupled to the processor 308 for providing instructions to the
processor
308 and/or to load/update client applications 307. The computer readable
medium 312
can include hardware and/or software such as, by way of example only, magnetic
disks,
magnetic tape, optically readable medium such as CD/DVD ROMS, and memory
cards.
In each case, the computer readable medium 312 may take the form of a small
disk,
floppy diskette, cassette, hard disk drive, solid-state memory card, or RAM
provided in
the memory module 110, 115. It should be noted that the above listed example
computer readable mediums 312 can be used either alone or in combination. The
device memory 110,115 and/or computer readable medium 312 can be used to store
the registration information of the information sources, such that
registration information
is used in processing of the product information 108 submitted from the
information
sources to the framework 112,152.
[0078] Further, it is recognized that the computing devices 101 can include
the
executable applications 307 comprising code or machine readable instructions
for
implementing predetermined functions/operations including those of an
operating
system, a web browser, the framework 112,152 for example. The processor 308 as
used herein is a configured device and/or set of machine-readable instructions
for
performing operations as described by example above. As used herein, the
processor
308 may comprise any one or combination of, hardware, firmware, and/or
software. The
CA 02657303 2009-03-06
-28-
processor 308 acts upon information by manipulating, analyzing, modifying,
converting
or transmitting information for use by an executable procedure or an
information device,
and/or by routing the information with respect to an output device. The
processor 308
may use or comprise the capabilities of a controller or microprocessor, for
example.
[0079] Accordingly, any of the functionality of the framework 112, 152 and/or
enabled DMS may be implemented in hardware, software or a combination of both.
Accordingly, the use of a processor 308 as a device and/or as a set of machine-
readable instructions is hereafter referred to generically as a
processor/module for sake
of simplicity. Further, it is recognised that the framework 112, 152 can
include one or
more of the computing devices 101 (comprising hardware and/or software) for
implementing the above described functionality, or subset thereof, of the
components of
the system 10 as desired. Further, it is recognised that the
methods/functionality of the
modules and/devices of the system 10 cam be storable on memory as instructions
for
execution by one or more of the computer processors.
[0080] It will be understood that the computing devices 101 of the consumers
104
may be, for example, personal computers, personal digital assistants, and
mobile
phones. Server computing devices 101 can be configured for the framework
112,152
and the dealers 114 as desired. Further, it is recognised that each server
computing
device 101, although depicted as a single computer system, may be implemented
as a
network of computer processors, as desired.
Operation of the System 10
[0081] Referring to Figures 5 and 6, shown is an example operation 600 of the
system 10 (e.g. as facilitated by the framework 112) for providing access to
the user
104 of vehicle information 107 over the telecommunications networkl 1 for
facilitating
the purchase of a vehicle from a corresponding vehicle dealer 114. At step
602, a
network interface 202 receives at least one search request parameter 99 from
the user
104 over the network 11. At step 604, the information module 216 accesses
stored, in
the database 110, a plurality of vehicle information 107 obtained from the
plurality of
vehicle dealer databases 115 (e.g. associated with the DMSs), such that the
vehiGle
information 107 includes vehicle characteristics of vehicles available for
purchase by the
user 104. At step 606, the information module 216 matches at least some of the
CA 02657303 2009-03-06
-29-
parameters with the contents of the stored vehicle information 107 and at step
608
sends over the network 11 in the response message 106 response data 107
selected
from the plurality of vehicle information 107 matching the at least one search
parameter
99. At step 610, the information module 216 coordinates processing of the down
payment 92 provided by the user 104 for a selected vehicle chosen from one or
more
vehicles defined in the response data 107, such that the down payment 92
represents a
portion of the purchase price of the selected vehicle. At step 612, the
information
module 216 confirms the selected vehicle is available for purchase before
accepting the
submission of the down payment 92, wherein upon validation of the down payment
92,
the user 104 is invited at step 614 to follow-up with the vehicle dealer 114
for finalizing
the purchase of the selected vehicle. It is recognised that the plurality of
vehicle
information 107 obtained from the plurality of vehicle dealer databases 115
can also
include at least one of vehicle parts data or vehicle service data.
[0082] Other optional steps of the example operation 600 include at step 615,
the
aggregation module collects and organizes the plurality of vehicle information
107
obtained from the plurality of vehicle dealer databases 115 according to
predefined
categories, such that the categories are selected from at least one of:
vehicle
information 107 classified by at least one of make or model; and vehicle
information 107
based on dealership centric information.
[0083] A further optional step 616, the information module 216 tags the
vehicle
information 107 related to the selected vehicle as unavailable for use as
message
response data 106 for subsequent search requests 105 received from other users
104
and removes at step 618 the tagging of the vehicle information 107 in the
event that the
down payment 92 is returned to the first user 104.
[0084] A further optional sep 618, the update module 216 facilitates periodic
synchronization over the network 11 of the stored plurality of vehicle
information 107 in
the database 110 with corresponding vehicle information stored in the vehicle
dealer
databases 115.
Further Example Embodiment of the System 10
[0085] Enabling consumers to buy cars online directly from franchise dealers
with
a credit card down payment - Buy Direct. In terms of the vehicle inventory
database
CA 02657303 2009-03-06
-30-
110, the framework 112 is configured to receive a search request message 105
having
vehicle details data submitted by a user 104, formulate a search query with
search
criteria 99 corresponding to the vehicle data, and search the inventory
database 110 for
a vehicle matching the data 99. The inventory database 110 can contain
vehicles on the
order bank, in-production, in-transit, and in-inventory, for example. The
search is
facilitated using a consumer front end that includes one or more portals 202
or web
sites accessible over the World Wide Web (WWW) or the Internet over which
consumers can access the framework 112. The portals 202 may also include a Web
site dedicated to automotive sales of one or more makers, or a Web site owned
and
operated by a dealership 114 selling automobiles of one or more makers.
[0086] The framework 112 provides a complete and real-time link between the
dealer's dealer management system (DMS) and designated auto web portal (e.g.
module 202). By doing so it can facilitate true ecommerce transactions (i.e.
acceptance
of down payments 92 and facilitating selection of search results 106 based on
search
parameters 99) in real time between the dealership 114 and consumers 104, and
the
framework 112 and the consumers 104, over the Web 11. Such transactions
encompass vehicle selling by enabling the consumer 104 to research by viewing
the
dealer's vehicle inventory 115 (as represented by the information 107 in the
database
110) and then permit the consumer 104 to complete a vehicle sales transaction
in real
time.
[0087] However, the ecommerce related to the vehicle information 107 is not
limited to vehicle sales transactions. The consumer interoperability with a
dealer's
primary DMS, via the vehicle related information 107 in the database 110 (as
representing the dealer data in the database 115 associated with the DMS) can
be
extended to other aspects that occur within the dealership 114, for example
activities
such as vehicle information107 such as but not limited to; service appointment
scheduling, checking on the status of a vehicle that is in for service,
providing an
additional service recommendation authorization, checking on outstanding
campaigns
and recalls, reprinting prior service invoices, placing orders for parts,
etc., all may be
done in a similar manner to search and purchase of vehicles via the framework
112, as
information 107 that is searched for (via parameters 99) and returned in the
responses
106, along with the acceptance of down payments 92 for providing a portion of
the fees
due for the related vehicle parts/ services related to the request 106.
Different
CA 02657303 2009-03-06
-31-
interfaces can also used via the module 202 for what is wholesale parts
customers
(body shops and aftermarket parts purchasers and other different make vehicle
dealerships) to directly place orders, check parts inventory, confirm shipment
status and
pay for orders via respective corresponding vehicle information/data 107
therefore (in
the database 110) again by directly interoperating with the dealer's primary
DMS by
coming in over the Internet 11, for example.
[0088] Accordingly, the framework 112 (as well as any associated client
applications 117 to the framework 112 server application) provides a direct
link for the
potential purchaser to the dealer management system DMS and vehicle inventory
115.
The framework 112 links the dealer's vehicle inventory data stored in the DMS
with a
designated auto web portal such as the module 202 and allows the shopper to
browse
through the dealer's available vehicle inventory as represented in the
database 110. It
is recognised that the different vehicle information 107 types in the database
110 may
have different update frequencies, dependent on the desired "freshness" or up-
to-date
nature of the vehicle information type 107. For example, vehicle information
107
pertaining to vehicle advertisements may be updated daily, while vehicle
information
107 pertaining to vehicle service and/or parts availability may be updated
more
frequently (e.g. hourly).
[0089] Referring to Figure 7, a further example operation 449 of the consumer
104 interaction with the framework 112 is as follows.
[0090] Once the shopper 104 selects 450 a vehicle make/type, the following
steps can be completed online:
[0091] STEP 451 - GET STARTED: Select a make and model, then click Search
Inventory. This action will search dealership inventory stored in the database
110. For
example, if the corresponding vehicle match is not within the database 110
(e.g.
because it is not there or those vehicles that do match are not desired by the
consumer
104), then the framework 112 can submit a search query to selected dealerships
114 to
request if they have such a vehicle match (e.g. in their database 115), i.e.
try to obtain a
better quality of match by searching for relevant vehicle information outside
of the
database 110.
CA 02657303 2009-03-06
-32-
[0092] STEP 452 - CHOOSE A VEHICLE: View a list 107 of available vehicles
currently on dealers' lots. Click View Details for more information or Buy
Direct to get
this vehicle.
[0093] STEP 453 - VIEW DETAILS: See more details 107 of a specific vehicle on
a dealers' lot, including days the vehicle has been on the lot, odometer
reading and
complete window sticker information.
[0094] STEP 454 - ACCOUNT LOGIN: The user 104 Logs in to their pre-existing
account or creates a new one (i.e. an account in the framework 112). For
example, the
user 104 can store their searches here and your finance/credit application
under a
manage account tab.
[0095] STEP 455 - PURCHASE DETAILS: View and choose from a number of
purchase options, e.g. three, for example: Buy (You have financing or you have
cash),
Finance, or Lease. The user 104 can adjust monthly payment and deposit amounts
here. This can also include 1) submit offer to the dealer 114 via the
framework 112; 2)
if the offer is below gross profit acceptability parameters in the DMS, a real
time (e.g.
automatic) counteroffer can be sent back to purchaser 104 according to
predefined
rules (either of the dealer 114 and/or of the framework 112) or the purchaser
offer is
accepted based on same rules; and 3) once accepted the purchaser 104 proceeds
to a
shopping cart to enter in personal details and use a Credit Card (or other
down payment
mechanism) to submit a deposit 92 to hold the vehicle.
[0096] STEP 456 - FINANCING: If the user 104 wishes to finance or lease the
vehicle, complete the financing application here. The user 104 can save this
in their
Manage Account tab of their account in the framework 112, and come back to it
later if
they choose to complete the transaction.
[0097] STEP 457 - PAYMENT INFO: The user 104 uses a major credit card (or
other form of payment) to place the deposit 92 on the vehicle and the dealer
114 will
complete the paperwork. This deposit 92 is applied to the purchase price and
can be
100% refundable, for example, should the user 104 change their mind. The user
104
can view the completed purchase form with dealer 114 contact person. The
dealer 114
will contact the user to arrange for vehicle pickup or optional shipping
(prices do not
include shipping or tax), for example.
CA 02657303 2009-03-06
-33-
[0098] In view of the above described example operation, at Step 451, the
consumer's contact information can be written into the dealer's DMS database
115 (e.g.
the consumer's info and vehicle desired is written in to the sales lead
tracking section in
the DMS via the framework 112. When Step 457 occurs the vehicle is marked as
sold in
the dealer's database 115.
[0099] Another related process is as follows, pertaining to the down payment
92
and subsequent purchase of the vehicle, for example:
[00100] 1) Purchaser 104 requests a Payment Quote for a specified term;
[00101] 2) credit information is collected and sent to the dealer DMS system
via
the framework 112;
[00102] 3) a credit check is performed and a score is determined based on
predefined criteria;
[00103] 4) Tiered interest rate criteria by financial institution is applied
to
accurately provide a payment quote which is returned to the purchaser 104;
[00104] 5) when accepted the deposit 92 is provided (e.g. via a Credit Card);
[00105] 6) the purchaser 104 proceeds to the shopping cart; and
[00106] 7) delivery of the vehicle is set up.
[00107] It is recognized that any of the steps performed directly by the
dealers 114
can also be performed as configured by the framework 112 and vice versa, as
desired.
[00108] In view of the above described system 10, it is recognised that the
framework 112 enables web service calls (WSDLs), for example, on the selling
party's
primary business system in order to facilitate true eCommerce in real time.
The selling
party's primary business system can be either Darwin XE or either ADP or
Reynolds &
Reynolds' (e.g. DMSs), for example, as the framework 112 can connect the
consumer
104 to those systems of the dealer 115, wither directly or initially via the
database 110.
The WSDLs then deliver back to the consumer 104 the result of the call (valid
inventory
listing, acceptable purchase price, available shop time, etc.) and provide the
opportunity
to transact with the selling party (i.e. dealer 114). Such inquiries can also
be directly
logged into the primary business application 117 against the customer record
and in
various sections of the primary business application 117 for efficient follow
up whether
the consumer 104 transacts over the Internet or not. Accordingly, the
framework 112
CA 02657303 2009-03-06
-34-
provides for a web application in the dealership (e.g. a Buy Direct module
117) that is
connected via the Internet 11 to the auto portal 202 so that, in effect,
consumers are
using web portal 202 of the framework 112 as an interface to the dealer's 114
business
system (e.g. DMS) to submit the down payment 92 by credit card and so buy in
real-
time the specific, desired vehicle from the dealer's inventory 115. In this
sense, the
user 104 is relatively seamless, as all of the searching, selection, and
subsequent
purchase/payment processing (at least the initial down payment 92) is
coordinated via
the framework 112 through the portal 202.
A Further Alternative Embodiment of the System 10
Framework 112
[00109] Referring again to Figure 1 the database 110 is hosted by or otherwise
accessed through the information aggregation framework 112, which aggregates
vehicle information 108 from various DMS sources (e.g. product manufacturers,
product
retailers such as vehicle dealerships). This aggregated vehicle information
108 is then
made available as the vehicle definitions 107 to the consumers 104 via the
database
110. The aggregation of the vehicle information 108 in the electronic database
110 can
be applied to any vehicle retailer, vehicle dealerships in a competitive
marketplace for
similar products through digital aggregation of vehicle information 108,
including for-
sale/availability status in view of any transactions 92 and/or completed
contracts for the
vehicles as noted by the dealers 114 in their DMSs) as further described
below. It is
recognised that the vehicle information 108, when received by the framework
112, may
already contain a formatted vehicle definition 107 (e.g. vehicle
advertisement) as part of
the vehicle information 108. Further, the framework 112 may make available the
formatted vehicle definition 107 to the consumer 104, as received, or may
modify the
received formatted vehicle definition 107 before making it available to the
consumer
104. It is also recognised that the framework 112 can supply the vehicle
definition 107
to a third party network interface, not shown, (e.g. independent web portal),
who then
makes the product definitions 107 available to the consumers 104 via
corresponding
ones of the search requests 105 and results 106 over the network 11. Also, for
example, the framework 112 also hosts, and/or has access to (e.g. hosted by a
third
party on the network 11), a payment engine that is configured for coordinating
the
CA 02657303 2009-03-06
-35-
processing (e.g. in conjunction with financing entities associated with the
dealer 114,
e.g. banks, financing companies, etc., not shown) the financial transactions
92.
[00110] For example, the framework 112 can have a network interface 202 for
interacting with the consumers 104, any specialized frameworks 112, as well as
any
DMSs of the dealers 114, in order to facilitate the distribution and
collection of data (e.g.
vehicle information 108, vehicle information 107, payment information 92
including
payment/purchase status of selected vehicles, and any other information
included in the
messages 105,106). The framework 112 also has, for example: an aggregation
module
for collecting the information 108 from all of the dealers 114, for making
available as
information 107 to the consumers 104; an update module for
receiving/requesting
updates 109 to the information 108 already stored in the memory 110; and an
information module for receiving the requests 105, formulating the responses
106,
including identifying any related payment information 92 and formatting the
responses
106 in view of vehicle status information (e.g. tagged vehicles) obtained by
the dealer
114 (e.g. from the DMSs).
Dealers 114
[00111] As already noted, a major problem in current DMS systems is that they
do
not do proper work in progress (WIP) accounting, e.g. in progress dealer
actions/activities, which is contrary to the functioning of the framework 152
(e.g.
consolidation engine 350, accounting engine 400, etc.). Current DMS systems
also
have weak integration between their inventory applications and their general
ledger,
which means that current DMS systems have major manual reconciliations that
need to
be done every month, for example, in order to do accurate financial reporting.
[00112] The following discussed the dealerships 114 ability to interact with
the
framework 112, as well as to leverage the operation of the framework 152 to
provide for
proper account of in progress dealer actions/activities.
[00113] Referring again to Figures 1,2, the framework 112 hosts the Web portal
202, accessed by the consumer 104 via their browser, and is also connected to
the
plurality of Dealer Management Systems (DMSs) through dealer 114 hosted Web
interfaces113. Each of the DMSs upload, for example, through their respective
Web
interface 113, to the Web portal 202 all information 108 needed about each
dealer's
CA 02657303 2009-03-06
-36-
inventory 115 to facilitate the consumer purchase (e.g. vehicle window sticker
details,
leasing/payment options, and vehicle picture(s)). The information for each
vehicle
(and/or vehicle parts/service, etc.) in the DMS system can be selected so as
to only
make available a portion of the total vehicle information to the Web portal
202 (e.g.
using set flags or other indicators). The framework 112 uses the DMSs to
provide
access by the consumer 104, via the Web portal 202, directly to the dealer's
inventory
115 of vehicles. There is polled intercommunication between the DMSs (via the
Web
interfaces) and the Web portal 202 for any information updates 109 available
on the
vehicles in the vehicle inventories 115 (e.g. changes to existing postings,
new postings,
and deleted postings, postings with down payment in process/progress, etc.).
The
intercommunication also includes an availability check on the consumer chosen
vehicle
prior to acceptance of the credit card (or other electronic payment e.g. Pay
Pal) down
payment 92, in the event that the chosen vehicle has recently been sold (or in
the
process of being sold) onsite at the dealership (or via another on-line
transaction).
Further, once the down payment 92 is accepted, the on-line purchase is entered
into the
respective DMS as if the consumer had physically come into the dealership to
see a
salesperson that is assigned to the chosen vehicle.
DMSs
Framework 152 Hosting Model
[00114] Referring to Figure 1, in view of the below description of the DMS
configurations, concerning a plurality of vehicle information management
procedures for
the data 140,142 related to, for example, accounting, payroll, vehicle sales
process,
vehicle inventory control, repair shop solutions, parts department solutions,
dealer OEM
communications, and general systems, it is recognised that the DMS can be
coupled to,
either directly as a fully configured DMS, or a DMS coupled to a remote
network service
for vehicle information management (e.g. offered by the framework 152). In the
case of
remote hosting, a third party network server 101 can be located on the network
11 and
communicate via the appropriately configured interface module 117 that
facilitates
communication between the DMS and the desired" Darwin" functionality that is
hosted
by the remote network service (e.g. offered by the framework 152). It is also
recognised
that the DMS could also host the framework 152 directly as an integrated DMS
solution
or otherwise configured as a separate framework 152 coupled to an existing
DMS.
CA 02657303 2009-03-06
-37-
Therefore, different hosting models can be adopted by different dealers 114
for the
framework 152, for example. For simplicity purposes, hereafter the terms DMS
and
framework 152 can be used interchangeably, where it is recognised that the DMS
functionality is integrated with the framework 152 functionality and/or the
DMS is
coupled for communication with an "add-on" modification to an existing DMS.
Framework 152 Functionality Overview
[00115] The DMSs include the functionality of the information management
framework 152 (see Figure 9) for dynamically monitoring of parts, service,
vehicle
inventory data (also referred to as vehicle data) and their associated
financial data in
the database 115 coupled to the DMSs. It is recognised that the vehicle data
140 of the
different data types (i.e. parts, service, vehicle inventory) and their
corresponding
financial data 142 are interrelated in the DMSs through a general accounts
ledger 150
(see Figure 2), which also includes accounts payable 154 and accounts
receivable 156
sub ledgers 151. The framework 152 is adapted to monitor the status of any
particular
vehicle, vehicle component, and/or vehicle service tracked in the database
115.
Further, the framework 152 is also adapted monitor the vehicle data 140 for
any
particular vehicle/ vehicle component/ vehicle service, as related to the
financial data
142 resident in the general ledger 150 (including the sub ledgers 151).
[00116] Further, it is recognised that framework 152 can be extended to
monitor
other aspects that occur within the dealership 114, for example activities
related to
vehicle data 140 and associated financial data 142 such as but not limited to;
service
appointment scheduling, status of a vehicle that is in for service, additional
service
recommendation authorization, outstanding campaigns and recalls, reprinting
prior
service invoices, placing orders for parts/vehicles/service, wholesale parts
customers
(body shops and aftermarket parts purchasers and other different make vehicle
dealerships), check inventory, shipment status, and pay for orders.
[00117] The Dealership Management System (DMS) (i.e. inclusive of the
management framework 152) can be referred to is as a bundled system created
specifically for car/vehicle dealerships 114, but also adaptable for Boat, RV,
and Power
sports dealers 114. The DMS system contains software (e.g. as a set of
instructions
executable by a computer processor) that cater to the needs of the finance,
sales, parts,
CA 02657303 2009-03-06
-38-
inventory and administration components of running the dealership 114. The DMS
typically includes support for all aspects of running a dealership 114, such
as but not
limited to: tracking vehicle inventory; tracking sales; finance and insurance
calculations;
menu selling systems; tracking customers (and customer follow up); accounting;
managing dealer 114 website; calculating employee commissions; purchase order
tracking; parts inventory; work order management; and appointment scheduling.
Further, is it recognised that the DMS can do proper work in progress (WIP)
accounting.
using integration between the inventory applications and the general ledger
150, further
described below.
General Ledger 150 Example
[00118] The general ledger 150, sometimes known as a nominal ledger, can be
defined as the main accounting record of a business (e.g. dealership 114 or
group of
dealerships 114) which uses double-entry bookkeeping, because each bookkeeping
entry debits one account and credits another account in an equal amounts, to
provide
for that the general ledger 150 is always in balance for all completed as well
as in-
progress actions/activities of the dealership(s) 114.
[00119] . The general ledger 150 can include accounts for such items as
current
assets, fixed assets, liabilities, revenue and expense items, gains and
losses, in the
context of vehicles (e.g. new, used, in-stock, on-order, trade-ins, etc.),
vehicle parts,
and vehicle service of the dealership, for example. In particular, the general
ledger 150
is generated so as to include in-progress dealership activities/actions, i.e.
those
activities/actions that contribute to the financial status of the dealership
but have yet to
be recognised by the dealership 114 as being invoiced. These
activities/actions can
include activities/actions such as but not limited to: work in progress for
parts; work in
progress for service; unprocessed accounts payable; unprocessed accounts
receivable;
unprocessed vendor invoices; physical inventory adjustments; and price changes
of
inventory.
[00120] For example, these in-progress dealer activities/actions as defined in
tables 402 (see Figure 9) can be used to represent in the ledger 150: WIP
maintained
for parts (i.e. in cases where dealer jobs/tasks cannot be invoiced with
outstanding
unbilled parts invoices, as well as for any other parts related transactions
occurring
CA 02657303 2009-03-06
-39-
within the dealership 114): WIP maintained for labour (i.e. in cases where
dealer
jobs/tasks cannot be invoiced unless labour is posted); WIP maintained for
sublets (i.e.
in cases where dealer jobs/tasks cannot be invoiced unless the corresponding
vendor
invoice is posted against outstanding sublets); and an option to enforce all
purchase
orders (i.e. in cases where invoices cannot be posted without an open purchase
order -
PO).
[00121] Further, the general ledger 150 is considered as a collection of the
group
of accounts that supports the items shown in the major financial statements.
The
general ledger 150 is built up by posting transactions, for example, recorded
in a sales
daybook, a purchases daybook, a cash book, a general journals daybook, as well
as
records for in progress items, via a plurality of clearing account tables 402
(see Figure
9). The general ledger 150 can be supported by one or more subsidiary ledgers
151
that provide details for accounts in the general ledger 150. For instance, an
accounts
receivable subsidiary ledger 151 would contain a separate account for each
credit
customer, tracking that customer's balance separately. This subsidiary ledger
151 would
then be totalled and compared with its controlling account (in this case,
Accounts
Receivable) to provide for accuracy as part of the process of preparing a
trial balance.
[00122] In a general ledger 150, there can be a number of categories in which
all
accounts are grouped, categories such as nut not limited to: Assets;
Liability; Owner's
equity; Revenue; Expense; Gains; and Losses. The balance sheet and the income
statement of the dealership 114 are both derived from the general ledger 150,
for
example. Each account in the general ledger 150 consists of one or more pages,
where
posting to the accounts occurs as a process of recording amounts as credits,
(right
side), and amounts as debits, (left side), in the pages of the general ledger
150. The
listing of the account names can be referred to as a chart of accounts. The
extraction of
account balances can be referred to as a trial balance. The purpose of the
trial balance
is, at a preliminary stage of the financial statement preparation process, to
provide for
the equality of the total debits and credits. For example, the general ledger
150
includes the date, description and balance or total amount for each account.
Consolidated Accounting via a General Ledger Engine 350
CA 02657303 2009-03-06
-40-
[00123] Consolidated financial statements can be defined as financial
statements
that factor the holding company's subsidiaries (e.g. individual dealerships
114) into its
aggregated accounting figure, as provided for in a consolidated accounting of
the
general ledger information 150, which can be a representation of how the
holding
company (e.g. owner of the various dealerships 114) is doing financially as a
group. The
consolidated accounts shown in the general ledger 150 can provide a true and
fair view
of the financial and operating conditions of the group. The ledger engine 350
facilitates
a complex set of eliminating and consolidating entries to work from individual
financial
statements of the dealerships 114 (e.g. formatted dealer data 140, 142) to a
group
financial statement (e.g. general ledger 150) that is an appropriate
representation of
operations of the group. For example, the financial accounting term of
consolidation
can refer to the aggregated financial statements of the group company as a
consolidated account.
[00124] Referring to Figure 8, the framework 152 includes a general ledger
engine
350 that is configured for providing consolidated accounting, whereby the
framework
152 enabled DMS provides a multi franchise and/or multi-location dealer 114
with the
ability to submit required OEM financial statements that adhere to
manufacturer
standards while enabling the dealer 114 to have consolidated reporting. The
configured
general ledger engine 350 can include generation of a Consolidated Financial
Statement related information 150(see Figure 2) that enables the dealer 114 to
view all
selected Franchisee/Companies as a single company, for example, as well as
providing
Consolidated accounting view(s) of all activities combined and broken out by
department with extensive break down detail of vehicle data 140 and financial
data 142.
The ledger information 150 shown in Figure 2 is selected by a dealer/company
selector
155, which can show the data 140,142 for a particular dealership (e.g. Green
Auto
Chrysler Jeep) and or combination of dealerships 114, as further described
below.
Ledaer Information 150
[00125] Referring to Figure 2, the display of the ledger information 150 on
the user
interface 302 of the computer device 101 (see Figure 3) can be configured so
as to
present to the device user with dealership summary information tailored to
his/her
profile 157. So, the Dealer Principal (and/or company principal owning more
than one
dealership) can see all applications and data 140,142 pertaining to the
CA 02657303 2009-03-06
-41-
individual/collection of dealership(s), while the Parts Manager only sees
applications
and data that needs to be seen to perform his/her job (e.g. considered as a
subset of
the total ledger information 150 available to the user based on available role
selections
157). An upper left-hand quadrant 159 of the view on the user interface 302
can contain
a standard tree-view of the departmental screens, while a lower left-hand
quadrant 161
can present icons for all personnel reporting to the user; for drilling down
into these
Example Confipuration of the Engine 350
[00126] Referring to Figure 8, shown is the consolidation engine 350 having an
extraction module 354 for extracting various selected data 140,142 content
from the
various databases 115 associated with the different dealers 114, based on the
selection
by the user of the users role 157, the selection 155 for dealership or
collection of
dealerships, for example, as well as any other selections 161 provided by the
user for
use in generating the ledger information 150. The extraction module 354
forwards the
extracted data 140,142 to the consolidation module 156 for consolidating the
data
140,142 based on a consolidation account number and associated formatting
information 353 (stored in a memory 355) for use in consolidating the dealer
data
140,142 (e.g. for service repairs, inventory, parts, sales) into the common
statement
information 150.
[00127] For example, the formatting information 353 can provide instructions
to the
consolidation module 156 for use in mapping incompatible formats and
associated
information for different car companies-based chart information (e.g.
formatted data
140,142) to the common consolidated chart information 150. The consolidated
chart
information 150 can provide for multiple factory layouts without losing their
inherent
functionality (i.e. a rationalized combined layout), for example. Accordingly,
the
formatting information 353 can be used to balance/validate the combined
content of the
ledger information 105 for output to the predefined customized format, without
losing the
inherent functionality included in the individual charts associated with the
extracted data
140,142. This formatting of the information 150 provides for the dealer (or
dealership(s)
owner) to compare his/her stores or groups of stores. The report information
150 can
be generated for stores/dealerships 114 by geographical area, franchise, or
group (or
any other desired classification of the dealerships 114) so that the user can
focus in on
each and see a real-time view of how the entire enterprise, as selected, is
doing. It is
recognised that one example of the information 150 is as mentioned above, i.e.
a
CA 02657303 2009-03-06
-42-
general ledger 150, however it is recognised that other forms/uses of the
information
150 can be envisioned to a person skilled in the art.
[00128] Further, the engine 350 can also have a report module 358 for
generating
a display of the information 150 (or a formatted document for storing in
memory 355 and
later viewing, e.g. PDF) on the user interface 302 available to the user of
the engine
350. Further, in any browser coupled to the engine 350, the user can select
from one a
many standard formats (e.g., Acrobat Reader PDF, Excel, XML, HTML, .txt) to
output,
save, manipulate and print the information 150 seen in the browser 302. In
addition, a
Report Field Selector can provide for the user to design, create, save, reuse
and control
access to report information 150 that may include any of the data fields in
tables
associated with the browser 302 being viewed. Further, any printed document as
Acrobat PDF files for storing on the server/DMS (rather than just reproducing
the
document from the data stored against a transaction). Signatures may be
scanned onto
documents, which are stored view-only, complying with pertinent legislation.
Additionally, external documents may be scanned into the memory 355 and stored
against records for later retrieval (e.g., Specification sheets, deal
contracts, etc).
Accounting Engine 400
[00129] Referring to Figure 9, shown in overview is an accounting engine 400
of
the management framework 152. The accounting engine 400 can work in
conjunction
with the consolidation engine 350, such that the accounting engine 400 can
manage the
individual accounting related data 140, 142 for each dealership 114, which
then can be
subsequently consolidated via the appropriate consolidation account number and
associated formatting information 353 implemented by the consolidation engine
350.
By example only, the data 140, 142 can be organized and maintained at the
dealership
114 level to provide for general ledger 150 and associated sub ledgers 151
information
as further described below, such that the data 140,142 in the general ledger
150 (and
associated sub ledgers 151) is accounts 402 appropriately for any "in-
progress"
activities in the dealership 114, i.e. those activities that have an intrinsic
worth but have
not yet had invoices associated with their worth reconciled against the
financials of the
dealership.
CA 02657303 2009-03-06
-43-
[00130] For example, the value to the dealership for appropriate recording and
maintaining of all in progress dealer actions/activities (as performed by the
accounting
engine 400 in conjunction with the generated/maintained tables 402) is where
all dealer
managers have readily available DOC (Daily Operating Control). This is where
the
managers (or other personnel associated with the dealership 114) can react to
business
events readily because the whole dealership 114 is "wired" together via the
framework
152 enabled DMS. For example a transaction (e.g. actions 404,406) posted to
the parts
dept. will be seen readily by the Office Manager and the Sales Manager if it
is applied to
a vehicle also associated with their personal workflows. This is provided, for
example,
by all of the dealer staff having their own modules 117 coupled to the
framework 152
over the network 11, and/or by each of the dealer staff having modules 117
that are
coupled to the dealer configured DMS (i.e. incorporating the functionality of
the
framework 152).
[00131] The following discussion of the accounting engine 400 is in relation
to a
single dealership 114, for example. It is recognised that the accounting
engine 400
uses a plurality of clearing account tables 402 for maintaining an accurate
record in the
general ledger 150 of all in progress actions/activities of the dealership
114. These
control account tables can be defined for all inventory accounts (e.g. parts,
vehicles,
and service work in progress WIP, for example), all Receivable accounts, and
all
Payable account (including sales tax). Entries can only hit the in the
clearing account
tables 402 when they are made in the corresponding sub-ledger (e.g. buy a
part, sell a
part, count a part or buy a vehicle, sell a vehicle, do recon on a vehicle,
etc.). The use of
the clearing account tables 402 in maintaining the general ledger 150 provides
for the
management framework 152 to represent an accurate balance of the parts
inventory (or
any other inventory or control account table 402). For example, if someone was
stealing parts from the dealership 114, the inventory represented in the
ledger 150 (via
the tables 402) would not to match the physical count and this would allow the
framework 152 to alert management that remedial action and adjustment was
required.
[00132] Accordingly, the accounting engine 400 creates and maintains the
control
account tables 402, in view of in progress actions/activities data 404 input
by employees
of the dealership 114 into the DMS, for example. As further described below,
the
control account tables 402 are used by the accounting engine 400 for
subsequent
generation of the general ledger 150, as requested 406 by a user of the DMS,
as further
CA 02657303 2009-03-06
-44-
described below. Further, the accounting engine 400 makes use of the several
"clearing" account tables 402 in synchronizing the general ledger 150 of the
dealership
114. It is also recognized that some of the below functionality of the
accounting engine
400 could be either performed or otherwise shared with the framework 112
capabilities.
These functionalities of the modules 410,412,414,416 are given below by
example only.
It is recognized in the below discussion that reference to inventory can
relate to the
dealership inventory 115 (e.g. available vehicles for sale/lease, service,
parts, etc.). It is
recognized that the below described functionality could use appropriate update
procedures as provided by example in the section entitled "Example
Configuration of
the Framework 152", provided further below. Further, all of the below given
example
mechanisms could also be interpreted as a means for doing their function, such
that
their function could be provided in software, hardware, or a combination
thereof as
modules of the computer system 101 (see Figure 3).
[00133] Referring to Figure 10, shown is an example embodiment of the
accounting engine 400. The engine 400 can have a number of modules for
creating
and maintaining the control account tables 402, including such as but not
limited to: a
parts module 410 for use in creating parts related control account tables 411
(i.e. for in
progress parts inventory related actions/activities) for use in synchronizing
parts
inventories with the contents of the general ledger 150 when dynamically
requested 406
and generated; a service module 412 for use in creating service related
control account
tables 413 (i.e. for in progress service inventory related actions/activities)
for use in
synchronizing service work inventories with the contents of the general ledger
150 when
dynamically requested 406 and generated; a vehicles module 414 for use in
creating
vehicle related control account tables 415 (i.e. for in progress vehicle
inventory related
actions/activities) for use in synchronizing vehicle inventories with the
contents of the
general ledger 150 when dynamically requested 406 and generated; and an
accounts
module 416 for use in creating accounts related control account tables 417
(i.e. for in
progress accounts payable/receivable related actions/activities) for use in
synchronizing
accounts data with the contents of the general ledger 150 when dynamically
requested
406 and generated. These modules 410, 412,414,416 are further discussed below.
[00134] Further, the accounting engine 400 can have a receipt module 418 (also
referred to as a workflow module) adapted for receiving financial data
associated with a
dealership activity having an in-progress status and for subsequently
receiving update
CA 02657303 2009-03-06
-45-
information representing a cancellation of the in-progress status of the
dealership
activity. The modules 410,412,414,416 can be referred to as processing
modules, as
desired. The receipt module 418 can also be referred to as a workflow module
for
selecting the processing module 410,412,414,416 from a plurality of processing
modules, in order to provide update to the appropriate account table
411,413,415,417,
the selection based on an account parameter (e.g. parts; service; vehicle;
and/or
accounting related) associated with the financial data 404. Further, the
engine 400 can
have a general ledger module 420 adapted for receiving the ledger generation
request
406 and for updating the financial information of the general ledger 150 using
the
contents of the updated account data structure(s) 411,413,415,417.
[00135] Further, it is recognised that the account table 411,413,415,417 can
be
defined more generally as account data structures 411,413,415,417 (e.g. data
structures other than tables, e.g. arrays), which used as a temporary data
storage
structure, such that the contents of the account data structures
411,413,415,417 are
used for updating the financial information of the general ledger 150
pertaining to a trio
of accounts in the general ledger 150, such that pairs of the trio of accounts
are related
to one another through double entry book keeping.
Parts Module 410
[00136] The parts module 410 updates the parts table 411 in response to the
occurrence of dealer actions/activities for parts related transactions. One
example of
the dealer actions/activities for parts related transactions is for
outstanding costs (e.g.,
parts associated with a Repair Order) associated with a vehicle that might
have
otherwise been missed when the vehicle was sold (i.e. for a used car
reconditioned
prior to the sale by the dealership 114). This could be a loss to the dealer,
since the
grosses would be inaccurate on which the negotiated selling price of the
vehicle and
commissions could be figured.
[00137] The parts module 410 can also offer a sophisticated recommended order
that provides for the required parts to be available in the sufficient
quantities when
needed, aiming to maximize service levels while minimizing inventory levels.
As
discussed above, the output table 411 provides for the maintenance of parts
inventories
(i.e. from both financial - represented by parts financial data 142 - and a
non-financial -
represented by parts count vehicle data 140 - information) in synch with the
general
CA 02657303 2009-03-06
-46-
ledger 150, thereby inhibiting any need for time consuming and costly manual
reconciliation by staff parts WIP of the dealership(s) 114.
[00138] For example, full WIP accounting is maintained between the Service
application (e.g. module 412) and the General Ledger 150, as well as the Parts
application (e.g. module 410) and Service (e.g. module 412). Also, as further
described
below, for work in process-labor/service, when labor is booked to a RO either
manually
or via the clocking module (e.g. input 404), the WIP labor account table 413
is debited
with the cost value and the technician payable account 413 is credited with
the same
amount. When the RO in invoiced to the customer, the WIP account 413 is
credited
and the COS account 413 is debited with the same amount. In this manner, the
contents of the general ledger 150 are kept in balance for in progress WIP.
[00139] For Work in Process-Parts, when a parts or service cash sale is
invoiced,
the parts or service cash clearing account 411 is debited with the total sales
value.
When the cashier produces a receipt'for the customer, the cash clearing
account 411 is
credited and a "Cash On Hand" or "Undeposited Cash" account is debited. When
the
Bank Deposit is processed, the Cash On Hand account 417 is credited and the
bank
account 417 is debited. What this allows is to easily identify unreceipted
cash sales as
well as undeposited cash. It also means that the cash deposit amount in the
bank
account 417 is the actual deposit amount, and not numerous individual receipts
which
makes bank reconciliation easier.
[00140] For Accounts Payable Purchases Clearing, the account 402 is used for
Parts Inventory purchases and returns. When a parts order is released into
inventory,
the Inventory account 402 is debited with the Qty * Replacement Cost and the
Purchase
Clearing account 402 is credited with the same amount. When the Vendor Invoice
is
processed, the Purchase clearing account 402 is debited with the original
amount, and
the AP account 402 is credited with the invoice amount. Any additional chares
such as
Freight are posted to the respective accounts 402 at the same time.
[00141] During the Monthly Parts Pricing Update process, parts cost values are
changed via the module 410. This causes an appreciation/depreciation
condition.
Since your Parts on hand (Oty x Cost) balances with the Parts GL + WIP parts,
how and
when is the difference accounted for is when the Price Tape is run any price
change (up
or down) will revalue the parts inventory if the is inventory on hand. The
parts Inventory
CA 02657303 2009-03-06
-47-
account 411 will be debited in the case of a price increase and the Parts
Write-up
Reserve account 411 will be credited with the same amount. At year end, the
dealer can
decide what to do about any credit balance (unrealized profit) in this
account. It can
either be taken as profit or used to adjust cost of sales / parts inventory
adjustments etc.
[00142] During the parts return process, parts are removed from inventory
several
days before a credit is received. How is perpetual inventory and accounting
inventory
balanced in this case? This is handled exactly as an order is handled. When
the Parts
Return is released, the module 410 will Credit Parts Inventory with the total
value and
debit the Purchases Clearing account 402t. When the credit note is received,
the
system will credit the Purchase Clearing and debit the AP control account 402.
The
above steps facilitate that the physical parts inventory at all times agrees
with the
general ledger 150 inventory balance, helping to eliminate the need for manual
reconciliations to be done, which is a big time-saver for the dealer 114.
Current DMS Deficiencies in Parts WIP Accounting
[00143] A major problem in typical dealer management systems is that they do
not
do proper work in progress (WIP) accounting. Typical dealer management systems
also do not have appropriate integration between the inventory applications
and their
general ledger, which means that typical dealer management systems have major
manual reconciliations that need to be done every month in order to do
accurate
financial reporting.
[00144] Typical dealer management systems do not relieve their physical parts
inventory at the time that the parts are issued (in response to repair orders)
and handed
over to the technicians. There is also no record of the transaction placed in
the general
ledger, as there is not financial transaction that has yet occurred with
entities outside of
the dealership in relation to the parts used in repair of the vehicle. What
this means is
that parts have been physically removed from the bin in the parts department
and
handed over to a technician, without any accounting of the unavailability of
the part in
their general ledger. The reason why the other typical dealer management
systems do
this is because it is considered not correct to reflect the sale of the part
until the repair
order is invoiced, because there is every possibility that the part could be
returned to the
parts department for any number of reasons. So the sale in typical dealer
management
CA 02657303 2009-03-06
-48-
systems is only raised once the repair order is invoiced, as it is then the
responsibility of
the customer to pay for the part.
[00145] However, when there is no account for that part until the repair order
has
been invoiced, the impact on this uncertainty in financial and part count
details can be
disruptive since invoicing could take anywhere from a few hours after the part
was taken
to many weeks after the part was taken. If one multiplies this uncertainty by
hundreds of
repair orders being worked on at any time at a dealership, the magnitude of
the
uncertainty problem is realized. The affect is further amplified in the case
of service
uncertainty associated with the parts used in the car repairs.
[00146] Typically, there are hundreds of parts where the on-hand quantity
shown
by the typical dealer management systems does not agree with what is in the
bin
because of this. The parts manager therefore never really knows if he has a
problem in
the parts inventory or not. Also, the financial statement value shown for
parts inventory
is never 100% correct because of the uncertainty caused by waiting for
parts/service
invoicing to be recognised before an accounting is recorded in their general
ledger.
This undesirable practice can also impact on the accuracy of parts recommended
orders, because the on hand value reflected by the typical dealer management
systems
is incorrect. Many person hours can be spent every month by the average
dealership
reconciling the physical inventory to their general ledger. Typically spread
sheets are
used to do this and the end result is never really 100% accurate.
How the Framework 152 handles parts WIP
[00147] Referring again to Figure 10, the parts module 410 is configured to
update
the parts table 411 using representative update vales 431 (e.g. the inventory
record for
that part is relieved in the parts table 411), in response to a reported part
related action
404, when the part or parts is issued to a repair order, . Entries are also
generated in
the general ledger 150 to account for the movement of the parts inventory, as
generated
in response to corresponding in progress reporting information 431 stored in
the parts
table 411. This is done to provide that that the part inventory records in the
system
agree with the parts inventory value reflected in the general ledger 105.
[00148] For example, assume a part where the cost price is $10 part value
(e.g.
associated financial data 142 of the part). The parts inventory account table
411 will
CA 02657303 2009-03-06
-49-
reflect the $10 as part of the balance. When the part is issued to the repair
order, the
parts module 410 will generate the following entries as information 431 for
the table
411, for example:
1. Credit Parts Inventory with $10 (i.e. part associated financial data 142);
2. Debit Parts Work In Progress with $10 (i.e. part associated financial data
142); and
3. Reduce the Physical Inventory quantity on the parts inventory record by 1
(i.e.
part associated vehicle data 142).
[00149] Once this has happened, should a parts inventory report be printed,
the
total value shown on the report would agree with the value reflected in the
parts
inventory account in the general ledger 150, as generated using the associated
in
progress parts information 431 in the table 411. Further, the on hand quantity
shown for
the stock record by the DMS will agree with the physical quantity in the bin.
For
example, a WIP report can be generated based on the parts information 431,
which
reflects all parts in status WIP (e.g. in progress). The total of this report
will agree with
the Parts Work In Progress account represented in the general ledger 150.
[00150] Further, when the repair order is invoiced, the parts module 410 will
create
the following entries 431 in the table 411 (in addition to all the other
desired entries), in
effect clearing the in progress status associated with the part(s) in the
table 411,
namely:
1. Credit Parts Work In Progress with $10;
2. Debit Parts Cost Of Sales with $10; and
3. All the other related GL entries for the repair order.
[00151] By performing the above functions within the framework 152, it can
inhibit
any manual reconciliation to be done every month to adjust the inventory value
in the
general ledger to reflect the actual parts inventory, as use of the table 411
representing
in progress (e.g. WIP) for the parts captured in the general ledger 150, by
using the
temporary data entries 431 (e.g. first debit and then credit, or credit and
then debit) in
the table 411 to keep track of the representative financial 142 and vehicle
140 data
values for use by the general ledger 150.
CA 02657303 2009-03-06
-50-
How the Framework 152 handles Parts Inventory Ordering
[00152] Another area in the typical dealer management system that causes
manual reconciliations is the lack of integration in the parts ordering
process. When
parts for an order are released into inventory the physical inventory is
updated, but the
general ledger is only updated when the vendor invoice is processed by the
accounting
office. This could take anything from a day to several weeks. Multiply this by
100 orders
per month and the magnitude of the problem is realized. There is probably
never a point
in time in the current DMS systems when the physical inventory reflected in
the DMS
agrees with the balance in the general ledger, for current typical dealer
management
systems.
[00153] Referring again to Figure 10, on the contrary, the parts module 410
makes
use of the clearing accounts tables 411 to attend to the above-identified
problem. For
example, a parts order module (e.g. a sub module of the parts module 410) uses
a
Parts Purchases Clearing account table (e.g. a sub table of the parts accounts
tables
411). Referring again to Figure 10, the parts module 410 is configured to
integrate the
parts ordering process of the DMS. Accordingly, when parts for an order are
released
into inventory, the parts module 410 is configured to update the parts table
411 using
representative update vales 431 such that the physical part inventory is
identified as
updated.
[00154] As an example, assume the part where the cost price is $10 (i.e. part
associated financial data 142). When the parts order (e.g. reporting data 404)
for this
part is released into inventory of the DMS, the parts module 410 will update
the physical
inventory on hand quantity (i.e. part associated vehicle data 142) as well as
generate
the necessary general ledger 150 associated entries as follows, i.e. will
create the
following entries431 in the table 411 (in addition to all the other desired
entries), in effect
clearing the in progress status associated with the part(s) in the table 411,
namely:
1. Debit Parts Inventory with $10 (i.e. part associated financial data 142);
2. Create Parts Purchase Clearing with $10 (i.e. part associated financial
data
142); and
3. Increase the Physical Inventory quantity on the parts inventory record by 1
(i.e. part associated vehicle data 142).
CA 02657303 2009-03-06
-51-
[00155] Once this has happened, should a parts inventory report be printed,
the
total value shown on the report would agree with the value reflected in the
parts
inventory account in the general ledger 150, as generated using the associated
in
progress parts information 431 in the table 411. Further, the on hand quantity
shown for
the stock record by the DMS will agree with the physical quantity in the bin.
For
example, a WIP report can be generated based on the parts information 431,
which
reflects all parts in status WIP (e.g. in progress). The total of this report
can also agree
with the Parts Work In Progress account represented in the general ledger 150.
There
is also a report which reflects all parts ordered that have been released into
inventory
where the vendor invoice has not yet been processed. The total of this report
can agree
with the Parts Purchase Clearing account represented in the general ledger
150.
[00156] Further, when the vendor order for the part is invoiced, the parts
module
410 will create/amend the following entries 431 in the table 411 (in addition
to all the
other desired entries), in effect clearing the "in progress status" associated
with the
part(s) in the table 411, namely:
1. Debit Parts Purchase Clearing with $10; and
2. Create Accounts Payable Control with $10
[00157] By performing the above functions within the framework 152, it can
inhibit
any manual reconciliation to be done every month to adjust the inventory value
in the
general ledger to reflect the actual parts inventory, as use of the table 411
representing
in progress (e.g. WIP) for the parts captured in the general ledger 150, by
using the
temporary data entries 431 (e.g. first debit and then credit, or credit and
then debit) in
the table 411 to keep track of the representative financial 142 and vehicle
140 data
values for use by the general ledger 150. By utilizing the above process in
the
framework 152, the users may need not manually reconcile the unprocessed, or
not yet
received vendor invoices in order to arrive at a true inventory value for
representation
dynamically in the general ledger prior to receipt/processing of the
invoice(s) associated
with when parts for an order are released into inventory .
How the Framework 152 handles Parts Inventory Adiustments
CA 02657303 2009-03-06
-52-
[00158] Typical dealer management systems allow for the changing of parts
quantities reflected on the inventory records without updating their general
ledger. This
is contrary to the ports module 410, which updates the account tables 411 used
to
generate the general ledger 150, when requested 406, with any change(s) made
to an
inventory quantity in the DMS database 115.
[00159] It is recognised that there are legitimate reasons for making changes
to
inventory quantities, a few are, by example:
1. a "left hand" part is sold using a "right hand" part number (although the
correct procedure would be to pass a credit note for the incorrect part and
invoice
the correct part);
2. the OEM send the wrong part using the part number of the part originally
ordered;
3. when a physical stock count shows a discrepancy; or
4. perpetual or Annual inventory counts.
[00160] Referring to Figure 10, assume a part costing $10 and an adjustment is
made for +1 part. When a physical inventory adjustment is made (e.g. in
progress input
404) the parts module 410 will generate the following entries 431 in the parts
table 411:
1. Debit Parts Inventory with $10 (i.e. part associated financial data 142);
and
2. Credit Parts Inventory Adjustment with $10 (i.e. part associated financial
data 142).
[00161] Once this has happened, should a parts inventory report be printed,
the
total value shown on the report would agree with the value reflected in the
parts
inventory account in the general ledger 150, using the temporary entries 431
in the
parts table 411. As discussed above, once the in progress parts
action/activity is
rectified in the accounts system of the DMS, e.g. the sale or otherwise
processing of an
invoice related to the part, the above noted entries 431 in the parts table
411 are
amended to, in effect clearing the "in progress status" associated with the
part(s) in the
table 411.
How the Framework 152 handles OEM Parts Price Tages
[00162] Every month, the OEMs send out new price tapes (e.g. in progress data
404) which reflect the latest dealer pricing for the parts inventory. Dealers
114 value
CA 02657303 2009-03-06
-53-
their inventory as replacement cost. Therefore, if the price of a part that
the dealer has
in inventory changes, this needs to generate entries in the general ledger
150, based on
the parts inventory account table 411, in order for the physical inventory to
remain in
balance with the general ledger 150.
[00163] For example, assume a part where the dealer has two in inventory
costing
$10 and the replacement cost of the part changes to $12, a $2 increase (e.g.
representing a change in the financial data 142 associated with the part).
When a Price
Update routine is run in the accounting engine 400, the parts module 410 makes
the
following entries 431 in the table 411, for example:
1. Debit Parts Inventory with $4 (2 x $2) (i.e. part associated financial data
142); and
2. Credit Parts Inventory Adjustment with $4.00 (i.e. part associated
financial
data 142).
[00164] Once this has happened, should a parts inventory report be printed,
the
total value shown on the report would agree with the value reflected in the
parts
inventory account associated with in the general ledger 150. As discussed
above, once
the in progress parts action/activity is rectified in the accounts system of
the DMS, e.g.
the sale or otherwise processing of an invoice related to the price adjusted
part, the
above noted entries 431 in the parts table 411 are amended to, in effect
clearing the "in
progress status" associated with the price adjusted part(s) in the table 411.
Summarv
[00165] The procedures described above for operation of the parts module 410
of
the accounting engine 400 facilitates the removal of dealer staff to do
lengthy manual
reconciliations of WIP parts, unprocessed vendor invoices, physical inventory
adjustments and price changes to arrive at a physical inventory value which
resembles
the value of inventory reflected in the general ledger 150. It also
facilitates the inhibition
of the need to make large inventory write offs at financial year end, which is
normal with
the other typical dealer management systems in use.
Service Module 412
CA 02657303 2009-03-06
-54-
[00166] The service module 412 updates the service table 413 in response using
entries 433 to the occurrence of dealer actions/activities (e.g. input 404)
for service
related transactions. One example of the dealer actions/activities for service
related
transactions is for outstanding costs (e.g., service associated with a Repair
Order)
associated with a vehicle that might have otherwise been missed when the
vehicle was
sold (i.e. for a used car reconditioned prior to the sale by the dealership
114). This could
be a loss to the dealer, since the grosses would be inaccurate on which the
negotiated
selling price of the vehicle and commissions could be figured.
[00167] The service module 412 can also include optional functionality such
as:
technician clocking (an electronic punch-clock) and electronic dispatching.
The service
module 412 can have a complete purchase order system for sublets and WIP (work
in
process), as account tables 413 maintained for accurate tracking of service
activity (i.e.
from both financial - represented by service financial data 142 - and a non-
financial -
represented by service staffing count vehicle data 140 - information) in synch
with the
general ledger 150, thereby inhibiting any need for time consuming and costly
manual
reconciliation of service WIP by staff of the dealership(s) 114 .
Vehicle Module 414
[00168] The vehicle module 414 updates the vehicle table 415 in response to
the
occurrence of dealer actions/activities for vehicle related transactions. One
example of
the dealer actions/activities for vehicle related transactions is for
outstanding costs (e.g.,
value of a trade-in) associated with a vehicle that might have otherwise been
missed
when the vehicle was sold (i.e. for a trade-in car evaluated and attributed a
trade-in
value prior to the sale of a new car by the dealership 114). This could be a
loss to the
dealer, since the grosses would be inaccurate on which the negotiated selling
price of
the new vehicle and commissions could be figured.
[00169] The vehicle module 414 can also include use by the office and sales
team
to manage the vehicle inventory (including loading vehicle photos for upload
to web
sites managed by the framework 112 - see Figure 1) and create/finalize vehicle
deals/transactions. This module 414 can contain a Desking screen with the
Activity Log
(e.g. has the ability to show a customer 4 optional side-by-side deals, for
example),
Finance and Lease Worksheets, and Summary screen for an F&I Manager of the
CA 02657303 2009-03-06
-55-
dealership. The latter screen can have an Alerts section that indicates if
there are any
outstanding costs associated with the vehicle (e.g. Vehicle and Trade-In
alerts that are
recorded for both vehicle data 140 and financial data 142 considerations in
the table
415) that can reduce the profit reflected in the deal (for accurate
commissioning).
[00170] The vehicle module 414 can have a complete purchase order system for
sublets and WIP (work in process), as account tables 414 maintained for
accurate
tracking of vehicle activity (i.e. from both financial - represented by
service financial
data 142 - and a non-financial - represented by service staffing count vehicle
data 140
- information) in synch with the general ledger 150, thereby inhibiting any
need for time
consuming and costly manual reconciliation of vehicle WIP by staff of the
dealership(s)
114.
Control Account tables 415 in the Vehicle Inventory System
[00171] The vehicle module 414 uses control account tables 415 in the Vehicle
Inventory system of the DMS to manage key areas of cost control that other
typical
dealer management systems do not do. This use of the control account tables
415 can
results in cost savings as these are typically areas that are manually
reconciled and
more often than not, the issues are only discovered after the vehicle has been
sold and
it is then too late to recover these costs.
Reconditioning on New and Used Vehicles
[00172] This is controlled by the vehicle module 414 using an Estimated
Reconditioning control account (e.g. a sub set of the account table 415). For
example,
when a purchase order is generated (e.g. in progress data 404) against a
vehicle for
reconditioning, either in the dealers own service department, or outsourced in
the form
of sublet work, a corresponding estimated amount 435 is entered into the
account table
415, associated with the vehicle. For example, assume an amount of $150 being
entered. This amount 435 is used to raise corresponding entries in the table
415 as
follows (e.g. for use in subsequent update of the general ledger 150 when
requested
406):
1. Debit Vehicle Inventory with $150 (i.e. vehicle associated financial data
142);
2. Credit Estimated Reconditioning with $150 (i.e. vehicle associated
financial data 142); and
CA 02657303 2009-03-06
-56-
3. Update the Reconditioning Cost on the Vehicle Inventory Record with $150
(i.e. vehicle associated financial data 142).
[00173] The above entries 435 are generated at the point of creating the
Purchase
Order, e.g. the trigger 404 for launching the appropriate vehicle module 414.
The
reason for doing this, for example, is so that the total potential cost of the
vehicle is
known/available in the general ledger 150 even before the work is completed.
This
knowledge can be very important should the dealer 114 be in the process of
selling the
vehicle, wherein the true costs are known upfront and no surprise costs appear
after the
vehicle has been sold and commissions have been paid, when it may not be
possible to
recover the costs (as in the current dealer management systems not having any
interaction with their general ledgers until after the work has been
completed).
[00174] Accordingly, in view of use of the table 415 and the entries 435, if a
Vehicle Inventory List is produced in the DMS, the Vehicle Inventory List
would balance
with the general ledger 150 because of the above actions.
[00175] Further, for example, when a Vendor Invoice for the sublet work is
processed (e.g. input 404), or the repair order is closed (e.g. input 404) in
the case of
dealer performed reconditioning, in response the vehicle module 414 is
launched (as
coordinated by the accounting engine 400 and then finalizes the entries 435.
Assuming
in the above example, the final cost is $155.90 the following entries 435 are
revised:
1. Credit the Payable with $155.90;
2. Debit Vehicle Inventory with $5.90;
3. Debit Estimated Reconditioning with $150; and
4. Update the Reconditioning Cost on the Vehicle Inventory Record with
$5.90, thereby providing for the correct information present in the table 415
for
use in generating the general ledger 150.
[00176] Therefore, if the Vehicle Inventory List is produced, based on the
revised
and current values 435, the list would balance with the general ledger 150
because of
the above actions.
Potential Trade-In Vehicle Reconditionina
CA 02657303 2009-03-06
-57-
[00177] It is common practice for a dealer to commence with reconditioning on
a
potential trade-in before the deal has been finalized. In the event that the
buyer is
unable to secure finance, or for some other reason, the deal might have to be
cancelled
and any money for work done on the potential trade-in needs to be recovered,
or written
off. It is even possible that the potential trade-in could have been sold.
Normal
Inventory reconditioning general ledger entries cannot be done in this case
using typical
dealer management systems, because the potential trade-in vehicle has not yet
been
stocked and this would cause an imbalance between general ledger and the
vehicle
inventories.
[00178] Referring again to Figure 10, in the framework 152 this is accounted
for by
the vehicle module 414 using the account table 415. When the Vendor Invoice
for the
sublet work is processed, or the repair order is closed in the case of dealer
performed
reconditioning, assuming a cost of $200, the vehicle module 414 generates the
following temporary entries 435 in the table 415, until such time as the deal
is booked
(e.g. input 404) into accounting (e.g. removing the in progress status of the
entries 435):
1. Credit the Payable with $200 (i.e. vehicle associated financial data 142);
2. Debit Potential Trade-in Reconditioning with $200 (i.e. vehicle associated
financial data 142); and
3. Update the Reconditioning Cost on the Vehicle Inventory Record with
$200 (i.e. vehicle associated financial data 142).
[00179] When the deal on the vehicle being sold is booked into accounting
(e.g.
input 404) , besides all the normal general ledger entries generated by the
sale the
following entries 435 are amended/revised in the table 415:
1. Debit Vehicle Inventory / Reconditioning with $200; and
2. Credit Potential Trade-in reconditioning with $200.
Accounts Module 416
[00180] The accounts module 416 updates the accounts table 417 in response to
the occurrence of dealer actionsJactivities for accounts related transactions.
One
example of the dealer actions/activities for accounts related transactions is
for
outstanding invoices (e.g., yet to be invoiced or already invoiced by not yet
recorded for
CA 02657303 2009-03-06
-58-
services associated with a internal dealer orders and external vendor orders)
associated
with a vehicle that might have otherwise been missed when the vehicle was
sold. This
could be a loss to the dealer, since the grosses would be inaccurate on which
the
negotiated selling price of the vehicle and commissions could be figured.
[00181] The accounts module 416 can also include maintenance of all in-system
reports for the dealership users: including in progress accounting issues with
financial,
parts, service, gross DOC and customer sales dealer activities/actions. The
latter can
lists in real-time all the dealerships customers (including companies) ranked
in
descending (or ascending) order of total sales (vehicles, parts, service) so
that
personnel are aware of the amount of business each customer has brought to the
dealership.
[00182] The accounts module 416 can maintain in progress accounting
activities/actions, as account tables 417 maintained for accurate tracking of
accounts
activity (i.e. from both financial - represented by service financial data 142
- and a non-
financial - represented by accounts not reconciled vehicle data 140 -
information) in
synch with the general ledger 150, thereby inhibiting any need for time
consuming and
costly manual reconciliation of accounting WIP by staff of the dealership(s)
114.. .
Control Accounts 417 in the Accounting System
[00183] The framework 152 utilizes control account tables 417 to manage all
cash
in the dealership 114 as well as the bank account in the general ledger 150.
Control
account tables 417 are maintained by the accounts module 416 for both parts
and
service cash sales, for example. These account tables 417 make is
straightforward to
cash sales in all departments that have not been receipted as well as all cash
and
checks that have not been deposited in the bank.
[00184] For example, when either a parts cash invoice or a service cash repair
order is invoiced (e.g. input action 404), the accounts module 416 will post a
debit entry
437 to a Parts or Service Cash Control account table 417. Assuming a cash sale
of
$125, when the cashier receipts the money the account tables 417 will generate
the
following entries 437:
1. Credit the Parts / Service Cash Control Account with $125 (i.e. vehicle
associated financial data 142); and
CA 02657303 2009-03-06
-59-
2. Debit the Cash On Hand Account with $125 (i.e. vehicle associated
financial data 142).
[00185] The Parts / Service Cash Control account table 417 contains details
437
of all the cash sales that have not been receipted and the Cash On Hand
account table
417 contains the detail 437 of all receipted cash sales that have not yet been
deposited
in the bank.
[00186] When the bank deposit is processed (e.g. input 404), the accounts
module
416 will amend/revise the following entries 437 for all the receipted entries
that have
been selected:
1. Credit the Cash On Hand account with the total being deposited;
2. Debit the Bank Account with the total being deposited; and
3. Optionally print a bank deposit report.
[00187] The above steps performed by the accounts module 416 makes
reconciling the bank statement to the bank account easier as the deposit
entries on the
general Iedger150 bank account agree with the deposit entries on the bank
statement.
[00188] The next step in the cash management process is the reconciliation of
the
bank statement to the bank account in the general ledger 150. When a check is
produced in the DMS or a bank deposit is made, these entries are automatically
generated in the general ledger bank account 150.
[00189] When the bank statement is reconciled in the Bank Reconciliation
application in the DMS, the accounts module 416 will transfer reconciled
entries 437
from the general ledger bank account to the general ledger bank statement
account and
flag them as paid / reconciled in the bank account.
[00190] This means that the bank statement account can reflect the detail and
the
balance of the actual bank statement and the bank account can reflect the
detail of
checks and cash that have not yet appeared on the bank statement. The net
balances
of the two accounts can reflect the true cash balance of the dealership 114.
Framework 152 Fixed Operations
(00191] Referring to Figures 1 and 9, the following are further example
capabilities
of the framework 152, as performed by any of the modules of the accounting
engine
400 and/or the consolidation engine 350, as desired.
CA 026573032009-03-06
-60-
[00192] Can the framework 152receive information via Bar Code Scanners for
parts both during stock in procedures and sales? Yes, the framework 152 can.
Remember, in a Windows environment, a bar code reader simply emulates a
keyboard.
The framework 152 can use bar code readers for parts inventory, stocking,
sales and
counting, stocking of vehicle inventory (reading the VIN), and creating a RO
(reading
the VIN). Further, the framework 152 can interact with an application 117
hosted on a
tablet PC with a bar code reader attached. This facilitates stocking of
vehicles when
they are delivered or creating ROs on the service drive. For example, the
tablet PC can
be used to enter the input 404 that prompts the accounting engine 400 to
implement, as
desired.
[00193] When a part that carries core is sold how is the core value handled?
When
a dirty core is turned in how is that credit handled both with regard to
perpetual counts
and to accounting entry? In the framework 152, we can have what is known as a
"core
part suffix" (or prefix as is the case with Chrysler). So part number "ABC123"
would
have a core part "ABC 1 23C". The core part has a cost price associated with
it, and the
main part's cost is net of the core. When the part it invoiced, the framework
152
automatically includes the core part number on the invoice. If the customer is
returning
a core, the quantity is simply changed to a credit. When a part is released
into inventory
from an order, the framework 152 will automatically update the core part as
well. When
cores are retuned to the factory, they are processed as a parts return by the
framework
152.
100194] When the parts department issues a Purchase Order to a local parts
store
does that information carry through to the RO? How about a sublet PO, i.e.,
radiator?
When a Parts Purchase Order is created, the framework 152 has the option of
entering
a RO number against individual order lines. When the order is released, the
framework
152 will automatically create a parts invoice with that part against the RO.
Depending on
a parameter setup, the framework 152 will either leave the Parts Invoice in
"created"
status, or the framework 152 will actually post the invoice to the RO. When a
Sublet is
ordered, the procedure in very similar, the main difference is that the system
creates a
"part number" using the Order Number and the Line Number (e.g. P0001232-01).
At
month end, all these parts with a zero on hand balance remain in the system
for
auditing purposes. Using this method make it easier to control sublets, as
they are
treated as physical inventory until the RO is invoiced.
CA 02657303 2009-03-06
-61-
[00195] When a purchase order for a Rental Car is issued, does that trigger
any
special alert for a service advisor? A Purchase Order is created against a RO
for car
rental, much like a Sublet (outwork) order. An RO cannot be invoiced without a
vendor
invoice posted against the PO. We need to do this in order to capture the
number of
days, and to also handle it correctly on the integration of warranty claims
with the OEM
where car rental information is required.
[00196] Does the framework 152 interface with Electronic Parts Catalogs? We
have done integration for Microcat, Pro Quest and Start Parts (Chrysler).
[00197] During the installation process, can the framework 152 transfer Parts
History and Vehicle Repair History from the retiring system? If the retiring
system is
REY or ADP, we have written a conversion process that converts Customer
records,
Vehicle Inventory, Service History and Parts History directly into the
framework 152
without having to dump out data from those systems. This process is automated,
and
does 95%+ of the work required to set us a new dealership in the framework
152. For
other systems we need to dump out data in the form of reports etc and convert
the data.
[00198] Many dealers rely upon an annual Parts Department Physical Inventory
to
verify the accuracy of the balance for Parts and Accessories in the General
Ledger.
During the annual process the following is needed: Parts Inventory Count Pad
in Bin
Location Sequence; Input process for entering the new physical counts; Report
of Count
Pad pages not posted; and Variance Report that displays any difference in
count/extended value before and after Final Extended Value Report in a variety
of
sequences. Can the framework 152 accommodate this process? The framework 152
has a very comprehensive parts count module that does all of the above items
that you
mention and more. We also have a perpetual count procedure where the dealer
can
specify how many time in a year every part needs to be counted (e.g. at least
twice) and
whether counts are done daily or weekly. The framework 152 then will generate
count
sheets randomly either daily or weekly for part numbers that need to be
counted. Also,
when parts are counted, the framework 152 uses a date and time stamp on the
part
number to check for part movement between the time that the part is counted to
when
the variance report is run. This enables part counts to be done during normal
trading
hours.
CA 02657303 2009-03-06
-62-
[00199] Unfortunately for me, I have done way too many parts-to-accounting
reconciliations. It is heart wrenching to tell a dealer that the parts on the
shelves do not
match what he has on his financial statement. There are unlimited reasons why
this can
happen, but I have found that the most common is that the accounts payable
clerk has
posted invoices to the wrong account (i.e.: marketing pamphlets posted to
parts
inventory, etc). How does the framework 152 logic help in this area? When
parts are
released into inventory, they are released at Replacement Cost (cost according
to the
factory parts tape). If there are additional charges on an invoice for example
freight,
these charges have to be allocated to the appropriate account. Because the
Parts
Inventory account is a "controlled" account, it is may not be possible to
manually post
anything to that account. Control accounts are all inventory accounts (parts
vehicles and
service WIP), all Receivable accounts and all Payable account (including sales
tax).
Entries 431, 433, 435, 437 can hit the control accounts 402 when they are made
in the
corresponding sub-ledger 151 (buy a part, sell a part, count a part or buy a
vehicle, sell
a vehicle, do recon on a vehicle). This is the reason why in the framework
152, the parts
inventory (or any other inventory or control account 402) may never be out of
balance
with the GL 150.
Other Example "clearing"/"control" accounts 402
[00200] There is a sales inventory reconditioning clearing account 402. When a
purchase order is made out for any outwork / sublets on a vehicle, the option
exists for
an estimated amount to be entered. Likewise, when desking a deal, and "dealer-
fitted"
extras with an estimated cost entered are included on the deal, the system 152
will
generate a debit entry to the vehicle inventory account 402 and a credit entry
to the
reconditioning clearing account 402. Once the final Vendor Invoice or RO is
processed,
the system will credit the clearing account 402 with the original amount, and
if the final
amount is different to the original estimate, any adjustment is automatically
done to the
Vehicle Inventory Account 402 (or Cost of Sales if the vehicle is sold).
[00201] These clearing accounts 402 are all automatically maintained by the
system 152, and need no manual reconciliation. What they do, is enable the
office
manager to be confident that the financials are good and in balance. It also
means no
surprises at the end of the month.
[00202] Some other accounts 402 are such as but not limited to:
CA 02657303 2009-03-06
-63-
1. When vehicles are stocked by not issuing a check or floor planning, a
vehicle
purchase clearing account 402 is used. When the vendor invoice is processed,
or a
check is cut or the vehicle is floor planned it clears the purchase account
402.
2. Like the Reconditioning clearing account 402 mentioned before, we have
similar
functionality for "potential trade-ins". Very often, the dealers start doing
work on
traded-in vehicles before the deal in finalized. We track these entries in a
clearing
account 402 (i.e., not to inventory, as this would put the GL and Vehicle
Inventory
sub-ledger 151 out of balance) and once the deal in finalized and the trade in
is
stocked, the system 152 transfers the amount from the clearing account 402 to
the
used vehicle reconditioning account 402.
3. We have a Bank account 402 and a Statement account 402\. All deposits and
checks hit the bank account 02 . Once the Bank Recon is done using our bank
reconciliation system of the framework 152, the reconciled entries are
automatically
moved from the Bank account 402 to the Statement account 402. So the Statement
account 402 reflects the actual bank balance.
4. Where a dealer has multiple rooftops (e.g. dealerships 114), we allow for
inter-
company processing in a number of areas:
a. Centralized bank account 402 - a check can be cut in one dealership 114 to
pay for an expense / AP etc in another dealership 114 and the system 152
will generate the necessary inter company accounts 402;
b. Centralized sales vehicle inventory where the vehicle is transferred to the
selling dealer inventory when the deal is booked to accounting;
c. Centralized AP accounts 402; and
d. Centralized AR accounts 402.
Database 110.115
[00203] The memory 110,115 can be defined as a collection of information that
is
organized so that it can easily be accessed, managed, and updated. In one
view,
databases can be classified according to types of content: bibliographic, full-
text,
numeric, and images. In computing, databases are sometimes classified
according to
CA 02657303 2009-03-06
-64-
their organizational approach. As well, a relational database is a tabular
database in
which data is defined so that it can be reorganized and accessed in a number
of
different ways. A distributed database is one that can be dispersed or
replicated among
different points in a network. An object-oriented programming database is one
that is
congruent with the data defined in object classes and subclasses.
[00204] Computer memory 110,115 typically contains aggregations of data
records or files, such as sales transactions, product catalogs and vehicle
inventories,
and customer profiles. Typically, a database manager provides users the
capabilities of
controlling read/write access, specifying report generation, and analyzing
usage.
Databases and database managers are prevalent in large mainframe systems, but
are
also present in smaller distributed workstation and mid-range systems such as
the
AS/400 and on personal computers. SQL (Structured Query Language) is a
standard
language for making interactive queries from and updating a database such as
IBM's
DB2, Microsoft's Access, and database products from Oracle, Sybase, and
Computer
Associates.
[00205] Memory storage is the electronic holding place for instructions and
data
that the computer's microprocessor 308 can reach. When the computer 101 is in
normal operation, its memory 100,115 can contain the main parts of the
operating
system and some or all of the application programs and related data that are
being
used. Memory is often used as a shorter synonym for random access memory
(RAM).
This kind of memory is located on one or more microchips that are physically
close to
the microprocessor in the computer.
[00206] It is recognized that the use of online advertisements (e.g. car ads
107)
and updating of the advertisements is based on information 108,109 obtained
from the
dealerships DMSs (i.e. Dealer Management Systems). It should be noted that an
advertisement 107 searchable by the consumers 104 in the database 110 is in
combination with this online system 10, and as such the interaction between
DMSs and
the online ad content is used to keep the online advertisements 107 current
with respect
to the details of the respective vehicle and/or vehicle part/service available
in the DMSs.
[00207] As discussed above, the use of up-to-date vehicle information is
useful for
facilitating the online searching and potential purchasing/selection of
vehicle information
107, based on information 108 obtained from the dealer databases 115.
Accordingly,
CA 02657303 2009-03-06
-65-
the vehicle data contained in the database 115, as managed by the DMS, is
dynamically monitored and maintained, in terms of the vehicle data's current
up-to-date-
values, both in financial and non-financial aspects.
Network Interface 202
[00208] The framework 112,152 uses the network interface 202 (e.g. a Web
portal) to provide access by the consumer 104, via the DMSs, directly to the
dealer's
inventory 115 of vehicles, as well as access of the dealer personnel to the
functionality
of the framework 152, respectively. There can be polled (according to a
selected poll
frequency) intercommunication between the DMSs (via the Web interfaces) and
the
Web portal 202 for any information updates 109 available on the vehicles in
the vehicle
inventories 115 (e.g. changes to existing postings, new postings, and deleted
postings,
postings with down payment in process/progress, etc.), as well as for initial
information
108 for vehicles and/or vehicle service/parts data 140,142, respectively. The
intercommunication also includes an availability check on the consumer chosen
vehicle
prior to acceptance of the credit card (or other electronic payment e.g. Pay
Pal) down
payment 92, in the event that the chosen vehicle has recently been sold (or in
the
process of being sold) onsite at the dealership (or via another on-line
transaction).
Further, once the down payment 92 is accepted, the on-line purchase is entered
into the
respective DMS as if the consumer had physically come into the dealership to
see a
salesperson that is assigned to the chosen vehicle.
[00209] The module 202 can be part of the network connection interface 300
(see
Figure 2) of the device 101 operating the framework 112, 152. The module 202
can
communicate synchronously or asynchronously with the device 101 of the
consumer
104 (or dealer personnel) over the network 11 to receive or otherwise
structure the
search requests 105, input 404,406, respectively. For example, the module 202
could
be a Web service as a software system designed to support interoperable
machine-to-
machine interaction over the network 11, between the framework 112, 152 and
the
users. The Web service of the framework 112, 152, as facilitated by the module
202
can be configured as a series of Web APIs that can be accessed over the
network 11
by the users and then executed on the framework 112,1522 hosting the requested
services.
CA 02657303 2009-03-06
-66-
[00210] The Web service definition of the interface of the module 202 can
encompass many different systems, such as clients and servers that communicate
using XML messages that follow the SOAP standard. Also, the module 202 could
provide a machine-readable description of the operations supported by the
framework
112,152 written in the Web Services Description Language (WSDL).
[00211] For example, the module 202 provides to the users an electronic
interface
for access to the vehicle definitions 107, as searched in the database 110
through any
subset of the vehicle details via the search parameters 99. For example, the
electronic
interface 202 can be a Web portal offering a structured vehicle search engine,
i.e. the
consumers 104 via their browser access the contents of the electronic database
110
over the network 11 via the framework 112 that hosts the vehicle search engine
(e.g.
information module). For example, the consumers 104 could search vehicle "for
sale"
information in the database110 to find the lowest advertised new vehicle
prices in
various markets across the country. The electronic interface 202 can present
predefined search parameter 99 selections (e.g. vehicle classifications as
selections via
suitable user interface control elements) as product and/or vendor centric
(e.g. vehicle
and dealership centric input). Therefore, instead of the consumer 104 typing a
vehicle
of vendor name in the search engine search string (e.g. a vehicle or
dealership name),
the consumer 104 can chose a name from a list element that is updated
regularly. It is
recognised that the selections 99 can pertain to the classifications that were
assigned to
the vehicle definitions 107 via a classification module.
[00212] Examples of user interface control elements of the interface 202 can
include such as but not limited to a dropdown list that is similar to a list
box, which
allows the users to choose one or more values 99 from the list. When the
dropdown list
is inactive it displays a single value. When activated, the dropdown list
displays (drops
down) a list of values (e.g. classifications) 99, from which the consumer 104
may select.
When the users selects a new value 99, the control element reverts to its
inactive state,
displaying the selected value. The control elements can include, for example,
a combo
box having an editable entry portion of the list. The navigation field of a
web browser is
an example of a combo box. A further example of the control elements is a list
box or
tabs that provide for the selection of one or more classifications at a time
by the users.
A further type of example control element is a Pop-up/down menu, whereby pop-
ups
CA 02657303 2009-03-06
-67-
are used to select a single classification from a list while pop-downs are
used to issue
commands 99 (e.g. customized search terms) or in cases where multiple
classifications
99 can be selected. In any event, it is recognised that the control elements
can be used
by the users to formulate at least some of the search parameters 99 of the
search
request 105, for example. The module 202 can include receipt and transmit sub-
modules can be part of the network connection interface module 202, in
accordance
with the parameters of the search request 105 as well as the generated search
results
106, as desired.
[00213] It is recognised that the above described module 202 can also be used
for
access by the users to parts and/or service information data 140,142 made
available to
the framework 112,152 via the dealers 114 (e.g. from their inventory 115 and
coupled
DMSs). As well, It is recognised that the module 202 can be used to provide
for access
with dealer staff and enabled DMS features that are for example, part of the
dealer DMS
and/or are hosted remote to the dealer (e.g. via the framework 112, 152).
Operation of the Accounting Engine 400 and the Consolidation Engine 350
[00214] Referring to Figures 1, 8, 9, and 11, shown is an example operation
500 of
the accounting engines 400, 350 of the system 10 for representing in-progress
activities
of a vehicle dealership 114 in financial information of a general ledger 150.
At step 502,
the receipt module 418 receives financial data 404 associated with a
dealership activity
having an in-progress status. At step 504, the storage 115 is access an
account data
structure 402 adapted for storing the financial data 404, the account data
structure 402
associated with a trio of accounts in the general ledger 150, pairs of the
trio of accounts
being related through double entry bookkeeping.
[00215] At step 506, the appropriate processing module 410,412,414,416 updates
the received financial data 404 in the account data structure 402 as
representing a
financial value of the in-progress activity, the updating in response to the
receipt of the
financial data 404 or other trigger for precipitating the operation of the
processing
module 410,412,414,416, such that the financial value represents a debit entry
431,433,435,437 for application to the first account of the trio of accounts
and
represents a credit entry 431,433,435,437 for application to the second
account of the
trio of accounts, the credit and debit entries 431,433,435,437 having the
financial value.
CA 02657303 2009-03-06
-68-
It is recognised that at this stage, the general ledger 150 can be generated,
taking into
account the entries 431,433,435,437 present in the accounts 402.
[00216] At step 508, the receipt module 418 receives subsequently update
information 404 representing a cancellation of the in-progress status of the
dealership
activity and this precipitate the corresponding processing module
410,412,414,416 (or
modules) to update the financial value in the respective account data
structure 402 in
response to receipt of the cancellation 404 of the in-progress status, such
that the
updating revises the credit entry 431,433,435,437 of the second account to a
debit and
adds a credit entry 431,433,435,437 to the third account of the trio of
accounts, such
that the revised credit entry 431,433,435,437 and the added credit entry
431,433,435,437 have the financial value.
[00217] At step 510, the entries 431,433,435,437 stored in the account data
structure are used for updating the financial information corresponding to at
least two of
the trio of accounts in the general ledger 150, when requested 406, as
performed by the
general ledger module 420 adapted for receiving the ledger generation request
406 and
for updating the financial information of the general ledger 150 using the
contents
431,433,435,437 of the account data structure(s) 402, wherein, for example,
the
updating is for the first and the second accounts prior to receipt of the
cancellation 404
of the in-progress status and is for the second and the third accounts after
receipt of the
cancellation 404of the in-progress status.
[00218] At step 512, optionally, the consolidation module 350 combines a
plurality
of account data structures 402 in the storage 115 for use in generating a
consolidated
general ledger 150 representing the financial information for a plurality of
dealerships
114, such that each of the plurality of account data structures402 is
associated with a
respective dealership 114 of the plurality of dealerships 114.
[00219] In view of the above, it is recognized that the account data structure
402
can be represented as a plurality of account data structures 402 in the
storage 115,
such that each of the account data structures 402 of the plurality of data
structures 402
is associated with an account type. The account types can be such as but not
limited
to: a parts account type and the in-progress status represents work-in-
progress
CA 02657303 2009-03-06
-69-
involving vehicle parts at the dealership 114; a service account type and the
in-
progress status represents work-in-progress involving vehicle service at the
dealership
114; a vehicle account type and the in-progress status represents vehicle
sales status
involving one or more vehicles at the dealership 114; and an accounting type
where the
in-progress activity relates to the in process processing or a received
invoice, received
payment on an already issued invoice, and/or a purchase order in the process
of being
converted to an invoice.
CA 02657303 2009-03-06
-70-
Example Configuration of the Framework 152
Darwin XE Uadate Proarams Page
Individual Table Update Programs 1
Accounts Payable update program 3
Accounts Receivable update program 7
General Ledger update program 11
Parts update program 16
Vehicle update program 22
Miscellaneous Update Programs 26
changeStockNo (Change a Vehicle Stock Number) 27
changeVehCategory (Change Vehicle Category) 28
transferFloorplan (Change Vehicle Fllorplan) 29
updateBatchDetail (Posting Detail Line) 30
updateCheck (Check Processing) 31
updateFloorplan (Vehicle Floorplan Payments) 33
updatelnternalOrder (Internal Orders and RO's - WEO's) 34
updateLostSale (Parts Lost Sales) 35
Systern Update Programs 37
PartInvoiceUpdate (Create Parts Invoices) 38
PartOrderUpdate (Create and Release Parts Orders) 43
ReceiptUpdates (Process a Cash or AR Recipt) 48
UpdatePostings (Process Manual Postings) 51
UpdateServicelnvoice (Close a Repair Order) 55
UpdateVehiclelnvoice (Invoice a Stocked Vehicle) 59
CA 02657303 2009-03-06
-71-
Individual Table Update Programs
There are a series of example update programs in the framework 152 for use in
updating various
components of the dealers 114 data 142,140, such as their modules of the
engines 350,400. It is
recognized that any procedures/steps referred to as
critical/important/must/needed/etc. can also
be considered as optional or otherwise not specifically
critical/important/must/needed/etc., as
appropriate. The programs are the only programs that update the various sub
ledgers so as to
ensure consistency and data integrity. The update programs are all server side
programs and they
need access to the the server side libaries. The update programs may not have
direct access to
shared properties created by the Darwin application and they would use the
DYNAMIC-
FUNCTION Progress function call to access these
When using the update programs, a temp table 402 is created and populated with
the necessary
data, before the program is run. Validations are done on the temp table 402 by
the update
programs and any necessary validation errors can be returned to the calling
program (e.g.
modules of the engines 350,400.
Multiple update programs can be called from a single calling program and all
updated records
fall into the same transaction scope as the calling procedure. The update
programs may not have
their own transaction scope, which can be defined in the calling program. This
faciliates that
should an error occur or a validation fail, the entire transaction is undone.
All the update programs can reside in the inc/upd directory structure on the
server (e.g. DMS),
and update program names can be prefixed with this information as shown in the
example above.
Many update programs can be run at any time, however a pre-defined sequence
can be used as
this can facilitate the possibility of deadly embrace record lock situations.
The following update
sequence is an example.
1. Accounts Receivable
2. Accounts Payable
3. Repair Order
4. Service DOC
5. Service Advisor
6. Technicians
7. Vehicle Stock
8. Vehicle DOC
9. Vehicle Salesperson
10. Service History
11. Parts
12. Parts Salesperson
13. Parts DOC
14. General Ledger
15. Invoice Register
16. Customer Sales Analysis
The individual update programs update the data in Sequence ID sequence.
Multiple records can
be created in each of the temp tables 402 before calling the update programs.
It can be more
efficient to do the updates in this way. So populate all the update program
temp tables 402 and
then call the update programs as required in the above sequence once all the
temp tables 402
have been populated with the required data.
CA 02657303 2009-03-06
-72-
1. Accounts Payable - inc/uad/uadateAP.a
The Accounts Payable update program (.ie. Module of the accounting engine 400)
will update
one or more AP accounts 402 with one or more transactions. This program does
not generate
general ledger 150 transactions, it updates only the AP balances and other
data such as dates and
ageing. The transaction supporting the update is generated by the updateGL.p
procedure.
The AP update program runs the following procedures:
UpdateCustomerSales - resident in the applStart.p library.
inc/ap/recalctradepoint.p - external procedure
The AP update program is run with the following syntax:
RUN inc/upd/updateap.p (INPUT TABLE ttAP,
INPUT TABLE ttAPTrade,
OUTPUT vlOkay).
IF RETURN-VALUE NE " THEN
RETURN RETURN-VALUE.
IF NOT vlOkay THEN
RETURN 'Error Updating AP in' + THIS-PROCEDURE:NAME.
The temp tables ttAP and ttAPTrade are defined in inc/ttAP.i and
inc/ttAPTrade.i.
The AP temp table ttAP requires to be populated with the following data:
DEFINE TEMP-TABLE ttAP NO-UNDO
FIELD APCono AS CHARACTER Company Number
FIELD APCoPrefix AS CHARACTER Company Prefix
FIELD APAccMonth AS INTEGER Accounting Month
FIELD aptTradePoint AS CHARACTER Trade Point
FIELD APAccno AS CHARACTER AP Account / Sequence ID
FIELD APMove AS CHARACTER Transaction Code
FIELD apmAccType AS CHARACTER Account Type
FIELD APRefno AS CHARACTER Reference Number
FIELD APOrder AS CHARACTER Order Number
FIELD APDate AS DATE Transaction Date
FIELD APDateCap AS DATE Date Captured
FIELD APTimeCap AS CHARACTER Time Captured HH:MM:SS
FIELD APAmount AS DECIMAL Posting Amount
FIELD APForAmt AS DECIMAL Forex Amount
FIELD APPaid AS LOGICAL Allocation Indicator
FIELD APAgeMth AS INTEGER Age Month
FIELD APNarr AS CHARACTER Narrative
FIELD APAudit AS CHARACTER Audit Number
FIELD APUserID AS CHARACTER. User ID
FIELD APJobNumber AS INTEGER RO Job Number
FIELD APLineNumber AS INTEGER RO Job Line Number
CA 02657303 2009-03-06
-73-
Field Descriptions
APCono The Company Number in which the posting is taking place. This
Is not necessarily the same company the AP resides in.
APCoPrefix The Company in which the AP resides. This is not necessarily the
Company in which the posting is being done. The best place to
get this company number is the property `getAPPrefix' which
will always contain the Company Number where the AP
resides.
APAccMonth The accounting month which the transaction is being posted into.
This is normally the current accounting month (glcGLControl.AccounMonth)
Or it can be any open accounting month. The table glmGLAccMonth contains
all the available accounting months that are still open.
aptTradePoint The Trade Point name where the posting is taking place.
APAccno This can be either the AP Account Number (aptAPMaster.APAccount)
Or the AP sequence ID (aptAPMaster.DbAPSeqID).
APMove The Movement Code. Valid values are:
INV - Invoice
CRN - Credit Note
CHK - Check
JNL - Journal
ORD - Order
APRefno This would be the AP Invoice Number or a Check Number etc.
APOrder System generated Order Number.
APDate Transaction Date. This might not be the Posting Date.
APDateCap The Posting Date. This might not be the same as the Transaction
Date.
APTimeCap Time that the transaction was captured in the format HH:MM:SS.
APAmount Transaction Amount with the correct sign. The amount will be added
to the AP so an Invoice will be a credit value and a check will be a
Debit value.
APForAmt Forex Amount in the currency as set up on the AP Account.
APAgeMth Ageing Month. 1= current, 2= 30 days etc up to 6 = 150 days.
APNarr Free form Narrative for the transaction.
APAudit The Audit number is a combination of the AP Audit Prefix and the
CA 02657303 2009-03-06
-74-
System Audit Number (apcApControl.AuditPrefix +
STRING(sycSysControl.CurrentAuditNo,"999999")).
APUserID User ID of the user doing the transaction.
Note: All the fields with the exception of the Forex Amount are mandatory
fields and the AP
update program will return an error if the fields are not populated with valid
data.
2. Accounts Receivable
The Accounts Receivable update program (e.g. of the accounting module 316)
will update one or
more AR accounts 402 with one or more transactions. This program does not
generate general
ledger transactions, it updates only the AR balances and other data such as
dates and ageing. The
transaction supporting the update is generated by the updateGL.p procedure.
The AR update program runs the following procedures:
UpdateCustomerSales - resident in the applStart.p library.
The AR update program is run with the following syntax:
RUN inc/upd/updatear.p (INPUT TABLE ttAR,
INPUT TABLE ttARTrade,
OUTPUT vlOkay).
IF RETURN-VALUE NE " THEN
RETURN RETURN-VALUE.
IF NOT vlOkay THEN
RETURN 'Error Updating AR'.
The temp tables ttAR and ttARTrade are defined in inc/ttAR.i and
inc/ttARTrade.i.
The AR temp table ttAR requires to be populated with the following data:
DEFINE TEMP-TABLE ttAR NO-UNDO
FIELD ARCono AS CHARACTER Company Number
FIELD ARCoPrefix AS CHARACTER Company Prefix
FIELD ARAccMonth AS INTEGER Accounting Month
FIELD ARTrade AS CHARACTER Trade Point
FIELD ARCredit AS LOGICAL Credit Note
FIELD ARAccno AS CHARACTER Sequence ID
FIELD ARRefno AS CHARACTER Reference
FIELD AROrder AS CHARACTER Order Number
FIELD ARDate AS DATE Transaction Date
FIELD ARDateCap AS DATE Date Captured
FIELD ARTimeCap AS CHARACTER Time Captured
FIELD ARAmount AS DECIMAL Transaction Amount
FIELD ARBudget AS DECIMAL Budget Amount
CA 02657303 2009-03-06
-75-
FIELD ARNarr AS CHARACTER Narrative
FIELD ARMove AS CHARACTER Movement Code
FIELD ARType AS CHARACTER Posting Type - P,W,V,O,S
FIELD ARAudit AS CHARACTER Audit Number
FIELD ARControl AS CHARACTEE AR Account Number
FIELD ARPostMonth AS INTEGER Posting Month
FIELD ARUserID AS CHARACTER User ID
FIELD ARForamt AS DECIMAL Foreign Amount
FIELD ARRate AS DECIMAL Exchange Rate
FIELD ARFirstAc AS LOGICAL. In Veh Invoicing indicates 1 st Account
Field Descriptions
ARCono The Company Number in which the posting is taking place. This
Is not necessarily the same company the AR resides in.
ARCoPrefix The Company in which the AR resides. This is not necessarily the
Company in which the posting is being done. The best place to
get this company number is the property `getARPrefix' which
will always contain the Company Number where the AR
resides.
ARAccMonth The accounting month which the transaction is being posted into.
This is normally the current accounting month (glcGLControl.AccounMonth)
Or it can be any open accounting month. The table glmGLAccMonth contains
all the available accounting months that are still open.
artTrade The Trade Point name where the posting is taking place.
ARCredit Indicates whether the transaction is a Credit Note - Yes or No
ARAccno This can be either the AR Account Number (artARMaster.AccountNumber)
Or the AR sequence ID (artARMaster.DbARSeqID).
ARRefno This would be the System produced Invoice Number, Receipt No,
Journal, Check Number etc.
AROrder The AR's Order Numbe.
ARDate Transaction Date. This might not be the Posting Date.
ARDateCap The Posting Date. This might not be the same as the Transaction
Date.
ARTimeCap Time that the transaction was captured in the format HH:MM:SS.
ARAmount Transaction Amount with the correct sign. The amount will be added
To the AR so an Invoice will be a Debit value and a Receipt will be a
Credit value.
ARBudget Work in Process Value on a Repair Order. This is used to calculate
. . . . .. . .... . .. . . . .. . . .. . . .. . . / ..,:. , . . .. .. ......
.. . . . . . . .. . .. . . . .. .
CA 02657303 2009-03-06
-76-
The Credit Available on a AR Account.
ARPaid
ARForAmt Forex Amount in the currency as set up on the AR Account.
ARAgeMth Ageing Month. 1= current, 2 = 30 days etc up to 6= 150 days.
ARNarr Free form Narrative for the transaction.
ARMove The Movement Code. Valid values are:
INV - Invoice
CRN - Credit Note
CHK - Check
JNL - Journal
ORD - Order
ARAudit The Audit number is a combination of the AR Audit Prefix and the
System Audit Number (arcArControl.AuditPrefix +
STRING( sycS ysControl. CurrentAuditNo,"999999")).
ARControl The AR account Number
ARUserID User ID of the user doing the transaction.
ARFirstAc In Vehicle Invoicing this indicates the First Account being updated
As an AR can have 2 accounts.
CA 02657303 2009-03-06
-77-
3. General Ledp-er
The General Ledger update program (e.g. as implemented by the accounting
engine 400 itself)
will update one or more GL accounts 402 with one or more transactions. The
transactions in the
temp table 402 passed to this program must be in balance or the update will
not take place. The
preparation of the temp table need not cater for intercompany transactions or
consolidation
transactions. The GL update program takes care of all that processing.
For example if a transaction is being generated for a check issued in one
companies bank account
402 to pay for an expense in another company, only 2 transactions need to be
generated. The
entry to credit the bank, and the entry to debit the expense account 402. As
long as both entries
have the correct company numbers the GL update program will generate the
correct inter
company entries and will as do all the consolidation updates.
This program also takes car of distribution postings. If a transaction needs
to be split across
multiple distribution accounts, only the entry to the main account is created
for the total amount.
The update GL program will create the entries for the distribution accounts
402.
The temp table ttGL is defined in inc/ttGL.i.
The GL update program does not run any external procedures .
The GL temp table ttGL requires to be populated with the following data:
RUN inc/upd/updateGL.p (INPUT TABLE ttGL,
OUTPUT vlOkay).
IF RETURN-VALUE NE " THEN
RETURN RETURN-VALUE.
IF NOT vlOkay THEN
RETURN 'Error Updating GL'.
The GL temp table ttGL is created and updated as follows:
DEFINE TEMP-TABLE ttGL NO-UNDO
FIELD GLHeader AS LOGICAL Header Record Indicator
FIELD GLCono AS CHARACTER Company No
FIELD GLInterCo AS CHARACTER Company No for Inter Company Posting
FIELD GLCoPref AS CHARACTER Company No Prefix for AR or AP
FIELD GLSeqID AS CHARACTER GL Account
FIELD GLRefno AS CHARACTER Invoice / Ref Number
FIELD GLAccmth AS INTEGER Accounting Month
FIELD GLAudit AS CHARACTER Audit Number
FIELD GLBatch AS CHARACTER Batch No
FIELD GLSource AS CHARACTER Source Code
FIELD GLType AS CHARACTER Transaction Type
FIELD GLProjNo AS INTEGER Project Number
FIELD GLAmount AS DECIMAL Posting Amount
FIELD GLAmountPaid AS DECIMAL Amount Paid
FIELD GLPaid AS LOGICAL G/L Paid / Allocated Indicator
FIELD GLAPContr AS CHARACTER AP Account No
CA 02657303 2009-03-06
-78-
FIELD GLARContr AS CHARACTER AR Account No
FIELD GLROContr AS CHARACTER RO Number
FIELD GLVHContr AS CHARACTER Vehicle Stock No
FIELD VehVinNumber AS CHARACTER Vehicle VIN Number
FIELD GLControl AS CHARACTER Control No
FIELD GLIntRef AS CHARACTER Integration Ref No
FIELD GLDate AS DATE Posting Date
FIELD GLDateCap AS DATE Capture Date
FIELD GLTimeCap AS CHARACTER Capture Time
FIELD GLNarr AS CHARACTER Narrative
FIELD GLDescr AS CHARACTER Transaction Description
FIELD GLUserID AS CHARACTER User ID
FIELD GLTrade AS CHARACTER AR or AP Trade Point
FIELD GLARSeqID AS CHARACTER AR Sequence ID
FIELD GLDtPaid AS LOGICAL AR Paid Indictator
FIELD GLAgeMth AS INTEGER Age Month
FIELD GLOrderNo AS CHARACTER Order No
FIELD GLOrigRef AS CHARACTER Original Ref No
FIELD GLAPSeqID AS CHARACTER AP Sequence ID
FIELD GLctChq AS LOGICAL Cheque Printed
FIELD GLctChqNo AS INTEGER Cheque Number
FIELD GLctMatch AS LOGICAL Matched Transaction
FIELD GLctPaid AS LOGICAL AP Paid Indicator
FIELD GLctQuery AS LOGICAL Query Indicator
FIELD GLctQReas AS CHARACTER Query Reason
FIELD GLArTran AS LOGICAL Always set to Yes to create AR
FIELD GLctReb AS DECIMAL Rebate
FIELD GLTaxType AS CHARACTER Input / Output Tax
FIELD GLTaxCode AS INTEGER Tax Code
FIELD GLOrgCtrl AS CHARACTER Original Control for tax postings
FIELD GLInvAmt AS DECIMAL Invoice Amount for tax postings
FIELD G1TaxGross AS DECIMAL Taxable Amount
FIELD TranType AS CHARACTER Transaction Type O= Original,
A = Adjustment, R = Reversal
FIELD GLBatSeqlD AS CHARACTER. Batch Sequence ID
FIELD GLJobNumber AS INETEGER RO Job Number
FIELD GLLineNumber AS INTEGER RO Detail Line Number
FIELD GLTechNo AS INTEGER RO Technician Number
FIELD GLReceiptNo AS CHARACTER Receipt Number
FIELD GLA11ocID AS DECIMAL Allocation ID
FIELD GLProgram AS CHARACTER Program Name Allocating
FIELD GLInvoice AS LOGICAL Invoice Transaction
FIELD GLNotes AS CHARACTER Transaction Notes
CA 02657303 2009-03-06
-79-
Field Descriptions
GLHeader Indicates where it is a Control record for AP and AR transactions.
Yes or No.
GLCono The Company Number that the posting is to update.
GLInterCo The company number where the posting was created.
GLCoPref The Company Number where the AP or AR accounts are. The best place to
get this is with the shared properties "getAPPrefix" or "getARPrefix".
GLSeqID The GL Account Number or the GL Sequence ID.
GLRefno The transaction Reference Number.
GLAccmth The accounting month which the transaction is being posted into.
This is normally the current accounting month (glcGLControl.AccounMonth)
Or it can be any open accounting month. The table g1mGLAccMonth contains
all the available accounting months that are still open.
GLAudit The current system audit number prefixed by the GL Audit Prefix
(glcGLControl.AuditPrefix +
STRIN G(sycS ysControl. CurrentAuditNo,"999999")).
GLProjNo The Project Number.
GLAmount The Transaction amount as either a debit or a credit.
GLAPContr The AP Account Number on a AP Posting.
GLARContr The AR Account Number on a AR Posting.
GLROContr The Repair Order Number on a RO Posting
GLVehContr The Vehicle Stock Number on a Vehicle Posting
VehVinNumber The Vehicle Vin Number on a Vehicle Posting.
GLDate The Transaction Date
GLDateCap Date the transaction was captured
GLTimeCap The time the transaction was captured HH:MM:SS.
GLNarr Free format transaction narrative.
GLDescr Description of the posting.
GLUserID Users ID of the user doing the posting.
GLTrade The AR or AP Trade Point
CA 02657303 2009-03-06
-80-
GLARSeqID The AR Sequence ID
GLAgeMth The Age Month - 1= Current 2 = 30 days up to 6 = 150 days.
GLOrderNo The Order Number for the transaction. AP Order typically.
GLOrigRef The Original Reference Number in the case of a Credit Note.
GLAPSeqID The AP Sequence ID.
TranType Transaction Type O- Original A - Adjustment R - Reversal.
GLBatSeqlD GL Batch Sequence ID. Only used for Batch Postings.
4. Parts Inventory
The Parts Inventory update program (e.g. the module 410) will update one or
more part records
with one or more transactions. This program does not generate general ledger
transactions, it
updates only the parts inventory records. The transaction supporting the
update is generated by
the updateGL.p procedure.
The Parts Inventory update program will update the parts in the sequence Parts
Sequence ID,
Stocking Group, Movement Category. This is to prevent a "Deadly Embrace" from
occurring in
the event of multiple users updating similar parts in a different sequence of
entry.
The Parts Inventory update program runs the following procedures:
createBranchParts - resident in the applStartParts.p library.
inc/pt/recalcprofile.p - external procedure
The Parts Inventory update program is run with the following syntax:
RUN inc/upd/updatePT.p (INPUT TABLE ttPT,
OUTPUT vlOkay).
IF RETURN-VALUE NE " THEN
RETURN RETURN-VALUE.
IF NOT vlOkay THEN
RETURN 'Error Updating Parts'.
The temp table ttPT is defined in inc/ttPT.i.
The Parts Inventory temp table ttPT requires to be populated with the
following data:
DEFINE TEMP-TABLE ttPT NO-UNDO
FIELD PTCono AS CHARACTER Company No
FIELD PTFran AS CHARACTER Franchise
FIELD PTPartno AS CHARACTER Part Number
FIELD PTSeqID AS CHARACTER Part SeqID
FIELD PTGroup AS INTEGER Stocking Group
CA 02657303 2009-03-06
-81-
FIELD PTWhSa1e AS LOGICAL Wholesale Sale?
FIELD PTSman AS INTEGER Salesman No
FIELD PTSerAdv AS INTEGER Service Advisor
FIELD PTAccno AS CHARACTER Account No
FIELD PTName AS CHARACTER Customer Name
FIELD PTAudit AS CHARACTER Audit No
FIELD PTQtyO AS DECIMAL Quantity Ordered
FIELD PTQtyD AS DECIMAL Quantity Sold
FIELD PTQtyRec AS DECIMAL Quantity Received on a Order
FIELD PTFromBack AS LOGICAL Is this a Backorder Sale
FIELD PTOnBack AS LOGICAL Is a Backorder being created
FIELD PTBckPrio AS INTEGER Back Order Priority 0 Low 9 High
FIELD PTCentOrd AS LOGICAL Is a part requested for Central Order
FIELD PTOrdQty AS DECIMAL Quantity to Order
FIELD PTInvOrd AS LOGICAL Parts Invoiced and Ordered
FIELD PTPslip AS LOGICAL Converting Picking Slip to Invoice?
FIELD PTDate AS DATE Invoice Date
FIELD PTTime AS CHARACTER Invoice Time
FIELD PTAge AS INTEGER Age Code (1 to 6)
FIELD PTRetail AS DECIMAL Retail Price
FIELD PTCost AS DECIMAL Cost Price
FIELD PTDiscAmt AS DECIMAL Discount Amount
FIELD PTValue AS DECIMAL Line Value
FIELD PTRefno AS CHARACTER Invoice or Order No
FIELD PTDocno AS CHARACTER Supplier Invoice No
FIELD PTOriglnv AS CHARACTER Original Invoice No on a Credit Note
FIELD PTOrderNo AS CHARACTER Customer Order No
FIELD PTInvType AS CHARACTER Inv or Order Type
FIELD PTDocType AS CHARACTER Document
FIELD PTOrdStat AS CHARACTER Order Status
FIELD PTFrBO AS INTEGER Qty From Backorder
FIELD PTToBO AS INTEGER Qty Onto Backorder
FIELD PTBackNo AS CHARACTER Backorder Ref No
FIELD PTSaleCode AS CHARACTER User Def Sales Code
FIELD PTDiscCd AS INTEGER Customer Discount Code
FIELD PTServPck AS CHARACTER Service Pack No
FIELD PTCntSeqlD AS CHARACTER Customer Seq ID
FIELD PTUserID AS CHARACTER User ID that created document
FIELD PTGpRange AS CHARACTER GP Range -"*" Means outside
FIELD PTPrinted AS LOGICAL Part printed on a Previous PickingSlip
FIELD PTNewRCost AS DECIMAL New Replacement Cost on Order Release
FIELD PTNewACost AS DECIMAL New Average Cost
FIELD PTNewLCost AS DECIMAL New Last Cost
FIELD PTSugOrd AS LOGICAL Does part come from Suggested Order
FIELD PTBinLoc AS CHARACTER. Bin Location
FIELD PTJobType AS CHARACTER Job Type
FIELD PTRONumber AS CHARACTER RO Number
FIELD PTVendorCode AS CHARACTER Vendor Code
FIELD PTAbnormal AS LOGICAL Abnormal Demand
CA 02657303 2009-03-06
-82-
Field Descriptions
PTCono The Company number in which the transaction is taking place
PTFran The part franchise code. This is either the local or main franchise
code
PTPartNo The Part Number of the part being updated. If the Part Number is used
then the
PTFran field must be populated. An error will be returned if this is not done.
PTSeqID The unique part sequence ID. It this field is populated then it is not
necessary to
populate the PTFran and PTPartNo fields
PTGroup The part's Stocking Group as stored on the Parts Branch table
PTWHSaIe For Parts Invoicing this indicated whether it is a wholesale sale.
This is used for
sales analysis purposes only
PTSMan Parts Salesperson Employee Number. This field is used to record
Customer Back
Orders, Special Order Parts (SOP) and the Parts Detail Transaction
PTSerAdv Service Advisor Employee Number. When requesting a Special Order Part
for a
Repair Order this field is required to be store on the SOP request. This is
used by
the system to track the SOP and to notify the service advisor when the part is
ordered and received into inventory
PTAccNo The Account Number being charged on a Parts Invoice. This is used to
record on
SOP requests and on the part detail transaction
PTName The Customer Name. This is used to record on SOP requests from parts
invoicing
PTAudit The current system audit number prefixed by the Parts Audit Prefix
(ptcPTControl.AuditPrefix +
STRING(sycS ysControl. CurrentAuditNo,"999999"))
PTQyO Quantity Ordered. On a Parts Invoice, this would be the part quantity
required by
the customer. This is not necessarily the quantity supplied (see PTQtyD). This
field is used to update demand as well as lost sales.
When creating an Order, this field contains the quantity being ordered.
PTQtyD Quantity Supplied to a Customer on a Parts Invoice. When creating a
pickikg
ticket, this will be used to update the Reserved Inventory. When converting a
Picking Ticket to an Invoice, this will reduce the Reserved Inventory. When
creating a Invoice, this will reduce the On Hand Inventory, update the
Quantity
Last Sold, update the Sales History quantity and value.
When performing an Inventory Count, this field contains the Inventory Count
quantity.
PTQtyRec When releasing an Order, this field containg the quantity being
received into
inventory
CA 02657303 2009-03-06
-83-
PTFromBack When supplying a part previously backordered for a customer, this
field contains
the part quantity being supplied to the customer
PTOnBack When back ordereing a part for a customer this field contains the
quanty of the
part to back order for the customer. A backorder record will be created
(pttCustBackOrd)
PTBckPrio The back order priority from 0 to 9 where 0 is the highest
PTCentOrd When doing a parts invoice and a SOP part is being processed, this
field is set to
"Yes". A SOP record is then created for this part (pttReqOrder). If the part
is
actually invoice (see PTInvOrd) then the status of the SOP is set to "Accept".
If it
is merely an AOP request, the status is set to "Request".
PTOrdQty The actual quantity requested for a SOP.
PTInvOrd If a SOP is invoiced on a parts invoice then this field is set to
"Yes". This will
cause the status on the SOP record to be set to "Accept"
PTPslip When coverting a picking ticket to an invoice, this field is set to
"Yes"
PTDate This contains the transaction date. This is required for all
transactions
PTTime This contains the transaction time. This is required for all
transactions.
PTAge When producing a Credit Note, this field contains the age of the
original invoice
in number of months from the current month where 1 is the current month, 2 is
current month - 1
PTRetail When creating an Invoice thisis the selling price of the part
PTCost The cost price of the part for all transactions
PTDiscAmt When creating an Invoice any discount value will be in the field
PTValue When creating an Invoice, this field contains the extended line value.
Quantity *
Selling Price - Discount. This is used for updating all sales values and the
calculation of all Gross values
PTRefNo The reference number for the transaction such as an Invoice Number or
a Order
Number. This field is required for all transactions
PTDocNo Vendor Invoice number for a parts order
PTOriglnv When producing a Parts Credit Note, this field contains the original
invoice
number. This is used to ensure that the cost used for crediting the parts is
the same
cost as was originally used when invoicing the part.
CA 02657303 2009-03-06
-84-
PTOrderNo When producing a parts invoice, this field contains the customer
purchase order
number. This is used as a reference if a back order part record is created.
PTInvType The type of Parts Invoice being created. Valid values are:
CSH - Customer Cash Sale
CST - Customer Account Sale
INT - Internal Sale
VEH - Vehicle Stock Issue
SRV - Service RO Issue
TRF - Inter Branch Transfer
The type of Parts Order being created. Valid values are:
STK - Stock Order (ex OEM)
URG - Urgent / Daily Order (ex OEM)
BYO - Buyout order (non OEM)
SUB - Sublet Order (non OEM)
PTDocType Document Type. Valid values are:
INV - Invoice
CRN - Credit Note
EST - Quotation / Estimate
PCK - Picking Ticket
TRF - Inter Branch Transfer
ORD - Parts Order
CNT - Parts Stock Count
PTOrdStat Parts Order Status. Valid values are:
Print - Printed Order
Partial - Partially Released Order
Release - Released Order
Vendor - Vendor Invoice Processed
PTFrBO The part quantity received from a vendor from a previous back order
PTToBO The part quantity being place onto back order by a vendor
PTBackNo The back order reference number
PTSaleCode User Defined Sales Analysis Code for Parts Invoicing. This will
update the table
pttSalesAnalysis
PTDiscCd Customer Discount code on a parts invoice
PTServPck Not Currently Used
PTCntSeqlD Unique Customer Sequence ID on a Parts Invoice
PTUserID User ID of the user creating the transaction
CA 02657303 2009-03-06
-85-
PTGpRange If a part is moutside the minimum or maximum GP% range, this
contains an
PTPrinted On a Picking Ticket, If a part was previously printed on a the same
tickey, this
would be set to `Yes'. Any new part added to an exiting Ticket would be set to
"No'
PTNewRCost New Replacement Cost on a Parts Order. This value is calculated in
the
partOrderUpdate.p program
PTNewACost New Average Cost on a Parts Order. This value is calculated in the
partOrderUpdate.p program
PTNewLCost New Last Cost on a Parts Order. This value is calculated in the
partOrderUpdate.p
program
PTSugOrd On a Parts Order, if the part being ordered was from the Suggested
order, then
this field is set to `Yes'. If the part being ordered was not on the Suggested
order
then this field is set to `No'.
PTBinLoc If this field is populated with a Bin Location the current bin
location will be
replaced with this value
PTJobType On a Parts Invoice, the Job Type that the part is being issued to
PTRONumber On a Parts Invoice the RO Number of the repair order that the part
is being issued
to
PTVendor On a Part Order, the Vendor Code
PTAbnormal Set to Yes if the invoice in for abnormal demand. This will adjust
the demand
by the quantity delivered
CA 02657303 2009-03-06
-86-
5. Vehicle Inventory
The Vehicle Inventory update program (e.g. module 412) will update one or more
vehicle
records with one or more transactions. This program does not generate general
ledger
transactions, it updates only the vehicle balances and other data such as
dates and ageing. The
transaction supporting the update is generated by the updateGL.p procedure.
The Vehicle Update program does not run any other procedures.
The Vehicle update program is run with the following syntax:
RUN inc/upd/updateVH.p (INPUT TABLE ttVH,
OUTPUT vlOkay).
IF RETURN-VALUE NE " THEN
RETURN RETURN-VALUE.
IF NOT vlOkay THEN
RETURN 'Error Updating Vehicles'.
The temp tables ttAR and ttARTrade are defined in inc/ttAR.i and
inc/ttARTrade.i.
The Vehicle temp table ttVH requires to be populated with the following data:
DEFINE TEMP-TABLE ttVH NO-UNDO
FIELD VHCono AS CHARACTER Company No
FIELD VHStock AS CHARACTER Stock No
FIELD VHType AS CHARACTER Posting Type
FIELD VHQte AS LOGICAL Quoted item
FIELD VHSource AS CHARACTER Source Code
FIELD VHRefno AS CHARACTER Reference / Invoice No
FIELD vhtVehicleOrder AS CHARACTER Order No
FIELD VHACode AS INTEGER Accessory Code
FIELD VHDate AS DATE Transaction Date
FIELD VHTimeCap AS CHARACTER Time Captured
FIELD VHAmount AS DECIMAL Posting Amount
FIELD VHRetail AS DECIMAL Accessory Retail
FIELD VHACost AS LOGICAL Accessory Cost
FIELD VHCRate AS DECIMAL Currency Rate
FIELD VHF1tClm AS CHARACTER Fleet Claim No
FIELD VHFItAmt AS DECIMAL Fleet Claim Amount
FIELD VHNarr AS CHARACTER Narrative
FIELD VHAudit AS CHARACTER Audit Number
FIELD VHUserID AS CHARACTER User ID
FIELD VHSaleType AS CHARACTER Sale Type
FIELD VHDeaINo AS CHARACTER Deal No
FIELD VHStockOrder AS CHARACTER. O= On Order S = Stock
FIELD UnwindDeal AS LOGICAL Unwind or Reverse
FIELD VHFPNo AS INTEGER Floor Plan Number
CA 02657303 2009-03-06
-87-
Field Descriptions
VHCono The Company Number in which the transaction is taking place. This must
be the
same company in which the vehicle stock record resides
VHStockNo The vehicle stock number
VHType Transaction Type. The following transaction types are valid
Order - Order a Vehicle
OrdGen - Generated Sublet Order
Posting - Posting (eg Journal) to a vehicle
Price - Cost Price Adjustment
Floorplan - Floorpaln Payment
NewFloorplan - Floorplan an existing vehicle
Stock - Stock a vehicle
Service - RO Invoice to a Vehicle
Invoice - Vehicle Sales Invoice
CreditNote - Vehicle Sales Credit Note (Reverse Invoice)
VHQte When creating a Sublet Order or an RO against a vehicle this would be
set to
`Yes' as would flag the vehicle transaction as a "Quoted Price". Once the
transaction is posted (vendor invoice, or close RO) then this would be set to
"No"
VHSource Transaction Source Code
VHRefNo Posting reference or Invoice / Credit note number
vhtVehicleOrder Order Number for a Sublet Order
VHACode Accessory Code - not currently used
VHACost Accessory Cost - not currently used
VHRetail Accessory Retail - not currently used
VHDate Transaction Date
VHTimeCap Transaction Time captured
VHAmount Transaction amount
VHCRate Currency Rate - not currently used
VHF1tClm Fleet Claim Number - not currently used
VHFItAmt Fleet Claim Amount - not currently used
VHNarr Transaction Narative
VHAudit The current system audit number prefixed by the Vehicles Audit Prefix
I
CA 02657303 2009-03-06
-88-
(vhcControll.AuditPrefix + STRING(sycSysControl.CurrentAuditNo,"999999"))
VHUserID The user ID of the user processing the transaction
VHSaleType Vehicle Sale Type. Valid values are:
Lease - Lease Sale
Finance - Finance Sale
Cash - Cash Sale
Dealer - Dealer swap / Wholesale Sale
VHDea1No Deal Number
VHStockOrder Indicates whether a vehicle is being Stocked or Ordered. Values
are S or 0
UnwindDeal Y indicates the deal is being completely unwound. N indicates the
deal is being
reversed for adjustments
VHFPNo Floorplan Number. The Floorplan Account number being used from 1 to 99.
This
value must represent a valid record in the vhcFloorplanAcc table
Miscellaneous Uadate Programs
The miscellaneous update programs of the engines 350, 400 perform simple
normally single
transactions. These are used for simple transactions like changing the
category code of a vehicle
where all that needs to happen is the vehicle record is updated with the new
category code and
general ledger transactions are generated to move the vehicle value from one
general ledger
account 402 to another general ledger account 402 , if the accounts 402 for
the old and new
catgory are different.
The programs do not perform complex transactions and are designed to perform
mundane
programming tasks efficiently and accurately. They need to reside on the
server as these
programs read and write database tables.
The miscellaneous update programs can be run directly on the server or they
can be run as a Web
Service.
CA 02657303 2009-03-06
-89-
changeStockNo
The changeStockNo procedure is used to change the stock number of a vehicle
stock unit. The
following parameters are passed to the procedure:
INPUT pcCono Company Number where the stock record resides
INPUT pcNewStockNo The new stock number
INPUT pcOldStockNo The old stock number
INPUT pclnvoice The original Vendor Invoice number
INPUT pcUser The User ID of the user processing the transaction
It is the reposnsibility of the calling program to ensure that the old stock
number is a valid stock
number and the new stock number is not an existing stock number. The
changeStockNo
procedure will update all tables where a stock number is stored from the old
stock number to the
new stock number.
The following tables will be updated:
vhtVehicleTran Vehicle Transaction
gltBatchDetail General Ledger Batch Detail
g1tGLTransac General Ledger Transactions
vhmTruckDetail Truck Detail
vhtAccessSold Accessories Sold Detail
vhtDealHeader Deal Header Records
vhtDealDetail Deal Detail Records
vhtRepTransac Vehicle Sales Person Transactions
vhtTradeinTable Vehicle Tradein Records
vhtVehicleRental Vehicle Rental Records
svtJobHeader Repair Order Header Records
The procedure will also create a new vehicle transaction record
(vhtVehicleTransac) with the
narrative Stock Number Changed From ABCDEF To GHIJKL.
chanuVehCatesory
The changeVehCategory procedure is used when the vehicle category needs to be
changed. The
following parameters are passed to the procedure:
INPUT hbuffdata# Handle of the vehicle master record before the change
INPUT hbuffclie# Handle of the vehicle master record after the change
OUTPUT pcMess Any Error Messages
OUTPUT pcVehType Vehicle Type of new category
When this procedure is run the following updates will take place:
1. The vehicle category code on the vehicle master will be updated.
2. Any vehicle deal detail records (vhtDealDetail) where the stock number is
being used
will be updated with the new category code.
CA 02657303 2009-03-06
-90-
3. If the inventory GL accounts on the new category code is different that the
inventory GL
accounts on the old category code, the procedure will generated all the
necessary GL
entries to move the vehicle from the old GL account to the new GL account.
These GL
entries will be done for the inventory cost, any reconditioning cost as well
as any unit
accounts and statistical accounts. There entries will be posted using the last
open GL
Accounting Month.
4. The Inventory value will be moved from theold to the new vehicle category
records
(vhmVehCategory).
5. A new vehicle transaction will be generated recording the fact that the
vehicle category
was changed.
6. The General Ledger will be updated in transactions were generated by the
change.
7. The original and reversing entries in the GL will be allocated to each
other to clear them
from GL schedules.
8. The pcVehType output parameter will contain the new category vehicle type.
9. If any errors occur, the error message will be in the pcMess output
parameter and the
transaction will be undone.
transferFloorplan
The transferFloorplan procedure is run when the Floorplan account on a vehicle
needs to be
changed. The following parameters are passed to the procedure:
INPUT hbuffdata# Handle of the vehicle master record before the change
INPUT hbuffclie# Handle of the vehicle master record after the change
OUTPUT pcMess Any Error Messages
When this procedure is run the following updates will take place:
1. Create a GL entry to debit the old Floorplan account with the Floorplan
Owing amount
2. Create a GL entry to credit the new Floorplan account with the Floorplan
Owing amount
3. Create a Vehicle transaction indicating the floorplan account change
4. Update the General Ledger with the entries generated
5. If any error occur they will be recorded in the pcMess output parameter and
the
transaction will be undone.
updateBatchDetail
The updateBatchDetail procedure will create a new batch detail line or update
an existing batch
detail line. The following parameters are passed to the procedure:
INPUT pcCono The Company number where the detail line is being created
INPUT cmode# Mode A - Add U - Update
INPUT hbuffclie# Handle to the updated / new batch record
INPUT hbuffdata# Handle to the old batch record (update)
INPUT pcOldPost GL Sequence ID of the old transaction when updating
When this procedure is run the following updates will take place:
CA 02657303 2009-03-06
-91-
1. If pcOldPost contains a value (this would happen if an already posted
transaction is being
changed) then the original leg of the transaction is reversed and the new leg
created. The
GL will be updated with these transactions.
2. If the mode is Add (A) or Copy (C) a new batch detail record is created.
3. If the mode is Update (U) the existing batch detail record is updated.
4. If a Purchase Order is being processed the order number is validated
depending on the
posting type for either a AP Sublet order or a Vehicle Sublet order.
updateCheck
The updateCheck procedure will process checks according to the parameters
passed. The
following parameters are passed to the procedure:
INPUT pcCoNo The Company number in which the check is being processed
INPUT pcCheckNo The check number
INPUT pdAmount The check amount
INPUT pcAction Process action code -
CheckRun - Process Check run for AP's
Void - Void the check
Relssue - Re Issue a check
INPUT pcCheckType Check Type -
V - Vehicle Payment
F - Floorplan Payment
G - GL check
A - AP Payment
INPUT pcUserlD User ID posting the transaction
OUTPUT pcNewCheck New check number in the case of a reissued check
OUTPUT pcMess Any error messages
When this procedure is run the following updates will take place:
CheckRun
1. For each entry in the aprCheckTemp table the procedure create create a GL
posting Batch
Header record and well as 2 batch detail records, one for the debit entry to
the AP accont
and one for the credit entry to the bank account.
2. The procedure will create create a GL entry for each check debiting the AP
and crediting
the bank account.
3. The AP accounts will be updated with the generated entries.
4. The GL account will be updated with the generated entries.
5. Any error messages will be returned to the calling program in the pcMess
parameter and
the transaction will be undone.
Void
1. The procedure will create a new aprCheckTemp record for the voiced check
copying all
the inforrnation from the original check record
2. The original entries are then reversed exactly as they were originally
posted but the the
sight reversed on the new transactions and new GL entries are generated. The
procedure
will also allocated all matching postings in both the original transaction as
well as the
nrely generated postings to ensure that they do not appear on the GL schedules
as
amounts due.
CA 02657303 2009-03-06
-92-
3. The AP accounts or Vehicle records will be with be updated with the
generated entries.
4. The GL accounts will be updated with the generated entries.
5. Any error messages will be retuned to the calling program in the pcMess
parameter and
the transaction will be undone.
Relssue
1. The procedure will validate that the check can be reissued by ensuring that
a subsequent
payment has not been made after the original check was voided.
2. The original entries that were generated by the original check are then
generated.
3. The AP account or Vehicle record is then updated.
4. The General ledger accounts are updated.
5. Any error messages will be retuned to the calling program in the pcMess
parameter and
the transaction will be undone.
pcMess error return parameter
The following messages could be returned in the error parameter:
1. Not Updated - Invalid Input. Company No = XX Check No = YYY Amount = 999
Action = XXX - This error would occur if all the input is not valid.
2. Allocate a Bank to All Checks - If all checks to be processed are not
allocated to a Bank
Account.
3. Original Transaction Not Available - If a check is being reissued and one
or more of the
original transactions that the original check paid is no longer available as
an unpaid
transaction.
4. Any system errors will return "Error - " plus a description of the error.
updateFloorplan
The updateFloorplan procedure is used to process floorplan payments. The
following parameters
are passed to the procedure:
INPUT pcCono Company number where the payments are processed
INPUT pcBankldentifier The identifier of the Bank issueing the check
INPUT pcAccount The Bank Account number issueing the check
INPUT pcType Payment method - C = Check E = EFT
INPUT pcPayee Check Payee Name
INPUT pdPayTotal Check Amount (Total of all payments)
INPUT pcRefNo For an EFT a reference number. For a check, the check
number will be ised as the reference number
INPUT pcDbAPSeqID The AP Account Sequence ID
INPUT piAccMonth The Accounting Month
INPUT phVehicleTTable The Handle of the temp table containing all the
floorplan
payments for each vehicle stock record
OUTPUT pcMess Error Message parameter
When this procedure is run the following updates will take place:
CA 02657303 2009-03-06
-93-
1. If payment is been made ny check the next check number for the selected
bank and bank
account is obtained.
2. The procedure will then gereate a GL transaction for each vehicle in the
temp table for
which a floorplan payment has been processed where the floorplan account is
debited
wiyh the payment amount
3. Each vehicle stock record will have the floorplan owing amount reduced by
the floorplan
payment amount for the vehicle
4. A credit entry is generated for the bank account for the total amount of
all the payments
5. If payment is being made with a check, a check wil be created for the total
amount of all
the floorplan payments
6. The procedure will then run the generalledger update program to process the
general
ledger entries generated
7. If an error occurs, the error message will be returned to the calling
procedure using the
pcMess error parameter and the transaction will be undone
updatelnternalOrder
The updatelnternalOrder procedure is used to process WEO's in the form of AP
purchase orders
in internal RO's for a vehicle deal. The following parameters are passed to
the procedure:
INPUT pcCono The company number in which the transaction is generated
INPUT pcOrder The internal Order number of a previously created order. This
order is created in the gItGLOrder table
OUTPUT pcMess Any error messages to be returned to the calling procedure
When this procedure is run the following updates will take place for an
Internal order:
1. The procedure will get the next available RO Number from the getDocno.p
procedure
2. A repair order is created using the Service Advisor as defined in the
vhcVehControl
record for the company. The status of the RO (Booking or WIP) is determined by
the
default setting in the vhcVehControl record for the company
3. A RO detail labor line will be created using the details stored on the
order record
4. If there are any errors they will be retuned to the calling program using
the pcMess error
parameter and the transaction will be undone
When the procedure is run the following updates will take place for a Vehicle
Order (AP):
1. A transaction is createdfor the Vehicle stock record with a quoted price as
stored on the
order
2. GL entries are generated for the Vehicle Inventory account for the amount
on the order as
a debit entry and the Reconditioning Clearing account for the same amount as a
credit
entry
3. The Vehicle Record is updated with the transaction
4. The General Ledger is updated with the generated entries
5. If there are any errors they will be retuned to the calling program using
the pcMess error
parameter and the transaction will be undone
CA 02657303 2009-03-06
-94-
uudateLostSale
The updateLostSale procedure is used to process Parts Lost Sales as entered in
the Parts Invoice
Program. The following parameters are passed to the procedure:
INPUT pcCono Company number in which the lost sale is entered
INPUT pcSeqlD Part unique Sequence ID
INPUT piQty Lost Sale Quantity
INPUT piRepNumber Parts Salesperson employee number
INPUT pcUserlD User ID of the user processing the lost sale
When this procedure is run the following updates will take:
1. The demand adjusted field for the current month is updated by the lost sale
quantity on
the pttSalesDemand record for the part in the pcSeqlD input parameter
2. A transaction for the part is created that will reflect the details of the
lost sale entered
3. The parts daily sales record (pttDailySales) is updatged with the lost sale
quantity
System Update Programs
The System Update Programs of the engines 350, 400 are procedures that do
complex updates
for complete functions such as producing a parts invoice, costing a repair
order, invoicing a
vehicle or creating a parts order. All the necessary business logic is built
into these programs.
They in turn will run one or more of the individual table update programs
described in the first
section of this document.
The System Update programs can be run directly on the DMS server, or can be
run as a Web
Service. These programs may reside on the server because they need to read and
write database
tables. Each program is a complete entity, and needs to be run once only to
perform a complete
update.
CA 02657303 2009-03-06
-95-
PartInvoiceUadate
The PartlnvoiceUpdate procedure is used to process all types of parts
invoices. The parts invoice
is prepared by creating one invoice header record (ptrInvoiceHead) and one or
more invoice
detail lines (ptrlnvoicePart). A invoice can also contain one or more
miscellaneous lines
(ptrlnvoiceMisc). Once these records have been created and populated will all
the required data,
the PartlnvoiceUpdate procedure can be run in order to complete the invoice
process.
The procedure will do all the updates necessary to complete the parts invoice
successfully. The
procedure is run for every line added to the parts invoice. If the pcPrint
parameter is not set to
(P)rint then the procedure will only calculate the part invoice totals. If the
procedure is run with
the pcPrint parameter set to (P)rint then the parts invoice will be processed
to completion.
The PartlnvoiceUpdate procedure is run with the following parameters:
INPUT pcCono The company number in which the invoice is being created
INPUT pcSeqlD The Sequence ID of the ptrlnvoiceHead record
INPUT pcAction Action performed - (A)dd (C)opy (U)pdate (D)elete
INPUT plChangeDoc Set to Yes when converting an existing Picking ticket (PCK)
or
Estimate (EST) to an Invoice (INV)
INPUT pcDocType Document Type -
INV Invoice
CRN Credit Note
TRF Inter Branch Transfer
EST Estimate
PCK Picking Ticket
INPUT pcPrint (P)rint document - this is the final step when creating an
invoice
INPUT pcPickNumber Picking ticket number
OUTPUT pcDocno Document Number of Invoice Created
OUTPUT pcMess Error messages returned to calling procedure
CA 02657303 2009-03-06
-96-
Delete Invoice Detail and reset reserved
pcAction = D inventory
I
Recalculate Return No Error to
pcPrint NE P Invoice Totals Calling Procedure
Get Document Number
Process Header Details
Fp-,(,ess Parts Line Detail
Fp Misc Line Detail
Update Header Record
Update Parts Records
RO Issue Update Repair Order
Update Parts Sales Rep and
Parts DOC
Update Customer Sales
Update General Ledger
Credit Note Do Allocation of entries
Create Print Document
When this procedure is run the following updates will take place:
1. If the pcAction parameter contains a (D)elete then the procedure will
delete the invoice
lines as well as the invoice header record. Each part on the invoice will have
the reserved
CA 02657303 2009-03-06
-97-
inventory field reduced by the quantity that was on the invoice line, and
control will be
retuned to the calling procedure.
2. If the pcPrint parameter does not contain a (P)rint then the invoice totals
will be
recalculated and control will be returned to the calling procedure.
3. The procedure will get the next document number by calling the getDocno.p
program.
4. The header details entries are generated according to the invoice type:
a. CSH (cash sale) or INT (internal Sale) - a GL entry (ttGL) will be created
for the
GL account for Cash Sale Control or the selected GL account for a debit amount
of the invoice total
b. CST (AR Account) or B2B (AR Account) - a GL entry (ttGL) will be created
for
the AR Control account of the AR Account being posted to for a debit amount of
the invoice total. An AR update record (ttAR) will also be ceated for the
total
invoice amount.
c. WEO (We Owe) - a GL entry will be created for the AP Control account of the
AP Account being posted to for the total invoice amount. An AP update record
(ttAP) will also be created for the total invoice amount.
d. SRV (RO Isuue) - a GL entry will be created for the Parts WIP GL account
for
the total Cost value of the invoice. A RO update record (ttROP) will be
created
for the total invoice amount.
e. VEH (Vehicle Issue) - a GL entry will be created for the total invoice
amount.
This entry will be posted to an account dependent of the type of vehicle being
posted to:
i. Stocked Vehicle - Vehicle Inventory Account
ii. On Order Vehcicle - Vehicle Inventory WIP Account
iii. Sold Vehicle - Vehicle After Sales GL or COS
iv. Potential Tradein - Tradein Reconditioning Clearing A/C
A Vehicle update record (ttVH) will be cfreated for the total invoice amount
5. The parts line details ure then updated for each entry in the
ptrInvoicePart table as
follows:
a. If the part being processed is a wholesale compensation or a fleet
compensation
part and the AR in the invoice header is flagged as a wholesale or fleet
customer
the procedure will:
i. Create a wholesale compensation claim record (ptrWHComp) for the part.
The claim amount will be for the wholesale compensation or fleet price
stored on the part.
ii. Create a debit entry for the claim amount to the AR control account for
the
Wholesale Compenation AR account as stored on the Parts Vendor Master
(pttVendorFile)
iii. Create a Credit entry for the claim amount to the Parts Wholesale
Compensation income account as stored on the Parts Vendor Master
(pttVendorFile)
iv. Create an AR update record (ttAR) for the Wholesale Compensation AR
account
b. The Parts Update record (ttPT) is created to update the part
CA 02657303 2009-03-06
-98-
c. If the document type is not a Picking ticket (PCK) or a Estimate (EST) then
the
GL entries for each part line is generated
i. If the invoice is taxable, create a GL entry (ttGL) to credit the GL
Control
account for the AP account as defined on the Tax Table record. Create an
AP Update record (ttAP) for the tax amount.
ii. Create a GL entry (ttGL) to credit the Parts Inventory GL account with the
cost value of the part (cost price * quantity delivered).
iii. Create a GL entry (ttGL) to debit the Parts Inventory COS account with
the cost value of the part.
iv. Create a GL entry (ttGL) to credit the Parts Inventory Sales account with
the sales value of the part (Sales Price * quantity delivered).
v. Create a GL entry (ttGL) to debit the Parts Inventory Discount account for
the discount value of the part.
vi. If a credit note is being processed to a RO and the price has changed
since
the original invoice was processed two entries are generated to the GL, the
Parts Inventory account is posted to with the difference in price, and the
Parts Writeup Resrve account is posted to with the opposite entry. The
reason this is done is because the credit entry to the Parts Work in Process
account must be at the original cost of the part.
6. For each miscellaneous item on the parts invoice the system will generate a
credit entry
(ttGL) to the GL account as stored on the miscellaneous item table
(ptcMiscSale) for the
miscellaneous amount.
7. The procedure will then run all the header update programs (updateAP,
updateAR,
updateVH) which will update any header transactions that were generated.
8. The Parts update program (updatePT) is then run.
9. If the parts invoice is a RO issue the the procedure will create a RO
update record
(ttROP) for each part on the invoice and run the RO update program (updateROP)
10. If the parts invoice is not a RO issue the procedure will update the Parts
Sales Person
table (pttPartsRep) as well as the Parts DOC totals (sytDocTotals).
11. The procedure will update the general ledger with all the entries
generated (updateGL)
12. If a credit note is being processed, the procedure will allocate the
credit noteentries to the
original invoice entries so they they do not appear as outsanding items on the
general
ledger schedules
13. The procedure will create the parts invoice print document (prtDocHeader
and
prtDocDetail) and complete the update.
14. If any errors occur, they will be returned to the calling procedure in the
error parameter
pcMess and the transaction will be undone.
PartOrderUpdate
CA 02657303 2009-03-06
-99-
The PartOrderUpdate procedure is used to process all types of parts orders.
The parts order is
prepared by creating one order header record (pttOrderControl) and one or more
invoice detail
lines (pttOrderLine). Once these records have been created and populated will
all the required
data, the PartOrderUpdate procedure can be run in order to complete the order
process.
The procedure will do all the updates necessary to complete the parts order
process successfully.
The procedure is run for every stage of the order which would be:
Print the Order
Release the order (partial or full release)
Process the Vendor Invoice
These stages can be run individually or combined into a single process.
The PartOrderUpdate procedure is run with the following parameters:
INPUT cmode# (A)dd (C)opy (U)pdate (D)elete
INPUT hbuffclie# Buffer of the Orderf Control table (pttOrderControl)
INPUT pcShipper OEM Shipper number
INPUT vlCloseOrder Set to Yes if an unconditional close of the order is
required. This
will cause the procedure to run all the processing for the order up
to and including the Vendor Invoice stage
INPUT plTransmit Set to Yes if the order needs to be transmitted to the OEM
INPUT vcDocType If a parts invoice is being generated for parts that are on
the order
when the order is released this contains the type of invoice to
create - (INV) Invoice (PCK) Picking Ticket
INPUT piSalesMan The Parts Sales Person in whose name the parts invoice will
be
Created
CA 02657303 2009-03-06
-100-
New Order Get Document Number
Create Print Tables
Print or All Print Order Update On Order Quantities
Update On Hand Quantities
Generate General Ledger Entries
Release or All Release Order Generate Revaluation Entries
Update Parts
Update General Ledger
Gererate AP Update Record
Generate General Ledger Entries
Vendor or All Process Vendor Invoice Generate Revaluation Entries
Update AP
Update General Ledger
Parts Invoice Parts Invoice or Pick Ticket 1111 Run PartlnvoiceUpdate Program
Transmit Order Generate Tranmission File Run Order Transmit Program
Return No Error to the
Calling Procedure
When this procedure is run the following updates will take place:
CA 02657303 2009-03-06
- 101 -
1. If a new order is being created the procedure will get the next document
number by
running the getDocno.p procedure.
2. If an Order is being printed the procedure will
a. Create the print document by createing one prtDocHeader record and one
prtDocDetail record for each line on the order.
b. If any parts are being ordered that have not been previously stocked, the
required
parts branch records are created.
c. The parts update records (ttPT) are generated for each line.
d. If the order line was generated from a SOP request, the SOP request
(pttReqOrder) record is updated as Ordered. If the SOP was for a customer, a
note
is gereated against the customer record recording the order detail and any
previously geberated customer activity is updated as completed.
e. If the order has been generated by a suggested order, that line on the
suggested
order is updated as Ordered.
f. The updatePT procedure is run to update the parts records with the ttPT
file
generated.
3. If an order is being released or partially released then for each parts
order line the
procedure will
a. If a Parts Return is being processed, the procedure will update the status
of any
SMR (suggested material return) record for this part to Returned.
b. If the order being released was generated by a suggested order, the
procedure will
update the status of the suggested order record for the part to Loaded
c. The procedure will generate the Parts Update Record (ttPT). If any prices
have
changed existing inventory will be revalued at the latest cost.
d. If the part being released was orderd on a SOP request, the procedure will
update
the status of the SOP as Received and a if the part was ordered for a
customer, a
Note will be generated on the Customer record.
e. The following entries will be generated to update the general ledger
i. Debit Parts Inventory with the cost value being released
ii. Credit Parts Receipts Suspense with the cost value being released
iii. Credit / Debit Parts Inventory Adjustment with any inventory revaluation
amount.
f. The updatePT procedure is run to update the parts records with the ttPT
file
generated.
g. The updateGL procedure is run to update the General Ledger with the ttGL
file
generated.
h. The order totals are recalculated taking into account any partially
released parts
on the order.
4. If an order is being processed with the Vendor Invoice then for each Vendor
Invoice that
has been entered for the order, the procedure will
a. Generated an AP Update Record (ttAP) with the invoice detail
b. Generate a GL entry (ttGL) to the AP Control account in the general ledger
with a
credit amount of the invoice total
c. Generate a GL entry (ttGL) to the Parts Receipts Suspense account in the
general
ledget for a debit amount equal to the original credit amount that was
processed
when the order was released
CA 02657303 2009-03-06
- 102 -
d. If there are any other charges such as shipping on the vendor invoice,
there will be
debited to the GL expense account entered with the other charges
e. If applicable, generate a Parts Inventory Revaluation entry if the Vendor
Invoice
is for a different value than what was processed when the parts were released
into
inventory
f. Update the Vendor Master table (pttVendorFile) for the Vendor with
cumulative
Purchases values. If the order is a stock order (STK) then the returns value
is also
calculated if the return % has been set up on the vendor record
g. If the order contains Sublets parts that are being invoiced to a Repair
Order (RO)
then the procedure will do the following updates
i. For all sublets that are flagged as labor lines, the procedure will create
a
Sublet Line (svtJobDetail) on the RO Job Header record (svtJobHeader).
GL entries will be gereated to debit Sublets Work in Process and credir the
Parts Receipts Suspense accounts
h. The procedure will then run the updateAP procedure to update all entries
generated in the ttAP file
i. The procedure with then run thenupdatePT procedure to update parts for all
entries generated in the ttPT file
j. The procedure will then run the updateGL procedure to update all entries
generated in the ttGL file
k. If the GL entries generated to the Parts Receipt Suspense account by both
the
Order Release process and the Vendor Invoice process balance, they are flagged
as allocated so that they do not appear as outstanding amounts on the GL
Schedules
5. If there are parts on the order that are to be issued to a RO via a parts
picking ticket or a
parts invoice then the procedure will do the following
a. For each order line for a part that has been allocated to a RO the
procedure will
create one Part Invoice Header record (ptrlnvoiceHead) and one Part Invoice
Detail record (ptrlnvoiceLine) per RO
b. The procedure will then run the PartInvoiceUpdate procedure where the part
Invoice or Pickikg Ticket will be generated, and all the inventory, work in
process
and general ledger entries are generated
6. If the order is to be transmitted to the OEM the procedure will
a. Generate the order transmission file
b. Run the StarXML procedure which will generate a STAR XML BOD and send
the order to the OEM using Sonic ESB
7. If any errors occur during the PartOrderUpdate procedure, the entire
transaction is
undone and control is returned to the calling procdure with the error message.
CA 02657303 2009-03-06
-103-
ReceintUudates
The ReceiptUpdates procedure is used to process all types of receipts. The
receipt is prepared by
creating a temp table (ttRec) for the receipt and in the case of a recipts for
an AR payment, the
temp table ttAPARAlloc is also created.
The ReceiptUpdates procedure is run with the following parameters:
INPUT ttRec Receipt Temp Table
INPUT ttAPARA11oc AR Allocations in the receipt
OUTPUT pcReceiptRet Receipt Number generated
CA 02657303 2009-03-06
-104 -
Get Next Receipt Number
For each AR Transaction that was selected
AR Receipt generated a opposite Debit entry to the AP
Cnntml C;I. arn.nnnt
Mark the Original Cash Transaction as
Cash Receipt allocated. Generate the Debit GL entry to
thP recnex tivr f:ach f:1Parino A/C'.
Generate up to 8 GL Credit entries to
each of the payment methods selected
Generate Write Off GL Entry is there
is a write off amount
For each AR transaction selected set the
AR Receipt transaction to allocated. Generate AR
nnriatP rPCnrtl
Run the updateAR procedure
Run the updateGL procedure
Run the create print document
procedure
Return No Error to the Calling
Procedure
When this procedure is run the following updates will take place:
1. The procedure will get the next receipt number by running the procedure
getDocno.p
I
CA 02657303 2009-03-06
- 105 -
2. If the receipt is being processed to an AR account the procedure will
generate a reversing
GL transactions (ttGL) for each AR transaction that has been selected for
payment. The
entries will post to the AR Control account in the general ledger
3. If the receipts is for a cash sale, the procedure will mark the original
transactions for the
cash sale as allocated so that they do not appear on the GL schedules as
outstanding
amounts
4. Depending on the number of payment methods selected, the procedure will
generate up to
8 credit general ledger entries (ttGL) to the GL accounts linked to the
payment methods
5. When the receipt is for an AR account, the AR transactions being recipted
are marked as
allocated so that they will not appear on the GL schedules as outstanding. The
AR update
record (ttAR) is also created
6. The procedure will run the updateAR procedure to update the entry generated
in the ttAR
table
7. The procedure will run the updateGL procedure to update the entry generated
in the ttGL
table
8. The procedure will create the print document tables, one prtDocHeader
record the the
document heading and all the required prtDocDetail entries for the receipt
detail
9. If any errors occur during the update, the error will be returned to the
calling procedure
and the transaction will be undone.
10. The procedure returns the Receipt number of the document just created to
the calling
procedure
CA 02657303 2009-03-06
- 106 -
UpdatePostin2s
The UpdatePosting procedure is used to process all types of manual postings.
The posting is
created by creating a posting header record gltBatchHead for each posting and
two or moe
posting detail lines gltBatchDetail for the posting detail.
Different posting targets can be mixed on the same posting type. Posting types
allowed are:
CHK - Check
JNL - Journal
INV - Invoice
CRN - Credit Note
REC - Receipt
PAY - Payroll
PMT - Payment
Posting Targets catered for are:
G - General Ledger
C - Accounts Payable
D - Accounts Receivable
V - Vehicle
The UpdatePostings procedure is run with the following parameters:
INPUT pcCono Company number in which the posting is created
INPUT pcDbGLBatSeqID Posting Header record sequence ID
INPUT pcUserlD User ID of the user creating the posting
INPUT pcAction Blank is a normal posting
Void is to void a check
Relssue is to re issue a check
Reverse is to reverse an existing posting
INPUT piRevMonth Accounting Month in which the posting is to be reversed
OUTPUT plmOkay Valid Return Code
CA 02657303 2009-03-06
- 107 -
1. Check that the posting balances to zero.
Exclude statistical accounts.
2. Void Check for a Sold Vehicle - force a
re issue
3. Check for stale allocations
Return Error to Calling
Errors? Proceudre
Each posting detail by posting source Get the current audit number from
C= AP D=AR sycSysControl.CurrentAuditNo prefixed with the
V= Vehicles G General Ledger sub system prefix
Get the AP AR GL or Vehicle Account Number
If AR or AP Allocations are used generate a
opposite entry for the amount allocated on each
allocation in the table ttGL
GL - Create GL entry ttGL
AR - Create AR update record ttAR
Create GL Control entry ttGL
Rnn nnarltPAR nrnrPrlnre
AP - Create AP update record ttAP
Create GL Control entry ttGL
Rnn nndatPAP nrnnPdnrP
VH - Create Vehicle update record ttVH
More transactions? Create GL Control entry ttGL
Rnn nntinteVH nrnrPdnre
Run updateGL procedure
Posting Type CHK - Create Check record
gltCheckMaster
Posting Type REC - Create Receipt print
record
When this procedure is run the following updates will take place:
CA 02657303 2009-03-06
- 108 -
1. The procedure will check that the sum of the posting equals zero.
Statistical
accounts (type Z) will be excluded from this test. If the posting does not
balance a
error message is retun=rned to the calling procedure
2. If a check is being voiced that was originally used to pay for a vehicle, a
flag is
set to force the reissue of the check
3. If any allocations are used in the posting, the procedure will check that
all the
allocations are still valid in the event that another posting has been created
using
any of the allocations in the active posting
4. If a check is being issued, the next check number is retrieved for the
selected bank
and bank account
5. If a receipt is being processed the next rceipt number is obtained from the
getDocno.p procedure
6. If a Journal is being processed and the auto journal number option is
active the
next journal number is obtained from the getDocno.p procedure
7. For each posting detail record sorted by porting source the procedure will
do
i. For AP Postings if there are any allocations, a opposite GL entry record
(ttGL) will be created for the amount that was allocated. The entry for the
AP Control will be gereated (ttGL) and the AP update record (ttAP) will
be created.
ii. For AR Postings if there are any allocations, a opposite GL entry record
(ttGL) will be created for the amount that was allocated. The entry for the
AR Control will be gereated (ttGL) and the AR update record (ttAR) will
be created.
iii. For GL postings the entry to the general ledger account of the posting
will
be generated (ttGL).
iv. For Vehicle postings, the entry to the vehicle control (ttGL) will be
generated and the vehicle update record (ttVH) will be created. The
vehicle update procedure updateVH will be run.
8. The updateAP procedure is run to update all entries in the ttAP file
9. The updateAR procedure is run to update all entries in the ttAR file
10. the updateGL procedure is run to update all entries in the ttGL file
11. If a check is being created the procedure will create the check record
(gltCheckMaster)
12. If a Receipt is being processed the receipt print records are created. One
prtDocHead record will be created and one or more prtDocDetail records will be
created for each detail line on the receipt
CA 02657303 2009-03-06
- 109 -
UadateServiceInvoice
The UpdateServicelnvoice procedure is used to close off and invoice all Repair
Orders. Each
repair order will have one svtROMaster record, and at lease one svtJobHeader
record. Each
svtJobHeader record will have at lease one svtJobDetail record.
The job types can be:
CSH - Cash
CST - Customer Account
ESC - Extended Service Contract
WAR - Warranty Claim
PDI - Pre Delivery Inspection
INT - Internal Charge
VEH - Stock Vehicle Reconditioning
WEO - We Owe RO to an AP Account
A RO can have any number of, and any combination of job types.
The UpdateServicelnvoice procedure is run with the following parameters:
INPUT phBuff The handle of the svtROMaster record
INPUT pcMode Not currently used
INPUT pcAction Set to "Main" when being called by the costing screen
And blank when being called by the warranty processing screen
INPUT pcUserlD User ID on the user processing the RO Invoice
INPUT pcDocType INV or CRN
INPUT pcAll If all jobs of the selected type are to be invoice set to "Yes"
INPUT pcAllJobs If all jobs on the RO are to invoiced set to "Yes"
INPUT pcCshCst If all customer pay jobs (cash and account) are to be invoiced
Set to "Yes"
OUTPUT pclnvNo The invoice number of the invoice generated
OUTPUT pclnvList A comma separated list of all invoice numbers generated if
All the jobs on a RO are being invoiced
OUTPUT pcRetVal Error messages return parameter
CA 02657303 2009-03-06
- 110 -
For each job to be invoiced Get the next Invoice Number from the getDocno.p
procedure
Process the Header Record
Process Labor Lines GL and Service DOC
Process Sublet Lines GL and Service DOC
Process Misc Lines GL and Service DOC
Process Parts Lines GL and Parts Sales
<More Jobs? Process Tax Entries GL and Tax AP
Process Policy Discount
Update AR Accounts
Update AP Accounts
Update StockVehicle Records
Update General Ledger
Update Customer Sales
Do WIP Allocations
Create Print Document
When this procedure is run the following updates will take place:
1. Get the next invoice number from the getDocument.p procedure
CA 02657303 2009-03-06
~ -11i-
.2. When an Invoice is being produced (not a proforma) the procedure will
check that
the job being invoiced is not flagged as waiting for replacement parts. If
this is the
case, an error message will be returned
3. If a Credit note is being produced for a cash job, the procedure will check
if the
receipt has been processed. It a receipt has been processed, the job cannot be
credited.
4. The procedure will then process the header record depending on the type of
ro as
follows:
i. CSH - Create the Cash Control GL entry (ttGL) for the total invoice
amount as a debit entry
ii. CST - Create the customer AR Control GL entry (ttGL) for the total
invoice amount as a debit entry. Create the AR update record (ttAR) to
update the AR record with the invoice amount as a debit entry
iii. WEO - Create the weowe AP Control GL entry (ttGL) for the total invoice
amount as a debit entry. Create the AP update record (ttAP) to update the
AP record with the invoice total
iv. ESC - Create the ESC AR Control GL entry (ttGL) for the total invoice
amount as a debit entry. Create the AR update record (ttAR) to update the
AR record with the invoice total
v. WAR - Create the OEM Warranty AR Control GL entry (ttGL) for the
total invoice amount as a debit entry. Create the AR update record (ttAR)
to update the AR record with the invoice total
vi. PDI - Create the OEM Warranty AR Control GL entry (ttGL) for the total
invoice amount as a debit entry. Create the AR update record (ttAR) to
update the AR record with the invoice total
vii. INT - Create the GL entry (ttGL) to the GL account selected for the total
invoice amount as a debit entry.
viii. VEH - Create the Vehicle GL control GL entry (ttGL) for the total
invoice
/
amount as a debit entry. This account will be the Inventory
Reconditioning account for a stocked vehicle and the aftersales cost / COS
account for a sold vehicle. Create the Vehicle update record (ttVH) to
update the vehicle with the invoice total.
5. The procedure will then generate the general ledger entries for the job
detail
records as follows:
i. For each labor line on the job:
1. Credit Labor WIP with the labor cost
2. Debit Labor COS with the labor cost
3. Credit Labor Sales with the labor Sales Value
4. Debit Labor discount with the labor discount
ii
6.
