CA2657303A1 - Internet enabled vehicle downpayment system and method with backend system for managing vehicle dealer information - Google Patents

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

[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

[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 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

[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.

Consumers 104

[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

[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 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

[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

[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

[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

[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

[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.

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.

Computing Devices 101

[0080] It will be understood that the computing devices 101 of the consumers 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

[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

[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 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

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 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

[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 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.

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

[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, 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

[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

[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

[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

[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

[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 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).

[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.

How the Framework 152 handles Parts Inventory Ordering

[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).

[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

[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

[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

[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

[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 3. Update the Reconditioning Cost on the Vehicle Inventory Record with $150 (i.e. vehicle associated financial data 142).

[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

[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

[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 2. Debit the Cash On Hand Account with $125 (i.e. vehicle associated financial data 142).

[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.

[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 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.

[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.

[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:

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 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, 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 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.

[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 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 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.

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 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 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.

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 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.

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 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 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 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 . . . . .. . .... . .. . . . .. . . .. . . .. . . / ..,:. , . . .. .. ......
.. . . . . . . .. . .. . . . .. .

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.

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 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 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 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 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 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 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.

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 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 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 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

(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.

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.

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:

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.

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:

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 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.

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 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 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 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 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 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:

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 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.

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 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

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 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 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:

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 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 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 ~ -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.