Product Overview - V3

Great Minds Software
Contract Advantage Date

Product Overview Page 1 of 25
Overview
Contract Advantage is a web-based contract management application that can be

accessed by internal or external users. Users may be part of the organization, or may
be an outside entity that must be greatly restricted in access capabilities.
The purpose of the product is to enable users to:
1. Requisition a new contract or services/products on an existing contract

2. Create solicitation documents (RFx)
3. Handle Workflow and RFP Reviews
4. Support Contract Negotiation
5. Assemble Contract Documents, and other documents, as required
6. Act as a repository for contract-related documents
7. Handle Workflow and Approvals of Contract Documents
8. Track versions of contract documents
9. Create a Contract Data Repository
10. Track Responsibilities and Actions
11. Send out alerts to Responsible Persons via Emails, Phone or IM regarding
pending action due dates
12. Handle Email and Word document creation from within the application by
users, including attaching documents.
13. During the life of the contract, track information as appropriate to each
contract. This includes such features as: Financial Transactions, Insurance
Certificates, Asset Management, Escrow, Intellectual Property (Copyright,
Patents and Trademarks), Complaints and Litigation, Amendments, New
Work Orders, Corporate Compliance, and more.
14. Archive completed contracts, track Warehousing and Destruction
Authorizations.
15. Provide User-Defined Reporting of various sorts.
Other major areas of Contract Advantage include:
1. Define Entities used in the system

a. An “Entity” is a Company, Company Division, Government Agency,
Hospital, or other organization or a unit of an organization.
b. Entities participate in the contract process, either as contracting parties,
or as related parties or in a support role (such as a law firm, banker,
advisor, etc.).
c. Each contract has at least 2 sides – for simplicity we call them “Our Side”
and “Their Side”. In addition to these entity types, the system can
support other types of entities: Our Side Counsel, Their Side Counsel,
Third Parties, Government, etc. Each role has a specific function in the
system.
Overview (cont’d)
2. Define People used in the System

a. People are associated with all types of entities. Depending on which type
of entity a person is associated with will determine some of their rights
and access to the system. In general, “Our Side” has more privileges
and access rights. Outside parties have less access – limited to THEIR
contracts, data and documents.
3. Control Items (Master Lists)

a. There are many control items defined in the system. These define
everything from countries and cities, to descriptive attributes used in the
contract data record.
b. Some Control Items are System Tables, and should only be touched by
authorized administrators.
c. Most Control Items can be selected by a user to be used in a contract
record.
d. Administrators can ADD Control Item tables as necessary, and then add
the related foreign keys to the Contracts table (or other table, as
required). The Control Item tables interface is a single form that
generates the user interface based on data-driven tables. can be
generated
Entities, People and Control Items make up the most important group of information to
get into the system – before contracts are ever created. The more information already
entered into the system, the easier the contract creation process will be for the user.
Login and Authentication
Contract Advantage provides the following Authentication Services:
1. Authentication against an LDAP Server.

2. Authentication against Active Directory
3. Optional Single Sign-in Services
a. Enable Domain login to flow thru to the application, if enabled. Not all
installations will want a single sign-in, but some will.
4. Embedded Login and Security (within application)
The Login System must verify the System Licensing, User count and occupied seats.
The system should capture the # of denied login attempts (detail and summary) to
determine need for additional licenses.
Users can only log in if there are sufficient seats available for the license.
Login distinguishes a Log In by a “Full User” and by a “VIEW ONLY USER”. Each is
managed with a separate counter system.
Login activity is to be recorded in the System Event Log.

Starting the Contract Process
The Contract process can be started in one of several different places, depending on
the need of the Organization:
1. Prepare an RFI/RFP/RFQ document

2. Requisition a Contract on-line thru Contract Advantage
3. Evaluate proposals through the Proposal Evaluation Workflow Module
4. Assemble a Contract Document
5. Open a Contract Record and start recording information
The process can really begin anywhere. There is no restriction other than the user
must open a Contract Record (Requisition or RFx Record) to start the process.
Contract Forms
Because different types of contracts have unique requirements, it is important to

