Accounting Software Selection RFP Template

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 ar