Technology Evaluation Centers Inc. Accounting Software Functional and Technical Worksheet
Hierarchy 1 1.1 Criteria General Ledger Chart of Accounts
Priority Mandatory (0-10) (Y/N) SUP MOD 3RD CST FUT NS
1.1.1
Chart of Accounts (Set Up)
1.1.1.1
Industry specific charts of accounts
1.1.1.2
User defined segment lengths
1.1.1.3
Delete segments not required
1.1.1.4
Copy range of accounts to new reporting units
1.1.1.5
User defined account ranges
1.1.1.6
Copy chart of accounts to new department Copy chart of accounts to new profit center
1.1.1.7
1.1.1.8
Copy chart of accounts to new company
1.1.1.9
Budget groups
1.1.1.10
Multiple account levels
1.1.1.11
Segregates subsidiary schedules
1.1.2
G/L account code (Set Up)
This category contains 7 criteria below it.
1.1.3
Major structures (Set Up)
1.1.4
This category contains 10 criteria below it. Valid Posting Accounts
1.1.5
This category contains 3 criteria below it. Reporting Units
1.1.6
This category contains 6 criteria below it. Allocations (Processing)
1.1.7
This category contains 6 criteria below it. Allocations (Formula Basis)
1.1.8
This category contains 13 criteria below it. Amortization Tracking
1.1.9
This category contains 4 criteria below it. Prepaid Expense Tracking
1.2
This category contains 4 criteria below it. Transaction Processing This category contains 63 criteria below it. Month and Year End Closing
1.3
1.4
This category contains 15 criteria below it. Control Reports
1.5
This category contains 17 criteria below it. Financial Statements
2 2.1 2.1.1
This category contains 83 criteria below it. Accounts Payable Vendor Master File Vendor Master Set Up
2.1.1.1
Departmental/divisional accounts payable files
2.1.1.2
Roll A/P processing into parent entity
2.1.1.3
One time vendors
2.1.1.4
Automatically assigns new vendor number User defined numbering convention
2.1.1.5
2.1.1.6
Consolidate vendor files
2.1.1.7 2.1.1.8 2.1.1.9
Identifies vendor type Supports foreign addresses Maintain electronic copies of purchase contracts
2.1.1.10
Vendor web access to master files
2.1.1.11
Changes automatically routed for approval Changes marked as provisional until approved Multiple 1099 codes per vendor
2.1.1.12 2.1.1.13
2.1.1.14
Non-print 1099 if below minimum value
2.1.1.15
Holds PO/invoice if W-9 information missing
2.1.1.16
Prints W-9 information form or equivalent
2.1.1.17
Prints user defined cover letter
2.1.1.18
Payment to third party
2.1.1.19
Single default expense account
2.1.1.20
Multiple default expense accounts
2.1.1.21
Default percentage distribution
2.1.1.22 2.1.1.23
User defined discount calculations Primary contact
2.1.1.24
Comment field
2.1.1.25
Maintain vendor special purchasing instructions
2.1.1.26
Display instructions automatically during PO entry
2.1.1.27
Documents linked to fields and tables
2.1.1.28
E-signature on contracts
2.1.1.29
User defined vendor master fields
2.1.2
Vendor ID Number
2.1.3
This category contains 3 criteria below it. Contract Employees
2.1.4
This category contains 4 criteria below it. Vendor Master File Options
2.1.5
This category contains 7 criteria below it. Vendor Contracts This category contains 2 criteria below it. Vendor View into A/P Capabilities
2.1.6
2.1.7
This category contains 5 criteria below it. Vendor Change A/P Data Capabilities
2.1.8
This category contains 5 criteria below it. Quick Purchase Review
2.1.9
This category contains 8 criteria below it. User Defined Blanket Payment Terms
2.1.10
This category contains 5 criteria below it. User Defined Individual Payment Terms
2.1.11
This category contains 5 criteria below it. Vendor Performance Ratings System
2.1.12
This category contains 12 criteria below it. Vendor Contact Manager
2.1.13
This category contains 8 criteria below it. Vendor Document Management System
2.2
This category contains 3 criteria below it. Purchasing Controls This category contains 257 criteria below it. Data Input
2.3
2.4
This category contains 76 criteria below it. Payables Analysis This category contains 75 criteria below it. Check Writing This category contains 28 criteria below it.
2.5
2.6
Control Reports
2.7
This category contains 7 criteria below it. Financial Reports
3 3.1 3.1.1 3.1.1.1
This category contains 87 criteria below it. Accounts Receivable Customer Master File Customer Master Set Up Divisional accounts receivable
3.1.1.2
Roll A/R processing into parent company
3.1.1.3
Open item customers
3.1.1.4
Balance forward customers
3.1.1.5
Automatically assigns new account number
3.1.1.6
Consolidate customer files and transactions Order by, ship to, paid by addresses
3.1.1.7
3.1.1.8
Sort customer list alphabetically
3.1.1.9 3.1.1.10
Foreign addresses COD customers
3.1.1.11
Tracks specific COD terms
3.1.1.12
Maintain electronic copies of purchase contracts
3.1.1.13
Occasional customers
3.1.1.14
Multiple ship to addresses
3.1.1.15
Record receiving hours at each ship to address
3.1.1.16
Record delivery/handling instructions
3.1.1.17
FOB terms
3.1.1.18
Stores UPS zone code
3.1.1.19
Ship complete only notation
3.1.1.20
Item substitution notation
3.1.1.21
Identifies customer type
3.1.1.22
Default revenue code
3.1.1.23
Set individual credit limits
3.1.1.24
Set blanket finance charges
3.1.1.25
Set individual finance charges
3.1.1.26
Set individual sales discount
3.1.1.27
Set blanket payment terms
3.1.1.28
Set individual payment terms
3.1.1.29
Tracks customer payment history
3.1.1.30
Calculates credit rating automatically
3.1.1.31
Segregate customers by payment history
3.1.1.32
Primary contact
3.1.1.33 3.1.1.34
Primary contact telephone number Sales account representative
3.1.1.35 3.1.1.36
Collections representative Statement options
3.1.1.37
Assign statement printing cycle options
3.1.1.38
Statement includes/excludes closed transactions
3.1.1.39
Record exemption IDs for non-taxable customers
3.1.1.40
Comment field
3.1.1.41
User defined customer master fields
3.1.2
Change Customer ID Number
3.1.3
This category contains 3 criteria below it. Customer Contracts
3.1.4
This category contains 2 criteria below it. Freight Carrier Assignment
This category contains 2 criteria below it.
3.1.5
Credit Management System
3.1.6
This category contains 6 criteria below it. Credit Limit/Hold Functionality
3.1.7
This category contains 4 criteria below it. Quick Payment Review
3.1.8
This category contains 9 criteria below it. Multiple Vendor Contacts
3.1.9
This category contains 3 criteria below it. Customer Contact Manager
This category contains 8 criteria below it.
3.1.10
Dispute Resolution Application
3.2
This category contains 6 criteria below it. Customer Relationship Management This category contains 103 criteria below it. Invoicing This category contains 77 criteria below it. Cash Receipts This category contains 44 criteria below it. Debt Collection
3.3
3.4
3.5
3.6
This category contains 50 criteria below it. Control Reports
3.7
This category contains 8 criteria below it. Financial Reports
4 4.1
This category contains 65 criteria below it. Payroll Employee Files
4.1.1 4.1.1.1
Employee Files (General) Restricts access to sensitive files
4.1.1.2
User defined employee master fields
4.1.1.3 4.1.1.4 4.1.1.5
Tracks citizenship information Automatic assignment of employee number User defined numbering convention
4.1.1.6
Assigns default department
4.1.1.7
Assigns default pay
4.1.1.8
Assigns default pay cycle
4.1.1.9
Automatically applies scheduled raises
4.1.1.10
Automatically applies cost of living adjustments Implements retroactive pay raise
4.1.1.11
4.1.1.12
Automatic deductions
4.1.1.13 4.1.1.14
Deduct meal allowances Credit meal allowances
4.1.1.15
Record, track, and deduct advances
4.1.1.16
Local union benefit reporting
4.1.1.17
Calculation of employer contribution
4.1.1.18
Process short term deductions over specified periods
4.1.1.19
Tracks deductions as non-mandatory
4.1.1.20
Tracks compensatory time off accrued
4.1.1.21
Automatically offsets sick pay received/accrued
4.1.1.22
Calculates employer FICA for sick leave
4.1.1.23 4.1.1.24
Prevents accrual during unpaid leave Accrues and tracks other paid leave
4.1.1.25
Tracks workers compensation information
4.1.1.26
Individual savings calculations
4.1.1.27
Retirement programs
4.1.1.28
Calculates employer contribution to retirement funds Supports additional tax withholding
4.1.1.29
4.1.1.30
Direct deposit
4.1.1.31
User can change tax tables
4.1.1.32
Insurance submissions
4.1.1.33
Segregates active and inactive employees
4.1.1.34
Calculates termination pay automatically
4.1.2
Employee Information (Basic)
4.1.3
This category contains 6 criteria below it. Pay Periods
4.1.4
This category contains 9 criteria below it. Position Classification Pay Rate Tables
4.1.5
This category contains 7 criteria below it. Default Expense Distribution
4.1.6
This category contains 7 criteria below it. Deduction Calculations
4.1.7
This category contains 3 criteria below it. Deduction Features
This category contains 4 criteria below it.
4.1.8
Deduction Limit Management
4.1.9
This category contains 3 criteria below it. Auto Payment of Employee Obligation
4.1.10
This category contains 3 criteria below it. Sick and Vacation Pay Tracking
4.1.11
This category contains 2 criteria below it. Vacation Accrual Basis
4.1.12
This category contains 5 criteria below it. Sick Leave Accrual Basis
4.1.13
This category contains 5 criteria below it. Time Off Carried Over to a New Year
4.1.14
This category contains 4 criteria below it. Unpaid Leave Tracking
4.1.15
This category contains 3 criteria below it. Vendor Provided Tax Tables (USA)
4.2
This category contains 7 criteria below it. Human Resource Management
4.3
This category contains 57 criteria below it. Canadian Payroll Processing
4.4
This category contains 17 criteria below it. Data Input and Cost Distribution This category contains 75 criteria below it. Payroll Check Writing This category contains 19 criteria below it. Control Reports
4.5
4.6
4.7
This category contains 9 criteria below it. Financial Reports
5
This category contains 34 criteria below it. Inventory
5.1
Inventory Master File
5.1.1 5.1.1.1
Inventory Master File (General) User defined numbering convention
5.1.1.2
Define item ID by item characteristics
5.1.1.3
Define procurement code (make/buy)
5.1.1.4
Group parts using similarities
5.1.1.5 5.1.1.6
Change item ID and transactions Superseded items
5.1.1.7
Combine original and superseded item histories Multi-line item descriptions Negative on-hand quantities
5.1.1.8 5.1.1.9
5.1.1.10
Item file supports item picture
5.1.1.11
Serial numbering
5.1.1.12
Tracks serial numbers of components
5.1.1.13 5.1.1.14
Lot tracking Identify customer(s) from serial/lot number
5.1.1.15
Multi-dimensional items
5.1.1.16 5.1.1.17 5.1.1.18
"Requires inspection" flag Product line segregation Shipping weight
5.1.1.19 5.1.1.20
Shipping dimensions Shelf life tracking
5.1.1.21 5.1.1.22
Picks items based on shelf life Converts item to dead stock with write off
5.1.1.23
Cycle count code
5.1.1.24
ABC code
5.1.1.25 5.1.1.26
Movement class Consignment inventory
5.1.1.27
Mass change cost revaluation
5.1.1.28 5.1.1.29
Alternate vendors Copy vendor information for new items
5.1.1.30
Default revenue account
5.1.1.31
Default cost of goods sold account
5.1.1.32
Sales tax rate
5.1.1.33 5.1.1.34
Excise tax rate Customer rebate programs
5.1.1.35
Rebate posted as voucher to A/P automatically
5.1.1.36
Reorder point adjusted for vendor lead time
5.1.1.37
Define commission rate
5.1.1.38
Prevents unauthorized alteration of records
5.1.1.39
Define commission types for each item
5.1.1.40
Define commission types for rate groups
5.1.2
Item Status This category contains 4 criteria below it.
5.1.3
Item Technical Specifications
5.1.4
This category contains 6 criteria below it. Bar Code Tracking
5.1.5
This category contains 4 criteria below it. Basis for Cycle Count Code
5.1.6
This category contains 2 criteria below it. ABC Class Code Management
5.1.7
This category contains 5 criteria below it. Customer-Owned Inventory Management
This category contains 9 criteria below it.
5.1.8
Inventory Costing Method
5.1.9
This category contains 5 criteria below it. Standard Cost Modification
5.1.10
This category contains 4 criteria below it. Normal Vendor
5.1.11
This category contains 6 criteria below it. Pricing Conventions
5.1.12
This category contains 11 criteria below it. Warehouse Level Pricing/Costing
5.1.13
This category contains 3 criteria below it. Customer Price Matrix Options
This category contains 6 criteria below it.
5.1.14
Customer Contract Options (Additional)
5.1.15
This category contains 5 criteria below it. Reorder Conventions
5.1.16
This category contains 9 criteria below it. Reorder Control
5.1.17
This category contains 5 criteria below it. Vendor Lead Time
5.1.18
This category contains 9 criteria below it. Internal Lead Times
5.2
This category contains 5 criteria below it. Inventory Control/Assembly Systems
5.3
This category contains 109 criteria below it. Data Input and Cost Distribution This category contains 43 criteria below it. Receiving Activities
5.4
5.5
This category contains 85 criteria below it. Shipping and Withdrawal Activities
5.6
This category contains 28 criteria below it. Financial Reports
6 6.1
This category contains 84 criteria below it. Job and Project Costing Job Initiation
6.1.1 6.1.1.1
Job Setup (General) DCAA approved
6.1.1.2
Automatic job numbering
6.1.1.3
User defined numbering convention
6.1.1.4
Job cost estimating
6.1.1.5
Convert estimate to budget
6.1.1.6
Multiple budgets with revisions
6.1.1.7
Assign default invoice format per client
6.1.1.8 6.1.1.9
Automatically calculates additional billing Future billing rates
6.1.1.10
Automatically updates billing rates
6.1.1.11
Master labor and material file
6.1.1.12
Store estimates
6.1.1.13
Update template with current costs
6.1.1.14
Vendor provided standard categories and phases
6.1.1.15
Segregates and identifies subcontractors
6.1.1.16
New job initiated entirely from job cost module
6.1.1.17
Stores data for completed job as a summary
6.1.1.18
Stores data for completed job in detail
6.1.2
Job/Project Industry Support
6.1.3
This category contains 6 criteria below it. Job Type Support
6.1.4
This category contains 4 criteria below it. Job Definition File
6.1.5
6.1.6
This category contains 6 criteria below it. Job Resource File This category contains 5 criteria below it. Job/Project Front Office Support
6.1.7
This category contains 7 criteria below it. Default Billing Rates
This category contains 10 criteria below it.
6.1.8
Billing Formats
6.1.9
This category contains 9 criteria below it. Bill-to Functions
6.1.10
This category contains 4 criteria below it. User Defined Line Item Cost Detail
6.1.11
This category contains 3 criteria below it. Start and End Date Tracking
6.1.12
This category contains 3 criteria below it. Cost Tracking
6.2
This category contains 10 criteria below it. Data Input and Cost Distribution
This category contains 78 criteria below it.
6.3
Job Control
6.4
This category contains 36 criteria below it. Cost Analysis and Reports
6.5
This category contains 47 criteria below it. Job Invoicing This category contains 80 criteria below it. Fixed Assets Equipment Files Equipment Files (General) User defined equipment master file
7 7.1 7.1.1 7.1.1.1
7.1.1.2
Asset ID permits grouping by category
7.1.1.3
Assignment of serial numbers
7.1.1.4 7.1.1.5
Identifies original manufacturer Identifies current location
7.1.1.6
Identifies current user
7.1.1.7
Prepares property tax reports
7.1.1.8
Tracks status of capital projects
7.1.1.9
Asset groups
7.1.2
Equipment Leasing
7.1.3
This category contains 4 criteria below it. Default Distribution
7.1.4
This category contains 3 criteria below it. Depreciation Methods
This category contains 4 criteria below it.
7.1.5
Simultaneous Depreciation Calculation
7.2
This category contains 3 criteria below it. Cost Calculation and Distribution This category contains 26 criteria below it. Reports This category contains 6 criteria below it. Order Entry Order Entry (Set Up)
7.3
8 8.1
8.1.1
Order Entry (General)
8.1.1.1
Manufacturer's agent sales
8.1.1.2
Post commission to payroll automatically
8.1.1.3
Cash drawer
8.1.1.4
Cash drawer balancing
8.1.1.5
Calculates change due
8.1.1.6 8.1.1.7
Supports all inventory functions Supports restocking
8.1.1.8
User designed data entry screens
8.1.1.9
Bar code reader
8.1.1.10
Prints price labels
8.1.1.11 8.1.2
Prints bar code labels Industry Type Support This category contains 5 criteria below it. Agent and Commission Structure
8.1.3
This category contains 4 criteria below it.
8.1.4
Commission Splits and Overrides
8.1.5
This category contains 3 criteria below it. Commission Basis
8.1.6
This category contains 12 criteria below it. Commission Review
8.1.7
This category contains 3 criteria below it. Payroll Timekeeping
This category contains 4 criteria below it.
8.1.8
Warranty Handling System
8.2
This category contains 9 criteria below it. Order Receipt
8.3
This category contains 259 criteria below it. Order Tracking
8.4
This category contains 31 criteria below it. Shipping
8.5
This category contains 38 criteria below it. Invoicing This category contains 11 criteria below it. Reports
8.6
9 9.1
This category contains 69 criteria below it. Budgeting Budgeting (General)
9.1.1
Comparison versus budget
9.1.2
Separate internal budgeting module
9.1.3
Integrates with third party budgeting system
9.1.4
Monthly budgets
9.1.5
Multiple budget revisions
9.1.6 9.1.7
Maintains budget revision history Non-G/L budget groups
9.1.8
Budget roll up system
9.1.9
Multiple year budgets
9.1.10
Budgeting for non-general ledger activities/accounts
9.1.11
Budgeting for activities or campaigns
9.1.12
Budgeting for capital projects
9.2
Review Process
9.3
This category contains 4 criteria below it. Construction of New Budget
10 10.1 10.1.1 10.1.1.1 10.1.1.2 10.1.1.3 10.1.1.4 10.1.1.5 10.1.1.6 10.1.1.7 10.1.1.8 10.1.1.9 10.1.1.10 10.1.1.11 10.1.2
This category contains 14 criteria below it. Manufacturing Product Costing Cost Components Raw material Subtotals by component Labor Special inspections Machine time Outside processing Packaging Scrap Yield Shrinkage Overhead/burden Costing Mechanisms
10.1.3
This category contains 6 criteria below it. Cost Generation Mode
10.1.4
This category contains 2 criteria below it. Cost Buildup Methodology
10.1.5
This category contains 2 criteria below it. Product Costing Reports This category contains 6 criteria below it. Master Production Scheduling (MPS) This category contains 29 criteria below it. Material Requirements Planning (MRP) This category contains 63 criteria below it. Capacity Requirements Planning (CRP) This category contains 41 criteria below it. Shop Floor Control This category contains 49 criteria below it. Quality Control This category contains 13 criteria below it. Multinational Accounting Installation and Support Local Support United States Canada Mexico Caribbean Latin America South America Great Britain Western Europe Eastern Europe Russian Republics Scandinavia Middle East
10.2
10.3
10.4
10.5
10.6
11 11.1 11.1.1 11.1.1.1 11.1.1.2 11.1.1.3 11.1.1.4 11.1.1.5 11.1.1.6 11.1.1.7 11.1.1.8 11.1.1.9 11.1.1.10 11.1.1.11 11.1.1.12
11.1.1.13 11.1.1.14 11.1.1.15 11.1.1.16 11.1.1.17 11.1.2
Africa India Southern/Southeastern Asia Japan/Korea/China Australia/New Zealand Languages Supported
11.1.3
This category contains 27 criteria below it. Simultaneous multilingual by user ID
11.2
11.3
11.4
11.5
11.6
12 12.1
Basic Information This category contains 18 criteria below it. Currency Rate Tables This category contains 10 criteria below it. Transaction Entry This category contains 10 criteria below it. Gain/Loss Reporting This category contains 13 criteria below it. Financial/Management Reporting This category contains 13 criteria below it. General VAR/Reseller Channel
12.1.1 12.1.1.1
VAR/Reseller Channel (General) Requires initial product certification
12.1.1.2
Requires recurring product certification
12.1.1.3
Vendor certified add-on program
12.1.1.4
Internet listing of add-on products
12.1.1.5
Partner board drives software development
12.1.1.6
Internet listing of channel members
12.1.1.7
Internet listing of open sales opportunities
12.1.1.8
Vendor supported opportunity management
12.1.1.9
Reseller can profile their target market
12.1.2
Vendor Sales Organization
12.1.3
This category contains 3 criteria below it. Reseller Education
12.1.4
This category contains 6 criteria below it. Reseller Access to Sales Collateral
12.2
This category contains 9 criteria below it. Industry Specific Modules This category contains 47 criteria below it. Presale Information This category contains 73 criteria below it. Technology Technical Requirements Client Operating System
12.3
13 13.1 13.1.1
13.1.1.1 13.1.1.2 13.1.1.3 13.1.1.4 13.1.1.5 13.1.1.6 13.1.1.7 13.1.1.8 13.1.1.9 13.1.1.10 13.1.1.11 13.1.1.12 13.1.1.13 13.1.1.14 13.1.1.15 13.1.1.16 13.1.1.17
3270 terminal DOS OS/2 OSF/Motif Sun Openlook Xenix/Unix Linux Macintosh Windows 3.1 + Windows 95 Windows 98 Windows 2000 Windows NT 4.0 Windows NT 5.0 Windows XP AS/400 RS/6000
13.1.2
Server Operating System
13.1.3
This category contains 28 criteria below it. Database
13.1.4
This category contains 26 criteria below it. Programming Language
13.1.5
This category contains 19 criteria below it. Client/Server Structure
13.1.6
This category contains 3 criteria below it. Client/Server Options
13.1.7
This category contains 3 criteria below it. Wireless Device Access
13.1.8
This category contains 3 criteria below it. Wireless Access Functionality This category contains 8 criteria below it. Web-enabled Employee-facing Applications This category contains 11 criteria below it. Microsoft Compliance
13.1.9
13.1.10
13.1.11
This category contains 10 criteria below it. Specific Application Support
13.1.12
This category contains 52 criteria below it. Manufacturing Application Support
13.1.13
This category contains 14 criteria below it. EDI Functionality
This category contains 7 criteria below it.
13.1.14
Inter/Intranet Functionality
13.1.15
This category contains 17 criteria below it. Customer-facing Portal
13.1.16
This category contains 10 criteria below it. OLAP Functionality
13.2
This category contains 4 criteria below it. Control and Audit
13.3
This category contains 34 criteria below it. Operational Functionality This category contains 118 criteria below it. Reports This category contains 92 criteria below it. Specify font
13.4
13.4.9.7
cal Worksheet
Comment
The Chart of Accounts is for all practical purposes the business managment system. If it is not set up properly so that revenues and costs are captured and segregated into the best suited categories, the financial statements produced will be useless. Chart of Accounts Set Up: The single most important set in the set up process is defining the Chart of Accounts. The Chart of Accounts forms the basis for financial reporting. Care must be taken to describe not just the business as it exists today but how it might exist in the future. One must also be careful to include all possible views of an opganization without making the Chart of Accounts so large that data input speed is decreased and while the chances for inaccuracy are increased. Industry Specific Charts of Accounts: Present users of accounting software represent every industry imaginable, and I am certain that new users would welcome the opportunity to install a Chart of Accounts which is a compilation of many companies in their industry. This would allow them to focus on the establishment of those accounts unique to their company rather than their industry as well. User Defined Segment Lengths: While many companies will want to define segments to track revenues and expenses for departments, divisions, regions, etc., there is no sense for data input personnel to have to input anything other than the exact segment number. By defining the length of the segment users will not have to input zeros in some systems, but of greater importance users will be able to reserve the unused segments digits for other segments which might be longer. Delete Segments Not Required: If a Chart of Accounts structure supports six segments, but a user requires only four or five, they should be able to delete the segments not required. Alternately the product should not display a segment in an input screen if it has not been defined. Copy Range of Accounts to New Reporting Units: Users operating multiple divisions or subsidiaries might establish identical revenue and cost structures for each division. Smaller users with multiple departments might wish to do the same thing. The process of establishing these account groupings can be accomplished more efficiently if the software has the ability to copy this whole range of accounts to other departments, divisions, or subsidiaries. User Defined Account Ranges: Many companies moving from manual to automated accounting might want to preserve their existing account numbering schemes. Everyone is used to these account numbers and the learning process might create a number of errors should a different scheme be adopted. This question asks if users can specify what account ranges will apply to what categories such as assets, liabilities, etc. Rather than having to input each account for a new company, department, or any other chart of accounts revenue/cost center, users should have the ability to define all of the accounts for the first department or company, and then copy that account structure to each new company or department. Rather than having to input each account for a new company, department, or any other chart of accounts revenue/cost center, users should have the ability to define all of the accounts for the first department or company, and then copy that account structure to each new company or department.
Rather than having to input each account for a new company, department, or any other chart of accounts revenue/cost center, users should have the ability to define all of the accounts for the first department or company, and then copy that account structure to each new company or department. Supports Budget Groups: While budgeting can be accomplished using General Ledger account numbers, larger organizations may wish to establish and track budgets for workgroups and smaller entities within the organization, but without having to establish separate General Ledger accounts for each entity. In this case the Budget Groups will need to be defined outside the General Ledger account codes, but allow users to assign expenses to these accounts. Supports Multiple Account Levels: Many packages have adopted the concept of account levels. The numbering convention adopted by the program is predicated upon this concept. Each level represents a layer of detail. Level five would then be more detailed than Level 4. The number of levels available to the user will determine to a large extent the degree of detail reported. The user needs to understand that it does not take very long to get to level five as the example demonstrates. Level # Balance Sheet Level 1 Liabilities Level 2 Short Term Liabilities Level 3 Taxes Payable Level 4 Payroll Taxes Level 5 Federal Withholding Income Statement Level 1 Total Expenses Level 2 G & A Expenses Level 3 Rents & Leases Level 4 Building Rent Level 5 Rent - Building #213
Segregates Subsidiary Schedules: If a company elects to establish a Chart of Accounts with a number of levels, how should the information be presented in the Income Statement and Balance Sheet? One method of presenting this detailed information without cluttering the basic report is the establishment of what is known as subsidiary accounts or schedules. An example from the previous question would explain this process. The Income Statement might indicate only the value of Rents and Leases. At the conclusion of the Income Statement the report would list the cost of all Building Rents and the rent for Building # 213. Should the manager wish to examine these, the information is there, but it does not cloud the picture in the primary Income Statement.
G/L Account Code Set Up: There are accounts other than just standard posting accounts. Active accounts are those standard accounts to which revenue and cost information can be posted. Inactive accounts are accounts to which information cannot be posted until the user makes them an active account. Allocation accounts collect information that will then be posted to other accounts (such as the allocation of overhead costs). Accrual accounts are used to input revenue and costs which have not yet been posted in one of the sub-modules. When those revenues and costs are posted, the allocated costs will be reversed. Inter-company accounts are used to collect revenues and costs relating to transactions between related entities. Some companies might not want to use Job Costing to collect information concerning projects or events, and they might want to define these projects in the G/L. Finally, some accounts are used to collect non-financial information such as the square footage occupied by each department so that overhead costs can be allocated. Statistical accounts are used to collect this information.
Define Separately Major Structures for: Rather than attaching a reporting unit such as a department to the Chart of Accounts itself, some users might want to define the reporting units in an entirely different function. As revenue or cost information is input, the prime G/L account can be specified in one field and the reporting unit in another field. By separating these major structures from the Chart of Accounts, the process of managing them becomes far easier. This would be particularly true for project and event costing where revenues and costs are not posted to Work in Process but to the project and the appropriate revenue or cost accounts. This will make any analysis far easier and closing the project requires no more than telling the system the project is closed (in essence making the account inactive). At some point in the future, but probably not in the current year, the exact same account number can be used for another project.
Define Valid Accounts for Reporting Units: The old fashioned way to define a department was to name that department and then assign however many valid accounts were required. A better way would be to define as an example a single template reporting unit and then copy that structure to every other similar reporting unit. If some accounts needed to be added or deleted, they could be done so quite easily. An even better way would be to use the graphical environment to define the new reporting unit account structure just be pointing and clicking to add or delete accounts. This routine would not actually add any totally new accounts, as those would have to be defined in a separate routine where all possible valid accounts would have been defined.
Reporting Units: While a single financial statement for the whole company may be acceptable for a small company, larger organizations need to break their financial statements into smaller units that reflect the way they do business. These questions deal with some of the requirements that may be imposed on a company if it wants to divide itself into organizational units for reporting purposes.
Allocation Account Processing: Most larger organizations contain any number of units whose function is the support of other groups. Since there is no revenue associated with these support groups, it is sometimes difficult to develop a true picture of a revenue generating group's true profitability without taking into consideration the work contributed by various supporting groups. This question is designed to identify the relative level of sophistication of a product when it comes to allocating costs to other reporting units.
Allocations (Formula Basis): One of the most effective ways of allocating costs is the use of what can become fairly complex formulas to measure activity or some other factors or groups of factors by which costs can be allocated rationally. This question is designed to identify the complexity of the formulas each product uses to allocate costs. Allocation formulas would be based on each of these criteria.
Amortization Tracking: One of the most time consuming aspects of maintaining any set of financial books is all of the tables and detailed notes required to track items such as amortization. All products offer depreciation tracking applications or functions. This question asks whether the system supports a similar function for identifying each item that is being amortized, the period over which it is being amortized, and then calculates the appropriate expense each period.
Prepaid Expense Tracking: One of the most time consuming aspects of maintaining any set of financial books is all of the tables and detailed notes required to track items such as Prepaid Expenses. All products offer depreciation tracking applications or functions. This question asks whether the system supports a similar function for identifying each Prepaid Expense item, the period over which it is being expensed, and then calculates the appropriate expense each period.
Transaction Processing: Journal entries control how revenues and costs are allocated across the organization. This section describes the journal entry process.
Month and Year End Closing: While revenue can be billed and cost information collected, if that information is not published in the form of financial statements quickly, so much time will have passed that the statements themselves become almost useless.
Control Reports: All business management systems must have some form of controls to make sure information is input correctly. The reports listed in this section have been designed to accomplish this task.
Financial Statements: The financial statements drive the company. For smaller companies this is less true since the owner or manager should have a "feel" for operations rather than relying on printed reports. Larger companies cannot do this simply because they are too big.
Vendor Master File: All master files are the starting point in any application. In this case the Vendor Master File must be set up first because that drives the rest of the functions in Accounts Payable. Vendor Master Set Up: The key to efficient and accurate data processing lies in how systems are set up. This applies to all master files.
Departmental / Divisional Accounts Payable Files: As in the case of Accounts Receivable, some companies might split their accounting functions along departmental or divisional lines. This would necessitate the establishment of separate accounts for Payables as well as Receivables. They could accomplish this by treating the two (or more) departments or divisions as if they were separate companies, and consolidate the financial statements, but this might not be convenient. These companies might wish to maintain one set of books for all departments and divisions. Roll A/P Processing into Parent Entity: Although an individual subsidiary may be responsible for purchasing parts and services, the payables created are paid by another entity, usually a parent organization. That organization or central group pays the bills of all subsidiaries. Rather than having to maintain separate payment applications for each individual entity, cash management functions would be improved if all items were consolidated and paid as if there was but a single entity. This question asks if the system can consolidate payments processing of multiple subsidiaries into a single system, paid from a single corporate bank account (or more than one but not tied to the subsidiary). Supports One Time Vendors: This is the same discussion which we had in Accounts Receivable. While companies need the information to pay their bills, they might not want that information to remain in the files for excessive lengths of time. The most important aspect to consider here is the deletion of the account as soon as the bill has been paid. Automatically Assigns New Vendor Number: This is the same discussion we had in Accounts Receivable. The objective here is a reduction in the time required to initialize a new account and therefore an increase in user efficiency. Supports User Defined Numbering Convention: This is the same question as found in Accounts Receivable. The rational remains the same as well; increased efficiency while meeting the specific needs of one user. Some users want their account numbers to indicate more than just an account number. In most instances this numbering convention is used to sort vendors into specific categories. Consolidate Vendor Files: What happens if two vendors merge or users inadvertently define the same vendor twice? This question asks if it is possible to automatically merge two vendor files into a single entity. The system must merge these files automatically for both current as well as transaction history files. Identifies Vendor Type: As in the case of Accounts Receivable, some users might wish to examine groups of vendors. The existence of this field permits the input of a vehicle by which accounts can be classified by type. Supports Foreign Addresses: Many companies purchase from overseas vendors. This question asks whether the system can accommodate overseas addresses. This accommodation must be natural, not forced. Maintain Electronic Copies of Purchase Contracts: In most instances some form of contract will be signed between a purchaser and supplier. In all instances this will be true for contracts that involve special pricing or special handling. If this is the case the purchaser could maintain printed copies of contracts or even electronic copies in some form of document management system. However, the most effective way perhaps may be the maintenance of these contracts within the accounting system itself. Supports Vendor Web Access to Master Files: One of the primary reasons the Internet should be of interest is its ability to save time doing routine chores. If a vendor needs to call their customers and change addresses or contact information, it may be far quicker to access their information on their customer's Web site (or a vendor only Web site) and make those changes themselves. Obviously vendors should not have access to sensitive files nor should they have access to any file other than their own. That's the purpose of the following question.
Changes Automatically Routed for Approval: If a vendor has the right to change certain information, their customer must have in place certain protections to make sure that the changes made are correct and agreed upon. Therefore this question asks if all changes are automatically routed for approval. Changes Marked as Provisional Until Approved: If a vendor does change information in their files, the system should record them but not activate them until they have been approved. Supports Multiple 1099 Codes per Vendor: Virtually all products support the designation of a 1099 code for a vendor, but sometimes a single vendor may provide more than a single product type or service. Since these additional products and services might fall into other 1099 categories, the product should give uses the ability to designate the 1099 type at the transaction level, rather than in the Vendor Master File. Non-Print 1099 if Below Minimum Value: Current tax regulations state that a vendor must receive more than a minimum dollar payments during any one year before a company has to send them a printed 1099 form. This question asks if the system has the ability to track the total payments during the year, and automatically not print a 1099 form if the payments are below this minimum. Holds PO/Invoice if W-4 Information Missing: If a supplier has not provided required 1099 related tax information, a company can be held liable. This question asks whether there is a mechanism built into the system whereby users are either prevented from placing orders with a vendor that has not furnished the required 1099 information, or users are warned that such information is missing. Automatically Prints W-9 Forms for New Vendors: The law states that a company must have on file a W-4 form or its equivalent for every vendor from whom they purchase products and services. This question asks if the system has the ability to print these forms automatically, including the cover letter. This function could be a prompt when a new vendor is defined or a special function somewhere in Accounts Payable. Automatically Prints W-4 Forms for New Vendors: The law states that a company must have on file a W-4 form or its equivalent for every vendor from whom they purchase products and services. This question asks if the system has the ability to print these forms automatically, including the cover letter. This function could be a prompt when a new vendor is defined or a special function somewhere in Accounts Payable. Payment to Third Party: This is a fairly common occurrence. Companies order material or services from one company, but are instructed to pay another company such as a factor. The solution to this dilemma is quite simple. The Customer Master file should contain a field identifying the party to whom the checks should be addressed. While the processing of third party payments can be accomplished through the manual checks routine, users must remember which accounts must be handled in this manner. Single Default Expense Account: Most vendors tend to supply the same material or service, and thus the resulting expense coding is the same. If user have the ability to establish this normal expense account coding as a default in the vendor file, and have the file read the expense code automatically into the processing routine, the input of the data will be more efficient. Multiple Default Expense Accounts: In some cases a supplier might provide multiple products and services and therefore the processing of their transactions might be made more efficient if the system displayed multiple default expense accounts, rather than a single account.
Default Percentage Distribution: If a vendor supplies services to more than one reporting unit, but those services cannot be segregated easily on an invoice, the expense might be distributed between the entities on a percentage basis with the same percentage being used for each invoice. Rather than having to do this manually, the system should give users the ability to define the default accounts to which a vendor's invoices will be distributed as well as the percentage for each. Obviously this distribution has to make sure that 100% of each invoice is allocated. Supports User Defined Discount Calculations: Virtually all systems support conventions such as 2/10 Net 30. This question asks if the system allows users to define their own discount structure. Primary Contact: This is the person to whom queries concerning overdue invoices should be addressed. If this information is in the customer's master file, everyone will know who should be called should a question concerning this account arise. Comment Field: No number of descriptive fields will meet the needs of all users. Some users may wish to have a field of some length into which they can input comments of any type. What they place in this field is not important. The fact that this field exists gives them the ability to design a more flexible customer file. Maintain Vendor Special Purchasing Instructions: In some cases vendors require that purchasers (their customers) submit their orders in a certain manner with certain documentation. These special instructions may be applicable to all customers or only certain customers. If these special instructions do exist, users should be able to record them in their purchasing system so that they can always see the instructions when required. Display Instructions Automatically During P.O. Entry: If special instructions do exist, users should not have to remember them or remember to check to see if they exist. The system itself should display these instructions automatically or at a minimum post a flashing sign that reminds the user that there are special instructions. Documents Linked to Fields and Tables: This is a follow up on the previous question. The key to a document management system is associating each document to a specific and logical field or table so that when the user is in that field or table they can access the document or documents quickly and easily. Supports e-Signature on Contracts: In most cases a contract is not valid unless it has been signed. While the text of a contact is important, the signature determines whether the contract is valid. Maintaining electronic copies of contracts does not help that much if the printed and signed document has to be stored as well. This question asks if the system can store not just the document text but an electronic signature that validates the document. User Defined Vendor Fields: Although most users might not want to keep track of as much information concerning their vendors as they do their customers, the same argument applies. There might be a limit to the amount of information one can or should store concerning a vendor, but the company should have the ability to do so via their Accounts Payable Master File. Change Vendor ID Number: As new vendors are added over time, it may become necessary to change the vendor ID numbering scheme. This question asks whether the system allows users to change a vendor ID number, whether there is a function whereby many numbers can be changed automatically, and most important of all whether the ID number is changed in all current and history files.
Supports Contract Employees: If an individual is deemed to be a contract employee rather than a standard vendor, an organization is required to withhold certain taxes. This question asks if the system can identify a person as being a contract employee, and of greater importance automatically withhold taxes.
Vendor Master File Supports: In many instances companies may be purchasing from divisions of a single organization, or might order from one entity, but the shipment may be coming from a third party (related or unrelated), or the payment may be made to a third party (related or unrelated). This question asks whether the system supports these three different purchasing schemes.
Attach Vendor Contracts to: If the accounting system can maintain electronic copies of purchase contracts, it makes sense to attach these copies to either the Vendor Master file or the item cost table.
Vendor Can View: Their are really two parts to the vendor Internet access question. This one asks what information the vendor can see, while the following question asks what information the vendor can actually change. Vendors should have access to information to make sure it is correct or for other purposes, but they should not have the right to change everything they can see. This question therefore asks what vendors can see, but not change.
Vendor Can Change: There are really two parts to the vendor Internet access question. This one asks what information the vendor can change, while the previous question asks what information the vendor can view but not change. Vendors should have access to information to make sure it is correct or for other purposes, but they should not have the right to change everything they can see. This question therefore asks what vendors can change. The following question then places certain checks and balances on this change process.
Quick Purchase Review: Vendors will call from time to time seeking payment. Rather than referring to one of the aging reports, users might be interested in a routine whereby the most recent history is available in the Vendor Master File. As in the case of Accounts Receivable, the intent of such a grouping of data is increased efficiency.
User Defined Blanket Payment Terms: The establishment of the thirty day standard does not mean that all companies need follow this rule. Some companies might have different criteria which they want to establish. If that is the case, their software should provide them with that flexibility. It should be noted that this question addresses the specification of payment criteria for all vendors.
User Defined Individual Payment Terms: It is unlikely that each vendor will offer the same payment terms. Users should have the ability to specify the terms in each vendor file so that discounts can be taken when appropriate and net payments not made until the last due date agreed.
Vendor Performance Rating System: It is almost impossible for larger companies to track the performance of hundred or thousands of vendors. However this information is critical to maintaining good relationships with vendors and to know which vendors need to be counseled because their performance is becoming unacceptable. This question tries to determine what form of rating program each system supports and whether these ratings are calculated automatically by the system.
Vendor Contact Manager: Just as many organizations utilize a contact manager for customers, there should be an equivalent system which keeps track of each contact with a vendor. This is particularly true when a vendor's performance is slipping or there is some question as to what was said about deliveries, etc. The contact manager should be used to record all or most contacts with a vendor, all transactions, document copies, etc. In addition, users should be able to sort this history file by subject or user or other criteria for review purposes. Finally, this system should perform exactly like a contact manager in that users should have the ability to schedule activities/call backs and write letters.
Supports Vendor Document Management System: While an earlier question asked if the system could maintain electronic copies of contracts, this question asks if the system can maintain electronic copies of all vendor related documents, including contracts. The key here is that all of the documents relating to a vendor are maintained in one central location within the system and therefore easier for users to access.
Purchasing Controls: While anyone can issue a purchase order, the process should be controlled and this section describes both the purchasing process as well as control systems that can be utilized.
Data Input: Once a purchase order has been sent and goods received, the obligation for that purchase needs to be recognized. This section reviews the various steps required to actually get information into Accounts Payable.
Payables Analysis: Once an invoice has been input, it needs to approved and scheduled for payment. This section discusses those steps.
Check Writing: Once an invoice has been processed and approved, it needs to be paid, This section reviews various check writing steps.
Control Reports: While one can assume that information has been input correctly, that is not always the case. The reports listed in this section (as well as sorts of the same report) give users the ability to check information to make sure it has been input correctly.
Financial Reports: Once data has been input into Accounts Payable, users will probably need to review slices of that data to determine if costs are in line, where costs are being incurred, and how those costs compare against other benchmarks.
Customer Master File: Accounts Receivable starts with customers. This section reviews the process whereby customers can be set up and all of the controls that relate to that customer defined. Customer Master Set Up: The key to efficient and accurate data processing lies in how systems are set up. This applies to all master files. Divisional Accounts Receivable: Some companies elect to separate their operations into departments or divisions. In most instances these divisions may be physically separated or large enough to support a separate accountant or accounting department. Part of this process may include the establishment of separate accounting files, including Accounts Receivable. Rather than establishing totally separate accounting systems, these companies may wish to establish separate files such as Accounts Receivable, but maintain only one General Ledger file. Under this set of circumstances, the software must be able to support multiple Accounts Receivable files. Roll A/R Processing into Parent Company: Although an individual subsidiary may be responsible for invoicing, the receivable created are collected by another entity, usually a parent organization. That organization or central group is responsible for debt collection for all subsidiaries. Rather than having to maintain separate receivables applications for each individual entity, cash management functions would be improved if all items were consolidated and collected as if there was but a single entity. This question asks if the system can consolidate receivables collections of multiple subsidiaries into a single system and deposited into a single corporate bank account (or more than one but not tied to the subsidiary). Open Item Customers: The transition from a manual to an automated accounting system can provide companies with greater abilities to control their cash flow. Open Item processing stores information concerning each outstanding invoice. While it may not seen important to some, statements using this method stand a much greater chance of being paid than statements indicating a balance due figure only. The Open Item method of tracking Accounts Receivable is perhaps the standard automated method. Balance Forward Customers: Although most companies moving from a manual to an automated accounting system elect to adopt the more detailed Open Item method of tracking Accounts Receivable, some prefer to keep their present Balance Forward method. This question and the previous one asks whether both or only one option are provided by the software. Automatically Assigns New Account Number: The process of adding a new customer to Accounts Receivable can be somewhat tedious, but the information specified will be useful down the road, particularly in the processing of invoices and the preparation of statements. If the system has the ability to automatically assign the next account number, the process of establishing new accounts will have been made that much more efficient.
Consolidate Customer Files: What happens if two customers merge? This question asks if the system has the ability to consolidate one or more customers into a single set of files. The most important part of this routine would be the consolidation of both current and history files into a single unit. Supports Order By, Ship to, Paid by Addresses: Given the trend today for companies to expend through acquisition, this question asks whether the system can support what could be called a tree-like structure for keeping track of customers. Here we are talking about a system which has the ability to define the name of the organization ordering products and services, multiple different names of ship to addresses for this single order by contact, and a third level which tracks the entity responsible for payments. Sort Customer List Alphabetically: Many programs permit users to sort master files in any number of ways. The most important method is the alphabetic sort. Many companies prepare their accounting information prior to data input, thus increasing the speed of the input session itself. If a company has many customers, the clerical time required to look up account numbers will be decreased dramatically by virtue of alphabetically sorted customer lists. Supports Foreign Addresses: Many companies sell goods and services to overseas accounts. This question asks whether the system can accommodate overseas addresses. This accommodation must be natural, not forced. Supports COD Customers: The process of accounting for COD sales is not a difficult one. It requires special notations be placed in the Accounts Receivable files for tracing purposes. While the sale is charged against the ultimate customer, some method must be collecting the charges and their responsibility for doing so. The liability for COD collection rests with the carrier, rather than the customer. Tracks Specific COD Terms: If a customer is COD only, the system should have the ability to record the specific terms as well as display those terms both in the order entry process as well as shipping. In order to answer this question positively, the system must be able to do all three; record the specific terms, display them in order entry, and transfer them to the shipping department automatically. Maintain Electronic Copies of Purchase Contracts: In most instances some form of contract will be signed between a purchaser and supplier. In virtually all instances this will be true for contracts that involve special pricing or special handling. If this is the case, the seller could maintain printed copies of contracts or even electronic copies in some form of document management system. However, the most effective way perhaps may be the maintenance of these contracts within the accounting system itself. Supports Occasional Customers: Every company is faced with the dilemma of processing infrequent or one time purchases. Cash sale customers present no problem for they can be grouped with all other cash sales. One time charge customers must be set up in Accounts Receivable. When the bill is paid, the account is still there and will eventually tend to clutter the files. The Accounts Receivable file should be designed to handle customers such as this. Either the file can be written over with new customer names or deleted together with all other customers like it, but without deleting repetitive customers who happen to have a zero balance at the time the other accounts are deleted. Multiple Ship to Addresses: Some customers receive goods at several locations, but pay for these purchases from one central location. Rather than establishing a separate account for each location, users should be aware that it is possible to establish one account for billing purposes while designating several addresses to which goods can be shipped. This will enable shippers to consolidate all receivables in one account automatically. Record Receiving Hours at Each Ship to Address: Many companies establish special receiving hours. If they do, the user should be able to record this information, and then print it on bills of lading or other shipping documents automatically.
Record Delivery/Handling Instructions: Many customers request special handling or delivery terms. If they do, users should be able to record this information and then have it flow through into order entry and shipping automatically. FOB Terms: In most instances the shipper is responsible for freight, but that isn't always the case. Users should have the ability to record the fact that the customer is responsible for freight, and that information should flow through into order entry and shipping. Stores UPS Zone Code: Those companies which utilizing the services of UPS can spend a great deal of time preparing the appropriate shipping papers. If each Ship To address carried the appropriate UPS zone code, this time could be reduced significantly. Ship Complete Only Notation: Some customers do not want to accept partial shipments, If this is the case, users should be able to note this in the customer's file, and have that information flow through into order entry and shipping automatically. Item Substitution Notation: Some manufacturers and distributors sell similar items such that one could be substituted for another. However, some customers do not want to accept anything but the specific item they have requested. In this case users should be able to record the fact that a customer does not accept substitutions, and have this information flow through into order entry and shipping. Identifies Customer Type: If companies are interested in identifying and analyzing particular groups of customers, the most efficient method of doing so is via one or more fields in the Customer Master File. One field might be the assignment of customers to particular categories such as wholesalers, retailers, etc. Default Revenue Code: Each time an invoice is created, an appropriate revenue account must be credited. If the system had the ability to store the normal revenue account in the Customer Master File, the invoicing routine might be slightly more efficient. When the customer number is specified in the invoicing routine, this revenue code will appear as well. Set Individual Credit Limits: Some customers will pay their bills within a reasonable length of time and others will not. Some customers will demand extended credit because they are large purchasers, while others will ignore all finance charges or will demand that finance charges not be applied. Users should be aware of the financial health of each of their customers and establish mutually acceptable payment terms. All of this leads to a realization that credit limits must be based upon the needs of the customer and the needs of the company setting those credit limits. If users fall into the above category, they should insure that their software is capable of establishing these individual limits. Set Blanket Finance Charges: Most systems have a routine whereby overdue accounts are assessed a finance charge. The most efficient means of doing so is in the master files for Accounts Receivable. These finance charges would then apply to all customers automatically. Set Individual Finance Charges: Some contracts for the delivery of goods or services contain stipulations concerning payment terms and finance charges. These charges should take precedence over the blanket charges mentioned earlier and need to be a part of individual customer files. Set Individual Sales Discount: Some contracts stipulate that all sales above a certain specified value will generate a certain percentage price reduction. If this is the case, the system should have the ability to calculate the discount automatically.
Set Blanket Payment Terms: Many companies elect to establish discounts for the payment of accounts within a certain length of time. The term "2, 10, Net 30" might be familiar to many people. The customer can take a two percent discount, if the bill is paid within ten days, otherwise the entire amount is due within thirty days. If such incentives are offered, the software must be capable of supporting these terms. Set Individual Payment Terms: As with the discussion concerning finance charges, some companies may have contracts stipulating payment discounts which differ from the blanket terms offered to other customers. If this is the case, their system should have the ability to note the contract terms in the customer file and override the blanket terms. Tracks Customer Payment History: Credit limits cannot be established with any degree of accuracy unless the payment history of each customer is examined in detail. Some customers pay bills on a regular cycle, while others pay sporadically or withhold payment until pressured. The process of determining credit limits, or whether a customer should be allowed credit at all, must be based upon an examination of past payment patterns. Companies should review this payment pattern regularly. The most effective means of preparing this analysis is via a report found in the software package. This eliminates the necessity of any manual analysis. Calculates Credit Rating Automatically: Many organizations should track their customers' payment history so that they can determine whether this customer is a good long-term credit risk or not. Virtually all systems will display the fact that a customer's account is overdue when they call to place an order, but this question asks whether the system has the ability to calculate a customer's credit rating based upon their payment history. This rating system would have to be user defined. Segregate Customers by Payment History: Cash flow is important to any company. The ability to segregate those customers who pay rapidly may place a company in a competitively advantageous position. This information may enable them to alter their marketing strategy and increase their cash flow significantly. As in all of these questions, the intent is increased efficiency and effectiveness via an automated system. Primary Contact: This is the person to whom queries concerning overdue invoices should be addressed. If this information is in the customer's master file, everyone will know who should be called should a question concerning this account arise. Primary Contact Telephone Number: If you are going to contact someone, you should have their telephone number indicated immediately adjacent to their name. Sales Account Representative: Should a customer fall behind in clearing overdue invoices, companies may choose to assign collection responsibilities to the sales representative rather than someone in accounting. Naming the account representative in the customer file makes this assignment task more efficient. Collections Representative: In larger organizations, an entirely separate group might be responsible for collections. If so, users will need to assign a specific collections to each customer. Statement Options: Although most customers record and pay based on an invoice, some companies prefer to pay based upon a statement. Statements do serve a useful purpose, but in many instances the statement represents a wasted cost. If customers prefer to pay based on statements, or they seem to pay as a result of being reminded when they receive a statement, then a statement should be sent. However, it makes no economic sense to send statements to customers that ignore them. In this case the users should have the ability to instruct the system not to print statements for specific customers.
Assign Statement Printing Cycle Options: Although most customers pay be invoice, some prefer to pay when a statement is received. However, some may prefer to receive statements other than at the end of the month. In this case the system should allow users to define various statement printing options, and then assign each customer to one of these options. Statement Includes/Excludes Closed Transactions: Although the primary purpose of statements is to remind customers to pay outstanding invoices, some customers would prefer to see all transactions during the most recent statement cycle. In this case uses should have the ability to instruct the system whether to print only outstanding transactions, or all transactions for the most recent statement cycle on a customer by customer basis. Record Exemption IDs for Non-Taxable Customers: Most programs allow users to exempt certain customers from sales taxes. This might be sufficient for internal purposes, but should the IRS or other tax authorities request proof, manual files must be opened. If a company has the ability to record the exemption number in Accounts Receivable, the process of justifying the exemptions is made that much easier. Comment Field: No number of descriptive fields will meet the needs of all users. Some users may wish to have a field of some length into which they can input comments of any type. What they place in this field is not important. The fact that this field exists gives them the ability to design a more flexible customer file. User Defined Customer Master Fields: Accounts Receivable files are not just accounting files. They can be the source of useful information for any number of departments, particularly marketing. The Customer Master file can be thought of as a family portrait. While it will contain information of interest only to the accounting department, the rest of the file can be used to gather information concerning a customer and any number of people who work for that customer. Interested users should determine the flexibility of this file structure. Change Customer ID Number: As new customers are added over time, it may become necessary to change the customer ID numbering scheme. This question asks whether the system allows users to change a customer ID number, whether there is a function whereby many numbers can be changed automatically, and most important of all whether the ID number is changed in all current and history files.
Customer Contracts: In many instances customer contracts are paper documents which means they are not attached to the business management system. This question asks if it is possible to attach digital copies of these contracts to either the customer master file or the item pricing tables for that customer.
Assign Freight Carrier: Many customers have preferred freight carriers. If they do, users should be able to identify the freight carrier in the customer file, and have that information flow through order entry and into shipping.
Supports Credit Management System: The credit of all new customers has to be checked, approved and appropriate limits established. This questions asks if the system supports what might be called advanced features for processing a customer's credit application. The first question asks if the customer can fill out a credit application form on-line, usually via the Internet. Second, the system should support separate functions or screens for processing a customer's credit application. These screens would include any amount of information required by the users, but the point is that there are special screens for doing this. Once the credit information has been received, users need to carry out a background check. The best method is to have the system link to any one of several credit services. Finally, advanced systems should support some form of workflow management whereby the customer's application can be processed and shared with several people. In addition, the use of workflow establishes set procedures which have to be carried out in a certain order.
Supports Credit Limit/Hold Functions: If a customer exceeds their credit limit, several things should happen. First, a flag should be posted in their Master File. Second, users should be notified that the customer is over their limit. Third, the system should block further orders until the customer's account has been brought into line. Finally, the system should assign a review date so that users can check to make sure the account has been brought into line.
Quick Payment Review: Although drastic changes in a customer's credit rating will require an in depth review, many companies might be interested in a report / file summarizing the most recent payment history of a particular customer. This file could be used as a reference when a customer calls, or it might be used as a means to screen customers at the time a large order is placed. The intent of such a file is the presentation of information of interest to a user without having to refer to larger reports. The number of years as a customer might be included in the Quick Payment Review file or it might stand alone. The intent is the same. Long standing customers are a valuable commodity. Their treatment might be slightly different than new customers.
Supports Multiple Contacts Simultaneously for: While most systems support a field to record a primary contact, larger organizations with multiple reporting levels might require that users be able to record the names of several people at each location. This will enable users to know who does what and of greater importance their responsibilities.
Customer Contact Manager: Just as with Accounts Payable, users should be able to maintain a file containing all of the history information with each customer as well as manage that information just as they would in a contact manager. This file would support call scheduling, notes, workflow forwarding to other people, and a review function sorted by various criteria.
Supports Dispute Resolution Application: Disputes will arise between sellers and buyers. This is a business fact of life. Rather than trying to track these disputes using an entirely manual system such as notes and letter files and other aides, the accounting system itself could provide users with a platform that allowed them to identify a problem or dispute and track that dispute until it has been resolved. This application would be entirely electronic which means that users could attach a flag to an invoice or sales order that identifies this item as being in dispute. Once an item has been identified the system would provide users with the equivalent of a contact manager that allowed them to record notes and recall the item on a regular basis until it has been resolved. Although most of the questions here are clear, the notion of Level Tracking and Transfer may need to be explained in more depth. Once a problem has been identified, it would be assigned to an individual person (preferably automatically) and that person would use the contact manager to track the problem and record notes. However, if that person takes no action or has reached the end of their options, the system should be able to transfer the problem to a higher level in the organization. In some cases this transfer would be manual, but it could be automatic, particularly if no action has been taken in a certain number of days.
Customer Relationship Management: CRM and its lighter weight cousin Contact Management are the keys to managing the relationship with customers.
Invoicing: Work can be performed, but funds will not be received unless invoices are sent quickly and accurately. This section covers the invoicing process.
Cash Receipts: Customer payments must be received in a timely fashion, recorded properly, and deposited into the bank as quickly as possible. This section deals with each of those processes.
Debt Collection: Recording profitable business counts for nothing if the funds are not received in a timely fashion or received at all. This section lists some of the procedures companies can take to make sure their customers pay them in a timely fashion.
Control Reports: While one can assume that information has been input correctly, that is not always the case. The reports listed in this section (as well as sorts of the same report) give users the ability to check information to make sure it has been input correctly.
Financial Reports: Once data has been input into Accounts Receivable, users will probably need to review slices of that data to determine if revenues are in line, where revenue is being generated, and how that revenue compare against other benchmarks.
Employee Files: As with all other applications discussed to this point, the Payroll application will not operate efficiently unless everything has been defined or set up. This series of questions helps users understand some of the more common set up functions.
Employee Files (General): This series of questions helps users understand how a payroll system can be set up and utilized. Restricts Access to Sensitive Files: Most software packages offer users multiple levels of security through the use of passwords. One of the most important and sensitive files for any company might be their Employee Files. Information in these files must be restricted to everyone except those who are authorized. While companies cannot prevent people from discussing what they are paid, they should restrict access to the computer files themselves. At the same time the system must grant access to people such as data entry clerks. This question asks, not whether the whole module is password protected, but whether the employee files themselves are password protected. User Defined Employee Files: Although there is a certain body of information common to all Employee Files, many users may wish to store additional information. This information could range from birthdays, to family names, to missed time, to awards, etc. The nature of the information is unimportant. The fact that there are multiple facts companies might want to store is important. In some respects the Employee Files might be viewed as a mini data base. As such all of the fields of information (with the exception of those required by the processing programs) should be user specified and the software should give users the opportunity to sort these fields any way they might desire. Tracks Citizenship Information: Given the emphasis on immigration tracking, a payroll system should track the citizenship or immigration status of each employee as well as work permit dates and other information required by law. Automatic Assignment of Employee Number: As in previous questions, the assignment of a new employee number should be automatic. This will increase efficiency. User Defined Numbering Convention: Some companies have unique numbering conventions. This convention might allow them to sort employee files and print lists of particular groups of employees or generate other employee based reports. As long as the numbering convention is not too complicated, it might make some sense for the software to replicate this convention. Assigns Default Department: Once payroll has been processed, the system must know the accounts to which the costs will be posted. The most effective method of assigning gross wages is the establishment of a default expense account in the Employee File. This usually takes the form of a department to which the costs will be posted. Assigns Default Pay: People tend to be salaried, hourly, or commissioned. Their pay rate tends to be the same as well (with the exception of commissioned employees whose rate could be established in Inventory). The processing of payroll will be made more efficient if the system has the ability to take the normal pay rate and apply it to the processing program. Assigns Default Pay Cycle: People can be paid weekly, bi-weekly, semi monthly, or monthly. As in the case of pay rates, the processing will be more efficient if the system has the ability to process only those people who will be paid. All others will be excluded automatically. Automatically Applies Scheduled Raises: If an employee is scheduled for an automatic pay increase on a specific date, and the system knows what the next pay rate will be (either by looking at a specific field or table), that pay rate increase should be applied automatically with no user intervention at all. The system should notify users that it has applies the rate increase, but that's all. Automatically Applies Cost of Living Adjustments: If an employee's benefits package includes automatic cost of living adjustments, the system should be able to note that fact and then calculate and apply the new pay rate automatically once the adjustment factor has been specified. Implements Retroactive Pay Raise: If an employee should have received a pay raise, but did not, the system should calculate the difference and then pay the differential to the employee the first time the new pay rate is processed.
Supports Automatic Deductions: Virtually all payroll systems will permit users to make a range of deductions for each employee. These deductions can range from savings programs to retirement programs, to court ordered payments. The problem with manual systems is that the calculation, tracking, and payment of each deduction must be manual. Companies with a large number of employees might find this cumbersome. The conversion to an automated accounting system should eliminate these manual calculations. Deduct Meal Allowances: Some companies provide cash free meals, but treat this as an employee paid benefit. The cost of the meal must be deducted each week as a result. Credit Meal Allowances: The other method of accounting for meals (other than treating it as a company paid benefit) is to treat the cost as income to the employee. If this is the case the system should have the ability to handle this transaction. Record, Track, and Deduct Advances: Employees will receive advances from time to time, and these advances will have to be repaid eventually. The rate of repayment might be in one lump sum or over a specified length of time. The software should support these deductions. Supports Local Union Benefit Reporting: Companies with union employees might have agreements whereby they will deduct certain amounts for retirement programs, union dues, etc. While the deductions can be scheduled for each employee fairly easily, and the funds turned over to the union, the union will probably want a listing of each employee and their deductions and/or contributions. Under these circumstances, it makes sense for the software to be capable of producing the report automatically. Supports Calculation of Employer Contribution: Some companies might have other agreements with the union(s) requiring contributions by the company itself. These contributions normally are based upon a percentage of payroll or a flat rate per union employee. Efficient systems will perform these calculations and produce appropriate reports automatically. Process Short Term Deductions Over Specified Periods: One of the most time consuming procedures with which many companies must cope is short term deductions. These can be voluntary such as loans or involuntary such as garnishments and child support. Users cannot escape the task of establishing the deduction (usually weekly). The real problem arises because these deductions must be calculated and tracked individually, paid to the appropriate party with manual checks, and stopped at the appropriate point in time. The efficiency of the whole payroll process can be increased greatly if the software has the ability to make the deductions, collect the required information, prepare the checks, and stop the deduction at the appropriate time, all automatically.
Tracks Deductions as Non-Mandatory: If an employee does not earn enough to pay for all of the deductions he or she has on file, many companies (and the law) allow the employee to receive a minimum amount. If a deduction is mandatory, it must be taken, but if it can be classified as non-mandatory, the system will only take the deduction if there is a certain amount left after all mandatory deductions have been taken. Tracks Compensatory Time Off Accrued: Although exempt employees might not be paid overtime, some companies provide these employees paid leave in lieu of overtime. If they do, the system should be able to track this accrued time off separate from normal accrued vacation. Automatically Offsets Sick Pay Received/Accrued: Some organizations purchase insurance for employee sicknesses. Even though the insurance company pays the employee rather than the employer, the employer must record the leave in their files so that the insurance company knows whether the employee qualifies or not.
Calculates Employer FICA for Sick Leave: Although an insurance company may have paid an employee's sick leave, the employer is still liable for FICA. The system should be able to calculate this FICA liability automatically once the sick leave pay has been recorded. Prevents Accrual During Unpaid Leave: If an employee is on unpaid leave, they should accrue no vacation and sick leave, and the system should delete these accruals automatically. Accrues and Tracks Other Paid Leave: Some companies give their employees paid leave other than just vacation and sick leave. Family emergencies and other legitimate reasons might qualify. Rather than lumping this in with either vacation or sick leave, these paid absences are tracked separately. Tracks Workers Compensation Information: The law states that workers compensation information must be segregated. This applies to time off as well as insurance rates. The system must at least track the position of an employee for determining insurance rates, but there is other information that could be tracked as well. Supports Individual Savings Calculations: Virtually every system permits the establishment of several deduction categories. In most instances these categories can be assigned to a particular class of deduction at the time the system is installed. Savings is a unique category in that the deduction is not designed to pay an obligation. The money is held for the employee until needed. This question asks whether the system has the ability to maintain a savings record for each employee. This figure is not the total deducted for the year to date. It is the balance in the individual's account at any point in time. Supports Retirement Programs: One of the more complicated deductions is that for retirement programs such as 401K, Cafeteria Plans, Keoghs, and IRA's. Each of these must be processed according to a specific set of rules unique to the program. This question asks whether the payroll module supports the calculations necessary to meet the requirements of each program. Calculates Employer Contribution to Retirement Funds: While many systems will support the tracking of contributions to retirement programs such as 401K plans, this question asks whether the system has the ability to calculate the employer portion of the fund obligations. Supports Additional Tax Withholding: Many employees use withholding taxes as a form of enforced savings. While some might argue that the government does not pay interest, employees counter that taxes withheld cannot be withdrawn and that is the most important factor to them. Some employees might wish to have additional taxes over and above normal withheld for this exact reason. The payroll system should have this capability. Direct Deposit: Some companies offer direct deposit whereby employees paychecks are deposited for them in their bank. If this is the case, the software must be capable of producing an automatic report listing the deposits to be made in each bank, the name of each employee, their account number, and the amount to be deposited in their account. User Can Change Tax Tables: This question does not presume that employers are going to change the tax tables illegally. As tax rates or deduction limits change, the tax tables used by the system must be changed. This question asks whether the tables can be accessed by the user and appropriate changes made. Supports Insurance Submissions: Insurance forms can be complicated and time consuming. Considering the fact that all of the basic information to make the submission is present in the Employee Master File, the system should have the ability to fill out the required form with little assistance from the user. Segregates Active and Inactive Employees: This coding permits companies to keep track of their employees more closely, and perhaps more importantly permits the system to automatically exclude from a pay run those employees permanently or temporarily inactive.
Calculates Termination Pay Automatically: If an employee leave a company, the system should be able to look at all earning, including any vacation and other paid time off for which the employee is eligible, and net that against all deductions for which the employee is liable to calculate a final pay check. Basic Employee Information: Although there are any number of pieces of information a system could track concerning each employee, this question lists some of information that some systems might not track, but which is of interest to many companies.
Pay Periods Supported: Most employees are paid either on a weekly, bi-weekly or monthly basis. However, some companies pay their employees using another frequency period. This question lists most of the more common frequencies by which employees can be paid.
Position Classification Determines Rate for: Rather than having to assign a specific pay rate for each employee, larger organizations base an employees salary or hourly rate upon a position classification. If that is the case, the system should give users the ability to define these classifications in a separate table, and then assign an employee to one of the positions. The position itself would then determine pay rates.
Default Expense Distribution: Many companies want to assign an employee's wages to several cost accounts depending upon what they have been doing. Many companies support payroll costs which are close to or exceed 50 percent of their total costs. The examination of the profitability of various revenue sources can be aided if the system has the ability to assign an individual's pay to a number of cost centers.
Deduction Calculations: There are two methods of calculating a deduction. The most prevalent is a flat amount per week. Some employees might wish to establish a savings account whose deduction is based upon a percentage of gross pay. If this is the case, the system should have the ability to perform this calculation.
Deduction Features Supported: Most payroll systems support voluntary and involuntary deductions. This questions double checks to make sure the system will support involuntary deductions, particularly garnishments. Further it asks whether the system can calculate and apply the last deduction amount automatically (e.g. where an employee may be obligated to pay $45 per pay period for 20 periods, with the last deduction being $12).
Deduction Limit Management: It is entirely possible form an employee to earn less than the deductions that are scheduled for a specific pay period. Since some of these deductions are mandatory (i.e. taxes), the system should assist users pay an employee a minimum wage while trying to be as fair to those who are supposed to receive a portion of the employees wages. In most instances there are three ways this can be accomplished. Either the user can set a minimum takehome pay the employee should receive, or set a maximum limit to the deductions. In order to be as fair as possible to those people who are scheduled to receive a portion of the employees wages, the user might want to establish a minimum for each deduction type.
Automatic Payment of Employee Obligations: If an employee must pay child support or a garnishment or other legal obligations, all systems can create the deduction, but that's only half the process. The system should be able to pay an employee's obligations in the most efficient manner possible. The deduction could be posted to A/P as an unpaid voucher, or there could be a special routine in Payroll that pays these obligations.
Sick and Vacation Pay Tracking: All companies offer vacation. Many companies offer some form of paid sick leave as well. The amount of vacation or sick leave earned differs with each employee. All of these calculations are based upon time, and time is a factor that lends itself to automation. It would make sense therefore for the payroll system to calculate vacation and sick leave, pay it when requested, and not pay it when it had not been earned.
Vacation Accrual Based on: Depending upon the nature of the terms and conditions of employment, vacation could be accrued based upon hours worked, months worked, or years worked. In addition, the increase from one step to another could be based on the employees anniversary date or calendar year end for all employees. Finally, if the organization requires that an employee work a certain time before qualifying for vacation, the system should track that qualification date as well.
Sick Leave Accrual Basis: Depending upon the nature of the terms and conditions of employment, sick leave could be accrued based upon hours worked, months worked, or years worked. In addition, the increase from one step to another could be based on the employees anniversary date or calendar year end for all employees. Finally, if the organization requires that an employee work a certain time before qualifying for sick leave, the system should track that qualification date as well.
Carries Over to New Year: If a company allows employees to carry over unused vacation, sick leave or compensatory time off, the system should be able to do exactly the same thing. In some instances the company may place a limit on the number of days that can be carried forward.
Unpaid Leave Tracking: If an employee is absent, that time should be tracked. The time off might be authorized or unauthorized. In addition, the employer might want to track unpaid leave according to certain user defined categories for statistical or disciplinary purposes.
Vendor Provided Tax Tables: The proper calculation of payroll is dependent upon the utilization of the most current tax rates for Federal and State Withholding, Employee and Employer FICA, Federal and State Unemployment, and a whole host of local taxes. This question is designed to determine if the vendor provides the tax tables as an integral part of their system or whether the user has to specify the tax rates.
Human Resource Management: HR applications track very detailed information for each employee. If users need to track educational qualifications, training, and other activities for employees, they probably require some form of HR application.
Canadian Payroll Processing: If a user has Canadian employees, they will require a payroll system that meets the various Canadian regulations. This series of questions lists some of the more common requirements.
Data Input and Cost Distribution: Payroll information drives not just the production of payroll checks but also the distribution of those costs to various departments and activities.
Payroll Check Writing: Just as was described for Accounts Payable, once data has been input into the Payroll system, check need to be printed.
Control Reports: While one can assume that information has been input correctly, that is not always the case. The reports listed in this section (as well as sorts of the same report) give users the ability to check information to make sure it has been input correctly.
Financial Reports: Once data has been input into Payroll, users will probably need to review slices of that data to determine if costs are in line, where costs are being incurred, and how those costs compare against other benchmarks.
Inventory Master File: As with all other applications discussed to this point, the Inventory application will not operate efficiently unless everything has been defined or set up. This series of questions helps users understand some of the more common set up functions. Inventory Master File (General): This series of questions helps users understand how an Inventory system can be set up and utilized. User Defined Numbering Convention: Many companies carry several thousand items in inventory. While the alphabetical listing of these items might assist in the location of a single item number, further subdivisions are usually required. One might equate the establishment of inventory categories to the establishment of discrete groupings within the General Ledger. Accountants want to examine all of their current assets or current liabilities. Inventory managers want the same degree of detailed control. The only method of accomplishing this is the availability of a numbering convention specified by the user. Define Item ID by Item Characteristics: Many commodities exhibit characteristics which lend them themselves to a description based upon their characteristics. Lumber, hosing and screws are but three examples. If a user stocks such commodities, the item ID should describe the item itself, and the system should have built into it a function which allows the user to identify the commodity type. The system would then ask for the items characteristics and build an item ID number automatically based upon those characteristics. Define Procurement Code (Make/Buy): The acquisition of replenishment material is the key to inventory management. This question asks whether the item master file helps users track whether an item is purchased from an outside supplier or made from scratch. Group Parts Using Similarities: Although customers and vendors and be classified according to "categories", many people do not think in terms of grouping inventory by classification. In fact items can be grouped by several characteristics. This question does not ask if a part can be assigned to a single product group, but according to several characteristics or similarities. Change Item ID and Transactions: If a user wants to change an item's ID number, the system should support that change, but also change the item ID number automatically in all current and history files. Supports Superseded Items: A superseded item is one which has replaced an existing item. It isn't really just a changed item ID number, but an entirely new, but similar item. In many instances the difference between the two is a difference in manufacturers. If a user orders the old part number, the system should immediately jump to the new item, but prompt the user that this item has been superseded. Combine Original and Superseded Item Histories: If an item has been superseded, and a user is examining the order or usage history of that item, the system should combine the history files together so that a single and complete picture can be painted. Multi-Line Item Descriptions: A single line may not be sufficient to describe an item adequately. Users should have the ability to define as many lines as might be appropriate to describe as item. Supports Negative On-Hand Quantities: In some cases item counts may be wrong, or items have been received but not yet reflected in the system. Rather than blocking a sale or blowing up in the face of users, the system should allow quantities on-hand to be negative. Item File Supports Item Picture: Although it may not be absolutely required, some users might wish to display a picture of an item as it is being ordered. This would be particularly useful as items are being sold over the Internet. Rather than using just the description of an item to confirm the selection, users and consumers would be able to use a visible image as confirmation.
Supports Serial Numbering: There are many reasons why a company might choose to identify each item with a serial number. One of the most important reasons is shelf life. Some products (and I am not referring to food items) may deteriorate over time. The only method of insuring that these items are shipped before the end of their shelf life is the identification of each item with a serial number and the subsequent shipping by serial number. Another reason may be for subsequent registration by the purchaser. If a company follows this practice, or it thinks that it might at some point in the near future, its software should have the capacity to assign and track serial numbers. Tracks Serial Numbers of Components: If an assembled item proves to be defective in the field, the problem usually is caused by the failure of one or more components. As such, users will need the serial number of the component, not the finished item for warranty purposes. Supports Lot Tracking: Lot tracking is similar to serial number tracking with one significant difference. All items in a lot carry the same ID number. This could be a batch of a commodity or a large number of the same item. Identify Customer(s) from Serial/Lot Number: If a component is proven to be defective after the finished item has been manufactured and shipped, users will need to contact each customer that has purchased that item. The system should be able to display the names of each customer to whom the defective part or batch has been shipped. Supports Multi-Dimensional Items: A multi-dimensional item is a single parent item with different characteristics such as size and color. Rather than assigning a unique item ID to each item, users can define the parent, the fact that it is multi-dimensional and the characteristics of the various dimensions. In the case of clothing the item would have two dimensions; color and size. Rather than having to define each item with a unique ID, the system would display the parent ID and ask that the user specify the specific characteristics, thus placing all items in the same general set of ID numbers. Supports "Requires Inspection" Flag: Some material may require inspection as it is being received. In order for receiving personnel to know this, the Item Master file must be flagged so that all receiving records will display this flag. Product Line Segregation: One of the primary item subdivisions adopted by many companies is based upon product lines. This is all that may be required by some companies. Shipping Weight: In most instances the weight of an item determines the freight cost. In this case the system should store the weight of the item and then calculate the total weight of each group if items being shipped as well as the total weight of the order. Shipping Dimensions: In some case the density of an item is the determining factor for shipping costs, not the weight. If that is the case, the system should store the dimensions of the item and calculate the total density of the shipment. Supports Shelf Life Tracking: Some items can be considered to be perishable. If they are, the system should track the date by which the item should be used, and prompt users when this date has been exceeded so the item can be disposed of. Picks Items Based on Shelf Life: If an item has a limited shelf life, and this could apply to a lot as well, the system should prompt user to use the oldest lot number or other marking number first. Converts Item to Dead Stock With Write Off: If an item can no longer be sold because it is too old or has been superseded by a more current model of the same type of merchandise, but the user does not yet wish to physically dispose of the item, the most practical way of recognizing this fact is to change the item status to what could be called Dead Stock. When an item is converted to this status, the system automatically writes off the total value of the item to either cost of goods sold or some other expense category.
Cycle Count Code: In many instances organizations cannot stop production to carry out a physical stock count. In such instances items are counted in small groups on a regular basis or cycle. This question asks if the system can assign a cycle count code to an item that will then prompt the user as to which items should be counted in the next cycle. ABC Code: ABC codes are codes assigned by the system to segregate items according to their dollar volume. Many companies use these codes to identify and examine slow moving items so that the slowest moving items can be discontinued or quantities onhand reduced. Movement Class: Movement classes are similar to ABC codes, but here the classification is based upon quantity volumes, not dollar volumes. Supports Consignment Inventory: Consignments are a special inventory category. This material technically does not belong to the seller. At the point of sale the seller become responsible for the cost of the material as if they had purchased it under normal circumstances. Companies such as this must have a specific routine for logging these sales and determining their liability to the vendor. Mass Change Cost Revaluation: Most systems allow users to change the cost of a single item. This question asks if it is possible to revalue all items containing a certain element. In most cases this would be used to revalue commodities such as metals where the cost fluctuates over time, sometimes quite dramatically. Alternate Vendors: The inclusion of a backup vendor(s) will enable a company to know to whom they should turn should the normal vendor not be able to provide the material requested. Copy Vendor Information for New Items: The process of establishing a new inventory item can be made that much more efficient if users have the ability to copy all of the information concerning a vendor from a previously established Vendor Master File. Default Revenue Account: As in the case of Accounts Receivable and Accounts Payable, the inclusion of a default revenue account in the Inventory Master File might make the invoicing routine more efficient. When an item code is specified on the invoice, the system will pull all of the details required, including the revenue account to which this item is normally associated. The user can override this code if required. Default Cost of Goods Sold Account: The same argument can be made for the assignment of Cost of Goods Sold. If an item is normally associated with one Revenue code and one Cost of Goods Sold code, the invoicing process can be made more efficient if the system can assign this code subject to user override. Sales Tax Rate: Some localities levy a sales tax on certain items and another rate on others. If this is the case, accuracy and efficiency will be increased if the system has the ability to store the tax rate for that item and assign it as a part of the invoicing routine. Excise Tax Rate: Some commodities such as tires, are taxed twice. The second tax is an excise tax imposed by the federal government. The system should have the ability to record this class of tax for each item affected. Supports Customer Rebate Programs: A rebate is a special form of discount given to customers, usually based upon the dollar volume during a given time period such as a month. The system has to have the ability to track the period in which the rebate will be tracked, track the value of all shipments during that period, and then automatically calculate the rebate. The rebate could be passed through to Accounts Payable as a voucher transaction, or to Accounts Receivable where the customer is given a credit on future purchases.
Rebate Posted as Voucher to A/P Automatically: If rebates are given to customers based upon monthly purchase quantities or dollar totals, the system should have the ability to calculate the amount of the rebate and then post that rebate liability to Accounts Payable as an unposted voucher. Since the voucher is unposted, users can approve the voucher and post it for payment. This eliminates any manual calculations and manual creation of a voucher. Reorder Point Adjusted for Vendor Lead Time: If an organization is to control its inventory levels, it has to maintain as little stock as practical. The point at which an automatic purchase trigger is generated cannot be a fixed point. It has to include both the forecasted demand during the next several weeks or months as well as the lead time it normally takes for the items to be received from a vendor. That lead time must include the time it takes to process an order, the time it takes the vendor to manufacture or ship the items, and the shipping time from the vendor to the receiving point. Define Commission Rate: There are a number of systems for calculating sales commissions. Given this, it seems that the efficiency of some systems would be improved if users had the ability to specify a commission rate for each item. Once this had been specified, the invoicing routine would automatically calculate the appropriate commission and report it to Payroll. Prevents Unauthorized Alteration of Records: Everyone knows that inventory will disappear. This is a fact of business life and must be addressed through the development of tight security systems. The introduction of automated inventory control will not reduce the likelihood of inventory shrinkage, and in some instances it may make the theft that much easier. We have discussed the use of passwords in general and the protection of employment records in particular. Inventory records fall into the same category. The innate weakness of automated inventory management systems must be strengthened by the addition of passwords and the establishment of other procedures to protect the system. The degree of protection must be determined by the user. It is sufficient to say here that this factor must be examined very closely.
Define Commission Types: Given the fact that margins will vary from item to item depending upon market conditions, users should have the ability to assign commission rates to individual items or groups of items depending upon any factor that might appear to achieve the sales goals of the organization. If commissions need to be based on the item itself, users might not want to define a specific commission rate to each item, but rather a code that places that item in a group with other items that follow a similar pricing or margin pattern. Once the group or commission type has been assigned, the commission rate itself is defined for the group, rather than the item. This allows users to change the effective commission rate for many items simultaneously. Define Commission Types: Given the fact that margins will vary from item to item depending upon market conditions, users should have the ability to assign commission rates to individual items or groups of items depending upon any factor that might appear to achieve the sales goals of the organization. If commissions need to be based on the item itself, users might not want to define a specific commission rate to each item, but rather a code that places that item in a group with other items that follow a similar pricing or margin pattern. Once the group or commission type has been assigned, the commission rate itself is defined for the group, rather than the item. This allows users to change the effective commission rate for many items simultaneously.
Item Status Code: The item status code tells the system how to group items, and in the case of non-active items, tells the system not to allow any activity.
Item File Includes Technical Specifications: In many instances an item being sold is a complex mechanical or electronic device where technical specifications are important to users as well as customers. In this case the user, particularly order entry personnel, will need to have access to this technical information which could be drawing numbers, technical specification text, schematic diagrams, parts lists, and any other information that might be required. Since the information that an individual user might require cannot be determined in advance, the system should give users the ability to define any number of files that contain technical information. In addition, users should be able to jump from a parent item and its technical specifications to one of the components and its technical specifications without having to do anything other than point at the component on the parts list or point at the drawing number to display the drawing itself.
Supports Bar Code Tracking: Most people are familiar with bar code tracking. This question tries to determine the functions supported by bar codes. As items are received, the receiving clerk should be able to select the PO to record the receipt, and then immediately have the system print bar code labels to be affixed to each item as it is received. In addition, the system should be able to translate the suppliers bar code and identify the user ID number from that bar code. Similarly users should be able to use a bar code scanner to record items for a physical inventory count and record items being picked for shipment (including serial number).
Cycle Count Code Based on: If items are to be counted on a cyclical basis, there has to be some "rule" that defines when the item will be counted. In some cases the ABC code as calculated by the system will drive the assignment of the cycle count code, or it will be based upon some user-defined criteria.
ABC Class Code Management: If a user manages 5,000 items, it's very difficult to review each of these items individually without some form of system support. This question tries to identify some of the ABC codes the system tracks and most importantly if the system has the ability to update this information automatically.
Manages Customer Owned Inventory: Many organizations stock not only their own material, but that of customers as well. Even though they may not own the material, they manage it just as if it were their own. In addition, they charge customers for storage, handling, and other services, as well as generating all of the standard inventory forms such as pick tickets, packing lists and bills of lading. This question lists several of the services that may be performed as well as billing options. Hopefully, the system will be able to meet all of these requirements.
Inventory Costing Method: There are several methods of determining what cost to assign to an item once it is sold. The choice of the costing method must be left to the user, and as such inventory modules should give users several choices. Many of these conventions are listed in this question.
Modify Standard Cost Based Upon: Companies that utilize standard costing will need to modify those standard costs from time to time, and that process should be automatic. This question tries to identify the basis upon which the standard costs will be modified as well as whether groups or all items can be changed in a single process.
Normal Vendor: The listing of the normal vendor for an item will improve a company's ability to place orders quickly and review recent statistics concerning the cost of that item. Once the system detects that the quantity on hand has reached the reorder point, that item can be called up. At the same time the Inventory Master File will seek the identification of the normal vendor and pull that information as well. The result is that the order can be placed extremely rapidly.
Pricing Conventions: There are a number of methods of pricing an item. Some companies use several price conventions, depending upon the product line or local conditions. This question asks whether the system has the ability to assign only one or multiple prices to an item and what the price conventions are.
Supports Warehouse Level: Market forces may be different in different regions for organizations that sell from multiple warehouses. As such, users might want to treat each warehouse as almost the equivalent of a separate company where pricing is based upon local conditions. Therefore, users should have the ability to maintain completely separate cost and price structures for each warehouse.
Customer Price Matrix Options: Market forces demand that users be able to create special pricing matrices for specific customers or customer groups. A good example of a customer group might be wholesale and retail customers. In addition, specific customers might be given special pricing either across the board, for specific items or for specific item groups.
Other Customer Contract Options: Competitive and market forces have created the need for special customer pricing options. In addition to the variations listed in the previous question, this question tries to highlight additional variations, functions, or options. If a customer specific rate table is to be used, is it possible to maintain several contracts for the same customer? In addition, when the rate table is created, is it possible to copy an existing rate table, thus reducing the time it takes to create the new one? If a contract is negotiated, is it possible to track the quantities or dollars purchased, and then subsequently calculate penalties if the volume is not achieved?
Reorder Conventions: There are as many reorder conventions are price conventions. This question asks whether the reordering must be handled manually or with the assistance of the system (i.e. the system will flag those items to be ordered and suggest the quantities to be ordered). This question also identifies the various reorder methodologies used by the system.
Reorder Control Includes: While the setting of fixed reorder points may work quite well for smaller distributors, those organizations with thousands of items in stock need more sophistication when it comes to determining when an item should be reordered from a supplier. In most instances users rely upon some form of forecast whereby needs are anticipated. The analysis can be based of several factors including the most recent sales history projected into the future, actual sales forecasts or estimated production. In addition, the forecast, particularly if it is based upon sales history, must ignore or otherwise take into consideration seasonal fluctuations. Finally, the history-based forecast should ignore or minimize the effect of extraordinary orders which have a tendency to exaggerate demand.
Vendor Lead Time: If a material is required, one of the most important factors determining when that material should be ordered is the time it typically takes a vendor to deliver the goods once an order is placed. If a vendor's lead time is lengthy, either more of an item has to be stocked or the sooner that item has to be ordered. This question lists some of the factors that must be taken into consideration as well as the internal mechanics by which the necessary calculations are performed.
Reorder Control Includes Internal Lead Times: The time it takes to complete the entire acquisition cycle must be taken into consideration when reorder points are determined. Here we are dealing with factors internal to the purchasing organization. Certainly there will be a delay between the time an item reaches its reorder point and the actual purchase order is issued. In addition, some parts may be manufactured internally, in which case production delays must be taken into consideration such as setup and run times, expected queues at specific machines, and even delays as material waits to move between one process and another. All of these internal factors must be taken into consideration.
Inventory Control / Assembly Systems: There are any number of activities that control how goods are received, stored, assembled, and ultimately shipped. This series of questions helps users understand some of these potential functions that may be of interest.
Data Input and Cost Distribution: Inventory information drives not just the shipping and receiving process but also the distribution of those costs to various departments and activities.
Receiving Activities: While many accounting systems support the notiation of a receipt of goods, that is cetainly not the way it happens in real life. This series of questions highlights the receiving process and all of its many individual activities.
Shipping and Withdrawal Activities: Once an order has been received, the objective of the exercise is to ship the goods to the customer as quickly and efficiently as possible. In some instances the shipping is internal only with the goods being sent to a production line. This series of questions traces each of the steps necessary to get material where it needs to be consumed.
Financial Reports: Once data has been input into Inventory, users will probably need to review slices of that data to determine if costs are in line, where costs are being incurred, and how those costs compare against other benchmarks.
Job Initiation: The process of setting up a job is similar to setting up any other master file. First you have to define system defaults. Then you define how the system is going to work. Finally you define the jobs themselves. Job Setup (General): This section lists setup type functions and features that do not fit into any one specific category. DCAA Approved: The Defense Contractor Audit Agency maintains a list of software products which track and report information according to rules which the agency has established. The fact that a product does not meet the DCAA terms does not mean that a project/job costing system cannot be used for government contracting, but it might mean that some of the reports required by the government might have to be prepared manually. Automatic Job Numbering: Most numbering conventions are designed for one purpose only; to separate one item from all others and to find that item quickly. Companies assign numbers to each job for this purpose, although smaller companies might never refer to the job by number, electing to call the job by a description referring to the customer or the locality. If the job number serves no other purpose, it would make sense for the software to assign the next available number automatically, rather than having the user maintain a separate manual list of available numbers.
User Defined Numbering Convention: Those companies choosing to assign special numbers usually do so for sorting purposes. In this case the numbering convention could be specified when the system is installed so that the screen will prompt the user to identify the variables which form the job number. Job Cost Estimating: Estimates usually serves two functions; bidding and budgeting. Many companies must supply information to potential customers prior to the awarding of a particular job. This information could be rough estimates or it could be a formal bid. The level of detail required could vary from a summary of the projected labor and material cost to a specification of each part and a projection of labor hours and cost in each of several categories. Estimates should be as accurate as possible because they have the potential to affect the very life of a company. Some estimates can become quite complex and the more complex they become, the more likely it is that mistakes will be made. Although automated estimating programs are quite complex and take some considerable time to initiate the first time, they can give companies the ability to generate more estimates in shorter lengths of time than manual estimating.
Convert Estimate to Budget: Estimates, once accepted, should form the basis for budgetary comparison as a project proceeds through its various phases. This may be one of the most important aspects of Job Costing. Budgets serve as the bench mark for cost and profitability. Since the budget was established using the software, it would make sense for the user to have the ability to transfer that information to the job once accepted. Supports Multiple Budgets With Revisions: As larger jobs and projects proceed over time, changes will be required. This question asks if the system has the ability to support multiple budgets, change those budgets, and review both the current and any past budget. Assign Default Invoice Format per Client: Although most printed invoices present sufficient information for customers to approve them and process them for payment, some customers may require specific information presented in a specific format. If this is the case, the accounting system will have to meet the customer's invoicing requirements or run the risk of the customer rejecting the invoice or taking longer to process it for payment. This question asks if the accounting system supports the storage of customer specific invoice formats and the printing of these formats automatically without the user having to remember that this particular customer requires a different format than standard. Automatically Calculates Additional Billing: If an engagement, service or task is based upon a fixed fee, but additional services are provided, this question asks if the system can identify these additional services and bill them automatically. Supports Future Billing Rates: If the billing rates are due to be raised by a certain date (say the end of the year), these rates should become effective automatically. Here the user would specify what the rates will be and the effective date. The system would store this information and update the rates automatically. This eliminates the necessity of changing rates in a panic on a specific date. Automatically Updates Billing Rates: As was indicated in the previous question, if rates will change on a specific date, the user should be able to specify those rates in advance and the system would automatically place them into effect on the date set. The key here is that the system itself takes care of the update process automatically.
Master Labor and Material File: One of the most time consuming and difficult tasks in determining what a job should cost is determining what each item will cost. The cost of each labor category and each individual piece of material must be determined. This can take quite some time. This whole process can be made considerably more efficient and less time consuming if standard labor rates and material costs are made a part of the estimating file. The updating of this file might seem to take quite some time and it does. The time it takes to maintain this file though is less than the time it takes to look up the price of each item which might be used times the number of jobs on which that part might be used during the course of the year. The long term savings can be large for those companies bidding on a number of jobs each year.
Store Estimates: Some jobs tend to be repetitive. If this is the case, companies might wish to store and recall a particular estimate for use on another job. This is not to say that the jobs have to be identical. The fact that they are essentially the same gives users the ability to turn out a completed estimate in less time than required for the first one. Update Template With Current Costs: A estimating template saves time, but a template containing out of date information is no help at all. If templates are going to be used efficiently, users must have the ability to input the current cost for labor and material. Vendor Provided Standard Categories and Phases: This question is related to the one concerning the Chart of Accounts. It might take quite some time for users to specify all of the cost categories and phases required. Although there are many different combinations of cost categories and phases spread out over a number of industries, the system should provide as many as possible to the user as a standard. The storage room required would be quite small, and the existence of predefined categories might enable users to bring their system up to speed more rapidly. Segregates and Identifies Subcontractors: As stated earlier, one of the primary uses of estimates is the comparison of actual costs versus estimates. If users are going to paint a detailed picture of a project, they must have the ability to examine each cost component in detail. Subcontractors may form the majority of the projected costs for a particular project. These subcontractors might replace labor and materials the prime contractor might supply if so inclined. Given this, each subcontractor should be thought of as a single line item requiring detailed analysis and control. Automated software will not help them very much if users do not have the ability to examine the cost of each subcontractor individually. New Job Initiated Entirely From Job Cost Module: Job Costing is a complicated task, particularly for an automated system. This might sound somewhat startling considering the fact that the objective of automated accounting is greater simplicity. Consider the process which might be followed in a manual system. An accounting clerk receives an invoice for a particular job. The clerk opens a file for the job in question and notes the details of the invoice. It can be that simple. If the invoice happens to be complicated, the clerk may elect to make a copy of the invoice and place it in the job file as well. Once posted in the job file, the invoice is processed identically to other invoices. The processing of the same invoice in an automated environment may be somewhat more complicated. Information must flow into and possibly out of the Job Cost module from/to all other modules. Because it tends to be somewhat complicated, users need as much assistance as possible so that the whole system works efficiently. One method of accomplishing this is to initiate the job from only one place in the whole accounting package, namely the Job Cost module itself. All instructions necessary to make the system act as a single unit should be specified in one place, rather than forcing the user to enter several modules as a part of the process of initiating a single job.
Stores Data for Completed Job: The information from a completed job might serve several useful purposes. Rather than using past estimates, some companies might decide to use actual jobs for estimating and budgeting purposes. Should a discrepancy or dispute arise, the information can be recalled quickly. The desires of the customer should dictate whether any filing system is required, and whether the information needed be in summary or detail. Stores Data for Completed Job: The information from a completed job might serve several useful purposes. Rather than using past estimates, some companies might decide to use actual jobs for estimating and budgeting purposes. Should a discrepancy or dispute arise, the information can be recalled quickly. The desires of the customer should dictate whether any filing system is required, and whether the information needed be in summary or detail. Supports Job/Project Types for: While many organizations require some form of job costing, in many instances the industry in which they compete will dictate what type of job or project costing system they require. This question asks each vendor whether their job and project costing system will supports the needs of users in the industries listed.
Job Types Supported: There is no one standard job or project. Some may accrue work in progress, while others may not. Some companies may need to track detailed project costs over multiple years, while others may just want to track the costs and possibly revenue from a short--term activity such as an advertising campaign.
Job Definition File Contains: Although there is any amount of information a job file should contain, we have elected to list some items that may not be found in some systems. Probably one of the most important items is the ability to describe a job in as much detail as might be required. This implies the existence of an unlimited text file that would let users input whatever they thought appropriate. On other item would be very useful and that is the existence of at least five user defined fields to track whatever needs to be tracked.
Job/Project Front Office Support: Job and project costing requires more than just the ability to record and analyze costs. In many instances the user will need other job and project related functions to serve their clients effectively. These additional functions all relate to customer support as well as organizational issues that have some effect on customer service.
Default Billing Rates: There are any number of methods by which a client can be billed. It may depend upon the person doing the work or the work itself or it may be based upon rates negotiated with the client. This question lists some of the methods by which default billing rates can be assigned.
Billing Formats Supported: Depending upon the nature of the job and the agreement reached between the service supplier and their customer, the methods by which a client can be billed may vary widely. This question lists many of these billing options and asks if the system supports such options.
Bill to Functions Supported: In some instances an engagement will require slightly different billing procedures. The work may be done for one organization, but billed to another. It may be done for one department, but the invoice sent to another address. This question lists some of these possibilities.
User Defined Line Item Cost Detail: Most job costing programs divide costs into a combination of cost categories and phases. Cost categories could be labor, material, etc. Phases could be foundations, electrical, etc.. Some users might wish to see as much detail as possible, while others wish to see summaries only. Most are somewhere in between. If the cost system is going to meet these varying sets of needs, it must be flexible. This requirement can be met best by giving users the ability to define the level of detail in as much detail as they desire.
Tracks Start/End Dates for: Most systems track some dates for jobs and projects. This question asks if the system has the ability to track both the start and end dates for the whole job as well as each phase and sub-phase (activity). Tracking the cost of jobs is but one portion of job and project systems. The other major activity is the control of each part of a job or project, and that requires target dates so that users can determine if each part of the job or project is on-track.
Tracks Costs for: Although all job costing systems have the ability to track direct costs, this question asks if the system has the ability to track other forms of costs which can be associated with a job or project, including direct administrative costs (portable office rental, electricity, etc.), indirect labor and material (overhead costs which can be associated with a job but which are not usually billed to clients), and non-billable or non-productive costs (down time for direct labor that normally would be billed to a client).
Data Input and Cost Distribution: Once a job has been launched, cost information will flow into it either directly or from other applications such as Payroll, Accounts Payable, and Inventory. The key to the success of any job related organization is allocating costs to jobs accurately and in a timely manner. Once the actual costs have been posted to a job, manager can control that job and bill for the work done.
Job Control: Small jobs are relatively easy to control. Larger jobs may be so complex that several people may act as managers. In cases like this it is very easy to lose track of costs and labor. This section lists some of the support a business management system can provide.
Cost Analysis and Reports: While it is important to post all costs to a jobs, it requires some degree of study to make sense of this information. This section lists some of the activities and information managers may need to help them control each job.
Job Invoicing: Collecting cost information is the first and most important step, but if those costs are not billed properly and billed at all, then all of the control efforts of managers goes to waste.
Equipment Files: Equipment files perform the same function as master files for customers, employees, etc. Equipment Files (General): The master files that need to be set up for assets are similar to all other master files. This series of questions lists some of these procedures. User Defined Equipment Master File: As with every other file we have discussed, many users might wish to track certain information unique to their industry or their individual company. Under these circumstances they might be interested in software which permits them to design their own master file for each piece of equipment or provides a number of blank fields to be used for any user purpose. Asset ID Permits Grouping by Category: The ID assigned to a particular asset should have the ability, not only to identify a unique item, but also to group that item with other items in the same class. If this is important, users should check to make sure that this type of sorting can be accomplished by their software. Supports Assignment of Serial Numbers: A serial number is a second tier in the identification of an asset. Although it can be the identification number itself, serial numbers tend to be quite complicated and therefore do not lend themselves to this purpose easily. The serial number might be the identification number assigned by the original manufacturer. All of this leads to the necessity for the listing of two identification number; the primary asset number and the serial number. Although discussed in another section of the book, users should check the field length allowed for serial numbers as it might not be long enough. Identifies Original Manufacturer: In many instances equipment is not bought from the original manufacturer, but an intermediary. However, the user might want to keep track of the original manufacturer as well as the intermediary. Identifies Current Location: Who has direct control of an asset? This question might be asked several times each year in a multi department organization. The location of the asset is important for two reasons. Department managers should know what assets have been assigned to them, and the location number could be used by the accounting system to allocate depreciation. Identifies Current User: Although users will need to know the current location of a fixed asset so the department or group can be charged depreciation, they might want to know the individual person responsible for equipment as well. This is particularly true for mobile assets such as laptops, etc.
Prepares Property Tax Reports: Property taxes are a fact of business life. Since property taxes are based on fixed assets and leased equipment, the system should have the ability to record the various tax jurisdictions to which an organization has to pay property taxes, and then prepare a list of equipment (including leased equipment) that is subject to property tax. Tracks Status of Capital Projects: As capital projects proceed, it may be possible to begin to charge depreciation before the project is completed. This question asks if it is possible for the system to track capital projects, and then calculate depreciation based upon the status of the project. Supports Asset Groups: Rather than determining the depreciation for each asset item, some users might be interested in a system whereby smaller assets are assigned to an asset group. This is not unlike a spreadsheet process whereby the cost of the item is added to the group, and then a new depreciation amount determined. This reduces the number of depreciation transactions each month, which for larger organizations can amount to several thousand. Supports Equipment Leasing: Leasing is just another form of financing. Even though a piece of equipment might be leased, depreciation can be charged, and that depreciation needs to be allocated to the proper department or group. This is a two part question. Users need to know if the system has the ability to track each lease, and whether that tracking system is within the Fixed Asset module or another module. Finally, users might want to know if the system has the ability to notify them when a lease is about to expire.
Default Distribution: The depreciation of an asset must be charged to some account. The Equipment Master File should contain the General Ledger account to which depreciation will be charged, the Job Costing account to which it will be charged (should the user charge depreciation to each job), or the department to which depreciation will be charged. It is obvious that all of these accounts need not be active at the same time. Indeed some are mutually exclusive. The system must know where to charge depreciation and the Equipment Master File is the most efficient means of indicating this.
Depreciation Methods: There are four basic depreciation conventions listed in this question. The first three listed are known to most people. The Unit of Production method bases depreciation upon the number of units a particular machine produces. This is a logical choice for those machines whose life is limited and is a function of the production of that machine. Although not a question which can be answered in the format chosen here, users should be aware that there are many depreciation conventions available. There might be as many as twenty depending upon the rate by which a user chooses to depreciate an asset. Given this, users should insure that the package they are examining supports the depreciation method currently utilized.
Calculates Simultaneous Depreciation: Many companies choose to manipulate income and expenses depending upon the audience reading the reports. The Income Statement sent to the IRS will take advantage of every conceivable tax deduction. The financial statements reported to shareholders might tend to dampen out any violent swings in income or expenses (shareholders and the investment community prefer smooth graphs). The management of the company wants the "true" picture. If this is the case, many companies elect to adopt three different depreciation methods, each being aimed at a different audience. Under this set of circumstances they could recalculate depreciation manually or their system could calculate and store each method chosen automatically.
Cost Calculation and Distribution: Once an asset has been acquired, its acquisition cost must be amortized over a period of years. This section lists functions that control that process.
Reports: Just has been found in every other application, users will need to access reports that analyze depreciation.
Order Entry (Set Up): Order entry is not just about taking orders and subsequently shipping goods. There are a lot of other activities that need to be considered when an order entry system is set up. This series of questions lists some of those functions and activities. Order Entry (General): While most of the questions under this order entry set up section can be grouped, this series of questins are more general and apply to the whole system rather than specific aspects of the application. Supports Manufacturer's Agent Sales: A manufacturer's agent is an independent individual or organization that is authorized to sell merchandise on behalf of specific manufacturers. In most instances the merchandise is actually shipped from a wholesale or distribution warehouse rather than direct from the manufacturer. The customer purchasing the merchandise is responsible for the bill, while the agent collects a commission either from the manufacturer or wholesaler. This general question asks if the system can track this class of sale and calculate and pay the resulting commission automatically. Post Commission to Payroll Automatically: Once a salesperson's commission has been calculated and approved, users should be able to instruct the system to post this information to the Payroll module for processing as earnings. This posting process should be automatic. Supports Cash Drawer: Although Order Entry can be found in an environment not requiring a cash drawer, most or all of the functions can be found in a retail setting as well. This question asks whether the system supports a cash drawer and whether the system will open the cash drawer at the proper time. Cash Drawer Balancing: All retail companies have cash drawers, and the task of balancing the cash drawer can become a tedious and time consuming task. This does not necessarily have to be the case. The software can assist users in balancing the cash drawer at the end of the day or at the change of each clerk, depending upon the procedures established by the company. This balancing might support the input of all checks, credit sales slips, coupons, and cash deposits. All of these should equal to the net sales for the time period in question. Any discrepancies would be indicated against the item in question, such as cash.
Calculates Change Due: The process of determining the change due a customer may seem to be straight forward, but the time lost over the course of one day may be significant. Any delays while the clerk is making this calculation may leave a negative impression with the customer. This rather insignificant problem can be overcome easily if the software has the ability to calculate the proper amount of change due for any transaction. Supports All Inventory Functions: Order Entry and Point of Sale systems should be tied to the Inventory module as one of their prime functions is the selling of products. Supports Restocking: Some retail companies do not maintain a central warehouse, but elect to adopt a policy of warehousing at each retail outlet with all purchases being shipped directly to the appropriate outlet. In this instance the retail outlet must have access to the inventory module to note the restocking in the records properly. User Designed Data Entry Screens: It is likely that some employees utilizing Order Entry or Point of Sale will be temporary or marginally skilled people. As a result, the screens they see must have the ability to describe exactly what is required of them. Many companies might wish to design screens suited to their particular industry or employee skill level. Although the data will be input to the exact same fields, the redesigned screen might reduce input errors. Supports Bar Code Reader: The process of recording sales item numbers manually can become quite time consuming and subject to any number of errors. Considering the fact that bar code labels are pre printed on many products as a standard feature, it makes sense for some retail establishments, particularly those employing part time and minimum wage employees, to utilize the power of bar code readers to reduce these errors and employee data entry time. Prints Price Labels: While the presence of bar code labels might assist retailers at the cash register, some means has to be devised to indicate the price of each item. There are many devices by which users can mark prices on an item, and one of these might be the software and printer themselves. The user would simply specify the item number to be priced and the number of tags required. The system should print the item numbers as well as the price. This virtually eliminates the necessity of looking up the item number at the check out counter. Prints Bar Code Labels: Although asked in another section, this question asks whether the system prints the bar code labels as a function within Order Entry or Point of Sale. Primarily Designed for: Not all order entry systems are designed to handle all forms of business. Some may serve specific types of orders, and that is what this question is all about.
Agent and Commission Structure: In most instances the commission rates for manufacturers agents are not that difficult to calculate. The problem is where these people are defined. They are not salespeople because they are independent contractors. In actual practice they are more like vendors, but they supply nothing directly. This question asks where the commission structure and identity of a manufacturer's agent is defined.
Commission Splits and Overrides: Although most systems support the calculation of sales commissions, many companies with multiple levels of salespeople have adopted fairly sophisticated commission structures. The inside salesperson may receive one rate. The customer field representative may receive a commission as well. That person's regional manager may receive an override. This question tries to determine the degree of sophistication that is built into the commission structure for each system.
Commission Based Upon: It seems as though every company has a different way it wants to calculate and pay commissions. Some base it on sales revenue while others wait until a customer has actually paid their bill. The commission may be based on sales revenue, gross margin, or net profit which includes overhead cost allocations or the profit made on a particularly large job. Some assign specific rates for specific items, while other companies set rates for individual salespeople. Finally, some companies require salespeople to achieve certain monthly targets before any commission will be paid or pay no commission if the order is too small.
Commission Review: Although salespeople may not like it, some organizations prefer to review commission calculations prior to payment. Managers may spot an error, or a sale which does not qualify for commission, or an incorrect rate. If review and changes are necessary, the system should give users the ability to review each sale and then make any modifications which are required. Salespeople need to know why a sale was modified, so the system needs to support a routine whereby the sales manager can describe why a modification was made. The original and modified calculations as well as any accompanying notes should then be printed and forwarded on to the salesperson.
Supports Payroll Timekeeping: If the accounting system is tied into the sales floor, it does not make a great deal of sense for any process to require the manual input of information more than one time. Payroll is just such a process. Hourly employees should be able to prepare their time cards themselves, and there are any number of methods of accomplishing this. All of them involve the logging of time into the software on the retail floor. This information can then be checked for accuracy by the appropriate manager and transferred to the payroll department for processing. Some employees may be commissioned in part or in whole. Just as the system should have the ability to receive hours, it should have the ability to calculate commissions based upon the revenue calculated each time an employee prints an invoice or order.
Supports Warranty Handling System: When a customer calls in with a complaint concerning a possible warranty claim, users should not have to research manually any information concerning the original shipment or warranty terms. The system should support a special inquiry screen that lets people see the details concerning the original shipment as well as all warranty qualification information. This includes any warranties offered by the company itself as well as any original manufacturers warranties. In addition, users should be able to input any notes concerning the customer's claim, pass that information on to anyone else that might be involved in this claim, tie into an RMA (Return Material Authorization) system to issue an RMA, and finally notify the receiving department that a return is expected. One last feature should be present. Although most reshipments are not scheduled until the defective merchandise has been inspected, users should have the ability to issue a no-charge sales order to replace the merchandise immediately, rather than waiting until the material has been inspected.
Order Receipt: The process of receiving an order can be quite simple or it can be quite complex depending on the nature of the order, how it is recorded, and the industry in which the user competes. This whole section deals with various aspects of the order receipt process.
Order Tracking: To assume that once an order has been received is a mistake. Anything can happen to prevent an order from being shipped on time or delivered on time. This series of questions list functionality that will help users track orders from the day they are placed to the day they are delivered.
Shipping: The process of actually getting a shipment out of the door can become quite complex as well as quite costly. This series of questions lists some of the activities that can be enhanced by a well designed business management system.
Invoicing: Once a shipment has been dispatched, invoices should be printed as soon as possible. This series of questions lists some of the procedures that business management system can support.
Reports: As is the case for all other applications, the reports coming from the Order Entry system should help users get shipments out the door efficiently and on time and also learn where improvements can be made.
Budgeting (General): This series of questions lists general questions about the budgeting process supported by the business management system.
Supports Comparison Versus Budget: The most fundamental question to be asked is whether the software supports budget comparisons in the first place. Some might say that budgeting is one of the most important aspects of running a business. One cannot establish plans to improve performance if they do not have some means of determining where they are, where they want to be, and the difference between the two. Budgeting can be a very important tool for many companies and might be a complete waste of time for others. The time required to prepare a realistic budget is enormous. Budget figures cannot be pulled out of the air. They must be based upon detailed facts which have been thoroughly analyzed. If the basis for the budget is unsound, the budget is worth nothing. Once a budget has been prepared, it must be utilized. The production of comparisons mean nothing if action is not taken as a result of variances from the budget. The most accurate and realistic budget is just as useless as an ill conceived budget if management does nothing with it.
Supports Separate Internal Budgeting Module: Although it would be nice to consolidate all budgeting activities into one module much like Accounts Receivable or General Ledger, the point of this question is that the software segregates budgeting and all of the information concerning the budgeting process into one section of the program. Integrates With Third Party Budgeting System: In many cases the process of budgeting can become very complex to say the very least. This has led to the creation of third party products specializing in budgeting. Rather than trying to compete against these specialized systems, many vendors have adopted them as their own system. This use of best-of-breed systems is very common in this financial management industry. Supports Monthly Budgets: Many companies consider their sales, and therefore profitability, to be seasonal. This is particularly true for retailers. Fifty to seventy percent or more of their revenue might be generated during the few months preceding Christmas. If these companies elect to establish budgets, the information should reflect the fact that there is such a drastic swing in revenue. A system supporting an annual budget only (i.e. each month is 1/12 of the annual budget) will not serve their needs. They need a budget for each month of the year. Supports Multiple Budget Revisions: Although forecasts might need to be revised as a fiscal year progresses to reflect the realities of the market, budgets should not be changed unless there is a very good reason to do so. Once a manager commits to a certain set of spending or revenue production goals, they should be held accountable for those targets. However, there may be certain circumstances where factors outside the control of the company or individual departments will render a budget unrealistic. In this case the budget should be changed, but the original budget should be stored for comparison sake as well. The system should allow users to revise the budget, but maintain a file of each previous budget as well. Maintains Budget Revision History: As we discussed in the previous question, the system should give users the ability to change a budget, but it should also maintain a file of each previous budget so the sake of comparison. Supports Non-G/L Budget Groups: This question is somewhat similar to the one following, but asks a very pointed question. Rather than having to tie budgeting to a specific General Ledger account, the whole budgeting, review and control process may be served more effectively if budgeting were removed from the General Ledger altogether. In this case completely separate budget groups would be defined and assigned a unique ID number, not unlike they might be in the General Ledger. Budgets for each of these groups would be determined by individual managers, and costs assigned to each group by using a separate field during data input. This would give users the same detailed reporting structure, but make the system itself more flexible by not having to tie it to a General Ledger account number.
Supports Budget Roll Up System: If budgeting is removed from the General Ledger, and budgets for each control group were to be defined, then it would be possible to roll up each lowest level budget unit into higher level reporting units, but without having to define a budget for that unit. Supports Multiple Year Budgets: In some cases, particularly for capital projects, various sales and marketing campaigns, and other projects, particular costs will be incurred over the life of the project or activity, and that activity cannot be tied to fiscal years. In this case the budget should be for the life of the activity, rather than the fiscal year. Supports Budgeting for: All accounting systems support budgeting for any General Ledger account. However, there may be subsidiary activities which require some form of budgeting as well, even though these activities aren't "listed" in the General Ledger. This question tries to determine if the system can support some form of budgeting outside the General Ledger. Supports Budgeting for: All accounting systems support budgeting for any General Ledger account. However, there may be subsidiary activities which require some form of budgeting as well, even though these activities aren't "listed" in the General Ledger. This question tries to determine if the system can support some form of budgeting outside the General Ledger. Supports Budgeting for: All accounting systems support budgeting for any General Ledger account. However, there may be subsidiary activities which require some form of budgeting as well, even though these activities aren't "listed" in the General Ledger. This question tries to determine if the system can support some form of budgeting outside the General Ledger. Review Process: Before a new budget can be created, users should review the results from last year as well as before. This may give them trend information that will be useful when establishing a new budget.
Construction of New Budget: The actual process of constructing a new budget can be fairly simple or very complex depending on the nature of the business as well as their desire to split the budget into very small pieces.
Cost Components Supported: The cost of a product is more than just the total cost of all material that comprises the item. This question lists several of the more common cost components.
Costing Mechanisms Supported: There are many different methods by which items can be costed. This question lists some of the more common methods.
Cost Generation Mode: While most non-manufacturing systems base costs solely upon purchase costs, manufacturing costing can become quite complicated. The calculated cost of an item or subassembly needs to be fixed for a period of time so that it can be
Cost Buildup Methodology: The cost of an item is not just the cost of the raw materials that make up that item, but the materials, production costs, etc. This question asks whether the cost is calculated by part number or by cost type.
Product Costing Reports: There are any number of reports users might want as they try to control product costing, and the question lists several reports that should be useful.
Local Support Provided in: This question identifies whether the vendor has either satellite offices or local resellers and/or consultants in specific countries and regions.
Languages Supported: This question lists some of the more common languages which users might require. If the language a user is not listed, the vendor will have to be queried manually if they support that language.
Simultaneous Multi-Lingual by User ID: In many countries, including the United States, multiple languages might be spoken. In cases such as this, individual users should have the ability to select their language of preference, and have the system defaul
VAR/Reseller Channel: Most middle market business management systems are sold through VAR or reseller channels. This series of questions tries to help users understand how each vendor's channel operates. In the end the user will have to determine for themselves if the individual reseller with whom they may be working is best suited to their unique set of circumstances. VAR/Reseller Channel (General): This series of questions presents general information about a vendor's reseller channel and how it works. Requires Initial Product Certification: While an individual or organization may say they are licensed to sell a particular product, that does not necessarily mean they are fully qualified. This question asks if the vendor requires that its resellers become certified in the product before they are licensed to sell the product. Requires Recurring Product Certification: While a vendor may require that a VAR or reseller become certified in the product before being licensed to sell that product, this question asks if the vendor requires that all VARs and resellers pass regular or recurring certification tests to remain licensed. This will ensure that the VAR or reseller has been tested on the latest version of the product and has not lost their ability to serve their clients effectively.
Vendor Certified Add-On Program: All accounting products will not meet all users' needs out of the box. That's why there are so many add-on products available. Resellers, VARs and developers can create these products for their clients or they can create them for resale to other users. This question asks whether the vendor has established testing programs whereby these products are examined in detail by the vendor and certified as being compatible with their product. Internet Listing of Add-On Products: This question could be for users or other VARs and resellers. If an add-on product has been created and may be of interest to other users, how will these other users know such a product exists? The only effective way this can happen is if the vendor creates a listing of such products on their Web site or one dedicated to their resellers. In some cases access to this Web site may be restricted to resellers only, and users will need to know this as part of their purchase decision process. Partner Board Drives Software Development: The bottom line to this question is who makes the decisions as to the development of a product. While the vendor is 100% responsible for creating new additions, they should at least receive input from their channel and hopefully their users. This question asks if this partner board has the power to vote/dictate or suggest strongly what new features should be added to the product. Internet Listing of Channel Members: This question is very sensitive to vendors as they do not want other vendors to learn the names of their channel members and try to recruit them. On the other hand, users and resellers may need to access this name list. Prospects need to know who to contact if they are interested in a product. In most instances the vendor will give them the name of a local reseller or perhaps several names. Users may not like this and want to know the names of more people and make the decision themselves as to who they will contact. Internet Listing of Open Sales Opportunities: New prospects are developed by resellers as well as the vendors themselves. This question tries to address how the names of new prospects are distributed to the channel and there probably is not one good way. Resellers live and die by attracting or contacting new prospects. Maybe one way to make this fair is to post the names of new prospects on a reseller only Web site and let the most aggressive resellers (or even several resellers) contact the prospect. Vendor Supported Opportunity Management: Most resellers do not like to sell nor do they do it well. That's because their expertise lies with the product and many feel uncomfortable selling. This question asks if the vendor tries to assist its channel in the selling process by providing their channel a Web based opportunity management system that lets resellers track their leads. Reseller Can Profile Their Target Market: Many vendors have hundreds to thousands of resellers. Some resellers choose to concentrate in one or more market niches or customer size while others serve all markets. If the vendor is handing out leads, resellers should be able to file with the vendor (hopefully via the Internet) a profile that describes exactly what markets are of interest to them. It makes no sense for a user to talk to a reseller who does not really specialize in their market. Vendor Sales Organization: There are three basic forms a vendor's sales organization can take. It could be exclusively via VARs and resellers. It could be direct sales only with no VARs and resellers. Finally it could be a combination of both.
Reseller Education Opportunities: From the perspective of an individual or organization that is interested in becoming a reseller, they may want to know the extent to which the vendor provides on-going educational opportunities and where these classes may take place.
Resellers Can Access/Download: Resellers need as much help as vendors can provide when it comes to the selling process. The vendor has the funds to invest in market research or create powerful sales scripts or even effective brochures. It makes sense for vendors to do this and this question asks what specific information is available to resellers via the vendor's Web site or print media.
Industry Specific Modules: This series of questions lists various major industry segments and asks vendors if they have applications that serve these specific segments.
Presale Information (General): These questions are very general by their nature and list factors that cannot otherwise be categorized.
Presale Information: This information lists information not tied to specific accounting applications that may be of interest to users before they make their final purchase decision. Client Operating System: There are any number of operating systems available today, and there are two methods by which users can select an appropriate operating system. Select the accounting system first, and then purchase an operating system compatible with the accounting system. Or, select your hardware first, and then select an accounting system compatible with your hardware. This is one of the features where an input value of "9" would be appropriate. This particular system has two purposes. First it indicates the operating system for LAN-based accounting systems where there is but one operating system throughout the entire network. Second, it identifies the operating system supported for the client or workstation side of a client/server accounting system where the two might be different.
Server Operating System: The other half of a client/server accounting system is the operating system supported at the server level. This question lists a number of server platforms that might be supported in a client/server operating environment.
Databases Supported: Given the fact that many companies prefer certain databases due to individual preferences, the size of their network, their past expertise, or other factors, the database a system supports may be one of the make or break decisions. If a product does not support a specific database, the user will not be interested in looking at that product further, regardless of how close the system matches the user's needs in all other respects.
Programming Language: As in the previous question, the language in which an accounting system is written my be very important to a potential user, particularly if they have already developed an expertise in one particular language. Rather than having to learn a new language, users should be able to see their options for the programs which support their preferred language.
Client/Server Structure Supported: The basic distinction between some client/server systems is whether they are two, three tier or n-tier. Two tier systems support processing at the server as well as the workstation, while three tier systems typically separate the database from the applications and place them on their own servers. Some people prefer a two tier system while others prefer a three tier system. An n-tier system allows users to define where processing for specific operations will occur. While this is the most complex arrangement from the point of view of system management, n-tier processing is the most scaleable, allowing users to define which server will be assigned the task of processing specific tasks.
Other Client/Server Options:Recent changes in client/server computing has added other options to the mix. Fat/Thin Clients refers to the load carried by the server vs. the workstation. Fat clients carry a significant data processing load, while thin clients are analogous to dumb terminals where it is possible to operate without a hard drive. In addition, some software vendors have even developed their thin client structures to the point where the desktop contains no more than an Internet browser, and that is the communications channel to the accounting applications. The browser concept reduces the cost and complexity of setting up desktops, and enables organizations to support a single common access methodology, regardless of whether users are in a headquarters building or on the road accessing the system via the Internet.
Supports Wireless Device Access: While many products can access the core accounting applications via the Internet and a browser, there are other ways that are becoming just as important. This question lists some of those alternative access options.
Wireless Access Functionality: If a user can access their accounting applications via a wireless device, the real question then is which applications they can access and that is the nature of this question.
Supports Web-Enabled Employee Facing Applications: Many accounting systems give users access to some or all of the system. This question lists some of those access options regardless of how the applications can be accessed (browser or wireless).
Microsoft Compliance: Since Microsoft is such a huge influence on all markets, this question tries to determine how closely the vendor's product complies with some of the standards set by Microsoft and/or Microsoft products.
Specific Application Support: As users are trying to decide which accounting systems they should be examining in more detail, they may have difficulty defining specific requirements, or we might not list all of their requirements in detail, or at all for that matter. This question is designed to assist users define in very general terms the functional areas in which they have an interest. By listing just the functional areas, they might look on this list as a quick and dirty needs definition, and that may be sufficient. Consultants may utilize the same approach when sitting down with a client for the first time. Rather than trying to get their client to immediately launch into a detailed needs definition, they might ask the client to list just the broad areas in which they have an interest. Once this broad needs definition has been utilized to identify products that offer the widest set of functions, the user and/or consultant may then restrict the detailed analysis to only those products.
Manufacturing Application Support: Manufacturing and light assembly can be thought of as a subset of a broad-based functional needs definition like the previous question. Since there are a number of functional areas within manufacturing and assembly, we have chosen to segregate them into their own set of questions.
EDI Functions Supported: EDI as a form of electronic commerce has been around for some years. While it is slowly being replaced by the Internet as a means of communicating in a business to business environment, its importance will remain for several years, if not longer. This question identifies some of the more common form of electronic communication via EDI.
Inter/Intranet Functions Supported: Obviously the Internet and Intranet are one of the fastest growing segments of commerce today. This question tries to identify many of the functional areas where the Internet or Intranet would assist organizations serve their customers more effectively and reduce processing costs at the same time. This list is not exhaustive. Other capabilities have been listed in the Order Entry section of the questionnaire.
Supports Customer Facing Portal: A portal is no more than an entry point for access to an accounting system. In this case a customer facing portal is an Internet Web page that allows users to access specific functions within the accounting system. The question lists some of the applications customers can access. In some respects the portal can be thought of as a common point of entry for all customers but one that gives users the ability to customize the portal to grant access to specific functions depending upon the customer.
OLAP Functions Supported: On Line Analytical Processing (OLAP) is a term used to describe the ability of a product to support sophisticated multi-dimensional queries using either a third-party application and a vendor-supplied data dictionary, or the automatic transfer of data to an OLAP database such as Essbase, or through a vendor supplied OLAP tool or application.
Control and Audit: As has been demonstrated when reviewing the questions for each application, control and audit information helps keep a business management system accurate. This series of questions identifies general or system wide control and audit factors that may be of interest.
Operational Functionality: This series of questions tries to help users understand how each business management system under consideration operates on a daily basis.
Reports: While application specific reports have been listed under each application area, this series of questions sheds some light on the reporting system in general.
Technology Evaluation Centers, Inc. Request for Information/Proposal Requirements Research
Instructions
RFI Rating Legend Format
● The top of the RFI tab contains six response columns. ● TEC analysts developed the RFI based on past experience and research into the widest and deepest range of possible requirements. 3RD CST FUT NS Priority Response Explanation SUP Supported as delivered "out-of-the-box" MOD Supported via modifications (screen configurations, reports, GUI tailoring, etc) Supported via a third party solution Supported via customization (changes to source code) Will be supported in a future release Not supported 0 to 10, where 10 is most important
Mandatory Yes, only for "must-have" factors
RFI Example Vendor Responses
● Complete the RFI worksheet by placing an X in the appropriate column for each criterion. ● The Xs represent the current state of a product or service. 1 1.1 1.1.1 1.1.1.1 1.1.1.2 1.1.1.3 1.1.1.4 1.1.1.5 1.1.1.6 Hierarchy Module 1 Category of Module 1 Subcategory of Category 1 Criterion 1 Criterion 2 Criterion 3 Criterion 4 Criterion 5 Criterion 6 Criterion
15
User Responses
● Use the Priority column to indicate how important a particular criterion or entire group of criteria (module or category) is for your organization. ● The Mandatory column is useful for indicating absolute requirements. Note that a "Yes" would mean a vendor/provider fails if it does not support that criterion or group of criteria. It is often useful to use "No" as the general default response and only change to a "Yes" for an absolutely critical item. Don't forget to indicate your priorities and mandatory requirements for modules, categories, subcategories, and criteria.
RFI Example
Priority (0-10) 9 5 10 1 5 5 10 7 9 Mandatory (Y/N) Y Y Y N Y N N N Y X X X X X X SUP MOD 3RD CST FUT NS