enable the administrator (or us as the implementing group) to define the pages and
data to be maintained for each type of contract. Thus, the system will have a
Repository of “Contract Pages” that can be used on a contract – and an authorized
user can pick from these contract pages.
The administrator can define ONE OR MORE sets of Contract Forms as defaults for
any given Contract Type. Different divisions or subsidiaries, in different locations, may
require that different types of data be maintained.
During the life of a contract, additional pages or data fields may need to be added. An
authorized user must be allowed to add forms or add fields to forms, as required. This
suggests that each form must be represented in a database table, and that each
CONTRACT have its own list, or repository, of contract pages. This will also help in
generating a contract detail report, which is a complete detailed snapshot of the
contract record.
Master Lists (a/k/a Control Items)
Master Lists (formerly known as Control Items) are tables that support the application
with common reference values, such as Currency, City, State, Contract Type, etc.
Master Lists are accessed through a common Form, driven by tables representing the
data content.
Most tables are accessible directly from the general User area of the application, but
still under security control. Certain tables (like Security Level) are more appropriate
as Administrator accessible tables, and are coded as a System Table.
The Administrator should be able to add Master List tables and fields, as appropriate.
Security should be set to allow access to several levels of the Master Lists: ALL, a
Master List Group, or individual Master Lists. If access is given to a Master List Group,
then the user will have access to all tables belonging to that group.
Company
The Company table and its supporting table system manages all of the entities that are
related to the contracts – as parties, advisors, regulatory bodies, law firms, etc. People
are usually associated with a Company, although they may appear as individual
contacts in the system.
A Company may be:

- Party – Our Side
- Party – Their Side
- Other – Our Side Outside Counsel
- Other – Their Side Outside Counsel
- Other – Regulatory Entity (SEC, FTC, etc.)
- Other – Our Side Financial Advisor
- etc.
The Company (Entity) will have a 3-line formal name, as well as a Display As field
(called Short Name). The field names can be changed at this stage. The Display As
name is a shorter, 50-character name that is easier to remember.
The fields Party, Our Side, Their Side, Other, and the linked table Company Other
Role should be used to generate the Parties Menu and the Forms accessed thru that
menu.
The People associated with each Party Entity can be accessed from the Company
form generated for that Party Entity.
Each Party Entity may have multiple address associations. People that belong to a
Party Entity can have the same address as the Party Entity, with only the floor or Mail
Stop being different – or a Person can have their own mailing address independent of
a company address.
When creating a new Company, there should be a Short Form that shows only certain
fields: Company Name, Display As, Ticker Symbol, Country, URL. (Ticker Symbol
and URL are not required). Once saved, the Full Company Form can be displayed for
editing.
People
People can belong to a Party Entity, or may exist as individuals.
People may have multiple Roles: Responsible Person, Attorney, Business Contact,
Principal Scientist, and Outside Counsel.
People who belong to Party - Our Side may have other attributes – enabled as a
Contract Approver, Dollar Limit for being able to authorize contracts, enabled to
approve Contract Clauses for the Clause Repository, etc.
People can be defined as System Users. If the user belongs to Party – Our Side, that
user will have more general access to the system. If the user belongs to Party – Their
Side, they will be restricted to accessing ONLY their contracts, usually with VIEW
ONLY privileges.
People are assigned to Groups. Groups are assigned Rights to various Security
Areas. Security Rights are implemented through groups as Role-based Security.
People, on Our Side, can be defined in hierarchies. If Hierarchy Control is enabled,

users higher up in a hierarchy can see contracts belonging to people below. People at
the same level cannot see each other’s contracts, unless authorized. A good example
is a sales organization in a large company: the Sales VP can see all of the sales
contracts below him. A Sales Manager cannot see another sales manager’s contracts,
or the contracts below that sales manager. And sales account executives cannot see
each other’s contracts.
A Person who is tagged as an Our Side Person and System User, and is a
Responsible Person, may have responsibilities only for certain Our Side Companies.
Security should define if the person has Access To or Responsibility For ALL Our Side
Companies, a Group of Companies in a hierarchy, or to specific Companies. A Person
does not have to be part of company entity to be Responsible or have access to that
company. A good example is a corporate attorney, who may be formally part of
Division 1, but has responsibility for Division 1, 2, and 3.
When creating a People record, a Short Form should be displayed to capture basic
information: Name (Last, First, Middle), Display As, Company, Country, Title, Phone #
and Email Address. When this information is completed and saved, the Full Form can
then be displayed.
Actions
The Action Management System provides the basis for some of the most important
functionality of Contract Advantage. Actions describe for each Contract WHAT must
be done and WHO is responsible for completing the task. Actions can be one-time
actions or recurring actions.
Actions, along with other dates throughout the system, provide the information required
by the Email Alert System, and for the Action Reports.
Alerts can be generated as “Task” emails – showing a list of OPEN actions, or as

“Action” emails. An Action Email is only generated on the specific date of an Early
Warning or of the Action itself. The contents of the “Action” email pertain only to that
action. If the “Hierarchy” system is enabled, the supervisor of a person responsible for
an action will receive an email either when a task is not completed on time, or when an
action is completed, depending on settings on the action record or in administration. If
an action is completed, there should be a notification list, including “All OUR SIDE on
this Action, ALL Their Side on this Action, ALL on Contract, or Specific People.”
The Administrator can specify which types of PEOPLE can receive Email Alerts. The
primary recipients of Email Alerts are OUR SIDE – Responsible Persons. Some
clients will want to also send alerts to THEIR SIDE – Responsible Persons. The
administrator can enable/disable Alerts to THEIR SIDE.
When there are multiple people Responsible for an Action, the user who sets up an
action can specify which Persons are to receive the EMAIL Alert. The user can also
specify “INFORMATION ONLY” recipients – they are NOT responsible for the action,
but they are being informed that an Action is due.
Special kinds of actions can be identified as KEY DATES. These dates show on
Contract Summary page. An Action Type record can be tagged as a Key Date
indicator.
Actions can also be Financial Actions – when Completed (Action_Status=Completed),

the user can POST the Financial component of the record to the Transactions table.
If a Recurring Action is reassigned or changed, ONLY the Open actions are re-
created/changed. The Completed Actions are NEVER changed.
The Actions table can also form the basis for Work Flow records, with some
modifications. It may be easier to maintain work flow as a separate table collection.
Intellectual Property
Intellectual Property includes Copyright, Patents and Trademarks. In this application,

we can combine all three into a single Intellectual Property table, and identify each
type of IP record by an IP Flag: C, T, P.
Each record can be linked to a Table of IP Images. Patents and Trademarks

especially may have attached images.
IP may be attached to contract records for reference. IP images should also be

accessible to the user through the contract, and be able to 1 or all images on a pop-up
web page.
Each IP item is defined by the jurisdiction in which it is filed – usually a country or

group of countries (like the EC). Within each IP item there is a link to a (possible) PTO
Agent who can file on behalf of the Company.
Intellectual Property is NOT present on every contract. All three IP types do NOT need
to be on the same contract – they are actually separate occurrences. The
administrator or other authorized user may add a specific type of IP page to a contract
as necessary, or it may be part of a template or Contract Type Forms definition. A
contract may have multiple IP items (multiple Patents, for instance).
Data Dictionary
The Data Dictionary provides an interface for accessing the data definitions for the
entire database. Importantly, it includes an ability to manage the field labels for tables
and fields so that administrators can customize the system for the user experience.
The Data Dictionary also has an extension that manages different language versions
for the table and field titles. If a User has a Language preference other than 0, Field
prompts and Form captions can use the alternative specified language.
All fields are identified by type, width and decimals (numeric only). Tables and fields
have Titles that are the custom names the administrator can give to fields. Key fields
are identified in the Data Dictionary for every table, and Foreign Keys are identified
along with the source table, key field and Display field.
The Data Dictionary plays 3 major roles:
1. Provides the custom field names for selecting columns for the Contract
Selection Grid
2. Provides the fields for defining User Reports
3. Provides the Table Titles and Field prompts for the entire application.
In the second round of development, the Data Dictionary will provide the means for
enabling the Administrator to ADD Tables and Fields into the Schema and Data
Dictionary.
The Data Dictionary can function as the Master List (Control Item) definition tables,
since all of the Control Item tables are already defined in the data dictionary. This will
reduce the number of tables used in the system.
The Data Dictionary should have a “Load ALL” button that will automatically load ALL
tables and data fields into the dictionary. If the Table already exists, give the
administrator the options of “SKIP”, “SKIP ALWAYS”, “OVERWRITE”, “OVERWRITE
ALWAYS”. There should be a button to “DELETE ALL” (with warning and
confirmation).
The Data Dictionary should have a field in the TABLE list that tags a table as “Delete
Records for Production” or “Delete Records for Demo”. Tables that have these
designations can be wiped clean based on the task. The actual tables may also have
records that are tagged as “Do NOT DELETE – Production” and “Do NOT DELETE –
Demo”.
Document Repository
Contract Management Systems exist ultimately to keep track of the contract

documents that are produced with the software system or that are received from the
outside. Hence, the Document Repository Module provides key access and control
features to the contract documents.
The Document Repository is accessible from:
1. Main Menu – Document Repository

a. Access the Attached Documents that the user is authorized to see
2. Contract Record
a. Each contract has a Document Repository link. This allows access to a
form that displays documents in a series of structured folders
(correspondence, email, Contract, images, etc.)
3. Contract Selection Screen
a. The user can search for a text string in any documents that the user is
authorized to see.
The features of the repository are:
1. CHECK OUT (Open) a document for editing. This copies the file down to a
local (or network) folder for the user, and allows the user to edit the
document. CHECK OUT locks the document from further checkouts until the
document is returned. All activity related to a document is logged in the
Document History.
2. CHECK IN (Save) a document. After editing, the user must return the
document to the system. CHECK IN is logged in the Document History, and
the LOCK flag is reset.
3. CANCEL CHECK IN – if the user decides not the return the document, then
the CHECK IN can be cancelled.
4. SEAL – documents or folders can be SEALED from any CHECK OUT
operation. This will prevent any modifications or deletions from the
document folders from the Contract’s Document Repository. An authorized
administrator is the only one who can remove the seal.
5. Document Scanning. Scan documents into system using a full-featured
scanning tool (like OmniPage Pro 12).
Documents that are edited (Checked Out) automatically create a Versioning folder, so
that the original document and all subsequent changes can be tracked.
Security
Security is a key component of the system, and affects every database access,
workflow and communication. Security is object-oriented, and has many levels:
1. Many prospects have requested LDAP Authentication. Some want to use

authentication to enable a single sign-on environment.
2. Users are placed in groups (roles) for role-based security.
3. Access rights begin at the MODULE level. Does the user have access to ALL
parts of the module, or only certain parts? We have typically used the keyword
“ALL” to define access rights to all areas of the object, but then we use further
attributes like “Add, Modify, Delete, Print, View” for further definition.
4. The app should have the option of implementing security by Entity. An Entity is
a “company” on Our Side who owns a contract. So, an attorney may have
access to all contracts from Division 1 and Division 3, but NOT Division 2.
5. Security is particularly sensitive regarding access to contracts and what a user
can do to contract records. Each Contract Record is assigned to 1 Security
Area (which may be “Joint Ventures”, or “Sales”; or “High”, “Medium”, “Low”; or
“Division 1”, “Division 3”; or some other definition. USERS can be assigned to
multiple Groups with multiple levels of security, and each relationship can have
different security attributes (like “Add”, “Edit”, “Delete”, “View”, “Print”.
6. There have been requests to include a capability of restricting which fields a
user can see – for instance, restrict clerical workers from seeing financial data.
7. Another request is to set up security by Contract Type. Entity and Contract
Type Security control, as with Security Areas, can be relaxed by using the
keyword ALL when defining GROUP security rights.
8. There are “Operational Security” rights as well:

a. Can user ADD a form to a contract? (Or Delete, etc.)
b. Can user AEDV a Document (even though they have rights to the
contract record itself)?
c. Can user Search for documents?
d. Can user Approve contracts?
e. Should we implement Form Level access?
f. Can user Add Control Item tables?
9. On the SYSTEM level, implement the Security Module and License File. The
software must be properly purchased and licensed for the system to function.
10. Security starts with the SYSTEM_USERS table. This is typically a rather small
table. People entered here are also created in the PEOPLE table. Or, if you
enter someone in the SYSTEM_USERS table, and make them a USER, their
data will be reflected in the SYSTEM_USERS table.
Work Flow
Work Flow management is critical to the contract system. It supports the routing of
documents for review and approval. Work Flow tools are implemented in the following
areas:
1. Review and approval of RFx outgoing documents.

2. Review and balloting on incoming Proposals.
3. Review and approval of contracts.
In addition, Work Flows should be enabled for other purposes not necessarily attached
to a particular contract.
Work Flow should be accessible from the following areas:
1. Main Menu – user should have access to Work Flows in which they
participate from the main menu. Users should also be able to create new
workflows or work flow steps from the main menu – this is especially true for
administrators.
2. RFx Module – RFx workflows should be accessible from the RFx module.
The system should show Open or In Process RFx projects and their related
workflows and status.
3. Contracts Module – From within a contract, an authorized user should be
able to set up and access their workflows. Each Contract may have multiple
workflows.
A graphical representation of the workflow, with editing capabilities, would be very

effective. (I have seen this in other products).
Insurance Certificates
Large companies often require that their suppliers/vendors carry appropriate

insurance. The evidence provided to the customer is called an Insurance Certificate.
Insurance Certificates always have an Expiration Date. Therefore, it is important to
track the insurance certificates for their expiration dates.
The Insurance Certificate carries the following information: Insurance Carrier, Type of
Insurance, Amount of Insurance (called the Coverage Amount), Deductible Amount,
Effective Date and Expiration Date.
The Insurance Certificate should be linked to the Vendor (Company Table). There
should also be a LINK table to join with the Contracts table. A Contract can have
multiple insurance certificates from a vendor, and the same contract can be on multiple
contracts. The user should be able to update the insurance or link to the contract from
either the vendor record or from within the contract record.
The Email Alert system should have the following functionality as it relates to insurance
certificates:
1. [Optionally] send an email to the vendor 90 days (or other specified time) before
an insurance certificate expires.
2. [Optionally] repeat email (or mail) every month until expiration (unless record is
updated with a new expiration date, or if the certificate was CANCELLED.
3. Send an email to Responsible Person on affected contracts.
Territories
The Territories Form is usually used in distribution contracts and Licensing contracts
(for trademarks, patents and copyrights). The Territories table comes primed with a list
of countries (WIPO countries) and states, but can really be anything that the user
wants it to be. For instance, territories can be groups of Postal Codes, regions of a
country, counties, Groups of Countries, Regions of the world, or any other definition.
Each Territory record also has a comments area that can further describe the
composition of the territory.
Multiple territories can be attached to a contract record.
The system can produce reports of contracts grouped by territory.

Asset Management
Large organizations acquire many types of assets. These can be plant and equipment,
car fleets, hardware, software, etc. With the Contract Advantage, the user can
associate the acquisition of any of these assets with a contract.
Some assets, such as hardware and software, can be moved, retired, reclaimed and
redeployed many times over the life of the asset. The system can be used to track the
purchase, deployment and reclamation of these assets. An important application can
be found in controlling maintenance costs based on the assets that are currently
deployed. Assets that are not deployed should not be counted in calculating
maintenance, which is usually based on the count of hardware or software units.
An Asset Master List holds the Product, Manufacturer, and Asset Type information.
On a contract, the user can Add an asset/product to the Asset Manager for that
contract, and then purchase (acquire) a number of units of the asset for an amount.
The asset can then be deployed to different Locations – tracked by date, location and
number of units. The “inventory” of that asset can then be updated to reveal count in
inventory and count deployed.
Reports can then show assets purchased, deployed and inventoried across contracts,
within business units and company entities or across multiple entities.
Transactions
The Financial Subsystem uses the Transactions table to accumulate financial

transactions for reporting, analysis or integration with external systems. Financial
Actions can generate entries into the Transactions table. Other subsystems and
external systems will be able to generate transaction entries as well.
Transactions are based on the General Ledger, a system of “accounts” that can be
structured, grouped and then used to accumulate transaction entries.
The General Ledger accounts can be further classified by SubAccounts. SubAccounts

are a structured series of numbers that are used to classify transactions by Entity,
Office, Department, Profit Center, Business Unit or other combinations. The
SubAccounts are defined in the system within System Administration and Control
Items – you can pick which tables represent segments of the SubAccount, the segment
size and the position in the concatenated string that makes up the SubAccount.
Each transaction is first defined to be an Asset/Liability OR a Payment, Receipt, or

Adjustment.
There are 2 types of transactions, Debits and Credits. Each transaction MUST be a
Debit or a credit. If a Transaction Type is used, the transaction gets its “Debit/Credit”
code from the Transaction Type.
The system can be set to force transactions as balanced entries, so that they must be
entered in as a batch – and Debits and Credits must be equal before posting to the
Transactions table.
Transactions can be in multiple currencies. Using a web service, we can retrieve the
conversion rate between any 2 currencies that was recorded on any given day. The
conversion rate should be saved in the conversion table. If a web service is NOT
used, then the conversion can be entered manually.
Transactions can also capture Check #’s, PO #’s, Payee, etc.

Leases
Contracts that involve leases can describe the Lease in more detail. It is possible that
a particular contract may have multiple leases associated with it.
A Lease can be one of several Types: Equipment, Hardware, Software, Fleet, Real
Estate, etc. Each Lease Type has specific attributes that must be tracked.
Real Estate: Commercial, Residential; Net Lease/Operating Lease; Location; Rentable

Size (sq ft); Net Usable (sq ft); Purpose; Building Manager;
Hardware/Software Leases: Asset Type; Detailed schedule showing Asset Master,

Quantity, Serial #. The Detail may be in aggregate, or list each item separately with its
serial #.
Fleet Leases: Manufacturer; Make; Model; Count; Year;
For ALL Leases: Description; Lease Amount; Start Date; Term (months); End Date;
Initial Payment; Monthly Payment; Balloon Payment; RE Taxes; Interest Rate. Monthly
Principal, Interest and Taxes (total = payment); Bank; Lease #.
Reports:
Simple, summary lease report;
Detailed Lease Report;
Lease Projection Report, taking a starting Year thru some planning horizon, say 5
years. The lease payments are calculated on a monthly and annual basis. Present by
Type, in summary and in detail.
Transactions:
Enable transactions to be extracted on a Monthly basis, and posted to the
Transactions table for either cutting checks or for analysis (assuming checks are paid).
Location
Location
Location
Location
Location
Location

Product Overview - V3

Uploaded by

Copyright:

Available Formats

You might also like

Product Overview - V3

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Product Overview - V3

Uploaded by

Copyright:

Available Formats

Great Minds Software

Contract Advantage Date

Contract Advantage is a web-based contract management application that can be

The purpose of the product is to enable users to:

1. Requisition a new contract or services/products on an existing contract

Other major areas of Contract Advantage include:

1. Define Entities used in the system

2. Define People used in the System

3. Control Items (Master Lists)

Login and Authentication

Contract Advantage provides the following Authentication Services:

1. Authentication against an LDAP Server.

Login activity is to be recorded in the System Event Log.

Starting the Contract Process

1. Prepare an RFI/RFP/RFQ document

Because different types of contracts have unique requirements, it is important to

Master Lists (a/k/a Control Items)

A Company may be:

People can belong to a Party Entity, or may exist as individuals.

People, on Our Side, can be defined in hierarchies. If Hierarchy Control is enabled,

Alerts can be generated as “Task” emails – showing a list of OPEN actions, or as

Actions can also be Financial Actions – when Completed (Action_Status=Completed),

Intellectual Property includes Copyright, Patents and Trademarks. In this application,

Each record can be linked to a Table of IP Images. Patents and Trademarks

IP may be attached to contract records for reference. IP images should also be

Each IP item is defined by the jurisdiction in which it is filed – usually a country or

The Data Dictionary plays 3 major roles:

Contract Management Systems exist ultimately to keep track of the contract

The Document Repository is accessible from:

1. Main Menu – Document Repository

The features of the repository are:

1. Many prospects have requested LDAP Authentication. Some want to use

8. There are “Operational Security” rights as well:

1. Review and approval of RFx outgoing documents.

Work Flow should be accessible from the following areas:

A graphical representation of the workflow, with editing capabilities, would be very

Large companies often require that their suppliers/vendors carry appropriate

Multiple territories can be attached to a contract record.

The system can produce reports of contracts grouped by territory.

The Financial Subsystem uses the Transactions table to accumulate financial

The General Ledger accounts can be further classified by SubAccounts. SubAccounts

Each transaction is first defined to be an Asset/Liability OR a Payment, Receipt, or

Transactions can also capture Check #’s, PO #’s, Payee, etc.

Real Estate: Commercial, Residential; Net Lease/Operating Lease; Location; Rentable

Hardware/Software Leases: Asset Type; Detailed schedule showing Asset Master,

Fleet Leases: Manufacturer; Make; Model; Count; Year;

You might also like